引言
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)
3. Antwortkapitel mit detaillierter Erklärung des HTTP-ProtokollsNach 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 CRLFUnter 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:
1xx: Anzeigeinformationen – zeigt an, dass die Anfrage eingegangen ist , Verarbeitung fortsetzen200 OK //Die Client-Anfrage war erfolgreich2xx: 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
4. Detaillierte Erläuterung des HTTP-Protokolls: Nachrichtenkopf
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
Ablaufdatum: Do, 08. März 2007 07:16:51 GMTSet-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/Cache-Kontrolle: privat/ /Ressourceninhalt weggelassen3.2 Die durch die Anforderung von Informationen 2.2 erhaltene Antwort lautet:HTTP/1.0 404 nicht gefunden //Die Anfrage ist fehlgeschlagenDatum: Do, 08. März 2007 07: 50:50 GMTServer: Apache/2.0.546. 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 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.
Gateways fungieren oft als serverseitige Portale durch Firewalls hindurch. Gateways können 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 Analyse und Verarbeitung von High-Level-Protokollen auf modulare Weise 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-Protokolls führt zu Denial-of-Service-Angriffen
Bei Verwendung der POST-Methode können Sie ContentLenth festlegen, um die Länge der zu übertragenden Daten zu definieren, z. B. ContentLenth:999999999. Der Speicher wird erst freigegeben, wenn die Übertragung abgeschlossen ist Dieser Fehler führt dazu, dass kontinuierlich Mülldaten an den Webserver gesendet werden, bis der Speicher des Webservers erschöpft ist. 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
Server Der Client ist mit der Verarbeitung der vom Angreifer gefälschten TCP-Verbindungsanforderung beschäftigt und hat keine Zeit, sich um die normale Anforderung des Clients zu kümmern (schließlich ist die normale Anforderungsquote des Clients aus dieser Sicht sehr gering). Beim normalen Client verliert der Server die Antwort: Die Serverseite 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 Verbindungsanfrage (Connect) an N Chargens. Nachdem Chargen die Verbindung erhalten hat, gibt er einen 72-Byte-Zeichenstrom pro Sekunde zurück (tatsächlich). an die tatsächlichen Netzwerkbedingungen anpassen, dies schneller) an den Server.
5. Http-Fingerprinting-Technologie
Das Prinzip des Http-Fingerprintings ist grundsätzlich dasselbe: Die Aufzeichnung der geringfügigen Unterschiede in der Ausführung des Http-Protokolls durch verschiedene Server zur Identifizierung ist besser als bei TCP 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 Der TCP/IP-Stack erfordert eine Änderung der Kernschicht, sodass er leicht zu identifizieren ist. Es ist sehr einfach, den Server so einzurichten, dass er verschiedene Banner-Informationen zurückgibt. Benutzer können die Banner-Informationen im Quellcode ändern, und dann wird ein Neustart des HTTP-Dienstes wirksam. Für HTTP-Server, die keinen offenen Quellcode haben, wie z. B. IIS oder Netscape von Microsoft, können Sie sie in der DLL-Datei ändern, in der Banner gespeichert ist In verwandten Artikeln wird dies besprochen, daher werde ich hier nicht näher darauf eingehen. Eine andere Möglichkeit, Banner-Informationen zu verwenden, ist jedoch vorhanden.
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 Anfrage löschen
3: GET/Http/3.0 sendet eine illegale Version der HTTP-Protokollanfrage
4: GET/JUNK/1.0 sendet eine falsche Spezifikation der HTTP-Protokollanfrage
Http-Fingerabdruck-Identifikationstool Httprint, das mithilfe statistischer Prinzipien und der Kombination von Fuzzy-Logik-Technologie den Typ des HTTP-Servers effektiv bestimmen kann. Es 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
Effizientere Verbindung bereitzustellen .
Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des HTTP-Protokolls. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
