Das TCP-Protokoll entspricht der Transportschicht, während das HTTP-Protokoll der Anwendungsschicht entspricht. Im Wesentlichen sind die beiden nicht vergleichbar. Das HTTP-Protokoll basiert auf dem TCP-Protokoll. Wenn der Browser Webseitendaten vom Server abrufen muss, sendet er eine HTTP-Anfrage. Http stellt über TCP einen Verbindungskanal zum Server her. Wenn die für diese Anforderung erforderlichen Daten abgeschlossen sind, trennt Http die TCP-Verbindung sofort. Daher ist die HTTP-Verbindung eine kurze Verbindung und eine zustandslose Verbindung. Das sogenannte Stateless bedeutet, dass der Browser jedes Mal, wenn er eine Anfrage an den Server initiiert, keine Verbindung herstellt, sondern jedes Mal eine neue Verbindung aufbaut. Wenn es sich um eine Verbindung handelt, kann der Serverprozess die Verbindung aufrechterhalten und sich einige Statusinformationen im Speicher merken. Nach Beendigung jeder Anfrage wird die Verbindung geschlossen und der relevante Inhalt freigegeben, sodass kein Status gespeichert wird und die Verbindung zu einer zustandslosen Verbindung wird.
Mit der Zeit wird die HTML-Seite komplexer und es können viele Bilder darin eingebettet sein. Zu diesem Zeitpunkt ist es ineffizient, bei jedem Zugriff auf das Bild eine TCP-Verbindung herzustellen. Daher wurde Keep-Alive vorgeschlagen, um das Problem der geringen Effizienz zu lösen. Ab HTTP/1.1 ist Keep-Alive standardmäßig aktiviert, um die Verbindungsfunktion beizubehalten. Wenn eine Webseite geöffnet wird, wird die TCP-Verbindung, die zum Übertragen von HTTP-Daten zwischen dem Client und dem Server verwendet wird, nicht geschlossen Wenn Sie die Webseite auf diesem Server erneut besuchen, verwenden Sie diese hergestellte Verbindung nicht dauerhaft. Sie verfügt über eine Aufbewahrungszeit, die in anderer Serversoftware (z. B. Apache) eingestellt werden kann. Obwohl die TCP-Verbindung hier für einen bestimmten Zeitraum aufrechterhalten wird, ist diese Zeit begrenzt und wird zu diesem Zeitpunkt dennoch geschlossen. Daher betrachten wir sie auch als Schließen nach Abschluss jeder Verbindung. Später, durch Session,
Cookies und andere verwandte Technologien können auch den Status einiger Benutzer aufrechterhalten. Es wird jedoch immer noch jedes Mal eine Verbindung verwendet und es handelt sich immer noch um eine zustandslose Verbindung.
Früher gab es ein Konzept, bei dem ich es nicht ertragen konnte, verwirrt zu werden. Deshalb ist HTTP eine zustandslose kurze Verbindung, während TCP eine zustandsbehaftete lange Verbindung ist? Basiert HTTP nicht auf TCP? Warum kann es trotzdem eine kurze Verbindung sein? Jetzt verstehe ich, dass HTTP die TCP-Verbindung schließt, nachdem jede Anforderung abgeschlossen ist, sodass es sich um eine kurze Verbindung handelt. Wenn wir das TCP-Protokoll direkt über die Socket-Programmierung verwenden, können wir über den Codebereich steuern, wann die Verbindung geöffnet und geschlossen werden soll. Solange wir die Verbindung nicht über den Code schließen, befindet sich die Verbindung im Prozess des Clients und Es existiert immer und die relevanten Statusdaten werden immer gespeichert.
Es gibt einen Socket in C#. Tatsächlich ist der Socket eine Kapselung des TCP/IP-Protokolls. Der Socket selbst ist kein Protokoll, sondern eine aufrufende Schnittstelle (API). Das Aufkommen von Socket erleichtert Programmierern nur die Verwendung des TCP/IP-Protokollstapels. Es handelt sich um eine Abstraktion des TCP/IP-Protokolls und bildet somit einige der grundlegendsten Funktionsschnittstellen, die wir kennen, wie z. B. Erstellen, Abhören, Verbinden usw. akzeptieren und senden, lesen und schreiben usw.
Eine anschaulichere Beschreibung: HTTP ist ein Auto, das eine bestimmte Form der Kapselung oder Anzeige von Daten bietet; Socket ist eine Engine, die die Möglichkeit zur Netzwerkkommunikation bietet. Aus Sicht der C#-Programmierung können Sie der Einfachheit halber direkt das bereits hergestellte HTTP für die Interaktion mit dem Server auswählen. Manchmal muss jedoch aufgrund von Umgebungsfaktoren oder anderen benutzerdefinierten Anforderungen das TCP-Protokoll verwendet werden. In diesem Fall müssen Sie die Socket-Programmierung verwenden und die erhaltenen Daten dann selbst verarbeiten. Es ist, als hätten Sie einen LKW mit einem vorhandenen Motor gebaut und mit dem Server interagiert.
HTTP/1.0 und HTTP/1.1 verwenden beide TCP als zugrunde liegendes Transportprotokoll. Der HTTP-Client initiiert zunächst den Aufbau einer TCP-Verbindung mit dem Server. Sobald die Verbindung hergestellt ist, können der Browserprozess und der Serverprozess über ihre jeweiligen Sockets auf TCP zugreifen. Wie bereits erwähnt, ist der Client-Socket die „Tür“ zwischen dem Client-Prozess und der TCP-Verbindung, und der serverseitige Socket ist die „Tür“ zwischen dem Server-Prozess und derselben TCP-Verbindung. Der Client sendet HTTP-Anfragenachrichten an seinen eigenen Socket und empfängt HTTP-Antwortnachrichten von seinem eigenen Socket. Ebenso empfängt der Server HTTP-Anforderungsnachrichten von seinem eigenen Socket und sendet HTTP-Antwortnachrichten an seinen eigenen Socket. Sobald der Client oder Server eine Nachricht an ihre jeweiligen Sockets sendet, unterliegt die Nachricht vollständig der Kontrolle von TCP. TCP bietet einen zuverlässigen Datenübertragungsdienst für HTTP; das bedeutet, dass jede vom Client gesendete HTTP-Anforderungsnachricht letztendlich verlustfrei den Server erreicht und jede vom Server gesendete HTTP-Antwortnachricht letztendlich verlustfrei den Client erreicht.
Der C#-Code verwendet das TCP-Protokoll, um eine Verbindung zur Remote-Datenbank herzustellen. Jedes Mal, wenn eine neue Verbindung erstellt wird, öffnet Connection.open die TCP-Verbindung. Die Verbindung wird geschlossen, wenn „connection.Close“ aufgerufen wird. Die unterste Schicht von FTP ist ebenfalls TCP, es handelt sich jedoch um eine langfristige Verbindung. Die Übertragung großer Dateien geht schneller. Das hängt vom konkreten Szenario ab. Wenn das Programm auf der Serverseite eine lange Verbindungsmethode verwendet, kann es die Anzahl der gleichzeitigen Verbindungen zum Server steuern, um mehrere Verbindungen gleichzeitig zu verhindern. Wenn Sie jedoch die Kurzverbindungsmethode verwenden, können Sie die Anzahl der gleichzeitig mit dem Server verbundenen Verbindungen nicht steuern. Dies ist ebenfalls ein Vorteil und kann eine große Anzahl von Verbindungsanforderungen gleichzeitig verarbeiten. Wenn jedoch die Anzahl der Verbindungsanfragen zu groß ist, funktioniert der Server möglicherweise nicht mehr.
WebService erfordert keine Verbindung. Es kann mindestens Zehntausende/Hunderttausend Anfragen in einer Sekunde unterstützen. Jede Anfrage wird dann freigegeben, und es gibt keinen freien Speicherverbrauch. Generell gibt es keine Begrenzung der Anzahl gleichzeitiger Verbindungen, was ein Vorteil ist. Message Queue muss eine Verbindung herstellen, und es ist sehr schwierig, Tausende von Verbindungen zu unterstützen. Denn jede Verbindung belegt einen bestimmten Speicherplatz, auch wenn sie keine Daten anfordert. Es wird Einschränkungen geben, wie zum Beispiel beim SQL Server-Datenbankserver, der in der Regel maximal 16 gleichzeitige Verbindungen hat.
Das HTTP-Protokoll muss den angegebenen Port 80 passieren, damit dieser Port nicht auf allgemeine Computer beschränkt ist und das HTTP-Protokoll die Firewalls auf allen Computern erfolgreich passieren kann. Wenn Sie die Socket-Programmierung verwenden, müssen Sie selbst einen bestimmten Port angeben. Dann ist es sehr wahrscheinlich, dass dieser Port in einer bestimmten Umgebung deaktiviert ist, sodass er die Firewall nicht durchdringen kann. IIS verwendet Port 80, was bedeutet, dass dieses Programm diesen Port überwacht hat. Sobald festgestellt wird, dass jemand eine Verbindung zu diesem Port aufbauen möchte, antwortet er und stellt dann die Verbindung her. Bei den hier genannten Verbindungen handelt es sich allesamt um Kurzverbindungen. Ihre Anfragen nach URLs auf dem Server werden also über Port 80 an das Website-Programm gesendet. Der Client-Browser sendet es dann über diesen Port.
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. Die sechste Version von HTTP/1.0 wird derzeit im WWW verwendet. Die Standardisierungsarbeiten von HTTP/1.1 sind im Gange und HTTP-NG (Next
Es wurden Vorschläge zur Generierung von HTTP 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 Erklärung des HTTP-Protokolls - URL
http ( Super Text Transfer Protocol) ist ein zustandsloses Protokoll auf Anwendungsebene, das auf dem Anforderungs- und Antwortmodell basiert. Die HTTP 1.1-Version bietet für die meisten Webanwendungen einen kontinuierlichen Verbindungsmechanismus basiert auf dem HTTP-Protokoll.
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 legaler Internet-Host-Domänenname oder eine IP-Adresse eine Portnummer angibt. Wenn diese leer ist, wird der Standardport 80 verwendet ; abs_path gibt den URI der angeforderten Ressource an; wenn er als Anforderungs-URI verwendet wird, muss er normalerweise in der Form „/“ angegeben werden uns.
zB:
1. Eingabe: www.guet.edu.cn
Der Browser konvertiert automatisch zu: http://www.guet.edu. cn/
2. http:192.168.0.116:8080/index.jsp
2. Detaillierte Erläuterung des HTTP-Protokolls – Anfrage
HTTP-Anfrage besteht aus drei Teilen, nämlich: Anfragezeile, Nachrichtenkopf, Anfragetext
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
wobei Methode die Anforderungsmethode darstellt -URI ist ein Uniform Resource Identifier; 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 werden in Großbuchstaben geschrieben). Die Erläuterungen zu jeder Methode lauten wie folgt:
GET-Anfrage zum Abrufen der durch Request-URI identifizierten Ressource
POST In Request – Neue Daten nach der durch URI identifizierten Ressource anhängen
HEAD Anfrage zum Abrufen des Antwortnachrichtenheaders der durch Request-URI identifizierten Ressource
PUT Fordern Sie den Server auf, eine Ressource zu speichern und Request-URI zu verwenden als seine Kennung
DELETE Fordern Sie den Server auf, die durch Request-URI identifizierte Ressource zu löschen
TRACE Fordern Sie 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 Abfrage und Ressourcen Verwandte Optionen und Anforderungen
Anwendungsbeispiele:
GET-Methode: Beim Zugriff auf eine Webseite durch Eingabe der URL in die Adressleiste des Browsers verwendet der Browser das GET Methode zum Abrufen von Ressourcen vom 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 Absenden 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 Nachrichtenkopf zu Ende ist, und davor war es der Nachrichtenkopf
user=jeffrey&pwd=1234 //Die folgende Zeile enthält die übermittelten Daten
HEAD-Methode und Die GET-Methoden sind nahezu identisch. Ebenso sind für den Antwortteil der HEAD-Anfrage die im HTTP-Header enthaltenen Informationen dieselben wie die über die GET-Anfrage erhaltenen Informationen. 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
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. Nachrichtenkopf mit detaillierter Erläuterung des HTTP-Protokolls
HTTP-Nachricht Sie besteht 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 Anfrage- und Antwortnachrichten verwendet werden, aber nicht für die übertragene Entität verwendet werden und nur zur Übermittlung von Nachrichten verwendet.
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
Das allgemeine Headerfeld „Datum“ gibt das Datum und die Uhrzeit an, zu der die Nachricht generiert wurde.
Das allgemeine Headerfeld „Verbindung“ ermöglicht Sendeoptionen zum Angeben einer 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 den Host-Anforderungsheader Domain, wie folgt:
Host: www.guet.edu.cn
Hier wird die Standard-Portnummer 80 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 Ihre Vorgänge aufgeführt sind. Der Name und Die Version des Systems sowie der Name und die Version des von Ihnen verwendeten Browsers sind für viele Menschen erstaunlich. Tatsächlich 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 Antworten auf die Anfrage – Informationen für den weiteren Zugriff auf die durch den URI identifizierte Ressource.
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 von der Ressource verwendete natürliche Sprache. 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, 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 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 die HTTP-Anfrage manuell einzugeben. In Form von Informationen wird eine Anfrage an den Server gesendet. Nachdem der Server die Anfrage empfangen, interpretiert und akzeptiert, gibt er eine Antwort zurück, die auf dem Telnet angezeigt wird Fenster, wodurch das Verständnis des Kommunikationsprozesses des http-Protokolls wahrnehmungsmäßig vertieft wird.
1. Öffnen Sie Telnet
1.1 Öffnen Sie Telnet und führen Sie-->cmd--> aus ; Telnet
Localecho einstellen
www.guet.edu.cn
80 //Beachten Sie, dass die Portnummer nicht weggelassen werden darf HEAD /index.asp HTTP/ 1.0
/*Wir können die Anforderungsmethode ändern und den Inhalt der Guilin Electronics-Homepage anfordern. Geben Sie die Nachricht wie folgt ein*/
öffnen
www.guet.edu.cn
80 GET /index.asp HTTP/1.0 //Der Inhalt der angeforderten Ressource Host:www.guet.edu.cn
2.2 öffnen
80 //Geben Sie Telnet direkt an der Eingabeaufforderung ein www.sina.com. cn 80 HEAD /index.asp HTTP/1.0 Host:www.sina.com.cn
3 Experimentelle Ergebnisse:
3.1 Erhalten aus den Anfrageinformationen 2.1 Die Antwort lautet:
HTTP/1.1 200 OK // Webserver
Datum: Do, 08. März 20 0707:17:51 GMT
Verbindung: Keep - Alive B=BEJCDGKADEDJKLKKAJEOIMMH path=/
Cache- Kontrolle: privat
//Ressourceninhalt weggelassen
3.2 Die durch die Anforderung von Informationen 2.2 erhaltene Antwort lautet:
HTTP/1.0 404 nicht gefunden //Anfrage fehlgeschlagenDatum: Do, 08. März 2007 07:50:50 GMTServer: Apache/2.0.54
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 von zjm152-78.sina.com.cn
Via: 1.0 zjm152-78. cn:80
X-Cache: MISS von th-143.sina.com.cn
Verbindung: geschlossen
Verbindung verloren mit dem Host
Drücken Sie eine beliebige Taste, um fortzufahren...
4. Ein Eingabefehler ist aufgetreten gelingen. 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.
HTTP-Protokoll zugehörige technische Ergänzungen
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.
Dort Es gibt drei Arten 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 festgelegt wird, z. B. ContentLenth:999999999. Der Speicher wird nicht freigegeben, bevor die Übertragung abgeschlossen ist. Ein Angreifer kann diesen Fehler ausnutzen, um kontinuierlich Junk zu versenden 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 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 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.
Das obige ist der detaillierte Inhalt vonWas ist der Unterschied zwischen dem HTTP-Protokoll und dem TCP-Protokoll?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
