Kwa zaidi ya miaka 20 tumekuwa tukitazama kurasa za wavuti kwa kutumia itifaki ya HTTP. Watumiaji wengi hata hawafikirii ni nini na jinsi inavyofanya kazi. Wengine wanajua kuwa mahali fulani chini ya HTTP kuna TLS, na chini ya hiyo ni TCP, chini ambayo ni IP, na kadhalika. Na bado wengine - wazushi - wanaamini kwamba TCP ni jambo la zamani; wanataka kitu cha haraka, cha kuaminika zaidi na salama. Lakini katika majaribio yao ya kuunda itifaki mpya bora, wamerudi kwenye teknolojia ya miaka ya 80 na wanajaribu kujenga ulimwengu wao mpya wa ujasiri juu yake.
Historia kidogo: HTTP/1.1
Mnamo 1997, itifaki ya kubadilishana habari ya maandishi HTTP toleo la 1.1 ilipata RFC yake mwenyewe. Wakati huo, itifaki ilikuwa imetumiwa na vivinjari kwa miaka kadhaa, na kiwango kipya kilidumu kumi na tano nyingine. Itifaki ilifanya kazi tu juu ya kanuni ya ombi-jibu na ilikusudiwa hasa kwa usambazaji wa habari za maandishi.
HTTP iliundwa ili kuendeshwa juu ya itifaki ya TCP, ili kuhakikisha kwamba pakiti zinawasilishwa kwa njia ya kuaminika hadi zinapoenda. TCP hufanya kazi kwa kuanzisha na kudumisha muunganisho wa kuaminika kati ya vituo vya mwisho na kuvunja trafiki katika sehemu. Sehemu zina nambari zao za serial na hundi. Ikiwa ghafla moja ya makundi haifiki au inakuja na checksum isiyo sahihi, basi maambukizi yataacha mpaka sehemu iliyopotea irejeshwe.
Katika HTTP/1.0, muunganisho wa TCP ulifungwa baada ya kila ombi. Hii ilikuwa ni ubadhirifu sana, kwa sababu ... kuanzisha muunganisho wa TCP (3-Way-Handshake) ni mchakato wa polepole. HTTP/1.1 ilianzisha utaratibu wa kuweka hai, ambao hukuruhusu kutumia tena muunganisho mmoja kwa maombi mengi. Hata hivyo, kwa kuwa inaweza kuwa kizuizi kwa urahisi, utekelezaji mbalimbali wa HTTP/1.1 huruhusu miunganisho mingi ya TCP kufunguliwa kwa seva pangishi sawa. Kwa mfano, Chrome na matoleo ya hivi karibuni ya Firefox huruhusu hadi miunganisho sita.
Usimbaji fiche pia ulitakiwa kuachwa kwa itifaki nyingine, na kwa hili, itifaki ya TLS ilitumiwa juu ya TCP, ambayo ililinda data kwa uaminifu, lakini iliongeza zaidi wakati unaohitajika kuanzisha muunganisho. Kama matokeo, mchakato wa kupeana mikono ulianza kuonekana kama hii:
Mchoro wa Cloudflare
Kwa hivyo HTTP/1.1 ilikuwa na shida kadhaa:
- Usanidi wa polepole wa muunganisho.
- Data hupitishwa kwa njia ya maandishi, ambayo inamaanisha kuwa uwasilishaji wa picha, video na habari zingine zisizo za maandishi hazifanyi kazi.
- Muunganisho mmoja wa TCP hutumiwa kwa ombi moja, ambayo ina maana kwamba maombi mengine lazima yapate muunganisho mwingine au kusubiri hadi ombi la sasa liiachilie.
- Ni mfano wa kuvuta tu ndio unaoungwa mkono. Hakuna kitu katika kiwango juu ya kushinikiza kwa seva.
- Vichwa vinatumwa kwa maandishi.
Iwapo msukumo wa seva unatekelezwa angalau kwa kutumia itifaki ya WebSocket, basi matatizo yaliyosalia yalipaswa kushughulikiwa kwa kiasi kikubwa zaidi.
Usasa kidogo: HTTP/2
Mnamo 2012, Google ilianza kufanya kazi kwenye itifaki ya SPDY (inayotamkwa "kasi"). Itifaki iliundwa ili kutatua matatizo makuu ya HTTP/1.1 na wakati huo huo ilitakiwa kudumisha utangamano wa nyuma. Mnamo 2015, kikundi cha kazi cha IETF kilianzisha vipimo vya HTTP/2 kulingana na itifaki ya SPDY. Hapa kuna tofauti katika HTTP/2:
- Usambazaji wa binary.
- Kuongeza maombi mengi ya HTTP kwenye muunganisho mmoja wa TCP.
- Seva-sukuma nje ya kisanduku (bila WebSocket).
Itifaki ilikuwa hatua kubwa mbele. Yeye kwa nguvu na hauhitaji uundaji wa miunganisho mingi ya TCP: maombi yote kwa seva pangishi moja yameongezwa kwa moja. Hiyo ni, katika uhusiano mmoja kuna mito kadhaa inayoitwa, ambayo kila mmoja ina kitambulisho chake. Bonasi ni kushinikiza kwa seva iliyo na sanduku.
Walakini, kuzidisha kunasababisha shida nyingine muhimu. Fikiria kuwa tunatekeleza ombi 5 kwa seva moja kwa usawa. Wakati wa kutumia HTTP/2, maombi haya yote yatafanyika ndani ya uunganisho sawa wa TCP, ambayo ina maana kwamba ikiwa moja ya sehemu za ombi lolote limepotea au kupokelewa vibaya, uwasilishaji wa maombi na majibu yote utaacha hadi sehemu iliyopotea itakapopatikana. kurejeshwa. Kwa wazi, ubora wa uunganisho mbaya zaidi, polepole HTTP/2 hufanya kazi. , katika hali ambapo pakiti zilizopotea zinahesabu 2% ya pakiti zote, HTTP/1.1 kwenye kivinjari hufanya vizuri zaidi kuliko HTTP/2 kutokana na ukweli kwamba inafungua miunganisho 6 badala ya moja.
Tatizo hili linaitwa "kuzuia kichwa cha mstari" na, kwa bahati mbaya, haiwezekani kutatua wakati wa kutumia TCP.
Mchoro na Daniel Steinberg
Matokeo yake, watengenezaji wa kiwango cha HTTP/2 walifanya kazi nzuri na walifanya karibu kila kitu ambacho kinaweza kufanywa kwenye safu ya maombi ya mfano wa OSI. Ni wakati wa kwenda chini kwa safu ya usafiri na kuvumbua itifaki mpya ya usafiri.
Tunahitaji itifaki mpya: UDP dhidi ya TCP
Haraka kabisa ikawa wazi kwamba kutekeleza itifaki mpya kabisa ya safu ya usafiri ni kazi isiyowezekana katika hali halisi ya leo. Ukweli ni kwamba vifaa au masanduku ya kati (ruta, ngome, seva za NAT ...) wanajua juu ya safu ya usafirishaji, na kuwafundisha kitu kipya ni kazi ngumu sana. Kwa kuongeza, usaidizi wa itifaki za usafiri hujengwa kwenye kernel ya mifumo ya uendeshaji, na kernels pia haziko tayari sana kubadilika.
Na hapa mtu anaweza kurusha mikono yake juu na kusema "Sisi, bila shaka, tutavumbua HTTP/3 mpya kwa upendeleo na wasaidizi, lakini itachukua miaka 10-15 kutekelezwa (baada ya karibu wakati huu vifaa vingi vitakuwa. kubadilishwa)," lakini kuna moja zaidi sio hivyo Chaguo dhahiri ni kutumia itifaki ya UDP. Ndiyo, ndiyo, itifaki ile ile tuliyotumia kutupa faili kwenye LAN mwishoni mwa miaka ya tisini na mwanzoni mwa miaka ya XNUMX. Karibu vifaa vyote vya leo vinaweza kufanya kazi nayo.
Je, ni faida gani za UDP juu ya TCP? Kwanza kabisa, hatuna kikao cha safu ya usafiri ambacho vifaa vinajua. Hili huturuhusu kubainisha kipindi kwenye miisho sisi wenyewe na kutatua mizozo hapo. Hiyo ni, hatuzuiliwi kwa kikao kimoja au kadhaa (kama katika TCP), lakini tunaweza kuunda nyingi kama tunavyohitaji. Pili, uwasilishaji wa data kupitia UDP ni haraka kuliko kupitia TCP. Kwa hivyo, kwa nadharia, tunaweza kuvunja dari ya kasi ya sasa iliyopatikana katika HTTP/2.
Hata hivyo, UDP haihakikishi upitishaji wa data unaotegemewa. Kwa kweli, tunatuma pakiti tu, tukitumaini kwamba mwisho mwingine utazipokea. Je, si kupokea? Sawa, hakuna bahati... Hii ilitosha kusambaza video kwa watu wazima, lakini kwa mambo mazito zaidi unahitaji kutegemewa, ambayo inamaanisha lazima ufunge kitu kingine juu ya UDP.
Kama ilivyo kwa HTTP/2, kazi ya kuunda itifaki mpya ilianza huko Google mnamo 2012, ambayo ni, karibu wakati huo huo kazi kwenye SPDY ilipoanza. Mnamo 2013, Jim Roskind aliwasilisha kwa umma , na tayari mwaka 2015 Rasimu ya Mtandao ilianzishwa kwa ajili ya kusawazisha katika IETF. Tayari wakati huo, itifaki iliyotengenezwa na Roskind huko Google ilikuwa tofauti sana na kiwango, hivyo toleo la Google lilianza kuitwa gQUIC.
QUIC ni nini
Kwanza, kama ilivyotajwa tayari, hii ni kifuniko juu ya UDP. Muunganisho wa QUIC huinuka juu ya UDP, ambayo, kwa mlinganisho na HTTP/2, mitiririko kadhaa inaweza kuwepo. Mitiririko hii ipo kwenye sehemu za mwisho pekee na inahudumiwa kwa kujitegemea. Ikiwa upotezaji wa pakiti hutokea kwenye mkondo mmoja, hautaathiri wengine.
Mchoro na Daniel Steinberg
Pili, usimbaji fiche hautekelezwi tena kwa kiwango tofauti, lakini umejumuishwa kwenye itifaki. Hii hukuruhusu kuanzisha muunganisho na kubadilishana funguo za umma kwa kupeana mkono mara moja, na pia hukuruhusu kutumia utaratibu wa kupeana mkono wa 0-RTT na kuepuka ucheleweshaji wa kupeana mkono kabisa. Kwa kuongeza, sasa inawezekana kusimba pakiti za data za kibinafsi. Hii hukuruhusu kungoja kukamilika kwa kupokea data kutoka kwa mkondo, lakini kusimbua pakiti zilizopokelewa kwa kujitegemea. Njia hii ya uendeshaji kwa ujumla haikuwezekana katika TCP, kwa sababu TLS na TCP zilifanya kazi kwa kujitegemea, na TLS haikuweza kujua ni vipande vipi data ya TCP ingekatwa. Na kwa hivyo, hakuweza kuandaa sehemu zake ili zilingane na sehemu za TCP moja hadi moja na ziweze kufutwa kwa kujitegemea. Maboresho haya yote huruhusu QUIC kupunguza muda wa kusubiri ikilinganishwa na TCP.
Tatu, dhana ya utiririshaji mwanga hukuruhusu kutenganisha muunganisho kutoka kwa anwani ya IP ya mteja. Hii ni muhimu, kwa mfano, wakati mteja anabadilisha kutoka kwa sehemu moja ya kufikia Wi-Fi hadi nyingine, kubadilisha IP yake. Katika kesi hii, wakati wa kutumia TCP, mchakato mrefu hutokea wakati miunganisho iliyopo ya TCP inaisha na miunganisho mpya huundwa kutoka kwa IP mpya. Kwa upande wa QUIC, mteja anaendelea tu kutuma pakiti kwa seva kutoka kwa IP mpya na kitambulisho cha zamani cha mtiririko. Kwa sababu Kitambulisho cha mtiririko sasa ni cha kipekee na hakitumiki tena; seva inaelewa kuwa mteja amebadilisha IP, hutuma tena pakiti zilizopotea na huendeleza mawasiliano kwenye anwani mpya.
Nne, QUIC inatekelezwa katika kiwango cha maombi, sio kiwango cha mfumo wa uendeshaji. Hii, kwa upande mmoja, inakuwezesha kufanya mabadiliko haraka kwa itifaki, kwa sababu Ili kupata sasisho, unahitaji tu kusasisha maktaba, badala ya kusubiri toleo jipya la OS. Kwa upande mwingine, hii inasababisha ongezeko kubwa la matumizi ya processor.
Na hatimaye, vichwa vya habari. Mfinyazo wa vichwa ni mojawapo ya mambo ambayo hutofautiana kati ya QUIC na gQUIC. Sioni maana ya kutumia muda mwingi kwa hili, nitasema tu kwamba katika toleo lililowasilishwa kwa ajili ya kusawazisha, ukandamizaji wa kichwa ulifanywa sawa iwezekanavyo na ukandamizaji wa kichwa katika HTTP/2. Unaweza kusoma zaidi .
Je, ni kasi gani?
Ni swali gumu. Ukweli ni kwamba mpaka tuwe na kiwango, hakuna kitu maalum cha kupima. Labda takwimu pekee tulizonazo ni takwimu kutoka Google, ambayo imekuwa ikitumia gQUIC tangu 2013 na 2016. kwamba takriban 90% ya trafiki inayoenda kwenye seva zao kutoka kwa kivinjari cha Chrome sasa inatumia QUIC. Katika wasilisho sawa, wanaripoti kuwa kurasa hupakia takriban 5% kwa kasi zaidi kupitia gQUIC na kuna vigugumizi vichache kwa 30% katika utiririshaji wa video ikilinganishwa na TCP.
Mnamo 2017, kikundi cha watafiti kilichoongozwa na Arash Molavi Kakhki kilichapishwa kusoma utendaji wa gQUIC ikilinganishwa na TCP.
Utafiti ulifunua udhaifu kadhaa wa gQUIC, kama vile kukosekana kwa uthabiti kwa uchanganyaji wa pakiti za mtandao, uchoyo (ukosefu) wa kipimo data cha chaneli na uhamishaji wa polepole wa vitu vidogo (hadi kb 10). Mwisho, hata hivyo, unaweza kulipwa kwa kutumia 0-RTT. Katika visa vingine vyote vilivyosomwa, gQUIC ilionyesha ongezeko la kasi ikilinganishwa na TCP. Ni ngumu kuzungumza juu ya nambari maalum hapa. Bora kusoma au .
Hapa ni lazima kusema kwamba data hii ni hasa kuhusu gQUIC, na haifai kwa kiwango kinachotengenezwa. Nini kitatokea kwa QUIC: bado ni siri, lakini kuna matumaini kwamba udhaifu ulioainishwa katika gQUIC utazingatiwa na kusahihishwa.
Kidogo cha siku zijazo: vipi kuhusu HTTP/3?
Lakini hapa kila kitu ni wazi kabisa: API haitabadilika kwa njia yoyote. Kila kitu kitabaki sawa na ilivyokuwa katika HTTP/2. Naam, ikiwa API itabaki vile vile, mpito kwa HTTP/3 italazimika kutatuliwa kwa kutumia toleo jipya la maktaba kwenye sehemu ya nyuma inayoauni usafiri wa QUIC. Kweli, itabidi uhifadhi kurudi nyuma kwa matoleo ya zamani ya HTTP kwa muda mrefu, kwa sababu Mtandao kwa sasa hauko tayari kwa ubadilishaji kamili hadi UDP.
Ambao tayari wanaunga mkono
Hapa Utekelezaji uliopo wa QUIC. Licha ya ukosefu wa kiwango, orodha sio mbaya.
Hakuna kivinjari kinachotumia QUIC kwa sasa katika toleo la umma. Hivi majuzi kulikuwa na habari kwamba usaidizi wa HTTP/3 ulijumuishwa kwenye Chrome, lakini hadi sasa tu katika Canary.
Kati ya sehemu za nyuma, HTTP/3 inasaidia tu ΠΈ , lakini bado ni majaribio. NGINX mwishoni mwa masika 2019 , kwamba walianza kufanya kazi kwenye usaidizi wa HTTP/3, lakini bado hawajaimaliza.
Je, ni matatizo gani?
Wewe na mimi tunaishi katika ulimwengu wa kweli, ambapo hakuna teknolojia kubwa inayoweza kufikia umati bila upinzani wa kukutana, na QUIC pia si ubaguzi.
Jambo muhimu zaidi ni kwamba unahitaji kwa njia fulani kuelezea kwa kivinjari kwamba "https://" sio ukweli tena kwamba inaongoza kwa bandari ya TCP 443. Huenda kusiwe na TCP hata kidogo. Kichwa cha Alt-Svc kinatumika kwa hili. Inakuruhusu kuambia kivinjari kuwa tovuti hii inapatikana pia kwenye itifaki kama hiyo kwa anwani kama hiyo na kama hiyo. Kinadharia, hii inapaswa kufanya kazi kama hirizi, lakini katika mazoezi tutakutana na ukweli kwamba UDP inaweza, kwa mfano, kupigwa marufuku kwenye ngome ili kuepuka mashambulizi ya DDoS.
Lakini hata kama UDP haijakatazwa, mteja anaweza kuwa nyuma ya kipanga njia cha NAT ambacho kimeundwa kushikilia kikao cha TCP kwa anwani ya IP, na tangu wakati huo. tunatumia UDP, ambayo haina kipindi cha maunzi, NAT haitashikilia muunganisho, na kipindi cha QUIC .
Shida hizi zote zinatokana na ukweli kwamba UDP haikuwa imetumiwa hapo awali kusambaza yaliyomo kwenye Mtandao, na watengenezaji wa vifaa hawakuweza kuona kwamba hii itawahi kutokea. Kwa njia hiyo hiyo, wasimamizi bado hawaelewi jinsi ya kusanidi vyema mitandao yao ili QUIC ifanye kazi. Hali hii itabadilika hatua kwa hatua, na, kwa hali yoyote, mabadiliko hayo yatachukua muda kidogo kuliko utekelezaji wa itifaki mpya ya safu ya usafiri.
Kwa kuongeza, kama ilivyoelezwa tayari, QUIC huongeza sana matumizi ya CPU. Daniel Stenberg ukuaji wa processor hadi mara tatu.
HTTP/3 itafika lini?
Standard kufikia Mei 2020, lakini kwa kuzingatia kwamba hati zilizopangwa Julai 2019 bado hazijakamilika kwa sasa, tunaweza kusema kwamba tarehe hiyo itarudishwa nyuma.
Kweli, Google imekuwa ikitumia utekelezaji wake wa gQUIC tangu 2013. Ukiangalia ombi la HTTP ambalo linatumwa kwa injini ya utaftaji ya Google, utaona hii:
Matokeo
QUIC sasa inaonekana kama teknolojia mbovu, lakini yenye matumaini makubwa. Ikizingatiwa kuwa katika kipindi cha miaka 20 iliyopita, uboreshaji wote wa itifaki za safu ya usafiri umehusu hasa TCP, QUIC, ambayo katika hali nyingi ina utendakazi bora, tayari inaonekana nzuri sana.
Hata hivyo, bado kuna matatizo ambayo hayajatatuliwa ambayo yatalazimika kushughulikiwa katika miaka michache ijayo. Mchakato unaweza kuchelewa kutokana na ukweli kwamba kuna vifaa vinavyohusika, ambavyo hakuna mtu anayependa kusasisha, lakini hata hivyo, matatizo yote yanaonekana kutatuliwa kabisa, na mapema au baadaye sote tutakuwa na HTTP/3.
Wakati ujao uko karibu tu!
Chanzo: mapenzi.com