2017-10-17 10 views
-1

Je joue avec Wireshark pour déboguer des projets d'automatisation de l'IdO sur lesquels je travaille. Je pense que j'aurais avantage à mieux comprendre comment fonctionnent HTTP et TCP/IP. La plupart des explications que je trouve décrivent le protocole HTTP comme "surfant sur" TCP/IP, mais je demande plus précisément ce qui est réellement envoyé.Comment TCP/IP et HTTP fonctionnent-ils ensemble?

Voici un exemple d'interaction client/serveur je prins

Client: [SYN] 
Server: [SYN, ACK] 
Client: [ACK] 

Si je comprends à ce jour, ils ont maintenant établi une connexion TCP. La capture suivante, cependant, me montre

Client: POST /whatever 
Server: 200 OK 

Okay maintenant je suis perdu. L'examen de cette capture me montre que j'ai une couche Ethernet, IP, TCP et HTTP dans une seule trame. Est-il vraiment aussi simple que le client d'ajouter un tas de texte après la fin du paquet TCP et d'injecter ces octets supplémentaires sur le routeur? Qui, probablement, analyse ensuite le TCP/IP et le transmet en conséquence? C'est la source de ma confusion. Par «chevauche sur», est-ce que cela signifie (dans un sens physique) que HTTP est juste une série d'octets qui sont envoyés dans la même trame, après le paquet TCP? Est-ce que le HTTP dans ce cas est considéré comme la charge utile du TCP/IP?

Et bien sûr, pour finir

Server: [FIN, ACK] 
Client: [ACK] 
Client: [FIN, ACK] 
Server: [ACK] 
//In this case the server terminates the connection. 

Edit: Un commentateur ci-dessous a posé une question qui me fait me sentir comme si je ne l'ai pas été très clair sur ce que je demande. Imaginez que je puisse me tenir entre mon client et le serveur (ou peut-être que ce serait plus précis de rester entre mon client et le routeur et encore entre le routeur et le serveur). En ignorant les considérations quand on doit physiquement envoyer des données brutes sur un support physique (sommes de contrôle, codes de correction d'erreurs, etc.), à quoi ressemblerait le trafic réel, par rapport au temps? Est-ce que je verrais des octets pour une couche ethernet suivie par des octets pour une couche ip, tcp, http, et ainsi de suite?

+0

HTTP est juste des données à TCP, mais je ne sais pas pourquoi vous continuez à dire '* après * le paquet TCP'. Les données envoyées via TCP sont envoyées * dans * les paquets TCP. – EJP

+0

Je veux dire qu'à un certain moment, mon client (un capteur) envoie juste un flux d'octets sur l'air au routeur. Le routeur interprète ces byes et fait quelque chose avec eux (les transmet au serveur). Ce flux d'octets peut être interprété de manière utile. Si vous deviez examiner ce flux d'octets un octet à la fois lorsqu'il est envoyé hors de l'antenne du capteur, cela ressemblerait-il à [Ethernet] [IP] [TCP] [HTTP]?(Sauf, bien sûr, ce que je suppose être beaucoup de codes de correction d'erreur, sommes de contrôle, etc.) – brenzo

+0

Si vous envoyez à partir d'une antenne, ce serait Wi-Fi, et les cadres seraient des cadres Wi-Fi , pas des cadres ethernet. Wi-Fi et ethernet sont deux protocoles de liaison de données complètement différents. –

Répondre

1

Les couches réseau utilisent l'abstraction et l'encapsulation. Les couches inférieures encapsulent les couches supérieures.

  • La couche Application peut avoir ses propres protocoles, par ex. HTTP. HTTP communique avec HTTP sur le périphérique cible, et c'est un protocole qui transfère les données d'application (HTML).
  • La couche transport (couche 4) encapsule les datagrammes d'application et communique avec le même protocole de couche Transport sur le périphérique cible . Certains protocoles de transport ont des garanties et créent des connexions pour la fiabilité, par ex. TCP (segments), mais certains sont sans connexion, sans garantie, par ex. UDP (datagrammes). Le but de cette couche est d'obtenir les données d'application d'une application à une autre application. Certains protocoles de transport utilisent l'adressage (ports) pour accomplir ceci, et certains utilisent quelque chose d'autre, ou rien du tout.
  • La couche réseau encapsule les datagrammes de protocole de transport dans des paquets et communique avec le protocole réseau du périphérique cible. Le but de cette couche est d'obtenir des paquets d'un périphérique sur un réseau vers un périphérique sur un autre réseau. Les routeurs utilisent les informations d'adressage dans les en-têtes de paquet pour accomplir ceci (adresses IPv4, IPX, IPv6, AppleTalk, etc.).
  • La couche Liaison de données encapsule les paquets réseau dans des trames et elle communique avec la liaison de données d'un périphérique sur le même réseau. Le but de cette couche est d'obtenir des trames à un autre périphérique sur le même réseau (imprimante PC, routeur, etc.). Certains protocoles de liaison de données utilisent l'adressage (les protocoles IEEE utilisent l'adressage MAC, 48 bits ou adresses MAC 64 bits), certains utilisent d'autres adressages (le relais de trame utilise DLCI, ATM utilise VPI/VCI, etc.), et certains n'utilisent aucun adressage (PPP seulement a deux périphériques, donc il n'a pas besoin d'adressage). Le protocole peut changer changement que le paquet encapsulé est envoyé d'un réseau à un autre sur son chemin vers le périphérique de destination. Les routeurs suppriment le cadre et le suppriment au fur et à mesure qu'ils transfèrent les paquets d'un réseau à un autre, créant une nouvelle trame pour encapsuler le paquet pour le nouveau réseau.
  • La couche physique (couche 1) convertit les trames de la couche Liaison de données (couche 2) en "bits sur le fil".

Le périphérique de destination effectue l'inverse de ce qui précède, en fournissant les données d'application à l'application de destination. En raison de l'abstraction et l'encapsulation à chaque couche, vous pouvez mélanger et faire correspondre différents protocoles à différentes couches. Par exemple, ethernet peut transporter n'importe quel nombre de protocoles réseau (IPv4, IPX, IPv6, AppleTalk, etc.) sans connaître ou prendre soin de ce qui est dans la charge utile de la trame ethernet. Inversement, IP ne sait pas ou ne se soucie pas quel protocole de liaison de données (Ethernet, Wi-Fi, anneau à jeton, PPP, relais de trames, etc.) le transporte.

Votre navigateur utilise le protocole HTTP pour communiquer les données (HTML) entre le navigateur Web et le serveur Web. HTTP utilise TCP pour le transporter vers le serveur Web. Le navigateur Web demandera que TCP lui attribue une adresse TCP (port). Le serveur Web utilise probablement le port TCP 80 bien connu pour HTTP, et TCP va segmenter le flux de données de l'application en segments TCP (ne pas confondre avec la fragmentation IPv4). TCP va créer une connexion avec TCP sur le système d'exploitation du serveur Web, et TCP garantit que les segments arriveront, et que les données présentées à l'application de destination seront complètes et dans l'ordre.

TCP peut théoriquement utiliser n'importe quel protocole de couche réseau, mais en pratique il n'utilise que IPv4 ou IPv6. IP encapsulera les segments TCP dans les paquets IP.

IP utilisera le protocole de liaison de données de l'interface par laquelle ces paquets seront envoyés. Sur un PC, il s'agit très probablement d'une connexion Ethernet ou Wi-Fi, mais cela peut être autre chose que PPP. Le protocole de liaison de données encapsulera les paquets dans des trames pour le protocole de liaison de données. Chaque protocole de liaison de données a un format de trame différent. Si le périphérique de destination est sur le même réseau, les trames sont adressées et livrées directement à la destination. Si la destination est sur un réseau différent, les trames sont adressées et envoyées à la passerelle (routeur) configurée dans le système d'exploitation source.

L'interface codera les bits dans la trame et le signal sur le support de l'interface.

+0

Merci pour cette réponse vraiment détaillée. Ça a beaucoup aidé. Pour confirmer j'ai bien compris, il pourrait théoriquement être que mon HTTP POST est cassé en plusieurs segments TCP, qui sont ensuite encapsulés par des couches inférieures, envoyés, et reconstruits sur le serveur. c'est-à-dire lorsque le logiciel de couche de transport du serveur a déterminé que tous les paquets TCP de cette session particulière ont été reçus, le HTTP est reconstruit à partir de ces segments et transmis à l'application concernée? – brenzo

+0

Oui. Mais rappelez-vous que HTTP est également un protocole de transfert de données d'application. Les données d'application qu'il transfère sont en fait du HTML. –

+0

Juste, cela a du sens. Et puis, parce que chaque couche est agnostique des autres, cette architecture facilite l'échange de HTTP pour FTP ou SSH, sans avoir à concevoir quelque chose de nouveau dessous pour les livrer. Exactement de la même manière que vous pouvez communiquer via Ethernet ou Wi-Fi sans avoir à changer l'une des couches ci-dessus. – brenzo