20 жылдан астам уақыт бойы біз HTTP протоколы арқылы веб-беттерді қарап келеміз. Көптеген пайдаланушылар оның не екенін және қалай жұмыс істейтінін ойламайды. Басқалары HTTP астында бір жерде TLS бар екенін біледі, ал оның астында TCP, оның астында IP және т.б. Ал басқалары - еретиктер - TCP өткен нәрсе деп санайды, олар тезірек, сенімдірек және қауіпсіз нәрсені қалайды. Бірақ жаңа идеалды хаттаманы ойлап табуға тырысқанда, олар 80-ші жылдардағы технологияға оралды және соған өздерінің батыл жаңа әлемін құруға тырысуда.
Кішкене тарих: HTTP/1.1
1997 жылы мәтіндік ақпарат алмасу протоколы HTTP 1.1 нұсқасы өзінің RFC-ке ие болды. Ол кезде хаттаманы браузерлер бірнеше жыл бойы қолданды, ал жаңа стандарт тағы он беске созылды. Хаттама тек сұрау-жауап принципімен жұмыс істеді және негізінен мәтіндік ақпаратты беруге арналған.
HTTP TCP протоколының жоғарғы жағында жұмыс істеуге арналған, бұл пакеттердің тағайындалған жеріне сенімді түрде жеткізілуін қамтамасыз етеді. TCP соңғы нүктелер арасында сенімді байланыс орнату және қолдау және трафикті сегменттерге бөлу арқылы жұмыс істейді. Сегменттердің өздерінің сериялық нөмірі мен бақылау сомасы болады. Егер кенеттен сегменттердің біреуі келмесе немесе дұрыс емес бақылау сомасымен келсе, онда жіберу жоғалған сегмент қалпына келгенше тоқтайды.
HTTP/1.0 жүйесінде TCP қосылымы әрбір сұраудан кейін жабылды. Бұл өте ысырап болды, өйткені... TCP қосылымын орнату (3-Way-Handshake) баяу процесс. HTTP/1.1 бірнеше сұраулар үшін бір қосылымды қайта пайдалануға мүмкіндік беретін тірі сақтау механизмін енгізді. Дегенмен, ол оңай қиыншылыққа айналуы мүмкін болғандықтан, HTTP/1.1 әртүрлі іске асырулары бір хостқа бірнеше TCP қосылымдарын ашуға мүмкіндік береді. Мысалы, Chrome және Firefox-тың соңғы нұсқалары алты қосылымға дейін мүмкіндік береді.
Сондай-ақ шифрлауды басқа хаттамаларға қалдыру керек болды және бұл үшін деректерді сенімді қорғайтын TCP арқылы TLS протоколы қолданылды, бірақ қосылымды орнату үшін қажетті уақытты одан әрі арттырды. Нәтижесінде қол алысу процесі келесідей болды:
Cloudflare иллюстрациясы
Осылайша, HTTP/1.1-де бірқатар мәселелер болды:
- Баяу қосылым орнату.
- Мәліметтер мәтіндік түрде беріледі, яғни суреттерді, бейнелерді және басқа да мәтіндік емес ақпаратты беру тиімсіз.
- Бір сұрау үшін бір TCP қосылымы пайдаланылады, бұл басқа сұраулар басқа қосылымды табуы немесе ағымдағы сұрау оны шығарғанша күту керек дегенді білдіреді.
- Тек тарту үлгісіне қолдау көрсетіледі. Стандартта серверді басу туралы ештеңе жоқ.
- Тақырыптар мәтін түрінде беріледі.
Егер серверді итеру кем дегенде WebSocket протоколы арқылы жүзеге асырылса, онда қалған мәселелерді түбегейлі шешу керек болды.
Сәл заманауилық: HTTP/2
2012 жылы Google SPDY («жылдам» деп айтылады) протоколымен жұмыс істей бастады. Протокол HTTP/1.1 негізгі мәселелерін шешуге арналған және сонымен бірге кері үйлесімділікті сақтауы керек еді. 2015 жылы IETF жұмыс тобы SPDY хаттамасына негізделген HTTP/2 спецификациясын енгізді. Міне, HTTP/2 арасындағы айырмашылықтар:
- Екілік сериялау.
- Бірнеше HTTP сұрауларын бір TCP қосылымына мультиплекстеу.
- Серверді қораптан шығарыңыз (WebSocketсіз).
Хаттама алға қарай жасалған үлкен қадам болды. Ол қатты және бірнеше TCP қосылымдарын жасауды қажет етпейді: бір хостқа барлық сұраныстар біреуге мультиплексирленген. Яғни, бір қосылымда әрқайсысының жеке идентификаторы бар бірнеше ағын деп аталатындар бар. Бонус - бұл қораптағы серверді басу.
Дегенмен, мультиплекстеу басқа негізгі мәселеге әкеледі. Біз бір серверге 5 сұрауды асинхронды түрде орындап жатырмыз деп елестетіңіз. HTTP/2 пайдалану кезінде бұл сұраулардың барлығы бір TCP қосылымында орындалады, яғни кез келген сұрау сегменттерінің бірі жоғалса немесе қате қабылданса, жоғалған сегмент жойылғанша барлық сұраулар мен жауаптарды жіберу тоқтатылады. қалпына келтірілді. Әлбетте, қосылым сапасы неғұрлым нашар болса, HTTP/2 соғұрлым баяу жұмыс істейді. , жоғалған пакеттер барлық пакеттердің 2%-ын құрайтын жағдайларда браузердегі HTTP/1.1 бір емес, 2 қосылымды ашатындықтан HTTP/6-ге қарағанда жақсырақ жұмыс істейді.
Бұл мәселе «басты блоктау» деп аталады және, өкінішке орай, TCP пайдалану кезінде оны шешу мүмкін емес.
Дэниел Штайнбергтің суреті
Нәтижесінде HTTP/2 стандартының әзірлеушілері тамаша жұмыс атқарды және OSI үлгісінің қолданбалы деңгейінде жасауға болатынның барлығын дерлік жасады. Көлік деңгейіне түсіп, жаңа көлік протоколын ойлап табудың уақыты келді.
Бізге жаңа протокол қажет: UDP және TCP
Тасымалдау деңгейінің мүлдем жаңа протоколын енгізу бүгінгі күннің шындығында мүмкін емес міндет екені тез арада белгілі болды. Аппараттық құралдар немесе ортаңғы жәшіктер (маршрутизаторлар, брандмауэрлер, NAT серверлері...) көлік қабаты туралы біледі және оларға жаңа нәрсені үйрету өте қиын міндет болып табылады. Сонымен қатар, тасымалдау протоколдарын қолдау операциялық жүйелердің ядросына енгізілген және ядролар да өзгертуге дайын емес.
Бұл жерде адам қолын көтеріп: «Біз, әрине, артықшылықты және сыпайылықпен жаңа HTTP/3 ойлап табамыз, бірақ оны енгізу үшін 10-15 жыл қажет (шамамен осы уақыттан кейін аппараттық құралдардың көпшілігі ауыстырылды)» дегенмен, тағы бір олай емес анық нұсқа - UDP протоколын пайдалану. Иә, иә, XNUMX-шы жылдардың соңы мен XNUMX-шы жылдардың басында біз файлдарды LAN арқылы лақтыратын бірдей протокол. Онымен қазіргі аппараттық құралдардың барлығы дерлік жұмыс істей алады.
UDP TCP-тен қандай артықшылығы бар? Біріншіден, бізде аппараттық құрал білетін транспорттық деңгей сеансы жоқ. Бұл соңғы нүктелердегі сеансты өзіміз анықтауға және сол жерде қайшылықтарды шешуге мүмкіндік береді. Яғни, біз бір немесе бірнеше сеанстармен шектелмейміз (TCP-дегідей), бірақ олардың қанша қажет болса, соншасын жасай аламыз. Екіншіден, деректерді UDP арқылы жіберу TCP арқылы қарағанда жылдамырақ. Осылайша, теориялық тұрғыдан біз HTTP/2-де қол жеткізілген ағымдағы жылдамдық шегінен өте аламыз.
Дегенмен, UDP сенімді деректерді тасымалдауға кепілдік бермейді. Шын мәнінде, біз жай ғана пакеттерді жіберіп жатырмыз, екінші жағы оларды алады деп үміттенеміз. алған жоқ па? Жақсы, сәттілік жоқ ... Бұл ересектерге арналған бейнелерді жіберу үшін жеткілікті болды, бірақ маңыздырақ нәрселер үшін сізге сенімділік қажет, яғни UDP үстіне тағы бір нәрсені орау керек.
HTTP/2 сияқты, жаңа хаттаманы жасау бойынша жұмыс Google-да 2012 жылы басталды, яғни SPDY бойынша жұмыс басталған кезде шамамен. 2013 жылы Джим Роскинд көпшілікке таныстырды , ал қазірдің өзінде 2015 жылы IETF стандарттау үшін Интернет жобасы енгізілді. Қазірдің өзінде Google-да Роскинд жасаған хаттама стандарттан мүлдем өзгеше болды, сондықтан Google нұсқасы gQUIC деп атала бастады.
QUIC дегеніміз не
Біріншіден, жоғарыда айтылғандай, бұл UDP үстінен орауыш. QUIC қосылымы UDP үстіне көтеріледі, онда HTTP/2 ұқсастығы бойынша бірнеше ағындар болуы мүмкін. Бұл ағындар тек соңғы нүктелерде бар және тәуелсіз қызмет көрсетеді. Егер пакет жоғалуы бір ағында орын алса, ол басқаларға әсер етпейді.
Дэниел Штайнбергтің суреті
Екіншіден, шифрлау енді жеке деңгейде жүзеге асырылмайды, бірақ хаттамаға енгізілген. Бұл бір рет қол алысу кезінде қосылым орнатуға және ашық кілттермен алмасуға мүмкіндік береді, сонымен қатар 0-RTT қол алысу механизмін пайдалануға және қол алысу кешігулерін мүлдем болдырмауға мүмкіндік береді. Сонымен қатар, қазір жеке деректер пакеттерін шифрлауға болады. Бұл ағыннан деректерді қабылдаудың аяқталуын күтпей, алынған пакеттердің шифрын дербес шешуге мүмкіндік береді. Бұл жұмыс режимі TCP-де әдетте мүмкін емес еді, өйткені TLS және TCP бір-бірінен тәуелсіз жұмыс істеді және TLS TCP деректерінің қай бөліктерге кесілетінін біле алмады. Сондықтан ол өз сегменттерін TCP сегменттеріне бір-бірден сыйғызып, дербес шифрын шешуге болатындай етіп дайындай алмады. Барлық осы жақсартулар QUIC-ке TCP-мен салыстырғанда кешіктіруді азайтуға мүмкіндік береді.
Үшіншіден, жарық ағынының тұжырымдамасы қосылымды клиенттің IP мекенжайынан ажыратуға мүмкіндік береді. Бұл, мысалы, клиент бір Wi-Fi кіру нүктесінен екіншісіне ауысқанда, оның IP-ін өзгерткенде маңызды. Бұл жағдайда TCP пайдалану кезінде ұзақ процесс орын алады, оның барысында бар TCP қосылымдары аяқталады және жаңа IP-ден жаңа қосылымдар жасалады. QUIC жағдайында клиент ескі ағын идентификаторы бар жаңа IP-ден серверге пакеттерді жіберуді жалғастырады. Өйткені Ағын идентификаторы енді бірегей және қайта пайдаланылмайды; сервер клиенттің IP өзгерткенін түсінеді, жоғалған пакеттерді қайта жібереді және жаңа мекенжай бойынша байланысты жалғастырады.
Төртіншіден, QUIC операциялық жүйе деңгейінде емес, қолданбалы деңгейде жүзеге асырылады. Бұл, бір жағынан, хаттамаға өзгерістерді жылдам енгізуге мүмкіндік береді, өйткені Жаңартуды алу үшін ОЖ-ның жаңа нұсқасын күтпей, тек кітапхананы жаңарту қажет. Екінші жағынан, бұл процессорды тұтынудың күшті өсуіне әкеледі.
Соңында, тақырыптар. Тақырыпты қысу QUIC және gQUIC арасындағы айырмашылықтардың бірі болып табылады. Мен бұған көп уақыт бөлудің мәнін көрмеймін, тек стандарттау үшін ұсынылған нұсқада тақырыпты сығу HTTP/2 ішіндегі тақырыпты сығуға барынша ұқсас жасалғанын айтайын. Толығырақ оқи аласыз .
Ол қаншалықты жылдам?
Бұл қиын сұрақ. Өйткені, бізде стандарт болғанша, өлшеуге ерекше ештеңе жоқ. Мүмкін бізде жалғыз статистика 2013 және 2016 жылдан бастап gQUIC қолданып келе жатқан Google статистикасы болуы мүмкін. Chrome браузерінен серверлеріне түсетін трафиктің шамамен 90% қазір QUIC пайдаланады. Сол презентацияда олар gQUIC арқылы беттердің шамамен 5%-ға жылдам жүктелетінін және TCP-мен салыстырғанда бейне ағынында 30%-ға аз кептелетінін хабарлайды.
2017 жылы Араш Молави Кахки бастаған зерттеушілер тобы жарық көрді TCP-мен салыстырғанда gQUIC өнімділігін зерттеу.
Зерттеу желілік пакеттерді араластыру тұрақсыздығы, арна өткізу қабілетіне ашкөздік (әділетсіздік) және шағын (10 кб дейін) нысандарды баяу тасымалдау сияқты gQUIC-тің бірнеше әлсіз жақтарын анықтады. Соңғысы 0-RTT арқылы өтелуі мүмкін. Барлық басқа зерттелген жағдайларда gQUIC TCP-мен салыстырғанда жылдамдықтың жоғарылауын көрсетті. Бұл жерде нақты сандар туралы айту қиын. Жақсырақ оқы немесе .
Айта кету керек, бұл деректер нақты gQUIC туралы және әзірленіп жатқан стандартқа қатысты емес. QUIC үшін не болады: бұл әлі құпия, бірақ gQUIC-те анықталған әлсіздіктер ескеріліп, түзетіледі деген үміт бар.
Біраз болашақ: HTTP/3 туралы не деуге болады?
Бірақ мұнда бәрі анық: API ешбір жолмен өзгермейді. Барлығы HTTP/2-дегідей болып қалады. Егер API өзгеріссіз қалса, HTTP/3 нұсқасына өту QUIC тасымалдауын қолдайтын сервердегі кітапхананың жаңа нұсқасын пайдалану арқылы шешілуі керек. Рас, HTTP-тің ескі нұсқаларында қалпына келтіруді біраз уақыт сақтауға тура келеді, өйткені Интернет қазіргі уақытта UDP-ге толық көшуге дайын емес.
Кім қолдайды
осында бар QUIC енгізулері. Стандарттың жоқтығына қарамастан, тізім жаман емес.
Өндіріс шығарылымында қазір ешбір браузер QUIC қолдамайды. Жақында HTTP/3 қолдауы Chrome жүйесіне енгізілгені туралы ақпарат болды, бірақ әзірге тек Канарияда.
Сверхендтердің ішінен HTTP/3 ғана қолдайды и , бірақ әлі де эксперименталды. NGINX 2019 жылдың көктемінің соңында , олар HTTP/3 қолдауында жұмыс істей бастады, бірақ оны әлі аяқтамаған.
Қандай проблемалар бар?
Сіз және мен нақты әлемде өмір сүріп жатырмыз, мұнда ешқандай үлкен технология қарсылыққа тап болмай бұқараға жете алмайды және QUIC де ерекшелік емес.
Ең бастысы, браузерге «https://» енді ол 443 TCP портына апаратын факті емес екенін түсіндіру керек. TCP мүлде болмауы мүмкін. Ол үшін Alt-Svc тақырыбы қолданылады. Ол браузерге бұл веб-сайттың анау-мынау хаттамада мына мекенжайда бар екенін айтуға мүмкіндік береді. Теориялық тұрғыдан бұл сүйкімділік сияқты жұмыс істеуі керек, бірақ іс жүзінде біз DDoS шабуылдарын болдырмау үшін, мысалы, брандмауэрде UDP-ге тыйым салуға болатынын көреміз.
Бірақ UDP тыйым салынбаса да, клиент IP мекенжайы бойынша TCP сеансын өткізуге конфигурацияланған NAT маршрутизаторының артында болуы мүмкін. біз аппараттық сеансы жоқ UDP пайдаланамыз, NAT қосылымды ұстамайды және QUIC сеансы .
Бұл мәселелердің барлығы UDP бұрын Интернет мазмұнын жіберу үшін пайдаланылмағандығына байланысты және аппараттық құралдар өндірушілері мұның ешқашан болатынын болжай алмады. Сол сияқты, әкімшілер QUIC жұмыс істеуі үшін өз желілерін қалай дұрыс конфигурациялау керектігін әлі түсінбейді. Бұл жағдай бірте-бірте өзгереді және кез келген жағдайда мұндай өзгерістер жаңа транспорттық деңгей хаттамасын енгізуге қарағанда аз уақыт алады.
Бұған қоса, жоғарыда сипатталғандай, QUIC процессорды пайдалануды айтарлықтай арттырады. Даниэль Стенберг процессордың өсуі үш есеге дейін.
HTTP/3 қашан келеді?
Стандартты 2020 жылдың мамырына дейін, бірақ 2019 жылдың шілдесіне жоспарланған құжаттар қазіргі уақытта аяқталмағанын ескере отырып, бұл күн кейінге шегерілуі мүмкін деп айта аламыз.
Google өзінің gQUIC енгізуін 2013 жылдан бері пайдаланып келеді. Google іздеу жүйесіне жіберілген HTTP сұрауын қарасаңыз, мынаны көресіз:
қорытындылар
QUIC қазір өте өрескел, бірақ өте перспективалы технологияға ұқсайды. Соңғы 20 жылда транспорттық деңгей хаттамаларының барлық оңтайландырулары негізінен TCP, QUIC-ке қатысты болғанын ескерсек, ол көп жағдайда ең жақсы өнімділікке ие, қазірдің өзінде өте жақсы көрінеді.
Дегенмен, әлі де шешімін таппаған мәселелер бар, оларды алдағы бірнеше жылда шешуге тура келеді. Ешкім жаңартуды ұнатпайтын аппараттық құралдардың болуына байланысты процесс кешіктірілуі мүмкін, бірақ соған қарамастан, барлық мәселелер шешілетін болып көрінеді және ерте ме, кеш пе бәрімізде HTTP/3 болады.
Болашақ жақын жерде!
Ақпарат көзі: www.habr.com