előszó
A HTTP protokoll az internet egyik legfontosabb protokollja, bár egyszerűnek tűnik, de a gyakorlatban gyakran szembesül problémákkal, és többször is találkoztunk vele. Hosszú kapcsolatok és csomagparsing is van. Nem tudhatsz semmit a HTTP protokollról, alaposan meg kell értened. Ezért írtam ezt a sorozatot, hogy megosszam a HTTP protokoll problémáit és tapasztalatait.
A HTTP protokollnak van fejléce és test mind a kérés, mind a válasz csomaghoz, és a test az erőforrás, amit meg akarsz szerezni, például egy html oldalt, egy jpeg képet, és a fejlécet bizonyos konvenciók kialakításához használják. Például az ügyfél és a szerver megegyezik bizonyos átviteli formátumokban, és először megkapja a fejlécet, ismer némi formátuminformációt, majd elkezdi olvasni a törzset.
Kliens: Accept-Encoding:gzip (tömörítsd nekem, forgalmat használok, először töltsd le, majd lassan oldd ki)
Server 1: Tartalomkódolás: null (Nincs tartalomkódolás fejléce.) Nem adok kompressziót, a CPU nem ingyenes, akarod)
Server 2: Content-Encoding:gzip (forgalmat ment, tömörít) Ügyfél: Kapcsolat: Keep alive (Nagy testvér, végre építettünk egy TCP kapcsolatot, legközelebb használni fogjuk)
1. szerver: Kapcsolat: életben marad (nem könnyű, továbbra is használom)
2. szerver: Kapcsolat: zár (Aki továbbra is használja veled, a TCP-nk egyszeri elérhető, és legközelebb újra kell csatlakoznunk, ha megtaláljuk) A HTTP protokollnak nincs három kézfogása, és amikor egy kliens erőforrásokat kér a szervertől, a szerver oldala győzedelmes. Vannak olyan fejlécek is, amelyeknek nincs tárgyalási folyamata, de a szerver közvetlenül megmondja a kliensnek, mit kell tennie. Például a fenti Tartalom-Hossz azt mutatja, hogy a szerver megmutatja a kliensnek, mekkora a test. De! A szerver nem biztos, hogy előre tudja pontosan megmondani, mekkora a test. A szervernek először a fejlécet kell írnia, majd a testet, ha a törzs esetét akarod a fejlécbe írni, előre tudnod kell a test méretét. Ha a test dinamikusan generálódik, a szerver befejezi, majd elkezdi a fejlécet írni, ami sok plusz overcost igényel, így lehet, hogy nincs tartalomhossz a fejlécben.
De honnan tudja a kliens a test méretét? A szerver háromféleképpen mondja el.
1. A szerver már tudja az erőforrás méretét, és a tartalomhosszúságú fejlécen keresztül jelzi.
Content-Length:1076(body的大小是1076B,你读取1076B就可以完成任务了)
Transfer-Encoding: null
2. A szerver nem tudja előre az erőforrás méretét, vagy nem hajlandó erőforrásokat költeni az erőforrás méretének előre kiszámítására, ezért hozzáad egy fejlécet a http válaszüzenethez, amelynek címe Transfer-Encoding:chunked néven, ami blokkátvitelt jelent. Minden blokk fix formátumot használ, az elöl lévő blokk mérete, mögötte lévő adat, majd az utolsó blokk 0 méretű. Így, amikor az ügyfél parzál, figyelnie kell arra, hogy eltávolítson néhány haszontalan mezőt.
Content-Length:null
Transfer-Encoding:chunked (接下来的body我要一块一块的传,每一块开始是这一块的大小,等我传到大小为0的块时,就没了)
3. A szerver nem ismeri az erőforrás méretét, és nem támogatja a chunked átviteli módot, így nincs sem tartalomhosszúságú fejléce, sem az átviteli kódolás fejléce. Ekkor a szerver által visszaküldött fejlécnek közel kell lennie.
Content-Length:null
Transfer-Encoding:null
Connection:close(我不知道大小,我也用不了chunked,啥时候我关了tcp连接,就说明传输结束了)
|