Quelle est la différence entre le protocole Http et le protocole TCP ?

Le protocole TCP correspond à la couche transport, tandis que le protocole HTTP correspond à la couche application. Par essence, les deux ne sont pas comparables. Le protocole HTTP est basé sur le protocole TCP. Lorsque le navigateur a besoin d'obtenir des données de page Web auprès du serveur, il émet une requête HTTP. Http établira un canal de connexion au serveur via TCP Lorsque les données requises pour cette requête seront complétées, Http déconnectera immédiatement la connexion TCP. Ce processus est très court. Par conséquent, la connexion HTTP est une connexion courte et une connexion sans état. Ce qu'on appelle sans état signifie que chaque fois que le navigateur initie une requête au serveur, il n'établit pas de connexion, mais établit à chaque fois une nouvelle connexion. S'il s'agit d'une connexion, le processus serveur peut maintenir la connexion et mémoriser l'état de certaines informations dans la mémoire. Une fois chaque requête terminée, la connexion est fermée et le contenu concerné est publié, donc aucun état n'est mémorisé et la connexion devient sans état.

Au fil du temps, la page HTML devient plus complexe et de nombreuses images peuvent y être intégrées. À l'heure actuelle, il est inefficace d'établir une connexion TCP à chaque fois que vous accédez à l'image. C'est pourquoi Keep-Alive a été proposé pour résoudre le problème de la faible efficacité. À partir de HTTP/1.1, Keep-Alive est activé par défaut pour conserver la fonctionnalité de connexion. En termes simples, lorsqu'une page Web est ouverte, la connexion TCP utilisée pour transmettre les données HTTP entre le client et le serveur ne sera pas fermée. client Lorsque vous visitez à nouveau la page Web sur ce serveur, vous continuerez à utiliser cette connexion établie. Keep-Alive ne maintient pas la connexion en permanence. Il a une durée de rétention qui peut être définie dans différents logiciels serveur (tels qu'Apache). Bien que la connexion TCP soit maintenue ici pendant un certain temps, cette durée est limitée et sera toujours fermée à ce moment-là, nous la considérons donc également comme une fermeture après chaque connexion terminée. Plus tard, au cours de la Session, Les cookies et autres technologies associées peuvent également maintenir le statut de certains utilisateurs. Mais il utilise toujours une connexion à chaque fois et il s’agit toujours d’une connexion sans état.
Il y avait un concept sur lequel je ne pouvais pas tolérer d'être confus. C'est pourquoi Http est une connexion courte sans état, alors que TCP est une connexion longue avec état ? HTTP n'est-il pas basé sur TCP ? Pourquoi peut-il toujours s'agir d'une connexion courte ? Maintenant, je comprends que Http ferme la connexion TCP une fois chaque requête terminée, il s'agit donc d'une connexion courte. Lorsque nous utilisons le protocole TCP directement via la programmation Socket, parce que nous pouvons contrôler quand ouvrir et fermer la connexion via la zone de code, tant que nous ne fermons pas la connexion via le code, la connexion sera en cours de processus par le client et serveur. Il existe toujours et les données d’état pertinentes seront toujours enregistrées.
Il existe un Socket en C#. En fait, le socket est une encapsulation du protocole TCP/IP. Le Socket lui-même n'est pas un protocole, mais une interface d'appel (API). L'émergence de Socket ne fait que faciliter l'utilisation par les programmeurs de la pile de protocoles TCP/IP. Il s'agit d'une abstraction du protocole TCP/IP, formant ainsi certaines des interfaces de fonctions les plus élémentaires que nous connaissons, telles que créer, écouter, connecter, accepter et envoyer, lire et écrire, etc.

Une description plus vivante : HTTP est une voiture, qui fournit une forme spécifique d'encapsulation ou d'affichage de données ; Socket est un moteur, qui offre la possibilité de communiquer en réseau. Du point de vue de la programmation C#, pour plus de commodité, vous pouvez directement choisir le Http de la voiture déjà fabriquée pour interagir avec le serveur. Cependant, le protocole TCP doit parfois être utilisé en raison de facteurs environnementaux ou d'autres demandes personnalisées. Dans ce cas, vous devez utiliser la programmation Socket, puis traiter vous-même les données obtenues. C'est comme si vous construisiez un camion en utilisant un moteur existant et interagissiez avec le serveur.

HTTP/1.0 et HTTP/1.1 utilisent tous deux TCP comme protocole de transport sous-jacent. Le client HTTP initie d'abord l'établissement d'une connexion TCP avec le serveur. Une fois la connexion établie, le processus du navigateur et le processus serveur peuvent accéder à TCP via leurs sockets respectifs. Comme mentionné précédemment, le socket client est la « porte » entre le processus client et la connexion TCP, et le socket côté serveur est la « porte » entre le processus serveur et la même connexion TCP. Le client envoie des messages de requête HTTP à son propre socket et reçoit des messages de réponse HTTP de son propre socket. De même, le serveur reçoit des messages de requête HTTP depuis son propre socket et envoie des messages de réponse HTTP à son propre socket. Une fois qu'un client ou un serveur envoie un message à leurs sockets respectifs, le message tombe entièrement sous le contrôle de TCP. TCP fournit un service de transmission de données fiable vers HTTP ; cela signifie que chaque message de requête HTTP envoyé par le client finira par atteindre le serveur sans perte, et chaque message de réponse HTTP envoyé par le serveur finira par atteindre le client sans perte.
　Le code C# utilise le protocole TCP pour se connecter à la base de données distante. Chaque fois qu'une nouvelle connexion est créée, connection.open ouvre la connexion TCP. La connexion est fermée lorsque connection.Close est appelé. La couche inférieure de FTP est également TCP, mais il s'agit d'une connexion à long terme. Le transfert de fichiers volumineux est plus rapide. Cela dépend du scénario spécifique. Côté serveur, si le programme adopte une méthode de connexion longue, il peut contrôler le nombre de connexions au serveur en même temps pour empêcher plusieurs connexions en même temps. Cependant, si vous adoptez la méthode de connexion courte, vous ne pouvez pas contrôler le nombre de connexions connectées au serveur en même temps. C'est également un avantage, et cela peut gérer un grand nombre de demandes de connexion en même temps. Cependant, si le nombre de demandes de connexion est trop important, le serveur peut cesser de fonctionner.
WebService ne nécessite pas de connexion. Il peut prendre en charge au moins des dizaines de milliers/centaines de milliers de requêtes en une seconde. Chaque requête est ensuite libérée, et il n'y a pas de consommation de mémoire libre. Généralement, il n’y a pas de limite sur le nombre de connexions simultanées, ce qui constitue un avantage. Message Queue doit établir une connexion et il est très difficile de prendre en charge des milliers de connexions. Parce que chaque connexion occupera une certaine quantité d’espace en mémoire même si elle ne demande pas de données. Il y aura des restrictions, comme le serveur de base de données SQL Server, qui dispose généralement d'un maximum de 16 connexions simultanées.

Le protocole Http doit passer le port spécifié, 80, donc ce port n'est pas restreint sur les ordinateurs généraux, donc le protocole Http peut passer avec succès à travers les pare-feu sur toutes les machines. Si vous utilisez la programmation Socket, vous devez spécifier vous-même un port spécifique. Il est alors très probable que ce port soit désactivé dans un certain environnement, il ne pourra donc pas pénétrer dans le pare-feu. IIS utilise le port 80, ce qui signifie que ce programme a écouté ce port. Une fois qu'il constate que quelqu'un souhaite établir une connexion à ce port, il répondra puis établira la connexion. Les connexions mentionnées ici sont toutes des connexions courtes. Ainsi, vos demandes d'URL sur le serveur sont envoyées au programme du site Web via le port 80. Le navigateur client l'envoie ensuite via ce port.

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. La sixième version de HTTP/1.0 est actuellement utilisée sur le WWW. Les travaux de normalisation de HTTP/1.1 sont en cours, et HTTP-NG (Suite). Génération de HTTP) des propositions 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 demande. 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 ( Super Text Transfer Protocol) est un protocole de couche application sans état basé sur le modèle de demande et de réponse. Il est souvent basé sur la méthode de connexion TCP. La version HTTP 1.1 fournit un mécanisme de connexion continue. Ce sont toutes des applications Web. construit 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]
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 ; . 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 "/". nous.
ex :
1. Saisie : www.guet.edu.cn
Le navigateur se convertit automatiquement en : http://www.guet.edu. cn/
2. http:192.168.0.116:8080/index.jsp

2. Explication détaillée du 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 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
où Method représente la méthode de requête ; -URI est un identifiant de ressource uniforme ; la version HTTP 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 distinct 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 Request-URI
🎜>POST In Request -Ajouter de nouvelles données après la ressource identifiée par URI
HEAD Demande d'obtenir l'en-tête du message de réponse de la ressource identifiée par Request-URI
PUT Demander au serveur de stocker une ressource et d'utiliser Request-URI comme identifiant
DELETE Demander au serveur de supprimer la ressource identifiée par Request-URI
TRACE Demander au serveur de renvoyer les informations de requête reçues, principalement utilisées à des fins de test ou de diagnostic
CONNECT Réservé pour une utilisation future
OPTIONS requête pour interroger les performances du serveur, ou requête et ressources Options et exigences associées
Exemples d'application :
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 le GET méthode pour obtenir des ressources du 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 requête, et est souvent utilisé 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é, et avant cela c'était l'en-tête du message
user=jeffrey&pwd=1234 //La ligne suivante est les données soumises

Méthode HEAD et La méthode GET est presque la même. De même, 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 ; 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 délai 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 texte de la réponse est le contenu de la ressource renvoyée par le serveur

. 4. En-tête de message d'explication détaillée du protocole HTTP

Message HTTP Il se compose de requêtes client à serveur et de réponses serveur à 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 ( une ligne avec uniquement CRLF), et la 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 et sont uniquement utilisé pour la transmission des nouvelles.
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 instructions 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 ","no-cache" ); La fonction est équivalente au code ci-dessus, généralement les deux // sont utilisés ensemble
Ce code définira le champ d'en-tête commun 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 Connexion permet d'envoyer des options pour spécifier une 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 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 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.
Host (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 Host 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 :
On rentre dans le navigateur : http://www.guet.edu.cn/index.html
Le message de requête envoyé par le navigateur inclura l'en-tête de requête Host Domain, 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-Agent
Lorsque nous nous connectons au forum en ligne, nous voyons souvent des messages de bienvenue, qui répertorient vos opérations Le nom et La version du système ainsi que le nom et la version du navigateur que vous utilisez font souvent sensation chez 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 les réponses à la demande - Informations pour un accès ultérieur à la ressource identifiée par l'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 du corps de l'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

But et principe de l'expérience :
Utilisez l'outil telnet de MS pour saisir manuellement la requête http Sous forme d'informations, une requête est envoyée 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 perceptuellement la compréhension du processus de communication du protocole http.

Étapes expérimentales :

1. Ouvrez telnet
1.1 Ouvrez telnet
et exécutez-->cmd-->. ; telnet

1.2 Ouvrir la fonction d'écho telnet
set localecho

2. Connectez-vous au serveur et envoyez une requête
2.1. open 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, saisissez le message comme suit*/
ouvrir 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 //Saisissez 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 Obtenu à partir des informations de la demande 2.1 La réponse est :

HTTP/1.1 200 OK                                                                   //serveur Web
Date : jeu. 08 mars 20 0707:17:51 GMT
Connexion : Garder - Alive B=BEJCDGKADEDJKLKKAJEOIMMH ; chemin=/
Cache- contrôle : privé



//Contenu de la ressource omis

3.2 La réponse obtenue en demandant l'information 2.2 est :

HTTP/1.0 404 introuvable //La requête a échouéDate : jeu. 8 mars 2007 07:50:50 GMTServeur : 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. 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. Une erreur de saisie s'est produite. réussir. 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.letf.org/rfc

.
4. Pour développer des programmes en arrière-plan, vous devez maîtriser le protocole http

6.

Protocole HTTP suppléments techniques associés

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, les protocoles Network News Transfer Protocol NNTP et HTTP, etc.
Là 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 l'orientation de la future détection des intrusions.
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.cnpaf.net/Class/HTTP/0532918532667330.html

4. Quelques idées d'utilisation des caractéristiques du protocole HTTP pour mener des attaques par déni de service
Côté serveur est occupé à traiter la demande de connexion TCP falsifiée de 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 à ce moment-là, du point de vue d'un client normal, le serveur perd). réponse. Cette situation s'appelle : le 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 utilisent est de générer une connexion UDP entre deux serveurs Chargen, permettant au serveur de traiter trop d'informations et d'être 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 méthode réelle). conditions du réseau, cette vitesse est plus rapide) au serveur.

5. Technologie d'empreintes digitales 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.
Demandes 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 les requêtes de suppression
3 : GET/Http/3.0 envoie une version illégale de la demande de protocole Http
4 : GET/JUNK/1.0 envoie une spécification incorrecte de la demande de protocole Http
Outil d'identification d'empreintes digitales HTTP Httprint, qui utilise des principes statistiques pour combiner La technologie de logique floue peut déterminer efficacement le type de serveur HTTP. Elle peut être utilisée 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 la nouvelle 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!