Bitte geben Sie die Quelle für den Nachdruck an: Einführung in HTTP, http ist ein objektorientiertes Protokoll, das zur Anwendungsschicht gehört
Einführung
HTTP ist ein objektorientiertes Protokoll der Anwendungsschicht. Aufgrund seiner einfachen und schnellen Methode eignet sich HTTP für verteilte Hypermedia-Informationssysteme. Es wurde 1990 vorgeschlagen und nach mehreren Jahren der Nutzung und Entwicklung kontinuierlich verbessert und erweitert. Derzeit wird im WWW die sechste Version von HTTP/1.0 verwendet. Die Standardisierungsarbeiten von HTTP/1.1 und die HTTP-NG-Vorschläge (Next Generation of HTTP) sind im Gange wurden gemacht.
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 von Kontakt 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 Erläuterung des HTTP-Protokolls – URL
HTTP (Hypertext Transfer Protocol) ist ein zustandsloses Protokoll auf Anwendungsebene, das auf der TCP-Verbindungsmethode basiert Anwendungen, 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://www.php.cn /[":" port][abs_path]
http bedeutet, Netzwerkressourcen über das HTTP-Protokoll zu finden; Host bedeutet, dass ein legaler Internet-Host-Domänenname oder eine IP-Adresse eine Portnummer angibt, wenn diese leer ist. Verwenden Sie die Standardeinstellung Port 80; abs_path gibt den URI der angeforderten Ressource an; wenn abs_path nicht in der URL angegeben ist, muss er bei Verwendung als Anforderungs-URI in der Form „/“ angegeben werden für uns.
zB:
1. Eingabe: www.guet.edu.cn
Der Browser konvertiert automatisch zu: http:// www.php.cn/
2. http:192.168.0.116:8080/index.jsp
2. Bitte um detaillierte Erläuterung des HTTP-Protokolls
Eine HTTP-Anfrage besteht aus drei Teilen: Anforderungszeile, 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: Methode Anforderungs-URI HTTP-Version CRLF
Methode stellt die Anforderungsmethode dar; Request-URI Es handelt sich um eine einheitliche Ressourcenkennung. HTTP-Version gibt die angeforderte HTTP-Protokollversion an. CRLF gibt Wagenrücklauf und Zeilenvorschub 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 Fügen Sie nach dem eine neue Ressource hinzu durch Request-URI identifizierte Ressource Die Daten
HEAD Fordert an, den Antwortnachrichtenheader der durch Request-URI identifizierten Ressource zu erhalten
PUT Fordert den Server auf, eine Ressource zu speichern und verwendet Request-URI als Identifikator
DELETE Fordert den Server auf, die durch Request-URI Resource identifizierte Ressource zu löschen
TRACE Fordert den Server auf, die empfangenen Anforderungsinformationen zurückzusenden, die hauptsächlich für Tests oder Diagnosen verwendet werden
CONNECT Für zukünftige Verwendung reserviert
OPTIONS-Anfrage zur Abfrage der Leistung des Servers oder Abfrageoptionen 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 abzurufen der Server, 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 zum Senden von Formularen verwendet.
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 identisch mit der GET-Methode. Für den Antwortteil der HEAD-Anfrage sind die in ihrem 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. Beschreibung des Anforderungsheaders
3. Anforderungstext (weggelassen)
3. Antwortkapitel Detaillierte 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 Statuszeilenformat ist wie folgt:
HTTP-Version Status-Code Reason-Phrase CRLF
Dabei stellt HTTP-Version die Version des Server-HTTP-Protokolls dar; Status-Code stellt den vom Server zurückgesendeten Antwortstatuscode 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: Nachrichtenkopf
HTTP-Nachrichten bestehen aus Client-zu-Server-Anfragen und Server-zu-Client-Antworten. 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) und einer Leerzeile (nur CRLF). Zeile), Nachrichtentext (optional) Zusammensetzung.
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 Anforderungs- 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;
Zu den Caching-Anweisungen als Antwort gehören: 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
Das gemeinsame Kopfzeilenfeld „Datum“ gibt das Datum und die Uhrzeit an, zu der die Nachricht generiert wurde
Das Feld „Connection common header“ ermöglicht das Senden verbindungsspezifischer Optionen. 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.php.cn/
Die vom Browser gesendete Anforderungsnachricht enthält das Host-Anforderungsheaderfeld wie folgt :
Host: www.guet.edu.cn
Die Standard-Portnummer 80 wird hier verwendet. Wenn die Portnummer angegeben wird, lautet sie: Host: www.guet.edu.cn:Portnummer angeben
User-Agent
Wenn wir uns online im Forum anmelden, sehen wir häufig einige Willkommensnachrichten, in denen die aufgeführt sind Der Name und die Version Ihres Betriebssystems sowie der Name und die Version des von Ihnen verwendeten Browsers sorgen oft für Erstaunen. Tatsächlich erhält die Serveranwendung diese Informationen aus dem User-Agent-Anfrage-Header-Feld. 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 Anforderung 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 Content-Type-Entitätsheaderfeld 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, wann 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 sie direkt aus dem Cache, um die Antwortzeit zu verkürzen und die Serverlast zu reduzieren), 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 Server zu senden, indem Sie die HTTP-Anfrageinformationen manuell eingeben. Nachdem der Server die Anfrage empfangen, interpretiert und akzeptiert, gibt er eine Antwort zurück in Telnet angezeigt werden Es wird im Fenster angezeigt, wodurch das Verständnis des Kommunikationsprozesses des http-Protokolls aus wahrnehmungsbezogener Sicht vertieft wird.
1. Telnet öffnen
1.1 Telnet öffnenAusführen-->cmd-->telnet
Localecho einstellen
2. Stellen Sie eine Verbindung zum Server her und senden Sie eine Anfrage
HEAD /index.asp HTTP/1.0
2.2 öffnen www.sina.com.cn 80 //Geben Sie Telnet direkt an der Eingabeaufforderung ein www.sina.com.cn 80
3 Experimentelle Ergebnisse:
3.1 Die durch die Informationsanfrage 2.1 erhaltene Antwort lautet:
http/1.1 200 ok // Anfrage erfolgreich
//Ressourceninhalt weggelassen
3.2 Die durch die Informationsanfrage 2.2 erhaltene Antwort lautet:
HTTP/1.0 404 nicht gefunden //Anfrage fehlgeschlagen
Drücken Sie eine beliebige Taste, um fortzufahren...
4. Hinweise: 1. Bei einem Eingabefehler ist die Anfrage nicht erfolgreich.
6. Technische Ergänzungen zum HTTP-Protokoll
1. Grundlagen:
2.1 Öffnen Sie www.guet.edu.cn 80 //Beachten Sie, dass die Portnummer nicht weggelassen werden darf
Host:www.guet.edu.cn
/*Wir können die Anforderungsmethode ändern und den Inhalt der Guilin Electronics-Homepage anfordern. Geben Sie die Nachricht als ein folgt*/
open www.guet.edu.cn 80
GET /index.asp HTTP/1.0 //Der Inhalt der angeforderten Ressource
Host: www.guet .edu.cn
HEAD /index.asp HTTP/1.0
Host:www.sina.com.cn
Server: Microsoft-IIS/5.0 // Webserver
Datum: DO, 08. MÄRZ 2007 07: 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-Kontrolle: privat
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
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.php.cn/ finden.
4. Um Hintergrundprogramme zu entwickeln, müssen Sie das http-Protokoll beherrschen
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 intern oder über mögliche Übersetzungen ü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.php.cn/
Einige Ideen zur Nutzung der Eigenschaften des HTTP-Protokolls zur Durchführung von Denial-of-Service-Angriffen
Der Server ist mit der Verarbeitung der gefälschten TCP-Verbindungsanfrage beschäftigt Der Angreifer hat keine Zeit, sich um die normale Anfrage des Clients zu kümmern (schließlich ist die normale Anfragequote des Clients sehr gering). Zu diesem Zeitpunkt verliert der Server aus Sicht eines normalen Clients die Antwort heißt: Der Server ist einem SYNFlood-Angriff (SYN-Flood-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 der Anfangszeit für Chargen-Angriffe verwendet, nämlich Chargen_Denial_of_Service, aber! Die Methode, die sie verwenden, besteht darin, eine UDP-Verbindung zwischen zwei Chargen-Servern zu erstellen, wodurch der Server zu viele Informationen verarbeiten und heruntergefahren werden kann. 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 Stationen. Nachdem Chargen die Verbindung empfangen hat, gibt er einen 72-Byte-Zeichenstrom pro Sekunde zurück (tatsächlich laut tatsächliche 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, sodass er leicht zu erkennen ist.
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. Bei HTTP-Servern, die keinen Open-Source-Code haben, wie z. B. 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 eine einfache HTTP-Anfrage
2: DELETE/Http/1.0 sendet Anfragen, die nicht zulässig sind, wie z. B. Löschanfragen
3: GET/Http/3.0 sendet eine illegale Version der HTTP-Protokollanfrage
4: GET/JUNK/1.0 sendet eine falsche Eine Spezifikation der HTTP-Protokollanforderung
Http-Fingerabdruck-Identifizierungstool Httprint, das mithilfe statistischer Prinzipien und der Kombination von Fuzzy-Logic-Technologie den Typ von HTTP-Servern effektiv bestimmen kann. Es kann zum Sammeln und Analysieren der von verschiedenen generierten HTTP-Servertypen verwendet werden HTTP-Server-Signatur.
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.
Das obige ist der detaillierte Inhalt vonEinführung in HTTP: http ist ein objektorientiertes Protokoll, das zur Anwendungsschicht gehört. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
