Hypertext Transfer Protocol

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken
Hypertext Transfer Protocol
HTTP-logo van de IETF HTTP-werkgroep
Familie: Internet protocol familie
Toepassingsgebied: Gegevensoverdracht (hypertekst enz.)
op de applicatielaag
Gebaseerd op TCP (transport)
Invoering: 1991
huidige versie: 2 (2015)
Voorlopige versie: 3e
Standaard: RFC 1945 HTTP / 1.0 (1996)

RFC 2616 HTTP / 1.1 (1999)
RFC 7540 HTTP / 2 (2015)
RFC 7541 Headercompressie (2, 2015)
RFC 7230 berichtsyntaxis en routering (1.1, 2014)
RFC 7231 Semantiek en inhoud (1.1, 2014)
RFC 7232 voorwaardelijke verzoeken (1.1, 2014)
RFC 7233 Bereikverzoeken (1.1, 2014)
RFC 7234- caching (1.1, 2014)
RFC 7235- authenticatie (1.1, 2014)

Gebruikers komen vaak de afkorting tegen, b.v. B. aan het begin van een webadres in de adresbalk van de browser

Het Hypertext Transfer Protocol (HTTP, Engels voor hypertext transmissieprotocol) is een stateloos protocol voor de overdracht van gegevens op de applicatielaag via een computernetwerk . Het wordt voornamelijk gebruikt om webpagina's (hypertekstdocumenten) van het World Wide Web (WWW) in een webbrowser te laden . Het is hier echter in principe niet toe beperkt en is ook heel gebruikelijk als een algemeen protocol voor bestandsoverdracht.

HTTP is gestandaardiseerd door de Internet Engineering Task Force (IETF) en het World Wide Web Consortium (W3C). De huidige versie is HTTP/2, die op 15 mei 2015 werd gepubliceerd als RFC 7540 . De verdere ontwikkeling wordt georganiseerd door de HTTP-werkgroep van de IETF (HTTPbis). Er zijn standaarden die HTTP aanvullen en erop voortbouwen, zoals HTTPS voor het versleutelen van verzonden inhoud of het WebDAV- transmissieprotocol.

eigenschappen

Volgens gevestigde laagmodellen voor het classificeren van netwerkprotocollen op basis van hun meer fundamentele of meer abstracte taken, wordt HTTP toegewezen aan de zogenaamde applicatielaag. Dit wordt aangepakt door de applicatieprogramma's , in het geval van HTTP is dit meestal een webbrowser. In het ISO/OSI-lagenmodel komt de applicatielaag overeen met de 7e laag.

HTTP is een staatloos protocol. Informatie van eerdere verzoeken gaat verloren. Betrouwbare overdracht van sessiegegevens kan alleen worden geïmplementeerd op de applicatielaag door middel van een sessie met behulp van een sessie- ID. Met behulp van cookies in de header-informatie kunnen echter toepassingen worden geïmplementeerd die statusinformatie kunnen toewijzen (gebruikersinvoer, winkelwagentjes). Dit maakt toepassingen mogelijk die status- of sessie- eigenschappen vereisen. Gebruiker authenticatie is ook mogelijk. Normaal gesproken kan de informatie die via HTTP wordt verzonden, worden gelezen op alle computers en routers die door het netwerk gaan . De verzending kan echter worden versleuteld via HTTPS .

Door de uitbreiding van de aanvraagmethoden, header- informatie en statuscodes beperkt HTTP zich niet tot hypertext , maar wordt het steeds vaker gebruikt om gegevens uit te wisselen.Het is ook de basis van het WebDAV- protocol, dat gespecialiseerd is in bestandsoverdracht. HTTP vertrouwt op eenbetrouwbaar transportprotocol voor communicatie , waarvoor in bijna alle gevallen TCP wordt gebruikt.

Er zijn momenteel twee hoofdversies van het protocol, HTTP / 1.0 en HTTP / 1.1. Nieuwere versies van alledaagse webbrowsers zoals Chromium , Chrome , Opera , Firefox , Edge en Internet Explorer zijn ook al compatibel met de nieuw geïntroduceerde versie 2 van HTTP (HTTP / 2)

bouw

De communicatie-eenheden in HTTP tussen client en server worden nieuws genoemd en er zijn twee verschillende manieren: het verzoek (English Request) van de client naar de server en het antwoord (English Response) als reactie van server naar client.

Elk bericht bestaat uit twee delen, de header (Engelse berichtkop, kortweg header of HTTP-header genoemd) en de berichttekst (Message Body Engels, korte tekst ). De berichtkop bevat informatie over de berichttekst, zoals de gebruikte codering of het inhoudstype, zodat deze door de ontvanger correct kan worden geïnterpreteerd (→ hoofdartikel: Lijst met HTTP-headervelden ). De berichttekst bevat tenslotte de gebruikersgegevens.

functionaliteit

Voorbeeld van een transactie uitgevoerd met Telnet

Als de link naar de URL http://www.example.net/infotext.html is geactiveerd in een webbrowser, wordt het verzoek verzonden naar de computer met de hostnaam www.example.net om de resource /infotext.html te verzenden rug.

De naam www.example.net wordt eerst via het DNS- protocol omgezet in een IP-adres . Voor de overdracht wordt een HTTP GET-verzoek via TCP verzonden naar de standaard poort 80 van de HTTP-server.

Navraag:

GET /infotext.html HTTP/1.1
Host: www.example.net

Als de link tekens bevat die niet zijn toegestaan ​​in het verzoek, zijn deze %-gecodeerd . Aanvullende informatie zoals informatie over de browser, de gewenste taal, etc. kan in elke HTTP-communicatie via de header (headers) worden verzonden. Met het veld "Host" kunnen verschillende DNS-namen worden onderscheiden onder hetzelfde IP-adres. Het is optioneel onder HTTP / 1.0, maar vereist onder HTTP / 1.1. Zodra de header eindigt met een lege regel (of twee opeenvolgende regeleinden), stuurt de computer die een webserver (op poort 80) bedient een HTTP-antwoord terug. Deze bestaat uit de header-informatie van de server, een lege regel en de eigenlijke inhoud van het bericht, d.w.z. de bestandsinhoud van het infotext.html- bestand. Bestanden worden meestal verzonden in paginabeschrijvingstalen zoals (X ) HTML en al hun toevoegingen, bijvoorbeeld afbeeldingen, stylesheets ( CSS ), scripts ( JavaScript ), enz., die meestal door een browser aan elkaar worden gekoppeld in een leesbare voorstelling. In principe kan elk bestand in elk formaat worden verzonden, waarbij het "bestand" ook dynamisch kan worden gegenereerd en niet als fysiek bestand op de server hoeft te staan ​​(bijvoorbeeld bij gebruik van CGI , SSI , JSP , PHP of ASP .NET ). Elke regel in de kop wordt afgesloten met een regeleinde < CR > < LF >. De lege regel na de kop mag alleen bestaan ​​uit <CR> <LF>, zonder tussenruimten .

Antwoord:

HTTP/1.1 200 OK
Server: Apache /1.3.29 ( Unix ) PHP/4.3.4
Content-Length: 123456 (grootte van infotext.html in bytes )
Content-Language: de (volgens RFC 3282 en RFC 1766 )
Connection: close
Content-Type : text/html

(Inhoud van infotext.html)

De server stuurt een foutmelding en een foutcode terug als de informatie om welke reden dan ook niet kan worden verzonden, maar statuscodes worden ook gebruikt als het verzoek is gelukt, in dit geval (meestal) 200 OK . De exacte volgorde van dit proces (verzoek en antwoord) wordt gespecificeerd in de HTTP-specificatie.

verhaal

Sir Tim Berners-Lee wordt beschouwd als de grondlegger van het web en hielp ook bij het ontwikkelen van HTTP.

Vanaf 1989 ontwikkelden Tim Berners-Lee en zijn team bij CERN , het Europese nucleaire onderzoekscentrum in Zwitserland, het Hypertext Transfer Protocol, samen met de URL- en HTML- concepten, die de basis legden voor het World Wide Web. De eerste resultaten van deze inspanningen waren de versie HTTP 0.9 in 1991. [1]

HTTP / 1.0

Het verzoek gepubliceerd in mei 1996 als RFC 1945 ( Request for Comments No. 1945) is bekend geworden als HTTP / 1.0. Met HTTP / 1.0 wordt voor elke aanvraag een nieuwe TCP- verbinding tot stand gebracht en wordt deze standaard door de server weer gesloten nadat het antwoord is verzonden. Als er bijvoorbeeld tien afbeeldingen zijn ingesloten in een HTML-document, zijn er in totaal elf TCP-verbindingen nodig om de pagina in een grafische browser op te zetten.

HTTP / 1.1

In 1999 werd een tweede vereiste gepubliceerd als RFC 2616 , die de HTTP / 1.1-standaard weerspiegelt. [2] Met HTTP / 1.1 kan een client met een extra header entry ( keepalive ) de wens uitspreken de verbinding niet te beëindigen om de verbinding weer te kunnen gebruiken (persistente verbinding). Ondersteuning aan de serverkant is echter optioneel en kan problemen veroorzaken in combinatie met proxy's. Versie 1.1 maakt het mogelijk om meerdere verzoeken en antwoorden per TCP-verbinding te verzenden met behulp van HTTP-pipelining . Voor het HTML-document met tien afbeeldingen is slechts één TCP-verbinding nodig. Omdat de snelheid van TCP-verbindingen in het begin vrij laag is door het gebruik van het slow start- algoritme, wordt de laadtijd voor de hele pagina aanzienlijk verkort. Bovendien kunnen overdrachten die met HTTP / 1.1 zijn afgebroken, worden voortgezet.

Een manier om het gebruik van HTTP / 1.1 in chatrooms is om het gebruik van MIME-type multipart / vervangen, waarbij de browser door het sturen van een Boundary codes, en een recente Content-Length -Headerfeldes en een nieuw type inhoud -Headerfeldes de inhoud van Rebuilds de browservenster.

Met HTTP/1.1 is het niet alleen mogelijk om data op te halen maar ook om data over te zetten naar de server. Met behulp van de PUT- methode kunnen webdesigners hun pagina's rechtstreeks via de webserver publiceren met behulp van WebDAV, en met de DELETE-methode kunnen ze gegevens van de server verwijderen. Daarnaast biedt HTTP/1.1 een TRACE-methode waarmee het pad naar de webserver kan worden getraceerd en gecontroleerd of de gegevens daar correct worden overgebracht. Hierdoor is het mogelijk om via de verschillende proxy's de route naar de webserver te bepalen, een traceroute op applicatieniveau.

Vanwege inconsistenties en onduidelijkheden is in 2007 een werkgroep gestart om de specificatie te verbeteren. Het doel was hier gewoon een duidelijkere formulering, nieuwe functies werden niet opgenomen. Dit proces eindigde in 2014 en resulteerde in zes nieuwe RFC's:

  • RFC 7230 - HTTP / 1.1: berichtsyntaxis en routering
  • RFC 7231 - HTTP / 1.1: semantiek en inhoud
  • RFC 7232 - HTTP / 1.1: voorwaardelijke verzoeken
  • RFC 7233 - HTTP / 1.1: Bereikverzoeken
  • RFC 7234 - HTTP / 1.1: caching
  • RFC 7235 - HTTP / 1.1: authenticatie

HTTP / 2

In mei 2015 heeft de IETF HTTP/2 aangenomen als opvolger van HTTP/1.1. De standaard wordt gespecificeerd door RFC 7540 en RFC 7541 . [3] De ontwikkeling werd grotendeels gedreven door Google ( SPDY ) en Microsoft (HTTP Speed ​​+ Mobility) [4] , elk met hun eigen suggesties. Een eerste concept, grotendeels gebaseerd op SPDY, verscheen in november 2012 en is sindsdien in verschillende stappen aangepast.

Met HTTP / 2 moet de overdracht worden versneld en geoptimaliseerd. [5] De nieuwe standaard moet echter volledig achterwaarts compatibel zijn met HTTP / 1.1.

Belangrijke nieuwe kansen zijn:

  • de mogelijkheid om meerdere onderzoeken te combineren,
  • verdere opties voor gegevenscompressie ,
  • de binair gecodeerde overdracht van inhoud en
  • Door de server geïnitieerde gegevensoverdracht (push-procedure),
  • individuele streams kunnen worden geprioriteerd.

Een versnelling komt vooral voort uit de nieuwe mogelijkheid om meerdere aanvragen te combineren ( multiplexen ) om ze via één verbinding te kunnen verwerken. De datacompressie kan nu ook headerdata bevatten (met behulp van een nieuw speciaal algoritme genaamd HPACK [6] ). Inhoud kan in binaire code worden verzonden. Om niet te hoeven wachten op vervolgverzoeken van de client die aan de serverzijde te voorzien zijn, kunnen gegevensoverdrachten gedeeltelijk door de server worden geïnitieerd (push-procedure). Door HTTP / 2 te gebruiken, kunnen website-exploitanten de latentie tussen client en server verminderen en de netwerkhardware ontlasten. [7]

De oorspronkelijk geplande optie dat HTTP/2 standaard TLS gebruikt, werd niet geïmplementeerd. De browserfabrikanten Google en Mozilla hebben echter aangekondigd dat hun webbrowsers alleen versleutelde HTTP/2-verbindingen zullen ondersteunen. Hiervoor is ALPN een encryptie-extensie die TLSv1.2 of nieuwer vereist. [8e]

HTTP/2 wordt ondersteund door de meeste browsers, waaronder Google Chrome (incl. Chrome op iOS en Android) vanaf versie 41, Mozilla Firefox vanaf versie 36, [9] Internet Explorer 11 onder Windows 10, Opera vanaf versie 28 (evenals Opera Mobiel vanaf versie 24) en Safari vanaf versie 8.

HTTP / 3

In november 2018 besloot de IETF dat HTTP/3 QUIC moest gebruiken. [10]

HTTP-verzoekmethoden

KRIJGEN
is de meest gebruikelijke methode. Het wordt gebruikt om een ​​bron (bijvoorbeeld een bestand) van de server op te vragen door een URI op te geven . Content kan ook als argumenten in de URI naar de server worden overgebracht, maar volgens de norm mag een GET-request alleen data ophalen en heeft het verder geen effect (zoals datawijzigingen op de server of uitloggen). (zie hieronder )
POSTKANTOOR
stuurt, afhankelijk van de fysieke configuratie van de gebruikte server, onbeperkte hoeveelheden gegevens naar de server voor verdere verwerking; deze worden als inhoud van het bericht verzonden en kunnen bijvoorbeeld bestaan ​​uit naam-waarde-paren die afkomstig zijn uit een HTML-formulier. Op deze manier kunnen nieuwe resources op de server worden aangemaakt of bestaande worden gewijzigd. Caches slaan over het algemeen geen POST-gegevens in de cache op . Daarnaast kunnen bij dit type verzending ook gegevens aan de URI worden toegevoegd, zoals bij de GET-methode. (zie hieronder )
HOOFD
instrueert de server om dezelfde HTTP-headers te verzenden als bij GET, maar niet de hoofdtekst van het bericht met de daadwerkelijke documentinhoud. Zo kan bijvoorbeeld snel de geldigheid van een bestand in de browsercache worden gecontroleerd.
NEERZETTEN
wordt gebruikt om een ​​bron (bijvoorbeeld een bestand) naar een webserver te uploaden door de doel-URI op te geven. Als er al een resource bestaat onder de opgegeven doel-URI, wordt deze vervangen, anders wordt deze gemaakt.
LAPJE
Wijzigt een bestaand document zonder het volledig te vervangen zoals bij PUT. Werd gespecificeerd door RFC 5789 .
VERWIJDEREN
verwijdert de opgegeven bron op de server.
SPOOR
retourneert het verzoek zoals de server het heeft ontvangen. Op deze manier kan worden gecontroleerd of en hoe het verzoek is gewijzigd op weg naar de server - handig voor het debuggen van verbindingen.
OPTIES
biedt een lijst met de methoden en functies die door de server worden ondersteund.
AANSLUITEN
wordt geïmplementeerd door proxyservers die SSL- tunnels kunnen bieden.

RESTful webservices gebruiken de verschillende aanvraagmethoden om webservices te implementeren. Met name de HTTP-verzoekmethoden GET, POST, PUT/PATCH en DELETE worden hiervoor gebruikt.

WebDAV voegt de methoden PROPFIND , PROPPATCH , MKCOL , COPY , MOVE , LOCK en UNLOCK toe aan HTTP.

Argumentoverdracht

Vaak wil een gebruiker informatie naar een website sturen. HTTP biedt hiervoor in principe twee mogelijkheden:

HTTP GET
De gegevens maken deel uit van de URL en blijven dus behouden wanneer de link wordt opgeslagen of doorgegeven. Ze moeten URL-gecodeerd zijn , d.w.z. gereserveerde tekens moeten worden weergegeven met "% < hex-waarde >" en spaties met "+".
HTTP-POST
Verzending van de gegevens met een speciaal ontworpen verzoektype in de HTTP-berichttekst, zodat ze niet zichtbaar zijn in de URL.

HTTP GET

Hier worden de parameter-waardeparen aangegeven met het teken ? gestart in de URL . Deze procedure wordt vaak gekozen om een ​​lijst met parameters te verzenden waarmee het station op afstand rekening moet houden bij het verwerken van een verzoek. Deze lijst bestaat vaak uit waardeparen, die van elkaar worden gescheiden door het & -teken. De respectieve waardeparen zijn gestructureerd in de vorm van parameternaam = parameterwaarde . Het teken wordt zeldzamer ; gebruikt om items in de lijst te scheiden. [11]

Een voorbeeld: Op de homepage van Wikipedia wordt in het zoekveld "katten" ingevuld en wordt op de knop "Artikel" geklikt. De browser stuurt het volgende of een soortgelijk verzoek naar de server:

 GET / wiki / special: Zoeken? Zoeken = cats & go = artikel HTTP / 1.1
Gastheer: de.wikipedia.org
...

Twee waardeparen worden overgebracht naar de Wikipedia-server:

argument waard
zoeken katten
Gaan artikelen

Deze waardeparen hebben de vorm

Parameter1=Wert1&Parameter2=Wert2

voorafgegaan door ? toegevoegd aan de gevraagde pagina.

Dit vertelt de server dat de gebruiker het artikel katten wil bekijken. De server verwerkt het verzoek, maar stuurt geen bestand, maar stuurt de browser door naar de juiste pagina met een locatieheader , bijvoorbeeld met:

 HTTP / 1.0 302 Gevonden
Datum : vr 13 jan 2006 15:12:44 GMT
Locatie : http://de.wikipedia.org/wiki/Katzen
...

De browser volgt deze instructie en stuurt op basis van de nieuwe informatie een nieuw verzoek, bijvoorbeeld:

 GET / wiki / katten HTTP / 1.1
Host : de.wikipedia.org
...

En de server reageert en drukt het artikel katten af , zoiets als:

 HTTP / 1.1 200 OK
Datum : vr 13 januari 2006 15:12:48 GMT
Laatst gewijzigd : di 10 jan 2006 11:18:20 GMT
Inhoud-Taal : de
Inhoudstype : tekst / html; tekenset = utf-8

De katten (Felidae) zijn een familie uit de orde van de roofdieren (Carnivora)
binnen de katachtige superfamilie (Feloidea).
...

Het gegevensgedeelte is meestal langer, alleen het logboek moet hier worden beschouwd.

Het nadeel van deze methode is dat de opgegeven parameters met de URL meestal worden opgeslagen in de geschiedenis van de browser en dus onbedoeld persoonlijke gegevens in de browser kunnen worden opgeslagen. In plaats daarvan moet u in dit geval de POST-methode gebruiken.

HTTP-POST

Omdat de gegevens niet in de URL staan, kunnen grote hoeveelheden gegevens, zoals afbeeldingen, via POST worden overgedragen.

In het volgende voorbeeld wordt het artikel cats opnieuw aangevraagd, maar deze keer gebruikt de browser een POST-verzoek vanwege een gewijzigde HTML-code ( method="POST" ). De variabelen staan ​​niet in de URL, maar apart in het lichaamsdeel, bijvoorbeeld:

 POST / wiki / Speciaal: Zoeken in HTTP / 1.1
Host : de.wikipedia.org
Inhoudstype : applicatie / x-www-form-urlencoded
Inhoud-Lengte : 24

zoeken = katten & gaan = artikelen

De server begrijpt dit ook en antwoordt bijvoorbeeld met de volgende tekst:

 HTTP / 1.1 302 Gevonden
Datum : vr 13 januari 2006 15:32:43 GMT
Locatie : http://de.wikipedia.org/wiki/Katzen
...

HTTP-statuscodes

Fout 404 is een van de meest voorkomende webgebruikers die u tegenkomt

Elk HTTP-verzoek wordt door de server beantwoord met een HTTP-statuscode. Het geeft bijvoorbeeld informatie of het verzoek met succes is verwerkt of informeert bij een fout de klant, dat wil zeggen de browser, waar (bijvoorbeeld omleiding) of hoe (bijvoorbeeld met authenticatie) hij of zij heeft de gewenste informatie (indien mogelijk) kunnen krijgen.

1xx - informatie
Ondanks de feedback loopt de verwerking van het verzoek nog steeds. Zo'n tussenreactie is soms nodig omdat veel clients na een bepaalde tijd ( timeout ) er automatisch vanuit gaan dat er een fout is opgetreden in de verzending of verwerking van de aanvraag en eindigen met een foutmelding.
2xx - Succesvolle operatie
Het verzoek is verwerkt en het antwoord wordt teruggestuurd naar de aanvrager.
3xx - omleiden
Om ervoor te zorgen dat de aanvraag met succes wordt verwerkt, zijn verdere stappen van de klant nodig. Dit is bijvoorbeeld het geval wanneer een website door de exploitant opnieuw is ontworpen, zodat een gewenst bestand zich nu op een andere locatie bevindt. Met het antwoord van de server kan de client achterhalen waar het bestand zich nu in de Location- header bevindt.
4xx - Clientfout
Er is een fout opgetreden bij het verwerken van het verzoek waarvoor de klant verantwoordelijk is. Een 404 treedt bijvoorbeeld op als er een document is opgevraagd dat niet op de server staat. Een 403 meldt de klant dat het niet is toegestaan ​​om toegang te krijgen tot het betreffende document. Het kan bijvoorbeeld een vertrouwelijk document zijn of een document dat alleen toegankelijk is via HTTPS .
5xx - Serverfout
Er is een fout opgetreden waarvan de oorzaak bij de server ligt. 501 betekent bijvoorbeeld dat de server niet over de nodige functies beschikt (bijvoorbeeld programma's of andere bestanden) om het verzoek te verwerken.

Naast de statuscode bevat de koptekst van de serverreactie een beschrijving van de fout in gewoon Engels . Een 404-fout is bijvoorbeeld te herkennen aan de volgende header:

 HTTP / 1.1 404 niet gevonden
...

HTTP-authenticatie

HTTP-authenticatie

Als de webserver vaststelt dat voor een opgevraagd bestand een gebruikersnaam of wachtwoord nodig is, meldt hij dit aan de browser met de statuscode 401 Unauthorized en de WWW-Authenticate header. Deze controleert of de informatie beschikbaar is of geeft de gebruiker een dialoog waarin de naam en het wachtwoord moeten worden ingevoerd en stuurt deze naar de server. Als de gegevens correct zijn, wordt de bijbehorende pagina naar de browser gestuurd. Volgens RFC 2617 wordt onderscheid gemaakt tussen:

Basisverificatie
Basisverificatie is het meest voorkomende type HTTP-verificatie. De webserver vraagt ​​om authenticatie, de browser zoekt vervolgens naar de gebruikersnaam/wachtwoord voor dit bestand en vraagt ​​de gebruiker indien nodig. Vervolgens stuurt het de authenticatie met de autorisatieheader in de vorm van gebruikersnaam: wachtwoord Base64- gecodeerd naar de server. Base64 biedt geen cryptografische bescherming, dus deze methode kan alleen als veilig worden beschouwd bij gebruik van HTTPS .
Digest-toegangsverificatie
Met Digest Access Authentication verzendt de server ook een speciaal gegenereerde willekeurige tekenreeks ( nonce ) met de WWW-Authenticate-header. De browser berekent de hash-code van de volledige gegevens (gebruikersnaam, wachtwoord, ontvangen tekenreeks, HTTP-methode en gevraagde URI ) en stuurt deze samen met de gebruikersnaam en de willekeurige tekenreeks terug naar de server in de autorisatieheader, die vervolgens stuurt het terug naar de server met de zelfberekende controlesom vergelijkt. Luisteren naar de communicatie heeft hier geen zin voor een aanvaller, omdat de gegevens vanwege de gebruiktecryptologische hash-functie niet kunnen worden gereconstrueerd uit de hash-code en voor elke aanvraag anders is.

HTTP-compressie

Om de hoeveelheid overgedragen gegevens te verminderen, kan een HTTP-server zijn antwoorden comprimeren . Bij het doen van een aanvraag moet een klant aangeven welke compressiemethode hij kan verwerken. Hiervoor wordt de Accept-Encoding header gebruikt ( bijv. Accept-Encoding: gzip , deflate ). De server kan het antwoord vervolgens comprimeren met behulp van een methode die door de client wordt ondersteund en specificeert de compressiemethode die wordt gebruikt in de Content-Encoding- header.

HTTP-compressie bespaart aanzienlijke hoeveelheden gegevens, vooral met tekstuele gegevens (HTML, XHTML, CSS, Javascript-code, XML, JSON), omdat deze gemakkelijk kunnen worden gecomprimeerd. In het geval van gegevens die al zijn gecomprimeerd (bijvoorbeeld gangbare formaten voor afbeeldingen, audio en video), is (her)compressie nutteloos en wordt daarom meestal niet gebruikt.

In verband met communicatie die is versleuteld met TLS , leidt de compressie echter tot de BREACH- exploit , die de encryptie kan doorbreken .

Toepassingen via HTTP

HTTP als op tekst gebaseerd protocol wordt niet alleen gebruikt voor het verzenden van websites, het kan ook worden gebruikt in onafhankelijke toepassingen, de webservices . De HTTP-opdrachten zoals GET en POST worden gebruikt voor CRUD- bewerkingen. Dit heeft als voordeel dat er geen apart protocol voor datatransmissie hoeft te worden ontwikkeld. Dit wordt als voorbeeld gebruikt bij REST .

HTTP vergeleken met het QUIC-protocol

HTTP is gebaseerd op het Transmission Control Protocol (TCP). TCP bevestigt de ontvangst van elk datapakket. Dit betekent dat in het geval van een pakketverlies, alle andere pakketten moeten wachten tot het verloren exemplaar opnieuw wordt verzonden als de cache van de ontvanger overloopt ( head-of-line blocking [12] )

Het QUIC-protocol in zijn geheel is bedoeld om snellere verzending van datapakketten via het verbindingsloze UDP- protocol mogelijk te maken. Functies die het UDP-protocol mist - zoals ontvangstbevestigingen - moeten worden geleverd door het protocol van een hoger niveau. QUIC regelt zelf de verbindingscontrole, in het geval van een dataverbinding wisselen zender en ontvanger alleen het certificaat en de sleutel uit tijdens de eerste handshake, wat de latency vermindert. Voor verdere overdrachtsprocessen "onthoudt" QUIC de verbinding die in het verleden tot stand is gebracht en heeft toegang tot de opgeslagen gegevens. TLS versie 1.3 wordt momenteel gebruikt als het coderingsprotocol. Het QUIC-protocol biedt ook de mogelijkheid tot multiplexen . Via een client-server-verbinding kunnen meerdere datastromen tegelijk worden verzonden, wat de laadtijd aanzienlijk verkort. [13]

Zie ook

web links

Commons : Hypertext Transfer Protocol - verzameling van foto's, video's en audiobestanden

Individueel bewijs

  1. ^ Tim Berners-Lee: The Original HTTP zoals gedefinieerd in 1991 . In: w3.org , geraadpleegd op 13 november 2010.
  2. RFC 2616 Hypertext Transfer Protocol - HTTP / 1.1
  3. RFC's voor HTTP/2 gedefinieerd en geschreven . iX , nieuwsbericht van 15 mei 2015 14:23 uur
  4. Christian Kirsch: Microsoft heeft zijn eigen voorstel voor HTTP 2.heise.de, 29 maart 2012, geraadpleegd op 4 april 2012 .
  5. Christian Kirsch: SPDY van Google zou het web moeten versnellen . heise.de, 13 november 2009; Ontvangen 4 april 2012
  6. Conceptspecificatie van HPACK (het header-compressiealgoritme voor HTTP / 2). IETF HTTP-werkgroep
  7. HTTP / 2 - surf sneller met de nieuwe protocolversie. pcwelt.de, 30 januari 2016, geraadpleegd op 21 februari 2018 .
  8. M. Belshe, R. Peon, M. Thomson: Hypertext Transfer Protocol versie 2, gebruik van TLS-functies. Ontvangen 10 februari 2015 .
  9. Firefox 36 implementeert HTTP / 2
  10. IETF: HTTP over Quic wordt HTTP / 3. 12 november 2018, geraadpleegd op 27 april 2019 .
  11. Appendix B: Performance, Implementation, and Design Notes . In: World Wide Web Consortium [W3C] (Hrsg.): HTML 4.01 Specification . 24. Dezember 1999, B.2.2: Ampersands in URI attribute values ( w3.org ).
  12. Was ist HTTP? Abgerufen am 25. März 2021 .
  13. QUIC: Das steckt hinter dem experimentellen Google-Protokoll. Abgerufen am 25. März 2021 .