Introduction . 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. La sixième version de HTTP/1.0 est actuellement utilisée sur le Web. Les travaux de normalisation de HTTP/1.1 sont en cours et la proposition HTTP-NG (Next Generation of HTTP) a été avancée.
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. Apatride : Le protocole HTTP est un protocole apatride. 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 basé sur request et Un protocole de couche application en mode réponse, sans état, souvent basé sur la méthode de connexion TCP version 1.1, fournit un mécanisme de connexion continue. La grande majorité du développement Web est basée 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://host[":"port][abs_path]
2. Explication détaillée de Protocole HTTP Requête
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 une méthode. symbole Début, séparé par des espaces, suivi de l'URI demandé et de la version du protocole, le format est le suivant : Method Request-URI HTTP-Version CRLF
où Method représente la méthode de requête Request-URI est une ressource uniforme ; identifiant ; HTTP -Version indique la version du protocole HTTP demandée ; CRLF indique le retour chariot et le saut de ligne (à l'exception du CRLF de 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 lettres majuscules). Les explications de chaque méthode sont les suivantes :GET Requête pour obtenir la ressource identifiée par le Request-URI.
POST Ajouter de nouvelles données après la ressource identifiée par Request-URI HEAD Demande pour obtenir l'en-tête du message de réponse de la ressource identifiée par Request-URI PUT Demander au serveur pour stocker une ressource et utiliser Request -URI comme identifiant DELETE Demande au serveur de supprimer la ressource identifiée par Request-URI TRACE Demande au serveur de renvoyer les informations de demande reçues, principalement utilisé pour les tests ou les diagnostics CONNECT est réservé à une utilisation future des requêtes OPTIONS pour interroger les performances du serveur ou interroger les options et exigences liées aux ressources Exemples d'application :
Méthode GET : Lors de l'accès à une page Web en saisissant une URL dans la barre d'adresse du navigateur, le navigateur utilise la méthode GET pour obtenir des ressources du serveur, par exemple : GET /form. html HTTP/1.1 (CRLF)
Exigences de la méthode POST Le serveur demandé accepte les données jointes à la requête, souvent utilisées 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 quoi il s'agissait de l'en-tête du message user=jeffrey&pwd =1234 //La ligne suivante correspond aux données soumises
La méthode HEAD est presque 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 les informations 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 avec une 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
Parmi eux, HTTP-Version représente la version du protocole HTTP du serveur ; 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. , continuez le traitement
2xx : Succès --indique que la demande a été reçue, comprise et acceptée avec succès
3xx : Redirection --d'autres opérations doivent être effectuées pour terminer la demande
4xx : Erreur du 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 à répondre à la demande légale
Codes d'état courants, description de l'état et explication :
200 OK //La demande du client a réussi
400 Bad Request //La demande du client contient une erreur de syntaxe et ne peut pas être compris par le serveur
401 Non autorisé //La demande n'est pas autorisée, ce code d'état doit être utilisé avec le rapport WWW-Authenticate //Champ d'en-tête
403 Interdit //Le serveur a reçu le 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 ne peut pas actuellement traiter le client Après un certain temps, // peut revenir à la normale
ex : HTTP/1.1 200 OK (CRLF)
2. Description de l'en-tête de réponse
3 . Le texte 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
Le message HTTP du client au serveur consiste en une requête et une réponse du serveur au client. Les messages de requête et les messages de réponse se composent d'une ligne de départ (pour un message de requête, la ligne de départ est la ligne de requête, pour un message de réponse, la ligne de démarrage 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é de nom + ":" + espace + valeur. 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 l'entité transmise, uniquement pour le message transmis. .
par exemple :
Cache-Control est utilisé pour spécifier 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. (a La directive de mise en cache d'un message n'affecte pas le mécanisme de mise en cache d'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 cache lors de la réponse incluent : public, privé, sans cache, sans magasin, sans transformation, doit-revalider, proxy-revalidate, max-age, s-maxage.
par exemple : afin de demander au navigateur IE (client) de ne pas mettre la page en cache, le programme JSP côté serveur peut être écrit comme suit : réponse.sehHeader("Cache-Control", "no-cache");
//response .setHeader("Pragma","no-cache"); La fonction est équivalente au code ci-dessus, généralement les deux // sont utilisés ensemble
Ce code définira l'en-tête commun champ dans le message de réponse envoyé : Cache-Control :no-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 de connexion permet aux options d'envoyer un message spécifié connexion. Par exemple, précisez que la connexion est continue, ou spécifiez l'option "fermer" pour notifier 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 le client pour transmettre la demande au serveur Informations supplémentaires ainsi que des informations sur le client lui-même.
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. Par exemple : 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.
Accepter-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 encodage 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 requête, 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 consulter une 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, qui est généralement extrait du L'URL HTTP sort, par exemple :
Nous entrons dans le navigateur : http://www.guet.edu.cn/index.html
Le message de requête envoyé par le navigateur inclura l'hôte champ d'en-tête de requê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 spécifié, il devient : Hôte : www. .guet.edu.cn : Spécifiez le numéro de port
User-Agent
Lorsque nous nous connectons au forum en ligne, nous voyons souvent des messages de bienvenue, qui répertorient le nom de votre système d'exploitation. et la version, le nom et la version du navigateur que vous utilisez, ce qui fait 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-Langue: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)
Agent utilisateur:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Hôte :www.guet.edu.cn (CRLF)
Connexion : Keep-Alive (CRLF)
(CRLF)
3.
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 un accès ultérieur à la ressource identifiée par le Request-URI. En-têtes de réponse couramment utilisésLocationLe 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. ServeurLe 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 du Champ d'en-tête de réponse du serveur : Serveur : Apache-Coyote/1.1WWW-AuthenticateRéponse WWW-Authenticate champ d'en-tête Doit être inclus dans le message de réponse 401 (non autorisé) 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 les ressources demandées. 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 du corps de l'entité) et la ressource identifiée par la requête. En-têtes d'entité couramment utilisésContent-EncodingLe champ d'en-tête d'entité Content-Encoding est utilisé comme modificateur de type de média et sa valeur indique qu'il a été appliqué à l'entité Le codage du contenu supplémentaire dans le corps, de sorte que pour obtenir le type de média référencé dans le champ d'en-tête Content-Type, un 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: gzipContent-LanguageLe champ d'en-tête d'entité Content-Language décrit le langage naturel utilisé par le 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:daContent-LengthLe champ d'en-tête d'entité Content-Length est utilisé pour indiquer la longueur du corps de l'entité, exprimée sous forme de nombre décimal stocké en octets. Content-TypeLe champ d'en-tête d'entité Content-Type spécifie le type de média du corps de l'entité envoyé au destinataire. par exemple :Type de contenu : texte/html ; charset=ISO-8859-1
Type de contenu : texte/html; charset=GB2312
Dernière modification
Le champ d'en-tête d'entité Last-Modified est utilisé pour indiquer la date et l'heure de la dernière modification de la ressource.
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, raccourcissez le temps de réponse et réduisez 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
Le but et le principe de l'expérience :
Utilisez l'outil MS telnet pour saisir manuellement les informations de la requête http et envoyer une requête au serveur Une fois que le serveur a reçu, interprété et accepté la requête, il renverra une réponse qui sera affichée sur telnet. fenêtre, approfondissant ainsi votre compréhension du processus de communication du protocole http.
Étapes expérimentales :
1. Ouvrez telnet
1.1 Ouvrez 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 //Remarque. 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. Pour demander le contenu de la page d'accueil de Guilin Electronics, saisissez le message comme suit*/
ouvrez www.guet.edu.cn 80
GET /index.asp HTTP/1.0 //Demande de ressources Contenu
Hôte : www.guet.edu.cn
2.2 ouvert www.sina.com.cn 80 //Saisie telnet www. sina.com.cn directement à l'invite de commande 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 ' ' il ' ‐ ‐ ‐ : jeu. 8 mars 200707:17:51 GMT
Connexion : Keep-Alive
Expiration : jeu. 8 mars 2007 07:16:51 GMTDéfinir le cookie : ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/Cache-control : privé/ /Contenu de la ressource omis3.2 La réponse obtenue en demandant des informations 2.2 est :HTTP/1.0 404 Not Found //La requête a échouéDate : jeu. 8 mars 2007 07 : 50h50 GMTServeur : Apache/2.0.546. Complé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 d'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.
Les passerelles agissent souvent comme des portails côté serveur via des pare-feu. Les passerelles peuvent é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 l'orientation de la future détection des intrusions.
Les ports 80, 3128 et 8080 couramment utilisés de HTTP 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 à des attaques par déni de service<.>
Lorsque vous utilisez la méthode POST, vous pouvez configurer ContentLenth 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 avant la fin de la transmission. cette faille pour envoyer continuellement des données inutiles au serveur WEB jusqu'à ce que la mémoire du serveur WEB soit épuisée. Cette méthode d’attaque ne laisse pratiquement aucune trace. http://www.cnpaf.net/Class/HTTP/0532918532667330.html4. Quelques idées pour utiliser les caractéristiques du protocole HTTP pour mener des attaques par déni de serviceServeur Le client est occupé à traiter la demande de connexion TCP falsifiée par l'attaquant et n'a pas le temps de prêter attention à la demande normale du client (après tout, le taux de demandes normales du client est très faible à l'heure actuelle). du client normal, le serveur perd la réponse. Cette situation est appelée : Le côté serveur est soumis à une attaque SYNFlood (attaque par inondation SYN). 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 Chargens. Une fois que Chargen aura reçu la connexion, il renverra un flux de caractères de 72 octets par seconde (en fait, selon). à la situation réelle du réseau, ceci plus rapidement) au serveur. 5. Technologie d'empreinte digitale Http Le principe de l'empreinte digitale Http est fondamentalement le même : il est préférable d'enregistrer les légères différences dans l'exécution du protocole Http par différents serveurs pour les identifier. L'empreinte digitale de la pile /IP est beaucoup plus compliquée. La raison en est que la personnalisation du fichier de configuration du serveur HTTP et l'ajout de plug-ins ou de composants facilitent la modification des informations de réponse HTTP, ce qui rend toutefois l'identification difficile. La pile TCP/IP nécessite que la couche principale soit modifiée, 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 Banner dans le code source, puis le redémarrage du service HTTP prendra effet ; pour les serveurs HTTP qui n'ont pas de code open source, tels que IIS ou Netscape de Microsoft, vous pouvez les modifier dans le fichier Dll qui stocke Banner. Des articles connexes en ont parlé, donc je n'entrerai pas dans les détails ici. Bien sûr, c'est le cas. L'effet de la modification est toujours bon. Une autre façon de brouiller les informations de la bannière est d'utiliser un plug-in. Requêtes de test courantes : 1 : HEAD/Http/1.0 envoie des requêtes Http de base 2 : DELETE/Http/1.0 envoie les requêtes qui ne sont pas autorisées, telles que Demande de suppression3 : GET/Http/3.0 envoie une version illégale de la demande de protocole HTTP4 : GET/JUNK/1.0 envoie une spécification incorrecte de la demande de protocole HTTPOutil 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 signatures générées par différents 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 le protocole HTTP de nouvelle génération : 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 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!
Solution http500
Comment résoudre l'erreur de requête http 415
Solution d'erreur HTTP 503
Comment résoudre l'erreur 0xc000409
Utilisation du mot-clé Type dans Go
Comment enregistrer des fichiers sur une clé USB
Introduction aux noms de domaine de premier niveau couramment utilisés
Comment se connecter à la base de données en VB
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
