Nätverk och protokoll

HTTP

Tillståndslöst förfrågningssvarsapplikationsprotokoll som används för att leverera webb- och API-innehåll.

Var du ser detta: Syns i paketfångster, nätverksdiagram, brandväggsregler samt system- och nätverksloggar.

Vad det är

HTTP (Hypertext Transfer Protocol) är ett applikationslagerprotokoll för att begära och överföra resurser. En klient skickar en förfrågan som inkluderar en metod, mål, rubriker och ibland en text. En server svarar med en statuskod, rubriker och en valfri text.

Nyckelpunkter

Byggd kring metoder som GET och POST och svar med statuskoder.
Kör över transporter som TCP (HTTP/1.1 och HTTP/2) och QUIC (HTTP/3).
Cachning och proxyservrar är centrala designfunktioner, inte tillägg.

Hur det fungerar i stora drag

Klienten löser servernamnet (vanligtvis via DNS) och öppnar en anslutning till servern.
Klienten skickar en HTTP förfrågan som anger en metod, en sökväg och rubriker. Vissa förfrågningar inkluderar en kropp.
Servern bearbetar förfrågan och returnerar ett HTTP-svar med en statuskod, rubriker och en text om det behövs.
HTTP är tillståndslös, så servern kommer inte automatiskt ihåg något mellan förfrågningar. Status förs i cookies, tokens eller applikationsdata.
Anslutningar kan återanvändas. HTTP/1.1 använder beständiga anslutningar, medan HTTP/2 multiplexerar många strömmar på en anslutning.
Cachningsregler tillåter klienter och mellanhänder att återanvända svar på ett säkert sätt, vilket minskar latens och belastning.
Proxies och gateways kan modifiera routing och beteende, varför vägen mellan klient och server ofta är mer komplex än den ser ut.

Konkret exempel

Din webbläsare skickar `GET /` till en server och tar emot `200 OK` plus HTML. Senare begär den bilder och skript med fler GET-förfrågningar. Även om det känns som en session är varje förfrågan oberoende såvida inte cookies eller tokens knyter ihop dem.

Varför det är viktigt

HTTP tillhandahåller ett flexibelt, interoperabelt sätt för klienter, servrar och mellanhänder att kommunicera. Dess design stöder cachning, proxyservering och inkrementell utveckling, vilket är anledningen till att den blev grunden för webben och moderna APIs.

Säkerhetsperspektiv

Många webbsårbarheter handlar om hur HTTP-data tolkas, såsom injicering i rubriker, parametrar eller kroppar.
Autentisering är vanligtvis en applikationslagermekanism som är skiktad ovanpå HTTP. Skydda polletter och kakor noggrant.
Att logga fullständiga webbadresser eller rubriker kan läcka hemligheter. Var medveten om vad du lagrar.

Vanliga fallgropar

Förutsatt att HTTP alltid är krypterad. Endast HTTPS tillhandahåller transportkryptering.
Blandar ihop idempotenta metoder med säkra metoder. Omförsök är inte alltid ofarliga.
Felkonfigurering av cachehuvuden och oavsiktlig servering av inaktuell eller privat data.
Att glömma att mellanhänder finns. Proxies kan skriva om rubriker, komprimera kroppar och avsluta anslutningar.
Behandla statuskoder som dekorativa. De är ett kontrakt som kunderna litar på.

FÖRDJUPNING

▾

Vad händer när du hämtar en URL

Kärnan är HTTP enkel. En klient öppnar en anslutning till en server, skickar en förfråganrad plus rubriker och eventuellt en text. Servern svarar med en statuskod, rubriker och en text. Det förfrågan och svarsparet är arbetsenheten.

HTTP är statslös i den meningen att varje förfrågan står för sig själv. Om servern behöver kontinuitet använder den cookies, tokens eller annat tillstånd som bärs i rubriker. Denna separation är kraftfull eftersom den tillåter lastbalansering och cachelagring, men det betyder också att autentisering och sessionshantering är explicita designval, inte dold magi.

I riktiga webbläsare orsakar en sidladdning många HTTP-förfrågningar: HTML, CSS, JavaScript, bilder, APIs. Effektivitet kommer från återanvändning av anslutningar, parallellitet och cachning, inte från att göra en förfrågan större.

Återanvändning av anslutningar och varför hålla liv är viktiga

I HTTP/1.1 kan en enda TCP-anslutning bära flera förfrågningar över tid. Klienten skickar en förfrågan, läser svaret och skickar sedan en annan. Återanvändning av anslutningen undviker att upprepa TCP och TLS inställningar och undviker upprepad långsam start, vilket förbättrar latens och genomströmning.

HTTP/2 går längre genom att multiplexa många strömmar över en anslutning. Istället för strikt förfrågan och sedan svarsordning på tråden, kan ramar för olika strömmar interfoliera. Detta minskar behovet av många parallella TCP-anslutningar och förbättrar prestandan på begränsade nätverk.

Även med nyare versioner stannar den mentala modellen kvar. Förfrågningar och svar finns fortfarande kvar. Skillnaderna ligger i hur de är inramade och schemalagda på tråden.

Cachning är en del av HTTP, inte en eftertanke

HTTP innehåller explicita cachelagringskontroller så att klienter och mellanhänder kan återanvända svar på ett säkert sätt. Rubriker som Cache Control och Expires beskriver hur länge innehåll får återanvändas. Validatorer som ETag och Last Modified möjliggör villkorliga förfrågningar där klienten frågar, har detta ändrats, och servern kan svara med Not Modified utan att skicka om kroppen.

Detta cachinglager är en anledning till att webben skalas. En CDN är i huvudsak en HTTP cache med smart routing. När cachning är väl konfigurerad gör din webbläsare och din närmaste edge-server det mesta av arbetet, och ursprunget ser mycket färre förfrågningar.

Cachning skapar också vanliga buggar. Om du cachar något som ska vara per användare läcker du data. Om du misslyckas med att cachelagra något som är säkert att dela, slösar du med bandbredd. Att förstå cachningsrubriker är en praktisk färdighet, inte en teoretisk detalj.

Meddelandedetaljer som visas i säkerhet och felsökning

Rubriker är både kraftfulla och riskfyllda. De har autentiseringstokens, cookies, innehållstyper och många andra kontroller. Om ett program återspeglar opålitlig indata i rubriker eller tolkar rubriker felaktigt kan du få sårbarheter som svarsdelning eller cacheförgiftning.

HTTP definierar också hur proxyservrar ska bete sig. Vissa rubriker är hop för hop och får inte vidarebefordras. Andra är från början till slut. Misstag här kan skapa subtila fel där en förfrågan fungerar direkt men misslyckas bakom en proxy eller en lastbalanserare.

En bra felsökningsvana är att inspektera den exakta förfrågan och svaret, inte bara webbadressen. Statuskoder, omdirigeringar, innehållstyper och cachningsrubriker berättar vad som verkligen hände, och de förklarar ofta problem snabbare än bara programloggar.