Introduction au HTTP, http est un protocole orienté objet appartenant à la couche application

Merci d'indiquer la source de réimpression : Introduction au HTTP, http est un protocole orienté objet appartenant à la couche application

Introduction

HTTP est un protocole orienté objet appartenant à la couche application. De par sa méthode simple et rapide, HTTP convient aux systèmes d'information hypermédia distribués. Il a été proposé en 1990 et a été continuellement amélioré et étendu après plusieurs années d'utilisation et de développement. Actuellement utilisée sur le WWW, la sixième version de HTTP/1.0 est en cours et les suggestions HTTP-NG (nouvelle génération de HTTP). ont été faites.
Les principales fonctionnalités du protocole HTTP peuvent être résumées comme suit :
1. Prise en charge du mode client/serveur.
2. Simple et rapide : Lorsqu'un client demande un service au serveur, il lui suffit de transmettre la méthode et le chemin de la requête. Les méthodes de requête couramment utilisées sont GET, HEAD et POST. Chaque méthode spécifie un type différent de contact entre le client et le serveur. En raison de la simplicité du protocole HTTP, la taille du programme du serveur HTTP est petite et la vitesse de communication est très rapide.
3. Flexible : HTTP permet la transmission de tout type d’objet de données. Le type en cours de transfert est marqué par Content-Type.
4. Aucune connexion : Le sens de l'absence de connexion est de limiter chaque connexion à une seule demande. Une fois que le serveur a traité la demande du client et reçu la réponse du client, il se déconnecte. Cette méthode permet de gagner du temps de transmission.
5. Sans état : Le protocole HTTP est un protocole sans état. Sans état signifie que le protocole n'a aucune capacité de mémoire pour le traitement des transactions. L'absence de statut signifie que si un traitement ultérieur nécessite les informations précédentes, celles-ci doivent être retransmises, ce qui peut entraîner une augmentation de la quantité de données transférées par connexion. En revanche, le serveur répond plus rapidement lorsqu’il n’a pas besoin d’informations préalables.

1. Explication détaillée du protocole HTTP - URL

HTTP (Hypertext Transfer Protocol) est un protocole de couche application sans état basé sur le mode requête et réponse. Il est souvent basé sur la méthode de connexion TCP et fournit un mécanisme de connexion continue, ce qui est absolument le cas. applications construites sur le protocole HTTP.

L'URL HTTP (l'URL est un type spécial d'URI qui contient suffisamment d'informations pour trouver une ressource) a le format suivant :
http://www.php.cn /[":" port][abs_path]
http signifie localiser les ressources réseau via le protocole HTTP ; hôte signifie un nom de domaine d'hôte Internet légal ou une adresse IP ; port spécifie un numéro de port, s'il est vide, utilisez la valeur par défaut. le port 80 ; abs_path spécifie l'URI de la ressource demandée ; si abs_path n'est pas indiqué dans l'URL, alors lorsqu'il est utilisé comme URI de requête, il doit être indiqué sous la forme de "/". pour nous.
par exemple :
1. Saisie : www.guet.edu.cn
Le navigateur se convertit automatiquement en : http:// www.php.cn/
2. http:192.168.0.116:8080/index.jsp

2. Demande d'explication détaillée du protocole HTTP

La requête http se compose de trois parties, à savoir : la ligne de requête, l'en-tête du message, le corps de la requête

1. La ligne de requête commence par un symbole de méthode, séparé par des espaces, suivi de l'URI demandé et de la version du protocole : Method Request-URI HTTP-Version CRLF
Method représente la méthode de requête ; Request-URI Il s'agit d'un identifiant de ressource uniforme ; HTTP-Version indique la version du protocole HTTP demandée ; CRLF indique le retour chariot et le saut de ligne (à l'exception du CRLF à la fin, aucun caractère CR ou LF séparé n'est autorisé).

Il existe de nombreuses méthodes de requête (toutes les méthodes sont en majuscules). Les explications de chaque méthode sont les suivantes :
GET Requête pour obtenir la ressource identifiée par Request-URI
POST Ajouter une nouvelle ressource après le ressource identifiée par Request-URI Les données
HEAD Demande d'obtenir l'en-tête du message de réponse de la ressource identifiée par Request-URI
PUT Demande au serveur de stocker une ressource et utilise Request-URI comme identifiant
DELETE Demande au serveur de supprimer la ressource identifiée par Request-URI Resource
TRACE Demande au serveur de renvoyer les informations de requête reçues, principalement utilisées pour les tests ou le diagnostic
CONNECT Réservé pour une utilisation future
OPTIONS demande d'interroger le performances du serveur, ou options de requête et exigences liées à la ressource
application Exemple :
Méthode GET : Lors de l'accès à une page Web en saisissant l'URL dans la barre d'adresse du navigateur, le navigateur utilise la méthode GET pour obtenir des ressources de le serveur, par exemple : GET /form.html HTTP/1.1 (CRLF)

La méthode POST nécessite que le serveur demandé accepte les données jointes à la demande et est souvent utilisée pour soumettre des formulaires.
par exemple：POST /reg.jsp HTTP/ (CRLF)
Accepter:image/gif,image/x-xbit,... (CRLF)
...
HÔTE:www.guet .edu.cn (CRLF)
Content-Length:22 (CRLF)
Connexion:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) // Ce CRLF indique que l'en-tête du message est terminé. Avant cela, c'était l'en-tête du message
user=jeffrey&pwd=1234 //La ligne suivante correspond aux données soumises

. La méthode HEAD est quasiment la même que la méthode GET. Pour la partie réponse de la requête HEAD, les informations contenues dans son en-tête HTTP sont les mêmes que celles obtenues via la requête GET. Grâce à cette méthode, des informations sur la ressource identifiée par le Request-URI peuvent être obtenues sans transmettre l'intégralité du contenu de la ressource. Cette méthode est souvent utilisée pour tester la validité d'un lien hypertexte, s'il est accessible et s'il a été mis à jour récemment.
2. Description de l'en-tête de la demande
3. Corps de la demande (omis)

3. Chapitre de réponse Explication détaillée du protocole HTTP

Après avoir reçu et interprété le message de requête, le serveur renvoie un message de réponse HTTP.

La réponse HTTP se compose également de trois parties, à savoir : la ligne d'état, l'en-tête du message, le corps de la réponse
1 Le format de la ligne d'état est le suivant :
HTTP-Version Status-Code Reason-Phrase CRLF
. où , HTTP-Version représente la version du protocole HTTP du serveur ; Status-Code représente le code d'état de réponse renvoyé par le serveur ; Reason-Phrase représente la description textuelle du code d'état.
Le code d'état est composé de trois chiffres. Le premier chiffre définit la catégorie de la réponse et a cinq valeurs possibles :
1xx : Informations d'indication - indique que la demande a été reçue et continue d'être traitée
2xx : Succès --Indique que la demande a été reçue, comprise et acceptée avec succès
3xx : Redirection - Des opérations supplémentaires doivent être effectuées pour terminer la demande
4xx : Erreur client --La demande contient une erreur de syntaxe ou la demande ne peut pas être satisfaite
5xx : Erreur côté serveur - le serveur n'a pas réussi à mettre en œuvre une demande légale
Codes d'état courants, descriptions d'état, instructions :
200 OK //Demande du client réussie
400 Bad Request //La demande du client est valide Erreur de syntaxe, ne peut pas être comprise par le serveur
401 Non autorisé //La demande n'est pas autorisée, ce code d'état doit être utilisé avec le champ d'en-tête WWW-Authenticate
403 Interdit //Le serveur a reçu la demande, mais a refusé de fournir le service
404 Not Found //La ressource demandée n'existe pas, par exemple : une mauvaise URL a été saisie
500 Internal Server Error //Une erreur inattendue s'est produite dans le serveur
503 Serveur indisponible //Le serveur est actuellement incapable de traiter la demande du client, un paragraphe Il peut revenir à la normale après un certain temps
ex : HTTP/1.1 200 OK (CRLF)

2. L'en-tête de réponse est décrit plus loin

3. Le corps de la réponse est le contenu de la ressource renvoyé par le serveur

4. Explication détaillée du protocole HTTP : en-tête du message

Les messages HTTP sont constitués de requêtes client à serveur et de réponses serveur à client. Les messages de demande et les messages de réponse se composent d'une ligne de début (pour un message de demande, la ligne de début est la ligne de demande, pour un message de réponse, la ligne de début est la ligne d'état), d'un en-tête de message (facultatif), d'une ligne vide (uniquement CRLF ligne), composition du corps du message (facultatif).

Les en-têtes de message HTTP incluent les en-têtes ordinaires, les en-têtes de requête, les en-têtes de réponse et les en-têtes d'entité.
Chaque champ d'en-tête est composé d'une valeur d'espace name ":" Le nom du champ d'en-tête du message est indépendant de la casse.

1. En-têtes ordinaires
Dans les en-têtes ordinaires, il existe quelques champs d'en-tête qui sont utilisés pour tous les messages de demande et de réponse, mais ne sont pas utilisés pour les entités transmises, uniquement pour les messages transmis.
par exemple :
Cache-Control est utilisé pour spécifier les instructions de cache. Les instructions de cache sont unidirectionnelles (les instructions de cache qui apparaissent dans la réponse peuvent ne pas apparaître dans la requête) et sont indépendantes (les instructions de cache d'un le message ne sera pas un mécanisme de mise en cache qui affecte un autre traitement de message), un champ d'en-tête similaire utilisé par HTTP 1.0 est Pragma.
Les directives de cache lors de la demande incluent : no-cache (utilisé pour indiquer que les messages de demande ou de réponse ne peuvent pas être mis en cache), no-store, max-age, max-stale, min-fresh, only-if-cached ;
Les directives de mise en cache en réponse incluent : public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage
par exemple : afin d'instruire IE. navigateur (Client) Ne pas mettre en cache la page. Le programme JSP côté serveur peut être écrit comme suit : réponse.sehHeader("Cache-Control","no-cache");
//response.setHeader("Pragma ","pas de cache" ;
Le champ d'en-tête commun Date indique la date et l'heure auxquelles le message a été généré

Le champ d'en-tête commun Connexion permet d'envoyer des options spécifiques à la connexion. Par exemple, précisez que la connexion est continue, ou spécifiez l'option "fermer" pour demander au serveur de fermer la connexion une fois la réponse terminée

2. En-tête de requête
L'en-tête de requête permet au client de transmettre des informations supplémentaires sur la requête et les propres informations du client au serveur.
En-têtes de requête couramment utilisés
Accepter
Le champ d'en-tête de requête Accepter est utilisé pour spécifier les types d'informations que le client accepte. Ex : Accepter : image/gif, indiquant que le client souhaite accepter les ressources au format image GIF ; Accepter : text/html, indiquant que le client souhaite accepter le texte html.
Accept-Charset
Le champ d'en-tête de requête Accept-Charset est utilisé pour spécifier le jeu de caractères accepté par le client. Par exemple : Accept-Charset:iso-8859-1, gb2312 Si ce champ n'est pas défini dans le message de demande, la valeur par défaut est que tout jeu de caractères est acceptable.
Accept-Encoding
Le champ d'en-tête de requête Accept-Encoding est similaire à Accept, mais il est utilisé pour spécifier un codage de contenu acceptable. Par exemple : Accept-Encoding:gzip.deflate Si ce domaine n'est pas défini dans le message de requête, le serveur suppose que le client peut accepter différents encodages de contenu.
Accept-Language
Le champ d'en-tête de requête Accept-Language est similaire à Accept, mais il est utilisé pour spécifier une langue naturelle. Par exemple : Accept-Language:zh-cn Si ce champ d'en-tête n'est pas défini dans le message de demande, le serveur suppose que le client peut accepter différentes langues.
Autorisation
Le champ d'en-tête de demande d'autorisation est principalement utilisé pour prouver que le client a le droit de visualiser une certaine ressource. Lorsque le navigateur accède à une page et reçoit un code de réponse 401 (Non autorisé) du serveur, il peut envoyer une requête contenant le champ d'en-tête de demande d'autorisation pour demander au serveur de le vérifier.
Hôte (ce champ d'en-tête est obligatoire lors de l'envoi d'une requête)
Le champ d'en-tête de requête d'hôte est principalement utilisé pour spécifier l'hôte Internet et le numéro de port de la ressource demandée. Il est généralement extrait de l'URL HTTP, par exemple : <.>Nous entrons dans le navigateur :
http://www.php.cn/
Le message de demande envoyé par le navigateur inclura le champ d'en-tête de demande d'hôte, comme suit : Hôte :
www.guet.edu.cn
Le numéro de port par défaut 80 est utilisé ici Si le numéro de port est précisé, il devient : Hôte : <.>www.guet.edu.cn:Spécifiez le numéro de portUser-AgentLorsque nous nous connectons au forum en ligne, nous voyons souvent des messages de bienvenue, qui répertorient Le Le nom et la version de votre système d'exploitation ainsi que le nom et la version du navigateur que vous utilisez font souvent plaisir à de nombreuses personnes. En fait, l'application serveur obtient ces informations à partir du champ d'en-tête de la requête User-Agent. Le champ d'en-tête de requête User-Agent permet au client d'indiquer au serveur son système d'exploitation, son navigateur et d'autres attributs. Cependant, ce champ d'en-tête n'est pas nécessaire. Si nous écrivons nous-mêmes un navigateur et n'utilisons pas le champ d'en-tête de requête User-Agent, alors le serveur ne pourra pas connaître nos informations.
Exemple d'en-tête de requête :
GET /form.html HTTP/1.1 (CRLF)
Accepter :image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/ vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accepter-Language:zh-cn (CRLF)
Accepter-Encoding:gzip,deflate (CRLF)
If-Modified-Since : mercredi 5 janvier 2007 11:21:25 GMT (CRLF)
If-None-Match :W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent :Mozilla /4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Hôte :www.guet.edu.cn (CRLF)
Connexion :Keep-Alive (CRLF)
(CRLF)

3. En-tête de réponse
L'en-tête de réponse permet au serveur de transmettre des informations de réponse supplémentaires qui ne peuvent pas être placées dans la ligne d'état, ainsi que des informations sur le serveur et des informations sur le prochain accès à la ressource identifiée par la requête. URI.
En-têtes de réponse couramment utilisés
Location
Le champ d'en-tête de réponse Location est utilisé pour rediriger le destinataire vers un nouvel emplacement. Le champ d’en-tête de réponse Location est souvent utilisé lors de la modification des noms de domaine.
Serveur
Le champ d'en-tête de réponse du serveur contient des informations sur le logiciel utilisé par le serveur pour traiter la demande. Correspond au champ d'en-tête de requête User-Agent. Voici un exemple de champ d'en-tête de réponse
Serveur :
Serveur : Apache-Coyote/1.1
WWW-Authenticate Le champ d'en-tête de réponse
WWW-Authenticate doit être inclus dans un 401 (Non autorisé) message de réponse Lorsque le client reçoit le message de réponse 401 et envoie le champ d'en-tête Autorisation pour demander au serveur de le vérifier, l'en-tête de réponse du serveur contient ce champ d'en-tête.
par exemple : WWW-Authenticate:Basic realm="Basic Auth Test!" //On peut voir que le serveur utilise un mécanisme d'authentification de base pour demander des ressources.

4. En-tête d'entité
Les messages de demande et de réponse peuvent transmettre une entité. Une entité se compose d'un champ d'en-tête d'entité et d'un corps d'entité. Cependant, cela ne signifie pas que le champ d'en-tête d'entité et le corps d'entité doivent être envoyés ensemble. Seul le champ d'en-tête d'entité peut être envoyé. L'en-tête d'entité définit des méta-informations sur le corps de l'entité (ex : présence ou absence d'un corps d'entité) et la ressource identifiée par la requête.
En-têtes d'entité couramment utilisés
Content-Encoding
Le champ d'en-tête d'entité Content-Encoding est utilisé comme modificateur du type de média. Sa valeur indique l'encodage du contenu supplémentaire qui a été appliqué au corps de l'entité, il doit donc Pour obtenir le type de média référencé dans le champ d'en-tête Content-Type, le mécanisme de décodage correspondant doit être utilisé. Content-Encoding est utilisé pour enregistrer la méthode de compression du document, par exemple : Content-Encoding : gzip
Content-Language
Le champ d'en-tête d'entité Content-Language décrit le langage naturel utilisé par la ressource. Si ce champ n'est pas défini, il est supposé que le contenu de l'entité sera disponible pour les lecteurs dans toutes les langues
. Par exemple : Content-Language:da
Content-Length
Le champ d'en-tête d'entité Content-Length est utilisé pour indiquer la longueur du corps de l'entité, exprimée sous la forme d'un nombre décimal stocké en octets. Le champ d'en-tête d'entité
Content-Type
Content-Type est utilisé pour indiquer le type de média du corps de l'entité envoyé au destinataire. Par exemple :
Content-Type : text/html ; charset=ISO-8859-1
Content-Type : text/html; charset=GB2312
Last-Modified
Champ d'en-tête d'entité Last-Modified Indique la date et l'heure auxquelles la ressource a été modifiée pour la dernière fois.
Expires
Le champ d'en-tête d'entité Expires donne la date et l'heure d'expiration de la réponse. Afin de permettre au serveur proxy ou au navigateur de mettre à jour la page dans le cache après un certain temps (lorsque vous accédez à nouveau à la page précédemment visitée, chargez-la directement depuis le cache pour raccourcir le temps de réponse et réduire la charge du serveur), nous pouvons utilisez le champ d'en-tête d'entité Expire pour spécifier l'heure d'expiration de la page. Par exemple : Expire : jeu. 15 septembre 2006 16:23:12 GMT
Les clients et les caches de HTTP 1.1 DOIVENT traiter les autres formats de date illégaux (y compris 0) comme ayant expiré. Exemple : Afin d'empêcher le navigateur de mettre la page en cache, nous pouvons également utiliser le champ d'en-tête d'entité Expires et le définir sur 0. Le programme en jsp est le suivant : réponse.setDateHeader("Expires","0");

5. Utilisez telnet pour observer le processus de communication du protocole http

Objectif et principe de l'expérience :
Utilisez l'outil telnet de MS pour envoyer une requête au serveur en saisissant manuellement les informations de la requête http. Une fois que le serveur aura reçu, interprété et accepté la requête, il renverra une réponse qui vous sera envoyée. être affiché dans telnet Il est affiché sur la fenêtre, approfondissant ainsi la compréhension du processus de communication du protocole http d'un point de vue perceptuel.

Étapes expérimentales :

1. Ouvrir telnet
1.1 Ouvrir telnet
Exécuter-->cmd-->telnet

1.2 Activer la fonction d'écho telnet
set localecho

2. Connectez-vous au serveur et envoyez une requête
2.1 ouvrez www.guet.edu.cn 80 //Notez que le numéro de port ne peut pas être omis

HEAD /index.asp HTTP/1.0
Hôte :www.guet.edu.cn

/*Nous pouvons modifier la méthode de demande et demander le contenu de la page d'accueil de Guilin Electronics, entrez le message comme suit*/
open www.guet.edu.cn 80

GET /index.asp HTTP/1.0 //Le contenu de la ressource demandée
Hébergeur : www.guet.edu.cn

2.2 ouvrir www.sina.com.cn 80 //Entrez telnet directement à l'invite de commande www.sina.com.cn 80
HEAD /index.asp HTTP/1.0
Hôte : www.sina.com.cn

3 Résultats expérimentaux :

3.1 La réponse obtenue en demandant des informations 2.1 est :

http/1.1 200 ok // Requête réussie
Serveur : Microsoft-IIS/5.0 // Serveur Web
Date : JEU, 08 MARS 200707 : 17 : 51 gmt
Connecter : Keep-Alive
Content-Length: 23330
Content-Type: text/html
Expire: jeu. 08 mars 2007 07:16:51 GMT
Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Contrôle du cache : privé

//Contenu de la ressource omis

3.2 La réponse obtenue en demandant des informations 2.2 est :

HTTP/1.0 404 Not Found //Request failed
Date : jeu. 08 mars 2007 07:50:50 GMT
Serveur : Apache/2.0.54
Dernière modification : Jeu. 30 novembre 2006 11:35:41 GMT
ETag : "6277a-415-e7c76980"
Accepter les plages : octets
X-Powered-By : mod_xlayout_jh/0.0.1vhs.markII.remix
Vary : Accept-Encoding
Content-Type : text/html
X-Cache : MISS de zjm152-78.sina.com.cn
Via : 1.0 zjm152-78.sina.com.cn :80
X-Cache : MISS de th-143.sina.com.cn
Connexion : fermer

Connexion perdue avec l'hôte

Appuyez sur n'importe quelle touche pour continuer...

4. Remarques : 1. S'il y a une erreur de saisie, la demande n'aboutira pas.
2. Le champ d'en-tête n'est pas sensible à la casse.
3. Pour en savoir plus sur le protocole HTTP, vous pouvez consulter la RFC2616 et trouver le fichier sur http://www.php.cn/.
4. Pour développer des programmes en arrière-plan, vous devez maîtriser le protocole http

6. Suppléments techniques liés au protocole HTTP

1. Bases :
Les protocoles de haut niveau incluent : le protocole de transfert de fichiers FTP, le protocole de transfert de courrier électronique SMTP, le service DNS du système de noms de domaine, le protocole de transfert de nouvelles réseau NNTP et les protocoles HTTP, etc.
Il existe trois types d'intermédiaires : Proxy ), Gateway et Tunnel, un proxy accepte les requêtes selon le format absolu de l'URI, réécrit tout ou partie du message, et envoie la requête formatée au serveur via l'identifiant URI. Une passerelle est un proxy de réception qui agit comme une couche au-dessus d'un autre serveur et, si nécessaire, peut traduire les requêtes vers le protocole du serveur sous-jacent. Un canal fait office de point relais entre deux connexions qui ne modifient pas les messages. Les canaux sont souvent utilisés lorsque la communication doit passer par un intermédiaire (comme un pare-feu, etc.) ou lorsque l'intermédiaire ne peut pas identifier le contenu du message.
Proxy : Un programme intermédiaire qui peut agir comme serveur ou client pour établir des requêtes pour d'autres clients. Les demandes sont transmises en interne ou via d'autres serveurs via d'éventuelles traductions. Un proxy doit interpréter et si possible réécrire un message de requête avant de l'envoyer. Un proxy agit souvent comme un portail pour les clients via un pare-feu. Un proxy peut également servir d'application d'assistance pour gérer les requêtes via un protocole qui ne sont pas complétées par l'agent utilisateur.
Passerelle : Un serveur qui sert d'intermédiaire pour les autres serveurs. Contrairement à un proxy, une passerelle accepte les requêtes comme s'il s'agissait du serveur d'origine de la ressource demandée ; le client demandeur ignore qu'il traite avec la passerelle.
Une passerelle agit souvent comme un portail côté serveur via un pare-feu. Une passerelle peut également agir comme un traducteur de protocole pour accéder aux ressources stockées dans des systèmes non HTTP.
Channel (Tunnel) : C'est un programme intermédiaire qui fait office de relais entre deux connexions. Une fois activé, le canal n'est pas considéré comme appartenant à la communication HTTP, bien que le canal puisse être initié par une requête HTTP. Lorsque les deux extrémités de la connexion relayée sont fermées, le canal disparaît. Les canaux sont souvent utilisés lorsqu'un portail doit exister ou lorsqu'un intermédiaire ne peut pas interpréter le trafic relayé.

2. Avantages de l'analyse de protocole - L'analyseur HTTP détecte les attaques réseau
L'analyse et le traitement des protocoles de haut niveau de manière modulaire seront la direction de la détection des intrusions à l'avenir.
Les ports HTTP 80, 3128 et 8080 couramment utilisés et son proxy sont spécifiés dans la section réseau à l'aide de la balise de port

3 La vulnérabilité de restriction de longueur de contenu du protocole HTTP conduit à une attaque par déni de service
Quand. en utilisant la méthode POST, ContentLenth peut être configuré pour définir la longueur des données qui doivent être transmises, par exemple, ContentLenth:999999999. La mémoire ne sera pas libérée tant que la transmission n'est pas terminée. Un attaquant peut profiter de cette faille pour continuer. envoyer des données indésirables au serveur WEB jusqu'à ce que le serveur WEB manque de mémoire. Cette méthode d’attaque ne laisse pratiquement aucune trace.
http://www.php.cn/

4. Quelques idées pour utiliser les caractéristiques du protocole HTTP pour mener des attaques par déni de service
Le serveur est en train de traiter la demande de connexion TCP forgée par l'attaquant et n'a pas le temps d'y prêter attention. La demande normale du client (après tout, le taux de demande normal du client est très faible), à ​​ce moment-là, du point de vue d'un client normal, le serveur perd cette situation. est appelé : le serveur est soumis à une attaque SYNFlood (SYN Flood Attack).
Smurf, TearDrop, etc. utilisent des messages ICMP pour mener des attaques par Flood et par fragmentation IP. Cet article utilise la méthode « connexion normale » pour générer une attaque par déni de service.
Le port 19 a été utilisé pour les attaques Chargen au début, à savoir Chargen_Denial_of_Service, mais ! La méthode qu'ils ont utilisée était de générer une connexion UDP entre deux serveurs Chargen, permettant au serveur de traiter trop d'informations et de devenir DOWN. Ensuite, il doit y avoir deux conditions pour tuer un serveur WEB : 1. Il y a un service Chargen. 2. Il y a. est la méthode du service HTTP
 : l'attaquant falsifie l'adresse IP source et envoie une demande de connexion (Connect) à N stations Chargen. Une fois que Chargen aura reçu la connexion, il renverra un flux de caractères de 72 octets par seconde (en fait, selon le). conditions réelles du réseau, cette vitesse est plus rapide) au serveur.

5. Technologie d'empreinte digitale Http
Le principe de l'empreinte digitale Http est fondamentalement le même : enregistrer les légères différences dans l'exécution du protocole Http par différents serveurs pour les identifier est préférable à la pile TCP/IP. empreinte digitale C'est beaucoup plus compliqué, car la personnalisation du fichier de configuration du serveur HTTP et l'ajout de plug-ins ou de composants facilitent la modification des informations de la réponse HTTP, ce qui rend cependant l'identification difficile, la personnalisation du comportement du TCP/; La pile IP nécessite de modifier la couche principale, elle est donc facile à identifier
Il est très simple de configurer le serveur pour renvoyer différentes informations de bannière. Pour les serveurs HTTP open source comme Apache, les utilisateurs peuvent modifier les informations de bannière dans la source. code, puis redémarrez le service HTTP pour prendre effet. Pour les serveurs HTTP qui n'ont pas de code open source, tels que IIS ou Netscape de Microsoft, vous pouvez le modifier dans le fichier Dll qui stocke les informations de bannière. Je n'entrerai pas dans les détails ici. Bien sûr, l'effet d'une telle modification est toujours bon. Une autre façon de masquer les informations de la bannière est d'utiliser un plug-in.
Requêtes de test courantes :
1 : HEAD/Http/1.0 envoie une requête Http de base
2 : DELETE/Http/1.0 envoie des requêtes non autorisées, telles que des requêtes de suppression
3 : GET/Http/3.0 envoie une version illégale de la requête du protocole Http
4 : GET/JUNK/1.0 envoie une requête incorrecte une Spécification de la demande de protocole HTTP
Outil d'identification d'empreintes digitales HTTP Httprint, qui peut déterminer efficacement le type de serveur HTTP en utilisant des principes statistiques et en combinant la technologie de logique floue. Il peut être utilisé pour collecter et analyser les types de serveurs HTTP générés par différents. La signature des serveurs HTTP.

6. Autres : Afin d'améliorer les performances des utilisateurs lors de l'utilisation du navigateur, les navigateurs modernes prennent également en charge les méthodes d'accès simultanées lors de la navigation sur une page Web, plusieurs connexions sont établies en même temps pour obtenir rapidement plusieurs icônes. sur une page Web, ce qui peut compléter la transmission de la page Web entière plus rapidement.
HTTP1.1 fournit cette méthode de connexion continue et la prochaine génération de protocole HTTP : HTTP-NG a ajouté la prise en charge du contrôle de session, de la négociation de contenu riche et d'autres méthodes pour fournir
une connexion plus efficace.

                                     

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!