HTTP2
چکیده
اﻳﻦ ﻣﺴﺘﻨﺪ ﺑﻪ ﺷﺮحHTTP2از ﺳﻄﺢ ﻓﻨﻲ و ﭘﺮوﺗﻜﻞ ﻣﻲ ﭘﺮدازد. ﻣﻨﺸﺎ آن اراﺋﻪ اي ﺑﻮد ﻛﻪ در ﻣﺎه آورﻳﻞ ﺳﺎل 2014 دراﺳﺘﻜﻬﻠﻢ داﺷﺘﻢ ﻛﻪ ﺑﻌﺪ از آن ﺑﻪ ﻳﻚ ﻣﺴﺘﻨﺪ ﭘﺮ ﺑﺎر ﺑﺎ ﻫﻤﻪ ﺟﺰﺋﻴﺎت و ﺗﻮﺿﻴﺤﺎت ﻣﻨﺎﺳﺐ ﺑﺴﻂ ﭘﻴﺪا ﻛﺮده و ﺗﺒﺪﻳﻞ ﺷﺪ. در اﻳﻦ ﻟﺤﻈﻪ ﻛﻪ اﻳﻦ ﻣﺴﺘﻨﺪ ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ (15 ﻣﺎه ژاﻧﻮﻳﻪ ﺳﺎل 2015)، ﻣﺸﺨﺼﺎت ﻧﻬﺎﻳﻲHTTP2ﺗﺎﻛﻨﻮن ﻛﺎﻣﻞ و اراﺋﻪ ﻧﺸﺪه اﻧﺪ. ﻧﺴﺨﻪ ي ﻓﻌﻠﻲ ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲ- 116 ﻧﺎﻣﻴﺪه ﻣﻲ ﺷﻮد و ﺧﻮﺷﺒﺨﺘﺎﻧﻪ ﻓﺮﻣﺘﻲ اﺳﺖ ﻛﻪ ﺑﻪ RFCﺗﺒﺪﻳﻞ ﺧﻮاﻫﺪ ﺷﺪ. اﻳﻦ ﻣﺴﺘﻨﺪ ﺑﻪ ﺷﺮح ﻣﻮﻗﻌﻴﺖ ﻓﻌﻠﻲ ﻣﻲ ﭘﺮدازد ﻛﻪ ﻣﻤﻜﻦ اﺳﺖ در ﻣﺸﺨﺼﺎت ﻧﻬﺎﻳﻲ ﺗﻐﻴﻴﺮ ﻛﻨﺪ ﻳﺎ ﻧﻜﻨﺪ.
مجوز
اﻳﻦ ﻣﺴﺘﻨﺪ ﺗﺤﺖ ﻣﺠﻮز 0.4 Creative Commons Attribution اراﺋﻪ ﺷﺪه اﺳﺖ: http://creativecommons.org/licenses/by/0.4/
مقدمه
پروتکل (Hyper Text Transfer Protocol (HTTP (انتقال فوق متن) پروتکلی است که وظیفه انتقال (ارسال و دریافت) داده ها بین کلاینت و سرور را بر عهده دارد. منظور از کلاینت مرورگر وب و منظور از سرور یک وب سایت اینترنتی است. در واقع پروتکل انتقال ابر متن زبان مشترک بین سرویس دهندگان و سرویس گیرندگان وب است و شامل مجموعه ای از قوانین است که برای انتقال انواع فایل ها مثل صدا، متن، عکس و... برای انتقال در شبکه وب استفاده می شود.
در این مقاله به معرفی پروتکل HTTP2 پرداخته می شود و همچنین مزیتهایی که این نسخه جدید نسبت به نسخه های قبلی این پروتکل دارد و همچنین بهینه سازی هایی که در این نسخه انجام شده است پرداخته می شود
HTTP اﻣﺮوز
1.1 HTTP ﺑﻪ ﭘﺮوﺗﻜﻠﻲ ﺗﺒﺪﻳﻞ ﺷﺪه اﺳﺖ ﻛﻪ ﺑﺮاي ﻫﺮ ﭼﻴﺰي ﻛﻪ ﺑﻪ ﻃﻮر ﻣﺠﺎزي ﺑﺮ اﻳﻨﺘﺮﻧﺖ ﻗﺮار دارد، اﺳﺘﻔﺎده ﻣﻲ ﺷﻮد. ﺳﺮﻣﺎﻳﻪ ﮔﺬاري ﻫﺎي زﻳﺎد ﺑﺮ ﭘﺮوﺗﻜﻞ ﻫﺎ و زﻳﺮﺳﺎﺧﺖ ﻫﺎﻳﻲ اﻧﺠﺎم ﺷﺪه اﻧﺪ ﻛﻪ از اﻳﻦ ﻣﺰﻳﺖ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ ﺗﺎ اﻧﺪازه اي ﭘﻴﺸﺮﻓﺖ ﻛﺮده اﺳﺖ ﻛﻪ اﻏﻠﺐ آﺳﺎﻧﺘﺮ اﺳﺖ ﻛﻪ ﭼﻴﺰﻫﺎ را ﺑﺮ روي HTTPﺑﻪ اﺟﺮا در آورﻳﻢ ﺑﻪ ﺟﺎي اﻳﻦ ﻛﻪ ﭼﻴﺰي را ﺧﻮدﻣﺎن ﺟﺪﻳﺪ ﺑﺴﺎزﻳﻢ.
1.1 HTTP ﺑﺰرگ اﺳﺖ
زﻣﺎﻧﻲ ﻛﻪ HTTPاﻳﺠﺎد ﺷﺪ، اﺣﺘﻤﺎﻻ ﺑﻪ ﻋﻨﻮان ﻳﻚ ﭘﺮوﺗﻜﻞ ﺑﻪ ﻧﺴﺒﺖ ﺳﺎده و ﺳﺮراﺳﺖ در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﺪ اﻣﺎ ﮔﺬﺷﺖ زﻣﺎن ﻧﺎدرﺳﺘﻲ اﻳﻦ ﻣﺴﺎﻟﻪ را ﺛﺎﺑﺖ ﻛﺮد. 0.1 HTTPدر 1945 RFCﻳﻚ ﻣﺸﺨﺼﺎت 60 ﺻﻔﺤﻪ اي اﺳﺖ ﻛﻪ در ﺳﺎل 1996 ﻣﻨﺘﺸﺮ ﺷﺪ.2616 RFCﻛﻪ ﺑﻪ ﺷﺮح 1.1 HTTPﻣﻲ ﭘﺮدازد ﻛﻪ ﺳﻪ ﺳﺎل ﺑﻌﺪ در ﺳﺎل 1999 ﻣﻨﺘﺸﺮ ﺷﺪ و ﺑﻪ ﻃﻮر ﭼﺸﻤﮕﻴﺮي ﺗﺎ 176 ﺻﻔﺤﻪ اﻓﺰاﻳﺶ ﺣﺠﻢ داﺷﺖ. ﻫﻨﻮز زﻣﺎﻧﻲ ﻛﻪ در IETFﺑﺮ ﺑﺮوزرﺳﺎﻧﻲ آن ﻣﺸﺨﺼﺎت ﻛﺎر ﻣﻲ ﻛﻨﻴﻢ، آن را ﺗﻘﺴﻴﻢ ﻛﺮده و ﺑﻪ 6 ﻣﺴﺘﻨﺪ ﺑﺎ ﺗﻌﺪاد ﺻﻔﺤﻪ ﺑﻴﺸﺘﺮي ﺗﺒﺪﻳﻞ ﻣﻲ ﻛﻨﻴﻢ )ﻣﻨﺠﺮ ﺑﻪ 7230 RFCو ﺧﺎﻧﻮاده اش ﻣﻲ ﺷﻮد(. 1.1 HTTPﺑﺰرگ اﺳﺖ و ﺷﺎﻣﻞ ﺟﺰﺋﻴﺎت زﻳﺎد، ﻇﺮاﻓﺖ و ﻣﻴﺰان زﻳﺎدي ﺑﺨﺶ ﻫﺎي اﺧﺘﻴﺎري اﺳﺖ.
دﻧﻴﺎیی از اﻣﻜﺎﻧﺎت و ﮔﺰﻳﻨﻪ ﻫﺎ
ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﻳﻦ ﻛﻪ ﺗﻘﺮﻳﺒﺎ ﻫﻴﭻ ﭘﻴﺎده ﺳﺎزي ﻫﺮﮔﺰ ﻫﻤﻪ ﭼﻴﺰ را ﭘﻴﺎده ﺳﺎزي ﻧﻤﻲ ﻛﻨﺪ، ﻃﺒﻴﻌﺖ 1.1 HTTPﻣﻴﺰان زﻳﺎدي ﺟﺰﺋﻴﺎت رﻳﺰ و ﮔﺰﻳﻨﻪ ﻫﺎﻳﻲ دارد ﻛﻪ ﺑﺮاي ﺑﺴﻂ ﻫﺎي ﺑﻌﺪي در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪه اﻧﺪ-و ﺣﺘﻲ اﻣﻜﺎن ﮔﻔﺘﻦ اﻳﻦ ﻛﻪ دﻗﻴﻘﺎ "ﻫﺮ ﭼﻴﺰ" ﭼﻴﺴﺖ، اﻣﻜﺎن ﭘﺬﻳﺮ ﻧﻴﺴﺖ. اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻨﺠﺮ ﺑﻪ ﻣﻮﻗﻌﻴﺘﻲ ﺷﺪه اﺳﺖ ﻛﻪ وﻳﮋﮔﻲ ﻫﺎﻳﻲ ﻛﻪ در اﺑﺘﺪا اﺳﺘﻔﺎده ﻛﻤﻲ داﺷﺘﻪ اﻧﺪ، ﺷﺎﻫﺪ ﭘﻴﺎده ﺳﺎزي ﻫﺎي ﺧﻴﻠﻲ ﻛﻤﻲ ﺑﻮده اﻧﺪ و آﻧﻬﺎﻳﻲ ﻛﻪ وﻳﮋﮔﻲ ﻫﺎ را ﭘﻴﺎده ﺳﺎزي ﻛﺮده اﻧﺪ، اﺳﺘﻔﺎده ﻛﻤﻲ از آﻧﻬﺎ را ﻣﺸﺎﻫﺪه ﻛﺮده اﻧﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ در اداﻣﻪ، زﻣﺎﻧﻲ ﻛﻪ ﻣﺸﺘﺮﻳﺎن و ﺳﺮورﻫﺎ ﺷﺮوع ﺑﻪ اﻓﺰاﻳﺶ اﺳﺘﻔﺎده از ﭼﻨﻴﻦ وﻳﮋﮔﻲ ﻫﺎﻳﻲ ﻛﺮده اﻧﺪ، ﻣﻨﺠﺮ ﺑﻪ ﻣﺸﻜﻞ ﻗﺎﺑﻠﻴﺖ ﻫﻤﻜﺎري می ﺷﻮد. ﺧﻂ ﻟﻮﻟﻪ ی HTTP ﻳک ﻣﺜﺎل اوﻟﻴﻪ از ﭼﻨﻴﻦ وﻳﮋگی اﺳﺖ.
اﺳﺘﻔﺎده ﻧﺎﻛﺎﻓﻲ از TCP
1.1 HTTP در اﺳﺘﻔﺎده ﻛﺎﻣﻞ از ﻣﺰاﻳﺎي ﻫﻤﻪ ي ﺗﻮاﻧﻤﻨﺪي ﻫﺎ و ﻛﺎراﻳﻲ ﻛﻪ TCPاراﺋﻪ ﻣﻲ ﻛﻨﺪ، دﭼﺎر ﻣﺸﻜﻞ ﺷﺪه اﺳﺖ. ﻣﺸﺘﺮﻳﺎن HTTP و ﻣﺮورﮔﺮﻫﺎ ﺑﺎﻳﺪ ﺑﺮاي ﻳﺎﻓﺘﻦ راه ﺣﻞ ﻫﺎﻳﻲ ﻛﻪ زﻣﺎن ﺑﺎرﮔﺬاري ﺻﻔﺤﻪ را ﻛﺎﻫﺶ ﻣﻲ دﻫﻨﺪ، ﺧﻴﻠﻲ ﺧﻼﻗﺎﻧﻪ ﺑﺎﺷﻨﺪ. ﺳﺎﻳﺮ ﺗﻼش ﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﻃﻮر ﻣﻮازي در ﻃﻮل ﺳﺎﻟﻴﺎن ﻣﺘﻤﺎدي اﻧﺠﺎم ﺷﺪه اﻧﺪ ﻧﻴﺰ ﺗﺎﻳﻴﺪ ﻛﺮده اﻧﺪ ﻛﻪ ﺟﺎﻳﮕﺰﻳﻨﻲ TCP آﺳﺎن ﻧﻴﺴﺖ و ﺑﻨﺎﺑﺮاﻳﻦ ﺑﺮ ﺑﻬﺒﻮد TCP و ﭘﺮوﺗﻜﻞ ﻫﺎي ﻣﻮﺟﻮد ﺑﺮ روي آن ﻛﺎر ﻣﻲ ﻛﻨﻴﻢ. TCP را ﻣﻲ ﺗﻮان ﺑﻪ ﺳﺎدﮔﻲ ﺑﺮاي اﺟﺘﻨﺎب از ﻣﻜﺚ ﻫﺎ ﻳﺎ ﻟﺤﻈﺎﺗﻲ ﻛﻪ ﺑﺮاي ارﺳﺎل ﻳﺎ درﻳﺎﻓﺖ داده ي زﻳﺎد وﺟﻮد دارﻧﺪ، ﻣﻮرد ﺑﻬﺮه ﺑﺮداري ﻗﺮار داد. ﺑﺨﺶ ﻫﺎي ﺑﻌﺪي ﺑﺮﺧﻲ از اﻳﻦ ﻣﻌﺎﻳﺐ را ﺑﺮﺟﺴﺘﻪ ﺧﻮاﻫﻨﺪ ﺳﺎﺧﺖ.
اﻧﺪازه ﻫﺎی اﻧﺘﻘﺎل و ﺗﻌﺪاد اﺷﻴﺎ
زﻣﺎﻧﻲ ﻛﻪ ﺑﻪ روﻧﺪ ﺑﺮﺧﻲ از ﻣﻌﺮوف ﺗﺮﻳﻦ ﺳﺎﻳﺖ ﻫﺎ ﺑﺮ وب ﻧﮕﺎه ﻣﻲ ﻛﻨﻴﻢ و داﻧﻠﻮد ﺻﻔﺤﺎت آﻧﻬﺎ ﭼﻘﺪر ﻃﻮل ﻣﻲ ﻛﺸﺪ، ﺷﻜﻲ در ﻣﻮرد روﻧﺪﻫﺎ وﺟﻮد ﻧﺪارد. در ﭼﻨﺪ ﺳﺎل ﮔﺬﺷﺘﻪ، ﻣﻴﺰان داده اي ﻛﻪ ﺑﺎﻳﺪ ﺑﺎزﻳﺎﺑﻲ ﺷﻮد، ﺑﻪ ﺗﺪرﻳﺞ ﺗﺎ ﺑﺎﻻي MB 1.9 اﻓﺰاﻳﺶ ﻳﺎﻓﺘﻪ اﺳﺖ، اﻣﺎ ﭼﻴﺰي ﻛﻪ ﺑﺮاي ﻣﺎ در اﻳﻦ زﻣﻴﻨﻪ ﻣﻬﻢ اﺳﺖ، اﻳﻦ اﺳﺖ. ﻛﻪ ﺗﻌﺪاد اﺷﻴﺎ ﺑﻪ ﻃﻮر ﻣﻴﺎﻧﮕﻴﻦ ﺻﺪ ﺷﻲ اﺳﺖ، ﺻﺪ ﺷﻲ ﺑﺎﻳﺪ ﺑﺮاي ﻧﻤﺎﻳﺶ ﺻﻔﺤﻪ ﻛﺎﻣﻞ ﺑﺎزﻳﺎﺑﻲ ﺷﻮﻧﺪ. ﻫﻤﺎﻧﻄﻮر ﻛﻪ ﻧﻤﻮدار زﻳﺮ ﻧﺸﺎن ﻣﻲ دﻫﺪ، روﻧﺪ ﺑﺮاي ﻣﺪﺗﻲ اداﻣﻪ ﻳﺎﻓﺘﻪ اﺳﺖ و ﻫﻴﭻ ﻧﺸﺎﻧﻪ اي وﺟﻮد ﻧﺪارد ﻛﻪ ﺑﻪ زودي ﺗﻐﻴﻴﺮ ﻛﻨﺪ. ﻧﻤﻮدار رﺷﺪ اﻧﺪازه ي اﻧﺘﻘﺎل ﻛﻞ (ﺑﻪ رﻧﮓ ﺳﺒﺰ) و ﺗﻌﺪاد ﻛﻠﻲ درﺧﻮاﺳﺖ ﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﻃﻮر ﻣﻴﺎﻧﮕﻴﻦ اﺳﺘﻔﺎده ﺷﺪه اﻧﺪ (ﺑﻪ رﻧﮓ ﻗﺮﻣﺰ) ﺑﺮاي ﻣﻌﺮوف ﺗﺮﻳﻦ وﺑﺴﺎﻳﺖ ﻫﺎ در دﻧﻴﺎ و ﭼﮕﻮﻧﮕﻲ ﺗﻐﻴﻴﺮ آﻧﻬﺎ در ﻃﻲ 4 ﺳﺎل ﮔﺬﺷﺘﻪ را ﻧﺸﺎن ﻣﻲ دﻫﺪ.
ﺗﺎﺧﻴﺮ ﻛﺸﻨﺪه اﺳﺖ
1.1 HTTP ﻧﺴﺒﺖ ﺑﻪ ﺗﺎﺧﻴﺮ ﺧﻴﻠﻲ ﺣﺴﺎس اﺳﺖ ﻛﻪ ﺑﺨﺸﻲ از اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﻪ اﻳﻦ دﻟﻴﻞ اﺳﺖ ﻛﻪ ﺧﻂ ﻟﻮﻟﻪ ی HTTP ﻣﺸﻜﻼت زﻳﺎدي دارد ﻛﻪ ﻣﻨﺠﺮ ﻣﻲ ﺷﻮد ﻛﻪ ﺑﺮاي درﺻﺪ ﺑﺰرﮔﻲ از ﻛﺎرﺑﺮان ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻧﮕﻴﺮد. در ﺣﺎﻟﻲ ﻛﻪ اﻓﺰاﻳﺶ زﻳﺎدي را در ﭘﻬﻨﺎي ﺑﺎﻧﺪ ﻓﺮاﻫﻢ ﺷﺪه ﺑﺮاي اﻓﺮاد در ﻃﻲ ﭼﻨﺪ ﺳﺎل اﺧﻴﺮ ﻣﺸﺎﻫﺪه ﻛﺮده اﻳﻢ، ﺳﻄﺢ ﻳﻜﺴﺎﻧﻲ از ﺑﻬﺒﻮد را در ﻛﺎﻫﺶ ﺗﺎﺧﻴﺮ ﻣﺸﺎﻫﺪه ﻧﻜﺮده اﻳﻢ. ﻟﻴﻨﻚ ﻫﺎي ﺑﺎ ﺗﺎﺧﻴﺮ ﺑﺎﻻ ﻧﻈﻴﺮ ﺑﺴﻴﺎري از ﺗﻜﻨﻮﻟﻮژي ﻫﺎي ﺳﻴﺎر ﻓﻌﻠﻲ، داﺷﺘﻦ ﺗﺠﺮﺑﻪ ي وب ﺧﻮب و ﺳﺮﻳﻊ را ﺣﺘﻲ در ﺻﻮرﺗﻲ ﻛﻪ اﺗﺼﺎل اﻳﻨﺘﺮﻧﺖ ﺑﺎ ﺳﺮﻋﺖ واﻗﻌﺎ ﺑﺎﻻﻳﻲ داﺷﺘﻪ ﺑﺎﺷﻴﺪ، دﺷﻮار ﻣﻲ ﺳﺎزد. ﻣﻄﺎﻟﻌﻪ ﻣﻮردي دﻳﮕﺮي ﻛﻪ واﻗﻌﺎ ﻧﻴﺎز ﺑﻪ ﺗﺎﺧﻴﺮ ﭘﺎﻳﻴﻦ دارد، اﻧﻮاع ﺧﺎﺻﻲ از وﻳﺪﺋﻮ، ﻧﻈﻴﺮ وﻳﺪﺋﻮ ﻛﻨﻔﺮاﻧﺲ، ﺑﺎزي ﻳﺎ ﻣﺸﺎﺑﻪ آن اﺳﺖ ﻛﻪ ﻓﻘﻂ ﻳﻚ ﺟﻮﻳﺒﺎي از ﻗﺒﻞ ﺗﻮﻟﻴﺪ ﺷﺪه ﺑﺮاي ارﺳﺎل وﺟﻮد ﻧﺪارد.
زﻣﺎن ﺑﺎرﮔﺬاري ﺻﻔﺤﻪ ﺑﺎ ﻛﺎﻫﺶ RTT
ﻧﻤﻮدار1:RTT زﻣﺎن ﺳﻔﺮ دوﺳﺮه ﺑﺮ زﻣﺎن ﺑﺎرﮔﺬاري ﺻﻔﺤﻪ ﺗﺎﺛﻴﺮ ﻣﻲ ﮔﺬارد
ﺑﺴﺘﻪ ﺷﺪن اول ﺧﻂ
ﺧﻂ ﻟﻮﻟﻪ ي HTTP روﺷﻲ ﺑﺮاي ارﺳﺎل درﺧﻮاﺳﺖ دﻳﮕﺮ، در ﺣﺎﻟﻲ ﻛﻪ ﻣﻨﺘﻈﺮ ﭘﺎﺳﺦ از درﺧﻮاﺳﺖ ﻗﺒﻠﻲ ﻣﻲ ﺑﺎﺷﻴﻢ، اﺳﺖ. اﻳﻦ ﻣﺴﺎﻟﻪ ﺧﻴﻠﻲ ﻣﺸﺎﺑﻪ ﺑﺎ وارد ﺷﺪن ﺑﻪ ﺻﻒ ﻳﻚ ﭘﻴﺸﺨﻮان در ﻳﻚ ﺳﻮﭘﺮﻣﺎرﻛﺖ ﻳﺎ در ﻳﻚ ﺑﺎﻧﻚ اﺳﺖ. ﺷﻤﺎ ﻧﻤﻲ داﻧﻴﺪ ﻛﻪ آﻳﺎ ﻣﺸﺘﺮي ﻛﻪ ﺟﻠﻮ ﺷﻤﺎ اﺳﺖ، ﻛﺎرش ﺳﺮﻳﻊ راه ﻣﻲ اﻓﺘﺪ ﻳﺎ ﺷﻤﺎ را ﻣﺪت زﻳﺎدي ﻣﻌﻄﻞ ﻣﻲ ﻛﻨﺪ: ﺑﻼك ﻛﺮدن ﺳﺮ ﺻﻒ.
اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ ﻛﻪ در ﻣﻮرد اﻧﺘﺨﺎب ﻋﻨﺼﺮ در ﺻﻒ دﻗﺖ دارﻳﺪ، ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﻣﻮردي را اﻧﺘﺨﺎب ﻛﻨﻴﺪ ﻛﻪ واﻗﻌﺎ ﻋﻘﻴﺪه دارﻳﺪ ﻛﻪ ﻋﻨﺼﺮ درﺳﺘﻲ اﺳﺖ و ﺣﺘﻲ ﮔﺎﻫﻲ اوﻗﺎت ﺧﻂ ﺟﺪﻳﺪ ﺧﻮد را اﻳﺠﺎد ﻛﻨﻴﺪ اﻣﺎ در اﻧﺘﻬﺎ ﻧﻤﻲ ﺗﻮاﻧﻴﺪ از ﻳﻚ ﺗﺼﻤﻴﻢ ﮔﻴﺮي اﺟﺘﻨﺎب ﻛﻨﻴﺪ و وﻗﺘﻲ ﻛﻪ ﺗﺼﻤﻴﻢ ﮔﻴﺮي اﻧﺠﺎم ﺷﺪ، ﻧﻤﻲ ﺗﻮاﻧﻴﺪ ﺧﻂ ﺧﻮد را ﻋﻮض ﻛﻨﻴﺪ. اﻳﺠﺎد ﻳﻚ ﺧﻂ ﺟﺪﻳﺪ ﻣﺮﺗﺒﻂ ﺑﺎ ﻳﻚ ﺟﺮﻳﻤﻪ ي ﻛﺎراﻳﻲ و ﻣﻨﺒﻊ اﺳﺖ ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ از ﺗﻌﺪاد ﻛﻤﻲ ﺧﻂ ﺑﻴﺸﺘﺮ ﻣﻘﻴﺎس ﭘﺬﻳﺮ ﻧﻴﺴﺖ. ﻫﻴﭻ راه ﺣﻞ ﻛﺎﻣﻠﻲ ﺑﺮاي اﻳﻦ ﻣﺴﺎﻟﻪ وﺟﻮد ﻧﺪارد. ﺣﺘﻲ اﻣﺮوز، ﺳﺎل 2015، ﺑﻴﺸﺘﺮ ﻣﺮورﮔﺮﻫﺎي وب روﻣﻴﺰي، ﺑﻪ ﻃﻮر ﭘﻴﺸﻔﺮض ﺑﺪون ﻓﻌﺎل ﺑﻮدن ﺧﻂ ﻟﻮﻟﻪ ي HTTP اراﺋﻪ ﻣﻲ ﺷﻮﻧﺪ. ﻣﻄﺎﻟﻌﺎت ﺑﻴﺸﺘﺮ در ارﺗﺒﺎط ﺑﺎ اﻳﻦ ﻣﻮﺿﻮع را ﻣﻲ ﺗﻮان ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل در ورودي ﺑﺎ موزﻳﻼ ﻓﺎﻳﺮﻓﺎﻛﺲ 26.4 ﻳﺎﻓﺖ.
اﻗﺪاﻣﺎﺗﻲ ﻛﻪ ﻣﻲ ﺗﻮان ﺑﺮاي ﻏﻠﺒﻪ ﺑﺮ ﻣﺸﻜﻞ ﺗﺎﺧﻴﺮ اﻧﺠﺎم داد
Spriting
Spriting ﻋﺒﺎرﺗﻲ اﺳﺖ ﻛﻪ اﻏﻠﺐ ﺑﺮاي ﺷﺮح زﻣﺎﻧﻲ ﻛﻪ ﺗﺼﺎوﻳﺮ ﻛﻮﭼﻚ زﻳﺎدي را ﺑﺎ ﻫﻢ در ﻳﻚ ﺗﺼﻮﻳﺮ ﺑﺰرگ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻗﺮار ﻣﻲ دﻫﻴﺪ، اﺳﺘﻔﺎده ﻣﻲ ﺷﻮد. ﺳﭙﺲ از ﺟﺎوااﺳﻜﺮﻳﭙﺖ ﻳﺎ CSS ﺑﺮاي ﺑﺮش ﻗﻄﻌﺎت ﺗﺼﻮﻳﺮ ﺑﺰرگ ﺑﺮاي ﻧﻤﺎﻳﺶ ﺗﺼﺎوﻳﺮ ﻛﻮﭼﻜﺘﺮ ﻣﺠﺰا اﺳﺘﻔﺎده ﻣﻲ ﺷﻮد. ﺳﺎﻳﺖ ﻫﺎ ﻣﻲ ﺗﻮاﻧﻨﺪ از اﻳﻦ روش ﺑﺮاي اﻓﺰاﻳﺶ ﺳﺮﻋﺖ اﺳﺘﻔﺎده ﻛﻨﻨﺪ. ﺑﺪﺳﺖ آوردن ﻳﻚ ﺗﺼﻮﻳﺮ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﺑﺰرگ در 1.1 HTTP ﺧﻴﻠﻲ ﺳﺮﻳﻌﺘﺮ از ﺑﺪﺳﺖ آوردن ﺻﺪ ﺗﺼﻮﻳﺮ ﻣﺠﺰاي ﻛﻮﭼﻜﺘﺮ اﺳﺖ. اﻟﺒﺘﻪ اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻌﺎﻳﺒﻲ ﺑﺮاي ﺗﺼﺎوﻳﺮ ﺳﺎﻳﺖ ﻛﻪ ﻓﻘﻂ ﻣﻲ ﺧﻮاﻫﻨﺪ از ﻳﻚ ﻳﺎ دو ﺗﺼﻮﻳﺮ ﻛﻮﭼﻚ و ﻣﺸﺎﺑﻪ اﺳﺘﻔﺎده ﻛﻨﻨﺪ، ﻣﻌﺎﻳﺒﻲ دارد و ﺑﺎﻋﺚ ﻣﻲ ﺷﻮد ﻛﻪ ﻫﻤﻪ ي ﺗﺼﺎوﻳﺮ ﻫﻤﺰﻣﺎن از ﻛﺶ ﺧﺎرج ﺷﻮﻧﺪ، ﺑﻪ ﺟﺎي اﻳﻦ ﻛﻪ ﺗﺼﺎوﻳﺮي ﻛﻪ ﺑﻪ ﻃﻮر ﻣﻌﻤﻮل اﺳﺘﻔﺎده ﻣﻲ ﺷﻮﻧﺪ را در ﻛﺶ ﺑﺎﻗﻲ ﺑﮕﺬارد.
inlining
Inlining روش دﻳﮕﺮي اﺳﺖ ﻛﻪ از ارﺳﺎل ﺗﺼﺎوﻳﺮ ﻣﺠﺰا اﺟﺘﻨﺎب ﻣﻲ ﻛﻨﺪ و اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﻪ ﺟﺎي اﺳﺘﻔﺎده از داده اﻧﺠﺎم ﻣﻲ ﺷﻮد: URLﻫﺎي ﻣﻮﺟﻮد در ﻓﺎﻳﻞ .CSS اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﺰاﻳﺎ و ﻣﻌﺎﻳﺐ ﻣﺸﺎﺑﻬﻲ ﻧﻈﻴﺮ ﻣﻮرد spriting دارد.
concatingation
ﻣﺸﺎﺑﻪ ﺑﺎ دو روش ﻗﺒﻠﻲ، اﻣﺮوزه ﻳﻚ ﺳﺎﻳﺖ ﺑﺰرگ ﻣﻲ ﺗﻮاﻧﺪ ﻓﺎﻳﻞ ﻫﺎي ﺟﺎوااﺳﻜﺮﻳﭙﺖ ﻣﺘﻔﺎوﺗﻲ داﺷﺘﻪ ﺑﺎﺷﺪ. اﺑﺰارﻫﺎي ﻗﺴﻤﺖ- ﺟﻠﻮﻳﻲ ﺑﻪ ﺗﻮﺳﻌﻪ دﻫﻨﺪﮔﺎن اﻣﻜﺎن ﻳﻜﭙﺎرﭼﻪ ﺳﺎزي آﻧﻬﺎ را در ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺑﺰرگ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻣﻲ دﻫﻨﺪ ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﻣﺮورﮔﺮ ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺑﺰرگ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﺑﻪ ﺟﺎي ده ﻫﺎ ﻓﺎﻳﻞ ﻛﻮﭼﻜﺘﺮ ﻣﻲ ﮔﻴﺮد. ﻣﻴﺰان داده ي زﻳﺎدي زﻣﺎﻧﻲ ﻛﻪ ﻓﻘﻂ اﻃﻼﻋﺎت ﻛﻤﻲ ﻣﻮرد ﻧﻴﺎز اﺳﺖ، ارﺳﺎل ﻣﻲ ﺷﻮد. داده ي زﻳﺎد زﻣﺎﻧﻲ ﻛﻪ ﻳﻚ ﺗﻐﻴﻴﺮ ﻣﻮرد ﻧﻴﺎز اﺳﺖ، ﻣﺠﺪدا ﺑﺎرﮔﺬاري ﻣﻲ ﺷﻮد.
sharding
روش ﻧﻬﺎﻳﻲ ﻛﻪ ذﻛﺮ ﻣﻲ ﻛﻨﻢ اﻳﻦ اﺳﺖ ﻛﻪ ﻋﻤﻠﻜﺮد ﺑﻬﺘﺮ ﻣﺎﻟﻜﺎن ﺳﺎﻳﺖ در ﻣﺮورﮔﺮﻫﺎ اﻏﻠﺐ ﺗﺤﺖ ﻋﻨﻮان "sharding" در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﻮد ﻛﻪ اﺳﺎﺳﺎ ﺑﻪ ﻣﻌﻨﻲ ﮔﺴﺘﺮش ﺳﺮوﻳﺲ ﻫﺎي ﺧﻮد ﺑﺮ ﺣﺪاﻛﺜﺮ ﻣﻴﺰﺑﺎن ﻫﺎي ﻣﻤﻜﻦ اﺳﺖ. ﮔﺮﭼﻪ در اﺑﺘﺪا اﺣﻤﻘﺎﻧﻪ ﺑﻨﻈﺮ ﻣﻲ رﺳﺪ، اﻣﺎ ﻳﻚ دﻟﻴﻞ ﺳﺎده وﺟﻮد دارد! ﻣﺸﺨﺼﺎت 1.1 HTTP در اﺑﺘﺪا ﺑﻴﺎن ﻣﻲ ﻛﺮد ﻛﻪ ﻳﻚ ﻣﺸﺘﺮي ﻣﺠﺎز ﺑﻪ اﺳﺘﻔﺎده از ﺣﺪاﻛﺜﺮ دو اﺗﺼﺎل TCP ﺑﺮاي ﻫﺮ ﻣﻴﺰﺑﺎن اﺳﺖ. ﺑﻨﺎﺑﺮاﻳﻦ ﺑﺮاي ﻋﺪم ﻧﻘﺾ ﻣﺸﺨﺼﺎت، ﺳﺎﻳﺖ ﻫﺎ ﺑﺎﻳﺪ ﺑﻪ ﺳﺎدﮔﻲ ﻧﺎم ﻫﺎي ﻣﻴﺰﺑﺎن ﺟﺪﻳﺪ را اﻳﺠﺎد ﻛﻨﻨﺪ و ﺑﺪﻳﻦ ﺷﻜﻞ اﺗﺼﺎﻻت ﺑﻴﺸﺘﺮي ﺑﻪ ﺳﺎﻳﺖ ﺧﻮد ﺑﺪﺳﺖ ﻣﻲ آورﻳﺪ و زﻣﺎن ﻫﺎي ﺑﺎرﮔﺬاري ﺻﻔﺤﻪ ﻛﺎﻫﺶ ﻣﻲ ﻳﺎﺑﻨﺪ. در ﻃﻮل زﻣﺎن، اﻳﻦ ﻣﺤﺪودﻳﺖ از ﻣﺸﺨﺼﺎت ﺣﺬف ﺷﺪ و اﻣﺮوزه ﻣﺸﺘﺮﻳﺎن ﺑﻪ آﺳﺎﻧﻲ از 6-8 اﺗﺼﺎل ﺑﻪ ازاي ﻫﺮ ﻧﺎم ﻣﻴﺰﺑﺎن اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ اﻣﺎ ﻫﻨﻮز ﻳﻚ ﻣﺤﺪودﻳﺖ وﺟﻮد دارد ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﺳﺎﻳﺖ ﺑﻪ اﺳﺘﻔﺎده از اﻳﻦ ﺗﻜﻨﻴﻚ ﺑﺮاي اﻓﺰاﻳﺶ ﺗﻌﺪاد اﺗﺼﺎﻻت اداﻣﻪ دادﻧﺪ. ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﻳﻦ ﻛﻪ ﺗﻌﺪاد اﺷﻴﺎ در ﺣﺎل رﺷﺪ داﺋﻤﻲ اﺳﺖ-ﻫﻤﺎﻧﻄﻮر ﻛﻪ ﻗﺒﻼ ﻧﺸﺎن دادم-ﺗﻌﺪاد زﻳﺎدي از اﺗﺼﺎﻻت ﻧﻴﺰ ﺑﺮاي ﺣﺼﻮل اﻃﻤﻴﻨﺎن از اﻳﻦ ﻛﻪ HTTP ﺑﻪ ﺧﻮﺑﻲ اﺟﺮا ﻣﻲ ﺷﻮد، اﺳﺘﻔﺎده ﻣﻲ ﺷﻮﻧﺪ و ﺳﺎﻳﺖ ﺷﻤﺎ را ﺳﺮﻳﻊ ﻣﻲ ﺳﺎزﻧﺪ. ﺑﺮاي ﺳﺎﻳﺖ ﻫﺎ اﺳﺘﻔﺎده از ﺑﻴﺶ از 50 ﻳﺎ ﺣﺘﻲ ﺑﻴﺸﺘﺮ از آن و ﻓﺮاﺗﺮ از 100 اﺗﺼﺎل، ﺑﺎ اﺳﺘﻔﺎده از اﻳﻦ ﺗﻜﻨﻴﻚ اﻣﻜﺎن ﭘﺬﻳﺮ ﺷﺪه اﺳﺖ. آﻣﺎر ﻓﻌﻠﻲ httparchive.org ﻧﺸﺎن دادﻧﺪ ﻛﻪ 300kurl ﺑﺮﺗﺮ در دﻧﻴﺎ ﻧﻴﺎز ﺑﻪ ﻣﻴﺎﻧﮕﻴﻦ (!)38 اﺗﺼﺎل TCP ﺑﺮاي ﻧﻤﺎﻳﺶ ﺳﺎﻳﺖ دارﻧﺪ و روﻧﺪﻫﺎ ﻧﺸﺎن ﻣﻲ دﻫﻨﺪ ﻛﻪ در ﻃﻮل زﻣﺎن ﺑﻪ ﻛﻨﺪي اﻓﺰاﻳﺶ ﻣﻲ ﻳﺎﺑﺪ. دﻟﻴﻞ دﻳﮕﺮ ﻗﺮار دادن ﺗﺼﺎوﻳﺮ ﻳﺎ ﻣﻨﺎﺑﻊ ﻣﺸﺎﺑﻪ ﺑﺮ ﻳﻚ ﻧﺎم ﻣﻴﺰﺑﺎن ﻣﺠﺰا ﻛﻪ از ﻫﻴﭻ ﻛﻮﻛﻲ اﺳﺘﻔﺎده ﻧﻤﻲ ﻛﻨﺪ، ﻣﻲ ﺑﺎﺷﺪ. ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﻳﻦ ﻛﻪ اﻣﺮوزه اﻧﺪازه ﻛﻮﻛﻲ ﻫﺎ ﻣﻲ ﺗﻮاﻧﺪ ﻛﺎﻣﻼ ﭼﺸﻤﮕﻴﺮ ﺑﺎﺷﺪ. ﺑﺎ اﺳﺘﻔﺎده از ﻣﻴﺰﺑﺎن ﻫﺎي ﺗﺼﻮﻳﺮ ﺑﺪون-ﻛﻮﻛﻲ، ﺑﺮﺧﻲ اوﻗﺎت ﻣﻲ ﺗﻮاﻧﻴﺪ ﻛﺎراﻳﻲ را ﺑﺎ اﺟﺎزه دادن درﺧﻮاﺳﺖ ﻫﺎي HTTP ﺧﻴﻠﻲ ﻛﻮﭼﻜﺘﺮ، اﻓﺰاﻳﺶ دﻫﻴﺪ. ﺗﺼﻮﻳﺮ زﻳﺮ ﺑﻪ ﻧﻤﺎﻳﺶ اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻲ ﭘﺮدازد ﻛﻪ زﻣﺎﻧﻲ ﻛﻪ ﻳﻜﻲ از وﺑﺴﺎﻳﺖ ﻫﺎي ﺑﺮﺗﺮ Sweden را ﻣﺮور ﻣﻲ ﻛﻨﻴﺪ، ﻋﻤﻠﻴﺎت ﺑﻪ ﭼﻪ ﺷﻜﻞ اﺳﺖ و درﺧﻮاﺳﺖ ﻫﺎ ﭼﮕﻮﻧﻪ ﺑﺮ ﭼﻨﺪﻳﻦ ﻧﺎم ﻣﻴﺰﺑﺎن ﺗﻮزﻳﻊ ﻣﻲ ﺷﻮﻧﺪ.
ﺑﺮوزرﺳﺎﻧﻲ HTTP
آﻳﺎ اﻳﺠﺎد ﻳﻚ ﭘﺮوﺗﻜﻞ ﺑﻬﺒﻮد ﻳﺎﻓﺘﻪ ﺧﻮب ﻧﻴﺴﺖ؟ ﭘﺮوﺗﻜﻞ ﺑﺎﻳﺪ ﺷﺎﻣﻞ ﻣﻮارد زﻳﺮ ﺑﺎﺷﺪ... 1) ﭘﺮوﺗﻜﻠﻲ اﻳﺠﺎد ﻛﻨﻴﺪ ﻛﻪ ﻛﻤﺘﺮ ﺑﻪ RTT ﺣﺴﺎس ﺑﺎﺷﺪ. 2) ﻣﺴﺎﻟﻪ ي ﺧﻂ ﻟﻮﻟﻪ و ﺑﻠﻮﻛﻪ ﺷﺪن ﺳﺮ ﺧﻂ را ﺑﺮﻃﺮف ﻛﻨﻴﺪ. 3) ﻧﻴﺎز ﺑﻪ اﻓﺰاﻳﺶ ﺗﻌﺪاد اﺗﺼﺎﻻت ﺑﻪ ﻫﺮ ﻣﻴﺰﺑﺎن را ﻣﺘﻮﻗﻒ ﻛﻨﻴﺪ. 4) ﻫﻤﻪ ي راﺑﻂ ﻫﺎي ﻛﺎرﺑﺮي ﻣﻮﺟﻮد، ﻫﻤﻪ ﻣﺤﺘﻮاﻫﺎ، ﻓﺮﻣﺖ URI و ﻃﺮح ﻫﺎ را ﻣﺘﻮﻗﻒ ﻛﻨﻴﺪ. 5) اﻳﻦ ﻣﺴﺎﻟﻪ در ﮔﺮوه ﻛﺎري IETF HTTPbis اﻧﺠﺎم ﺷﺪه اﺳﺖ.
ﮔﺮوه ﻛﺎري IETFو HTTPbis
ﻧﻴﺮوي ﻛﺎري ﻣﻬﻨﺪﺳﻲ اﻳﻨﺘﺮﻧﺖ ()IETF ﺳﺎزﻣﺎﻧﻲ اﺳﺖ ﻛﻪ ﺑﻪ ﺗﻮﺳﻌﻪ و ارﺗﻘﺎي اﺳﺘﺎﻧﺪاردﻫﺎي اﻳﻨﺘﺮﻧﺘﻲ ﺑﻴﺸﺘﺮ در ﺳﻄﺢ ﭘﺮوﺗﻜﻞ ﻣﻲ ﭘﺮدازد. آﻧﻬﺎ ﺑﻪ ﻃﻮر ﮔﺴﺘﺮده ﺑﺮاي ﺳﺮي RFC از ﻣﺴﺘﻨﺪاﺗﻲ ﻛﻪ ﻫﺮ ﭼﻴﺰي را از FTP ،DNS ،TCP ﺗﺎ ﺑﻬﺘﺮﻳﻦ ﻓﻌﺎﻟﻴﺖ ﻫﺎ، HTTP و ﮔﻮﻧﻪ ﻫﺎي ﭘﺮوﺗﻜﻞ زﻳﺎدي ﻛﻪ ﻫﺮﮔﺰ ﺟﺎﻳﻲ اراﺋﻪ ﻧﺸﺪه اﻧﺪ، ﺷﻨﺎﺧﺘﻪ ﺷﺪه اﻧﺪ. ﮔﺮوه ﻛﺎري اﺧﺘﺼﺎﺻﻲ درون IETFدر ﻳﻚ ﺣﻮزه ي ﻣﺤﺪود ﺑﺮاي رﺳﻴﺪن ﺑﻪ ﻳﻚ ﻫﺪف ﺷﻜﻞ ﮔﺮﻓﺘﻪ اﻧﺪ. آﻧﻬﺎ ﻳﻚ ﻣﻨﺸﻮر را ﺑﺎ ﺑﺮﺧﻲ راﻫﻨﻤﺎﻳﻲ ﻫﺎ و ﻣﺤﺪودﻳﺖ ﻫﺎ ﺑﺮاي ﭼﻴﺰي ﻛﻪ ﺑﺎﻳﺪ ﺗﻮﻟﻴﺪ ﻛﻨﻨﺪ، اﻳﺠﺎد ﻣﻲ ﻛﻨﻨﺪ. ﻫﺮ ﻛﺴﻲ ﻣﺠﺎز ﺑﻪ ﺷﺮﻛﺖ در ﺑﺤﺚ ﻫﺎ و ﺗﻮﺳﻌﻪ اﺳﺖ. ﻫﺮ ﻛﺴﻲ ﻛﻪ ﺷﺮﻛﺖ ﻣﻲ ﻛﻨﺪ و ﭼﻴﺰي ﻣﻲ ﮔﻮﻳﺪ، وزن و ﺷﺎﻧﺲ ﺑﺮاﺑﺮي ﺑﺮاي ﺗﺎﺛﻴﺮ ﺑﺮ ﺧﺮوﺟﻲ دارد و ﺗﻮﺟﻪ ﻛﻤﻲ ﺑﻪ اﻳﻦ ﻣﻲ ﺷﻮد ﻛﻪ ﻫﺮ ﻓﺮد ﺑﺮاي ﭼﻪ ﺷﺮﻛﺘﻲ و ﻛﺠﺎ ﻛﺎر ﻣﻲ ﻛﻨﺪ. ﮔﺮوه ﻛﺎري HTTPbis در ﻃﻮل ﺗﺎﺑﺴﺘﺎن ﺳﺎل 2007 ﺷﻜﻞ ﮔﺮﻓﺘﻪ ﺷﺪ و ﺑﺮوزرﺳﺎﻧﻲ ﻣﺸﺨﺼﺎت 1.1 HTTP ﺑﻪ آن اﺧﺘﺼﺎص داده ﺷﺪ-ﺑﻨﺎﺑﺮاﻳﻦ ﺑﺨﺶ bis ﻣﻮﺟﻮد در ﻧﺎم را ﺷﻜﻞ داد. در اﻳﻦ ﮔﺮوه، ﺑﺤﺚ و ﺑﺮرﺳﻲ درﻣﻮرد ﻧﺴﺨﻪ ﺑﻌﺪي HTTPواﻗﻌﺎ در اواﺧﺮ ﺳﺎل 2012 اﻳﺠﺎد ﺷﺪ. ﻛﺎر ﺑﺮوزرﺳﺎﻧﻲ 1.1 HTTP در اواﺋﻞ ﺳﺎل 2014 ﺑﻪ اﺗﻤﺎم رﺳﻴﺪ و ﻣﻨﺠﺮ ﺑﻪ ﺳﺮي 7320 RFCﺷﺪ. ﻣﻼﻗﺎت ﻧﻬﺎﻳﻲ ﺑﺮاي HTTPbis WG در ﺷﻬﺮ ﻧﻴﻮﻳﻮرك در اواﺋﻞ ﻣﺎه ﺟﻮﺋﻦ ﺳﺎل 2014 اﻧﺠﺎم ﮔﺮﻓﺖ. روﻳﻪ ﻫﺎي IETF ﺑﺮاي ﺑﺪﺳﺖ آوردن ﻳﻚ RFC رﺳﻤﻲ ﻣﻤﻜﻦ اﺳﺖ ﺑﻪ ﺧﻮﺑﻲ ﺑﻘﻴﻪ ﺳﺎل ﻳﺎ ﺑﻴﺸﺘﺮ ﺑﻪ ﻃﻮر ﺑﻴﺎﻧﺠﺎﻣﺪ. ﺑﺮﺧﻲ از ﺑﺎزﻳﻜﻨﺎن ﺑﺰرﮔﺘﺮ در زﻣﻴﻨﻪ ي HTTP از ﺑﺤﺚ ﻫﺎي ﮔﺮوه ﻛﺎري و ﺟﻠﺴﺎت آن ﺣﺬف ﺷﺪﻧﺪ. ﻣﻦ در اﻳﻨﺠﺎ ﻧﻤﻲ ﺧﻮاﻫﻢ ﻧﺎم ﻫﻴﭻ ﺷﺮﻛﺖ ﻳﺎ ﻣﺤﺼﻮل ﺧﺎﺻﻲ را ﺑﻴﺎن ﻛﻨﻢ اﻣﺎ ﺑﻪ وﺿﻮح ﺑﺮﺧﻲ از ﻋﺎﻣﻞ ﻫﺎ ﺑﺮ اﻳﻨﺘﺮﻧﺖ ﺑﻪ ﻧﻈﺮ ﻣﻲ رﺳﺪ ﻛﻪ ﻣﻄﻤﺌﻦ ﻫﺴﺘﻨﺪ ﻛﻪ IETF ﺑﺪون وﺟﻮد اﻳﻦ ﺷﺮﻛﺖ ﻫﺎ ﻧﻴﺰ ﺑﻪ ﺧﻮﺑﻲ ﻋﻤﻞ ﺧﻮاﻫﺪ ﻛﺮد... ﺑﺨﺶ bisﻣﻮﺟﻮد در ﻧﺎم: ﻧﺎم ﮔﺮوه HTTPbis اﺳﺖ ﻛﻪ ﺑﺨﺶ bisاز ﻗﻴﺪ ﻻﺗﻴﻦ ﺑﻪ ﻣﻌﻨﻲ "دو" ﮔﺮﻓﺘﻪ ﺷﺪه اﺳﺖ. bis ﺑﻪ ﻃﻮر ﻣﻌﻤﻮل ﺑﻪ ﻋﻨﻮان ﻳﻚ ﭘﻴﺸﻮﻧﺪ ﻳﺎ ﺑﺨﺸﻲ از ﻧﺎم در IETF ﺑﺮاي ﻳﻚ ﺑﺮوزرﺳﺎﻧﻲ اﺳﺘﻔﺎده ﺷﺪه اﺳﺖ.ﻧﻈﻴﺮ ﻣﻮرد 1.1 .HTTP
HTTP2 از SPDY ﺷﺮوع ﺷﺪ
SPDY ﭘﺮوﺗﻜﻠﻲ اﺳﺖ ﻛﻪ ﺗﻮﺳﻂ ﮔﻮﮔﻞ ﺗﻮﻟﻴﺪ و ﻣﻨﺘﺸﺮ ﺷﺪ. ﮔﻮﮔﻞ ﺣﺘﻤﺎ آن را ﺑﻪ ﺷﻜﻞ ﻣﺘﻦ ﺑﺎز ﺗﻮﺳﻌﻪ داد و از ﻫﺮ ﻛﺴﻲ ﺑﺮاي ﻣﺸﺎرﻛﺖ در آن دﻋﻮت ﻛﺮد اﻣﺎ واﺿﺢ ﺑﻮد ﻛﻪ ﻣﺰاﻳﺎي ﺑﺴﻴﺎري از داﺷﺘﻦ ﻛﻨﺘﺮل ﺑﺮ ﭘﻴﺎده ﺳﺎزي ﻳﻚ ﻣﺮورﮔﺮ ﻣﻌﺮوف و ﺟﻤﻌﻴﺖ ﺳﺮور ﭼﺸﻤﮕﻴﺮي ﺑﺎ ﺳﺮوﻳﺲ ﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﺧﻮﺑﻲ اﺳﺘﻔﺎده ﺷﺪه اﻧﺪ، ﺑﺪﺳﺖ آورد. زﻣﺎﻧﻲ ﻛﻪ ﮔﺮوه HTTPbis ﺗﺼﻤﻴﻢ ﮔﺮﻓﺖ ﻛﻪ ﻛﺎر ﺑﺮHTTP2را ﺷﺮوع ﻛﻨﺪ، SPDYﺛﺎﺑﺖ ﻛﺮده ﺑﻮد ﻛﻪ ﻳﻚ ﻣﻔﻬﻮم ﻛﺎري اﺳﺖ و اﻣﻜﺎن اﺳﺘﻘﺮار ﺑﺮ اﻳﻨﺘﺮﻧﺖ را دارد. ﺳﭙﺲ ﻛﺎرHTTP2 از ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲ 3/ SPDY ﺷﺮوع ﺷﺪ ﻛﻪ اﺳﺎﺳﺎ در ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲHTTP2 ﺑﺎ ﻛﻤﻲ ﭘﮋوﻫﺶ و ﺟﺎﻳﮕﺰﻳﻦ ﺳﺎزي اﻧﺠﺎم ﺷﺪه ﺑﻮد.
ﻣﻔﺎﻫﻴﻢ HTTP2
ﺑﻨﺎﺑﺮاﻳﻦ HTTP2 ﭼﻪ ﻛﺎري ﻣﻲ ﺧﻮاﻫﺪ اﻧﺠﺎم دﻫﺪ؟ ﻣﺮزﻫﺎي ﻛﺎر ﮔﺮوه HTTPbis ﻛﺠﺎ ﻫﺴﺘﻨﺪ؟ آﻧﻬﺎ در واﻗﻊ ﻛﺎﻣﻼ ﺻﺮﻳﺢ ﺑﻮدﻧﺪ و ﻣﺤﺪودﻳﺖ ﻫﺎﻳﻲ را ﺑﺮ ﺗﻮاﻧﺎﻳﻲ ﺗﻴﻢ ﺑﺮاي ﻧﻮآوري ﻗﺮار دادﻧﺪ: • ﺑﺎﻳﺪ اﻟﮕﻮواره ي HTTP را ﺣﻔﻆ ﻛﻨﺪ. ﻫﻨﻮز ﭘﺮوﺗﻜﻠﻲ اﺳﺖ ﻛﻪ ﻣﺸﺘﺮي درﺧﻮاﺳﺖ ﻫﺎي ﺧﻮد را ﺑﺮ TCPﺑﻪ ﺳﺮور ارﺳﺎل ﻣﻲ ﻛﻨﺪ. • URL ﻫﺎي //: httpو //: https را ﻧﻤﻲ ﺗﻮان ﺗﻐﻴﻴﺮ داد. ﻫﻴﭻ ﻃﺮح ﺟﺪﻳﺪي ﺑﺮاي آن وﺟﻮد ﻧﺪارد. ﻣﻴﺰان ﻣﺤﺘﻮاﻳﻲ ﻛﻪ از ﭼﻨﻴﻦ URL ﻫﺎﻳﻲ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﺪ، آﻧﻘﺪر ﺑﺰرگ اﺳﺖ ﻛﻪ ﻫﺮﮔﺰ ﺗﻐﻴﻴﺮ آﻧﻬﺎ را ﻗﺒﻮل ﻧﻤﻲ ﻛﻨﺪ. • ﺳﺮورﻫﺎ و ﻣﺸﺘﺮﻳﺎن 1 HTTP ﺑﻪ ﻣﺪت دﻫﻪ ﻫﺎ وﺟﻮد داﺷﺘﻪ اﻧﺪ، ﻧﻴﺎز دارﻳﻢ ﻛﻪ آﻧﻬﺎ را ﺑﻪ ﺳﺮورﻫﺎي HTTP2 ﭘﺮوﻛﺴﻲ ﻛﻨﻴﻢ. • در ﻧﺘﻴﺠﻪ، ﭘﺮوﻛﺴﻲ ﻫﺎ ﺑﺎﻳﺪ ﻗﺎدر ﺑﻪ ﻧﮕﺎﺷﺖ وﻳﮋﮔﻲ ﻫﺎي HTTP2 ﺑﻪ ﻣﺸﺘﺮﻳﺎن 1.1 HTTP ﺑﺎﺷﻨﺪ. • ﺣﺬف ﻳﺎ ﻛﺎﻫﺶ ﺑﺨﺶ ﻫﺎي اﺧﺘﻴﺎري از ﭘﺮوﺗﻜﻞ. اﻳﻦ ﻣﺴﺎﻟﻪ واﻗﻌﺎ ﻳﻚ ﻧﻴﺎزﻣﻨﺪي ﻧﺒﻮد. ﺑﺎ اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﺮدن از اﻳﻦ ﻛﻪ ﻫﻤﻪ ﭼﻴﺰ اﺟﺒﺎري اﺳﺖ، ﻫﻴﭻ راﻫﻲ وﺟﻮد ﻧﺪارد ﻛﻪ ﻫﻤﻪ ﭼﻴﺰﻫﺎ را اﻛﻨﻮن ﭘﻴﺎده ﺳﺎزي ﻧﻜﻨﻴﺪ و ﺑﻌﺪ دﭼﺎر ﻣﺸﻜﻞ ﺷﻮﻳﺪ. • دﻳﮕﺮ ﻧﺴﺨﻪ ي ﻛﻮﭼﻜﺘﺮ وﺟﻮد ﻧﺪاﺷﺖ. ﺗﺼﻤﻴﻢ ﮔﺮﻓﺘﻪ ﺷﺪ ﻛﻪ ﻣﺸﺘﺮﻳﺎن و ﺳﺮورﻫﺎ ﺑﺎHTTP2 ﺳﺎزﮔﺎر ﺑﺎﺷﻨﺪ ﻳﺎ ﻧﺒﺎﺷﻨﺪ. اﮔﺮ ﻧﻴﺎز ﺑﻪ ﺑﺴﻂ ﭘﺮوﺗﻜﻞ ﻳﺎ ﺗﻐﻴﻴﺮ ﭼﻴﺰﻫﺎ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ، آﻧﮕﺎه 3 HTTP ﻣﺘﻮﻟﺪ ﺧﻮاﻫﺪ ﺷﺪ. ﻫﻴﭻ ﻧﺴﺨﻪ ي ﻛﻮﭼﻜﺘﺮي در HTTP2 وﺟﻮد ﻧﺨﻮاﻫﺪ داﺷﺖ.
HTTP2 ﺑﺮاي ﻃﺮح ﻫﺎي URI ﻣﻮﺟﻮد
ﻫﻤﺎﻧﻄﻮر ﻛﻪ ﺗﺎﻛﻨﻮن ذﻛﺮ ﺷﺪه اﺳﺖ، ﻃﺮح ﻫﺎي URIﻣﻮﺟﻮد را ﻧﻤﻲ ﺗﻮان ﺗﻐﻴﻴﺮ داد ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ HTTP2 ﺑﺎﻳﺪ ﺑﺎ اﺳﺘﻔﺎده از ﻣﻮارد ﻣﻮﺟﻮد اﻧﺠﺎم ﺷﻮد. ﭼﻮن آﻧﻬﺎ اﻣﺮوزه ﺑﺮاي HTTP1.x ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﻴﺮﻧﺪ، ﺑﻪ وﺿﻮح ﻧﻴﺎز ﺑﻪ داﺷﺘﻦ روﺷﻲ ﺑﺮاي ارﺗﻘﺎي ﭘﺮوﺗﻜﻞ ﺑﻪHTTP2دارﻳﻢ ﻳﺎ در ﻏﻴﺮاﻳﻨﺼﻮرت از ﺳﺮور ﺑﺨﻮاﻫﻴﻢ ﻛﻪ از HTTP2 ﺑﻪ ﺟﺎي ﭘﺮوﺗﻜﻞ ﻫﺎي ﻗﺪﻳﻤﻲ ﺗﺮ اﺳﺘﻔﺎده ﻛﻨﺪ. 1.1 HTTP روﺷﻲ ﺗﻌﺮﻳﻒ ﺷﺪه ﺑﺮاي اﻧﺠﺎم اﻳﻦ ﻛﺎر دارد، ﻣﺜﻼ ارﺗﻘﺎ: ﺳﺮآﻳﻨﺪ ﺑﻪ ﺳﺮور اﻣﻜﺎن ارﺳﺎل ﭘﺎﺳﺦ ﻫﺎ ﺑﺎ اﺳﺘﻔﺎده از ﭘﺮوﺗﻜﻞ ﺟﺪﻳﺪ، زﻣﺎﻧﻲ ﻛﻪ ﭼﻨﻴﻦ درﺧﻮاﺳﺘﻲ را ﺑﺮ ﭘﺮوﺗﻜﻞ ﻗﺪﻳﻤﻲ درﻳﺎﻓﺖ ﻣﻲ ﻛﻨﺪ، ﻣﻲ دﻫﺪ. ﻫﺰﻳﻨﻪ اﻳﻦ ﻛﺎر ﻳﻚ ﺳﻔﺮ رﻓﺖ و ﺑﺮﮔﺸﺖ اﺳﺖ. اﻳﻦ ﺟﺮﻳﻤﻪ ي رﻓﺖ و ﺑﺮﮔﺸﺖ ﭼﻴﺰي ﻧﻴﺴﺖ ﻛﻪ ﺗﻴﻢ SPDY ﻗﺒﻮل ﻛﻨﺪ و ﭼﻮن ﻓﻘﻂ SPDY را ﺑﺮ TLS ﭘﻴﺎده ﺳﺎزي ﻛﺮدﻧﺪ، ﻳﻚ ﺑﺴﻂ TLS ﺟﺪﻳﺪ را ﺗﻮﺳﻌﻪ دادﻧﺪ ﻛﻪ ﺑﺮاي ﻣﻴﺎن ﺑﺮ ﻛﺮدن ﻣﺬاﻛﺮات ﻛﺎﻣﻼ ﻣﻮﺛﺮ ﺑﻮد. ﺑﺎ اﺳﺘﻔﺎده از اﻳﻦ ﺑﺴﻂ ﻛﻪ NPN (ﻣﺬاﻛﺮات ﭘﺮوﺗﻜﻞ ﺑﻌﺪي) ﻧﺎﻣﻴﺪه ﻣﻲ ﺷﻮد، ﺳﺮور ﺑﻪ ﻣﺸﺘﺮي ﻣﻲ ﮔﻮﻳﺪ ﻛﻪ ﻛﺪام ﭘﺮوﺗﻜﻞ ﻫﺎ را ﻣﻲ ﺷﻨﺎﻧﺪ و ﻣﺸﺘﺮي ﻣﻲ ﺗﻮاﻧﺪ ﭘﻴﺶ ﺑﺮود و از ﭘﺮوﺗﻜﻠﻲ ﻛﻪ ﺑﺮاﻳﺶ اوﻟﻮﻳﺖ دارد اﺳﺘﻔﺎده ﻛﻨﺪ.
HTTP2 ﺑﺮاي //: https
ﺗﻤﺮﻛﺰ زﻳﺎدHTTP2 ﺑﺮاي رﻓﺘﺎر ﻣﻮﺛﺮ ﺑﺮ TLSاﻧﺠﺎم ﺷﺪه اﺳﺖ. SPDY ﻓﻘﻂ ﺑﺮ TLS اﻧﺠﺎم ﻣﻲ ﺷﻮد و ﻧﻴﺎز ﻗﻮي ﺑﺮاي اﺟﺒﺎري ﺳﺎﺧﺘﻦ TLSﺑﺮاي HTTP وﺟﻮد دارد اﻣﺎ ﺗﻮاﻓﻖ اﻳﺠﺎد ﻧﺸﺪه اﺳﺖ و HTTP2 ﺑﺎ TLS ﺑﻪ ﺷﻜﻞ اﺧﺘﻴﺎري اراﺋﻪ ﺧﻮاﻫﺪ ﺷﺪ. اﻣﺎ دو ﭘﻴﺎده ﺳﺎزي ﺑﺮﺗﺮ ﺑﻪ وﺿﻮح اراﺋﻪ ﺷﺪه اﻧﺪ ﻛﻪ ﻓﻘﻂ ﺑﻪ ﭘﻴﺎده ﺳﺎزي HTTP2 ﺑﺮ TLS ﻣﻲ ﭘﺮدازﻧﺪ : ﻣﻮزﻳﻼ ﻓﺎﻳﺮﻓﺎﻛﺲ lead و ﮔﻮﮔﻞ ﻛﺮوم .lead اﻳﻦ دو ﻣﺮورﮔﺮ، ﻣﺮورﮔﺮﻫﺎي ﭘﻴﺸﺮو اﻣﺮوزي ﻫﺴﺘﻨﺪ. دﻻﻳﻞ اﻧﺘﺨﺎب TLS ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﺷﺎﻣﻞ اﺣﺘﺮام ﺑﻪ ﻣﺤﺮﻣﺎﻧﮕﻲ ﻛﺎرﺑﺮ و اﻧﺪازه ﮔﻴﺮي ﻫﺎي اوﻟﻴﻪ اﺳﺖ ﻛﻪ ﻧﺸﺎن ﻣﻲ دﻫﻨﺪ ﻛﻪ ﭘﺮوﺗﻜﻞ ﻫﺎي ﺟﺪﻳﺪ ﻧﺮخ ﻣﻮﻓﻘﻴﺖ ﺑﺎﻻﺗﺮي زﻣﺎﻧﻲ ﻛﻪ ﺑﺎ TLS اﻧﺠﺎم ﻣﻲ ﺷﻮﻧﺪ، دارﻧﺪ. اﻳﻦ اﻣﺮ ﺑﻪ دﻟﻴﻞ اﻳﻦ ﻓﺮض ﮔﺴﺘﺮده اﺳﺖ ﻛﻪ ﻫﺮ اﺗﻔﺎﻗﻲ ﻛﻪ ﺑﺮ ﭘﻮرت 80 رخ ﻣﻲ دﻫﺪ از ﻃﺮﻳﻖ 1.1 HTTP اﺳﺖ ﻛﻪ ﻣﻮﺟﺐ ﺑﺮﺧﻲ ﻣﺪاﺧﻠﻪ ﻫﺎي middle-box ﻣﻲ ﺷﻮد و زﻣﺎﻧﻲ ﻛﻪ ﺑﻪ ﺟﺎي ﺳﺎﻳﺮ ﭘﺮوﺗﻜﻞ ﻫﺎ در اﻳﻦ ﭘﻮرت ارﺗﺒﺎط ﺑﺮﻗﺮار ﻣﻲ ﻛﻨﺪ، ﺗﺮاﻓﻴﻚ را ﻣﺨﺪوش ﻣﻲ ﻛﻨﺪ. ﻣﻮﺿﻮع TLSاﺟﺒﺎري ﻣﻨﺠﺮ ﺑﻪ ﺑﺤﺚ ﻫﺎ و اﻋﺘﺮاض ﻫﺎي زﻳﺎدي ﺷﺪه اﺳﺖ-آﻳﺎ ﺧﻮب اﺳﺖ ﻳﺎ ﺑﺪ؟ اﻳﻦ ﻣﻮﺿﻮع، ﻳﻚ ﻣﻮﺿﻮع ﺳﺮاﻳﺖ ﻛﻨﻨﺪه و ﻫﻤﻪ ﮔﻴﺮ اﺳﺖ-از اﻳﻦ ﻣﺴﺎﻟﻪ زﻣﺎﻧﻲ ﻛﻪ ﭘﺮﺳﺸﻲ در اﻳﻦ ﻣﻮرد را از ﻳﻚ ﻣﺸﺎرﻛﺖ ﻛﻨﻨﺪه ي HTTPbis ﻣﻲ ﭘﺮﺳﻴﺪ، ﻣﻄﻠﻊ ﺑﺎﺷﻴﺪ! ﺑﻪ ﻃﻮر ﻣﺸﺎﺑﻪ، ﺑﺤﺚ و ﺑﺮرﺳﻲ ﺷﺪﻳﺪ و ﻃﻮﻻﻧﻲ ﻣﺪت در ﻣﻮرد اﻳﻦ ﻛﻪ آﻳﺎ HTTP2 ﺑﺎﻳﺪ ﻳﻚ ﻟﻴﺴﺖ از رﻣﺰﻫﺎي اﺟﺒﺎري را زﻣﺎﻧﻲ ﻛﻪ از TLSاﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻴﻢ، اﺧﺘﺼﺎص دﻫﺪ ﻳﺎ اﻳﻦ ﻛﻪ ﻳﻚ ﻣﺠﻤﻮﻋﻪ را در ﻟﻴﺴﺖ ﺳﻴﺎه ﻗﺮار دﻫﺪ ﻳﺎ ﻛﻼ ﻫﻴﭻ ﭼﻴﺰي از ﻻﻳﻪ ي TLS ﻧﻴﺎز ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ، وﺟﻮد دارد، اﻣﺎ ﺑﻬﺘﺮ اﺳﺖ اﻳﻦ ﻣﺴﺎﺋﻞ را ﺑﻪ ﮔﺮوه ﻛﺎري TLS واﮔﺬار ﻛﻨﻴﻢ.
ﻣﺬاﻛﺮاتHTTP2 ﺑﺮ TLS
ﻣﺬاﻛﺮات ﭘﺮوﺗﻜﻞ ﺑﻌﺪي ()NPN ﭘﺮوﺗﻜﻠﻲ اﺳﺖ ﻛﻪ ﺑﺮاي اﻳﺠﺎد ارﺗﺒﺎط SPDYﺑﺎ ﺳﺮورﻫﺎي TLSﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﻴﺮد. ﭼﻮن اﺳﺘﺎﻧﺪارد ﻣﻨﺎﺳﺒﻲ ﻧﺒﻮد، از ﻃﺮﻳﻖ IETFﺣﺎﺻﻞ ﺷﺪه و ALPNاز آن ﺣﺎﺻﻞ ﺷﺪ: ﻣﺬاﻛﺮات ﭘﺮوﺗﻜﻞ ﺳﻄﺢ ﺑﺮﻧﺎﻣﻪ ﻛﺎرﺑﺮدي. ALPN ﭼﻴﺰي اﺳﺖ ﻛﻪ ﺑﺮايHTTP2ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﺧﻮاﻫﺪ ﮔﺮﻓﺖ، در ﺣﺎﻟﻲ ﻛﻪ ﻣﺸﺘﺮﻳﺎن SPDY و ﺳﺮورﻫﺎ ﻫﻨﻮز از NPNاﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ. اﻳﻦ واﻗﻌﻴﺖ ﻛﻪ NPNدر اﺑﺘﺪا وﺟﻮد داﺷﺘﻪ اﺳﺖ و اﺳﺘﺎﻧﺪاردﺳﺎزي ALPNﻣﺪﺗﻲ ﻃﻮل ﻛﺸﻴﺪه اﺳﺖ، ﻣﻨﺠﺮ ﺑﻪ ﭘﻴﺎده ﺳﺎزي و اﺳﺘﻔﺎده ي ﺑﺴﻴﺎري از ﻣﺸﺘﺮﻳﺎن و ﺳﺮورﻫﺎي HTTP2 و اﺳﺘﻔﺎده از ﻫﺮ دوي اﻳﻦ ﺑﺴﻂ ﻫﺎ زﻣﺎﻧﻲ ﻛﻪ ﺑﻪ ﻣﺬاﻛﺮه ﺑﺎ اﺳﺘﻔﺎده از HTTP2 ﻣﻲ ﭘﺮدازﻧﺪ، ﺷﺪه اﺳﺖ. ﻫﻤﭽﻨﻴﻦ ﭼﻮن NPN ﭼﻴﺰي اﺳﺖ ﻛﻪ ﺑﺮاي SPDYاﺳﺘﻔﺎده ﻣﻲ ﺷﻮد و ﺳﺮورﻫﺎي ﺑﺴﻴﺎري ﻫﺮ دوي SPDY و HTTP2 را اراﺋﻪ ﻣﻲ ﻛﻨﻨﺪ، ﺑﻨﺎﺑﺮاﻳﻦ ﭘﺸﺘﻴﺒﺎﻧﻲ از NPNو ALPN ﺑﺮ اﻳﻦ ﺳﺮورﻫﺎ ﻣﻨﻄﻘﻲ اﺳﺖ. ALPN اﺳﺎﺳﺎ از NPN ﻣﺘﻔﺎوت اﺳﺖ و در ALPN ﻛﺴﻲ ﻛﻪ ﺗﺼﻤﻴﻢ ﻣﻲ ﮔﻴﺮد ﻛﻪ ﺑﺎ ﻛﺪام ﭘﺮوﺗﻜﻞ ﻫﺎ ارﺗﺒﺎط ﺑﺮﻗﺮار ﻛﻨﺪ، ﻣﺘﻔﺎوت اﺳﺖ. در ALPN ﻛﻼﻳﻨﺖ ﺑﻪ ﺳﺮور ﻟﻴﺴﺘﻲ از ﭘﺮوﺗﻜﻞ ﻫﺎ را ﺑﺮ اﺳﺎس اوﻟﻮﻳﺖ ﺧﻮد اراﺋﻪ ﻣﻲ ﻛﻨﺪ و ﺳﺮور ﻣﻮردي را ﻛﻪ ﻣﻲ ﺧﻮاﻫﺪ اﻧﺘﺨﺎب ﻣﻲ ﻛﻨﺪ، در ﺣﺎﻟﻲ ﻛﻪ در WPN ﻣﺸﺘﺮي اﻧﺘﺨﺎب ﻧﻬﺎﻳﻲ را اﻧﺠﺎم ﻣﻲ دﻫﺪ.
HTTP2 ﺑﺮاي //: http
ﻫﻤﺎﻧﻄﻮر ﻛﻪ ﻗﺒﻼ ﺑﻪ ﻃﻮر ﺧﻼﺻﻪ ذﻛﺮ ﺷﺪ، ﺑﺮاي 1.1 HTTP روﺷﻲ ﻛﻪ ﺑﺎ HTTP2 ﻣﺬاﻛﺮه ﻣﻲ ﻛﻨﺪ از ﻃﺮﻳﻖ درﺧﻮاﺳﺖ از ﺳﺮور ﺑﺎ ﻳﻚ ارﺗﻘﺎ اﺳﺖ: ﺳﺮآﻳﻨﺪ. اﮔﺮ ﺳﺮور از ﻃﺮﻳﻖ HTTP2 ارﺗﺒﺎط ﺑﺮﻗﺮار ﻛﻨﺪ، ﺑﺎ ﻳﻚ وﺿﻌﻴﺖ "" 101 switchingﭘﺎﺳﺦ ﻣﻲ دﻫﺪ و از آن ﺑﻪ ﺑﻌﺪ ارﺗﺒﺎط ﺧﻮد را از ﻃﺮﻳﻖ HTTP2 ﺑﺮﻗﺮار ﻣﻲ ﻛﻨﺪ. اﻟﺒﺘﻪ اﻳﻦ روﻳﻪ ي ارﺗﻘﺎ ﻧﻴﺎز ﺑﻪ ﻳﻚ رﻓﺖ و ﺑﺮﮔﺸﺖ ﻛﺎﻣﻞ دارد اﻣﺎ ﺑﺮﺗﺮي آن اﻳﻦ اﺳﺖ ﻛﻪ ﻓﻌﺎل ﻧﮕﻪ داﺷﺘﻦ اﺗﺼﺎل HTTP2 ﺑﺎﻳﺪ اﻣﻜﺎن ﭘﺬﻳﺮ ﺑﺎﺷﺪ و ﺑﺘﻮان ﺑﻪ ﻣﻴﺰان زﻳﺎدي ﻧﺴﺒﺖ ﺑﻪ ﭼﻴﺰي ﻛﻪ اﺗﺼﺎﻻت 1 HTTPاﻏﻠﺐ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ از آن اﺳﺘﻔﺎده ﻛﺮد. در ﺣﺎﻟﻲ ﻛﻪ ﺑﺮﺧﻲ از ﻣﺮورﮔﺮﻫﺎ اﻇﻬﺎر ﻛﺮده اﻧﺪ ﻛﻪ اﻳﻦ اﺑﺰار HTTP2 را ﭘﻴﺎده ﺳﺎزي ﻧﺨﻮاﻫﻨﺪ ﻛﺮد، ﺗﻴﻢ اﻳﻨﺘﺮﻧﺖ اﻛﺴﭙﻠﻮرر ﮔﻔﺘﻪ اﺳﺖ ﻛﻪ آن را ﭘﻴﺎده ﺳﺎزي ﺧﻮاﻫﺪ ﻛﺮد و curlدر ﺣﺎل ﺣﺎﺿﺮ از آن ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲ ﻛﻨﺪ.
ﭘﺮوﺗﻜﻞ HTTP2
ﺗﺎ اﻳﻨﺠﺎ ﺑﻪ اﻧﺪازه ﻛﺎﻓﻲ در ﻣﻮرد ﭘﺲ زﻣﻴﻨﻪ، ﺗﺎرﻳﺨﭽﻪ و ﺳﻴﺎﺳﺖ ﻫﺎي ﭘﺸﺖ ﭼﻴﺰي ﻛﻪ ﻣﺎ را ﺑﺪﻳﻨﺠﺎ رﺳﺎﻧﺪه اﺳﺖ، ﺷﺮح دادﻳﻢ. اﺟﺎزه دﻫﻴﻢ ﺑﻪ ﺷﺮح ﻣﺸﺨﺼﺎت ﭘﺮوﺗﻜﻞ ﺑﭙﺮدازﻳﻢ. ﻣﻔﺎﻫﻴﻤﻲ ﻛﻪ HTTP2 را اﻳﺠﺎد ﻛﺮده اﻧﺪ.
دودوﻳﻲ
HTTP2 ﻳﻚ ﭘﺮوﺗﻜﻞ دودوﻳﻲ اﺳﺖ. اﺟﺎزه دﻫﻴﺪ ﻛﻤﻲ در ﻣﻮرد آن ﺑﻴﺎﻧﺪﻳﺸﻴﻢ. اﮔﺮ ﺷﻤﺎ ﻛﺴﻲ ﺑﺎﺷﻴﺪ ﻛﻪ ﻗﺒﻼ در ﭘﺮوﺗﻜﻞ ﻫﺎي اﻳﻨﺘﺮﻧﺘﻲ ﻣﺸﺎرﻛﺖ داﺷﺘﻪ اﻳﺪ، اﻳﻦ ﺷﺎﻧﺲ وﺟﻮد دارد ﻛﻪ ﺑﻪ ﺷﺪت ﺑﻪ اﻳﻦ ﻣﺴﺎﻟﻪ واﻛﻨﺶ دﻫﻴﺪ و ﺑﺤﺚ ﻫﺎي رد ﻛﺮدن ﺧﻮد را در ﻣﻮرد اﻳﻦ ﻛﻪ ﭼﻘﺪر ﭘﺮوﺗﻜﻞ ﻫﺎﻳﻲ ﻛﻪ ﺑﺎ ﻣﺘﻦ/اﺳﻜﻲ اﻳﺠﺎد ﺷﺪه اﻧﺪ، ﻣﻔﻴﺪ ﻫﺴﺘﻨﺪ، اراﺋﻪ ﻛﻨﻴﺪ. HTTP2 ﺑﺮاي آﺳﺎﻧﺘﺮ ﺳﺎﺧﺘﻦ framing دودوﻳﻲ اﺳﺖ. ﻣﺸﺨﺺ ﻛﺮدن زﻣﺎن ﺷﺮوع و اﻧﺘﻬﺎي ﻓﺮﻳﻢ ﻫﺎ ﻳﻜﻲ از ﭼﻴﺰﻫﺎي واﻗﻌﺎ ﭘﻴﭽﻴﺪه در 1.1 HTTP و ﺑﻪ ﻃﻮر ﻛﻠﻲ در ﭘﺮوﺗﻜﻞ ﻫﺎي ﻣﺒﺘﻨﻲ ﺑﺮ ﻣﺘﻦ اﺳﺖ. ﺑﺎ دور ﺷﺪن از ﻓﻀﺎﻫﺎي ﺳﻔﻴﺪ اﺧﺘﻴﺎري و راه ﻫﺎي ﻣﺨﺘﻠﻒ ﻧﻮﺷﺘﻦ ﻳﻚ ﭼﻴﺰ ﻳﻜﺴﺎن، ﭘﻴﺎده ﺳﺎز ﻫﺎ آﺳﺎﻧﺘﺮ ﻣﻲ ﺷﻮد. ﻫﻤﭽﻨﻴﻦ ﺟﺪاﺳﺎزي ﺑﺨﺶ ﻫﺎي ﭘﺮوﺗﻜﻞ واﻗﻌﻲ از framing آﺳﺎﻧﺘﺮ اﺳﺖ ﻛﻪ در HTTP1 ﺑﻪ ﻃﻮر ﮔﻴﺞ ﻛﻨﻨﺪه اي ﺑﻪ ﻫﻢ آﻣﻴﺨﺘﻪ ﺷﺪه اﻧﺪ. واﻗﻌﻴﺎت ﻓﺸﺮده ﺳﺎزي وﻳﮋﮔﻲ ﻫﺎي ﭘﺮوﺗﻜﻞ و اﺟﺮاي آﻧﻬﺎ ﺑﺮ TLSﻣﻨﺠﺮ ﺑﻪ ﻛﺎﻫﺶ ارزش ﻣﺘﻦ ﻣﻲ ﺷﻮﻧﺪ ﭼﻮن دﻳﮕﺮ ﻣﺘﻦ را ﺑﺮ رﺳﺎﻧﻪ ﺳﻴﻤﻲ ﻣﺸﺎﻫﺪه ﻧﻤﻲ ﻛﻨﻴﺪ. ﺑﻪ ﺳﺎدﮔﻲ ﺑﺎﻳﺪ ﺑﻪ اﻳﺪه ي ﻳﻚ ﺑﺮرﺳﻲ ﻛﻨﻨﺪه ي wireshark ﻳﺎ ﻣﺸﺎﺑﻪ ﺑﺎ آن، ﺑﺮاي ﻣﺸﺨﺺ ﻛﺮدن اﻳﻦ ﻛﻪ دﻗﻴﻘﺎ ﭼﻪ اﺗﻔﺎﻗﻲ در ﺳﻄﺢ ﭘﺮوﺗﻜﻞ در HTTP2 رخ ﻣﻲ دﻫﺪ، ﻋﺎدت ﻛﻨﻴﻢ.
دﻳﺒﺎگ اﻳﻦ ﭘﺮوﺗﻜﻞ اﺣﺘﻤﺎل ﺑﺎﻳﺪ ﺑﺎ اﺑﺰارﻫﺎﻳﻲ ﻧﻈﻴﺮ curlﻳﺎ ﺑﺎ ﺗﺠﺰﻳﻪ و ﺗﺤﻠﻴﻞ ﺟﺮﻳﺎن ﺷﺒﻜﻪ ﺑﺎ ﺗﺸﺮح ﻛﻨﻨﺪه ي wireshark HTTP2 و ﻣﺸﺎﺑﻪ آن اﻧﺠﺎم ﺷﻮد.
ﻓﺮﻣﺖ دودوﻳﻲ
HTTP2 ﻓﺮﻣﺖ ﻫﺎي دودوﻳﻲ را ارﺳﺎل ﻣﻲ ﻛﻨﺪ. اﻧﻮاع ﻓﺮﻳﻢ ﻫﺎي ﻣﺨﺘﻠﻔﻲ وﺟﻮد دارﻧﺪ ﻛﻪ ﻣﻲ ﺗﻮان ارﺳﺎل ﻛﺮد و ﺑﺎﻳﺪ ﻣﺮﺣﻠﻪ ﻳﻜﺴﺎﻧﻲ داﺷﺘﻪ ﺑﺎﺷﻨﺪ: ﻧﻮع، ﻃﻮل، ﻓﻠﮓ، ﺷﻨﺎﺳﻪ ﺟﺮﻳﺎن و ﺑﺎر ﻣﻔﻴﺪ ﻓﺮﻳﻢ. ده ﻓﺮﻳﻢ ﻣﺨﺘﻠﻒ وﺟﻮد دارﻧﺪ ﻛﻪ در ﻣﺸﺨﺼﺎت HTTP2 ﺗﻌﺮﻳﻒ ﺷﺪه اﻧﺪ و دو ﻣﻮرد از آﻧﻬﺎ ﻛﻪ ﺷﺎﻳﺪ ﭘﺎﻳﻪ اي ﺗﺮﻳﻦ ﻣﻮارد ﺑﺎﺷﻨﺪ ﻛﻪ ﺑﺎ وﻳﮋﮔﻲ ﻫﺎي HTTP 1.1 ﺗﻄﺎﺑﻖ دارﻧﺪ، DATA و HEADERS ﻫﺴﺘﻨﺪ. در اداﻣﻪ ﺑﻪ ﺷﺮح ﺑﺮﺧﻲ از ﻓﺮﻳﻢ ﻫﺎ ﺑﺎ ﺟﺰﺋﻴﺎت ﺑﻴﺸﺘﺮ ﻣﻲ ﭘﺮدازﻳﻢ.
ﺟﺮﻳﺎن ﻫﺎي ﺗﺴﻬﻴﻢ ﺷﺪه
ﺷﻨﺎﺳﻪ ي ﺟﺮﻳﺎن ذﻛﺮ ﺷﺪه در ﺑﺨﺶ ﻗﺒﻠﻲ ﺑﻪ ﺷﺮح ﻓﺮﻣﺖ ﻓﺮﻳﻢ دودوﻳﻲ ﻣﻲ ﭘﺮدازد ﻛﻪ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮد ﻛﻪ ﻫﺮ ﻓﺮﻳﻤﻲ ﻛﻪ ﺑﺮ HTTP2 ارﺳﺎل ﺷﺪه اﺳﺖ ﺑﺎ ﻳﻚ ﺟﺮﻳﺎن ﻣﺮﺗﺒﻂ ﺷﻮد. ﺟﺮﻳﺎن ﻳﻚ ارﺗﺒﺎط ﻣﻨﻄﻘﻲ اﺳﺖ. ﻳﻚ دﻧﺒﺎﻟﻪ ي ﻣﺴﺘﻘﻞ، دو-ﺟﻬﺘﻪ از ﻓﺮﻳﻢ ﻫﺎﻳﻲ ﻛﻪ ﺑﻴﻦ ﻣﺸﺘﺮي و ﺳﺮور در ﻳﻚ ارﺗﺒﺎط HTTP2 ﻣﺒﺎدﻟﻪ ﺷﺪه اﻧﺪ. ﻳﻚ اﺗﺼﺎل HTTP2 ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻣﻲ ﺗﻮاﻧﺪ ﺣﺎوي ﭼﻨﺪﻳﻦ ﺟﺮﻳﺎن ﺑﺎز ﻫﻤﺮوﻧﺪ از ﻫﺮ ﻓﺮﻳﻢ ﻣﻴﺎن ﮔﺬاري ﻧﻘﻄﻪ اﻧﺘﻬﺎﻳﻲ از ﭼﻨﺪﻳﻦ ﺟﺮﻳﺎن ﺑﺎﺷﺪ. ﺟﺮﻳﺎن ﻫﺎ را ﻣﻲ ﺗﻮان ﺑﻪ ﺷﻜﻞ ﻳﻚ ﻃﺮﻓﻪ ﻳﺎ اﺷﺘﺮاﻛﻲ ﺗﻮﺳﻂ ﻣﺸﺘﺮي و ﺳﺮور ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار داد و ﻣﻲ ﺗﻮان ﺗﻮﺳﻂ ﻫﺮ ﻧﻘﻄﻪ اﻧﺘﻬﺎﻳﻲ ﺑﻪ اﺗﻤﺎم ﺑﺮﺳﻨﺪ. ﺗﺮﺗﻴﺒﻲ ﻛﻪ ﻓﺮﻳﻢ ﻫﺎ در ﻳﻚ ﺟﺮﻳﺎن ارﺳﺎل ﻣﻲ ﺷﻮﻧﺪ، ﻣﻬﻢ اﺳﺖ. ﮔﻴﺮﻧﺪﮔﺎن ﻓﺮﻳﻢ ﻫﺎ را ﺑﻪ ﺗﺮﺗﻴﺒﻲ ﻛﻪ آﻧﻬﺎ را درﻳﺎﻓﺖ ﻣﻲ ﻛﻨﻨﺪ، ﭘﺮدازش ﻣﻲ ﻧﻤﺎﻳﻨﺪ. ﺗﺴﻬﻴﻢ ﺟﺮﻳﺎن ﺑﺪﻳﻦ ﻣﻌﻨﻲ اﺳﺖ ﻛﻪ ﺑﺴﺘﻪ ﻫﺎ از ﺗﻌﺪاد زﻳﺎدي ﺟﺮﻳﺎن ﺑﺮ اﺗﺼﺎل ﻳﻜﺴﺎﻧﻲ ﺗﺮﻛﻴﺐ ﻣﻲ ﺷﻮﻧﺪ. دو (ﻳﺎ ﺑﻴﺸﺘﺮ) ﺟﺮﻳﺎن ﻣﺠﺰاي داده در ﻳﻚ ﺟﺮﻳﺎن ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻗﺮار ﻣﻲ ﮔﻴﺮﻧﺪ و ﺳﭙﺲ دوﺑﺎره در ﺳﻤﺖ دﻳﮕﺮ ﻣﺠﺰا ﻣﻲ ﺷﻮﻧﺪ. در اﻳﻨﺠﺎ دو ﺟﺮﻳﺎن (ﻗﻄﺎر) وﺟﻮد دارﻧﺪ:
ﺑﻨﺎﺑﺮاﻳﻦ اﻳﻦ دو در اﺗﺼﺎل ﻳﻜﺴﺎﻧﻲ ﺑﻪ ﺷﻴﻮه اي ﺗﺴﻬﻴﻢ ﺷﺪه ﺗﺮﻛﻴﺐ ﻣﻲ ﺷﻮﻧﺪ:
در HTTP2 ده ﻫﺎ و ﺻﺪﻫﺎ ﺟﺮﻳﺎن ﻫﻤﺰﻣﺎن ﻣﺸﺎﻫﺪه ﺧﻮاﻫﻴﻢ ﻛﺮد. ﻫﺰﻳﻨﻪ ي اﻳﺠﺎد ﻳﻚ ﺟﺮﻳﺎن ﺟﺪﻳﺪ ﺧﻴﻠﻲ ﭘﺎﻳﻴﻦ اﺳﺖ.
اوﻟﻮﻳﺖ ﻫﺎ و واﺑﺴﺘﮕﻲ ﻫﺎ
ﻫﺮ ﺟﺮﻳﺎن ﻳﻚ اوﻟﻮﻳﺖ دارد ﻛﻪ ﺑﺮاي اﻃﻼع رﺳﺎﻧﻲ ﺑﻪ ﻧﻈﻴﺮ ﻛﻪ ﻛﺪام ﺟﺮﻳﺎن را ﻣﻬﻤﺘﺮﻳﻦ ﺟﺮﻳﺎن در ﻧﻈﺮ ﺑﮕﻴﺮد، ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﻴﺮد. ﺟﺰﺋﻴﺎت دﻗﻴﻖ در ﻣﻮرد اﻳﻦ ﻛﻪ ﭼﻄﻮر اوﻟﻮﻳﺖ ﻫﺎ در ﭘﺮوﺗﻜﻞ ﻫﺎ ﻋﻤﻞ ﻣﻲ ﻛﻨﻨﺪ ﭼﻨﺪﻳﻦ ﺑﺎر ﺗﻐﻴﻴﺮ ﻛﺮده اﻧﺪ و ﻫﻨﻮز ﻧﻴﺰ ﻣﻮرد ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻗﺮار دارﻧﺪ. ﻧﻜﺘﻪ اﻳﻦ اﺳﺖ ﻛﻪ ﻣﺸﺘﺮي ﻣﻲ ﺗﻮاﻧﺪ ﻣﺸﺨﺺ ﻛﻨﺪ ﻛﻪ ﻛﺪام ﺟﺮﻳﺎن ﻫﺎ ﻣﻬﻤﺘﺮﻳﻦ ﻫﺴﺘﻨﺪ و ﻳﻚ ﭘﺎراﻣﺘﺮ واﺑﺴﺘﮕﻲ وﺟﻮد دارد، ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﻳﻚ ﺟﺮﻳﺎن را ﻣﻲ ﺗﻮان ﺑﻪ دﻳﮕﺮي واﺑﺴﺘﻪ ﺳﺎﺧﺖ. اوﻟﻮﻳﺖ ﻫﺎ ﻣﻲ ﺗﻮاﻧﻨﺪ ﺑﻪ ﻃﻮر ﭘﻮﻳﺎ در زﻣﺎن اﺟﺮا ﺗﻐﻴﻴﺮ ﻛﻨﻨﺪ ﻛﻪ ﺑﺎﻳﺪ ﻣﺮورﮔﺮﻫﺎ را ﻗﺎدر ﺑﻪ ﺣﺼﻮل اﻃﻤﻴﻨﺎن از اﻳﻦ ﻣﺴﺎﻟﻪ ﻛﻨﻨﺪ ﻛﻪ زﻣﺎﻧﻲ ﻛﻪ ﻛﺎرﺑﺮان ﻳﻚ ﺻﻔﺤﻪ ي ﭘﺮ از ﺗﺼﺎوﻳﺮ را ﺗﺎ ﭘﺎﻳﻴﻦ ﭘﻴﻤﺎﻳﺶ ﻣﻲ ﻛﻨﻨﺪ، ﻣﻲ ﺗﻮاﻧﺪ ﻣﺸﺨﺺ ﻛﻨﺪ ﻛﻪ ﻛﺪام ﺗﺼﺎوﻳﺮ ﻣﻬﻤﺘﺮ ﻫﺴﺘﻨﺪ ﻳﺎ اﮔﺮ ﺗﺐ ﻫﺎ را ﺗﻐﻴﻴﺮ دﻫﻴﺪ، ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺟﺪﻳﺪ از ﺟﺮﻳﺎن ﻫﺎ را اوﻟﻮﻳﺖ ﺑﻨﺪي ﻣﻲ ﻛﻨﺪ ﻛﻪ ﻣﻮرد ﺗﻤﺮﻛﺰ ﻗﺮار ﻣﻲ ﮔﻴﺮﻧﺪ.
نتیجه گیری
نتیجه ای که در نهایت حاصل شده است.
مراجع
[1] Thomson, WEBPUSH M. "Internet-Draft Mozilla Intended status: Standards Track May 12, 2014 Expires: November 13, 2014." (2014).
[2] Stenberg, Daniel. "HTTP2 explained." ACM SIGCOMM Computer Communication Review 44.3 (2014): 120-128.
[3] Thomson, M., and A. Melnikov. "Hypertext Transfer Protocol version 2.0 draft-ietf-httpbis-http2-09." (2013).
[4] Peon, Roberto. "Header Delta-Compression for HTTP/2.0." (2013).