Am fwy nag 20 mlynedd rydym wedi bod yn edrych ar dudalennau gwe gan ddefnyddio'r protocol HTTP. Nid yw'r rhan fwyaf o ddefnyddwyr hyd yn oed yn meddwl beth ydyw a sut mae'n gweithio. Mae eraill yn gwybod bod rhywle o dan HTTP mae TLS, ac o dan hynny mae TCP, o dan y mae IP, ac yn y blaen. Ac mae eraill o hyd - hereticiaid - yn credu bod TCP yn rhywbeth o'r gorffennol; maen nhw eisiau rhywbeth cyflymach, mwy dibynadwy a diogel. Ond yn eu hymdrechion i ddyfeisio protocol delfrydol newydd, maen nhw wedi dychwelyd at dechnoleg yr 80au ac yn ceisio adeiladu eu byd newydd dewr arno.
Ychydig o hanes: HTTP/1.1
Ym 1997, cafodd y protocol cyfnewid gwybodaeth testun HTTP fersiwn 1.1 ei Glwb Rygbi ei hun. Bryd hynny, roedd y protocol wedi'i ddefnyddio gan borwyr ers sawl blwyddyn, ac roedd y safon newydd yn para pymtheg arall. Roedd y protocol yn gweithio ar yr egwyddor cais-ymateb yn unig ac fe'i bwriadwyd yn bennaf ar gyfer trosglwyddo gwybodaeth testun.
Cynlluniwyd HTTP i redeg ar ben y protocol TCP, gan sicrhau bod pecynnau'n cael eu danfon yn ddibynadwy i'w cyrchfan. Mae TCP yn gweithio trwy sefydlu a chynnal cysylltiad dibynadwy rhwng pwyntiau terfyn a rhannu traffig yn segmentau. Mae gan segmentau eu rhif cyfresol a siec eu hunain. Os na fydd un o'r segmentau'n cyrraedd yn sydyn neu'n cyrraedd gyda siec anghywir, yna bydd y trosglwyddiad yn dod i ben nes bod y segment coll yn cael ei adfer.
Yn HTTP/1.0, caewyd y cysylltiad TCP ar ôl pob cais. Roedd hyn yn wastraffus iawn, oherwydd... mae sefydlu cysylltiad TCP (3-Way-Handshake) yn broses araf. Cyflwynodd HTTP/1.1 y mecanwaith cadw'n fyw, sy'n eich galluogi i ailddefnyddio un cysylltiad ar gyfer ceisiadau lluosog. Fodd bynnag, gan y gall ddod yn dagfa yn hawdd, mae gweithrediadau amrywiol HTTP/1.1 yn caniatáu agor cysylltiadau TCP lluosog i'r un gwesteiwr. Er enghraifft, mae Chrome a fersiynau diweddar o Firefox yn caniatáu hyd at chwe chysylltiad.
Roedd amgryptio hefyd i fod i gael ei adael i brotocolau eraill, ac ar gyfer hyn, defnyddiwyd y protocol TLS dros TCP, a oedd yn diogelu'r data yn ddibynadwy, ond a gynyddodd ymhellach yr amser sydd ei angen i sefydlu cysylltiad. O ganlyniad, dechreuodd y broses ysgwyd llaw edrych fel hyn:
Darlun Cloudflare
Felly roedd gan HTTP/1.1 nifer o broblemau:
- Gosod cysylltiad araf.
- Trosglwyddir data ar ffurf testun, sy'n golygu bod trosglwyddo lluniau, fideos a gwybodaeth arall nad yw'n destun yn aneffeithiol.
- Defnyddir un cysylltiad TCP ar gyfer un cais, sy'n golygu bod yn rhaid i geisiadau eraill naill ai ddod o hyd i gysylltiad arall neu aros nes bod y cais presennol yn ei ryddhau.
- Dim ond y model tynnu sy'n cael ei gefnogi. Nid oes dim yn y safon am wthio gweinydd.
- Mae penawdau'n cael eu trosglwyddo mewn testun.
Os yw gweinydd-gwthio yn cael ei weithredu o leiaf gan ddefnyddio protocol WebSocket, yna roedd yn rhaid delio â'r problemau oedd yn weddill yn fwy radical.
Ychydig o foderniaeth: HTTP/2
Yn 2012, dechreuodd Google weithio ar y protocol SPDY (ynganu “cyflym”). Cynlluniwyd y protocol i ddatrys prif broblemau HTTP/1.1 ac ar yr un pryd roedd i fod i gynnal cydnawsedd yn ôl. Yn 2015, cyflwynodd gweithgor IETF y fanyleb HTTP/2 yn seiliedig ar y protocol SPDY. Dyma'r gwahaniaethau yn HTTP/2:
- serialization deuaidd.
- Amlblecsu ceisiadau HTTP lluosog i mewn i un cysylltiad TCP.
- Gweinydd-gwthio allan o'r blwch (heb WebSocket).
Roedd y protocol yn gam mawr ymlaen. Ef yn gryf ac nid oes angen creu cysylltiadau TCP lluosog: mae pob cais i un gwesteiwr yn cael ei amlblecsu yn un. Hynny yw, mewn un cysylltiad mae yna nifer o ffrydiau fel y'u gelwir, ac mae gan bob un ohonynt ei ID ei hun. Y bonws yw gweinydd-gwthio mewn bocsys.
Fodd bynnag, mae amlblecsio yn arwain at broblem allweddol arall. Dychmygwch ein bod yn anghydamserol yn gweithredu 5 cais i un gweinydd. Wrth ddefnyddio HTTP/2, bydd yr holl geisiadau hyn yn cael eu cynnal o fewn yr un cysylltiad TCP, sy'n golygu os bydd un o'r segmentau o unrhyw gais yn cael ei golli neu ei dderbyn yn anghywir, bydd trosglwyddo'r holl geisiadau ac ymatebion yn dod i ben nes bod y segment coll yn cael ei adferedig. Yn amlwg, y gwaethaf yw ansawdd y cysylltiad, yr arafach y mae HTTP/2 yn gweithio. , mewn amodau lle mae pecynnau coll yn cyfrif am 2% o'r holl becynnau, mae HTTP/1.1 yn y porwr yn perfformio'n well na HTTP/2 oherwydd ei fod yn agor 6 cysylltiad yn hytrach nag un.
Gelwir y broblem hon yn “blocio pen llinell” ac, yn anffodus, nid yw'n bosibl ei datrys wrth ddefnyddio TCP.
Darlun gan Daniel Steinberg
O ganlyniad, gwnaeth datblygwyr y safon HTTP/2 waith gwych a gwneud bron popeth y gellid ei wneud ar haen gymhwyso'r model OSI. Mae'n bryd mynd i lawr i'r haen drafnidiaeth a dyfeisio protocol trafnidiaeth newydd.
Mae angen protocol newydd arnom: CDU yn erbyn TCP
Yn weddol gyflym daeth yn amlwg bod gweithredu protocol haen drafnidiaeth hollol newydd yn dasg amhosibl yn realiti heddiw. Y ffaith yw bod caledwedd neu flychau canol (llwybryddion, waliau tân, gweinyddwyr NAT...) yn gwybod am yr haen drafnidiaeth, ac mae dysgu rhywbeth newydd iddynt yn dasg anodd dros ben. Yn ogystal, mae cefnogaeth ar gyfer protocolau trafnidiaeth wedi'i ymgorffori yng nghnewyllyn systemau gweithredu, ac nid yw cnewyllyn hefyd yn barod iawn i newid.
Ac yma fe allech chi daflu eich dwylo i fyny a dweud “Byddwn ni, wrth gwrs, yn dyfeisio HTTP/3 newydd gyda ffafriaeth a chwrteisi, ond bydd yn cymryd 10-15 mlynedd i'w weithredu (ar ôl tua'r amser hwn bydd y rhan fwyaf o'r caledwedd yn cael ei yn ei le),” ond mae un arall ddim felly Yr opsiwn amlwg yw defnyddio protocol y CDU. Ie, ie, yr un protocol a ddefnyddiwyd gennym i daflu ffeiliau dros LAN ar ddiwedd y nawdegau a dechrau'r XNUMXau. Gall bron pob caledwedd heddiw weithio gydag ef.
Beth yw manteision y CDU dros TCP? Yn gyntaf oll, nid oes gennym sesiwn haen trafnidiaeth y mae'r caledwedd yn gwybod amdani. Mae hyn yn ein galluogi i benderfynu ar y sesiwn ar y pwyntiau terfyn ein hunain a datrys gwrthdaro yno. Hynny yw, nid ydym yn gyfyngedig i un neu nifer o sesiynau (fel yn TCP), ond gallwn greu cymaint ohonynt ag sydd ei angen arnom. Yn ail, mae trosglwyddo data trwy CDU yn gyflymach na thrwy TCP. Felly, mewn theori, gallwn dorri trwy'r terfyn cyflymder cyfredol a gyflawnwyd yn HTTP/2.
Fodd bynnag, nid yw CDU yn gwarantu trosglwyddo data dibynadwy. Yn wir, yn syml, rydym yn anfon pecynnau, gan obeithio y bydd y pen arall yn eu derbyn. Heb dderbyn? Wel, dim lwc... Roedd hyn yn ddigon i drosglwyddo fideos i oedolion, ond ar gyfer pethau mwy difrifol mae angen dibynadwyedd, sy'n golygu bod yn rhaid i chi lapio rhywbeth arall ar ben y CDU.
Yn yr un modd â HTTP/2, dechreuodd Google weithio ar greu protocol newydd yn 2012, hynny yw, tua'r un amser ag y dechreuodd y gwaith ar SPDY. Yn 2013, cyflwynodd Jim Roskind i'r cyhoedd , ac eisoes yn 2015 cyflwynwyd Drafft Rhyngrwyd i'w safoni yn yr IETF. Eisoes bryd hynny, roedd y protocol a ddatblygwyd gan Roskind yn Google yn wahanol iawn i'r safon, felly dechreuwyd galw'r fersiwn Google yn gQUIC.
Beth yw QUIC
Yn gyntaf, fel y crybwyllwyd eisoes, mae hwn yn ddeunydd lapio dros y CDU. Mae cysylltiad QUIC yn codi ar ben CDU, lle, trwy gyfatebiaeth â HTTP/2, gall sawl ffrwd fodoli. Dim ond ar y pwyntiau terfyn y mae'r ffrydiau hyn yn bodoli ac fe'u gwasanaethir yn annibynnol. Os bydd colled pecyn yn digwydd mewn un ffrwd, ni fydd yn effeithio ar eraill.
Darlun gan Daniel Steinberg
Yn ail, nid yw amgryptio bellach yn cael ei weithredu ar lefel ar wahân, ond mae wedi'i gynnwys yn y protocol. Mae hyn yn caniatáu ichi sefydlu cysylltiad a chyfnewid allweddi cyhoeddus mewn un ysgwyd llaw, a hefyd yn caniatáu ichi ddefnyddio'r mecanwaith ysgwyd llaw clyfar 0-RTT ac osgoi oedi wrth ysgwyd llaw yn gyfan gwbl. Yn ogystal, mae bellach yn bosibl amgryptio pecynnau data unigol. Mae hyn yn caniatáu ichi beidio ag aros am gwblhau derbyn data o'r ffrwd, ond i ddadgryptio'r pecynnau a dderbyniwyd yn annibynnol. Roedd y dull gweithredu hwn yn gyffredinol amhosibl yn TCP, oherwydd Roedd TLS a TCP yn gweithio'n annibynnol ar ei gilydd, ac ni allai TLS wybod i ba ddarnau y byddai data TCP yn cael eu torri. Ac felly, ni allai baratoi ei segmentau fel eu bod yn ffitio i segmentau TCP un i un a gellid eu dadgryptio'n annibynnol. Mae'r holl welliannau hyn yn caniatáu i QUIC leihau hwyrni o'i gymharu â TCP.
Yn drydydd, mae'r cysyniad o ffrydio golau yn caniatáu ichi ddatgysylltu'r cysylltiad o gyfeiriad IP y cleient. Mae hyn yn bwysig, er enghraifft, pan fydd cleient yn newid o un pwynt mynediad Wi-Fi i un arall, gan newid ei IP. Yn yr achos hwn, wrth ddefnyddio TCP, mae proses hir yn digwydd lle mae cysylltiadau TCP presennol yn dod i ben a chysylltiadau newydd yn cael eu creu o IP newydd. Yn achos QUIC, mae'r cleient yn syml yn parhau i anfon pecynnau i'r gweinydd o IP newydd gyda'r hen ID ffrwd. Achos Mae ID y ffrwd bellach yn unigryw ac nid yw'n cael ei ailddefnyddio; mae'r gweinydd yn deall bod y cleient wedi newid IP, yn ail-anfon pecynnau coll ac yn parhau i gyfathrebu yn y cyfeiriad newydd.
Yn bedwerydd, gweithredir QUIC ar lefel y cais, nid lefel y system weithredu. Mae hyn, ar y naill law, yn caniatáu ichi wneud newidiadau i'r protocol yn gyflym, oherwydd I gael diweddariad, does ond angen i chi ddiweddaru'r llyfrgell, yn hytrach nag aros am fersiwn OS newydd. Ar y llaw arall, mae hyn yn arwain at gynnydd cryf yn y defnydd o broseswyr.
Ac yn olaf, y penawdau. Mae cywasgu penawdau yn un o'r pethau sy'n gwahaniaethu rhwng QUIC a gQUIC. Nid wyf yn gweld y pwynt mewn neilltuo llawer o amser i hyn, byddaf yn dweud yn y fersiwn a gyflwynwyd i'w safoni, bod cywasgu penawdau wedi'i wneud mor debyg â phosibl i gywasgu pennawd yn HTTP/2. Gallwch ddarllen mwy .
Pa mor gyflym yw hi?
Mae'n gwestiwn anodd. Y ffaith yw, hyd nes y bydd gennym safon, nad oes dim byd arbennig i'w fesur. Efallai mai'r unig ystadegau sydd gennym yw ystadegau gan Google, sydd wedi bod yn defnyddio gQUIC ers 2013 ac yn 2016 bod tua 90% o'r traffig sy'n mynd i'w gweinyddwyr o'r porwr Chrome bellach yn defnyddio QUIC. Yn yr un cyflwyniad, maent yn adrodd bod tudalennau'n llwytho tua 5% yn gyflymach trwy gQUIC a bod 30% yn llai o ataliadau mewn ffrydio fideo o gymharu â TCP.
Yn 2017, cyhoeddodd grŵp o ymchwilwyr dan arweiniad Arash Molavi Kakhki i astudio perfformiad gQUIC o'i gymharu â TCP.
Datgelodd yr astudiaeth nifer o wendidau gQUIC, megis ansefydlogrwydd i gymysgu pecynnau rhwydwaith, barusrwydd (annhegwch) i sianeli lled band a throsglwyddo gwrthrychau bach (hyd at 10 kb) yn arafach. Fodd bynnag, gellir gwneud iawn am yr olaf trwy ddefnyddio 0-RTT. Ym mhob achos arall a astudiwyd, dangosodd gQUIC gynnydd mewn cyflymder o gymharu â TCP. Mae'n anodd siarad am rifau penodol yma. Gwell darllen neu .
Yma mae'n rhaid dweud bod y data hwn yn ymwneud yn benodol â gQUIC, ac nid yw'n berthnasol i'r safon sy'n cael ei datblygu. Beth fydd yn digwydd i QUIC: mae’n gyfrinach o hyd, ond mae gobaith y bydd y gwendidau a nodwyd yn gQUIC yn cael eu hystyried a’u cywiro.
Ychydig o'r dyfodol: beth am HTTP/3?
Ond yma mae popeth yn grisial glir: ni fydd yr API yn newid mewn unrhyw ffordd. Bydd popeth yn aros yn union yr un fath ag yr oedd yn HTTP/2. Wel, os yw'r API yn aros yr un fath, bydd yn rhaid datrys y newid i HTTP/3 trwy ddefnyddio fersiwn newydd o'r llyfrgell ar yr ôl-wyneb sy'n cefnogi cludiant QUIC. Yn wir, bydd yn rhaid i chi gadw'r wrth gefn ar hen fersiynau o HTTP am gryn amser, oherwydd Nid yw'r Rhyngrwyd yn barod ar hyn o bryd ar gyfer trosglwyddo'n llwyr i'r CDU.
Pwy sydd eisoes yn cefnogi
Yma gweithrediadau QUIC presennol. Er gwaethaf y diffyg safon, nid yw'r rhestr yn ddrwg.
Nid oes unrhyw borwr yn cefnogi QUIC mewn datganiad cynhyrchu ar hyn o bryd. Yn ddiweddar cafwyd gwybodaeth bod cefnogaeth i HTTP/3 wedi'i gynnwys yn Chrome, ond hyd yn hyn dim ond yn Canary.
O'r backends, mae HTTP/3 yn cefnogi yn unig и , ond yn dal yn arbrofol. NGINX ar ddiwedd gwanwyn 2019 , eu bod wedi dechrau gweithio ar gefnogaeth HTTP/3, ond heb ei orffen eto.
Beth yw'r problemau?
Rydych chi a minnau'n byw yn y byd go iawn, lle na all unrhyw dechnoleg fawr gyrraedd y llu heb gwrdd â gwrthiant, ac nid yw QUIC yn eithriad.
Y peth pwysicaf yw bod angen i chi rywsut esbonio i'r porwr nad yw “https: //” bellach yn ffaith ei fod yn arwain at borthladd TCP 443. Efallai na fydd TCP o gwbl. Defnyddir y pennawd Alt-Svc ar gyfer hyn. Mae'n caniatáu ichi ddweud wrth y porwr bod y wefan hon hefyd ar gael ar brotocol o'r fath ac mewn cyfeiriad o'r fath. Mewn theori, dylai hyn weithio fel swyn, ond yn ymarferol byddwn yn dod ar draws y ffaith y gall CDU, er enghraifft, gael ei wahardd ar wal dân i osgoi ymosodiadau DDoS.
Ond hyd yn oed os na waherddir CDU, gall y cleient fod y tu ôl i lwybrydd NAT sydd wedi'i ffurfweddu i gynnal sesiwn TCP yn ôl cyfeiriad IP, ac ers hynny rydym yn defnyddio CDU, sydd heb sesiwn caledwedd, ni fydd NAT yn dal y cysylltiad, a sesiwn QUIC .
Mae'r holl broblemau hyn oherwydd y ffaith nad oedd CDU wedi'i ddefnyddio o'r blaen i drosglwyddo cynnwys Rhyngrwyd, ac ni allai gweithgynhyrchwyr caledwedd ragweld y byddai hyn byth yn digwydd. Yn yr un modd, nid yw gweinyddwyr yn deall mewn gwirionedd sut i ffurfweddu eu rhwydweithiau yn gywir er mwyn i QUIC weithio. Bydd y sefyllfa hon yn newid yn raddol, a, beth bynnag, bydd newidiadau o'r fath yn cymryd llai o amser na gweithredu protocol haen trafnidiaeth newydd.
Yn ogystal, fel y disgrifiwyd eisoes, mae QUIC yn cynyddu'r defnydd o CPU yn fawr. Daniel Stenberg twf prosesydd hyd at dair gwaith.
Pryd fydd HTTP/3 yn cyrraedd?
Safon erbyn mis Mai 2020, ond o ystyried bod dogfennau a drefnwyd ar gyfer Gorffennaf 2019 yn parhau i fod heb eu gorffen ar hyn o bryd, gallwn ddweud y bydd y dyddiad yn fwyaf tebygol o gael ei wthio yn ôl.
Wel, mae Google wedi bod yn defnyddio ei weithrediad gQUIC ers 2013. Os edrychwch ar y cais HTTP sy'n cael ei anfon i beiriant chwilio Google, fe welwch hwn:
Canfyddiadau
Mae QUIC bellach yn edrych fel technoleg braidd yn amrwd, ond yn addawol iawn. O ystyried, yn ystod yr 20 mlynedd diwethaf, fod pob optimizations o brotocolau haenau trafnidiaeth wedi ymwneud yn bennaf â TCP, QUIC, sydd â'r perfformiad gorau yn y rhan fwyaf o achosion, eisoes yn edrych yn eithriadol o dda.
Fodd bynnag, mae problemau heb eu datrys o hyd y bydd yn rhaid ymdrin â nhw yn yr ychydig flynyddoedd nesaf. Efallai y bydd y broses yn cael ei gohirio oherwydd y ffaith bod yna galedwedd, nad oes neb yn hoffi ei ddiweddaru, ond serch hynny, mae'r holl broblemau'n edrych yn eithaf solvable, ac yn hwyr neu'n hwyrach bydd gennym ni i gyd HTTP/3.
Mae'r dyfodol rownd y gornel!
Ffynhonnell: hab.com