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-ийн сүүлийн хувилбарууд нь XNUMX хүртэлх холболтыг зөвшөөрдөг.
Шифрлэлтийг бусад протоколд үлдээх ёстой байсан бөгөөд үүний тулд TLS протоколыг TCP дээр ашигласан бөгөөд энэ нь өгөгдлийг найдвартай хамгаалсан боловч холболт үүсгэхэд шаардагдах хугацааг улам нэмэгдүүлсэн. Үүний үр дүнд гар барих үйл явц дараах байдлаар харагдаж эхлэв.
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 холболт үүсгэх шаардлагагүй: нэг хост руу илгээсэн бүх хүсэлтийг нэг болгон олон талт болгодог. Өөрөөр хэлбэл, нэг холболтонд хэд хэдэн урсгал гэж нэрлэгддэг урсгалууд байдаг бөгөөд тус бүр нь өөрийн ID-тай байдаг. Бонус нь хайрцагласан сервер түлхэлт юм.
Гэсэн хэдий ч мультиплекс хийх нь өөр нэг гол асуудалд хүргэдэг. Бид нэг серверт 5 хүсэлтийг асинхроноор гүйцэтгэж байна гэж төсөөлөөд үз дээ. HTTP/2-г ашиглах үед эдгээр бүх хүсэлтүүд нь ижил TCP холболтын хүрээнд хийгдэх бөгөөд хэрэв хүсэлтийн аль нэг хэсэг алдагдсан эсвэл буруу хүлээн авбал бүх хүсэлт, хариултын дамжуулалт алдагдсан сегмент болох хүртэл зогсох болно. сэргээгдсэн. Мэдээжийн хэрэг, холболтын чанар муу байх тусам HTTP/2 удааширна. , алдагдсан пакетууд нь нийт пакетуудын 2%-ийг эзэлдэг нөхцөлд хөтөч дээрх HTTP/1.1 нь нэг биш 2 холболт нээдэг тул HTTP/6-оос илүү сайн ажилладаг.
Энэ асуудлыг "head-of-line blocking" гэж нэрлэдэг бөгөөд харамсалтай нь TCP ашиглах үед үүнийг шийдвэрлэх боломжгүй юм.
Дэниел Стайнберг зурсан
Үүний үр дүнд HTTP/2 стандартыг хөгжүүлэгчид маш сайн ажиллаж, OSI загварын хэрэглээний давхарга дээр хийж болох бараг бүх зүйлийг хийсэн. Тээврийн давхарга руу бууж, шинэ тээврийн протокол зохион бүтээх цаг болжээ.
Бидэнд шинэ протокол хэрэгтэй байна: UDP vs TCP
Тээврийн түвшний цоо шинэ протоколыг хэрэгжүүлэх нь өнөөгийн бодит байдалд боломжгүй ажил болох нь маш хурдан тодорхой болсон. Техник хангамж эсвэл дунд хайрцаг (чиглүүлэгч, галт хана, NAT сервер...) нь тээврийн давхаргын талаар мэддэг бөгөөд тэдэнд шинэ зүйл заах нь туйлын хэцүү ажил юм. Нэмж дурдахад, тээвэрлэлтийн протоколуудын дэмжлэг нь үйлдлийн системийн цөмд холбогдсон байдаг бөгөөд цөм нь өөрчлөгдөхөд тийм ч бэлэн байдаггүй.
Энд хэн нэгэн гараа өргөөд "Бид мэдээжийн хэрэг, шинэ HTTP/3-ийг давуу эрх, эелдэг байдлаар зохион бүтээх болно, гэхдээ үүнийг хэрэгжүүлэхэд 10-15 жил шаардлагатай (энэ хугацааны дараа ихэнх техник хангамж хийгдэх болно). солигдсон)," гэхдээ өөр нэг тийм биш байна. Мэдээжийн хэрэг, UDP протоколыг ашиглах явдал юм. Тийм ээ, тийм ээ, ерээд оны сүүл, 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-ийн хувьд үйлчлүүлэгч хуучин урсгалын ID-тай шинэ IP-ээс сервер рүү пакетуудыг үргэлжлүүлэн илгээдэг. Учир нь Дамжуулалтын ID нь одоо өвөрмөц бөгөөд дахин ашиглагдахгүй; сервер нь үйлчлүүлэгч IP-г өөрчилсөн гэдгийг ойлгож, алдагдсан пакетуудыг дахин илгээж, шинэ хаягаар харилцаагаа үргэлжлүүлнэ.
Дөрөвдүгээрт, QUIC нь үйлдлийн системийн түвшинд биш хэрэглээний түвшинд хэрэгждэг. Энэ нь нэг талаас, протоколд хурдан өөрчлөлт оруулах боломжийг олгодог, учир нь Шинэчлэлт авахын тулд та үйлдлийн системийн шинэ хувилбарыг хүлээхээс илүүтэйгээр номын санг шинэчлэх хэрэгтэй. Нөгөөтэйгүүр, энэ нь процессорын хэрэглээг хүчтэй нэмэгдүүлэхэд хүргэдэг.
Тэгээд эцэст нь гарчиг. Толгойн шахалт нь QUIC болон gQUIC хоёрын хооронд ялгаатай зүйлүүдийн нэг юм. Би үүнд их цаг зарцуулах нь утгагүй гэдгийг би зүгээр л хэлье, стандартчилахаар оруулсан хувилбарт толгой хэсгийг шахах нь HTTP/2 дахь толгойн шахалттай аль болох адилхан хийгдсэн гэдгийг хэлье. Та илүү ихийг уншиж болно .
Хэр хурдан вэ?
Хэцүү асуулт байна. Баримт нь бид стандарттай болтол хэмжих онцгой зүйл байхгүй. Магадгүй бидэнд байгаа цорын ганц статистик бол 2013, 2016 оноос хойш gQUIC ашиглаж байгаа Google-ийн статистик мэдээлэл байж магадгүй юм. Chrome хөтчөөс сервер рүүгээ орж байгаа траффикийн 90 орчим хувь нь одоо QUIC ашиглаж байна. Үүнтэй ижил танилцуулгад тэд gQUIC-ээр дамжуулан хуудсууд ойролцоогоор 5%-иар хурдан ачаалагддаг бөгөөд TCP-тэй харьцуулахад видео цацалтад гацах нь 30%-иар бага байгааг мэдээлсэн.
2017 онд Араш Молави Кахки тэргүүтэй хэсэг судлаачид нийтлэв TCP-тэй харьцуулахад gQUIC-ийн гүйцэтгэлийг судлах.
Судалгаагаар gQUIC-ийн хэд хэдэн сул талууд, тухайлбал сүлжээний пакетуудыг холих тогтворгүй байдал, сувгийн зурвасын өргөнд шунахайрах (шударга бус байдал), жижиг (10 кб хүртэл) объектуудын дамжуулалт удаашрах зэрэг хэд хэдэн сул талууд илэрсэн. Сүүлийнх нь 0-RTT ашиглан нөхөж болно. Судалгаанд хамрагдсан бусад бүх тохиолдлуудад gQUIC нь TCP-тэй харьцуулахад хурдны өсөлтийг харуулсан. Энд тодорхой тооны талаар ярихад хэцүү байдаг. Уншсан нь дээр буюу .
Энэ өгөгдөл нь gQUIC-ийн тухай бөгөөд боловсруулж буй стандартад хамааралгүй гэдгийг энд хэлэх ёстой. QUIC-д юу тохиолдох вэ: энэ нь нууц хэвээр байгаа ч gQUIC-д тодорхойлсон сул талуудыг харгалзан үзэж, засч залруулах болно гэж найдаж байна.
Ирээдүйн тухай: HTTP/3-ийн талаар юу хэлэх вэ?
Гэхдээ энд бүх зүйл тодорхой байна: API ямар ч байдлаар өөрчлөгдөхгүй. Бүх зүйл HTTP/2 дээр байсантай яг адилхан хэвээр байх болно. Хэрэв API хэвээр байвал HTTP/3 руу шилжих асуудлыг QUIC тээвэрлэлтийг дэмждэг backend дээрх номын сангийн шинэ хувилбарыг ашиглан шийдэх шаардлагатай болно. Үнэн бол та HTTP-ийн хуучин хувилбаруудын нөөцийг нэлээд удаан хадгалах хэрэгтэй болно, учир нь Интернет нь одоогоор UDP руу бүрэн шилжихэд бэлэн биш байна.
Хэн аль хэдийн дэмждэг
энд одоо байгаа QUIC хэрэгжүүлэлтүүд. Хэдийгээр стандарт байхгүй ч жагсаалт нь муу биш юм.
Одоогоор ямар ч хөтөч үйлдвэрлэлийн хувилбарт QUIC-г дэмждэггүй. Саяхан HTTP/3-ийн дэмжлэгийг Chrome-д оруулсан гэсэн мэдээлэл гарч байсан ч одоогоор зөвхөн Канарид байдаг.
Backends дотроос HTTP/3 нь зөвхөн дэмждэг и , гэхдээ туршилтын хэвээр байна. NGINX 2019 оны хаврын сүүлээр , тэд HTTP/3 дэмжлэг дээр ажиллаж эхэлсэн боловч хараахан дуусгаагүй байна.
Ямар асуудал тулгарч байна вэ?
Та бид хоёр эсэргүүцэлтэй тулгарахгүйгээр ямар ч том технологи олон нийтэд хүрч чадахгүй, QUIC ч үл хамаарах бодит ертөнцөд амьдарч байна.
Хамгийн чухал зүйл бол "https://" нь TCP 443 порт руу хөтлөх баримт байхаа больсон гэдгийг та ямар нэгэн байдлаар хөтөчдөө тайлбарлах хэрэгтэй. TCP огт байхгүй байж магадгүй. Үүний тулд Alt-Svc толгойг ашигладаг. Энэ нь вэб сайт нь ийм ийм протокол дээр ийм, тийм хаягаар байдаг гэдгийг хөтөчдөө хэлэх боломжийг танд олгоно. Онолын хувьд энэ нь сэтгэл татам мэт ажиллах ёстой боловч практик дээр DDoS халдлагаас зайлсхийхийн тулд UDP-г галт хананд хориглох боломжтой гэдгийг бид олж мэдэх болно.
Хэдийгээр UDP-г хориглоогүй байсан ч үйлчлүүлэгч нь IP хаягаар TCP сессийг явуулахаар тохируулсан NAT чиглүүлэгчийн ард байж болно. Бид UDP-г ашигладаг бөгөөд энэ нь техник хангамжийн сесс байхгүй, NAT холболтыг барихгүй бөгөөд QUIC сессийг ашигладаг .
Эдгээр бүх бэрхшээлүүд нь UDP-ийг өмнө нь интернетийн агуулгыг дамжуулахад ашигладаггүй байсантай холбоотой бөгөөд тоног төхөөрөмжийн үйлдвэрлэгчид ийм зүйл тохиолдохыг урьдчилан таамаглах боломжгүй байсан. Үүний нэгэн адил администраторууд QUIC-г ажиллуулахын тулд сүлжээгээ хэрхэн зөв тохируулахаа хараахан ойлгоогүй байна. Энэ нөхцөл байдал аажмаар өөрчлөгдөх бөгөөд ямар ч тохиолдолд ийм өөрчлөлт нь шинэ тээврийн түвшний протоколыг хэрэгжүүлэхээс бага хугацаа шаардагдах болно.
Нэмж дурдахад QUIC нь CPU-ийн хэрэглээг ихээхэн нэмэгдүүлдэг. Даниел Стенберг процессорын өсөлт XNUMX дахин их байна.
HTTP/3 хэзээ ирэх вэ?
Стандарт 2020 оны 2019-р сар гэхэд XNUMX оны XNUMX-р сард төлөвлөсөн бичиг баримтууд одоогоор дуусаагүй байгаа тул огноо хойшлогдох магадлал өндөр байна гэж бид хэлж чадна.
Google 2013 оноос хойш gQUIC хэрэгжүүлэлтийг ашиглаж байна. Хэрэв та Google хайлтын систем рүү илгээсэн HTTP хүсэлтийг харвал дараах зүйлийг харах болно.
үр дүн нь
QUIC нь одоо нэлээд бүдүүлэг, гэхдээ маш ирээдүйтэй технологи шиг харагдаж байна. Сүүлийн 20 жилийн хугацаанд тээврийн давхаргын протоколуудын бүх оновчлол нь ихэвчлэн TCP, QUIC-д хамааралтай байсан бөгөөд ихэнх тохиолдолд хамгийн сайн гүйцэтгэлтэй байдаг нь аль хэдийн маш сайн харагдаж байна.
Гэсэн хэдий ч ойрын хэдэн жилд шийдвэрлэх ёстой шийдэгдээгүй асуудлууд байсаар байна. Хэн ч шинэчлэх дургүй техник хангамж байгаа тул процесс хойшлогдож магадгүй ч бүх асуудал шийдэгдэх боломжтой бөгөөд эрт орой хэзээ нэгэн цагт бид бүгд HTTP/3-тэй болно.
Ирээдүй яг л булан тойроод байна!
Эх сурвалж: www.habr.com