TCP envoie-t-il un SYN/ACK sur chaque paquet ou seulement sur la première connexion?
j'ai un serveur TCP qui écoute un client entrant, puis lui envoie un paquet de données chaque seconde. Je me demandais, est-ce que le paquet SYN/ACK n'est envoyé que sur la connexion initiale, donc il ressemble à ceci:
<client connect>
SYN
ACK
DATA
DATA
DATA
<client disconnect>
Ou fait-il envoyé avec chaque paquet, comme ça?
<client connect>
SYN
ACK
DATA
SYN
ACK
DATA
SYN
ACK
DATA
<client disconnect>
aussi, si c'est le premier cas, y a-t-il des avantages de L'UDP sur TCP si vous laissez la connexion ouverte sur une longue période de temps?
3 réponses
C'est un peu comme:
+-------------------------------------------------------+
| client network server |
+-----------------+ +--------------------|
| (connect) | ---- SYN ----> | |
| | <-- SYN,ACK -- | (accepted) |
| (connected) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when client sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| (send) | ---- data ---> | |
| | <---- ACK ---- | (data received) |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when server sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
...and so on, til the connection is shut down or reset
SYN démarre une connexion; vous ne la verrez habituellement que lorsque la connexion est établie. Mais toutes les données envoyées via TCP nécessitent un ACK. Chaque octet envoyé doit être comptabilisé, ou il sera retransmis (ou la connexion réinitialisée (fermée), dans les cas graves).
les connexions réelles ne sont généralement pas exactement comme le diagramme ci-dessus, cependant, pour deux raisons:
- les ACKs peuvent s'accumuler, donc un ACK peut reconnaître tout ce qui a été reçu jusqu'à ce point. Cela signifie que vous pouvez reconnaître deux ou plusieurs envois avec un ACK.
- un ACK est simplement un drapeau et un champ dans un en-tête TCP. L'envoi nécessite au moins la valeur de bande passante de l'en-tête, plus ce que les couches inférieures mettent en place. Mais les segments de données incluent déjà tout cela...donc si vous envoyez des données, vous pouvez envoyer un ACK en même temps gratuitement.
la plupart des piles TCP/IP tentent de réduire le nombre d'ACKs nus sans risque indu de retransmission ou de réinitialisation de la connexion. Ainsi, une conversation comme celle-ci est tout à fait possible:
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| (send) | ---- data ---> | (wait a bit) |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | (dead air) | |
| | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
quant à UDP, il n'y a pas de concept intégré de SYN et ACK -- UDP est par nature "peu fiable", et pas orienté sur la connexion, donc les concepts ne s'appliquent pas autant. Votre accusé de réception ne sera généralement que la réponse du serveur. Mais certains protocoles de couche d'application construits au-dessus de L'UDP auront une façon spécifique de reconnaître les données envoyées et reçu.
SYN n'est qu'au début.
ACK est sur les segments suivants dans l'une ou l'autre direction. [edit] L'ACK définira également une taille de fenêtre. Si la taille de la fenêtre est de 100 par exemple, l'expéditeur peut envoyer 100 segments avant de s'attendre à recevoir un ACK. Par exemple, si l'expéditeur envoie 100 segments mais que le segment numéro 50 est perdu, le destinataire obtiendra 1-49 & 51 -100. Le récepteur ACK alors pour 50 (le segment suivant qu'il attend) et la taille de fenêtre à 1. L'expéditeur renvoie 1 segment avec séquence numéro 50. Le récepteur ACK alors pour 101 et définit la taille de la fenêtre de nouveau à un nombre plus élevé [edit]
les deux sont en fait des champs dans l'en-tête TCP et peuvent être envoyés avec des données, bien que le SYN et le premier ACK soient typiquement sans données.
donc aucun des scénarios que vous décrivez n'est tout à fait correct. La première est en fait plus proche de la réalité, mais tous les paquets de données après la SYN doivent inclure un ACK, ainsi qu'un champ de numéro d'accusé de réception qui identifie le nombre le prochain paquet attendu.
la fin d'une session implique également des poignées de main avec des paquets marqués FIN et des ACKs les concernant.
les numéros de séquence échangés sont utilisés pour identifier les paquets perdus et permettre un mécanisme de réessaiement, et aussi pour remonter tout le flux de paquets dans le bon ordre.
aussi, si c'est le premier cas, y a-t-il des avantages de L'UDP sur TCP si vous gardez juste la connexion ouverte sur une longue période de de temps?
avec UDP vous ne pouvez pas simplement garder la connexion ouverte sur une longue période de temps. Il n'y a pas de connexion.
cette séquence de drapeaux SYN/ACK/FIN est ce qui fait une connexion.
avec UDP, il n'y a pas de SYNs ou D'ACKs, donc la communication est unidirectionnelle, la livraison n'est pas garantie et la commande n'est pas préservée. Mais il a moins de frais généraux, donc il est utile quand la vitesse est plus importante que la fiabilité, comme par exemple dans les médias de streaming.
C'est un peu simplifié, mais c'est le mieux que je puisse faire pour le moment.
il y a beaucoup plus à ce sujet dans le entrée de wikipedia sur TCP et bien sûr dans les Rfc.
imaginez ceci: La norme TCP D'origine RFC 793 permettait l'envoi de données avec le premier paquet SYN. Cependant, ce n'est pas le cas aujourd'hui. Ce que vous obtenez est un paquet SYN séparé lors de l'initiation de la poignée de main à trois issues du demandeur de la connexion. Supposons Qu'une requête se connecte avec B, ainsi A envoie un paquet avec un bit SYN. B répond par un ACK pour accuser réception et envoie un paquet ACK + SYN. Les données peuvent alors être transmises désormais.
Dordal a une très bonne explication à ce sujet. Cliquez sur ce lien ici.