Detaillierte Erklärung des HTTP-Protokolls (wirklich klassisch)

Einführung

HTTP ist ein objektorientiertes Protokoll, das zur Anwendungsschicht gehört. Aufgrund seiner einfachen und schnellen Art eignet es sich für verteilte Hypermedia-Informationssysteme. Es wurde 1990 vorgeschlagen und nach mehreren Jahren der Nutzung und Entwicklung kontinuierlich verbessert und erweitert. Die sechste Version von HTTP/1.0 wird derzeit im WWW verwendet. Die Standardisierungsarbeiten für HTTP/1.1 sind im Gange und der HTTP-NG-Vorschlag (Next Generation of HTTP) wurde vorgelegt.
Die Hauptfunktionen des HTTP-Protokolls können wie folgt zusammengefasst werden:
1. Unterstützung des Client/Server-Modus.
2. Einfach und schnell: Wenn ein Client einen Dienst vom Server anfordert, muss er nur die Anforderungsmethode und den Pfad übermitteln. Häufig verwendete Anforderungsmethoden sind GET, HEAD und POST. Jede Methode spezifiziert eine andere Art des Kontakts zwischen dem Client und dem Server. Aufgrund der Einfachheit des HTTP-Protokolls ist die Programmgröße des HTTP-Servers gering und die Kommunikationsgeschwindigkeit sehr hoch.
3. Flexibel: HTTP ermöglicht die Übertragung jeglicher Art von Datenobjekten. Der zu übertragende Typ wird durch Content-Type gekennzeichnet.
4. Keine Verbindung: Die Bedeutung von „Keine Verbindung“ besteht darin, jede Verbindung auf die Verarbeitung nur einer Anfrage zu beschränken. Nachdem der Server die Anfrage des Clients verarbeitet und die Antwort des Clients empfangen hat, wird die Verbindung getrennt. Diese Methode spart Übertragungszeit.
5. Zustandslos: Das HTTP-Protokoll ist ein zustandsloses Protokoll. Zustandslos bedeutet, dass das Protokoll über keine Speicherkapazität für die Transaktionsverarbeitung verfügt. Das Fehlen eines Status bedeutet, dass, wenn für die nachfolgende Verarbeitung die vorherigen Informationen erforderlich sind, diese erneut übertragen werden müssen, was zu einer Erhöhung der pro Verbindung übertragenen Datenmenge führen kann. Andererseits reagiert der Server schneller, wenn er keine vorherigen Informationen benötigt.

1. Detaillierte Erklärung des HTTP-Protokolls: URL

http (Hypertext Transfer Protocol) ist ein zustandsloses Protokoll auf Anwendungsebene, das häufig auf dem Anforderungs- und Antwortmodus basiert über die TCP-Verbindungsmethode Die HTTP 1.1-Version bietet einen kontinuierlichen Verbindungsmechanismus. Der überwiegende Teil der Webentwicklung besteht aus Webanwendungen, die auf dem HTTP-Protokoll basieren.

HTTP-URL (URL ist ein spezieller URI-Typ, der genügend Informationen enthält, um eine Ressource zu finden) hat das folgende Format:
http://host[":"port][ abs_path]
http bedeutet, Netzwerkressourcen über das HTTP-Protokoll zu finden. Host bedeutet, dass ein gültiger Internet-Host-Domänenname oder eine IP-Adresse eine Portnummer angibt. Wenn er leer ist, wird der Standardport 80 verwendet Wenn abs_path nicht in der URL angegeben ist, muss er bei Verwendung als Anforderungs-URI in der Form „/“ angegeben werden. Normalerweise erledigt der Browser diese Aufgabe automatisch für uns.
zB:
1. Geben Sie ein: www.guet.edu.cn
Der Browser konvertiert automatisch zu: http://www.guet.edu.cn/
2 :8080/index.jsp

2. Anfrage zur detaillierten Erläuterung des HTTP-Protokolls

Eine HTTP-Anfrage besteht aus drei Teilen, nämlich: Anfragezeile, Nachrichtenkopf und Anforderungstext

1. Die Anforderungszeile beginnt mit einem durch Leerzeichen getrennten Methodensymbol, gefolgt von der angeforderten URI und der Protokollversion. Das Format lautet wie folgt: Methodenanforderungs-URI HTTP-Version CRLF
wobei Methode stellt die Anforderungsmethode dar; „Request-URI“ ist eine einheitliche Ressourcenkennung; CRLF gibt die angeforderte HTTP-Protokollversion an (mit Ausnahme des CRLF am Ende sind keine separaten CR- oder LF-Zeichen zulässig). .

Es gibt viele Anforderungsmethoden (alle Methoden sind in Großbuchstaben angegeben):
GET-Anfrage zum Abrufen der durch Request-URI identifizierten Ressource
POST Die identifizierte Ressource per Request-URI Neue Daten anhängen
HEAD Anforderung zum Abrufen des Antwortnachrichtenheaders der durch Request-URI identifizierten Ressource
PUT Anforderung an den Server, eine Ressource zu speichern und Request-URI als Identifikator zu verwenden
DELETE Request Der Server soll den Request-URI löschen. Die identifizierte Ressource
TRACE fordert den Server auf, die empfangenen Request-Informationen zurückzusenden, die hauptsächlich für Tests oder Diagnosen verwendet werden.
CONNECT ist für die zukünftige Verwendung der
OPTIONS reserviert Anfrage zur Abfrage der Leistung des Servers oder zur Abfrage von Optionen und Anforderungen im Zusammenhang mit der Ressource
Anwendungsbeispiel:
GET-Methode: Beim Zugriff auf eine Webseite durch Eingabe der URL in die Adressleiste des Browsers verwendet der Browser die GET-Methode, um Ressourcen vom Server abzurufen, z. B.: GET /form.html HTTP/1.1 (CRLF)

Die POST-Methode erfordert, dass der angeforderte Server die an die Anfrage angehängten Daten akzeptiert, und wird häufig verwendet Formulare einreichen.
zB:POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,... (CRLF)
...
HOST:www.guet .edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) // Dieses CRLF zeigt an, dass der Nachrichtenheader beendet wurde. Davor war es der Nachrichtenheader
user=jeffrey&pwd=1234 //Die folgende Zeile enthält die übermittelten Daten

Die HEAD-Methode ist fast dieselbe wie die GET-Methode für die HEAD-Anfrage. Was den Antwortteil betrifft, sind die im HTTP-Header enthaltenen Informationen dieselben wie die, die über die GET-Anfrage erhalten wurden. Mit dieser Methode können Informationen über die durch den Request-URI identifizierte Ressource abgerufen werden, ohne den gesamten Ressourceninhalt zu übertragen. Diese Methode wird häufig verwendet, um die Gültigkeit eines Hyperlinks zu testen, ob er zugänglich ist und ob er kürzlich aktualisiert wurde.
2. Anforderungsheaderbeschreibung
3. Anforderungstext (weggelassen)

3. Antwortkapitel mit detaillierter Erläuterung des HTTP-Protokolls

Nach dem Empfang und der Interpretation der Anforderungsnachricht gibt der Server eine HTTP-Antwortnachricht zurück.

HTTP-Antwort besteht ebenfalls aus drei Teilen, nämlich: Statuszeile, Nachrichtenkopf, Antworttext
1 Das Format der Statuszeile ist wie folgt:
HTTP-Version Status-Code Reason- Phrase CRLF
Unter diesen stellt HTTP-Version die Version des Server-HTTP-Protokolls dar; Reason-Phrase stellt die Textbeschreibung des Statuscodes dar;
Der Statuscode besteht aus drei Ziffern. Die erste Zahl definiert die Kategorie der Antwort und hat fünf mögliche Werte:
1xx: Anzeigeinformationen – zeigt an, dass die Anfrage empfangen wurde und weiterhin verarbeitet wird
2xx: Erfolg – ​​Zeigt an, dass die Anfrage erfolgreich empfangen, verstanden und akzeptiert wurde
3xx: Umleitung – Weitere Vorgänge müssen ausgeführt werden, um die Anfrage abzuschließen
4xx: Clientfehler – Die Anfrage weist einen Syntaxfehler auf oder die Anfrage kann nicht erfüllt werden
5xx: Serverseitiger Fehler – der Server konnte eine rechtliche Anfrage nicht umsetzen
Allgemeine Statuscodes, Statusbeschreibungen, Anweisungen:
200 OK //Client-Anfrage erfolgreich
400 Bad Request //Client-Anfrage ist gültig Syntaxfehler, kann vom Server nicht verstanden werden
401 Unauthorized //Die Anfrage ist nicht autorisiert, dieser Statuscode muss zusammen mit dem WWW-Authenticate-Header-Feld verwendet werden
403 Forbidden //Der Server hat die Anfrage empfangen, sich jedoch geweigert, den Dienst bereitzustellen
404 Not Found //Die angeforderte Ressource existiert nicht, z. B.: Die falsche URL wurde eingegeben
500 Interner Serverfehler //Ein unerwarteter Fehler ist aufgetreten in der Server
503 Server nicht verfügbar //Der Server ist derzeit nicht in der Lage, die Anfrage des Clients zu verarbeiten, ein Absatz Es kann nach einiger Zeit zum Normalzustand zurückkehren
z. B.: HTTP/1.1 200 OK (CRLF)

2. Der Antwortheader wird später beschrieben

3. Der Antworttext ist der Inhalt der vom Server zurückgegebenen Ressource

4. Detaillierte Erläuterung des HTTP-Protokolls – Nachricht Header

HTTP-Nachricht besteht aus einer Anfrage vom Client an den Server und einer Antwort vom Server an den Client. Sowohl Anforderungsnachrichten als auch Antwortnachrichten bestehen aus einer Startzeile (bei einer Anforderungsnachricht ist die Startzeile die Anforderungszeile, bei einer Antwortnachricht ist die Startzeile die Statuszeile), einem Nachrichtenkopf (optional), einer Leerzeile ( eine Zeile nur mit CRLF) und die Zusammensetzung des Nachrichtentextes (optional).

HTTP-Nachrichtenheader umfassen normale Header, Anforderungsheader, Antwortheader und Entitätsheader.
Jedes Header-Feld besteht aus Name + „:“ + Leerzeichen + Wert. Der Name des Nachrichten-Header-Felds ist unabhängig von der Groß- und Kleinschreibung.

1. Gewöhnliche Header
In gewöhnlichen Headern gibt es einige Header-Felder, die für alle Anfrage- und Antwortnachrichten verwendet werden, jedoch nicht für die übertragenen Entitäten, sondern nur für die übertragenen Nachrichten.
zB:
Cache-Control wird verwendet, um Cache-Anweisungen anzugeben. Die Cache-Anweisungen sind unidirektional (die Cache-Anweisungen, die in der Antwort erscheinen, erscheinen möglicherweise nicht in der Anfrage) und sind unabhängig (die Cache-Anweisungen von a Die Nachricht wird nicht über einen Caching-Mechanismus gespeichert, der sich auf die Verarbeitung einer anderen Nachricht auswirkt. Ein ähnliches Header-Feld, das von HTTP 1.0 verwendet wird, ist Pragma.
Cache-Anweisungen bei Anfragen umfassen: No-Cache (wird verwendet, um anzugeben, dass Anforderungs- oder Antwortnachrichten nicht zwischengespeichert werden können), No-Store, Max-Age, Max-Stale, Min-fresh, Only-if-cached;
Die Caching-Anweisungen als Antwort umfassen: public, private, no-cache, no-store, no-transform, Must-revalidate, Proxy-revalidate, max-age, s-maxage, zB: Um IE anzuweisen Browser ( Client) Die Seite nicht zwischenspeichern. Das serverseitige JSP-Programm kann wie folgt geschrieben werden: Response.sehHeader("Cache-Control","no-cache");
//response.setHeader("Pragma ","no-cache" ); Die Funktion entspricht dem obigen Code, normalerweise werden beide // zusammen verwendet
Dieser Code legt das gemeinsame Header-Feld in der gesendeten Antwortnachricht fest: Cache-Control: no-cache

Datum Allgemein Das Header-Feld gibt das Datum und die Uhrzeit an, zu der die Nachricht generiert wurde

Verbindung Das gemeinsame Header-Feld ermöglicht das Senden von Optionen zur Angabe der Verbindung. Geben Sie beispielsweise an, dass die Verbindung kontinuierlich ist, oder geben Sie die Option „Schließen“ an, um den Server zu benachrichtigen, die Verbindung zu schließen, nachdem die Antwort abgeschlossen ist

2. Anforderungsheader
Der Anforderungsheader ermöglicht es dem Client, zusätzliche Informationen der Anforderung und die eigenen Informationen des Clients an den Server zu übergeben.
Häufig verwendete Anforderungsheader
Akzeptieren
Das Feld „Anforderungsheader akzeptieren“ wird verwendet, um anzugeben, welche Arten von Informationen der Client akzeptiert. Beispiel: Accept: image/gif, was angibt, dass der Client Ressourcen im GIF-Bildformat akzeptieren möchte; Accept: text/html, was angibt, dass der Client HTML-Text akzeptieren möchte.
Accept-Charset
Das Anforderungsheaderfeld Accept-Charset wird verwendet, um den vom Client akzeptierten Zeichensatz anzugeben. Beispiel: Accept-Charset:iso-8859-1, gb2312. Wenn dieses Feld in der Anforderungsnachricht nicht festgelegt ist, ist standardmäßig jeder Zeichensatz akzeptabel.
Accept-Encoding
Das Anforderungsheaderfeld „Accept-Encoding“ ähnelt „Akzeptieren“, wird jedoch verwendet, um eine akzeptable Inhaltskodierung anzugeben. Beispiel: Accept-Encoding:gzip.deflate Wenn diese Domäne nicht in der Anforderungsnachricht festgelegt ist, geht der Server davon aus, dass der Client verschiedene Inhaltskodierungen akzeptieren kann.
Accept-Language
Das Anforderungsheaderfeld Accept-Language ähnelt Accept, wird jedoch zur Angabe einer natürlichen Sprache verwendet. Beispiel: Accept-Language:zh-cn. Wenn dieses Header-Feld in der Anforderungsnachricht nicht gesetzt ist, geht der Server davon aus, dass der Client verschiedene Sprachen akzeptieren kann.
Autorisierung
Das Headerfeld „Autorisierungsanforderung“ wird hauptsächlich verwendet, um nachzuweisen, dass der Client das Recht hat, eine bestimmte Ressource anzuzeigen. Wenn der Browser auf eine Seite zugreift und vom Server den Antwortcode 401 (Nicht autorisiert) erhält, kann er eine Anfrage senden, die das Header-Feld „Autorisierungsanforderung“ enthält, um den Server zur Überprüfung aufzufordern.
Host (dieses Header-Feld ist beim Senden einer Anfrage erforderlich)
Das Host-Anfrage-Header-Feld wird hauptsächlich zur Angabe des Internet-Hosts und der Portnummer der angeforderten Ressource verwendet. Es wird normalerweise aus der HTTP-URL extrahiert, z. B.
Wir geben in den Browser ein: http://www.guet.edu.cn/index.html
Die vom Browser gesendete Anforderungsnachricht enthält das Host-Anforderungsheaderfeld wie folgt:
Host: www .guet.edu.cn
Hier wird die Standard-Portnummer 80 verwendet. Wenn eine Portnummer angegeben wird, lautet sie: Host: www.guet.edu.cn:Specify port number
User-Agent
Wenn wir uns online im Forum anmelden, sehen wir häufig einige Willkommensnachrichten, in denen der Name und die Version Ihres Betriebssystems sowie der Name und die Version des von Ihnen verwendeten Browsers aufgeführt sind. Dies ist für viele Menschen tatsächlich erstaunlich Auf dieser Seite erhält die Serveranwendung diese Informationen aus dem User-Agent-Anforderungsheaderfeld. Das User-Agent-Anforderungsheaderfeld ermöglicht es dem Client, dem Server sein Betriebssystem, seinen Browser und andere Attribute mitzuteilen. Dieses Header-Feld ist jedoch nicht erforderlich. Wenn wir selbst einen Browser schreiben und das User-Agent-Anfrage-Header-Feld nicht verwenden, kann der Server unsere Informationen nicht kennen.
Beispiel für einen Anforderungsheader:
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/ vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla /4.0(kompatibel;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Verbindung:Keep-Alive (CRLF)
(CRLF)

3. Antwortheader
Der Antwortheader ermöglicht es dem Server, zusätzliche Antwortinformationen zu übergeben, die nicht in der Statuszeile platziert werden können, sowie Informationen über den Server und Informationen über den nächsten Zugriff auf die durch die Anfrage identifizierte Ressource -URI.
Häufig verwendete Antwortheader
Standort
Das Antwortheaderfeld „Standort“ wird verwendet, um den Empfänger an einen neuen Standort umzuleiten. Das Feld „Location Response Header“ wird häufig beim Ändern von Domänennamen verwendet.
Server
Das Server-Antwort-Header-Feld enthält Informationen über die Software, die der Server zur Verarbeitung der Anfrage verwendet. Entspricht dem User-Agent-Anforderungsheaderfeld. Das Folgende ist ein Beispiel für ein
Server-Antwort-Header-Feld:
Server: Apache-Coyote/1.1
WWW-Authenticate Das
WWW-Authenticate-Antwort-Header-Feld muss in einem 401 (Unauthorized) enthalten sein. Antwortnachricht Wenn der Client die 401-Antwortnachricht empfängt und das Autorisierungs-Header-Feld sendet, um den Server zur Überprüfung aufzufordern, enthält der Server-Antwort-Header dieses Header-Feld.
zB: WWW-Authenticate:Basic realm="Basic Auth Test!" // Es ist ersichtlich, dass der Server einen grundlegenden Authentifizierungsmechanismus zum Anfordern von Ressourcen verwendet.

4. Entitätsheader
Sowohl Anforderungs- als auch Antwortnachrichten können eine Entität übertragen. Eine Entität besteht aus einem Entitäts-Header-Feld und einem Entitäts-Körper. Dies bedeutet jedoch nicht, dass das Entitäts-Header-Feld und der Entitäts-Körper zusammen gesendet werden müssen. Der Entitätsheader definiert Metainformationen über den Entitätskörper (z. B. Vorhandensein oder Fehlen eines Entitätskörpers) und die durch die Anfrage identifizierte Ressource.
Häufig verwendete Entitätsheader
Content-Encoding
Das Content-Encoding-Entitätsheaderfeld wird als Modifikator des Medientyps verwendet. Sein Wert gibt die Codierung zusätzlicher Inhalte an, die auf den Entitätskörper angewendet wurden. Daher muss der entsprechende Dekodierungsmechanismus verwendet werden, um den im Content-Type-Headerfeld referenzierten Medientyp zu erhalten. Content-Encoding wird verwendet, um die Komprimierungsmethode des Dokuments aufzuzeichnen, z. B.: Content-Encoding: gzip
Content-Language
Content-Language-Entitätsheaderfeld beschreibt die natürliche Sprache, die von der Ressource verwendet wird. Wenn dieses Feld nicht gesetzt ist, wird davon ausgegangen, dass der Entitätsinhalt den Lesern in allen Sprachen zur Verfügung steht
. Beispiel: Content-Language:da
Content-Length
Das Entitätsheaderfeld „Content-Length“ wird verwendet, um die Länge des Entitätskörpers anzugeben, ausgedrückt als in Bytes gespeicherte Dezimalzahl.
Content-Type
Das Entitätsheaderfeld „Content-Type“ wird verwendet, um den Medientyp des an den Empfänger gesendeten Entitätstexts anzugeben. Beispiel:
Content-Type: text/html; charset=ISO-8859-1
Content-Type: text/html; Datum und Uhrzeit der letzten Änderung der Ressource.
Läuft ab
Das Entitätsheaderfeld „Expires“ gibt das Datum und die Uhrzeit an, zu der die Antwort abläuft. Damit der Proxyserver oder Browser die Seite im Cache nach einer gewissen Zeit aktualisieren kann (wenn Sie erneut auf die zuvor besuchte Seite zugreifen, laden Sie diese direkt aus dem Cache, verkürzen Sie die Antwortzeit und reduzieren Sie die Serverlast), können wir dies tun Verwenden Sie das Entitätsheaderfeld „Expires“, um die Ablaufzeit der Seite anzugeben. Beispiel: Läuft ab: Do, 15. September 2006 16:23:12 GMT
Clients und Caches von HTTP 1.1 MÜSSEN andere illegale Datumsformate (einschließlich 0) als abgelaufen behandeln. Beispiel: Um zu verhindern, dass der Browser die Seite zwischenspeichert, können wir auch das Expires-Entitätsheaderfeld verwenden und es auf 0 setzen. Das Programm in JSP lautet wie folgt: Response.setDateHeader("Expires","0");

5. Verwenden Sie Telnet, um den Kommunikationsprozess des http-Protokolls zu beobachten

Zweck und Prinzip des Experiments:

Verwenden Sie das Telnet-Tool von MS, um eine Anfrage an den zu senden Server durch manuelle Eingabe von http-Anforderungsinformationen, und der Server empfängt. Nach der Interpretation und Annahme der Anforderung wird eine Antwort zurückgegeben, die im Telnet-Fenster angezeigt wird, wodurch das Verständnis des Kommunikationsprozesses des http-Protokolls wahrnehmungsmäßig vertieft wird.

Experimentelle Schritte:

1. Öffnen Sie Telnet

1.1 Öffnen Sie Telnet

Ausführen-->cmd-->telnet

1.2 Öffnen Sie die Telnet-Echo-Funktion

Localecho einstellen

2. Stellen Sie eine Verbindung zum Server her und senden Sie eine Anfrage

2.1 Öffnen Sie www.guet.edu.cn 80 //Beachten Sie, dass die Portnummer nicht weggelassen werden darf

HEAD /index.asp HTTP/1.0

Host:www.guet.edu.cn

/*Wir können die Anforderungsmethode ändern und den Inhalt der Guilin Electronics-Homepage anfordern. Geben Sie die Nachricht wie folgt ein*/
öffne www.guet.edu.cn 80

GET /index.asp HTTP/1.0 //Der Inhalt der angeforderten Ressource
Host:www.guet.edu.cn

2.2 www.sina.com.cn 80 öffnen //Telnet direkt an der Eingabeaufforderung eingeben www.sina.com.cn 80

HEAD /index.asp HTTP/1.0

Host:www.sina.com .cn


3 Experimentelle Ergebnisse:

3.1 Die durch die Anforderung von Informationen 2.1 erhaltene Antwort lautet:

HTTP/1.1 200 OK //Webserver >Datum: Do ,08. März 200707:17:51 GMT

Verbindung: Keep-Alive     

Inhaltslänge: 23330
Inhaltstyp: Text/HTML
Ablaufdatum: Do,08. März 2007 07:16:51 GMT
Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Cache-control: privat

//Ressourceninhalt weggelassen

3.2 Erhalten aus Anforderungsinformationen 2.2 Die Antwort lautet:

HTTP/1.0 404 nicht gefunden //Anfrage fehlgeschlagen
Datum: Do, 08. März 2007 07:50:50 GMT
Server: Apache/2.0.54
Letzte Änderung: Do, 30. Nov. 2006 11:35:41 GMT
ETag: "6277a-415-e7c76980"
Accept-Ranges: Bytes
X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
Vary: Accept-Encoding
Content-Type: text/html
X-Cache: MISS from zjm152-78.sina.com.cn
Via: 1.0 zjm152-78.sina.com.cn :80
X-Cache: MISS von th-143.sina.com.cn
Verbindung: schließen

Verbindung zum Host verloren

Drücken Sie eine beliebige Taste, um fortzufahren...

4. Hinweise: 1. Wenn ein Eingabefehler vorliegt, ist die Anfrage nicht erfolgreich.
2. Im Header-Feld wird die Groß-/Kleinschreibung nicht beachtet.
3. Um mehr über das HTTP-Protokoll zu erfahren, können Sie sich RFC2616 ansehen und die Datei unter http://www.letf.org/rfc finden.
4. Um Hintergrundprogramme zu entwickeln, müssen Sie das http-Protokoll beherrschen

6. Technische Ergänzungen zum HTTP-Protokoll

1. Grundlagen:
Zu den High-Level-Protokollen gehören: File Transfer Protocol FTP, Email Transfer Protocol SMTP, Domain Name System Service DNS, Network News Transfer Protocol NNTP und HTTP-Protokolle usw.
Es gibt drei Typen von Vermittlern: Proxy), Gateway und Tunnel, ein Proxy akzeptiert Anfragen entsprechend dem absoluten Format des URI, schreibt die Nachricht ganz oder teilweise um und sendet die formatierte Anfrage über die URI-Kennung an den Server. Ein Gateway ist ein empfangender Proxy, der als Schicht über einem anderen Server fungiert und bei Bedarf Anfragen in das zugrunde liegende Serverprotokoll übersetzen kann. Ein Kanal fungiert als Relaispunkt zwischen zwei Verbindungen, die Nachrichten nicht ändern. Kanäle werden häufig verwendet, wenn die Kommunikation über einen Vermittler (z. B. eine Firewall usw.) erfolgen muss oder wenn der Vermittler den Inhalt der Nachricht nicht identifizieren kann.
Proxy: Ein Zwischenprogramm, das als Server oder Client fungieren kann, um Anfragen für andere Clients einzurichten. Anfragen werden über mögliche Übersetzungen intern oder über andere Server weitergeleitet. Ein Proxy muss eine Anforderungsnachricht interpretieren und wenn möglich neu schreiben, bevor er sie sendet. Ein Proxy fungiert oft als Portal für Clients durch eine Firewall. Ein Proxy kann auch als Hilfsanwendung dienen, um Anfragen über ein Protokoll zu verarbeiten, die nicht vom Benutzeragenten ausgeführt werden.
Gateway: Ein Server, der als Vermittler für andere Server fungiert. Im Gegensatz zu einem Proxy akzeptiert ein Gateway Anfragen, als ob es der Ursprungsserver für die angeforderte Ressource wäre; der anfragende Client weiß nicht, dass es sich um das Gateway handelt.
Ein Gateway fungiert häufig als serverseitiges Portal über eine Firewall hinweg. Ein Gateway kann auch als Protokollübersetzer für den Zugriff auf Ressourcen fungieren, die in Nicht-HTTP-Systemen gespeichert sind.
Kanal (Tunnel): Es handelt sich um ein Vermittlungsprogramm, das als Relais zwischen zwei Verbindungen fungiert. Nach der Aktivierung wird der Kanal nicht als Teil der HTTP-Kommunikation betrachtet, obwohl der Kanal durch eine HTTP-Anfrage initiiert werden kann. Wenn beide Enden der weitergeleiteten Verbindung geschlossen werden, verschwindet der Kanal. Kanäle werden häufig verwendet, wenn ein Portal vorhanden sein muss oder wenn ein Vermittler den weitergeleiteten Datenverkehr nicht interpretieren kann.

2. Vorteile der Protokollanalyse – HTTP-Analysator erkennt Netzwerkangriffe
Die modulare Analyse und Verarbeitung von High-Level-Protokollen wird die Richtung der zukünftigen Einbruchserkennung sein.
Häufig verwendete Ports 80, 3128 und 8080 von HTTP und sein Proxy werden im Netzwerkabschnitt mithilfe des Port-Tags angegeben

3. Schwachstelle hinsichtlich der Inhaltslängenbeschränkung des HTTP führt zu einem Denial-of-Service-Angriff
Wann Mit der POST-Methode kann ContentLenth so eingestellt werden, dass die Länge der zu übertragenden Daten definiert wird, z. B. ContentLenth:999999999. Der Speicher wird erst freigegeben, wenn die Übertragung abgeschlossen ist. Ein Angreifer kann diesen Fehler ausnutzen, um kontinuierlich Müll zu senden Daten an den WEB-Server weiter, bis der WEB-Server nicht mehr über genügend Speicher verfügt. Diese Angriffsmethode hinterlässt grundsätzlich keine Spuren.
http://www.cnpaf.net/Class/HTTP/0532918532667330.html

Einige Ideen zur Nutzung der Eigenschaften des HTTP-Protokolls zur Durchführung von Denial-of-Service-Angriffen
Die Serverseite ist mit der Verarbeitung der gefälschten TCP-Verbindungsanforderung des Angreifers beschäftigt und hat keine Zeit, sich um die normale Anforderung des Clients zu kümmern (schließlich ist die normale Anforderungsquote des Clients zu diesem Zeitpunkt aus Sicht eines normalen Clients sehr gering). Reaktion: Der Server ist einem SYNFlood-Angriff ausgesetzt.
Smurf, TearDrop usw. verwenden ICMP-Nachrichten, um Flood- und IP-Fragmentierungsangriffe durchzuführen. In diesem Artikel wird die Methode „Normale Verbindung“ verwendet, um einen Denial-of-Service-Angriff zu generieren.
Port 19 wurde in den frühen Tagen für Chargen-Angriffe verwendet, nämlich Chargen_Denial_of_Service, aber! Die von ihnen verwendete Methode bestand darin, eine UDP-Verbindung zwischen zwei Chargen-Servern zu erstellen, wodurch der Server zu viele Informationen verarbeiten und heruntergefahren werden konnte. Dann müssen zwei Bedingungen für das Abschalten eines WEB-Servers vorliegen: 1. Es gibt einen Chargen-Dienst. 2. Da ist HTTP Service
Methode: Der Angreifer fälscht die Quell-IP und sendet eine Verbindungsanforderung (Connect) an N Chargens. Nachdem Chargen die Verbindung erhalten hat, gibt er einen 72-Byte-Zeichenstrom pro Sekunde zurück (eigentlich, je nach aktuellem Stand). Netzwerkbedingungen, diese Geschwindigkeit ist schneller) an den Server.

5. Http-Fingerprinting-Technologie
Das Prinzip des Http-Fingerprintings ist im Grunde dasselbe: Die Aufzeichnung der geringfügigen Unterschiede in der Ausführung des Http-Protokolls durch verschiedene Server ist besser als der TCP/IP-Stack Fingerabdruck ist viel komplizierter. Der Grund dafür ist, dass das Anpassen der Konfigurationsdatei des HTTP-Servers und das Hinzufügen von Plug-Ins oder Komponenten das Ändern der HTTP-Antwortinformationen erleichtert, was jedoch die Identifizierung erschwert und das Verhalten des TCP/IP-Servers anpasst. Der IP-Stack erfordert eine Änderung der Kernschicht, daher ist es leicht zu identifizieren.
Es ist sehr einfach, den Server so einzurichten, dass er verschiedene Banner-Informationen zurückgibt. Bei Open-Source-HTTP-Servern wie Apache können Benutzer die Banner-Informationen in der Quelle ändern Code, und starten Sie dann den HTTP-Dienst neu, damit er wirksam wird. Für HTTP-Server, die keinen Open-Source-Code haben, wie z. B. Microsoft IIS oder Netscape, können Sie ihn in der DLL-Datei ändern, in der Banner-Informationen gespeichert werden Ich werde hier nicht auf Details eingehen, die Wirkung einer solchen Änderung ist jedoch immer noch gut. Eine andere Möglichkeit, Bannerinformationen zu verschleiern, ist die Verwendung eines Plug-Ins.
Häufige Testanfragen:
1: HEAD/Http/1.0 sendet grundlegende HTTP-Anfragen
2: DELETE/Http/1.0 sendet die Anfragen, die nicht zulässig sind, wie z. B. Löschanfragen
3: GET/Http/3.0 sendet eine ungültige Version der HTTP-Protokollanforderung
4: GET/JUNK/1.0 sendet eine falsche Spezifikation der HTTP-Protokollanforderung
Http-Fingerabdruck-Identifizierungstool Httprint, das statistische Prinzipien zum Kombinieren verwendet Die Fuzzy-Logic-Technologie kann den Typ des HTTP-Servers effektiv bestimmen. Sie kann zum Sammeln und Analysieren von Signaturen verwendet werden, die von verschiedenen HTTP-Servern generiert werden.

6. Um die Leistung der Benutzer bei der Verwendung des Browsers zu verbessern, unterstützen moderne Browser auch gleichzeitige Zugriffsmethoden. Beim Durchsuchen einer Webseite werden mehrere Verbindungen gleichzeitig hergestellt, um schnell mehrere Symbole zu erhalten auf einer Webseite, wodurch die Übertragung der gesamten Webseite schneller abgeschlossen werden kann.
HTTP1.1 bietet diese kontinuierliche Verbindungsmethode und die nächste Generation des HTTP-Protokolls: HTTP-NG hat Unterstützung für Sitzungssteuerung, Rich-Content-Aushandlung und andere Methoden hinzugefügt, um
eine effizientere Verbindung zu ermöglichen.