HTTP امروز
HTTP 1.1 تبدیل به پرتکلی شده که این روز‌ها، تقریبا برای همه‌چیز در اینترنت استفاده می‌شود. سرمایه‌گذاری‌های عظیمی در پرتکل‌ها و زیرساخت‌هایی که از HTTP 1.1 بهره می‌برند شده است، به دلیل این‌که اغلب اوقات، اجرا‌کردن چیزی روی HTTP راحت‌تر از ساختن چیزی از نو است.
هنگامی که HTTP ساخته شده و به دنیا عرضه شد، بسیاری آن را یک پرتکل ساده و سرراست یافتند، ولی زمان ثابت کرد که این دیدگاه نادرست است. HTTP 1.0 در استاندارد RFC 1945 تنها در ۶۰ صفحه توصیف شده است که در سال ۱۹۹۶ منتشر شد. RFC 2616 که HTTP 1.1 را توضیح می‌دهد، در یک رشد قابل‌توجه، به ۱۷۶ صفحه هم می‌رسد. هنوز هم هنگامی که در IETF روی استاندارد‌های مربوط به آن کار می‌کنیم، [ناچارا] آن را به ۶ سند، که تعداد صفحات آن‌ها روی هم بسیار بیشتری می‌شود، تقسیم کردیم که حاصل آن، استاندارد RFC 7230 و خانواده شد. به هر حال، HTTP 1.1 بزرگ است و دارای جزئیات و ظریف‌کاری‌های بسیار، و البته امکانات اختیاری است.
طبیعت HTTP 1.1، داشتن جزئیات بسیار و گزینه‌های موجود برای افزونه‌های بعدی، تبدیل به یک اکوسیستم نرم‌افزاری شد که تقریبا هیچ پیاده‌سازی، همه‌چیز را پیاده‌سازی نمی‌کند، و حتی ممکن نیست که دقیقا بگوییم که این «همه‌چیز» چه چیزهایی هستند. این ویژگی باعث به‌وجودآمدن شرایطی شد که قابلیت‌هایی که در ابتدا، بسیار کم‌استفاده بودند، به ندرت پیاده‌سازی شدند و کسانی که این قابلیت‌ها را پیاده‌سازی کردند، متوجه شدند که کاربردهای بسیار کمی برای آن‌ها وجود دارد.
بعدها، این ویژگی‌ها باعث ایجاد ناهماهنگی بین کلاینت‌ها و سرورهایی که از این قابلیت‌ها استفاده می‌کردند شد. HTTP pipelining از نمونه‌های بارز این قابلیت‌ها است.
HTTP 1.1 به سختی از همه‌ی مزایا، قدرت و کارایی TCP استفاده می‌کند. کلاینت‌های HTTP و مرورگرها باید در پی یافتن راه‌های خلاقانه برای کاهش زمان بارگذاری صفحات باشند.
تلاش‌های دیگری که در طول این سال‌ها به طور موازی پیگیری می‌شدند هم نشان داده‌اند که جایگزین‌کردن TCP کار راحتی نیست، به همین دلیل ما روی بهبود TCP و پرتکل‌های وابسته به آن کار می‌کنیم.
به عبارت دیگر، TCP می‌تواند به گونه‌ای استفاده شود که وقفه‌ها را کمتر کند یا از بازه‌های زمانی تلف‌شده برای ارسال و دریافت داده‌های بیشتری استفاده شود. قسمت‌های بعدی بعضی از این کاستی‌ها را نمایان می‌کنند.
وقتی به آمارهای امروزی درمورد پرطرفدارترین وب‌سایت‌ها و صفحه‌های اول آن‌ها نگاه می‌کنیم، یک الگوی مشخص را می‌توان برداشت کرد. در طول این سال‌ها، حجم داده‌هایی که باید برای بازکردن این صفحات مبادله کرد، به ۱.۹ مگابایت رسیده است. چیزی که دراین‌باره مهم‌تر است، این است که بیش از ۱۰۰ فایل مختلف برای نمایش هر صفحه لازم است.
همان‌طور که نمودار زیر نشان می‌دهد، این روند به همین منوال در حال پیش‌رفت است و کمتر نشانه‌ای از تغییر در آینده‌ای نزدیک به چشم می‌خورد. این نمودار، رشد اندازه‌ی داده‌های مبادله‌شده (با رنگ سبز) و میانگین تعداد درخواست‌ها (قرمز) را در وب‌سایت‌های پرطرفدار اینترنت نشان می‌دهد و این‌که این ارقام چگونه در یک بازه‌ی ۴ ساله تغییر کرده‌اند.
رشد اندازه‌ی مبادلات
HTTP 1.1 بسیار به تأخیر حساس است، می‌توان گفت بخشی از این حساسیت به دلیل این است که HTTP pipelining هنوز آن‌قدر مشکل دارد که اکثر کاربران نتوانند از آن استفاده کنند.
با این که شاهد رشد عظیمی در پهنای‌باند در‌دسترس مردم در چند سال اخیر بوده‌ایم، ولی به همان نسبت،، اقدامی برای کاهش این تأخیرها نشده است. ارتباطات با تأخیر بالا، مانند فناوری‌های کنونی موبایل، داشتن یک تجربه‌ی وب‌گردی خوب و سریع را سخت می‌کند، حتی اگر پهنای باند بسیار بالایی هم در اختیار داشته باشید.
مورد استفاده‌ی دیگری از تأخیرهای پایین، نوع‌های خاصی از ویدیو هستند، مانند ویدیوکنفرانس، گیمینگ و مشابه‌های آن که هیچ جریان از‌پیش‌ساخته‌ای برای ارسال وجود ندارند.
HTTP pipelining یک راه برای فرستادن یک درخواست دیگر، در حالی که منتظر پاسخ درخواست دیگری هستیم، است. این مفهوم بسیار شبیه به صف‌های بانک یا سوپرمارکت است. شما نمی‌دانید که نفر اول صف یک آدم تر و فرز است یا یک آدم مزاحم که وقت زیادی را تلف می‌کند تا کارش را انجام دهد.
البته، شما می‌توانید صفی را انتخاب کنید که فکر می‌کنید سریع‌تر است یا حتی صف خودتان را تشکیل بدهید. ولی در نهایت، شما نمی‌توانید تصمیم نگیرید. و وقتی تصمیم گرفتید، نمی‌توانید تصمیم خود را عوض کنید.
تشکیل یک صف جدید با هدررفت منابع و کارایی همراه است، پس هنگامی که تعداد صف‌ها بیشتر می‌شود دیگر کارایی ندارد. در واقع، هیچ راه‌حل بی‌نقصی برای این مشکل وجود ندارد.
حتی امروزه هم بیشتر مرورگرهای دسکتاپ با HTTP pipelining به صورت غیرفعال عرضه می‌شوند.
Last modified 3yr ago