johdanto
HTTP-protokolla on yksi Internetin tärkeimmistä protokollista, vaikka se vaikuttaa yksinkertaiselta, mutta käytännössä se kohtaa usein ongelmia, ja olemme kohdanneet sen useita kertoja. Yhteydet ja pakettien jäsentäminen ovat pitkiä. Et voi tietää mitään HTTP-protokollasta, sinun täytyy ymmärtää se perusteellisesti. Kirjoitin tämän sarjan jakaakseni HTTP-protokollan ongelmat ja kokemukset.
HTTP-protokollassa on otsikko ja runko sekä pyyntö- että vastauspaketeille, ja runko on se resurssi, jonka haluat saada, kuten html-sivun, jpeg-kuvan, ja otsikkoa käytetään tiettyjen käytäntöjen tekemiseen. Esimerkiksi asiakas ja palvelin sopivat joistakin siirtomuodoista, ja asiakas saa ensin otsikon, tietää jonkin verran formaattitietoa ja alkaa sitten lukea runkoa.
Asiakas: Accept-Encoding:gzip (pakkaa se minulle, käytän liikennettä, lataa ensin ja avaa sitten hitaasti)
Palvelin 1: Sisällönkoodaus: null (Ei Content-Encoding -otsikkoa.) En anna kompressiota, prosessori ei ole ilmainen, haluatko sen)
Palvelin 2: Content-Encoding:gzip (tallenna liikennettä puolestasi, pakkaa se) Asiakas: Yhteys: säilytä (Iso veli, rakensimme vihdoin TCP-yhteyden, käytämme sitä ensi kerralla)
Palvelin 1: Yhteys: säilytä (ei helppoa, jatka käyttöä)
Palvelin 2: Yhteys: sulje (Kuka tahansa, joka jatkaa sen käyttöä kanssasi, meidän TCP on kertaluonteinen, ja seuraavalla kerralla joudumme yhdistämään uudelleen) HTTP-protokollassa ei ole kolmea kättelyä, ja kun asiakas pyytää resursseja palvelimelta, palvelinpuoli voittaa. On myös joitakin otsikoita, joissa ei ole neuvotteluprosessia, mutta palvelin kertoo suoraan asiakkaalle, mitä tehdä. Esimerkiksi yllä oleva Content-Length on se, mitä palvelin kertoo asiakkaalle, kuinka suuri runko on. Mutta! Palvelin ei välttämättä pysty kertomaan etukäteen, kuinka suuri vartalo on. Palvelimen täytyy ensin kirjoittaa otsikko ja sitten runko, jos haluat kirjoittaa runkotapauksen otsikkoon, sinun täytyy tietää rungon koko etukäteen. Jos runko generoidaan dynaamisesti, palvelin viimeistelee ja alkaa kirjoittaa otsikon, mikä vaatii paljon ylimääräistä kuormitusta, joten otsikossa ei välttämättä ole sisältöpituutta.
Miten asiakas siis tietää kehon koon? Palvelin kertoo sinulle kolmella tavalla.
1. Palvelin tietää jo resurssikoon ja kertoo sisällön pituuden otsikon kautta.
Content-Length:1076(body的大小是1076B,你读取1076B就可以完成任务了)
Transfer-Encoding: null
2. Palvelin ei voi tietää resurssin kokoa etukäteen tai ei ole valmis käyttämään resursseja resurssin koon laskemiseen etukäteen, joten se lisää http-vastaukseen otsikon nimeltä Transfer-Encoding:chunked, joka tarkoittaa lohkosiirtoa. Jokainen lohko käyttää kiinteää muotoa, jossa lohkon koko on edessä, data sen takana ja viimeisen lohkon koko on 0. Näin asiakkaan täytyy jäsentäessään kiinnittää huomiota joidenkin turhien kenttien poistamiseen.
Content-Length:null
Transfer-Encoding:chunked (接下来的body我要一块一块的传,每一块开始是这一块的大小,等我传到大小为0的块时,就没了)
3. Palvelin ei tiedä resurssin kokoa eikä tue chunked-siirtotilaa, joten ei ole sisällönpituuden otsikkoa eikä siirtokoodauksen otsikkoa. Tällä hetkellä palvelimen palauttama otsikko on oltava lähellä.
Content-Length:null
Transfer-Encoding:null
Connection:close(我不知道大小,我也用不了chunked,啥时候我关了tcp连接,就说明传输结束了)
|