forord
HTTP-protokollen er en af de vigtigste protokoller på internettet, selvom den virker enkel, men i praksis støder den ofte på problemer, og vi har oplevet den flere gange. Der er lange forbindelser og pakkeparsing. Du kan ikke vide noget om HTTP-protokollen, du skal forstå den grundigt. Så jeg skrev denne serie for at dele problemerne og erfaringerne med HTTP-protokollen.
HTTP-protokollen har et header og en body til både anmodnings- og svarpakkerne, og body er den ressource, du vil have, såsom en html-side, et jpeg-billede, og headeren bruges til at lave visse konventioner. For eksempel bliver klienten og serveren enige om nogle transmissionsformater, og klienten får først headeren, kender noget formatinformation og begynder derefter at læse brødteksten.
Klient: Accept-Encoding:gzip (komprimer det for mig, jeg bruger trafik, download det først og pak det så langsomt ud)
Server 1: Indholdskodning: null (Ingen indholdskodningsheader.) Jeg giver ikke komprimering, CPU'en er ikke gratis, vil du have den)
Server 2: Indholdskodning: gzip (gemmer trafikken for dig, komprimer den) Klient: Forbindelse: keep-alive (Storebror, vi har endelig bygget en TCP-forbindelse, vi bruger den næste gang)
Server 1: Forbindelse: keep-alive (ikke let, brug dem fortsat)
Server 2: Forbindelse: luk (Den, der fortsætter med at bruge den sammen med dig, vores TCP er engangs, og vi må genoprette forbindelsen næste gang, vi finder den) HTTP-protokollen har ikke tre håndtryk, og når en klient anmoder om ressourcer fra serveren, vil serversiden have forrang. Der er også nogle headers, som ikke har en forhandlingsproces, men serveren fortæller direkte klienten, hvad den skal gøre. For eksempel er Content-Length ovenfor det, serveren fortæller klienten, hvor stor kroppen er. Men! Serveren kan måske ikke fortælle dig præcis, hvor stor kroppen er på forhånd. Serveren skal først skrive headeren og derefter bodyen; hvis du vil skrive body-casen i headeren, skal du kende body-størrelsen på forhånd. Hvis brødteksten genereres dynamisk, vil serveren færdiggøre og derefter begynde at skrive headeren, hvilket kræver en masse ekstra overhead, så der er måske ikke en indholdslængde i headeren.
Så hvordan ved klienten størrelsen på kroppen? Serveren fortæller dig det på tre måder.
1. Serveren kender allerede ressourcestørrelsen og fortæller dig det via indholdslængde-headeren.
Content-Length:1076(body的大小是1076B,你读取1076B就可以完成任务了)
Transfer-Encoding: null
2. Serveren kan ikke kende ressourcens størrelse på forhånd eller er uvillig til at bruge ressourcer på at beregne ressourcens størrelse på forhånd, så den tilføjer en header til http-svarbeskeden kaldet Transfer-Encoding:chunked, hvilket betyder blokoverførsel. Hver blok bruger et fast format, hvor størrelsen på blokken foran, dataene bagved og derefter den sidste blok med størrelsen 0. På denne måde skal klienten, når den parser, være opmærksom på at fjerne nogle ubrugelige felter.
Content-Length:null
Transfer-Encoding:chunked (接下来的body我要一块一块的传,每一块开始是这一块的大小,等我传到大小为0的块时,就没了)
3. Serveren kender ikke ressourcens størrelse og understøtter ikke chunked transmission-tilstanden, så der er hverken indholdslængde-headeren eller transfer-encoding headeren. På dette tidspunkt skal headeren, som serveren returnerer, være tæt på.
Content-Length:null
Transfer-Encoding:null
Connection:close(我不知道大小,我也用不了chunked,啥时候我关了tcp连接,就说明传输结束了)
|