HTTP2

چکیده

اﻳﻦ ﻣﺴﺘﻨﺪ ﺑﻪ ﺷﺮح (Hyper Text Transfer Protocol‬‬ 2 (HTTP2 از نظر ﻓﻨﻲ و ﭘﺮوﺗﻜﻞ ﻣﻲ ﭘﺮدازد.

در اﻳﻦ ﻟﺤﻈﻪ ﻛﻪ اﻳﻦ ﻣﺴﺘﻨﺪ ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ (15 ﻣﺎه ژاﻧﻮﻳﻪ ﺳﺎل 2015)، ﻣﺸﺨﺼﺎت ﻧﻬﺎﻳﻲ HTTP2‬ ﺗﺎﻛﻨﻮن ﻛﺎﻣﻞ و‬ اراﺋﻪ ﻧﺸﺪه اﻧﺪ.

اﻳﻦ ﻣﺴﺘﻨﺪ ﺑﻪ ﺷﺮح ﻣﻮﻗﻌﻴﺖ فعلی می ﭘﺮدازد ﻛﻪ ﻣﻤﻜﻦ اﺳﺖ در ﻣﺸﺨﺼﺎت ﻧﻬﺎیی ﺗﻐﻴﻴﺮ ﻛﻨﺪ ﻳﺎ ﻧﻜﻨﺪ.‬‬‬‬‬ همچنین بهینه سازی هایی که در این نسخه نسبت به نسخه قبل انجام شده است را مورد بررسی قرار می دهد.

مجوز

اﻳﻦ ﻣﺴﺘﻨﺪ ﺗﺤﺖ ﻣﺠﻮز 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 اﻣﻜﺎن اﻓﺰودن اﻳﻦ‬ ﺑﺴﻂ ﻫﺎ ﻓﺮاﻫﻢ ﺷﺪ.‬‬‬‬‬ ﺑﻨﺎﺑﺮاﻳﻦ ﺑﺴﻂ ﻫﺎ ﺑﺨﺸﻲ از ﻣﺤﺼﻮل واﻗﻌﻲ ﻧﻴﺴﺘﻨﺪ اﻣﺎ ﺧﺎرج از ﻣﺸﺨﺼﺎت ﭘﺮوﺗﻜﻞ ﻫﺴﺘﻪ ﻣﺴﺘﻨﺪ ﺧﻮاﻫﻨﺪ ﺷﺪ. ﺗﺎﻛﻨﻮن در‬ اﻳﻦ ﻧﻘﻄﻪ، دو ﻧﻮع ﻓﺮﻳﻢ وﺟﻮد دارﻧﺪ ﻛﻪ ﺑﺮاي در ﺑﺮ ﮔﺮﻓﺘﻪ ﺷﺪن در ﭘﺮوﺗﻜﻞ ﻣﻮرد ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻗﺮار ﮔﺮﻓﺘﻪ اﻧﺪ ﻛﻪ ﺑﻪ ﻃﻮر‬ ﻣﻨﺎﺳﺐ اوﻟﻴﻦ ﻓﺮﻳﻢ ﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﺑﻪ ﻋﻨﻮان ﺑﺴﻂ ﻫﺎ ارﺳﺎل ﺧﻮاﻫﻨﺪ ﺷﺪ. در اﻳﻨﺠﺎ ﺑﻪ دﻟﻴﻞ ﻣﻌﺮوﻓﻴﺖ آﻧﻬﺎ و وﺿﻌﻴﺖ‬ ﻗﺒﻠﻲ ﺑﻪ ﻋﻨﻮان ﻓﺮﻳﻢ ﻫﺎي "ﺑﻮﻣﻲ" ﺑﻪ ﺑﺤﺚ و ﺑﺮرﺳﻲ در ﻣﻮرد آﻧﻬﺎ ﻣﻲ ﭘﺮدازم:‬‬‬‬‬

ﺧﺪﻣﺎت دﻳﮕﺮ

ﺑﺎ اﺗﺨﺎذ HTTP2‬ دﻻﻳﻠﻲ ﺑﺮاي ﺑﺮرﺳﻲ اﻳﻦ ﻛﻪ آﻳﺎ اﺗﺼﺎﻻت TCP‬ﻃﻮﻻﻧﻲ ﺗﺮ ﺧﻮاﻫﻨﺪ ﺑﻮد و ﻣﺪت زﻣﺎن ﻃﻮﻻﻧﻲ ﺗﺮي ﻧﺴﺒﺖ‬ ﺑﻪ اﺗﺼﺎﻻت HTTP1.x‬ ﺑﻪ ﻃﻮل اﻧﺠﺎﻣﻨﺪ، وﺟﻮد دارد. ﻳﻚ ﻣﺸﺘﺮي ﺑﺎﻳﺪ ﻗﺎدر ﺑﻪ اﻧﺠﺎم ﻛﺎرﻫﺎﻳﻲ ﻛﻪ دارد ﺑﺎ ﻳﻚ اﺗﺼﺎل‬ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد در ﻫﺮ ﺳﺎﻳﺖ/ﻣﻴﺰﺑﺎن ﺑﺎﺷﺪ و اﻳﻦ اﺗﺼﺎل ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﺑﺎﻳﺪ ﺑﻪ ﻃﻮر ﺑﺎﻟﻘﻮه ﺑﺮاي ﻣﺪﺗﻲ ﺑﺎز ﺑﺎﺷﺪ.‬‬‬‬‬‬‬ اﻳﻦ ﻣﺴﺎﻟﻪ ﺑﺮ ﭼﮕﻮﻧﮕﻲ ﻛﺎر ﻣﺘﻮازن ﻛﻨﻨﺪه ي ﺑﺎر HTTP‬ ﺗﺎﺛﻴﺮ ﻣﻲ ﮔﺬارد و ﻣﻮﻗﻌﻴﺖ ﻫﺎﻳﻲ ﻣﻤﻜﻦ اﺳﺖ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‬ ﻛﻪ ﻳﻚ ﺳﺎﻳﺖ ﺑﺨﻮاﻫﺪ اﻋﻼن ﻛﻨﺪ ﻛﻪ ﻣﺸﺘﺮي ﺑﻪ ﻣﻴﺰﺑﺎن دﻳﮕﺮي ﻣﺘﺼﻞ ﺷﻮد. اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻤﻜﻦ اﺳﺖ ﺑﻪ دﻻﻳﻞ ﻛﺎراﻳﻲ ﺑﺎﺷﺪ‬ اﻣﺎ اﮔﺮ ﻳﻚ ﺳﺎﻳﺖ ﺑﺮاي ﻣﺪﺗﻲ ﺑﻪ دﻟﻴﻞ ﻧﮕﻬﺪاﺷﺖ و ﻏﻴﺮه ﻏﻴﺮﻓﻌﺎل ﺑﺎﺷﺪ ﻧﻴﺰ رخ ﻣﻲ دﻫﺪ.‬‬‬‬‬ ﺳﭙﺲ ﺳﺮور Alt‐Svc‬را ارﺳﺎل ﺧﻮاﻫﺪ ﻛﺮد: ﺳﺮآﻳﻨﺪ ﻛﻪ ﺑﻪ ﻣﺸﺘﺮي در ﻣﻮرد ﻳﻚ ﺳﺮوﻳﺲ ﺟﺎﻳﮕﺰﻳﻦ ﻣﻲ ﮔﻮﻳﺪ. ﻣﺴﻴﺮ دﻳﮕﺮ‬ ﺑﻪ ﻣﺤﺘﻮاي ﻳﻜﺴﺎﻧﻲ ﺑﺎ اﺳﺘﻔﺎده از ﺳﺮوﻳﺲ، ﻣﻴﺰﺑﺎن و ﺷﻤﺎره ﭘﻮرت دﻳﮕﺮ اﺳﺖ.‬‬‬‬ ﺳﭙﺲ ﻳﻚ ﻣﺸﺘﺮي ﺳﻌﻲ در اﺗﺼﺎل ﺑﻪ آن ﺳﺮوﻳﺲ ﺑﻪ ﻃﻮر ﻧﺎﻫﻤﺰﻣﺎن ﻣﻲ ﻛﻨﺪ و ﻓﻘﻂ از ﻣﺴﻴﺮﻫﺎي دﻳﮕﺮ در ﺻﻮرﺗﻲ ﻛﻪ ﺑﻪ‬ ﺧﻮﺑﻲ ﻛﺎر ﻛﻨﺪ، اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﺪ.‬‬‬

TLS‬ ﻓﺮﺻﺖ ﻃﻠﺒﺎﻧﻪ‬ :‬ ﺳﺮآﻳﻨﺪ Alt‐svc‬ ﺑﻪ ﻳﻚ ﺳﺮور اﻳﻦ اﺟﺎزه را ﻣﻲ دﻫﺪ ﻛﻪ ﻣﺤﺘﻮا را ﺑﺮ //:http‬ ﻓﺮاﻫﻢ ﻛﻨﺪ، ﺑﺮاي اﻃﻼع رﺳﺎﻧﻲ ﺑﻪ ﻣﺸﺘﺮي‬ ﻛﻪ ﻣﺤﺘﻮاي ﻳﻜﺴﺎﻧﻲ ﻧﻴﺰ ﺑﺮ ﻳﻚ اﺗﺼﺎل TLS‬ﻣﻮﺟﻮد اﺳﺖ.‬‬‬‬‬‬ اﻳﻦ وﻳﮋﮔﻲ اﺳﺖ ﻛﻪ ﻣﻮرد ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻗﺮار ﮔﺮﻓﺘﻪ اﺳﺖ. ﭼﻨﻴﻦ اﺗﺼﺎﻟﻲ TLS‬ ﻛﻪ ﻫﻤﺮاه ﺑﺎ اﺣﺮاز ﻫﻮﻳﺖ ﻧﻴﺴﺖ را اراﺋﻪ‬ ﻛﺮده و دﻳﮕﺮ اﻣﻦ ﻧﻴﺴﺖ ﻛﻪ از ﻫﻴﭻ padlock‬ ي در UI‬ اﺳﺘﻔﺎده ﻧﻤﻲ ﻛﻨﺪ ﻳﺎ ﺑﻪ ﻫﻴﭻ روﺷﻲ ﺑﻪ ﻛﺎرﺑﺮ ﻧﻤﻲ ﮔﻮﻳﺪ ﻛﻪ ﻳﻚ‬ HTTP‬ ﻗﺪﻳﻤﻲ رﻣﺰ ﻧﺸﺪه ﻧﻴﺴﺖ اﻣﺎ ﻫﻨﻮز TLS‬ ﻓﺮﺻﺖ ﻃﻠﺒﺎﻧﻪ اﺳﺖ و ﺑﺮﺧﻲ از اﻓﺮاد ﺑﻪ ﺷﺪت ﺑﺎ اﻳﻦ ﻣﻔﻬﻮم ﻣﺨﺎﻟﻒ ﻫﺴﺘﻨﺪ.‬‬‬‬‬‬‬‬‬

اﻧﺴﺪاد

ﻳﻚ ﻓﺮﻳﻢ از اﻳﻦ ﻧﻮع دﻗﻴﻘﺎ ﻳﻜﺒﺎر ﺗﻮﺳﻂ ﻳﻚ ﮔﺮوه HTTP2‬ ‬زﻣﺎﻧﻲ ﻛﻪ داده اي ﺑﺮاي ارﺳﺎل دارد، ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ‬ ﮔﻴﺮد اﻣﺎ ﻛﻨﺘﺮل ﺟﺮﻳﺎن از ارﺳﺎل ﻫﺮ داده اي ﺗﻮﺳﻂ آن ﺟﻠﻮﮔﻴﺮي ﻣﻲ ﻛﻨﺪ. اﻳﺪه اﻳﻦ اﺳﺖ ﻛﻪ اﮔﺮ ﭘﻴﺎده ﺳﺎزي ﺷﻤﺎ اﻳﻦ‬ ﻓﺮﻳﻢ را درﻳﺎﻓﺖ ﻛﺮد، ﻣﺘﻮﺟﻪ ﻣﻲ ﺷﻮﻳﺪ ﻛﻪ ﭼﻴﺰي در ﭘﻴﺎده ﺳﺎزي ﺷﻤﺎ اﺷﺘﺒﺎه اﺳﺖ و ﻳﺎ ﺳﺮﻋﺖ اﻧﺘﻘﺎل ﻛﻤﺘﺮي ﻧﺴﺒﺖ ﺑﻪ‬ ﺣﺎﻟﺖ ﻋﺎدي دارﻳﺪ.‬‬‬‬‬‬ ﻳﻚ ﻋﺒﺎرت از ﭘﻴﺸﻨﻮﻳﺲ-21، ﻗﺒﻞ از اﻧﺘﻘﺎل اﻳﻦ ﻓﺮﻳﻢ ﺑﻪ ﻋﻨﻮان ﻳﻚ ﺑﺴﻂ اراﺋﻪ ﺷﺪه اﺳﺖ:‬‬

"ﻓﺮﻳﻢ ﺑﻼك ﺷﺪه در اﻳﻦ ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲ ﺑﺮاي ﺗﺴﻬﻴﻞ آزﻣﺎﻳﺸﺎت اراﺋﻪ ﺷﺪه اﺳﺖ. اﮔﺮ ﻧﺘﺎﻳﺞ آزﻣﺎﻳﺶ، ﺑﺎزﺧﻮرد ﻣﺜﺒﺘﻲ‬ را ﻓﺮاﻫﻢ ﻧﻜﻨﻨﺪ، ﻣﻲ ﺗﻮان آن را ﺣﺬف ﻛﺮد".‬‬‬

دﻧﻴﺎي HTTP2

زﻣﺎﻧﻲ ﻛﻪ HTTP2 ‬اﺗﺨﺎذ ﺷﻮد، ﭼﻴﺰﻫﺎ ﭼﮕﻮﻧﻪ ﺑﻪ ﻧﻈﺮ ﺧﻮاﻫﻨﺪ رﺳﻴﺪ؟ آﻳﺎ اﺳﺘﻔﺎده ﺧﻮاﻫﺪ ﺷﺪ؟‬‬

HTTP2 ‬ﭼﮕﻮﻧﻪ ﺑﺮ اﻧﺴﺎن ﻫﺎي ﻋﺎدي ﺗﺎﺛﻴﺮ ﺧﻮاﻫﺪ ﮔﺬاﺷﺖ؟‬

HTTP2 ‬ﻫﻨﻮز ﺑﻪ ﻃﻮر ﮔﺴﺘﺮده ﻣﻮرد اﺳﺘﻔﺎده ﻳﺎ اﺗﺨﺎذ ﻗﺮار ﻧﮕﺮﻓﺘﻪ اﺳﺖ. ﻧﻤﻲ ﺗﻮاﻧﻴﻢ ﺑﺎ اﻃﻤﻴﻨﺎن ﺑﮕﻮﻳﻴﻢ ﻛﻪ دﻗﻴﻘﺎ ﭼﻪ‬ ﺗﺒﺪﻳﻼﺗﻲ اﻧﺠﺎم ﺧﻮاﻫﻨﺪ ﺷﺪ. اﻳﻦ ﻛﻪ ﭼﮕﻮﻧﻪ SPDY‬ اﺳﺘﻔﺎده ﺷﺪه اﺳﺖ را ﻣﺸﺎﻫﺪه ﻛﺮده اﻳﻢ و ﻣﻲ ﺗﻮاﻧﻴﻢ ﺣﺪﺳﻴﺎﺗﻲ در اﻳﻦ‬ ﻣﻮرد ﺑﺰﻧﻴﻢ و ﻣﺤﺎﺳﺒﺎﺗﻲ را ﺑﺮ اﺳﺎس آن و ﺳﺎﻳﺮ آزﻣﺎﻳﺸﺎت ﻗﺒﻠﻲ و ﻓﻌﻠﻲ اﻧﺠﺎم دﻫﻴﻢ.‬‬‬‬‬ HTTP2 ‬ﺗﻌﺪاد ﺳﻔﺮﻫﺎي رﻓﺖ و ﺑﺮﮔﺸﺖ ﺷﺒﻜﻪ ﺿﺮوري را ﻛﺎﻫﺶ ﻣﻲ دﻫﺪ و ﻛﺎﻣﻼ از ﻣﺸﻜﻞ ﺑﻠﻮﻛﻪ ﺳﺎزي ﺳﺮ ﺻﻒ ﺑﺎ‬ ﺗﺴﻬﻴﻢ و ﺻﺮﻓﻨﻈﺮ از ﺟﺮﻳﺎن ﻫﺎي ﻧﺎﺧﻮاﺳﺘﻪ ﺟﻠﻮﮔﻴﺮي ﻣﻲ ﻛﻨﺪ.‬‬‬ HTTP2 اﻣﻜﺎن ﻣﻴﺰان زﻳﺎدي ﺟﺮﻳﺎن ﻫﺎي ﻣﻮازي را ﻓﺮاﻫﻢ ﻣﻲ ﻛﻨﺪ ﻛﻪ ﺑﺮ ﺣﺘﻲ sharding‬ ﺗﺮﻳﻦ ﺳﺎﻳﺖ ﻫﺎي اﻣﺮوزي رخ‬ ﻣﻲ دﻫﻨﺪ.‬‬‬‬ ﺑﺎ اوﻟﻮﻳﺖ ﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﻃﻮر ﻣﻨﺎﺳﺐ ﺑﺮ ﺟﺮﻳﺎن ﻫﺎ اﻋﻤﺎل ﺷﺪه اﻧﺪ، ﺷﺎﻧﺲ اﻳﻦ ﻛﻪ ﻣﺸﺘﺮي ﻫﺎ داده ي ﻣﻬﻢ را ﻗﺒﻞ از داده ي‬ ﺑﺎ اﻫﻤﻴﺖ ﻛﻤﺘﺮ ﺑﺪﺳﺖ آوردﻧﺪ، ﺑﻴﺸﺘﺮ ﻣﻲ ﺷﻮد.‬‬‬ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻫﻤﻪ اﻳﻦ ﻣﺴﺎﺋﻞ، ﻣﻲ ﮔﻮﻳﻢ ﻛﻪ ﺷﺎﻧﺲ اﻳﻦ ﻛﻪ اﻳﻦ ﻣﺴﺎﻟﻪ ﻣﻨﺠﺮ ﺑﻪ ﺑﺎرﮔﺬاري ﺳﺮﻳﻌﺘﺮ ﺻﻔﺤﻪ و وﺑﺴﺎﻳﺖ ﻫﺎي‬ واﻛﻨﺶ ﮔﺮاﺗﺮ ﺷﻮد ﺑﻴﺸﺘﺮ اﺳﺖ. ﺑﻪ ﻃﻮر ﺧﻼﺻﻪ: ﻳﻚ ﺗﺠﺮﺑﻪ وب ﺑﻬﺘﺮ.‬‬‬ اﻳﻦ ﻛﻪ ﭼﻪ ﻣﻴﺰان ﺑﻬﺘﺮ ﻳﺎ ﺳﺮﻳﻌﺘﺮ ﺑﻮدن را ﻣﻲ ﺗﻮان ﺗﺠﺮﺑﻪ ﻛﺮد، اﻛﻨﻮن ﻧﻤﻲ ﺗﻮاﻧﻢ در ﻣﻮرد آن ﻧﻈﺮي ﺑﺪﻫﻢ. در اﺑﺘﺪا،‬ ﺗﻜﻨﻮﻟﻮژي ﻫﻨﻮز در ﻣﺮاﺣﻞ ﺧﻴﻠﻲ اوﻟﻴﻪ اﺳﺖ و ﻫﻨﻮز ﻣﺸﺘﺮﻳﺎن و ﺳﺮورﻫﺎﻳﻲ ﻛﻪ واﻗﻌﺎ از ﻣﺰاﻳﺎي ﻫﻤﻪ ي ﺗﻮاﻧﻤﻨﺪي ﻫﺎﻳﻲ ﻛﻪ‬ اﻳﻦ ﭘﺮوﺗﻜﻞ ﺟﺪﻳﺪ اراﺋﻪ ﻣﻲ ﻛﻨﺪ را ﻣﺸﺎﻫﺪه ﻧﻜﺮده اﻳﻢ.‬‬‬‬

ﭼﻄﻮر HTTP2‬ ‬ﺑﺮ ﺗﻮﺳﻌﻪ وب ﺗﺎﺛﻴﺮ ﺧﻮاﻫﺪ داﺷﺖ؟‬‬

در ﻃﻮل ﺳﺎﻟﻴﺎن ﺗﻮﺳﻌﻪ دﻫﻨﺪﮔﺎن وب و ﻣﺤﻴﻂ ﻫﺎي ﺗﻮﺳﻌﻪ ي وب ﻳﻚ ﻣﺠﻤﻮﻋﻪ اﺑﺰار ﻛﺎﻣﻞ را اراﺋﻪ ﻛﺮده اﻧﺪ و اﺑﺰارﻫﺎﻳﻲ‬ ﻛﻪ ﺣﻮل ﻣﺸﻜﻼت HTTP 1.1‬ اراﺋﻪ ﺷﺪه اﻧﺪ، ﻧﻈﻴﺮ اﺑﺰارﻫﺎﻳﻲ ﻛﻪ در اﺑﺘﺪاي اﻳﻦ ﻣﺴﺘﻨﺪ ﻣﻌﺮﻓﻲ ﻛﺮدم.‬‬‬‬ ﺑﺴﻴﺎري از ﻛﺴﺎﻧﻲ ﻛﻪ از اﻳﻦ اﺑﺰارﻫﺎ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ و ﺗﻮﺳﻌﻪ دﻫﻨﺪﮔﺎن اﻛﻨﻮن ﺑﻪ ﻃﻮر ﭘﻴﺸﻔﺮض و ﺑﺪون ﻓﻜﺮ اﺣﺘﻤﺎﻻ ﺑﻪ‬ ﻛﺎراﻳﻲ HTTP2‬ ‬ﺻﺪﻣﻪ ﻣﻲ زﻧﻨﺪ ﻳﺎ ﺣﺪاﻗﻞ واﻗﻌﺎ از ﻣﺰاﻳﺎي ﺗﻮاﻧﻤﻨﺪي ﻫﺎي ﺟﺪﻳﺪ HTTP2‬ ‬اﺳﺘﻔﺎده ﻧﻤﻲ ﻛﻨﻨﺪ. spriting‬و‬ inlining‬ ﻧﺒﺎﻳﺪ در HTTP2‬ ‬اﻧﺠﺎم ﺷﻮد. sharding‬ اﺣﺘﻤﺎﻻ ﺑﺮاي HTTP2 ﻣﻀﺮ ﺧﻮاﻫﺪ ﺑﻮد ﭼﻮن اﺣﺘﻤﺎﻻ از اﺳﺘﻔﺎده از‬ اﺗﺼﺎﻻت ﻛﻤﺘﺮي ﺳﻮد ﻣﻲ ﺑﺮد.‬‬‬‬‬‬‬‬‬‬‬ ﻣﺴﺎﻟﻪ اي ﻛﻪ در اﻳﻨﺠﺎ وﺟﻮد دارد اﻳﻦ اﺳﺖ ﻛﻪ وﺑﺴﺎﻳﺖ ﻫﺎ و ﺗﻮﺳﻌﻪ دﻫﻨﺪﮔﺎن وب ﻧﻴﺎز ﺑﻪ ﺗﻮﺳﻌﻪ و ﮔﺴﺘﺮش دﻧﻴﺎﻳﻲ دارﻧﺪ‬ ﻛﻪ در ﻛﻮﺗﺎه ﻣﺪت ﻣﺸﺘﺮﻳﺎن ﻫﺮ دويHTTP 1.1‬ و HTTP2‬ ‬را ﺑﻪ ﻋﻨﻮان ﻛﺎرﺑﺮان ﺧﻮد داﺷﺘﻪ ﺑﺎﺷﻨﺪ و ﺑﺪﺳﺖ آوردن‬ ﺣﺪاﻛﺜﺮ ﻛﺎراﻳﻲ ﺑﺮاي ﻫﻤﻪ ي ﻛﺎرﺑﺮان ﺑﺪون اراﺋﻪ ي دو ﻗﺴﻤﺖ-ﺟﻠﻮﻳﻲ ﻣﻲ ﺗﻮاﻧﺪ ﻛﺎري ﭼﺎﻟﺶ ﺑﺮاﻧﮕﻴﺰ ﺑﺎﺷﺪ.‬‬‬‬‬‬ ﺑﻪ ﻫﻤﻴﻦ دﻻﻳﻞ، ﺑﻨﻈﺮم زﻣﺎﻧﻲ ﻃﻮل ﻣﻲ ﻛﺸﺪ ﺗﺎ ﭘﺘﺎﻧﺴﻴﻞ ﻛﺎﻣﻞ HTTP2‬ ‬ﻣﺤﻘﻖ ﺷﻮد.‬‬‬

ﭘﻴﺎده ﺳﺎزي ﻫﺎي HTTP2

ﺳﻌﻲ در ﻣﺴﺘﻨﺪﺳﺎزي ﭘﻴﺎده ﺳﺎزي ﻫﺎي ﺧﺎص در ﻳﻚ ﻣﺴﺘﻨﺪ ﻧﻈﻴﺮ اﻳﻦ ﻣﺴﺘﻨﺪ، اﻟﺒﺘﻪ ﻛﺎﻣﻼ ﺑﻴﻬﻮده اﺳﺖ و در ﻧﻬﺎﻳﺖ ﺑﺎ‬ ﺷﻜﺴﺖ ﻣﻮاﺟﻪ ﻣﻲ ﺷﻮد و در ﻃﻮل دوره زﻣﺎﻧﻲ ﻛﻮﺗﺎﻫﻲ ﻗﺪﻳﻤﻲ ﻣﻲ ﺷﻮد. ﺑﻪ ﺟﺎﻳﺶ ﺑﻪ ﺷﺮح ﻣﻮﻗﻌﻴﺖ ﺑﻪ ﻃﻮر ﮔﺴﺘﺮده ﺗﺮ‬ ﻣﻲ ﭘﺮدازدم و ﺧﻮاﻧﻨﺪﮔﺎن را ﺑﻪ ﻟﻴﺴﺘﻲ از ﭘﻴﺎده ﺳﺎزي ﻫﺎ ﺑﺮ وﺑﺴﺎﻳﺖ HTTP2 ‬ارﺟﺎع ﻣﻲ دﻫﻢ.‬‬‬‬ ﻣﻴﺰان زﻳﺎدي ﭘﻴﺎده ﺳﺎزي وﺟﻮد دارﻧﺪ و ﻣﻴﺰان آﻧﻬﺎ در ﻃﻮل ﻛﺎر HTTP2 ‬اﻓﺰاﻳﺶ ﻳﺎﻓﺘﻪ اﺳﺖ. در زﻣﺎن ﻧﻮﺷﺘﻦ اﻳﻦ ﻣﺴﺘﻨﺪ،‬ 27 ﭘﻴﺎده ﺳﺎزي ﻟﻴﺴﺖ ﺷﺪه اﻧﺪ و ﺑﻴﺸﺘﺮ آﻧﻬﺎ آﺧﺮﻳﻦ ﭘﻴﺸﻨﻮﻳﺲ ﻫﺎ را ﭘﻴﺎده ﺳﺎزي ﻣﻲ ﻛﻨﻨﺪ.‬‬‬ ﻓﺎﻳﺮﻓﺎﻛﺲ ﻣﺮورﮔﺮي اﺳﺖ ﻛﻪ ﻳﻜﻲ از اﻳﻦ ﻧﺴﺨﻪ ﻫﺎي ﭘﻴﺸﻨﻮﻳﺲ اﺳﺖ، ﺗﻮﻳﻴﺘﺮ ﺳﺮوﻳﺲ ﻫﺎي ﺧﻮد را ﺑﺮ HTTP2 ‬اراﺋﻪ ﻛﺮده‬ اﺳﺖ. ﮔﻮﮔﻞ در ﻃﻮل ﻣﺎه آورﻳﻞ ﺳﺎل 2014 ﺑﻪ اراﺋﻪ ي ﭘﺸﺘﻴﺒﺎﻧﻲ HTTP2 ‬ﺑﺮ ﺗﻌﺪاد ﻛﻤﻲ ﺳﺮور ﺗﺴﺖ ﻛﻪ اﻳﻦ ﺳﺮوﻳﺲ ﻫﺎ‬ را اﺟﺮا ﻣﻲ ﻛﺮدﻧﺪ، ﭘﺮداﺧﺖ و از ﻣﺎه ﻣﻲ ﺳﺎل 2014 آﻧﻬﺎ ﭘﺸﺘﻴﺒﺎﻧﻲ HTTP2 ‬را در ﻧﺴﺨﻪ ﻫﺎي ﻛﺮوم اراﺋﻪ ﻛﺮدﻧﺪ.‬‬‬ Curl‬ و libcurl‬ از HTTP‬ رﻣﺰﻧﺸﺪه ﺑﻪ ﻫﻤﺮاه TLS‬ ﺑﺮ اﺳﺎس اﺳﺘﻔﺎده از ﭼﻨﺪﻳﻦ ﻛﺘﺎﺑﺨﺎﻧﻪ ي TLS‬ ﻣﺨﺘﻠﻒ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲ‬ ﻛﻨﻨﺪ.‬‬‬‬‬‬‬‬ در ﺣﺎﻟﻲ ﻛﻪ ﭘﻴﺸﻨﻮﻳﺲ-16 ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲ ﻓﻌﻠﻲ اﺳﺖ، ﺑﺎ ﻧﺴﺨﻪ ي-41 ﺑﻪ ﺷﻜﻞ دودوﻳﻲ ﺳﺎزﮔﺎر اﺳﺖ و ﻧﺴﺨﻪ-14‬ آﺧﺮﻳﻦ ﻧﺴﺨﻪ اي اﺳﺖ ﻛﻪ ﺑﻪ ﻋﻨﻮان ﻳﻚ ﻧﺴﺨﻪ ي ﭘﻴﺎده ﺳﺎزي/ interop‬ ﻣﺸﺨﺺ ﺷﺪه اﺳﺖ. ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل، در ﻣﺎه‬ ﻧﻮاﻣﺒﺮ ﺳﺎل 2014، ﻓﺎﻳﺮﻓﺎﻛﺲ ﺑﻪ ﺗﺒﻠﻴﻎ ﻫﺮ دو ﻧﺴﺨﻪ ي ﺧﻮد ﭘﺮداﺧﺖ. اﻣﺎ در ﺣﺎﻟﻲ ﻛﻪ دودوﻳﻲ ﺑﺮ ﺳﻴﻢ ﺳﺎزﮔﺎري دارد،‬ زﺑﺎن ﻣﺸﺨﺼﺎت ﺗﺎﺣﺪودي ﺗﻐﻴﻴﺮ ﻛﺮده اﺳﺖ ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ رﻓﺘﺎر ﻣﻌﺎدﻟﻲ ﻧﺪارﻧﺪ.‬‬‬‬‬‬

اﻧﺘﻘﺎدﻫﺎي ﻣﻌﻤﻮل ﺑﺮاي HTTP2 ‬‬

در ﻃﻮل ﺗﻮﺳﻌﻪ ي اﻳﻦ ﭘﺮوﺗﻜﻞ، ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻫﺎﻳﻲ اﻧﺠﺎم ﺷﺪ و اﻓﺮاد ﺧﺎﺻﻲ وﺟﻮد دارﻧﺪ ﻛﻪ اﻋﺘﻘﺎد دارﻧﺪ ﻛﻪ اﻳﻦ‬ ﭘﺮوﺗﻜﻞ ﻛﺎﻣﻼ اﺷﺘﺒﺎه اﺳﺖ. ﻣﻲ ﺧﻮاﻫﻴﻢ ﺗﻌﺪادي از ﻣﻌﻤﻮﻟﺘﺮﻳﻦ اﻋﺘﺮاﺿﺎت و ﺑﺤﺚ ﻫﺎﻳﻲ ﻛﻪ در ﻣﻘﺎﺑﻞ آﻧﻬﺎ اﻧﺠﺎم ﻣﻲ ﺷﻮد را‬ اراﺋﻪ ﻛﻨﻢ:‬‬‬‬

ﭘﺮوﺗﻜﻞ ﺗﻮﺳﻂ ﮔﻮﮔﻞ ﻃﺮاﺣﻲ ﺷﺪه ﻳﺎ اﻳﺠﺎد ﺷﺪه اﺳﺖ‬‬

ﻫﻤﭽﻨﻴﻦ اﺧﺘﻼﻓﺎﺗﻲ وﺟﻮد دارد ﻛﻪ ﺑﺪﻳﻦ وﺳﻴﻠﻪ دﻧﻴﺎ ﺑﻴﺸﺘﺮ ﺗﻮﺳﻂ ﮔﻮﮔﻞ ﻛﻨﺘﺮل ﻣﻲ ﺷﻮد ﻳﺎ ﺑﻪ آن واﺑﺴﺘﻪ ﻣﻲ ﺷﻮد. اﻳﻦ‬ ﻣﺴﺎﻟﻪ درﺳﺖ ﻧﻴﺴﺖ. ﭘﺮوﺗﻜﻞ در IETF‬ ﺗﻮﺳﻌﻪ داده ﺷﺪه اﺳﺖ ﻛﻪ ﻧﻈﻴﺮ ﭘﺮوﺗﻜﻞ ﻫﺎﻳﻲ ﺑﺎ ﺷﻴﻮه ﻳﻜﺴﺎن اﺳﺖ ﻛﻪ در ﻃﻲ‬ 30 ﺳﺎل ﮔﺬﺷﺘﻪ ﺗﻮﺳﻌﻪ داده ﺷﺪه اﻧﺪ. اﻣﺎ، از ﻛﺎر ﮔﻮﮔﻞ در ارﺗﺒﺎط ﺑﺎ SPDY‬ ﺗﺸﻜﺮ ﻣﻲ ﻛﻨﻴﻢ ﻛﻪ ﻧﻪ ﺗﻨﻬﺎ ﺛﺎﺑﺖ ﻛﺮد ﻛﻪ‬ اﻣﻜﺎن اﺳﺘﻘﺮار ﻳﻚ ﭘﺮوﺗﻜﻞ ﺟﺪﻳﺪ ﺑﺪﻳﻦ روش وﺟﻮد دارد ﺑﻠﻜﻪ در اراﺋﻪ ي اﻋﺪاد و ارﻗﺎﻣﻲ در ﻣﻮرد ﻣﺰاﻳﺎﻳﻲ ﻛﻪ ﻣﻲ ﺗﻮاﻧﻴﻢ‬ ﺑﺪﺳﺖ آورﻳﻢ، ﻛﻤﻚ ﻛﺮد.‬‬‬‬‬‬‬‬

ﭘﺮوﺗﻜﻞ ﻓﻘﻂ ﺑﺮاي ﻣﺮورﮔﺮﻫﺎ و ﺳﺮوﻳﺲ ﻫﺎي ﺑﺰرگ ﻣﻔﻴﺪ اﺳﺖ

ﺗﺎ ﺣﺪي درﺳﺖ اﺳﺖ. ﻳﻜﻲ از اﻧﮕﻴﺰه ﻫﺎي اﺻﻠﻲ ﭘﺸﺖ ﺗﻮﺳﻌﻪ ي HTTP2 ‬رﻓﻊ ﻣﺸﻜﻼت ﺧﻂ ﻟﻮﻟﻪ ي HTTP‬ اﺳﺖ. اﮔﺮ‬ ﻣﻄﺎﻟﻌﻪ ﻣﻮردي ﺷﻤﺎ اﺳﺎﺳﺎ ﻧﻴﺎزي ﺑﻪ ﺧﻂ ﻟﻮﻟﻪ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ، HTTP2 ‬ﻛﻤﻚ زﻳﺎدي ﺑﻪ ﺷﻤﺎ ﻧﻤﻲ ﻛﻨﺪ. اﻳﻦ ﻣﺴﺎﻟﻪ ﻗﻄﻌﺎ ﺗﻨﻬﺎ‬ ﺑﻬﺒﻮد در ﭘﺮوﺗﻜﻞ ﻧﻴﺴﺖ، اﻣﺎ ﻳﻜﻲ از ﺑﻬﺒﻮدﻫﺎي ﺑﺰرگ اﺳﺖ.‬‬‬‬‬ ﺑﻪ ﻣﺤﺾ اﻳﻦ ﻛﻪ ﺧﺪﻣﺎت ﺑﻪ ﺗﺤﻘﻖ ﺗﻮان ﻛﺎﻣﻞ و ﺗﻮاﻧﺎﻳﻲ ﻫﺎي ﺟﺮﻳﺎن ﻫﺎي ﺗﺴﻬﻴﻢ ﺷﺪه ﺑﺮ ﻳﻚ اﺗﺼﺎل ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد ﻣﻲ‬ ﭘﺮدازﻧﺪ، ﺑﻪ ﻧﻈﺮ ﻣﻲ رﺳﺪ ﻛﻪ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻛﺎرﺑﺮدي ﺑﻴﺸﺘﺮي از HTTP2 ‬اﺳﺘﻔﺎده ﻛﻨﻨﺪ.‬‬‬ REST API‬ ﻛﻮﭼﻚ و اﺳﺘﻔﺎده ﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﺳﺎده ﺗﺮ از HTTP1.x‬ ﻣﻤﻜﻦ اﺳﺖ ﮔﺎﻣﻲ ﺑﻪ ﺳﻤﺖ HTTP2 ‬ﺑﺮاي اراﺋﻪ‬ ي ﻣﺰاﻳﺎي ﺑﺰرگ ﻧﻴﺎﺑﻨﺪ. اﻣﺎ ﻫﻤﭽﻨﻴﻦ ﺑﺎﻳﺪ ﺑﺮاي ﺑﻴﺸﺘﺮ ﻛﺎرﺑﺮان ﻣﻌﺎﻳﺐ ﺧﻴﻠﻲ ﻛﻤﻲ در ارﺗﺒﺎط ﺑﺎ HTTP2 ‬وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ.‬‬‬‬‬

اﺳﺘﻔﺎده آن از TLS‬ آن را ﻛﻨﺪﺗﺮ ﻣﻲ ﺳﺎزد ‬‬‬

اﻳﻦ ﻣﻄﻠﺐ ﺗﺎ ﺣﺪي درﺳﺖ اﺳﺖ. دﺳﺘﺪاد TLS‬ ﺳﺮﺑﺎر اﺿﺎﻓﻲ ﻛﻤﻲ اﻳﺠﺎد ﻣﻲ ﻛﻨﺪ اﻣﺎ ﺗﻼش ﻫﺎي ﻣﻮﺟﻮد و ﭘﻴﻮﺳﺘﻪ اي ﺑﺮ‬ﻛﺎﻫﺶ ﺳﻔﺮﻫﺎي رﻓﺖ و ﺑﺮﮔﺸﺖ ﻻزم ﺑﻴﺸﺘﺮ ﺑﺮاي TLS‬ در ﺣﺎل اﻧﺠﺎم اﺳﺖ. ﺳﺮﺑﺎر اﻧﺠﺎم TLS‬ ﺑﺮ ﺳﻴﻢ ﺑﻪ ﺟﺎي ﻣﺘﻦ-‬ رﻣﺰﻧﺸﺪه ﭼﺸﻤﮕﻴﺮ ﻧﻴﺴﺖ و ﺑﻪ وﺿﻮح CPU‬ و ﺗﻮان ﺑﻴﺸﺘﺮي ﺑﺮ اﻟﮕﻮﻫﺎي ﺗﺮاﻓﻴﻚ ﻳﻜﺴﺎن ﻧﻈﻴﺮ ﭘﺮوﺗﻜﻞ ﻏﻴﺮ-اﻣﻦ ﺻﺮف‬ ﺧﻮاﻫﺪ ﺷﺪ. ﻣﻴﺰان ﺗﺎﺛﻴﺮي ﻛﻪ ﺧﻮاﻫﺪ داﺷﺖ ﻣﻮﺿﻮﻋﻲ ﺟﻬﺖ اﻇﻬﺎر ﻧﻈﺮ و اﻧﺪازه ﮔﻴﺮي اﺳﺖ. ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل‬ Istlsfastyet.com‬ را ﺑﺮاي ﻛﺴﺐ اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ ﻣﻄﺎﻟﻌﻪ ﻧﻤﺎﻳﻴﺪ.‬‬‬‬‬‬‬‬‬‬ ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل Telecom‬ و ﺳﺎﻳﺮ ﻋﻤﻠﮕﺮﻫﺎي ﺷﺒﻜﻪ، در ATIS open web alliance‬ ﻧﻴﺎز ﺑﻪ ﺗﺮاﻓﻴﻚ رﻣﺰﻧﺸﺪه ﺑﺮاي‬ اراﺋﻪ ي وﻳﮋﮔﻲ ﻛﺶ، ﻓﺸﺮده ﺳﺎزي و ﺳﺎﻳﺮ ﺗﻜﻨﻴﻚ ﻫﺎي ﻻزم ﺑﺮاي ﻓﺮاﻫﻢ ﻛﺮدن ﻳﻚ ﺗﺠﺮﺑﻪ وب ﺳﺮﻳﻊ ﺑﺮ ﻣﺎﻫﻮاره، ﻫﻮاﭘﻴﻤﺎ و‬ ﻣﻮارد ﻣﺸﺎﺑﻪ دارﻧﺪ.‬‬‬‬‬‬ HTTP2 ‬از TLS‬ اﺳﺘﻔﺎده اﺟﺒﺎري ﻧﻤﻲ ﻛﻨﺪ ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﻧﻤﻲ ﺗﻮاﻧﻴﻢ اﻳﻦ ﻋﺒﺎرات را ﺑﺎ ﻫﻢ اﺷﺘﺒﺎه ﺑﮕﻴﺮﻳﻢ.‬‬‬ اﻣﺮوزه ﺑﺴﻴﺎري از ﻛﺎرﺑﺮان ﺑﺮ اﻳﻨﺘﺮﻧﺖ TLS‬ را ﺑﺮاي اﺳﺘﻔﺎده ﮔﺴﺘﺮده ﺗﺮ ﻣﻲ ﺧﻮاﻫﻨﺪ و ﺑﺎﻳﺪ ﻛﻤﻚ ﻛﻨﻴﻢ ﻛﻪ از ﻣﺤﺮﻣﺎﻧﮕﻲ‬ ﻛﺎرﺑﺮ ﻣﺤﺎﻓﻈﺖ ﺷﻮد.‬‬‬‬ در ﻧﻬﺎﻳﺖ، ﺑﺎ ﺗﺸﻜﺮ از ﺟﺮﻳﺎن ﻫﺎي ﺗﺴﻬﻴﻢ ﺷﺪه ي HTTP2 ‬ﺑﺮ ﻳﻚ اﺗﺼﺎل ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮد، ﻣﻮارد اﺳﺘﻔﺎده ي ﻣﺮورﮔﺮﻫﺎي‬ ﻣﻌﻤﻮل ﻫﻨﻮز ﻣﻲ ﺗﻮاﻧﻨﺪ ﻣﻨﺠﺮ ﺑﻪ اﻧﺠﺎم دﺳﺘﺪادﻫﺎي TLS‬ ﻛﻤﺘﺮ ﺷﺪه و ﺑﻨﺎﺑﺮاﻳﻦ ﺳﺮﻳﻌﺘﺮ از HTTPS‬ زﻣﺎﻧﻲ ﻛﻪ ﻫﻨﻮز از‬ 1.1 HTTP‬ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ، ﺷﻮﻧﺪ.‬‬‬‬‬‬‬

اﺳﻜﻲ ﻧﺒﻮدن ﻳﻚ ﻋﺎﻣﻞ ﻣﺸﻜﻞ ﺳﺎز اﺳﺖ

ﺑﻠﻪ، ﻋﻼﻗﻤﻨﺪ ﻫﺴﺘﻴﻢ ﻛﻪ ﻗﺎدر ﺑﺎﺷﻴﻢ ﭘﺮوﺗﻜﻞ ﻫﺎ را واﺿﺢ ﺗﺮ ﺑﺒﻴﻨﻴﻢ ﭼﻮن دﻳﺒﺎگ و ردﻳﺎﺑﻲ را آﺳﺎﻧﺘﺮ ﻣﻲ ﺳﺎزد. اﻣﺎ ﭘﺮوﺗﻜﻞ‬ ﻫﺎي ﻣﺒﺘﻨﻲ ﺑﺮ ﻣﺘﻦ ﻧﻴﺰ داراي ﺧﻄﺎي ﺑﻴﺸﺘﺮي ﻫﺴﺘﻨﺪ و ﺑﺮاي ﭘﻮﻳﺶ ﺑﺎزﺗﺮ ﻫﺴﺘﻨﺪ و ﺑﻨﺎﺑﺮاﻳﻦ ﻣﺸﻜﻼت ﭘﻮﻳﺸﻲ ﺑﻴﺸﺘﺮي‬ دارﻧﺪ.‬‬‬‬ اﮔﺮ ﻧﺘﻮاﻧﻴﺪ ﻳﻚ ﭘﺮوﺗﻜﻞ دودوﻳﻲ را اﺳﺘﻔﺎده ﻛﻨﻴﺪ، آﻧﮕﺎه ﻧﻤﻲ ﺗﻮاﻧﻴﺪ TLS‬ و ﻓﺸﺮده ﺳﺎزي را در HTTP1.x‬ ﻧﻴﺰ ﻣﺪﻳﺮﻳﺖ‬ ﻛﻨﻴﺪ ﻛﻪ وﺟﻮد داﺷﺘﻪ و ﺑﻪ ﻣﺪت ﻃﻮﻻﻧﻲ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﺮﻓﺘﻪ اﺳﺖ.‬‬‬‬‬

ﺳﺮﻳﻌﺘﺮ از HTTP 1.1‬ ﻧﻴﺴﺖ

اﻟﺒﺘﻪ اﻳﻦ ﻛﻪ ﺳﺮﻳﻌﺘﺮ ﺑﻮدن ﺑﻪ ﭼﻪ ﻣﻌﻨﻲ اﺳﺖ، ﻣﻮﺿﻮﻋﻲ اﺳﺖ ﻛﻪ ﺑﺎﻳﺪ ﻣﻮرد ﺑﺤﺚ و ﺑﺮرﺳﻲ ﻗﺮار ﮔﻴﺮد اﻣﺎ ﺗﺎﻛﻨﻮن در‬ SPDY‬ﺗﺴﺖ ﻫﺎي ﺑﺴﻴﺎري اﻧﺠﺎم ﺷﺪه اﻧﺪ ﻛﻪ ﺑﺎرﮔﺬاري ﺳﺮﻳﻌﺘﺮ ﺻﻔﺤﺎت را ﻧﻤﺎﻳﺶ ﻣﻲ دﻫﻨﺪ (ﻣﻘﺎﻟﻪ ي "SPDY‬ ﭼﻘﺪر‬ ﺳﺮﻳﻊ اﺳﺖ؟" ﺗﻮﺳﻂ اﻓﺮاد داﻧﺸﮕﺎه واﺷﻨﮕﺘﻦ و "ارزﻳﺎﺑﻲ ﻛﺎراﻳﻲ ﺳﺮورﻫﺎي وب ﺑﺎ ﻗﺎﺑﻠﻴﺖ "SPDY‬ ﺗﻮﺳﻂ Herveservy) ‬‬و ﭼﻨﻴﻦ ﺗﺠﺮﺑﻴﺎﺗﻲ در ارﺗﺒﺎط ﺑﺎ HTTP2 ‬ﻧﻴﺰ اﻧﺠﺎم ﺷﺪه اﻧﺪ. ﻣﻦ ﻣﻨﺘﻈﺮ ﻫﺴﺘﻢ ﻛﻪ ﺗﺴﺖ ﻫﺎي اﻳﻨﭽﻨﻴﻨﻲ ﺑﻴﺸﺘﺮي اﻧﺠﺎم ﺷﺪه‬ و ﻣﻨﺘﺸﺮ ﺷﻮﻧﺪ.‬‬‬‬‬‬‬‬‬ HTTP2 ‬در ﺑﺮﺧﻲ از ﺳﻨﺎرﻳﻮﻫﺎ ﺳﺮﻳﻌﺘﺮ اﺳﺖ، ﺑﻪ ﺧﺼﻮص در ارﺗﺒﺎﻃﺎت ﺑﺎ ﺗﺎﺧﻴﺮ ﺑﺎﻻ ﻛﻪ اﺷﻴﺎي زﻳﺎدي را در ﺑﺮ ﻣﻲ ﮔﻴﺮﻧﺪ و‬ ﻫﻤﺎﻧﻄﻮر ﻛﻪ در ﺑﺨﺶ ﻫﺎي ﻗﺒﻠﻲ ﻧﺸﺎن داده ﺷﺪه اﺳﺖ، روﻧﺪ ﺑﻪ ﺳﻤﺖ اﺷﻴﺎي ﺑﻴﺸﺘﺮ و داده ﺑﻴﺸﺘﺮ درﻫﺮ ﺳﺎﻳﺖ ﭘﻴﺶ ﻣﻲ‬ رود.‬‬‬‬

ﻧﻘﺾ ﻻﻳﻪ ﺑﻨﺪي دارد‬‬

ﺑﻪ ﻃﻮر ﺟﺪي، آﻳﺎ اﻳﻦ ﻣﻮﺿﻮع ﻣﻮرد ﺑﺤﺚ ﺷﻤﺎﺳﺖ؟ ﻻﻳﻪ ﻫﺎ رﻛﻦ ﻫﺎي ﻏﻴﺮﻗﺎﺑﻞ دﺳﺘﺮﺳﻲ از ﻳﻚ آﻳﻴﻦ ﻣﻘﺪس ﻧﻴﺴﺘﻨﺪ و‬ اﮔﺮ ﺑﻪ ﻧﻮاﺣﻲ ﺧﺎﻛﺴﺘﺮي در ﺣﻴﻦ ﺳﺎﺧﺖ HTTP2 ‬وارد ﺷﺪﻳﻢ، ﺑﻪ دﻟﻴﻞ ﻋﻼﻗﻪ ﺑﻪ اﻳﺠﺎد ﻳﻚ ﭘﺮوﺗﻜﻞ ﺧﻮب و ﻣﻮﺛﺮ در‬ ﻣﺤﺪودﻳﺖ ﻫﺎي اراﺋﻪ ﺷﺪه ﺑﻮده اﺳﺖ.‬‬‬‬

ﻛﻤﺒﻮدﻫﺎي HTTP 1.1‬ را رﻓﻊ ﻧﻤﻲ ﻛﻨﺪ

اﻳﻦ ﻣﺴﺎﻟﻪ درﺳﺖ اﺳﺖ. ﺑﺎ ﻫﺪف ﺧﺎص ﻧﮕﻬﺪاﺷﺖ اﻟﮕﻮواره ﻫﺎي HTTP 1.1 ﭼﻨﺪﻳﻦ وﻳﮋﮔﻲ ﻗﺪﻳﻤﻲ HTTP‬ وﺟﻮد دارﻧﺪ‬ ﻛﻪ ﺑﺎﻳﺪ ﺑﺎﻗﻲ ﺑﻤﺎﻧﻨﺪ. ﭼﻨﻴﻦ ﺳﺮآﻳﻨﺪﻫﺎي ﻣﻌﻤﻮﻟﻲ ﻛﻪ در ﻛﻮﻛﻲ ﻫﺎ، ﺳﺮآﻳﻨﺪﻫﺎي ﻣﺠﺎزﺷﻨﺎﺳﻲ و ﻏﻴﺮه در ﺑﺮ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﻮﻧﺪ.‬ اﻣﺎ ﻣﺰﻳﺘﻲ ﻛﻪ ﺣﻔﻆ اﻳﻦ اﻟﮕﻮﻫﺎ دارد اﻳﻦ اﺳﺖ ﻛﻪ ﭘﺮوﺗﻜﻠﻲ را ﺑﺪﺳﺖ ﻣﻲ آورﻳﻢ ﻛﻪ اﻣﻜﺎن اﺳﺘﻘﺮار آن ﺑﺪون ﻣﻴﺰان زﻳﺎدي‬ ﻛﺎر ارﺗﻘﺎ ﻛﻪ ﺑﺮاي ﺟﺎﻳﮕﺰﻳﻦ ﺳﺎزي ﻳﺎ ﻧﻮﺷﺘﻦ ﻣﺠﺪد ﺑﺨﺶ ﻫﺎي اﺳﺎﺳﻲ ﻣﻮرد ﻧﻴﺎز اﺳﺖ، اﻣﻜﺎن ﭘﺬﻳﺮ اﺳﺖ. HTTP2 ‬اﺳﺎﺳﺎ‬ ﻳﻚ ﻻﻳﻪ ي ﻓﺮﻳﻤﻲ ﺟﺪﻳﺪ اﺳﺖ.‬‬‬‬‬‬‬‬

آﻳﺎ HTTP2 ﺑﻪ ﻃﻮر ﮔﺴﺘﺮده اﺳﺘﻘﺮار ﺧﻮاﻫﺪ ﻳﺎﻓﺖ؟‬

ﻫﻨﻮز زود اﺳﺖ ﻛﻪ ﺑﻪ ﻃﻮر ﻣﻄﻤﺌﻦ اﻳﻦ ﻣﺴﺎﻟﻪ را اﻋﻼن ﻛﻨﻴﻢ، اﻣﺎ ﻣﻦ ﺣﺪس ﻣﻲ زﻧﻢ و ﺗﺨﻤﻴﻦ ﻣﻲ زﻧﻢ. ﻣﻨﻔﻲ ﺑﺎﻓﺎن‬ ﺧﻮاﻫﻨﺪ ﮔﻔﺖ "ﺑﻪ ﭼﮕﻮﻧﮕﻲ ﻋﻤﻠﻜﺮد ﺧﻮب IPv6‬ ﻧﮕﺎه ﻛﻨﻴﺪ" ﻛﻪ اﻳﻦ ﻣﻮرد را ﺑﻪ ﻋﻨﻮان ﻳﻚ ﻣﺜﺎل از ﻳﻚ ﭘﺮوﺗﻜﻞ ﺟﺪﻳﺪ ﻛﻪ‬ ده ﻫﺎ ﺷﺮوع آن و اﺳﺘﻘﺮار ﮔﺴﺘﺮده اش ﺑﻪ ﻃﻮر اﻧﺠﺎﻣﻴﺪه اﺳﺖ، ﺑﻴﺎن ﻣﻲ ﻛﻨﻨﺪ. ﮔﺮﭼﻪ HTTP2 ‬ﻳﻚ IPv6‬ ﻧﻴﺴﺖ. ﭘﺮوﺗﻜﻠﻲ‬ اﺳﺖ ﻛﻪ ﺑﺮ ﺑﺎﻻي TCP‬ ﺑﺎ اﺳﺘﻔﺎده از ﻣﻜﺎﻧﻴﺴﻢ ﻫﺎي ﺑﺮوزرﺳﺎﻧﻲ HTTP‬ ﻋﺎدي ﻋﻤﻞ ﻣﻲ ﻛﻨﺪ. اﻳﻦ ﭘﺮوﺗﻜﻞ اﺻﻼ ﻧﻴﺎز ﺑﻪ‬ ﺗﻐﻴﻴﺮ ﺑﺴﻴﺎري از روال ﻫﺎ و ﻓﺎﻳﺮوال ﻫﺎ ﻧﺪارد.‬‬‬‬‬‬‬‬‬‬ ﮔﻮﮔﻞ ﺑﺎ ﻛﺎر SPDY‬ ﺧﻮد ﺑﻪ ﺟﻬﺎن ﺛﺎﺑﺖ ﻛﺮد ﻛﻪ ﻳﻚ ﭘﺮوﺗﻜﻞ ﺟﺪﻳﺪ ﻣﺜﻞ اﻳﻦ ﻣﻲ ﺗﻮاﻧﺪ ﺗﻮﺳﻂ ﻣﺮورﮔﺮﻫﺎ و ﺳﺮوﻳﺲ ﻫﺎ ﺑﺎ‬ ﭼﻨﺪﻳﻦ ﭘﻴﺎده ﺳﺎزي در زﻣﺎن ﻛﻮﺗﺎﻫﻲ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﺑﮕﻴﺮد. در ﺣﺎﻟﻲ ك ﻣﻴﺰان ﺳﺮورﻫﺎﻳﻲ ﺑﺮ اﻳﻨﺘﺮﻧﺖ ﻛﻪ اﻣﺮوزه‬ SPDY‬ را اراﺋﻪ ﻣﻲ ﻛﻨﻨﺪ در ﺑﺎزه ي 1% اﺳﺖ، ﻣﻴﺰان داده اي ﻛﻪ اﻳﻦ ﺳﺮورﻫﺎ ﺑﺎ آن ﺳﺮو ﻛﺎر دارﻧﺪ، ﺧﻴﻠﻲ ﺑﻴﺸﺘﺮ اﺳﺖ.‬‬‬‬‬‬

ﺑﺮﺧﻲ از ﻣﻌﺮوﻓﺘﺮﻳﻦ وﺑﺴﺎﻳﺖ ﻫﺎي اﻣﺮوزي SPDY‬ اراﺋﻪ ﻣﻲ ﻛﻨﻨﺪ.‬‬‬ HTTP2 ‬ﺑﺮ اﺳﺎس اﻟﮕﻮ واره ي اﺳﺎﺳﻲ ﻧﻈﻴﺮ، SPDY‬ اﺣﺘﻤﺎﻻ ﺑﻴﺸﺘﺮ ﺗﻮﺳﻌﻪ ﺧﻮاﻫﺪ ﻳﺎﻓﺖ ﭼﻮن ﻳﻚ ﭘﺮوﺗﻜﻞ IETF‬ اﺳﺖ.‬ اﺳﺘﻘﺮار SPDY‬ ﻫﻤﻴﺸﻪ ﻛﻤﻲ ﺑﻪ دﻟﻴﻞ ﺑﺮﭼﺴﺐ "اﻳﻦ ﻳﻚ ﭘﺮوﺗﻜﻞ ﮔﻮﮔﻞ اﺳﺖ" ﻋﻘﺐ ﻧﮕﻪ داﺷﺘﻪ ﺷﺪه اﺳﺖ.‬‬‬‬‬‬ ﭼﻨﺪﻳﻦ ﻣﺮورﮔﺮ ﺑﺰرگ ﭘﺸﺖ اﻳﻦ ﮔﺴﺘﺮش وﺟﻮد دارﻧﺪ. ﻧﻤﺎﻳﻨﺪﮔﺎﻧﻲ از ﻓﺎﻳﺮﻓﺎﻛﺲ، ﻛﺮوم و اﻳﻨﺘﺮﻧﺖ اﻛﺴﭙﻠﻮرر ﺑﻪ اراﺋﻪ ي‬ ﻣﺮورﮔﺮﻫﺎي ﺑﺎ ﻗﺎﺑﻠﻴﺖ HTTP2 ‬ﭘﺮداﺧﺘﻪ اﻧﺪ و ﺑﻪ اﻧﺠﺎم ﭘﻴﺎده ﺳﺎزي ﻫﺎ ﭘﺮداﺧﺘﻪ اﻧﺪ.‬‬‬ ﭼﻨﺪﻳﻦ ﻋﻤﻠﮕﺮ ﺳﺮور ﺑﺰرگ وﺟﻮد دارﻧﺪ ﻛﻪ ﻣﻲ ﺗﻮاﻧﻨﺪ ﺑﻪ زودي HTTP2 ‬را اراﺋﻪ ﻛﻨﻨﺪ، از ﺟﻤﻠﻪ ﮔﻮﮔﻞ، ﺗﻮﻳﻴﺘﺮ و ﻓﻴﺴﺒﻮك و‬ اﻣﻴﺪ دارﻳﻢ ﻛﻪ ﭘﺸﺘﻴﺒﺎﻧﻲ HTTP2 ﺑﻪ زودي ﺑﻪ ﭘﻴﺎده ﺳﺎزي ﻫﺎي ﺳﺮور ﻣﻌﺮوف ﻧﻈﻴﺮ ﺳﺮور HTTP‬ آﭘﺎﭼﻲ و nginx‬ اﻓﺰوده‬ ﺷﻮد. H2o‬ ﻳﻚ ﺳﺮور HTTP‬ ﺳﺮﻳﻊ ﺑﺎ ﭘﺸﺘﻴﺒﺎﻧﻲ HTTP2 ‬اﺳﺖ ﻛﻪ ﭘﺘﺎﻧﺴﻴﻞ ﻫﺎﻳﻲ را ﻧﺸﺎن داده اﺳﺖ.‬‬‬‬‬‬‬‬ ﺑﺮﺧﻲ از ﻓﺮوﺷﻨﺪﮔﺎن ﺑﺰرگ ﭘﺮوﻛﺴﻲ از ﺟﻤﻠﻪ squid ،HAProxy‬و varnish‬ ﺗﻤﺎﻳﻞ ﺧﻮد را ﺑﺮاي ﭘﺸﺘﻴﺒﺎﻧﻲ از HTTP2 ﻧﺸﺎن داده اﻧﺪ.‬‬‬‬‬ ﻣﻦ ﻓﻜﺮ ﻣﻲ ﻛﻨﻢ اﺣﺘﻤﺎﻻ ﭘﻴﺎده ﺳﺎزي ﻫﺎي ﺑﻴﺸﺘﺮي زﻣﺎﻧﻲ ﻛﻪ ﻣﺸﺨﺼﺎت RFC‬ ﺗﺎﻳﻴﺪ ﺷﺪه ﺑﺸﻮﻧﺪ، اراﺋﻪ ﺧﻮاﻫﻨﺪ ﺷﺪ.‬‬‬

HTTP2 در ﻓﺎﻳﺮﻓﺎﻛﺲ

ﻓﺎﻳﺮﻓﺎﻛﺲ ﺑﻪ ردﻳﺎﺑﻲ ﻧﺴﺨﻪ ﻫﺎي ﭘﻴﺸﻨﻮﻳﺲ ﭘﺮداﺧﺘﻪ و ﭘﻴﺎده ﺳﺎزي ﻫﺎي ﺗﺴﺖ HTTP2 ‬را ﺑﺮاي ﻣﺎه ﻫﺎي زﻳﺎدي اراﺋﻪ ﻣﻲ‬ ﻛﺮد. در ﻃﻮل ﺗﻮﺳﻌﻪ ي ﭘﺮوﺗﻜﻞ HTTP2 ، ‬ﻣﺸﺘﺮﻳﺎن و ﺳﺮورﻫﺎ ﺑﺎﻳﺪ ﺑﺮ ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲ ﭘﺮوﺗﻜﻠﻲ ﻛﻪ ﭘﻴﺎده ﺳﺎزي ﻣﻲ‬ ﻛﺮدﻧﺪ ﺑﻪ ﺗﻮاﻓﻖ ﻣﻲ رﺳﻴﺪﻧﺪ ﻛﻪ آن را ﻛﻤﻲ ﺑﺮاي اﺟﺮاي ﺗﺴﺖ ﻫﺎ آزاردﻫﻨﺪه ﻣﻲ ﺳﺎﺧﺖ. ﻣﻄﻤﺌﻦ ﺑﺎﺷﻴﺪ ﻛﻪ ﻣﺸﺘﺮي و‬ ﺳﺮور ﺷﻤﺎ ﺑﺮ ﻧﺴﺨﻪ ي ﭘﻴﺸﻨﻮﻳﺲ ﭘﺮوﺗﻜﻠﻲ ﻛﻪ ﭘﻴﺎده ﺳﺎزي ﻣﻲ ﺷﻮد، ﺗﻮاﻓﻖ دارﻧﺪ.‬‬‬‬‬

اول آن را ﻓﻌﺎل ﺳﺎزﻳﺪ

"about:config‬" را در ﻧﻮار آدرس وارد ﻛﻨﻴﺪ و ﺑﻪ ﺟﺴﺘﺠﻮي network.http.spdy.enabled.http2draft ﺑﭙﺮدازﻳﺪ. اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ ﻛﻪ ﺑﻪ true‬ ﻣﻘﺪار دﻫﻲ ﺷﺪه اﺳﺖ.‬‬‬‬ در ﻧﺴﺨﻪ ﻫﺎي ﺷﺒﺎﻧﻪ ي ﻓﺎﻳﺮﻓﺎﻛﺲ از 8 اﮔﻮﺳﺖ، HTTP2 ‬ﺑﻪ ﻃﻮر ﭘﻴش ﻔﺮض ﻓﻌﺎل ﺷﺪه اﺳﺖ!‬‬

ﻓﻘﻂ TLS

ﺑﻪ ﻳﺎد داﺷﺘﻪ ﺑﺎﺷﻴﺪ ﻛﻪ ﻓﺎﻳﺮﻓﺎﻛﺲ ﻓﻘﻂ ﺑﻪ ﭘﻴﺎده ﺳﺎزي HTTP2 ‬ﺑﺮ TLS‬ ﻣﻲ ﭘﺮدازد. ﻓﻘﻂ HTTP2 ‬را در ارﺗﺒﺎط ﺑﺎ ﻓﺎﻳﺮﻓﺎﻛﺲ‬ زﻣﺎﻧﻲ ﻛﻪ ﺑﻪ آدرس https://sites ﻣﻲ روﻳﺪ ﻛﻪ از HTTP2 ‬ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲ ﻛﻨﺪ، ﻣﺸﺎﻫﺪه ﻣﻲ ﻛﻨﻴﺪ.‬‬‬‬‬

ﺷﻔﺎف!

ﻫﻴﭻ ﻋﻨﺼﺮ UI‬ در ﻫﻴﭻ ﺟﺎﻳﻲ وﺟﻮد ﻧﺪارد ﻛﻪ ﺑﮕﻮﻳﺪ ﻛﻪ ﺷﻤﺎ ﺑﺎ HTTP2 ‬ارﺗﺒﺎط ﺑﺮﻗﺮار ﻣﻲ ﻛﻨﻴﺪ. اﻳﻦ را ﻧﻤﻲ ﺗﻮاﻧﻴﺪ ﺑﻪ‬ آﺳﺎﻧﻲ ﺑﮕﻮﻳﻴﺪ. ﻳﻚ راه ﺑﺮاي ﻣﺸﺨﺺ ﺳﺎﺧﺘﻦ اﻳﻦ ﻣﺴﺎﻟﻪ، ﻓﻌﺎﻟﺴﺎزي "web developer‐>network‬" و ﺑﺮرﺳﻲ‬ ﺳﺮآﻳﻨﺪﻫﺎي ﭘﺎﺳﺦ و اﻳﻦ ﻛﻪ ﭼﻪ ﭼﻴﺰي را از ﺳﺮور درﻳﺎﻓﺖ ﻣﻲ ﻛﻨﻴﺪ، اﺳﺖ. ﭘﺎﺳﺦ "HTTP 0.2‬" اﺳﺖ و ﻓﺎﻳﺮﻓﺎﻛﺲ‬ ﺳﺮآﻳﻨﺪ ﺧﻮد را ﻛﻪ : "X‐firefox‐spdy‬" ﻧﺎﻣﻴﺪه ﻣﻲ ﺷﻮد، ﻫﻤﺎﻧﻄﻮر ﻛﻪ در ﺗﺼﻮﻳﺮ ﺑﺎﻻ ﻧﻤﺎﻳﺶ داده ﺷﺪه اﺳﺖ، وارد ﻣﻲ‬ ﻛﻨﺪ.‬‬‬‬‬‬‬‬‬‬ ﺳﺮآﻳﻨﺪﻫﺎﻳﻲ ﻛﻪ در در اﺑﺰار ﺷﺒﻜﻪ زﻣﺎﻧﻲ ﻛﻪ ﺑﺎ HTTP2 ‬ارﺗﺒﺎط ﺑﺮﻗﺮار ﻣﻲ ﻛﻨﺪ، ﻣﺸﺎﻫﺪه ﻣﻲ ﻛﻨﻴﺪ از ﻓﺮﻣﺖ دودوﻳﻲ‬ HTTP2 ‬ﺑﻪ ﺳﺮآﻳﻨﺪﻫﺎي ﺷﺒﻪHTTP 1.x‬ ﺷﻴﻮه-ﻗﺪﻳﻤﻲ ﺗﺒﺪﻳﻞ ﺷﺪه اﻧﺪ.‬‬‬‬

ﺷﻜﻞ 1: ﺗﺼﻮﻳﺮي ﻛﻪ ﻧﺴﺨﻪ ﭘﻴﺸﻨﻮﻳﺲ-12 اﺳﺘﻔﺎده ﺷﺪه ﺗﻮﺳﻂ ﻓﺎﻳﺮﻓﺎﻛﺲ را ﻧﺸﺎن ﻣﻲ دﻫﺪ

HTTP2 ‬در curl

ﭘﺮوژه ي curl‬ ﭘﺸﺘﻴﺒﺎﻧﻲ آزﻣﺎﻳﺸﻲ از HTTP2 ‬را از ﻣﺎه ﺳﭙﺘﺎﻣﺒﺮ ﺳﺎل 2013 ﻓﺮاﻫﻢ ﻛﺮده اﺳﺖ. در زﻣﻴﻨﻪ ي، curl‬ ﻫﺪف‬ ﻣﺎ ﭘﺸﺘﻴﺒﺎﻧﻲ از ﻫﺮ ﺟﻨﺒﻪ از HTTP2 اﺳﺖ ﻛﻪ ﻣﻲ ﺗﻮاﻧﻴﻢ. Curl‬ اﻏﻠﺐ ﺑﻪ ﻋﻨﻮان ﻳﻚ اﺑﺰار ﺗﺴﺖ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﻴﺮد‬ و ﻣﻲ ﺧﻮاﻫﻴﻢ آن را ﺑﺮاي HTTP2 ‬ﻧﻴﺰ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار دﻫﻴﻢ.‬‬‬‬‬‬‬ Curl‬ از ﻛﺘﺎﺑﺨﺎﻧﻪ ي ﻣﺠﺰاي NGHTTP2 ‬ﺑﺮاي ﻋﻤﻠﻜﺮد ﻻﻳﻪ ي ﻓﺮﻳﻢ HTTP2 ‬اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﺪ.‬‬‬

ﺗﺸﺎﺑﻪ HTTP1.x

ﺑﻪ ﻃﻮر داﺧﻠﻲ، curl‬ ﺳﺮآﻳﻨﺪﻫﺎي ورودي HTTP2 ‬را ﺑﻪ ﺳﺮآﻳﻨﺪﻫﺎي ﺷﻴﻮه ي HTTP1.x‬ ﺗﺒﺪﻳﻞ ﻛﺮده و آﻧﻬﺎ را در اﺧﺘﻴﺎر‬ ﻛﺎرﺑﺮ ﻗﺮار ﻣﻲ دﻫﺪ، ﺑﻪ ﮔﻮﻧﻪ اي ﻛﻪ ﺧﻴﻠﻲ ﺷﺒﻴﻪ ﺑﻪ HTTP‬ ﻣﻮﺟﻮد ﺑﻪ ﻧﻈﺮ ﻣﻲ رﺳﻨﺪ. اﻳﻦ اﻣﺮ اﻣﻜﺎن اﻧﺘﻘﺎل آﺳﺎﻧﺘﺮ ﺑﺮاي‬ ﭼﻴﺰي ﻛﻪ از curl‬ و HTTP‬ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﺪ، ﻓﺮاﻫﻢ ﻣﻲ ﻧﻤﺎﻳﺪ. ﺑﻪ ﻃﻮر ﻣﺸﺎﺑﻪ curl‬ ﺳﺮآﻳﻨﺪﻫﺎي ﺧﺮوﺟﻲ را ﺑﻪ ﺷﻴﻮه ي‬ ﻳﻜﺴﺎﻧﻲ ﺗﺒﺪﻳﻞ ﺧﻮاﻫﺪ ﻛﺮد. آﻧﻬﺎ ﺑﻪ curl‬ﺑﻪ ﺷﻴﻮه ي HTTP1.x‬ اراﺋﻪ ﺷﺪه و آﻧﻬﺎ را زﻣﺎﻧﻲ ﻛﻪ ﺑﺎ ﺳﺮورﻫﺎي HTTP2 ‬‬ارﺗﺒﺎط ﺑﺮﻗﺮار ﻣﻲ ﻛﻨﺪ، ﺗﺒﺪﻳﻞ ﺧﻮاﻫﺪ ﻛﺮد. اﻳﻦ اﻣﺮ ﺑﻪ ﻛﺎرﺑﺮان اﻳﻦ اﻣﻜﺎن را ﻣﻲ دﻫﺪ ﻛﻪ زﻳﺎد در ﻣﻮرد اﻳﻦ ﻛﻪ ﻛﺪام ﻧﺴﺨﻪ‬ ي ﺧﺎص HTTP‬ ﻛﻪ در واﻗﻊ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲ ﮔﻴﺮد، ﻧﮕﺮاﻧﻲ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﻨﺪ.‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬

ﻣﺘﻦ رﻣﺰ ﻧﺸﺪه

Curl‬ از HTTP2 ‬رﻣﺰ ﻧﺸﺪه از ﻃﺮﻳﻖ ارﺗﻘﺎ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﺪ: ﺳﺮآﻳﻨﺪ. اﮔﺮ ﻳک درﺧﻮاﺳﺖ HTTP‬ اﻧﺠﺎم دﻫﻴﺪ و درﺧﻮاﺳﺖ‬ HTTP2 ‬داﺷﺘﻪ ﺑﺎﺷﻴﺪ، curl‬ در ﺻﻮرت اﻣﻜﺎن از ﺳﺮور درﺧﻮاﺳﺖ ارﺗﻘﺎي اﺗﺼﺎل ﺑﻪ HTTP2 ‬ﺧﻮاﻫﺪ داﺷﺖ.‬‬‬‬‬‬

TLS‬ و ﻛﺘﺎﺑﺨﺎﻧﻪ ﻫﺎﻳﺶ‬‬

Curl‬ از ﺑﺎزه ي ﮔﺴﺘﺮده اي از ﻛﺘﺎﺑﺨﺎﻧﻪ ﻫﺎي ﻣﺨﺘﻠﻒ TLS‬ ﺑﺮاي ﻗﺴﻤﺖ ﭘﺸﺘﻲ TLS‬ ﺧﻮد ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲ ﻛﻨﺪ و ﻫﻨﻮز ﺑﺮاي‬ ﭘﺸﺘﻴﺒﺎﻧﻲ HTTP2 ‬ﻣﻌﺘﺒﺮ اﺳﺖ. ﭼﺎﻟﺸﻲ ﻛﻪ در ارﺗﺒﺎط ﺑﺎ TLS‬ ﺑﻪ ﺧﺎﻃﺮ HTTP2 ‬وﺟﻮد دارد، ﭘﺸﺘﻴﺒﺎﻧﻲ APLN‬ و ﺗﺎ ﺣﺪي‬ ﭘﺸﺘﻴﺒﺎﻧﻲ NPN‬ اﺳﺖ.‬‬‬‬‬‬‬‬‬‬ Curl‬ را در ﻣﻘﺎﺑﻞ ﻧﺴﺨﻪ ﻫﺎي ﻣﺪرن openSSl‬ ﻳﺎ NSS‬ ﺑﺮاي ﺑﺪﺳﺖ آوردن ﭘﺸﺘﻴﺒﺎﻧﻲ ALPN‬ و NPN‬ اﻳﺠﺎد ﻛﻨﻴﺪ. ﺑﺎ‬ اﺳﺘﻔﺎده از GnuTLS‬ ﻳﺎ PolarSSL‬ ﭘﺸﺘﻴﺒﺎﻧﻲ ALPN‬ را ﺑﺪﺳﺖ ﺧﻮاﻫﻴﺪ آورد اﻣﺎ ﭘﺸﺘﻴﺒﺎﻧﻲ NPN‬ را ﺑﺪﺳﺖ ﻧﺨﻮاﻫﻴﺪ‬ آورد.‬‬‬‬‬‬‬‬‬‬‬‬‬

اﺳﺘﻔﺎده از ﺧﻂ ﻓﺮﻣﺎن‬

ﺑﺮاي ﮔﻔﺘﻦ ﺑﻪ curl‬ ﻛﻪ از HTTP2 ‬اﺳﺘﻔﺎده ﻛﻨﺪ، ﺑﻪ ﺷﻜﻞ ﻣﺘﻦ رﻣﺰ ﻧﺸﺪه ﻳﺎ ،TLS‬ﻣﻲ ﺗﻮاﻧﻴﺪ از ﮔﺰﻳﻨﻪ ي HTTP2 (که dash dash HTTP2‬ اﺳﺖ) اﺳﺘﻔﺎده ﻛﻨﻴﺪ. curl‬ ﻫﻨﻮز ﭘﻴﺸﻔﺮض HTTP 1.1‬ را دارد، ﺑﻨﺎﺑﺮاﻳﻦ ﮔﺰﻳﻨﻪ ﻫﺎي اﺿﺎﻓﻲ زﻣﺎﻧﻲ که HTTP2 را می خواهید، ضروری است.‬ ‬‬‬‬‬‬

ﮔﺰﻳﻨﻪ ﻫﺎي libcurl

ﺑﺮﻧﺎﻣﻪ ﻛﺎرﺑﺮدي ﺷﻤﺎ از URL‬ ﻫﺎي //:https‬ ﻳﺎ //:http‬ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﺪ اﻣﺎ ﮔﺰﻳﻨﻪ ي curl_easy_setopt’s‬‬ CURLOPT_HTTP_VERSION‬ را ﺑﻪ 2_ CURL_HTTP_VERSION‬ ﺗﻨﻈﻴﻢ ﻛﻨﻴﺪ ﺗﺎ libcurl‬ ﺳﻌﻲ در اﺳﺘﻔﺎده از‬ HTTP2 ‬ﻧﻤﺎﻳﺪ. ﺳﭙﺲ ﺑﻬﺘﺮﻳﻦ ﺗﻼش اﻧﺠﺎم ﺷﺪه و HTTP2 ‬در ﺻﻮرت اﻣﻜﺎن اﻧﺠﺎم ﻣﻲ ﺷﻮد، اﻣﺎ در ﻏﻴﺮاﻳﻨﺼﻮرت ﺑﻪ ﻋﻤﻠﻜﺮد‬ ﺑﺎ 1.1 HTTP‬ اداﻣﻪ ﻣﻲ دﻫﺪ.‬‬‬‬‬‬‬‬‬‬‬‬‬

ﺑﻌﺪ از HTTP2

ﺗﺼﻤﻴﻢ ﮔﻴﺮي ﻫﺎ و ﻣﻘﺎﻳﺴﻪ ﻫﺎي زﻳﺎدي ﺑﺮاي HTTP2 ‬اﻧﺠﺎم ﺷﺪه اﻧﺪ. ﺑﺎ اﺳﺘﻘﺮار HTTP2 ‬روﺷﻲ ﺑﺮاي ارﺗﻘﺎ ﺑﻪ ﺳﺎﻳﺮ ﻧﺴﺨﻪ‬ ﻫﺎي ﭘﺮوﺗﻜﻞ وﺟﻮد دارد ﻛﻪ ﭘﺎﻳﻪ اي ﺑﺮاي اﻧﺠﺎم ﺑﺮرﺳﻲ ﻫﺎي ﭘﺮوﺗﻜﻞ ﺑﻴﺸﺘﺮ اراﺋﻪ ﻣﻲ ﻛﻨﺪ. ﻫﻤﭽﻨﻴﻦ ﻳﻚ ﻣﻔﻬﻮم و‬ زﻳﺮﺳﺎﺧﺖ را اراﺋﻪ ﻣﻲ ﻛﻨﺪ ﻛﻪ ﻣﻲ ﺗﻮاﻧﺪ ﺑﻪ ﻣﺪﻳﺮﻳﺖ ﭼﻨﺪﻳﻦ ﻧﺴﺨﻪ ﺑﻪ ﻃﻮر ﻣﻮازي ﺑﭙﺮدازد. ﺷﺎﻳﺪ ﻧﻴﺎز ﺑﻪ ﺧﺎرج ﻛﺮدن ﻛﺎﻣﻞ‬ ﻣﻮارد ﻗﺒﻠﻲ زﻣﺎﻧﻲ ﻛﻪ ﻳﻚ ﻣﻮرد ﺟﺪﻳﺪ را اراﺋﻪ ﻣﻲ ﻛﻨﻴﻢ، ﻧﺪاﺷﺘﻪ ﺑﺎﺷﻴﻢ.‬‬‬‬‬

HTTP2 ‬ﻫﻨﻮز ﻣﻴﺰان زﻳﺎدي 1 HTTP‬ را ﺑﻪ دﻟﻴﻞ ﻋﻼﻗﻪ ﺑﻪ اﻣﻜﺎن ﭘﺬﻳﺮﺳﺎﺧﺘﻦ ﭘﺮوﻛﺴﻲ ﺗﺮاﻓﻴﻚ ﺑﻴﻦ HTTP1‬ و HTTP2 ﺑﺎ ﺧﻮد ﺑﻪ آﻳﻨﺪه آورده اﺳﺖ. ﺑﺮﺧﻲ از اﻳﻦ وﻳﮋﮔﻲ ﻫﺎ ﻣﺎﻧﻊ از ﺗﻮﺳﻌﻪ و اﺑﺘﻜﺎر ﺑﻴﺸﺘﺮ ﻣﻲ ﺷﻮﻧﺪ. ﺷﺎﻳﺪ HTTP3 ‬ﺑﺘﻮاﻧﺪ ﺑﺮﺧﻲ از‬ آﻧﻬﺎ را ﺣﺬف ﻛﻨﺪ. ﺷﻤﺎ ﻓﻜﺮ ﻣﻲ ﻛﻨﻴﺪ ﭼﻪ ﭼﻴﺰي در HTTP‬ ﻫﻨﻮز ﻛﻤﺒﻮدش ﺣﺲ ﻣﻲ ﺷﻮد؟‬‬‬‬‬‬‬

ﻣﻄﺎﻟﻌﻪ ي ﺑﻴﺸﺘﺮ

اﮔﺮ ﻓﻜﺮ ﻣﻲ ﻛﻨﻴﺪ ﻛﻪ اﻳﻦ ﻣﺴﺘﻨﺪ ﻣﺤﺘﻮا ﻳﺎ ﺟﺰﺋﻴﺎت ﻓﻨﻲ ي ﻛﻤﻲ دارد، در اﻳﻨﺠﺎ ﻣﻨﺎﺑﻊ اﺿﺎﻓﻲ اراﺋﻪ ﺷﺪه اﻧﺪ ﻛﻪ ﺑﻪ ﺷﻤﺎ در‬ ارﺿﺎي ﻛﻨﺠﻜﺎوﻳﺘﺎن ﻛﻤﻚ ﻣﻲ ﻛﻨﺪ:‬‬

ﻟﻴﺴﺖ اﻳﻤﻴﻞ ﻫﺎي ﮔﺮوه HTTPbis‬و ﺑﺎﻳﮕﺎﻧﻲ آن: http://lists.w3.org/Archives/Public/ietf-http-wg/

ﻧﺴﺨﻪ ﭘﻴﺸﻨﻮﻳﺲ ﻣﺸﺨﺼﺎت HTTP2 ‬و ﻣﺴﺘﻨﺪات ﻣﺮﺗﺒﻂ از ﮔﺮوه httpbis در http://datatracker.ietf.org/wg/httpbis/documents/ ‬‬‬‬‬

ﺟﺰﺋﻴﺎت ﭘﻴﺎده ﺳﺎزي 2 http://curl.haxx.se/dev/readme-http2.html :curl HTTP‬‬‬

‬وﺑﺴﺎﻳﺖ http://HTTP2.github.io :HTTP2‬ و ﺳﻮاﻻت ﻣﺘﺪاول: http://http2.github.io/faq/

مراجع

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