متن زیر ترجمه اجمالی مقاله‌ای است که به معرفی پروتکل جدید ارائه شده توسط گوگل به نام `SPDY` می پردازد. این مقاله را دوست خوبم نوند نمیرانیان ترجمه کرده است. البته نا گفته نماند که مطلب زیر کامل و بخش اندکی از مقاله اصلی ترجمه نشده است.

خلاصه ی اجرایی:

به عنوان قسمتی از ابتکار "Let's make the web faster"، ما در حال آزمایش با پروتکل های جایگزین برای کمک به کاهش زمان تاخیرصفحات وب هستیم. یکی از این آزمایشات SPDY است، یک پروتکل لایه ی Application برای حمل و نقل محتوا بر روی وب که به طور خاص برای حداقل کردن تاخیر طراحی شده است. علاوه بر مشخصات پروتکل، ما یک Google Chrome که در آن SPDY فعال شده است و همچنین یک وب سرور Open Source راه اندازی کرده ایم. در تست های آزمایشگاهی ما عملکرد این برنامه ها را بر روی HTTP و SPDY مقایسه کردیم، که تا ۶۴٪ کاهش زمان بارگزاری صفحه در SPDY مشاهده شد. ما امیدواریم تا با شرکت کردن جامعه منبع باز(Open source Community) و به کمک نظرات، انتقادات و پیشنهادات، کد و نتایج آزمون، SPDY را نسل بعدی پروتکل Applicationبرای سریعتر شدن وب قرار بدهیم.

پیش زمینه: پروتکل های وب و تاخیر وب

امروزه، HTTP و TCP پروتکل های وب هستند. TCP یک پروتکل عمومی است که دارای ویژگی هایی چون: حمل و نقل قابل اعتماد(Transport)، ارایه تحویل تضمین شده، جلوگیری از تکرار، in-order delivery، کنترل جریان، اجتناب از تراکم و ویژگی های دیگر در حمل و نقل. HTTP یک پروتکل سطح کاربر (Application) است که وظیفه ی تهیه ی مفاهیم اولیه request/response را بر عهده دارد. در حالی که ما باور داریم ممکن است فرصت هایی برای بهبود تاخیر در لایه ی انتقال (Transport) وجود دارد، تحقیقات اولیه ما بر روی لایه ی کاربرد (Application)،و HTTP متمرکز شده است.

متاسفانه، HTTP برای جلوگیری از تاخیر طراحی نشده است یا به زبان دیگر این ویژگی را دارا نمی باشد. علاوه بر این، صفحات وب که امروزه منتقل می شوند به طور قابل توجهی متفاوت از صفحات ۱۰ سال پیش  می باشند و بهبود تقاضا در HTTP نمی توانست پیش بینی شده باشد زمانی که  توسعه داده شد. موارد زیر بخشی از ویژگی های HTTP می باشد که مانع عملکر مطلوب آن می شود:

  • یک request در هر connection. از آنجایی که HTTP تنها می تواند یک منبع را در آن واحد در اختیار داشته باشد (خط لوله ی HTTP به این عمل کمک می کند، اما هنوز هم  تنها یک صف FIFO را به اجرا می گذارد) تاخیر سرور از ۵۰۰ میلی ثانیه مانع استفاده مجدد از کانال TCP برای request های اضافی می شود.
  • منحصرا مشتری (Client) درخواست را شروع می کند. در HTTP، تنها مشتری (Client) می تواند یک request یا به عبارتی درخواست را شروع کند. حتی اگر سرور بداند که مشتری (Client) نیاز به منبعی دارد، هیچ ساز و کاری برای اطلاع دادن به مشتری (Client) وجود ندارد و به جای آن باید صبر کند تا درخواست منبع از جانب مشتری (Client) دریافت شود.
  • سرآیند request و response فشرده نشده است. سرآیند request امروزه بین ۲۰۰ بایت تا ۲ کیلوبایت متغییر است. به عنوان مثال برنامه هایی که استفاده بیشتری از Cookies و ویژگی های کاربردی می کنند، معمولا سرآیندی (Header)  با حجمی بین ۷۰۰ تا ۸۰۰ بایت متداول است. برای مودم ها و اتصالات ADSL، که پهنای باند uplink آن نسبتا کم است، این تاخیر می تواند قابل توجه باشد. کاهش داده در سرآیند می تواند مستقیما تسلسل تاخیر را برای ارسال درخواست بهبود بخشد.
  • سرآیند زاید، علاوه بر این چندین سرآیند بارها و بارها در سراسر درخواست های همان کانال ارسال می شوند. با این حال سرآیندهایی مانند User-Agent ، Host و Accept* به طور کلی ثابت هسنتد و نیازی به ارسال مجدد ندارند.
  • فشرده سازی داده ها اختیاری است. HTTP از سیستم های کد گذاری فشرده سازی اختیاری برای داده ها استفاده می کند. مطالب همواره باید به فرمت فشرده ارسال شوند.

دیدگاه های قبلی

SPDY تنها یک تحقیق برای سریعتر کردن HTTP نیست. راه حل های پیشنهادی دیگری که عمدتا در سطح لایه ی انتقال یا Session وجود داشته است:

  • Stream Control Transmission Protocol (SCTP):

یک پروتکل لایه ی انتقال به جای TCP، که وظیفه تسهیم جریان و جریان آگاه کنترل ازدحام (Congestion control)را بر عهده داشت.

  • HTTP over SCTP: یک پیشنهاد برای اجرای HTTP بر روی SCTP. مقایسه HTTP بر روی SCTP و TCP در شبکه هایی با تاخیر بالا یک مطالعه تحقیقاتی در مقایسه با توصیف عملکرد بر روی هر دو پروتکل لایه شبکه بوده است.
  • Structured Stream Transport (SST):

یک پروتکل که اختراع "جریان سازمان یافته" بوده: جریان های سبک و مستقلی که روی لایه ی انتقال جابه جا می شوند. که می توان به جای TCP استفاده بشوند و یا بر روی UDP اجرا بشوند.

  • MUX and SMUX:پروتکل های لایه ی میانی (بین لایه ی انتقال و لایه ی کاربرد) که وظیفه ی تسهیم جریان را بر عهده دارد. این ها سال ها پیش هم زمان با HTTP/1.1 مطرح شدند.

این پیشنهادات راه حل هایی را برای برخی از مشکلات تاخیر صفحات وب ارایه دادند، اما نه همه ی آنها. مشکلات ذاتی در HTTP (فشرده سازی، الویت بندی و غیره ) هنوز هم باید درست شوند، صرف نظر از زمینه ی پروتکل انتقال. در هر صورت، در عمل، گسترش تغییر در انتقال، کار بسیار دشواری است……..(ترجمه تشده)

اهداف SPDY

پروژه SPDY یک  پروتکل لایه ی کاربرد  برای وب است  که به شکل قابل توجهی  زمان تاخیر را کاهش می دهد. اهداف سطح بالای SPDY عبارت اند از:

  • کاهش ۵۰٪ در زمان بارگزاری صفحه. نتایج اولیه ما نزدیک به این هدف هستند.
  • به حداقل رساندن پیچیدگی در توسعه دادن و گسترش. به دلیل استفاده SPDY از TCP به عنوان زمینه ای از لایه ی انتقال، بنابراین نیازی به تغییر در زیر ساخت شبکه وجود ندارد.
  • اجتناب از نیاز به تغییر محتوای وبسایت ها به وسیله ی نویسندگانشان. تنها تغییر مورد نیاز، پشتیبانی از SPDY در سرویس گیرنده کاربر(Client User Agent) و Web Server ها.
  • دور هم جمع کردن علاقه مندان برای پیدا کردن پروتکل هایی که بتوان راه حلی برای مشکل زمان تاخیر پیدا بکنند. ما امیدواریم این پروتکل جدید را با همکاری جوامع متن باز (Open Source) و متخصصان صنعت توسعه بدهیم.

برخی از اهداف خاص فنی:

  • اجازه می دهد تعداد بسیار زیادی HTTP request های همزمان در طول یک TCP Session اجرا شوند.
  • کاهش دادن پهنای باندی که هم اکنون توسط HTTP استفاده می شودُ به وسیله ی فشرده سازی سرآیندها و از بین بردن سرآیندهای غیر ضروری
  • تعریف یک پروتکل که راحت قابل پیاده سازی و کارآمد باشد. ما امیدواریم پیچیدگی HTTP را با حذف در edge cases و تعریف فرمت های ساده تری برای پیغام ها کاهش بدهیم.
  • برای اینکه SSL زیربنای پروتکل انتقال شود، برای امنیت بهتر و سازگاری با ساختارهای موجود شبکه. اگرچه SSL باعث به وجود آمدن تاخیر می شود، اما ما باور داریم که آینده وب به یک شبکه امن وابسته است. علاوه بر این استفاده از SSL برای اطمینان از نشکستن ارتباط در بین یک اتصال (Connection) الزامی است.
  • سرور توانایی این را داشته باشد که با مشتری (Client) ارتباط برقرار کند و داده ها را هر وقت ممکن بود برای Client بفرستد.

طرح و ویژگی های SPDY

SPDY یک لایه Session را در بالای لایه ی SSL می افزاید که موجب بروز همزمانی را می دهد، بروز جریانات لایه ای تنها بر روی یک اتصال TCP.

فرمت پیغام های HTTP POST و GET معمول به شکل قبلی خود باقی می مانند؛ با این حال، SPDY یک فرمت قالب بندی جدید را برای کد گذاری و انتقال داده ها بر روی سیم مشخص می کند.

ایجاد جریان دو طرفه که هم به وسیله ی client و هم به وسیله ی server می تواند ایجاد شود.

SPDY با استفاده از ویژگی های عمومی خود که همیشه فعال هستند و ویژگی های پیشرفته که به صورت اختیاری می باشند به ما کمک می کنند تا تاخیر کمتری را داشته باشیم.

ویژگی های عمومی

  • جریان های چند گانه
  • SPDY به ما این اجازه را می دهد تا جریان های همزمان و نا محدودی را بر روی یک TCP Connection داشته باشیم. از آنجایی که requestها در یک کانال تک لایه ای هستند، بهره وری از TCP بسیار بالاتر است: تعداد Connection کمتری نیاز به ایجاد است و کمتر، اما تراکم بسته ها بالاست.
  • الویت بندی در request
  • اگرچه جریان موازی نامحدود مشکل تسلسل را حل می کند، آنها یک مورد دیگر را تعریف کردن: اگر پهنای باند در کانال محدود است، client ممکن است به دلیل ترس از گرفتگی کانال request ها را مسدود کند. برای غلبه بر این مشکل، SPDY اولویت در درخواست ها (requests) را پیاده سازی کرده است: client می تواند هر تعداد درخواستی را که خواست از server بکند و اولویتی به هر request بدهد. این عمل مانع می شود که کانال با منابع غیر ضروری پر شود در حالی که یک request با اولویت بالا وجود دارد.
  • فشرده سازی در سرآیند HTTP
  • SPDY سرآیند HTTP request  و response را فشرده سازی می کند و باعث می شود تعداد کمتری بسته و بایت منتقل شود.

ویژگی های پیشرفته

علاوه بر این SPDY ویژگی های پیشرفته ای را فراهم می کند، جریان های آغاز شده توسط server. جریان های آغاز شده توسط server و(server-initiated streams) می تواند به منظور ارسال محتوا به client بدون نیازی به پرسش از جانب client باشند. این گزینه به وسیله ی توسعه دهندگان وب به دور روش زیر قابل تنظیم است:

  • Server push
  • آزمایشات SPDY با گزینه ای برای server  صورت گرفت که server می تواند با استفاده از سرآیند X-Associated-Content داده ها را برای client بفرستد. این سرآیند این آگاهی را به client می دهد که server در حال ارسال منابعی به client است قبل از اینکه client آنها را پرسش کند. برای دریافت اولیه صفحه (مثلا اولین باری که کاربر یک سایت را نگاه می کند)، این امر موجب بسیار بالا رفتن تجربه client می شود.
  • Server hint
  • به جای اینکه server به صورت خودکار منابع را به سمت client سوق دهد، server با استفاده از سرآیند X-Subresources به client پیشنهاد می دهد که ممکن است این منبع را درخواست کند، این عمل زمانی رخ می دهد که server از قبل بداند که client نیاز به این منبع دارد. با این حال server هنوز هم برای درخواست مشتری قبل از ارسال مطالب باید صبر کند. بر روی لینک های کند، این گزینه می تواند زمانی که طول می کشد تا client دنبال منبع مورد نیازش بگردد صدها میلی ثانیه کاهش یابد و ممکن است برای بار گزاری صفحاتی که برای بار اول باز می شوند مفیدتر باشد.

اجرای SPDY: آنچه ما ساخته ایم

SPDY گام های بعدی: چگونه می توانید کمک کنید

SPDY پرسش و پاسخ های متداول

  • سوال: آیا خط لوله ی HTTPو(HTTP pipelining) در حال حاضر مشکل تاخیر را حل می کند؟
  • جواب: خیر، هر چند به صورت pipeline می باشد و داده ها را به صورت موازی می فرستد ولی در نهایت بر روی یک جریان داده ها انتقال پیدا می کنند. بنابراین اگه یک جای جریان به مشکل بخورد باز هم تمام پردازش ها به تاخیر می افتند. و نکته دیگر اینکه راه اندازی pipeline کار دشواری است بنابراین به صورت پیش فرض بر روی مرورگرها غیر فعال است.
  • سوال: آیا SPDY جایگزینی برای HTTP است؟
  • جواب: خیر، SPDY بخش هایی از HTTP را عوض می کند، ولی در کل سعی در تقویت و تکمیل آن را دارد. در بالاترین سطح لایه ی Application پروتکل request و response بدون تغییر باقی می مانند. SPDY هنوز هم از متودها، سرآیندها و معانی دیگر HTTP استفاده می کند.اما بقیه ی قسمت ها را مانند: مدیریت connection و فرمت های انتقال داده را جایگزین می کند.