Lohkoinen siirtokoodaus - Chunked transfer encoding

Chunked transfer encoding on suoratoistotiedonsiirtomekanismi , joka on saatavana HTTP: n ( Hypertext Transfer Protocol ) versiossa 1.1 . Palannetussa siirtokoodauksessa tietovirta on jaettu sarjaan päällekkäisiä "paloja". Palat lähetetään ja vastaanotetaan toisistaan ​​riippumatta. Tietoa tietovirrasta parhaillaan käsiteltävän osan ulkopuolella ei tarvita sekä lähettäjälle että vastaanottajalle milloin tahansa.

Jokaista kappaletta edeltää sen koko tavuina. Lähetys päättyy, kun vastaanotetaan nollapituinen pala. Chunked avainsanan Transfer-Encoding -otsikkoa käytetään osoittamaan chunked siirto.

Osittaisen siirtokoodauksen varhaista muotoa ehdotettiin vuonna 1994. Katkottua siirtokoodausta ei tueta HTTP/2: ssa , joka tarjoaa omat mekanisminsa tietojen suoratoistoon.

Perustelut

Lohkotun koodauksen käyttöönotolla oli useita etuja:

  • Lohkoisen siirtokoodauksen avulla palvelin voi ylläpitää pysyvää HTTP -yhteyttä dynaamisesti luodulle sisällölle. Tässä tapauksessa HTTP-sisällön pituus -otsikkoa ei voi käyttää sisällön ja seuraavan HTTP-pyynnön/vastauksen rajaamiseen, koska sisällön koko ei ole vielä tiedossa. Rypytetyn koodauksen etuna on, että koko sisältöä ei tarvitse luoda ennen otsikon kirjoittamista, koska se mahdollistaa sisällön suoratoiston paloina ja nimenomaisesti sisällön lopun signaloimiseksi, jolloin yhteys on käytettävissä seuraavaa HTTP -pyyntöä/vastausta varten.
  • Lohkotun koodauksen avulla lähettäjä voi lähettää ylimääräisiä otsikkokenttiä viestin tekstin jälkeen. Tämä on tärkeää tapauksissa, joissa kentän arvoja ei voida tietää ennen kuin sisältö on tuotettu, esimerkiksi silloin, kun viestin sisältö on allekirjoitettava digitaalisesti. Ilman osittaista koodausta lähettäjän olisi puskuroitava sisältö, kunnes se on valmis, jotta se voi laskea kentän arvon ja lähettää sen ennen sisältöä.

Soveltuvuus

HTTP -protokollan versiossa 1.1 lohkotettua siirtomekanismia pidetään aina ja joka tapauksessa hyväksyttävänä, vaikka sitä ei olisi lueteltu TE (siirtokoodaus) -pyyntöotsikkokentässä, ja kun sitä käytetään muiden siirtomekanismien kanssa, sitä tulee aina käyttää viimeisenä siirretyt tiedot eikä koskaan useammin kuin kerran. Tämä siirtokoodausmenetelmä mahdollistaa myös entiteetin ylätunnistekenttien lähettämisen viimeisen osan jälkeen, jos asiakas on määrittänyt "perävaunut" -parametrin TE -kentän argumentiksi. Vastauksen alkuperäpalvelin voi myös päättää lähettää muita entiteettitrailereita, vaikka asiakas ei olisi määritellyt "perävaunut" -vaihtoehtoa TE -pyyntökentässä, mutta vain jos metatiedot ovat valinnaisia ​​(eli asiakas voi käyttää vastaanotettua kokonaisuutta ilman niitä ). Aina kun käytetään perävaunuja, palvelimen on lueteltava niiden nimet Trailer header -kenttään; Kolme otsikkokenttätyyppiä on nimenomaisesti kielletty esiintymästä perävaunukentässä: Transfer-Encoding , Content-Length ja Trailer .

Muoto

Jos HTTP-sanomassa (joko asiakkaan lähettämä pyyntö tai palvelimen vastaus) on määritetty siirtokoodauskenttä , jonka arvo on " paloiteltu ", viestin runko koostuu määrittämättömästä palasista, päättyvä palan, perävaunun ja lopullisen CRLF -sekvenssin (eli vaunun paluun ja rivin syötön ).

Jokainen lohko alkaa sen sisältämien tietojen oktettien lukumäärällä ASCII: n heksadesimaaliluvuna , jota seuraa valinnaiset parametrit ( palan laajennus ) ja päättyvä CRLF -sekvenssi, jota seuraa palatiedot. Palan lopettaa CRLF.

Jos lohkon laajennuksia on, kappaleen koko päättyy puolipisteeseen ja sen jälkeen parametrit, jotka myös rajataan puolipisteillä. Jokainen parametri koodataan laajennuksen nimeksi, jota seuraa valinnainen yhtäläisyysmerkki ja arvo. Näitä parametreja voitaisiin käyttää esimerkiksi käynnissä olevaan viestin tiivistelmään tai digitaaliseen allekirjoitukseen tai esimerkiksi arvioidun siirtoedistyksen osoittamiseen.

Päätekappale on tavallinen pala, paitsi että sen pituus on nolla. Sitä seuraa perävaunu, joka koostuu (mahdollisesti tyhjästä) kokonaisuudesta otsikkokenttiä. Normaalisti tällaiset otsikkokentät lähetetään viestin otsikkoon; niiden määrittäminen voi kuitenkin olla tehokkaampaa koko viestiyksikön käsittelyn jälkeen. Siinä tapauksessa on hyödyllistä lähettää nämä otsikot perävaunuun.

Perävaunujen käyttöä säätelevät otsikkokentät ovat TE (käytetään pyyntöissä) ja Trailerit (käytetään vastauksissa).

Käytä pakkauksen kanssa

HTTP-palvelimet käyttävät usein pakkausta lähetyksen optimoimiseksi, esimerkiksi Content-Encoding: gzip tai Content-Encoding: deflate . Jos sekä pakkaus että paloitettu koodaus ovat käytössä, sisältövirta pakataan ensin ja sitten paloitellaan; palan koodausta ei siis pakata eikä kunkin palan tietoja pakata erikseen. Etäpäätepiste purkaa sitten virran ketjuttelemalla palat ja purkamalla tuloksen.

Esimerkki

Koodatut tiedot

Seuraavassa esimerkissä on esitetty kolme palan pituutta 4, 6 ja 14 (heksadesimaalinen "E"). Palan koko siirretään heksadesimaaliluvuna, jota seuraa \ r \ n rivinerottimena, jota seuraa tietyn kokoinen data. 

4\r\n        (bytes to send)
Wiki\r\n     (data)
6\r\n        (bytes to send)
pedia \r\n   (data)
E\r\n        (bytes to send)
in \r\n
\r\n
chunks.\r\n  (data)
0\r\n        (final byte - 0)
\r\n         (end message)

Huomautus: palan koko osoittaa palan datan koon eikä sulje pois CRLF -arvoa ("\ r \ n"). Tässä nimenomaisessa esimerkissä "in": n jälkeen oleva CRLF lasketaan kahdeksi oktetiksi kohti palan kokoa 0xE (14). CRLF omalla rivillään lasketaan myös kahdeksi oktetiksi kohti palan kokoa. Pisteiden lopussa oleva piste -merkki on 14. merkki, joten se on kyseisen palan viimeinen datamerkki. Kauden jälkeinen CRLF on perässä oleva CRLF, joten sitä ei lasketa palan kokoon 0xE (14).

Dekoodattu data

Wikipedia in

chunks.

Katso myös

Viitteet