Detaillierte Erläuterung des HTTP-Protokolls

引言                                       

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。

HTTP协议的主要特点可概括如下：

1.支持客户/服务器模式。

2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

一、HTTP协议详解之URL篇

http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：

http://host[":"port][abs_path]

http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

eg:

1、输入：www.guet.edu.cn

浏览器自动转换成：http://www.guet.edu.cn/

2、http:192.168.0.116:8080/index.jsp 

二、HTTP协议详解之请求篇

http请求由三部分组成，分别是：请求行、消息报头、请求正文

1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF 

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET     请求获取Request-URI所标识的资源

POST    在Request-URI所标识的资源后附加新的数据

HEAD    请求获取由Request-URI所标识的资源的响应消息报头

PUT     请求服务器存储一个资源，并用Request-URI作为其标识

DELETE  请求服务器删除Request-URI所标识的资源

TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断

CONNECT 保留将来使用

OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

应用举例：

GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET /form.html HTTP/1.1 (CRLF)

POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。

eg：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)         //该CRLF表示消息报头已经结束，在此之前为消息报头

user=jeffrey&pwd=1234  //此行以下为提交的数据

Die HEAD-Methode ist fast die gleiche wie die GET-Methode. Für den Antwortteil der HEAD-Anfrage sind die in ihrem HTTP-Header enthaltenen Informationen dieselben wie die durch 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

3. Anforderungstext (weggelassen)

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:

Unter anderem stellt HTTP-Version die Version des Server-HTTP-Protokolls dar; 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:

2xx: Erfolgreich – zeigt an, dass die Anfrage erfolgreich empfangen, verstanden und akzeptiert wurde

3xx: Weiterleiten – weitere Vorgänge müssen durchgeführt werden, um die Anfrage abzuschließen

4xx: Client-Fehler – die Anfrage weist einen Syntaxfehler auf oder die Anfrage kann nicht erfüllt werden

5xx: Serverseitiger Fehler – der Server konnte die rechtliche Anfrage nicht erfüllen

Allgemeine Statuscodes, Statusbeschreibung und Erklärung:

400 Bad Request //Die Client-Anfrage weist einen Syntaxfehler auf und kann nicht erfolgreich sein vom Server verstanden

401 Unauthorized //Die Anfrage ist nicht autorisiert, dieser Statuscode muss zusammen mit dem WWW-Authenticate-Bericht //Header-Feld verwendet werden

403 Forbidden //Der Server hat die empfangen Anfrage, verweigerte aber die Bereitstellung des Dienstes

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 kann den Kunden derzeit nicht verarbeiten. Nach einer gewissen Zeit kann // zum Normalzustand zurückkehren

z. B.: HTTP/1.1 200 OK (CRLF)

2. Antwort-Header-Beschreibung

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

HTTP-Nachricht vom Client zum Server besteht aus einer Anfrage 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) 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 übertragene Entität, sondern nur für die übertragene Nachricht .

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 (a Die Caching-Anweisung einer Nachricht hat keinen Einfluss auf den Caching-Mechanismus einer anderen Nachrichtenverarbeitung.) 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 ;

Cache-Anweisungen beim Antworten umfassen: öffentlich, privat, kein Cache, kein Speichern, keine Transformation, erneute Validierung erforderlich, erneute Proxy-Überprüfung, maximales Alter, maximales Alter.

zB: Um den IE-Browser (Client) anzuweisen, die Seite nicht zwischenzuspeichern, kann das serverseitige JSP-Programm 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 den gemeinsamen Header fest Feld in der gesendeten Antwortnachricht: Cache-Control :no-cache

Das gemeinsame Headerfeld „Datum“ gibt das Datum und die Uhrzeit an, zu der die Nachricht generiert wurde.

Das gemeinsame Headerfeld „Verbindung“ ermöglicht Optionen zum Senden einer angegebenen Nachricht 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 dies Der Client soll die Anfrage an den Server weiterleiten. Zusätzliche Informationen sowie Informationen über den Client selbst.

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 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 verwendet, um den Internet-Host und die Portnummer der angeforderten Ressource anzugeben, die normalerweise aus extrahiert wird Es erscheint eine HTTP-URL, z. B.:

Wir geben in den Browser ein: http://www.guet.edu.cn/index.html

Die vom Browser gesendete Anforderungsnachricht enthält Host Anforderungs-Header-Feld 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 der Name Ihres Betriebssystems aufgeführt ist. und Version, der Name und die Version des von Ihnen verwendeten Browsers, was bei vielen Menschen oft ein Erstaunen hervorruft. 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 Informationen über den weiteren Zugriff auf die durch den Request-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 das

Server-Antwort-Header-Feld:

Server: Apache-Coyote/1.1

WWW-Authenticate

WWW-Authenticate-Antwort Header-Feld Muss in der 401-Antwortnachricht (nicht autorisiert) enthalten sein. 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 für angeforderte 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 Medientypmodifikator verwendet und sein Wert gibt an, dass es angewendet wurde die Entität Die Codierung zusätzlicher Inhalte im Textkörper, sodass zum Erhalten des im Content-Type-Headerfeld referenzierten Medientyps ein entsprechender Decodierungsmechanismus verwendet werden muss. Content-Encoding wird verwendet, um die Komprimierungsmethode des Dokuments aufzuzeichnen, z. B.: Content-Encoding: gzip

Content-Language

Das Content-Language-Entitätsheaderfeld beschreibt die natürliche Sprache, die von verwendet wird Ressource. 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 Content-Length-Entitätsheaderfeld wird verwendet, um die Länge des Entitätskörpers anzugeben, ausgedrückt als Dezimalzahl, die in Bytes gespeichert ist.

Content-Type

Das Content-Type-Entitätsheaderfeld gibt den Medientyp des an den Empfänger gesendeten Entitätstexts an. zB:

Inhaltstyp: text/html; charset=ISO-8859-1

Inhaltstyp: text/html; charset=GB2312

Zuletzt geändert

Das Entitätsheaderfeld „Zuletzt geändert“ wird verwendet, um das Datum und die Uhrzeit der letzten Änderung der Ressource anzugeben.

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

Der Zweck und das Prinzip des Experiments:

Verwenden Sie das MS-Telnet-Tool, um die HTTP-Anfrageinformationen manuell einzugeben und eine Anfrage an den Server zu senden. Nachdem der Server die Anfrage empfangen, interpretiert und akzeptiert, gibt er eine Antwort zurück, die auf dem Telnet angezeigt wird Fenster und vertiefen so Ihr Verständnis des Kommunikationsprozesses des http-Protokolls.

Experimentelle Schritte:

1. Telnet öffnen

1.1 Telnet öffnen

Ausführen-->cmd-->telnet

1.2 Aktivieren Sie die Telnet-Echo-Funktion

Setzen Sie Localecho ein

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

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

HEAD /index.asp HTTP/1.0

Host:www.guet.edu.cn

/* Wir können die Anforderungsmethode ändern. Um den Inhalt der Guilin Electronics-Homepage anzufordern, geben Sie die Nachricht wie folgt ein*/

öffnen Sie www.guet.edu.cn 80

GET /index.asp HTTP/1.0 //Ressourcen anfordern Inhalt

Host:www.guet.edu.cn

2.2 open www.sina.com.cn 80 //Eingabe Telnet www. sina.com.cn direkt an der Eingabeaufforderung 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                                                                                                                                                                                                                                                   ' ' it    ' ‐ ‐ ‐ ​ ​ ​ ​ ​ ​ ​ ​​ ​: Do, 08. März 200707:17:51 GMT

Verbindung: Keep-Alive