HTTP از دهه 90 میلادی وجود داشته و در طول سالها تکامل پیدا کرده. آخرین ورژنی هم که از آن توسعه پیدا کرده ، HTTP/3 هست. HTTP/1 در سال 1996 عرضه شد. این نسخه با TCP کار میکرد. هر درخواستی که به یک سرور مشابه ارسال میشد نیاز به یک TCP Connection جداگانه داشت.
HTTP 1.1 در سال 1997 به دنبال HTTP 1 عرضه شد. ویژگی متمایز آن، وجود مکانیزم Keep Alive بود. این کار یعنی اینکه بتوانیم از یک connection برای بیشتر از یک درخواست استفاده کنیم.
کانکشن های دائمی یا persistence connection ها باعث کاهش latency درخواستها میشوند زیرا که کلاینت ، دیگر نیازی به initiate کردن TCP three way handshake برای هر درخواست ندارد. این فرآنید به لحاظ زمانی و پردازشی، یک فرآیند پرهزینه در مقیاس بالا به حساب میرود.
ضمنا یک HTTP1.1 دارای یک مکانیزم دیگر به نام pipelining هست. این موضوع در تئوری به کلاینت این اجازه را میدهد تا قبل از انتظار برای هر response ، چندین request را ارسال کند. response ها باید به همان ترتیب request ها دریافت شود.
البته اجرای صحیح این موضوع مشکل بود. چون همانطور که گفته شد، پاسخ ها باید به همان ترتیب که request ها فرستاده میشوند، دریافت میشدند و بسیاری از سرورهای پراکسی در این بین، pipelining را نمیتوانستند به درستی مدیریت کنند. این باعث شد که پشتیبانی از این پروتکل در نهایت از بسیاری از مرورگرها حذف شد.
HTTP1.1 با مکانیزم pipelining یک مشکل دیگر داشت به نام head of line blocking. بدون head of line blocking درخواستهای بعدی یا به اصطلاح، sub sequence request ها در همان connection باید منتظر تکمیل درخواستهای قبل باشند. اگر درخواستی به هر دلیلی مانند packet lost بلاک شود، همه ی درخواستهای بعدی که در همان کانکشن هستند، تحت تاثیر قرار میگیرند.
برای حفظ performance loading در یک سطح قابل قبول، مرورگرها معمولا چندین اتصال TCP را به یک سرور نگه میدارند و درخواستها را به صورت موازی به آن ارسال میکنند.
HTTP 2 در سال 2015 منتشر شد . این ورژن در واقع، HTTP Streams را معرفی کرد. یعنی بتوان چندین stream request را به یک سرور مشابه در یک TCP Connection واحد ارسال کرد( compressed header ).
برخلاف HTTP 1.1 pipelining ، هر جریانی مستقل از یکدیگر هست ونیازی به ارسال یا دریافت به ترتیب ندارد.
HTTP2 مشکل head of line blocking را در لایه application حل کرد ولی در لایه transport این مشکل همچنان با TCP وجود دارد.
همچنین درنظر داشته باشید که HTTP2 یک قابلیت Push را معرفی کرده تا به سرور ها این اجازه را بدهد که هر زمان داده های جدیدی را که در دسترس هستند را سریعا برای کلاینت بروز کنند.
HTTP3 بعنوان یک پیش نویس در سال 2020 آغاز شد و در ابتدای ژوئن سال 22022 عرضه شد. این ورژن از پروتکل جدیدی به نام QUIC به جای TCP بعنوان پروتکل اصلی انتقال استفاده میکند. QUIC برمبنای UDP است و Streamها را به عنوان first class citizen در لایه transport معرفی میکند. stream های از نوع QUIC اتصال های سریع یکسانی را به اشتراک میگذارند بنابراین نیازی به handshake های اضافی برای ایجاد موارد جدید نیست.
QUIC Stream ها به طور مستقل تحویل داده می شوند. در بیشتر موارد، packet lost بر روی یک stream تاثیر میگذارد و برروی دیگر streamها تاثیر نمیگذارد. به این ترتیب QUIC مشکل head of line blocking را در لایه transport حل میکند.
QUIC برای استفاده سنگین از اینترنت موبایل طراحی شده.امروزه افرادی که از گوشی های هوشمند استفاده میکنند، در طول روز به طور مداوم از یک شبکه به یک شبکه دیگر سوییچ میکنند. مثلا از اینترنت موبایل به اینترنت ثابت و ... که با TCP ، انتقال از یک شبکه به یک شبکه دیگر کند انجام میشود. QUIC مفهومی به نام Connection ID را پیاده سازی میکند که به connection ها این اجازه را میدهد که بین IP Address های مختلف و رابط های شبکه به سرعت و با اطمینان حرکت کند.
در این صورت حتی اگر نتورک عوض شود چون connection ID ها یکسان هستند بنابراین دیگر نیاز به باز شدن یک کانکشن جدید نیست و از همان کانکشن در ادامه استفاده میشود.
امروزه بیشتر مروگر ها از HTTP3 استفاده میکنند.
