Hoi! Vandaag leren we over de HTTP- en HTTPS-protocollen. Maar laten we eerst één punt verduidelijken: we hebben het over protocollen voor het verzenden van gegevens over een netwerk op het toepassingsniveau van het OSI-model. U herinnert zich misschien dat we het OSI-model hebben leren kennen in een van de vorige artikelen. Als je dat niet meer weet, hier is het .
Wat is een datacommunicatieprotocol?
Dit noemen we de overeengekomen set regels waarmee ontwikkelaars van verschillende services informatie kunnen verzenden in een formaat dat anderen kunnen begrijpen. U kunt bijvoorbeeld Google Chrome gebruiken om informatie van zowel Facebook als Twitter te krijgen, omdat de ontwikkelaars deze verzenden via het standaard HTTP-protocol, waardoor uw browser deze kan verwerken. Uniforme regels zijn erg handig voor de mensen die het servergedeelte ontwikkelen: er zijn veel bibliotheken die informatie voor je kunnen converteren en verzenden met het juiste protocol. HTTP is oorspronkelijk bedacht als een protocol voor het verzenden van HTML-pagina's. Zo werd het lange tijd gebruikt, maar nu gebruiken programmeurs het vaak om zowel strings als mediabestanden te verzenden. Over het algemeen is dit protocol universeel geaccepteerd en veelzijdig, en het is heel gemakkelijk te gebruiken. En nu gaan we onderzoeken hoe het te gebruiken.
De structuur van HTTP
We moeten meteen opmerken dat het HTTP-protocol alleen uit tekst bestaat. Wat ons het meest interesseert is de structuur van deze tekst. Elk bericht bestaat uit drie delen:
Startlijn - Dit definieert enkele huishoudelijke gegevens.
Headers — Deze beschrijven de berichtparameters.
Body — Dit is de inhoud van het bericht. De hoofdtekst moet door een lege regel van de kopteksten worden gescheiden.
Het HTTP-protocol wordt gebruikt om verzoeken naar een server te verzenden en antwoorden van de server te ontvangen. De parameters van verzoeken en antwoorden zijn iets anders.
De berichttekst ontbreekt. In een HTTP-verzoek zijn alleen de startregel en de "Host"-header vereist. Laten we nu alles stap voor stap bekijken. Een HTTP-verzoek moet een methode bevatten. Er zijn er negen: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. De meest voorkomende zijn GET en POST. Deze twee methoden zullen in eerste instantie voldoende zijn. GET — Deze methode vraagt om inhoud van de server. Dienovereenkomstig hebben verzoeken met de GET-methode geen berichttekst. Maar als het nodig is, kunt u parameters doorgeven via het pad (in de startregel) in het volgende formaat:
waarbij codegym.cc de host is, /send het pad van het verzoek, en ? is een scheidingsteken dat aangeeft dat de queryparameters volgen. Aan het einde worden sleutel-waardeparen ("sleutel=waarde") weergegeven, gescheiden door een ampersand. POST — Deze methode publiceert informatie op de server. Een POST-verzoek kan verschillende soorten informatie verzenden: parameters als "sleutel=waarde"-paren, JSON, HTML-code of zelfs bestanden. Alle informatie wordt verzonden in de hoofdtekst van het bericht. Bijvoorbeeld:
Het verzoek wordt verzonden naar codegym.cc/user/create/json en de protocolversie is HTTP/1.1. "Accepteren" geeft het antwoordformaat aan dat de klant verwacht te ontvangen. "Content-Type" geeft het formaat aan van de berichttekst die in het verzoek is verzonden. "Content-Length" is het aantal karakters in de body. Een HTTP-verzoek kan veel verschillende headers bevatten. Bekijk voor meer informatie de specificatie van het protocol .
HTTP-antwoorden
Na ontvangst van een verzoek verwerkt de server het en stuurt een antwoord naar de client:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98
<html>
<head>
<title>An Example Page</title>
</head>
<body>
<p>Hello World</p>
</body>
</html>
De startregel van het antwoord bevat de protocolversie (HTTP/1.1), de statuscode (200) en de statusbeschrijving (OK). De headers bevatten het type en de lengte van de inhoud. De hoofdtekst van het antwoord bevat HTML-code die de browser weergeeft als een HTML-pagina.
Reactiestatuscodes
Alles is duidelijk wat betreft de berichttekst en headers, maar we moeten een paar woorden zeggen over statuscodes. Antwoordstatuscodes bestaan altijd uit drie cijfers. Het eerste cijfer van de code geeft de categorie van het antwoord aan:
1xx — Informatief. Het verzoek is ontvangen. De server is klaar om verder te gaan.
2xx — Succesvol. Het verzoek is ontvangen, begrepen en verwerkt.
3xx — Omleiding. Er moeten aanvullende acties worden uitgevoerd om de aanvraag te verwerken.
4xx — Clientfout. De aanvraag bevat fouten of voldoet niet aan het protocol.
5xx — Serverfout. Het verzoek was correct samengesteld, maar de server kon het niet verwerken.
Het tweede en derde cijfer in de code geven een specifieker antwoord aan. Bijvoorbeeld:
200 OK — Het verzoek is ontvangen en succesvol verwerkt.
201 Gemaakt: het verzoek is ontvangen en succesvol verwerkt, wat heeft geleid tot het maken van een nieuwe bron of instantie.
301 Permanent verplaatst — De aangevraagde resource is permanent verplaatst. Bij latere verzoeken moet het nieuwe adres worden gebruikt.
307 Tijdelijke omleiding — De bron is tijdelijk verplaatst. Voorlopig is het toegankelijk via automatisch doorsturen.
403 Verboden — Het verzoek is begrepen, maar autorisatie is vereist.
404 Niet gevonden — De server heeft de bron op dit adres niet gevonden.
501 Niet geïmplementeerd — De server ondersteunt niet de functionaliteit die nodig is om op het verzoek te reageren.
505 HTTP-versie niet ondersteund: de server ondersteunt de opgegeven versie van het HTTP-protocol niet.
Naast de responsstatuscode wordt ook een statusbeschrijving verzonden. Dit helpt te verduidelijken wat elke specifieke status betekent. Het HTTP-protocol is heel praktisch: het voorziet in een groot aantal headers, waarmee je heel flexibel de communicatie tussen een client en server kunt regelen. Een volledige afweging van alle verzoek- en antwoordheaders, verzoekmethoden en antwoordstatuscodes zou te veel zijn voor een enkel artikel. Indien nodig kunt u de officiële specificatie van het protocol lezen, die alle nuances beschrijft. Het is gebruikelijk om het HTTP-protocol op poort 80 te gebruiken, dus als u een URL ziet die eindigt op poort 80, kunt u erop vertrouwen dat u HTTP moet gebruiken om toegang te krijgen. Naarmate de technologie evolueerde en persoonlijke gegevens via internet werden verzonden, werd het noodzakelijk om na te denken over hoe extra bescherming kan worden geboden voor de informatie die de client naar de server stuurt. Het resultaat van dit denken was het HTTPS-protocol.
Het verschil tussen HTTPS en HTTP
Qua syntaxis is HTTPS identiek aan het HTTP-protocol. Dat wil zeggen, het gebruikt dezelfde startlijnen en kopteksten. De enige verschillen zijn extra codering en de standaardpoort (443) . HTTPS is versleuteld tussen HTTP en TCP, dat wil zeggen tussen de applicatie- en transportlagen. Als je bent vergeten wat dat betekent, bekijk dan het artikel over het OSI-model . De huidige encryptiestandaard is TLS. We zullen niet te veel op dit onderwerp ingaan, maar onthoud dat versleuteling plaatsvindt voordat informatie de transportlaag bereikt. Bij HTTPS wordt absoluut alle informatie versleuteld, behalve de host en poort waar het verzoek naartoe wordt gestuurd. Als u een server omschakelt om het HTTPS-protocol te gebruiken in plaats van HTTP, hoeft u de servercode niet te wijzigen. Deze functie is ingeschakeld in servletcontainers, die we in volgende artikelen zullen bespreken. En dat is alles voor vandaag. Wacht eigenlijk even. Om enkele HTTP-verzoeken te bemachtigen, opent u Google Chrome, drukt u op F12 en selecteert u het tabblad 'Netwerk'. Alle verzoeken en antwoorden die door uw browser zijn verzonden/ontvangen, worden hier weergegeven. Deel 4. De basis van Maven Deel 5. Servlets en de Java Servlet API. Een eenvoudige webapplicatie schrijven Deel 6. Servlet-containers Deel 7. Introductie van het MVC-patroon (Model-View-Controller)
Hoi! Vandaag leren we over de HTTP- en HTTPS-protocollen. Maar laten we eerst één punt verduidelijken: we hebben het over protocollen voor het verzenden van gegevens over een netwerk op het toepassingsniveau van het OSI-model. U herinnert zich misschien dat we het OSI-model hebben leren kennen in een van de vorige artikelen. Als je dat niet meer weet, hier is het .
GO TO FULL VERSION