Je suis confus sur les numéros ACK et SEQ dans les paquets TCP juste après la poignée de main à 3 voies. Je pensais que le numéro ACK est le prochain numéro SEQ prévu. Ainsi, lorsque j'analyse une connexion TCP dans Wireshark, il est indiqué
TCP SYN with SEQ=0 TCP SYN ACK with SEQ 0, ACK=1 (clear, server expects SEQ 1 in next packet) TCP ACK with SEQ 1, ACK=1 (clear, sender expects SEQ 1 in next packet) HTTP Request: TCP PSH ACK with SEQ 1, ACK=1
3 Réponses :
Eh bien, dans la poignée de main, le client ne reçoit qu'un seul paquet à partir du serveur: SEQ = 0 et ACK = 1. Avec cette information, le serveur indique au client 'J'attends un paquet avec SEQ = 1 maintenant'. Vous avez eu ce droit.
Maintenant, dans la dernière partie de la poignée de main, le client envoie un SEQ = 1 et ACK = 1, ce qui signifie essentiellement la même chose que du serveur: «J'attends votre paquet avec SEQ = 1 Maintenant ' P>
Mais: après une poignée de main TCP, le client n'attendra généralement pas que ce paquet soit acqué, mais aussi envoyer les premiers paquets de données déjà (en fait, les données peuvent déjà être contenues dans le dernier Paquet de la poignée de main - Je suppose que c'est le cas dans votre exemple, car la requête HTTP a le même SEQ comme le dernier paquet de la poignée de main). Donc, tout prochain paquet a à nouveau ACK = 1. Mais pourquoi? C'est à nouveau dit «j'attends un paquet avec Seq = 1 de vous». Et cela a du sens complètement: le dernier paquet que le client reçu du serveur avait SEQ = 0 (dans la poignée de main). Gardez également à l'esprit que le client et le serveur ont des SEQ indépendants. Cela signifie que le client pourrait envoyer 100 paquets. Tant que le serveur n'en envoyait pas un, le client attendrait toujours ACK = 1, car le dernier paquet qu'il a reçu du serveur chapeau SEQ = 0 P>
Une autre modification: Pour vraiment comprendre ce qui se passe, vous voudrez peut-être choisir un exemple avec différents SEQS (je l'ai déjà écrit, SEQS de serveur et de client est indépendant): P>
Client -> SYN, SEQ=100 Client <- SYN, ACK, SEQ=700, ACK=101 <- Server Client -> ACK = 701, SEQ=101 [50 Bytes of data] Client -> ACK = 701 [Again, didn't receive sth from server yet], SEQ = 151
Pourquoi la ligne 4 utilise-t-elle à nouveau SEQ 1?
Habituellement, cela ne devrait pas être encore 1, s'il s'agit d'un nouveau paquet. Mais je suppose que la requête HTTP est en fait le dernier paquet de la poignée de main. C'est un peu pas clair dans ma réponse, je vais le modifier
La ligne 4 utilise SEQ 1 car les paquets ACK n'augmentent pas le compteur SEQ et la ligne 3 est juste un ack.
Je ne pense pas que ce soit en ce moment. L'ACK dans la poignée de main à 3 voies ne contient aucune donnée. C'est un ack simple. Et cela n'augmente pas le numéro de séquence.
Dans mon exemple, cela fait :) J'ai des liens de mon parcours, mais c'est en allemand, mais vous comprendrez peut-être la partie importante: www7.informatik.uni-erlangen.de/~eckert/Teaching/... (page 131) Le 3ème paquet de poignée de main contient ack = Sqn_ofserver + 1
Numéro d'accusé de réception (32 bits) - Si le drapeau ACK est défini, la valeur de ce champ est le numéro de séquence suivant que le récepteur attend. Cela reconnaît la réception de tous les octets précédents (le cas échéant). Le premier ACK envoyé par chaque extrémité reconnaît le numéro de séquence initiale de l'autre extrémité elle-même, mais aucune donnée .
Alors ils reconnaissent simplement où ils devraient partir de.
La réponse à votre question est en fait assez simple. Je peux voir que vous n'avez pas de problème à comprendre la procédure de main à la main à trois voies que je suppose que vous connaissez déjà le client et le serveur comptent le numéro de séquence séparément et indépendamment, mais veuillez noter: un paquet ACK pur ne contribue pas au numéro de séquence: < BlockQuote>
seg.len = le nombre d'octets occupés par les données dans le segment (Comptage SYN et FIN) Voir RFC 793
Par conséquent, le deuxième paquet [SYN, ACK] augmente le numéro de séquence de 1, mais le troisième paquet [ACK] n'affecte pas le numéro de séquence, lequel est la raison pour laquelle le prochain paquet a toujours SEQ = 1.
Je vais vous montrer un exemple de connexion TCP dans SMTP pour l'illustrer davantage: Vous pouvez voir qu'après la connexion de la connexion, Le client a en fait envoyé trois paquets consécutifs avec SEQ = 1! En effet, le paquet PURE ACK n'augmente pas le numéro de séquence, ce qui est logique, car vous ne transférez pas de données réelles. Dans un résumé, le numéro de séquence n'augmente pas toujours après avoir été envoyé. paquets. En règle générale, il vous suffit de regarder la len et de vérifier les drapeaux SYN FIN pour déterminer si le numéro de séquence doit être augmenté.