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‬ اﻣﺮوز

HTTP 1.1 ﺑﻪ ﭘﺮوﺗﻜﻠﻲ ﺗﺒﺪﻳﻞ ﺷﺪه اﺳﺖ ﻛﻪ ﺑﺮاي ﻫﺮ ﭼﻴﺰي ﻛﻪ ﺑﻪ ﻃﻮر ﻣﺠﺎزي ﺑﺮ اﻳﻨﺘﺮﻧﺖ ﻗﺮار دارد، اﺳﺘﻔﺎده ﻣﻲ ﺷﻮد.‬ ﺳﺮﻣﺎﻳﻪ ﮔﺬاري ﻫﺎي زﻳﺎد ﺑﺮ ﭘﺮوﺗﻜﻞ ﻫﺎ و زﻳﺮﺳﺎﺧﺖ ﻫﺎﻳﻲ اﻧﺠﺎم ﺷﺪه اﻧﺪ ﻛﻪ از اﻳﻦ ﻣﺰﻳﺖ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ ﺗﺎ‬ اﻧﺪازه اي ﭘﻴﺸﺮﻓﺖ ﻛﺮده اﺳﺖ ﻛﻪ اﻏﻠﺐ آﺳﺎﻧﺘﺮ اﺳﺖ ﻛﻪ ﭼﻴﺰﻫﺎ را ﺑﺮ روي HTTP‬ ﺑﻪ اﺟﺮا در آورﻳﻢ ﺑﻪ ﺟﺎي اﻳﻦ ﻛﻪ ﭼﻴﺰي‬ را ﺧﻮدﻣﺎن ﺟﺪﻳﺪ ﺑﺴﺎزﻳﻢ.‬‬‬‬‬‬‬

HTTP 1.1 ﺑﺰرگ اﺳﺖ

زﻣﺎﻧﻲ ﻛﻪ HTTP‬ اﻳﺠﺎد ﺷﺪ، اﺣﺘﻤﺎﻻ ﺑﻪ ﻋﻨﻮان ﻳﻚ ﭘﺮوﺗﻜﻞ ﺑﻪ ﻧﺴﺒﺖ ﺳﺎده و ﺳﺮراﺳﺖ در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﺪ اﻣﺎ ﮔﺬﺷﺖ‬ زﻣﺎن ﻧﺎدرﺳﺘﻲ اﻳﻦ ﻣﺴﺎﻟﻪ را ﺛﺎﺑﺖ ﻛﺮد. HTTP 0.1‬ در 1945 RFC‬ ﻳﻚ ﻣﺸﺨﺼﺎت 60 ﺻﻔﺤﻪ اي اﺳﺖ ﻛﻪ در ﺳﺎل‬ 1996 ﻣﻨﺘﺸﺮ ﺷﺪ.2616 RFC‬ ﻛﻪ ﺑﻪ ﺷﺮح HTTP 1.1 ﻣﻲ ﭘﺮدازد ﻛﻪ ﺳﻪ ﺳﺎل ﺑﻌﺪ در ﺳﺎل 1999 ﻣﻨﺘﺸﺮ ﺷﺪ و ﺑﻪ‬ ﻃﻮر ﭼﺸﻤﮕﻴﺮي ﺗﺎ 176 ﺻﻔﺤﻪ اﻓﺰاﻳﺶ ﺣﺠﻢ داﺷﺖ. ﻫﻨﻮز زﻣﺎﻧﻲ ﻛﻪ در IETF‬ﺑﺮ ﺑﺮوزرﺳﺎﻧﻲ آن ﻣﺸﺨﺼﺎت ﻛﺎر ﻣﻲ ﻛﻨﻴﻢ،‬ آن را ﺗﻘﺴﻴﻢ ﻛﺮده و ﺑﻪ 6 ﻣﺴﺘﻨﺪ ﺑﺎ ﺗﻌﺪاد ﺻﻔﺤﻪ ﺑﻴﺸﺘﺮي ﺗﺒﺪﻳﻞ ﻣﻲ ﻛﻨﻴﻢ (ﻣﻨﺠﺮ ﺑﻪ 7230 RFC‬ و ﺧﺎﻧﻮاده اش ﻣﻲ‬ ﺷﻮد)HTTP 1.1 ﺑﺰرگ اﺳﺖ و ﺷﺎﻣﻞ ﺟﺰﺋﻴﺎت زﻳﺎد، ﻇﺮاﻓﺖ و ﻣﻴﺰان زﻳﺎدي ﺑﺨﺶ ﻫﺎي اﺧﺘﻴﺎري اﺳﺖ.

دﻧﻴﺎیی از اﻣﻜﺎﻧﺎت و ﮔﺰﻳﻨﻪ ﻫﺎ

ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﻳﻦ ﻛﻪ ﺗﻘﺮﻳﺒﺎ ﻫﻴﭻ ﭘﻴﺎده ﺳﺎزي ﻫﺮﮔﺰ ﻫﻤﻪ ﭼﻴﺰ را ﭘﻴﺎده ﺳﺎزي ﻧﻤﻲ ﻛﻨﺪ، ﻃﺒﻴﻌﺖ HTTP 1.1 ﻣﻴﺰان زﻳﺎدي‬ ﺟﺰﺋﻴﺎت رﻳﺰ و ﮔﺰﻳﻨﻪ ﻫﺎﻳﻲ دارد ﻛﻪ ﺑﺮاي ﺑﺴﻂ ﻫﺎي ﺑﻌﺪي در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪه اﻧﺪ-و ﺣﺘﻲ اﻣﻜﺎن ﮔﻔﺘﻦ اﻳﻦ ﻛﻪ دﻗﻴﻘﺎ "ﻫﺮ‬ ﭼﻴﺰ" ﭼﻴﺴﺖ، اﻣﻜﺎن ﭘﺬﻳﺮ ﻧﻴﺴﺖ. اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻨﺠﺮ ﺑﻪ ﻣﻮﻗﻌﻴﺘﻲ ﺷﺪه اﺳﺖ ﻛﻪ وﻳﮋﮔﻲ ﻫﺎﻳﻲ ﻛﻪ در اﺑﺘﺪا اﺳﺘﻔﺎده ﻛﻤﻲ‬ داﺷﺘﻪ اﻧﺪ، ﺷﺎﻫﺪ ﭘﻴﺎده ﺳﺎزي ﻫﺎي ﺧﻴﻠﻲ ﻛﻤﻲ ﺑﻮده اﻧﺪ و آﻧﻬﺎﻳﻲ ﻛﻪ وﻳﮋﮔﻲ ﻫﺎ را ﭘﻴﺎده ﺳﺎزي ﻛﺮده اﻧﺪ، اﺳﺘﻔﺎده ﻛﻤﻲ از‬ آﻧﻬﺎ را ﻣﺸﺎﻫﺪه ﻛﺮده اﻧﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ در اداﻣﻪ، زﻣﺎﻧﻲ ﻛﻪ ﻣﺸﺘﺮﻳﺎن و ﺳﺮورﻫﺎ ﺷﺮوع ﺑﻪ اﻓﺰاﻳﺶ اﺳﺘﻔﺎده از ﭼﻨﻴﻦ وﻳﮋﮔﻲ‬ ﻫﺎﻳﻲ ﻛﺮده اﻧﺪ، ﻣﻨﺠﺮ ﺑﻪ ﻣﺸﻜﻞ ﻗﺎﺑﻠﻴﺖ ﻫﻤﻜﺎري می ﺷﻮد. ﺧﻂ ﻟﻮﻟﻪ ی HTTP‬ ﻳک ﻣﺜﺎل اوﻟﻴﻪ از ﭼﻨﻴﻦ وﻳﮋگی اﺳﺖ.‬‬‬‬‬‬‬‬‬

اﺳﺘﻔﺎده ﻧﺎﻛﺎﻓﻲ از TCP

HTTP 1.1 در اﺳﺘﻔﺎده ﻛﺎﻣﻞ از ﻣﺰاﻳﺎي ﻫﻤﻪ ي ﺗﻮاﻧﻤﻨﺪي ﻫﺎ و ﻛﺎراﻳﻲ ﻛﻪ TCP‬ اراﺋﻪ ﻣﻲ ﻛﻨﺪ، دﭼﺎر ﻣﺸﻜﻞ ﺷﺪه اﺳﺖ.‬ ﻣﺸﺘﺮﻳﺎن HTTP‬ و ﻣﺮورﮔﺮﻫﺎ ﺑﺎﻳﺪ ﺑﺮاي ﻳﺎﻓﺘﻦ راه ﺣﻞ ﻫﺎﻳﻲ ﻛﻪ زﻣﺎن ﺑﺎرﮔﺬاري ﺻﻔﺤﻪ را ﻛﺎﻫﺶ ﻣﻲ دﻫﻨﺪ، ﺧﻴﻠﻲ ﺧﻼﻗﺎﻧﻪ‬ ﺑﺎﺷﻨﺪ.‬‬‬‬‬‬‬ ﺳﺎﻳﺮ ﺗﻼش ﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﻃﻮر ﻣﻮازي در ﻃﻮل ﺳﺎﻟﻴﺎن ﻣﺘﻤﺎدي اﻧﺠﺎم ﺷﺪه اﻧﺪ ﻧﻴﺰ ﺗﺎﻳﻴﺪ ﻛﺮده اﻧﺪ ﻛﻪ ﺟﺎﻳﮕﺰﻳﻨﻲ TCP‬ آﺳﺎن‬ ﻧﻴﺴﺖ و ﺑﻨﺎﺑﺮاﻳﻦ ﺑﺮ ﺑﻬﺒﻮد TCP‬ و ﭘﺮوﺗﻜﻞ ﻫﺎي ﻣﻮﺟﻮد ﺑﺮ روي آن ﻛﺎر ﻣﻲ ﻛﻨﻴﻢ.‬‬‬‬‬ TCP‬ را ﻣﻲ ﺗﻮان ﺑﻪ ﺳﺎدﮔﻲ ﺑﺮاي اﺟﺘﻨﺎب از ﻣﻜﺚ ﻫﺎ ﻳﺎ ﻟﺤﻈﺎﺗﻲ ﻛﻪ ﺑﺮاي ارﺳﺎل ﻳﺎ درﻳﺎﻓﺖ داده ي زﻳﺎد وﺟﻮد دارﻧﺪ، ﻣﻮرد‬ ﺑﻬﺮه ﺑﺮداري ﻗﺮار داد. ﺑﺨﺶ ﻫﺎي ﺑﻌﺪي ﺑﺮﺧﻲ از اﻳﻦ ﻣﻌﺎﻳﺐ را ﺑﺮﺟﺴﺘﻪ ﺧﻮاﻫﻨﺪ ﺳﺎﺧﺖ.‬‬‬‬

اﻧﺪازه ﻫﺎی اﻧﺘﻘﺎل و ﺗﻌﺪاد اﺷﻴﺎ

زﻣﺎﻧﻲ ﻛﻪ ﺑﻪ روﻧﺪ ﺑﺮﺧﻲ از ﻣﻌﺮوف ﺗﺮﻳﻦ ﺳﺎﻳﺖ ﻫﺎ ﺑﺮ وب ﻧﮕﺎه ﻣﻲ ﻛﻨﻴﻢ و داﻧﻠﻮد ﺻﻔﺤﺎت آﻧﻬﺎ ﭼﻘﺪر ﻃﻮل ﻣﻲ ﻛﺸﺪ، ﺷﻜﻲ‬ در ﻣﻮرد روﻧﺪﻫﺎ وﺟﻮد ﻧﺪارد. در ﭼﻨﺪ ﺳﺎل ﮔﺬﺷﺘﻪ، ﻣﻴﺰان داده اي ﻛﻪ ﺑﺎﻳﺪ ﺑﺎزﻳﺎﺑﻲ ﺷﻮد، ﺑﻪ ﺗﺪرﻳﺞ ﺗﺎ ﺑﺎﻻي 1.9MB ‬‬اﻓﺰاﻳﺶ ﻳﺎﻓﺘﻪ اﺳﺖ، اﻣﺎ ﭼﻴﺰي ﻛﻪ ﺑﺮاي ﻣﺎ در اﻳﻦ زﻣﻴﻨﻪ ﻣﻬﻢ اﺳﺖ، اﻳﻦ ‬ اﺳﺖ. ﻛﻪ ﺗﻌﺪاد اﺷﻴﺎ ﺑﻪ ﻃﻮر ﻣﻴﺎﻧﮕﻴﻦ ﺻﺪ ﺷﻲ اﺳﺖ، ﺻﺪ ﺷﻲ ﺑﺎﻳﺪ ﺑﺮاي ﻧﻤﺎﻳﺶ ﺻﻔﺤﻪ ﻛﺎﻣﻞ ﺑﺎزﻳﺎﺑﻲ ﺷﻮﻧﺪ.‬‬‬‬‬ ﻫﻤﺎﻧﻄﻮر ﻛﻪ ﻧﻤﻮدار زﻳﺮ ﻧﺸﺎن ﻣﻲ دﻫﺪ، روﻧﺪ ﺑﺮاي ﻣﺪﺗﻲ اداﻣﻪ ﻳﺎﻓﺘﻪ اﺳﺖ و ﻫﻴﭻ ﻧﺸﺎﻧﻪ اي وﺟﻮد ﻧﺪارد ﻛﻪ ﺑﻪ زودي ﺗﻐﻴﻴﺮ ‬ﻛﻨﺪ. ﻧﻤﻮدار رﺷﺪ اﻧﺪازه ي اﻧﺘﻘﺎل ﻛﻞ (ﺑﻪ رﻧﮓ ﺳﺒﺰ) و ﺗﻌﺪاد ﻛﻠﻲ درﺧﻮاﺳﺖ ﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﻃﻮر ﻣﻴﺎﻧﮕﻴﻦ اﺳﺘﻔﺎده ﺷﺪه اﻧﺪ‬ (ﺑﻪ رﻧﮓ ﻗﺮﻣﺰ) ﺑﺮاي ﻣﻌﺮوف ﺗﺮﻳﻦ وﺑﺴﺎﻳﺖ ﻫﺎ در دﻧﻴﺎ و ﭼﮕﻮﻧﮕﻲ ﺗﻐﻴﻴﺮ آﻧﻬﺎ در ﻃﻲ 4 ﺳﺎل ﮔﺬﺷﺘﻪ را ﻧﺸﺎن ﻣﻲ دﻫﺪ.‬‬‬

ﺗﺎﺧﻴﺮ ﻛﺸﻨﺪه اﺳﺖ

HTTP 1.1‬ ﻧﺴﺒﺖ ﺑﻪ ﺗﺎﺧﻴﺮ ﺧﻴﻠﻲ ﺣﺴﺎس اﺳﺖ ﻛﻪ ﺑﺨﺸﻲ از اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﻪ اﻳﻦ دﻟﻴﻞ اﺳﺖ ﻛﻪ ﺧﻂ ﻟﻮﻟﻪ ی HTTP ﻣﺸﻜﻼت زﻳﺎدي دارد ﻛﻪ ﻣﻨﺠﺮ ﻣﻲ ﺷﻮد ﻛﻪ ﺑﺮاي درﺻﺪ ﺑﺰرﮔﻲ از ﻛﺎرﺑﺮان ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻧﮕﻴﺮد.‬‬‬‬‬ در ﺣﺎﻟﻲ ﻛﻪ اﻓﺰاﻳﺶ زﻳﺎدي را در ﭘﻬﻨﺎي ﺑﺎﻧﺪ ﻓﺮاﻫﻢ ﺷﺪه ﺑﺮاي اﻓﺮاد در ﻃﻲ ﭼﻨﺪ ﺳﺎل اﺧﻴﺮ ﻣﺸﺎﻫﺪه ﻛﺮده اﻳﻢ، ﺳﻄﺢ‬ ﻳﻜﺴﺎﻧﻲ از ﺑﻬﺒﻮد را در ﻛﺎﻫﺶ ﺗﺎﺧﻴﺮ ﻣﺸﺎﻫﺪه ﻧﻜﺮده اﻳﻢ. ﻟﻴﻨﻚ ﻫﺎي ﺑﺎ ﺗﺎﺧﻴﺮ ﺑﺎﻻ ﻧﻈﻴﺮ ﺑﺴﻴﺎري از ﺗﻜﻨﻮﻟﻮژي ﻫﺎي ﺳﻴﺎر‬ ﻓﻌﻠﻲ، داﺷﺘﻦ ﺗﺠﺮﺑﻪ ي وب ﺧﻮب و ﺳﺮﻳﻊ را ﺣﺘﻲ در ﺻﻮرﺗﻲ ﻛﻪ اﺗﺼﺎل اﻳﻨﺘﺮﻧﺖ ﺑﺎ ﺳﺮﻋﺖ واﻗﻌﺎ ﺑﺎﻻﻳﻲ داﺷﺘﻪ ﺑﺎﺷﻴﺪ،‬ دﺷﻮار ﻣﻲ ﺳﺎزد.‬‬‬‬‬ ﻣﻄﺎﻟﻌﻪ ﻣﻮردي دﻳﮕﺮي ﻛﻪ واﻗﻌﺎ ﻧﻴﺎز ﺑﻪ ﺗﺎﺧﻴﺮ ﭘﺎﻳﻴﻦ دارد، اﻧﻮاع ﺧﺎﺻﻲ از وﻳﺪﺋﻮ، ﻧﻈﻴﺮ وﻳﺪﺋﻮ ﻛﻨﻔﺮاﻧﺲ، ﺑﺎزي ﻳﺎ ﻣﺸﺎﺑﻪ آن‬ اﺳﺖ ﻛﻪ ﻓﻘﻂ ﻳﻚ ﺟﻮﻳﺒﺎي از ﻗﺒﻞ ﺗﻮﻟﻴﺪ ﺷﺪه ﺑﺮاي ارﺳﺎل وﺟﻮد ﻧﺪارد.‬‬‬

زﻣﺎن ﺑﺎرﮔﺬاري ﺻﻔﺤﻪ ﺑﺎ ﻛﺎﻫﺶ RTT‬‬‬‬

ﻧﻤﻮدار1:RTT‬ زﻣﺎن ﺳﻔﺮ دوﺳﺮه ﺑﺮ زﻣﺎن ﺑﺎرﮔﺬاري ﺻﻔﺤﻪ ﺗﺎﺛﻴﺮ ﻣﻲ ﮔﺬارد

ﺑﺴﺘﻪ ﺷﺪن اول ﺧﻂ

ﺧﻂ ﻟﻮﻟﻪ ي HTTP‬ روﺷﻲ ﺑﺮاي ارﺳﺎل درﺧﻮاﺳﺖ دﻳﮕﺮ، در ﺣﺎﻟﻲ ﻛﻪ ﻣﻨﺘﻈﺮ ﭘﺎﺳﺦ از درﺧﻮاﺳﺖ ﻗﺒﻠﻲ ﻣﻲ ﺑﺎﺷﻴﻢ، اﺳﺖ.‬ اﻳﻦ ﻣﺴﺎﻟﻪ ﺧﻴﻠﻲ ﻣﺸﺎﺑﻪ ﺑﺎ وارد ﺷﺪن ﺑﻪ ﺻﻒ ﻳﻚ ﭘﻴﺸﺨﻮان در ﻳﻚ ﺳﻮﭘﺮﻣﺎرﻛﺖ ﻳﺎ در ﻳﻚ ﺑﺎﻧﻚ اﺳﺖ. ﺷﻤﺎ ﻧﻤﻲ داﻧﻴﺪ ﻛﻪ‬ آﻳﺎ ﻣﺸﺘﺮي ﻛﻪ ﺟﻠﻮ ﺷﻤﺎ اﺳﺖ، ﻛﺎرش ﺳﺮﻳﻊ راه ﻣﻲ اﻓﺘﺪ ﻳﺎ ﺷﻤﺎ را ﻣﺪت زﻳﺎدي ﻣﻌﻄﻞ ﻣﻲ ﻛﻨﺪ: ﺑﻼك ﻛﺮدن ﺳﺮ ﺻﻒ.‬‬‬‬‬

اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ ﻛﻪ در ﻣﻮرد اﻧﺘﺨﺎب ﻋﻨﺼﺮ در ﺻﻒ دﻗﺖ دارﻳﺪ، ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﻣﻮردي را اﻧﺘﺨﺎب ﻛﻨﻴﺪ ﻛﻪ واﻗﻌﺎ‬ ﻋﻘﻴﺪه دارﻳﺪ ﻛﻪ ﻋﻨﺼﺮ درﺳﺘﻲ اﺳﺖ و ﺣﺘﻲ ﮔﺎﻫﻲ اوﻗﺎت ﺧﻂ ﺟﺪﻳﺪ ﺧﻮد را اﻳﺠﺎد ﻛﻨﻴﺪ اﻣﺎ در اﻧﺘﻬﺎ ﻧﻤﻲ ﺗﻮاﻧﻴﺪ از ﻳﻚ‬ ﺗﺼﻤﻴﻢ ﮔﻴﺮي اﺟﺘﻨﺎب ﻛﻨﻴﺪ و وﻗﺘﻲ ﻛﻪ ﺗﺼﻤﻴﻢ ﮔﻴﺮي اﻧﺠﺎم ﺷﺪ، ﻧﻤﻲ ﺗﻮاﻧﻴﺪ ﺧﻂ ﺧﻮد را ﻋﻮض ﻛﻨﻴﺪ.‬‬‬‬ اﻳﺠﺎد ﻳﻚ ﺧﻂ ﺟﺪﻳﺪ ﻣﺮﺗﺒﻂ ﺑﺎ ﻳﻚ ﺟﺮﻳﻤﻪ ي ﻛﺎراﻳﻲ و ﻣﻨﺒﻊ اﺳﺖ ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ از ﺗﻌﺪاد ﻛﻤﻲ ﺧﻂ ﺑﻴﺸﺘﺮ ﻣﻘﻴﺎس ﭘﺬﻳﺮ‬ ﻧﻴﺴﺖ. ﻫﻴﭻ راه ﺣﻞ ﻛﺎﻣﻠﻲ ﺑﺮاي اﻳﻦ ﻣﺴﺎﻟﻪ وﺟﻮد ﻧﺪارد.‬‬‬ ﺣﺘﻲ اﻣﺮوز، ﺳﺎل 2015، ﺑﻴﺸﺘﺮ ﻣﺮورﮔﺮﻫﺎي وب روﻣﻴﺰي، ﺑﻪ ﻃﻮر ﭘﻴﺸﻔﺮض ﺑﺪون ﻓﻌﺎل ﺑﻮدن ﺧﻂ ﻟﻮﻟﻪ ي HTTP‬ اراﺋﻪ‬ ﻣﻲ ﺷﻮﻧﺪ.‬‬‬‬ ﻣﻄﺎﻟﻌﺎت ﺑﻴﺸﺘﺮ در ارﺗﺒﺎط ﺑﺎ اﻳﻦ ﻣﻮﺿﻮع را ﻣﻲ ﺗﻮان ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل در ورودي ﺑﺎ موزﻳﻼ ﻓﺎﻳﺮﻓﺎﻛﺲ 26.4 ﻳﺎﻓﺖ.‬‬

اﻗﺪاﻣﺎﺗﻲ ﻛﻪ ﻣﻲ ﺗﻮان ﺑﺮاي ﻏﻠﺒﻪ ﺑﺮ ﻣﺸﻜﻞ ﺗﺎﺧﻴﺮ اﻧﺠﺎم داد‬‬

Spriting

Spriting‬ ﻋﺒﺎرﺗﻲ اﺳﺖ ﻛﻪ اﻏﻠﺐ ﺑﺮاي ﺷﺮح زﻣﺎﻧﻲ ﻛﻪ ﺗﺼﺎوﻳﺮ ﻛﻮﭼﻚ زﻳﺎدي را ﺑﺎ ﻫﻢ در ﻳﻚ ﺗﺼﻮﻳﺮ ﺑﺰرگ ﻣﻨﺤﺼﺮ ﺑﻪ‬ ﻓﺮد ﻗﺮار ﻣﻲ دﻫﻴﺪ، اﺳﺘﻔﺎده ﻣﻲ ﺷﻮد. ﺳﭙﺲ از ﺟﺎوااﺳﻜﺮﻳﭙﺖ ﻳﺎ CSS‬ ﺑﺮاي ﺑﺮش ﻗﻄﻌﺎت ﺗﺼﻮﻳﺮ ﺑﺰرگ ﺑﺮاي ﻧﻤﺎﻳﺶ ﺗﺼﺎوﻳﺮ ﻛﻮﭼﻜﺘﺮ ﻣﺠﺰا اﺳﺘﻔﺎده ﻣﻲ ﺷﻮد.‬‬‬‬‬‬ ﺳﺎﻳﺖ ﻫﺎ ﻣﻲ ﺗﻮاﻧﻨﺪ از اﻳﻦ روش ﺑﺮاي اﻓﺰاﻳﺶ ﺳﺮﻋﺖ اﺳﺘﻔﺎده ﻛﻨﻨﺪ. ﺑﺪﺳﺖ آوردن ﻳﻚ ﺗﺼﻮﻳﺮ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﺑﺰرگ در‬ HTTP 1.1 ﺧﻴﻠﻲ ﺳﺮﻳﻌﺘﺮ از ﺑﺪﺳﺖ آوردن ﺻﺪ ﺗﺼﻮﻳﺮ ﻣﺠﺰاي ﻛﻮﭼﻜﺘﺮ اﺳﺖ.‬‬‬‬ اﻟﺒﺘﻪ اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻌﺎﻳﺒﻲ ﺑﺮاي ﺗﺼﺎوﻳﺮ ﺳﺎﻳﺖ ﻛﻪ ﻓﻘﻂ ﻣﻲ ﺧﻮاﻫﻨﺪ از ﻳﻚ ﻳﺎ دو ﺗﺼﻮﻳﺮ ﻛﻮﭼﻚ و ﻣﺸﺎﺑﻪ اﺳﺘﻔﺎده ﻛﻨﻨﺪ،‬ ﻣﻌﺎﻳﺒﻲ دارد و ﺑﺎﻋﺚ ﻣﻲ ﺷﻮد ﻛﻪ ﻫﻤﻪ ي ﺗﺼﺎوﻳﺮ ﻫﻤﺰﻣﺎن از ﻛﺶ ﺧﺎرج ﺷﻮﻧﺪ، ﺑﻪ ﺟﺎي اﻳﻦ ﻛﻪ ﺗﺼﺎوﻳﺮي ﻛﻪ ﺑﻪ ﻃﻮر‬ ﻣﻌﻤﻮل اﺳﺘﻔﺎده ﻣﻲ ﺷﻮﻧﺪ را در ﻛﺶ ﺑﺎﻗﻲ ﺑﮕﺬارد.‬‬‬‬

inlining

Inlining‬ روش دﻳﮕﺮي اﺳﺖ ﻛﻪ از ارﺳﺎل ﺗﺼﺎوﻳﺮ ﻣﺠﺰا اﺟﺘﻨﺎب ﻣﻲ ﻛﻨﺪ و اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﻪ ﺟﺎي اﺳﺘﻔﺎده از داده اﻧﺠﺎم ﻣﻲ‬ ﺷﻮد: URL‬ﻫﺎي ﻣﻮﺟﻮد در ﻓﺎﻳﻞ .CSS اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﺰاﻳﺎ و ﻣﻌﺎﻳﺐ ﻣﺸﺎﺑﻬﻲ ﻧﻈﻴﺮ ﻣﻮرد spriting‬ دارد.‬‬‬‬‬‬‬

concatingation

ﻣﺸﺎﺑﻪ ﺑﺎ دو روش ﻗﺒﻠﻲ، اﻣﺮوزه ﻳﻚ ﺳﺎﻳﺖ ﺑﺰرگ ﻣﻲ ﺗﻮاﻧﺪ ﻓﺎﻳﻞ ﻫﺎي ﺟﺎوااﺳﻜﺮﻳﭙﺖ ﻣﺘﻔﺎوﺗﻲ داﺷﺘﻪ ﺑﺎﺷﺪ. اﺑﺰارﻫﺎي‬ ﻗﺴﻤﺖ- ﺟﻠﻮﻳﻲ ﺑﻪ ﺗﻮﺳﻌﻪ دﻫﻨﺪﮔﺎن اﻣﻜﺎن ﻳﻜﭙﺎرﭼﻪ ﺳﺎزي آﻧﻬﺎ را در ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺑﺰرگ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻣﻲ دﻫﻨﺪ ﺑﻪ ﮔﻮﻧﻪ‬ اي ﻛﻪ ﻣﺮورﮔﺮ ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺑﺰرگ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﺑﻪ ﺟﺎي ده ﻫﺎ ﻓﺎﻳﻞ ﻛﻮﭼﻜﺘﺮ ﻣﻲ ﮔﻴﺮد. ﻣﻴﺰان داده ي زﻳﺎدي زﻣﺎﻧﻲ ﻛﻪ‬ ﻓﻘﻂ اﻃﻼﻋﺎت ﻛﻤﻲ ﻣﻮرد ﻧﻴﺎز اﺳﺖ، ارﺳﺎل ﻣﻲ ﺷﻮد. داده ي زﻳﺎد زﻣﺎﻧﻲ ﻛﻪ ﻳﻚ ﺗﻐﻴﻴﺮ ﻣﻮرد ﻧﻴﺎز اﺳﺖ، ﻣﺠﺪدا ﺑﺎرﮔﺬاري‬ ﻣﻲ ﺷﻮد.‬‬‬‬‬

sharding

روش ﻧﻬﺎﻳﻲ ﻛﻪ ذﻛﺮ ﻣﻲ ﻛﻨﻢ اﻳﻦ اﺳﺖ ﻛﻪ ﻋﻤﻠﻜﺮد ﺑﻬﺘﺮ ﻣﺎﻟﻜﺎن ﺳﺎﻳﺖ در ﻣﺮورﮔﺮﻫﺎ اﻏﻠﺐ ﺗﺤﺖ ﻋﻨﻮان "sharding‬" در‬ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﻮد ﻛﻪ اﺳﺎﺳﺎ ﺑﻪ ﻣﻌﻨﻲ ﮔﺴﺘﺮش ﺳﺮوﻳﺲ ﻫﺎي ﺧﻮد ﺑﺮ ﺣﺪاﻛﺜﺮ ﻣﻴﺰﺑﺎن ﻫﺎي ﻣﻤﻜﻦ اﺳﺖ. ﮔﺮﭼﻪ در اﺑﺘﺪا اﺣﻤﻘﺎﻧﻪ ﺑﻨﻈﺮ ﻣﻲ رﺳﺪ، اﻣﺎ ﻳﻚ دﻟﻴﻞ ﺳﺎده وﺟﻮد دارد!‬‬‬‬‬ ﻣﺸﺨﺼﺎت HTTP 1.1 در اﺑﺘﺪا ﺑﻴﺎن ﻣﻲ ﻛﺮد ﻛﻪ ﻳﻚ ﻣﺸﺘﺮي ﻣﺠﺎز ﺑﻪ اﺳﺘﻔﺎده از ﺣﺪاﻛﺜﺮ دو اﺗﺼﺎل 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 ﺷﻜﻞ ﮔﺮﻓﺘﻪ ﺷﺪ و ﺑﺮوزرﺳﺎﻧﻲ ﻣﺸﺨﺼﺎت HTTP 1.1 ﺑﻪ آن‬ اﺧﺘﺼﺎص داده ﺷﺪ-ﺑﻨﺎﺑﺮاﻳﻦ ﺑﺨﺶ 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‬ ﺑﻪ ﺟﺎي ﭘﺮوﺗﻜﻞ ﻫﺎي‬ ﻗﺪﻳﻤﻲ ﺗﺮ اﺳﺘﻔﺎده ﻛﻨﺪ.‬‬‬‬‬‬‬‬‬‬ HTTP 1.1روﺷﻲ ﺗﻌﺮﻳﻒ ﺷﺪه ﺑﺮاي اﻧﺠﺎم اﻳﻦ ﻛﺎر دارد، ﻣﺜﻼ ارﺗﻘﺎ: ﺳﺮآﻳﻨﺪ ﺑﻪ ﺳﺮور اﻣﻜﺎن ارﺳﺎل ﭘﺎﺳﺦ ﻫﺎ ﺑﺎ اﺳﺘﻔﺎده از‬ ﭘﺮوﺗﻜﻞ ﺟﺪﻳﺪ، زﻣﺎﻧﻲ ﻛﻪ ﭼﻨﻴﻦ درﺧﻮاﺳﺘﻲ را ﺑﺮ ﭘﺮوﺗﻜﻞ ﻗﺪﻳﻤﻲ درﻳﺎﻓﺖ ﻣﻲ ﻛﻨﺪ، ﻣﻲ دﻫﺪ. ﻫﺰﻳﻨﻪ اﻳﻦ ﻛﺎر ﻳﻚ ﺳﻔﺮ رﻓﺖ‬ و ﺑﺮﮔﺸﺖ اﺳﺖ.‬‬‬‬‬ اﻳﻦ ﺟﺮﻳﻤﻪ ي رﻓﺖ و ﺑﺮﮔﺸﺖ ﭼﻴﺰي ﻧﻴﺴﺖ ﻛﻪ ﺗﻴﻢ SPDY‬ ﻗﺒﻮل ﻛﻨﺪ و ﭼﻮن ﻓﻘﻂ SPDY‬ را ﺑﺮ TLS‬ ﭘﻴﺎده ﺳﺎزي ﻛﺮدﻧﺪ،‬ ﻳﻚ ﺑﺴﻂ TLS‬ ﺟﺪﻳﺪ را ﺗﻮﺳﻌﻪ دادﻧﺪ ﻛﻪ ﺑﺮاي ﻣﻴﺎن ﺑﺮ ﻛﺮدن ﻣﺬاﻛﺮات ﻛﺎﻣﻼ ﻣﻮﺛﺮ ﺑﻮد. ﺑﺎ اﺳﺘﻔﺎده از اﻳﻦ ﺑﺴﻂ ﻛﻪ NPN (ﻣﺬاﻛﺮات ﭘﺮوﺗﻜﻞ ﺑﻌﺪي) ﻧﺎﻣﻴﺪه ﻣﻲ ﺷﻮد، ﺳﺮور ﺑﻪ ﻣﺸﺘﺮي ﻣﻲ ﮔﻮﻳﺪ ﻛﻪ ﻛﺪام ﭘﺮوﺗﻜﻞ ﻫﺎ را ﻣﻲ ﺷﻨﺎﻧﺪ و ﻣﺸﺘﺮي ﻣﻲ‬ ﺗﻮاﻧﺪ ﭘﻴﺶ ﺑﺮود و از ﭘﺮوﺗﻜﻠﻲ ﻛﻪ ﺑﺮاﻳﺶ اوﻟﻮﻳﺖ دارد اﺳﺘﻔﺎده ﻛﻨﺪ.‬‬‬‬‬‬‬‬‬‬

HTTP2‬ ﺑﺮاي //: https

ﺗﻤﺮﻛﺰ زﻳﺎدHTTP2‬ ﺑﺮاي رﻓﺘﺎر ﻣﻮﺛﺮ ﺑﺮ TLS‬اﻧﺠﺎم ﺷﺪه اﺳﺖ. SPDY‬ ﻓﻘﻂ ﺑﺮ TLS‬ اﻧﺠﺎم ﻣﻲ ﺷﻮد و ﻧﻴﺎز ﻗﻮي ﺑﺮاي‬ اﺟﺒﺎري ﺳﺎﺧﺘﻦ TLS‬ﺑﺮاي HTTP‬ وﺟﻮد دارد اﻣﺎ ﺗﻮاﻓﻖ اﻳﺠﺎد ﻧﺸﺪه اﺳﺖ و HTTP2‬ ﺑﺎ TLS‬ ﺑﻪ ﺷﻜﻞ اﺧﺘﻴﺎري اراﺋﻪ‬ ﺧﻮاﻫﺪ ﺷﺪ. اﻣﺎ دو ﭘﻴﺎده ﺳﺎزي ﺑﺮﺗﺮ ﺑﻪ وﺿﻮح اراﺋﻪ ﺷﺪه اﻧﺪ ﻛﻪ ﻓﻘﻂ ﺑﻪ ﭘﻴﺎده ﺳﺎزي HTTP2‬ ﺑﺮ TLS‬ ﻣﻲ ﭘﺮدازﻧﺪ : ﻣﻮزﻳﻼ‬ ﻓﺎﻳﺮﻓﺎﻛﺲ lead‬ و ﮔﻮﮔﻞ ﻛﺮوم .lead‬ اﻳﻦ دو ﻣﺮورﮔﺮ، ﻣﺮورﮔﺮﻫﺎي ﭘﻴﺸﺮو اﻣﺮوزي ﻫﺴﺘﻨﺪ.‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬ دﻻﻳﻞ اﻧﺘﺨﺎب TLS‬ ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﺷﺎﻣﻞ اﺣﺘﺮام ﺑﻪ ﻣﺤﺮﻣﺎﻧﮕﻲ ﻛﺎرﺑﺮ و اﻧﺪازه ﮔﻴﺮي ﻫﺎي اوﻟﻴﻪ اﺳﺖ ﻛﻪ ﻧﺸﺎن ﻣﻲ دﻫﻨﺪ ﻛﻪ‬ ﭘﺮوﺗﻜﻞ ﻫﺎي ﺟﺪﻳﺪ ﻧﺮخ ﻣﻮﻓﻘﻴﺖ ﺑﺎﻻﺗﺮي زﻣﺎﻧﻲ ﻛﻪ ﺑﺎ TLS‬ اﻧﺠﺎم ﻣﻲ ﺷﻮﻧﺪ، دارﻧﺪ. اﻳﻦ اﻣﺮ ﺑﻪ دﻟﻴﻞ اﻳﻦ ﻓﺮض ﮔﺴﺘﺮده‬ اﺳﺖ ﻛﻪ ﻫﺮ اﺗﻔﺎﻗﻲ ﻛﻪ ﺑﺮ ﭘﻮرت 80 رخ ﻣﻲ دﻫﺪ از ﻃﺮﻳﻖ HTTP 1.1 اﺳﺖ ﻛﻪ ﻣﻮﺟﺐ ﺑﺮﺧﻲ ﻣﺪاﺧﻠﻪ ﻫﺎي 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‬ دودوﻳﻲ اﺳﺖ. ﻣﺸﺨﺺ ﻛﺮدن زﻣﺎن ﺷﺮوع و اﻧﺘﻬﺎي ﻓﺮﻳﻢ ﻫﺎ ﻳﻜﻲ از ﭼﻴﺰﻫﺎي‬ واﻗﻌﺎ ﭘﻴﭽﻴﺪه در HTTP 1.1 و ﺑﻪ ﻃﻮر ﻛﻠﻲ در ﭘﺮوﺗﻜﻞ ﻫﺎي ﻣﺒﺘﻨﻲ ﺑﺮ ﻣﺘﻦ اﺳﺖ. ﺑﺎ دور ﺷﺪن از ﻓﻀﺎﻫﺎي ﺳﻔﻴﺪ اﺧﺘﻴﺎري‬ و راه ﻫﺎي ﻣﺨﺘﻠﻒ ﻧﻮﺷﺘﻦ ﻳﻚ ﭼﻴﺰ ﻳﻜﺴﺎن، ﭘﻴﺎده ﺳﺎز ﻫﺎ آﺳﺎﻧﺘﺮ ﻣﻲ ﺷﻮد.‬‬‬‬‬‬ ﻫﻤﭽﻨﻴﻦ ﺟﺪاﺳﺎزي ﺑﺨﺶ ﻫﺎي ﭘﺮوﺗﻜﻞ واﻗﻌﻲ از framing‬ آﺳﺎﻧﺘﺮ اﺳﺖ ﻛﻪ در HTTP1‬ ﺑﻪ ﻃﻮر ﮔﻴﺞ ﻛﻨﻨﺪه اي ﺑﻪ ﻫﻢ‬ آﻣﻴﺨﺘﻪ ﺷﺪه اﻧﺪ.‬‬‬‬‬ واﻗﻌﻴﺎت ﻓﺸﺮده ﺳﺎزي وﻳﮋﮔﻲ ﻫﺎي ﭘﺮوﺗﻜﻞ و اﺟﺮاي آﻧﻬﺎ ﺑﺮ TLS‬ﻣﻨﺠﺮ ﺑﻪ ﻛﺎﻫﺶ ارزش ﻣﺘﻦ ﻣﻲ ﺷﻮﻧﺪ ﭼﻮن دﻳﮕﺮ ﻣﺘﻦ را‬ ﺑﺮ رﺳﺎﻧﻪ ﺳﻴﻤﻲ ﻣﺸﺎﻫﺪه ﻧﻤﻲ ﻛﻨﻴﺪ. ﺑﻪ ﺳﺎدﮔﻲ ﺑﺎﻳﺪ ﺑﻪ اﻳﺪه ي ﻳﻚ ﺑﺮرﺳﻲ ﻛﻨﻨﺪه ي wireshark‬ ﻳﺎ ﻣﺸﺎﺑﻪ ﺑﺎ آن، ﺑﺮاي‬ ﻣﺸﺨﺺ ﻛﺮدن اﻳﻦ ﻛﻪ دﻗﻴﻘﺎ ﭼﻪ اﺗﻔﺎﻗﻲ در ﺳﻄﺢ ﭘﺮوﺗﻜﻞ در HTTP2‬ رخ ﻣﻲ دﻫﺪ، ﻋﺎدت ﻛﻨﻴﻢ.‬‬‬‬‬‬

دﻳﺒﺎگ اﻳﻦ ﭘﺮوﺗﻜﻞ اﺣﺘﻤﺎل ﺑﺎﻳﺪ ﺑﺎ اﺑﺰارﻫﺎﻳﻲ ﻧﻈﻴﺮ curl‬ﻳﺎ ﺑﺎ ﺗﺠﺰﻳﻪ و ﺗﺤﻠﻴﻞ ﺟﺮﻳﺎن ﺷﺒﻜﻪ ﺑﺎ ﺗﺸﺮح ﻛﻨﻨﺪه ي‬ wireshark HTTP2‬ و ﻣﺸﺎﺑﻪ آن اﻧﺠﺎم ﺷﻮد.‬‬‬‬‬

ﻓﺮﻣﺖ دودوﻳﻲ‬‬

HTTP2‬ ﻓﺮﻣﺖ ﻫﺎي دودوﻳﻲ را ارﺳﺎل ﻣﻲ ﻛﻨﺪ. اﻧﻮاع ﻓﺮﻳﻢ ﻫﺎي ﻣﺨﺘﻠﻔﻲ وﺟﻮد دارﻧﺪ ﻛﻪ ﻣﻲ ﺗﻮان ارﺳﺎل ﻛﺮد و ﺑﺎﻳﺪ ﻣﺮﺣﻠﻪ‬ ﻳﻜﺴﺎﻧﻲ داﺷﺘﻪ ﺑﺎﺷﻨﺪ:‬‬‬‬ ﻧﻮع، ﻃﻮل، ﻓﻠﮓ، ﺷﻨﺎﺳﻪ ﺟﺮﻳﺎن و ﺑﺎر ﻣﻔﻴﺪ ﻓﺮﻳﻢ.‬‬ ده ﻓﺮﻳﻢ ﻣﺨﺘﻠﻒ وﺟﻮد دارﻧﺪ ﻛﻪ در ﻣﺸﺨﺼﺎت HTTP2‬ ﺗﻌﺮﻳﻒ ﺷﺪه اﻧﺪ و دو ﻣﻮرد از آﻧﻬﺎ ﻛﻪ ﺷﺎﻳﺪ ﭘﺎﻳﻪ اي ﺗﺮﻳﻦ ﻣﻮارد‬ ﺑﺎﺷﻨﺪ ﻛﻪ ﺑﺎ وﻳﮋﮔﻲ ﻫﺎي HTTP 1.1‬ ﺗﻄﺎﺑﻖ دارﻧﺪ، DATA‬ و HEADERS‬ ﻫﺴﺘﻨﺪ. در اداﻣﻪ ﺑﻪ ﺷﺮح ﺑﺮﺧﻲ از ﻓﺮﻳﻢ ﻫﺎ ﺑﺎ‬ ﺟﺰﺋﻴﺎت ﺑﻴﺸﺘﺮ ﻣﻲ ﭘﺮدازﻳﻢ.‬‬‬‬‬‬‬‬

ﺟﺮﻳﺎن ﻫﺎي ﺗﺴﻬﻴﻢ ﺷﺪه‬‬

ﺷﻨﺎﺳﻪ ي ﺟﺮﻳﺎن ذﻛﺮ ﺷﺪه در ﺑﺨﺶ ﻗﺒﻠﻲ ﺑﻪ ﺷﺮح ﻓﺮﻣﺖ ﻓﺮﻳﻢ دودوﻳﻲ ﻣﻲ ﭘﺮدازد ﻛﻪ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮد ﻛﻪ ﻫﺮ ﻓﺮﻳﻤﻲ ﻛﻪ‬ ﺑﺮ HTTP2‬ ‬ارﺳﺎل ﺷﺪه اﺳﺖ ﺑﺎ ﻳﻚ ﺟﺮﻳﺎن ﻣﺮﺗﺒﻂ ﺷﻮد. ﺟﺮﻳﺎن ﻳﻚ ارﺗﺒﺎط ﻣﻨﻄﻘﻲ اﺳﺖ. ﻳﻚ دﻧﺒﺎﻟﻪ ي ﻣﺴﺘﻘﻞ، دو-ﺟﻬﺘﻪ‬ از ﻓﺮﻳﻢ ﻫﺎﻳﻲ ﻛﻪ ﺑﻴﻦ ﻣﺸﺘﺮي و ﺳﺮور در ﻳﻚ ارﺗﺒﺎط HTTP2‬ ‬ﻣﺒﺎدﻟﻪ ﺷﺪه اﻧﺪ.‬‬‬‬‬‬ ﻳﻚ اﺗﺼﺎل HTTP2‬ ‬ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻣﻲ ﺗﻮاﻧﺪ ﺣﺎوي ﭼﻨﺪﻳﻦ ﺟﺮﻳﺎن ﺑﺎز ﻫﻤﺮوﻧﺪ از ﻫﺮ ﻓﺮﻳﻢ ﻣﻴﺎن ﮔﺬاري ﻧﻘﻄﻪ اﻧﺘﻬﺎﻳﻲ از‬ ﭼﻨﺪﻳﻦ ﺟﺮﻳﺎن ﺑﺎﺷﺪ. ﺟﺮﻳﺎن ﻫﺎ را ﻣﻲ ﺗﻮان ﺑﻪ ﺷﻜﻞ ﻳﻚ ﻃﺮﻓﻪ ﻳﺎ اﺷﺘﺮاﻛﻲ ﺗﻮﺳﻂ ﻣﺸﺘﺮي و ﺳﺮور ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار داد و‬ ﻣﻲ ﺗﻮان ﺗﻮﺳﻂ ﻫﺮ ﻧﻘﻄﻪ اﻧﺘﻬﺎﻳﻲ ﺑﻪ اﺗﻤﺎم ﺑﺮﺳﻨﺪ. ﺗﺮﺗﻴﺒﻲ ﻛﻪ ﻓﺮﻳﻢ ﻫﺎ در ﻳﻚ ﺟﺮﻳﺎن ارﺳﺎل ﻣﻲ ﺷﻮﻧﺪ، ﻣﻬﻢ اﺳﺖ.‬ ﮔﻴﺮﻧﺪﮔﺎن ﻓﺮﻳﻢ ﻫﺎ را ﺑﻪ ﺗﺮﺗﻴﺒﻲ ﻛﻪ آﻧﻬﺎ را درﻳﺎﻓﺖ ﻣﻲ ﻛﻨﻨﺪ، ﭘﺮدازش ﻣﻲ ﻧﻤﺎﻳﻨﺪ.‬‬‬‬‬‬ ﺗﺴﻬﻴﻢ ﺟﺮﻳﺎن ﺑﺪﻳﻦ ﻣﻌﻨﻲ اﺳﺖ ﻛﻪ ﺑﺴﺘﻪ ﻫﺎ از ﺗﻌﺪاد زﻳﺎدي ﺟﺮﻳﺎن ﺑﺮ اﺗﺼﺎل ﻳﻜﺴﺎﻧﻲ ﺗﺮﻛﻴﺐ ﻣﻲ ﺷﻮﻧﺪ. دو (ﻳﺎ ﺑﻴﺸﺘﺮ) ﺟﺮﻳﺎن ﻣﺠﺰاي داده در ﻳﻚ ﺟﺮﻳﺎن ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻗﺮار ﻣﻲ ﮔﻴﺮﻧﺪ و ﺳﭙﺲ دوﺑﺎره در ﺳﻤﺖ دﻳﮕﺮ ﻣﺠﺰا ﻣﻲ ﺷﻮﻧﺪ. در اﻳﻨﺠﺎ‬ دو ﺟﺮﻳﺎن (ﻗﻄﺎر) وﺟﻮد دارﻧﺪ:‬‬‬‬

ﺑﻨﺎﺑﺮاﻳﻦ اﻳﻦ دو در اﺗﺼﺎل ﻳﻜﺴﺎﻧﻲ ﺑﻪ ﺷﻴﻮه اي ﺗﺴﻬﻴﻢ ﺷﺪه ﺗﺮﻛﻴﺐ ﻣﻲ ﺷﻮﻧﺪ:‬‬

در HTTP2‬ ‬ده ﻫﺎ و ﺻﺪﻫﺎ ﺟﺮﻳﺎن ﻫﻤﺰﻣﺎن ﻣﺸﺎﻫﺪه ﺧﻮاﻫﻴﻢ ﻛﺮد. ﻫﺰﻳﻨﻪ ي اﻳﺠﺎد ﻳﻚ ﺟﺮﻳﺎن ﺟﺪﻳﺪ ﺧﻴﻠﻲ ﭘﺎﻳﻴﻦ اﺳﺖ.‬‬‬

اوﻟﻮﻳﺖ ﻫﺎ و واﺑﺴﺘﮕﻲ ﻫﺎ‬

ﻫﺮ ﺟﺮﻳﺎن ﻳﻚ اوﻟﻮﻳﺖ دارد ﻛﻪ ﺑﺮاي اﻃﻼع رﺳﺎﻧﻲ ﺑﻪ ﻧﻈﻴﺮ ﻛﻪ ﻛﺪام ﺟﺮﻳﺎن را ﻣﻬﻤﺘﺮﻳﻦ ﺟﺮﻳﺎن در ﻧﻈﺮ ﺑﮕﻴﺮد، ﻣﻮرد‬ اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﻴﺮد.‬‬‬ ﺟﺰﺋﻴﺎت دﻗﻴﻖ در ﻣﻮرد اﻳﻦ ﻛﻪ ﭼﻄﻮر اوﻟﻮﻳﺖ ﻫﺎ در ﭘﺮوﺗﻜﻞ ﻫﺎ ﻋﻤﻞ ﻣﻲ ﻛﻨﻨﺪ ﭼﻨﺪﻳﻦ ﺑﺎر ﺗﻐﻴﻴﺮ ﻛﺮده اﻧﺪ و ﻫﻨﻮز ﻧﻴﺰ ﻣﻮرد‬ ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻗﺮار دارﻧﺪ. ﻧﻜﺘﻪ اﻳﻦ اﺳﺖ ﻛﻪ ﻣﺸﺘﺮي ﻣﻲ ﺗﻮاﻧﺪ ﻣﺸﺨﺺ ﻛﻨﺪ ﻛﻪ ﻛﺪام ﺟﺮﻳﺎن ﻫﺎ ﻣﻬﻤﺘﺮﻳﻦ ﻫﺴﺘﻨﺪ و ﻳﻚ ﭘﺎراﻣﺘﺮ واﺑﺴﺘﮕﻲ وﺟﻮد دارد، ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﻳﻚ ﺟﺮﻳﺎن را ﻣﻲ ﺗﻮان ﺑﻪ دﻳﮕﺮي واﺑﺴﺘﻪ ﺳﺎﺧﺖ.‬‬‬‬ اوﻟﻮﻳﺖ ﻫﺎ ﻣﻲ ﺗﻮاﻧﻨﺪ ﺑﻪ ﻃﻮر ﭘﻮﻳﺎ در زﻣﺎن اﺟﺮا ﺗﻐﻴﻴﺮ ﻛﻨﻨﺪ ﻛﻪ ﺑﺎﻳﺪ ﻣﺮورﮔﺮﻫﺎ را ﻗﺎدر ﺑﻪ ﺣﺼﻮل اﻃﻤﻴﻨﺎن از اﻳﻦ ﻣﺴﺎﻟﻪ‬ ﻛﻨﻨﺪ ﻛﻪ زﻣﺎﻧﻲ ﻛﻪ ﻛﺎرﺑﺮان ﻳﻚ ﺻﻔﺤﻪ ي ﭘﺮ از ﺗﺼﺎوﻳﺮ را ﺗﺎ ﭘﺎﻳﻴﻦ ﭘﻴﻤﺎﻳﺶ ﻣﻲ ﻛﻨﻨﺪ، ﻣﻲ ﺗﻮاﻧﺪ ﻣﺸﺨﺺ ﻛﻨﺪ ﻛﻪ ﻛﺪام‬ ﺗﺼﺎوﻳﺮ ﻣﻬﻤﺘﺮ ﻫﺴﺘﻨﺪ ﻳﺎ اﮔﺮ ﺗﺐ ﻫﺎ را ﺗﻐﻴﻴﺮ دﻫﻴﺪ، ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺟﺪﻳﺪ از ﺟﺮﻳﺎن ﻫﺎ را اوﻟﻮﻳﺖ ﺑﻨﺪي ﻣﻲ ﻛﻨﺪ ﻛﻪ ﻣﻮرد‬ ﺗﻤﺮﻛﺰ ﻗﺮار ﻣﻲ ﮔﻴﺮﻧﺪ.‬‬‬‬‬

ﻓﺸﺮده ﺳﺎزي ﺳﺮآﻳﻨﺪ

HTTP‬ ﻳﻚ ﭘﺮوﺗﻜﻞ ﺑﺪون ﺣﺎﻟﺖ اﺳﺖ. ﺑﻪ ﻃﻮر ﺧﻼﺻﻪ اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﺪﻳﻦ ﻣﻌﻨﻲ اﺳﺖ ﻛﻪ ﻫﺮ درﺧﻮاﺳﺖ ﺑﺎﻳﺪ ﺟﺰﺋﻴﺎت زﻳﺎدي‬ را اراﺋﻪ ﻛﻨﺪ ﻛﻪ ﺳﺮور ﺑﺮاي ﭘﺎﺳﺦ دﻫﻲ ﺑﻪ آن درﺧﻮاﺳﺖ ﻧﻴﺎز دارد و ﺳﺮور ﻣﺠﺒﻮر ﺑﻪ ﻧﮕﻬﺪاري اﻃﻼﻋﺎت و ﻓﺮا-داده زﻳﺎدي از‬درﺧﻮاﺳﺖ ﻫﺎي ﻗﺒﻠﻲ ﻧﺪارد. ﭼﻮن HTTP2‬ ‬ﻫﻴﭻ ﻳﻚ از اﻟﮕﻮواره ﻫﺎي اﻳﻨﭽﻨﻴﻨﻲ را ﺗﻐﻴﻴﺮ ﻧﻤﻲ دﻫﺪ، ﺑﺎﻳﺪ ﻫﻤﻴﻦ ﻛﺎر را‬ اﻧﺠﺎم دﻫﺪ.‬‬‬‬‬‬‬

اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻨﺠﺮ ﺑﻪ ﺗﻜﺮاري ﺷﺪن HTTP‬ ﻣﻲ ﺷﻮد. زﻣﺎﻧﻲ ﻛﻪ ﻳﻚ ﻣﺸﺘﺮي درﺧﻮاﺳﺖ ﻣﻨﺎﺑﻊ زﻳﺎدي از ﺳﺮور ﻳﻜﺴﺎﻧﻲ ﻣﻲ‬ ﻛﻨﺪ، ﻧﻈﻴﺮ ﺗﺼﺎوﻳﺮ از ﺻﻔﺤﻪ وب، ﺳﺮي ﻫﺎي ﺑﺰرﮔﻲ از درﺧﻮاﺳﺖ ﻫﺎ وﺟﻮد دارﻧﺪ ﻛﻪ ﻫﻤﮕﻲ ﺗﻘﺮﻳﺒﺎ ﻣﻌﺎدل ﺑﻨﻈﺮ ﻣﻲ رﺳﻨﺪ.‬‬‬‬ در ﺣﺎﻟﻲ ﻛﻪ ﺗﻌﺪاد اﺷﻴﺎي ﻫﺮ ﺻﻔﺤﻪ وب اﻓﺰاﻳﺶ ﻣﻲ ﻳﺎﺑﻨﺪ، اﺳﺘﻔﺎده از ﻛﻮﻛﻲ ﻫﺎ و اﻧﺪازه ي درﺧﻮاﺳﺖ ﻫﺎ ﻧﻴﺰ در ﻃﻮل‬ زﻣﺎن ﺗﻐﻴﻴﺮ ﻣﻲ ﻛﻨﺪ. ﻛﻮﻛﻲ ﻫﺎ ﻧﻴﺰ ﺑﺎﻳﺪ در ﻫﻤﻪ ي درﺧﻮاﺳﺖ ﻫﺎ ﺷﺎﻣﻞ ﺷﻮﻧﺪ، ﻛﻪ ﺑﻴﺸﺘﺮ در درﺧﻮاﺳﺖ ﻫﺎي زﻳﺎدي ﻳﻜﺴﺎن‬ ﻫﺴﺘﻨﺪ.‬‬‬‬ اﻧﺪازه ﻫﺎي درﺧﻮاﺳﺖ 1.1 HTTP‬ در ﻃﻮل زﻣﺎن آﻧﻘﺪر ﺑﺰرگ ﻣﻲ ﺷﻮﻧﺪ ﻛﻪ ﺑﺮﺧﻲ اوﻗﺎت از ﭘﻨﺠﺮه ي اوﻟﻴﻪ ي TCP‬ ﻧﻴﺰ‬ ﺑﺰرﮔﺘﺮ ﻣﻲ ﺷﻮﻧﺪ ﻛﻪ اﻳﻦ ﻣﺴﺎﻟﻪ آﻧﻬﺎ را در ارﺳﺎل اﻃﻼﻋﺎت ﻛﻨﺪ ﻣﻲ ﺳﺎزد ﭼﻮن ﻧﻴﺎز ﺑﻪ ﻳﻚ ﺳﻔﺮ ﺑﺮﮔﺸﺘﻲ ﻛﺎﻣﻞ ﺑﺮاي‬ ﺑﺪﺳﺖ آوردن ﻳﻚ ACK‬ از ﺳﺮور ﻗﺒﻞ از ارﺳﺎل درﺧﻮاﺳﺖ ﻛﺎﻣﻞ دارﻧﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ، ﻣﺴﺎﻟﻪ دﻳﮕﺮي اﺳﺖ ﻛﻪ در ﻓﺸﺮده‬ ﺳﺎزي ﻣﻮرد ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻗﺮار ﻣﻲ ﮔﻴﺮد.‬‬‬‬‬‬‬‬

ﻓﺸﺮده ﺳﺎزي ﻣﻮﺿﻮﻋﻲ ﻣﺸﻜﻞ اﺳﺖ‬ ﻓﺸﺮده ﺳﺎزي ﻫﺎي HTTPS‬ و SPDY‬در ﻣﻘﺎﺑﻞ ﺣﻤﻼت BREACH‬ و CRIME‬ آﺳﻴﺐ ﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ. ﺑﺎ وارد ﺳﺎزي ﻣﺘﻦ‬ ﺷﻨﺎﺧﺘﻪ ﺷﺪه در ﺟﺮﻳﺎن و ﻣﺸﺨﺺ ﺳﺎزي اﻳﻦ ﻛﻪ ﭼﮕﻮﻧﻪ ﺧﺮوﺟﻲ را ﺗﻐﻴﻴﺮ ﻣﻲ دﻫﺪ، ﻣﻬﺎﺟﻢ ﻣﻲ ﺗﻮاﻧﺪ ﭼﻴﺰي را ﻛﻪ ارﺳﺎل‬ ﻣﻲ ﺷﻮد، ﻣﻌﻴﻦ ﻛﻨﺪ.‬‬‬‬‬‬‬‬ ﻓﺸﺮده ﺳﺎزي ﺑﺮ ﻳﻚ ﻣﺤﺘﻮاي ﭘﻮﻳﺎ ﺑﺮاي ﻳﻚ ﭘﺮوﺗﻜﻞ ﺑﺪون آﺳﻴﺐ ﭘﺬﻳﺮ ﺑﻮدن در ﻣﻘﺎﺑﻞ ﻳﻜﻲ از اﻳﻦ ﺣﻤﻼت، ﻧﻴﺎز ﺑﻪ ﻓﻜﺮ و‬ ﻣﻼﺣﻈﺎت دﻗﻴﻖ دارد. اﻳﻦ ﻛﺎري اﺳﺖ ﻛﻪ ﺗﻴﻢ HTTPbis‬ ﺳﻌﻲ در اﻧﺠﺎم آن دارد.‬‬‬‬ وارد ﺳﺎﺧﺘﻦ ،HPACK‬ ﻓﺸﺮده ﺳﺎزي ﺳﺮآﻳﻨﺪ ﺑﺮاي HTTP2‬ ﻳﻚ ﻓﺮﻣﺖ ﻓﺸﺮده ﺳﺎزي اﺳﺖ ﻛﻪ ﺑﻪ ﻃﻮر ﺧﺎص ﺑﺮاي‬ ﺳﺮآﻳﻨﺪﻫﺎي HTTP2‬ ‬اﻳﺠﺎد ﺷﺪه اﺳﺖ و در ﻳﻚ ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲ اﻳﻨﺘﺮﻧﺖ ﻣﺠﺰا ﻣﺸﺨﺺ ﺷﺪه اﺳﺖ. ﻓﺮﻣﺖ ﺟﺪﻳﺪ،‬ ﻫﻤﺮاه ﺑﺎ اﻗﺪاﻣﺎت ﻣﺘﻘﺎﺑﻞ دﻳﮕﺮ ﻧﻈﻴﺮ ﺑﻴﺘﻲ ﻛﻪ از واﺳﻄﻪ ﻫﺎ ﻣﻲ ﺧﻮاﻫﺪ ﻛﻪ ﻳﻚ ﺳﺮآﻳﻨﺪ ﺧﺎص را ﻓﺸﺮده ﺳﺎزي ﻧﻜﻨﻨﺪ و‬ padding‬ اﺧﺘﻴﺎري ﻓﺮﻳﻢ ﻫﺎ ﺑﻬﺮه ﺑﺮداري از اﻳﻦ ﻓﺸﺮده ﺳﺎزي را دﺷﻮارﺗﺮ ﻣﻲ ﺳﺎزﻧﺪ.‬‬‬‬‬‬‬‬‬ ﺑﺮ اﺳﺎس اﻇﻬﺎرات (Roberto peon‬ ﻳﻜﻲ از اﻳﺠﺎد ﻛﻨﻨﺪﮔﺎن HPACK" ،(HPACK‬" ﺑﺮاي ﺟﻠﻮﮔﻴﺮي از ﻧﺸﺖ اﻃﻼﻋﺎت‬ ﺑﺮاي ﻳﻚ ﭘﻴﺎده ﺳﺎزي ﺗﻄﺒﻴﻘﻲ، ﺑﺮاي رﻣﺰﮔﺬاري و رﻣﺰﮔﺸﺎﻳﻲ ﺧﻴﻠﻲ ﺳﺮﻳﻊ/ارزان، ﻓﺮاﻫﻢ ﻛﺮدن ﻛﻨﺘﺮل ﺑﺮ اﻧﺪازه ي ﺑﺎﻓﺖ‬ ﻓﺸﺮده ﺳﺎزي، ﻧﻤﺎﻳﻪ ﺳﺎزي ﻣﺠﺪد ﭘﺮوﻛﺴﻲ (ﻣﺜﻼ، وﺿﻌﻴﺖ ﻣﺸﺘﺮك ﺑﻴﻦ ﻗﺴﻤﺖ ﺟﻠﻮﻳﻲ و ﭘﺸﺘﻲ در ﻳﻚ ﭘﺮوﻛﺴﻲ) و ﺑﺮاي‬ ﻣﻘﺎﻳﺴﻪ ﻫﺎي ﺳﺮﻳﻊ رﺷﺘﻪ ﻫﺎي رﻣﺰﮔﺬاري ﺷﺪه ي ﻫﺎﻓﻤﻦ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﻴﺮد.‬‬‬‬‬‬‬

اﺳﺘﺮاﺣﺖ-ﺗﻐﻴﻴﺮ ﻋﻘﻴﺪه‬

ﻳﻜﻲ از ﻣﻌﺎﻳﺐ 1.1 HTTP‬ اﻳﻦ اﺳﺖ ﻛﻪ زﻣﺎﻧﻲ ﻛﻪ ﭘﻴﺎم HTTP‬ ﺑﺎ ﻃﻮل-ﻣﺤﺘﻮاي ﺑﺎ ﻳﻚ اﻧﺪازه ي ﺧﺎص ارﺳﺎل ﺷﺪ، ﻣﻲ‬ ﺗﻮاﻧﻴﺪ ﺑﻪ آﺳﺎﻧﻲ آن را ﻣﺘﻮﻗﻒ ﻛﻨﻴﺪ. اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ ﻛﻪ اﻏﻠﺐ (اﻣﺎ ﻧﻪ ﻫﻤﻴﺸﻪ) ﻣﻲ ﺗﻮاﻧﻴﺪ اﺗﺼﺎل TCP‬را ﻗﻄﻊ ﻣﻲ‬ ﻛﻨﻴﺪ، اﻣﺎ اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻲ ﺗﻮاﻧﺪ ﻫﺰﻳﻨﻪ ي اﻧﺠﺎم ﻣﺬاﻛﺮه ﺑﺮ ﻳﻚ دﺳﺘﺪاد TCP‬ ﺟﺪﻳﺪ را ﺗﺤﻤﻴﻞ ﻛﻨﺪ.‬‬‬‬‬‬‬‬ ﺷﻤﺎ ﻣﻲ ﺗﻮاﻧﻴﺪ ﭘﻴﺎم را ﻣﺘﻮﻗﻒ ﻛﺮده و ﻳﻚ اﺗﺼﺎل ﺟﺪﻳﺪ را ﺷﺮوع ﻛﻨﻴﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﺎ اﺳﺘﻔﺎده از ﻓﺮﻳﻢHTTP‬‬2 ST_STREAM‬ ﻗﺎﺑﻞ اﻧﺠﺎم اﺳﺖ ﻛﻪ از اﺗﻼف ﭘﻬﻨﺎي ﺑﺎﻧﺪ اﺟﺘﻨﺎب ﻣﻲ ﻛﻨﺪ و از ﻗﻄﻊ ﺷﺪن ﻫﺮ اﺗﺼﺎﻟﻲ ﺟﻠﻮﮔﻴﺮي ﻣﻲ ‬ﻛﻨﺪ.‬‬‬‬‬‬

server push

اﻳﻦ وﻳﮋﮔﻲ اﺳﺖ ﻛﻪ ﺗﺤﺖ ﻋﻨﻮان "cache push‬" ﺷﻨﺎﺧﺘﻪ ﺷﺪه اﺳﺖ. اﻳﺪه اي ﻛﻪ در اﻳﻨﺠﺎ اراﺋﻪ ﻣﻲ ﺷﻮد اﻳﻦ اﺳﺖ ﻛﻪ‬ اﮔﺮ ﻣﺸﺘﺮي ﺗﻘﺎﺿﺎي ﻣﻨﺒﻊ x‬را داﺷﺘﻪ ﺑﺎﺷﺪ، ﺳﺮور ﻣﻤﻜﻦ اﺳﺖ ﺑﺪاﻧﺪ ﻛﻪ ﻣﺸﺘﺮي ﺑﻌﺪ از آن ﻣﻨﺒﻊ z‬را ﻣﻲ ﺧﻮاﻫﺪ و آن را‬ ﺑﺪون درﺧﻮاﺳﺖ ﻣﺸﺘﺮي، ﺑﺮاﻳﺶ ﻣﻲ ﻓﺮﺳﺘﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﻪ ﻣﺸﺘﺮي ﻛﻤﻚ ﻣﻲ ﻛﻨﺪ ﻛﻪ z‬را در ﻛﺶ ﺧﻮد ﻗﺮار دﻫﺪ ﺑﻪ ﮔﻮﻧﻪ‬ اي ﻛﻪ زﻣﺎﻧﻲ ﻛﻪ آن را ﻣﻲ ﺧﻮاﻫﺪ در ﻛﺶ ﺑﺎﺷﺪ.‬‬‬‬‬‬‬‬‬ Server push‬ ﭼﻴﺰي اﺳﺖ ﻛﻪ ﻣﺸﺘﺮي ﺑﻪ ﻃﻮر ﺻﺮﻳﺢ از ﺳﺮور ﻣﻲ ﺧﻮاﻫﺪ آن را اﻧﺠﺎم دﻫﺪ و ﺣﺘﻲ اﮔﺮ ﻳﻚ ﻣﺸﺘﺮي آن‬ را اﻧﺠﺎم دﻫﺪ، ﻣﻲ ﺗﻮاﻧﺪ ﺑﻪ اﺧﺘﻴﺎر ﺧﻮد ﻳﻚ ﺟﺮﻳﺎن را ﺑﺎ RST_STRAM‬ ﺑﻪ ﭘﺎﻳﺎن ﺑﺮﺳﺎﻧﺪ.‬‬‬‬‬

ﻛﻨﺘﺮل ﺟﺮﻳﺎن

ﻫﺮ ﺟﺮﻳﺎن ﻣﺠﺰا ﺑﺮ HTTP2‬ ‬ﭘﻨﺠﺮه ي ﺟﺮﻳﺎن اﻋﻼﻧﻲ ﺧﻮد را دارد ﻛﻪ اﻧﺘﻬﺎي دﻳﮕﺮ آن ﻣﺠﺎز ﺑﻪ ارﺳﺎل داده ﺑﺮاي آن اﺳﺖ.‬ اﮔﺮ ﺑﺪاﻧﻴﺪ ﻛﻪ SSH‬ ﭼﻄﻮر ﻛﺎر ﻣﻲ ﻛﻨﺪ، اﻳﻦ ﻣﺴﺎﻟﻪ ﻧﻴﺰﺧﻴﻠﻲ ﻣﺸﺎﺑﻪ ﺷﻴﻮه و اﺳﺎس ﻣﺸﺎﺑﻬﻲ اﺳﺖ.‬‬‬‬‬ ﺑﺮاي ﻫﺮ ﺟﺮﻳﺎن، ﻫﺮ دو اﻧﺘﻬﺎ ﺑﺎﻳﺪ ﺑﻪ ﻧﻈﻴﺮﻫﺎي ﺧﻮد ﺑﮕﻮﻳﻨﺪ ﻛﻪ ﻓﻀﺎي ﺑﻴﺸﺘﺮي ﺑﺮاي ﻗﺮار دادن داده ي ورودي در آن دارد‬ و اﻧﺘﻬﺎي دﻳﮕﺮ ﻓﻘﻂ ﻣﺠﺎز ﺑﻪ ارﺳﺎل ﻣﻴﺰاﻧﻲ از داده ﻛﻪ ﭘﻨﺠﺮه ﺑﺴﻂ ﻳﺎﻓﺘﻪ اﺳﺖ، دارد. ﻓﻘﻂ ﻓﺮﻳﻢ ﻫﺎي DATA‬ ﻛﻨﺘﺮل‬ ﺟﺮﻳﺎﻧﻲ ﻣﻲ ﺷﻮﻧﺪ.‬‬‬‬‬

ﺑﺴﻂ ﻫﺎ

اﻳﻦ ﭘﺮوﺗﻜﻞ ﻧﻴﺎز دارد ﻛﻪ ﻫﺮ ﮔﻴﺮﻧﺪه ﻫﻤﻪ ي ﻓﺮﻳﻢ ﻫﺎي ﻧﺎﺷﻨﺎﺧﺘﻪ را ﺑﺎ اﺳﺘﻔﺎده از اﻧﻮاع ﻓﺮﻳﻢ ﻫﺎي ﻧﺎﺷﻨﺎﺧﺘﻪ ﺑﺨﻮاﻧﺪ و‬ ﺻﺮﻓﻨﻈﺮ ﻛﻨﺪ. ﺑﻨﺎﺑﺮاﻳﻦ دو ﮔﺮوه ﻣﻲ ﺗﻮاﻧﻨﺪ ﺑﺎ اﺳﺘﻔﺎده از اﻧﻮاع ﻓﺮﻳﻢ ﻫﺎي ﺟﺪﻳﺪ ﺑﺮ اﺳﺎس ﻫﺎپ-ﺑﻪ-ﻫﺎپ ﺑﺎ ﻫﻢ ﻣﺬاﻛﺮه ﻛﻨﻨﺪ‬ و اﻳﻦ ﻓﺮﻳﻢ ﻫﺎ ﻣﺠﺎز ﺑﻪ ﺗﻐﻴﻴﺮ وﺿﻌﻴﺖ ﻧﻴﺴﺘﻨﺪ و ﺑﺎﻳﺪ از ﻧﻈﺮ ﺟﺮﻳﺎن ﻛﻨﺘﺮل ﺷﻮﻧﺪ.‬‬‬‬ اﻳﻦ ﻣﺴﺎﻟﻪ ﻛﻪ آﻳﺎ HTTP2‬ ‬ﺑﺎﻳﺪ اﺻﻼ اﻣﻜﺎن ﺑﺴﻂ داﺷﺘﻪ ﺑﺎﺷﺪ ﻳﺎ ﺧﻴﺮ، ﺑﻪ ﻣﺪت ﻃﻮﻻﻧﻲ ﻣﻮرد ﺑﺤﺚ و ﻣﺬاﻛﺮه ﺑﻮده اﺳﺖ و در‬ ﻃﻮل زﻣﺎﻧﻲ ﻛﻪ ﭘﺮوﺗﻜﻞ ﺗﻮﺳﻌﻪ داده ﺷﺪه اﺳﺖ، ﻣﻮرد ﺑﺮرﺳﻲ ﻗﺮار ﮔﺮﻓﺘﻪ اﺳﺖ. ﺑﻌﺪ از ﭘﻴﺸﻨﻮﻳﺲ-21 اﻣﻜﺎن اﻓﺰودن اﻳﻦ‬ ﺑﺴﻂ ﻫﺎ ﻓﺮاﻫﻢ ﺷﺪ.‬‬‬‬‬ ﺑﻨﺎﺑﺮاﻳﻦ ﺑﺴﻂ ﻫﺎ ﺑﺨﺸﻲ از ﻣﺤﺼﻮل واﻗﻌﻲ ﻧﻴﺴﺘﻨﺪ اﻣﺎ ﺧﺎرج از ﻣﺸﺨﺼﺎت ﭘﺮوﺗﻜﻞ ﻫﺴﺘﻪ ﻣﺴﺘﻨﺪ ﺧﻮاﻫﻨﺪ ﺷﺪ. ﺗﺎﻛﻨﻮن در‬ اﻳﻦ ﻧﻘﻄﻪ، دو ﻧﻮع ﻓﺮﻳﻢ وﺟﻮد دارﻧﺪ ﻛﻪ ﺑﺮاي در ﺑﺮ ﮔﺮﻓﺘﻪ ﺷﺪن در ﭘﺮوﺗﻜﻞ ﻣﻮرد ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻗﺮار ﮔﺮﻓﺘﻪ اﻧﺪ ﻛﻪ ﺑﻪ ﻃﻮر‬ ﻣﻨﺎﺳﺐ اوﻟﻴﻦ ﻓﺮﻳﻢ ﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﺑﻪ ﻋﻨﻮان ﺑﺴﻂ ﻫﺎ ارﺳﺎل ﺧﻮاﻫﻨﺪ ﺷﺪ. در اﻳﻨﺠﺎ ﺑﻪ دﻟﻴﻞ ﻣﻌﺮوﻓﻴﺖ آﻧﻬﺎ و وﺿﻌﻴﺖ‬ ﻗﺒﻠﻲ ﺑﻪ ﻋﻨﻮان ﻓﺮﻳﻢ ﻫﺎي "ﺑﻮﻣﻲ" ﺑﻪ ﺑﺤﺚ و ﺑﺮرﺳﻲ در ﻣﻮرد آﻧﻬﺎ ﻣﻲ ﭘﺮدازم:‬‬‬‬‬

نتیجه گیری

نتیجه ای که در نهایت حاصل شده است.

مراجع

[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).