HTTP/1 to HTTP/2 to HTTP/3

HTTP/1 to HTTP/2 to HTTP/3

 

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  استفاده میکنند.

از بهترین نوشته‌های کاربران سکان آکادمی در سکان پلاس


online-support-icon