دنیایی با http2
Last updated
Was this helpful?
Last updated
Was this helpful?
خب، وقتی http2 تصویب شود، دنیا چگونه خواهد شد؟ اصلا تصویب خواهد شد؟
http2 هنوز به‌طور گسترده نه پخش شده نه استفاده. ما نمی‌توانیم دقیقا بگوییم که چیزها چگونه تغییر خواهند کرد. ما دیدیم که SPDY مورداستفاده قرار گرفت و می‌توان با کمی محاسبات، حدس‌های نسبتا دقیقی براساس آزمایش‌های قبلی و کنونی زد.
http2 تعداد رفت و برگشت‌ها در شبکه را کاهش می‌دهد، مشکل Head-of-line blocking را با طور کامل با Multiplexing و پس‌زدن سریع استریم‌های ناخواسته، حل می‌کند.
این پرتکل اجازه می‌دهد که تعداد زیادی از استریم‌های موازی استفاده شود، حتی بیشتر از آن‌چه که سایت‌های توزیع‌شده (Sharded) ارائه می‌دهند.
با اختصاص اولویت‌های صحیح به استریم‌ها، احتمال این که کلاینت‌ها، اول داده‌های مهم‌تر را دریافت می‌کنند بیشتر می‌شود. با همه‌ی این‌ها، می‌توانم بگویم که احتمال این که این پرتکل به سریع‌تر‌شدن بارگذاری صفحات و پاسخ‌گویی آن‌ها منجر می‌شود، بسیار بالاست. خلاصه این‌که: یک تجربه‌ی بهتر از وب.
این‌که چقدر سریع‌تر و بهتر، خواهیم دید، ولی فکر نمی‌کنم الان بتوانیم چیزی بگوییم. اول این‌که این تکنولوژی هنوز بسیار جوان است و ما هنوز حتی شروع نکرده‌ایم که ببینم آیا کلاینت‌ها و سرورها و به طور کلی «پیاده‌سازی‌ها» از همه‌ی قدرت این پرتکل جدید استفاده خواهند کرد یا نه.
در طول این سال‌ها، توسعه‌دهندگان وب، جعبه ابزاری از ترفندها و ابزارها برای حل مشکلات HTTP 1.1 فراهم کرده‌اند، در اول این کتاب به بعضی از این مشکلات و راه‌حل‌ها اشاره کرده‌ام.
بسیاری از این راه‌حل‌هایی که ابزارها و توسعه‌دهندگان، این روز‌ها به طور پیش‌فرض و بدون فکر استفاده می‌کنند، احتمالا به کارایی http2 آسیب خواهند زد یا حداقل از ابرقدرت‌های جدید http2 بهره نخواهند برد. Spriting و Inlining نباید در http2 انجام شوند. Sharding یا توزیع‌کردن هم به کارایی http2 آسیب می‌زند و احتمالا تنها از تعداد کانکشن‌های کمتر سود خواهد برد.
مشکلی که اینجاست، این است که وب‌سایت‌ها و توسعه‌دهندگان آن‌ها باید در مدت کوتاهی، محصولات خود را برای دنیایی ارائه دهند که در آن هم کاربران HTTP 1.1 وجود دارند هم http2 ارائه دهند. ارائه‌ی حداکثر سرعت و کارایی برای همه‌ی کاربران بدون ارائه‌ی دو نوع فرانت‌اند، چالش‌بر‌انگیز خواهد بود.
به همین دلیل‌ها، احتمالا مدتی طول خواهد کشید که ببینیم از همه‌ی ظرفیت‌های http2 استفاده می‌شود.
تلاش‌کردن برای مستند‌کردن پیاده‌سازی‌های خاص در چنین نوشته‌ای، کار بیهوده‌ای است و تنها بعد از مدتی، قدیمی می‌شود. به جای این کار، شرایط به طور عمومی‌تری توضیح می‌دهم و خوانندگان را به در وب‌سایت http2 ارجاع می‌دهم.
در ابتدا، پیاده‌سازی‌های بسیاری وجود داشتند و تعداد آن‌ها به مرور زمان افزایش پیدا کرد. در هنگام نوشتن این کتاب، حدود ۴۰ پیاده‌سازی لیست شده‌اند و بیشتر آن‌ها ورژن نهایی را پیاده کرده‌اند.
فایرفاکس مرورگری بوده که همواره آخرین ویژگی‌ها را پیاده‌سازی کرده، توییتر نیز سرویس‌هایش را بر پرتکل http2 ارائه می‌دهد. گوگل از آپریل ۲۰۱۴ شروع به پشتیبانی از http2 در چند سرور آزمایشی کرد و از می ۲۰۱۴، پشتیبانی از http2 را در ورژن‌های توسعه‌دهندگان Chrome کردند. ماکروسافت نیز یک پیش‌نمایش از پشتیبانی از http2 در نسخه‌ی بعدی Internet Explorer نشان دهند. سافاری (در iOS 9 و Mac OS X El Capitan) و اپرا نیز هر دو اعلام کردند که به زودی پشتیبانی خواهند کرد.
پیاده‌سازی‌های زیادی از http2 در سمت سرور وجود دارد.
curl و libcurl از http2 نا‌امن و همچنین امن بر مبنای TLS پشتیبانی می‌کنند.
Wireshark که بهترین ابزار برای آنالیز ترافیک http2 است نیز پشتیبانی می‌کند.
هنگام توسعه‌ی این پرتکل، گاهی افراد شک می‌کردند که احتمالا نتیجه از سوی بعضی به عنوان یک پرتکل اشتباه خوانده خواهد شد. بعضی از انتقادات وارد به این پرتکل و توجیه درست یا غلط‌بودن آن‌ها را در ادامه می‌آورم.
این دیدگاه، به روش‌های دیگری هم بیان می‌شود که در آینده، دنیا به گوگل وابسته خواهد شد و یا کنترل می‌شود. این درست نیست. این پرتکل در IETF و به همان روشی که ۳۰ سال است پرتکل‌ها طراحی می‌شوند، طراحی شد. اما، همه‌ی ما کار تأثیرگذار گوگل با SPDY را دیدیم که ثابت کرد که نه تنها ممکن است که یک پرتکل جدید منتشر کنیم، بلکه آمارها نشان دادند که چه چیز‌هایی حاصل خواهد شد.
این دیدگاه تا حدودی درست است. یکی از انگیزه‌های اصلی توسعه‌ی http2، حل‌کردن مشکل HTTP Pipelining است. اگر برنامه‌ی شما نیازی به این تکنولوژی ندارد، پس احتمالا http2 تأثیر مثبت چندانی بر برنامه‌ی شما نخواهد گذاشت. البته، HTTP Pipelining تنها قابلیت اضافه‌شده در این پرتکل نیست.
وقتی سرویس‌ها متوجه شوند که قدرت و توانایی‌های استریم‌های Multiplexed در یک کانکشن چقدر است، احتمال می‌دهم که اپلیکیشن‌های بیشتری از http2 استفاده کنند.
REST APIهای کوچک و برنامه‌های کوچک مبتنی بر HTTP 1.x احتمالا دلیلی برای مهاجرت به http2 نخواهند یافت. ولی همچنین، معایب‌های خیلی کمی برای کاربران این سرویس‌ها بر بستر http2 به چشم می‌آید.
نه اصلا! قابلیت‌های Multiplexing به بهبود تجربه‌ی وب‌گردی در کانکشن‌هایی با تأخیر زیاد حتی در سایت‌های کوچکی که توزیع جغرافیایی (CDN) ندارند نیز کمک می‌کند. سایت‌های بزرگ معمولا بسیار سریع‌ترند و از سرورهای بیشتری برای کاهش زمان دریافت داده‌ها استفاده می‌کنند.
بسیاری از کاربران اینترنت اعلام کرده‌اند که استفاده از TLS را به‌طور گسترده‌تر ترجیح می‌دهند، چرا که باعث می‌شود حریم خصوصی کاربران محافظت شود.
آزمایش‌ها همچنین نشان داده‌اند که با استفاده از TLS، شانس بیشتری نسبت به پیاده‌سازی پرتکل‌های متن ساده برای موفقیت وجود دارد، چرا که پرتکل‌های متن‌ساده‌ای که بر پورت ۸۰ پیاده‌سازی می‌شوند، موانع زیادی در سر‌راه خود دارند که ممکن است اختلال ایجاد کنند، چرا که فکر می‌کنند HTTP 1.1 است که در پورت ۸۰ رد و بدل می‌شود.
در آخر، به لطف استریم‌های Multiplexشده‌ی http2 بر روی یک کانکشن، مرورگرهای معمولی می‌توانند ارتباط‌های اولیه‌ی خیلی کمتری بر بستر TLS انجام دهند و در نتیجه سریع‌تر از HTTPS در HTTP 1.1 عمل کنند.
بله، ما دوست داریم که اطلاعاتی که پرتکل‌ها مبادله می‌کنند را به طور واضح ببینیم، چرا که ردگیری و دیباگ‌کردن آن‌ها را آسان می‌کند. ولی پرتکل‌های برمبنای‌متن به خطا حساس هستند و مشکلات زیادی را برای پردازش متن‌های گرفته‌شده دارند.
اگر شما نمی‌توانید یک پرتکل باینری را تحمل کنید، بنابراین نباید اصلا از TLS و فشرده‌سازی در HTTP 1.x استفاده کنید، با این که هر دو مدت زیادی است که وجود دارند.
جدا این نقد شماست؟ لایه‌ها جزئی از یک دین مقدس جهانی نیستند که نتوان به آن‌ها دست زد. ما به منطقه‌های خاکستری (نسبتا خطرناک) وارد شدیم تا http2 را یک پرتکل خوب و مؤثر در چارچوب مرزها کنیم.
این درست است. چون هدف ما، حفظ پاراداریم‌های HTTP/1.1 بود، بعضی از قابلیت‌های قدیمی HTTP باید می‌ماندند، مثل هدرهای مرسوم که معمولا شامل Cookies هم می‌شدند، هدرهای احراز هویت و غیره. ولی مزیت نگه‌داشتن این پارادایم‌ها این است که ما پرتکلی داریم که انتشار آن، بدون حجم زیادی از کار برای به‌روز‌رسانی آن و جایگرینی زیرساخت‌های قبلی، ممکن است. http2 اساسا فقط یک لایه‌ی جدید برای Framing است.
هنوز بسیار زود است که بتوانیم با یقین حرف بزنیم، ولی می‌توانیم حدس‌هایی بزنیم که آن را در ادامه می‌آورم.
مخالفان خواهند گفت که «ببینید که IPv6 چقدر خوب عمل کرده!» تا مثالی برای پرتکل جدیدی بیاورند که دهه‌ها طول کشید تا به طور جهانی گسترش یابد. البته، پرتکل http2 اصلا شبیه IPv6 نیست. این پرتکلی بر مبنای TCP است و از همان مکانیزم‌های آپگرید HTTP، همان شماره‌ی پورت‌ها و همان TLS استفاده می‌کند و نیازی به تغییر روترها و فایروال‌ها ندارد.
گوگل با SPDY به دنیا ثابت کرد که یک پرتکل مانند این می‌تواند به طور جهانی گسترش یابد و در مرورگرها و سرویس‌ها با پیاده‌سازی‌های مختلف در مدت زمان نسبتا کوتاهی استفاده شود. در حالی که تعداد سرویس‌هایی که SPDY را ارائه می‌دهند، در حدود ۱٪ است، ولی مقدار داده‌هایی که این سرویس‌ها مبادله می‌کنند بسیار بزرگ است. بعضی از پرطرفدارترین وب‌سایت‌های امروزی، SPDY ارائه می‌دهند.
http2 بر مبنای همان پارادایم‌های SPDY است، می‌توانم بگویم که احتمال گسترش آن نسبت به SPDY بسیار بیشتر است، چرا که استانداردی است که از سوی IETF ارائه می‌شود. توسعه‌ی SPDY همیشه با توجیه این‌که «پرتکل ساخته‌ی گوگل است» پس زده شده.
مرورگرهای بسیاری از این به‌روز‌رسانی حمایت کردند. نمایندگانی از Firefox, Chrome, Safari, Internet Explorer و Opera اعلام کرده‌اند که مرورگرهای http2 خود را ارائه کرده‌اند یا خواهند کرد.
اپراتورهای سرویس‌های بزرگ به زودی http2 را ارائه خواهند داد، مانند گوگل، توئیتر و فیس‌بوک. امیدواریم که به زودی پشتیبانی از http2 را در پیاده‌سازی‌های سمت‌سرور مانند Apache httpd و nginx ببینیم. H2O نیز یک سرور HTTP سریع است که از http2 نیز پشتیبانی می‌کند.
بعضی از بزرگ‌ترین فروشندگان پراکسی، مثل HAProxy, Squid و Varnish نیز تمایل خود را برای پشتیبانی از http2 اعلام کرده‌اند.
در سراسر سال ۲۰۱۵، ترافیک http2 در حال افزایش بوده است. در اوایل سپتامبر، سهم فایرفاکس ۴۰ از ترافیک HTTP حدود ۱۳٪ و از HTTPS حدود ۲۷٪ بوده، در حالی که گوگل حدود ۱۸٪ از درخواست‌های ارسالی را HTTP/2 می‌دانسته. باید به این نکته توجه داشت که گوگل در حال آزمایش پرتکل‌های جدیدتری است (QUIC را در قسمت ۱۲.۱ ببینید) که میزان استفاده‌ی http2 را از آن‌چه که می‌توانست باشد، کمتر می‌کند.
سرور nginx از http2 از نسخه‌ی که در سپتامبر ۲۰۱۵ منتشر شد (این قابلیت، جایگزین ماجول SPDY شد تا نتوانند هر دو در یک سرور اجرا شوند.)
سرور httpd آپاچی نیز یک ماجول http2 به نام از نسخه‌ی ۲.۴.۱۷ دارد که در نهم اکتبر ۲۰۱۵ منتشر شد.
, , , و نیز از http2 پشتیبانی می‌کنند.
گوگل به طور عمومی که پشتیبانی از SPDY و NPN را از Chrome در ۲۰۱۶ حذف می‌کنند و سرورها را مجبور به مهاجرت به HTTP/2 می‌کنند. در فبریه‌ی ۲۰۱۶ آن‌ها که SPDY و NPN بالاخره در Chrome 51 حذف شدند.
از جهاتی این مورد می‌تواند صحیح باشد. ارتباط اولیه (Handshake) در TLS می‌تواند سرعت را تا حدی کاهش دهد، ولی کارهایی در حال انجام‌شدن است تا این فرآیند سریع‌تر شود. ولی سربار حاصل از جایگزینی متن ساده با TLS خصوصا در CPU و انرژی، قابل‌چشم‌پوشی نیست، در حالی که اگر همان ترافیک و داده‌ها با متن ساده رد و بدل شوند، انرژی کمتری می‌برد. این که میزان تأثیر چه‌قدر است، مورد بحث بوده و اندازه‌گیری‌هایی نیز در این رابطه انجام شده است. برای مثال سایت از نمونه‌ی یکی از این منابع برای آزمایش‌های انجام‌شده است.
برای مثال Telecom و دیگر اپراتورهای شبکه، در اتحاد وب باز ATIS، اعلام کرده‌اند که به نیاز دارند تا بتوانند Caching، فشرده‌سازی و تکنیک‌های دیگر برای ارائه‌ی تجربه‌ی وب سریع‌تر را در اختیار کاربران از طریق ماهواره‌ها قرار دهند. http2 استفاده از TLS را اجبار نمی‌داند، بنابراین نباید با این بندها تداخلی داشته باشد.
این موضوعی شک‌برانگیز و بحث‌برانگیز است که دقیقا سریع‌تر چه معنایی دارد، ولی در SPDY، قبلا آزمایش‌های زیادی انجام شده که ثابت می‌کند سرعت بارگذاری صفحات در مرورگرها بیشتر می‌شود (مثل که توسط افرادی در دانشگاه واشنگتن تهیه‌شده یا که توسط Hervé Servy نوشته شده) و چنین آزمایش‌هایی با http2 هم تکرار‌شده‌اند. من منتظر دیدن آزمایش‌های بیشتری هستم. یک ساخته‌شده که نشان می‌دهد HTTP/2 به قول‌های خود وفا می‌کند.