Protocole de contrôle de transmission

Protocole de contrôle de transmission (TCP)
Famille:	Famille de protocoles Internet
Zone d'opération :	Transport de données bidirectionnel fiable
TCP dans la pile de protocoles TCP/IP : application HTTP SMTP ... transport TCP l'Internet IP ( IPv4 , IPv6 ) L'accès au réseau Ethernet Bus à jetons Anneau de jeton FDDI ...
Normes:	RFC 793 (1981) RFC 7323 (2014)

L' anglais Transmission Control Protocol ( TCP , allemand  Transmission Control Protocol ) est un protocole de réseau qui définit pour être sur le chemin dans lequel les données échangées entre les composants du réseau. Presque tous les systèmes d'exploitation actuels des ordinateurs modernes peuvent gérer TCP et l'utiliser pour échanger des données avec d'autres ordinateurs. Le protocole est un fiable , orienté connexion , à commutation par paquets protocole de transport dans les réseaux informatiques . Il fait partie de la famille des protocoles Internet , le fondement d' Internet .

TCP a été développé par Robert E. Kahn et Vinton G. Cerf . Leurs travaux de recherche, qu'ils ont commencés en 1973, ont duré plusieurs années. La première normalisation de TCP a donc eu lieu en 1981 sous le nom de RFC 793 . Après cela, il y a eu de nombreuses améliorations qui sont encore spécifiées aujourd'hui dans les nouvelles RFC , une série de documents techniques et organisationnels sur Internet.

Contrairement à l' UDP sans connexion (en anglais User Datagram Protocol ) est une connexion TCP entre deux points d'extrémité d'une connexion réseau ( sockets ) il y a. Les données peuvent être transmises dans les deux sens sur cette connexion. Dans la plupart des cas, TCP est basé sur l' IP (Internet Protocol), c'est pourquoi le terme « TCP/IP protocol » est souvent (et souvent à tort) également utilisé . Dans les piles de protocoles comme le modèle OSI , TCP et IP ne sont pas situés sur la même couche. TCP est une implémentation de la couche transport.

En raison de ses nombreuses propriétés positives (la perte de données est reconnue et corrigée automatiquement, la transmission de données est possible dans les deux sens, la surcharge du réseau est évitée, etc.) TCP est un protocole très répandu pour la transmission de données. Par exemple, TCP est utilisé presque exclusivement comme moyen de transport pour le WWW , le courrier électronique et de nombreux autres services réseau populaires.

Général

En principe, TCP est une connexion de bout en bout en full duplex , qui permet de transmettre des informations dans les deux sens, à la manière d'un appel téléphonique. Cette connexion peut également être considérée comme deux connexions semi-duplex dans lesquelles les informations peuvent circuler dans les deux sens (mais pas en même temps). Les données dans le sens opposé peuvent contenir des informations de contrôle supplémentaires. La gestion de cette connexion ainsi que le transfert des données sont pris en charge par le logiciel TCP. Le logiciel TCP se trouve généralement dans la pile de protocoles réseau du système d'exploitation. Les programmes d'application utilisent une interface à cet effet, principalement des sockets , qui sont (selon le système d'exploitation), par exemple dans Microsoft Windows dans des bibliothèques de programmes spécialement intégrées (" Winsock .dll " ou " wsock32.dll "). Linux et de nombreux autres systèmes d' exploitation de type Unix contiennent une couche socket dans le noyau du système d'exploitation. La couche socket est accessible via des appels système. Les applications qui utilisent fréquemment TCP incluent les navigateurs Web et les serveurs Web .

Chaque connexion TCP est identifiée de manière unique par deux points de terminaison. Un point de terminaison est une paire ordonnée constituée d'une adresse IP et d'un port . Une telle paire forme une interface logicielle bidirectionnelle et est également appelée socket . Ainsi, une connexion TCP est identifiée par quatre valeurs (un quadruple) :

(Lokaler Rechner, Lokaler Port, Entfernter Rechner, Entfernter Port)

Cela dépend de l'ensemble du quadruple. Par exemple, deux processus différents sur le même ordinateur peuvent utiliser le même port local et même communiquer avec le même ordinateur du côté opposé, à condition que les processus impliqués utilisent des ports différents de l'autre côté. Dans un tel cas, il y aurait deux connexions différentes, dont les quadruples ne diffèrent que par l'une des quatre valeurs : le port du côté opposé.

Verbindung 1: (Lokaler Rechner, Port x, Entfernter Rechner, Port y)
Verbindung 2: (Lokaler Rechner, Port x, Entfernter Rechner, Port z)

Par exemple, un processus serveur crée un socket ( socket , bind ) sur le port 80, le marque pour les connexions entrantes ( listen ) et demande la prochaine connexion en attente du système d'exploitation ( accept ). Cette requête bloque initialement le processus serveur car il n'y a pas encore de connexion. Si la première demande de connexion arrive d'un client, elle est acceptée par le système d'exploitation pour que la connexion soit établie. Cette connexion est désormais identifiée par le quadruple décrit ci-dessus.

Enfin, le processus serveur est réveillé et reçoit un handle pour cette connexion. Généralement, le processus serveur démarre alors un processus fils auquel il délègue la gestion de la connexion. Il continue ensuite son travail avec une autre requête Accept au système d'exploitation. Cela permet à un serveur Web d'accepter plusieurs connexions provenant de différents ordinateurs. Plusieurs listes sur le même port ne sont pas possibles. Habituellement, le programme côté client ne détermine pas le port lui-même, mais permet au système d'exploitation de l'attribuer.

Les ports sont des numéros de 16 bits ( numéros de port) et vont de 0 à 65535. Les ports de 0 à 1023 sont réservés et attribués par l' IANA , par ex. B. Le port 80 est réservé au HTTP utilisé dans le WWW . L'utilisation des ports prédéfinis n'est pas contraignante. Par exemple, chaque administrateur peut exécuter un serveur FTP (généralement le port 21) sur n'importe quel autre port.

Etablissement et terminaison de la connexion

Un serveur qui propose son service crée un point de terminaison (socket) avec le numéro de port et son adresse IP. Ceci est connu sous le nom d' ouverture passive ou aussi d' écoute .

Si un client veut établir une connexion, il crée sa propre socket à partir de son adresse d'ordinateur et de son propre numéro de port encore libre. Une connexion peut alors être établie à l'aide d'un port connu et de l'adresse du serveur. Une connexion TCP est clairement identifiée par les 4 valeurs suivantes :

• Adresse IP source
• Port source
• Adresse IP de destination
• Le port de destination

Lors de la phase de transfert de données ( active open ), les rôles de client et de serveur (d'un point de vue TCP) sont totalement symétriques. En particulier, chacun des deux ordinateurs impliqués peut initier une suppression de connexion.

Connexions semi-fermées

La connexion peut être interrompue de deux manières : des deux côtés ou progressivement unidirectionnelle. Cette dernière variante est appelée connexion semi-fermée (à ne pas confondre avec les connexions semi-ouvertes, voir ci-dessous). Il permet à l'autre côté de transférer des données après la séparation unilatérale.

Les connexions semi-fermées sont un héritage du système d' exploitation Unix , dans l'environnement duquel TCP a été créé. Conformément au principe tout est un fichier (dt. " Tout est un fichier ") prend également en charge les connexions TCP Unix. Pipes interaction complètement analogue de deux processus : pour un programme, il ne devrait être absolument pas pertinent que l'une d'une connexion TCP ou d'un fichier lise. Un programme Unix lit généralement jusqu'à la fin de l'entrée standard, puis écrit le résultat du traitement dans la sortie standard. Les flux de données standard sont liés aux fichiers avant l'exécution du programme.

Les canaux aller et retour d'une connexion TCP sont connectés aux entrées et sorties standard et sont donc logiquement représentés comme un fichier chacun. Une connexion fermée est traduite dans le processus de lecture comme une fin de fichier atteinte. Le schéma de traitement Unix typique mentionné suppose que la connexion dans le sens inverse est toujours disponible pour l'écriture après la lecture de la fin du fichier, ce qui nécessite des connexions à moitié fermées.

Connexions à moitié ouvertes

Une connexion est à moitié ouverte si un côté tombe en panne sans que le côté restant ne le sache. Cela a pour effet indésirable que les ressources du système d'exploitation ne sont pas libérées. Des connexions semi-ouvertes peuvent survenir car des connexions TCP du côté protocole existent jusqu'à ce qu'elles soient effacées. Cependant, des précautions appropriées sont souvent prises du côté de l'application.

Établissement de la connexion

Le client qui veut établir une connexion envoie au serveur un paquet SYN (de l' anglais Synchronize ) avec un numéro de séquence x . Les numéros de séquence sont importants pour assurer une transmission complète dans le bon ordre et sans doublons. C'est un paquet dont le bit SYN est positionné dans l'en-tête du paquet (voir en- tête TCP ). Le numéro de séquence de début est un nombre quelconque, dont la génération dépend de l'implémentation TCP respective. Cependant, il doit être aussi aléatoire que possible pour éviter les risques de sécurité.

Le serveur (voir croquis) reçoit le colis. Si le port est fermé, il répond par un TCP-RST pour signaler qu'aucune connexion ne peut être établie. Si le port est ouvert, il confirme la réception du premier paquet SYN et accepte l'établissement de la connexion en renvoyant un paquet SYN/ACK ( ACK de l'anglais acknowledgement 'confirmation'). Le drapeau ACK défini dans l'en-tête TCP identifie ces paquets, qui contiennent le numéro de séquence x + 1 du paquet SYN dans l'en-tête. En retour, il envoie également son numéro de séquence de début y , qui est également arbitraire et indépendant du numéro de séquence de début du client.

Le client confirme finalement la réception du paquet SYN / ACK en envoyant son propre paquet ACK avec le numéro de séquence x + 1 . Ce processus est également appelé « accusé de réception avant ». Pour des raisons de sécurité, le client renvoie la valeur y + 1 (le numéro de séquence du serveur + 1) dans le segment ACK. La connexion est maintenant établie. L'exemple suivant montre le processus de manière abstraite :

1.	SYN-ENVOYÉ	→	<SEQ = 100> <CTL = SYN>	→	SYN-REÇU
2.	SYN / ACK-REÇU	←	<SEQ = 300> <ACK = 101> <CTL = SYN, ACK>	←	SYN / ACK-ENVOYÉ
3.	ACK-ENVOYÉ	→	<SEQ = 101> <ACK = 301> <CTL = ACK>	→	ÉTABLI

Une fois établie, la connexion a des droits égaux pour les deux partenaires de communication, il n'est pas possible de voir qui est le serveur et qui est le client d'une connexion existante au niveau TCP. Par conséquent, une distinction entre ces deux rôles n'est plus pertinente dans un examen plus approfondi.

Coupure

La déconnexion régulée s'effectue de la même manière. Au lieu du bit SYN, le bit FIN est (de l'anglais. Finish end ',' final ') est utilisé, ce qui indique qu'aucune autre donnée ne vient de l'émetteur. La réception du colis est à nouveau confirmée par ACK. Le destinataire du paquet FIN envoie finalement un paquet FIN, qui lui est également confirmé.

De plus, une procédure raccourcie est possible dans laquelle FIN et ACK sont hébergés dans le même package, tout comme lors de l'établissement d'une connexion. La durée de vie maximale d'un segment (MSL) est la durée maximale qu'un segment peut passer sur le réseau avant d'être supprimé. Une fois le dernier ACK envoyé, le client passe à un état d'attente de deux MSL , dans lequel tous les segments retardés sont rejetés. Cela garantit que les segments en retard ne peuvent pas être mal interprétés comme faisant partie d'une nouvelle connexion. Une terminaison correcte de la connexion est également garantie. Si ACK y + 1 est perdu, le temporisateur du serveur expire et le segment LAST_ACK est retransmis.

amortir

Lors de l'envoi de données via TCP, deux tampons sont utilisés. Côté émetteur, l'application transmet les données à envoyer au TCP, qui met en mémoire tampon les données afin d'envoyer plus efficacement plusieurs petites transmissions sous la forme d'une seule grande. Une fois les données transmises au destinataire, elles se retrouvent dans la mémoire tampon du destinataire. Celui-ci poursuit des objectifs similaires. Si plusieurs paquets individuels ont été reçus par le TCP, il est préférable de les transmettre à l'application en combinaison.

Poignée de main à trois

Lors de l'établissement et de la déconnexion de la connexion, les réponses au premier paquet SYN ou FIN sont généralement combinées en un seul paquet (SYN / ACK ou FIN / ACK) - théoriquement, l'envoi de deux paquets séparés serait également envisageable. Étant donné que dans ce cas, seuls trois colis doivent être envoyés, on parle souvent de ce que l'on appelle la poignée de main à trois . La combinaison du paquet FIN et du paquet ACK est toutefois problématique, car l'envoi d'un paquet FIN signifie « qu'aucune donnée ne suivra ». Cependant, l'expéditeur du paquet FIN peut toujours (souhaiter) recevoir des données ; on parle de liaison semi-fermée (le sens de réception est toujours ouvert alors que le sens d'émission est fermé). Ce serait B. envisageable d'envoyer le début d'une requête HTTP (requête HTTP ) directement dans le paquet SYN, d'autres données dès que la connexion a été établie, et dans le dernier paquet de requête HTTP pour fermer immédiatement la (sens d'envoi de la) connexion en utilisant FIN. En pratique, cependant, cette procédure n'est pas utilisée. Si le navigateur fermait immédiatement la connexion de cette manière, le serveur fermerait éventuellement également la connexion au lieu de répondre complètement à la demande.

Structure de l'en-tête TCP

Général

Le segment TCP se compose toujours de deux parties : l'en- tête et la charge utile (en anglais payload ). La charge utile contient les données à transmettre, qui à leur tour peuvent correspondre à des informations de protocole de la couche application, telles que HTTP ou FTP . L'en-tête contient les données nécessaires à la communication ainsi que des informations décrivant le format du fichier. La structure schématique de l'en-tête TCP est illustrée à la figure 5. Étant donné que le champ d'option n'est généralement pas utilisé, un en-tête typique a une taille de 20 octets. Les valeurs sont spécifiées dans l' ordre des octets big-endian .

Explication

Port source (2 octets)

Spécifie le numéro de port côté expéditeur.

Port de destination (2 octets)

Spécifie le numéro de port à l'extrémité de réception.

Numéro de séquence (4 octets)

Numéro de séquence du premier octet de données( byte ) de ce paquet TCP ou le numéro de séquence d'initialisation si le drapeau SYN est positionné. Après le transfert de données, il est utilisé pour trier les segments TCP, car ceux-ci peuvent arriver au destinataire dans un ordre différent.

Numéro d'accusé de réception (4 octets)

Il spécifie le numéro de séquence que l'expéditeur de ce segment TCP attend ensuite. Il n'est valide que si le drapeau ACK est défini.

Décalage des données (4 bits)

Longueur de l' en- tête TCP en blocs de 32 bits - sans les données utilisateur ( payload ). Cela montre l'adresse de début des données utilisateur.

Réservé (4 bits)

Le champ Réservé est réservé pour une utilisation future. Tous les bits doivent être à zéro.

Indicateurs de contrôle (8 bits)

Les variables à deux valeurs sont-elles définies et non définies avec les états possibles nécessaires pour identifier certains états importants pour la communication et le traitement ultérieur des données. Ce qui suit décrit les drapeaux de l'en-tête TCP et les actions à effectuer en fonction de leur statut.

CWR et ECE

sont deux indicateurs requis pour la notification explicite d'encombrement (ECN). Si le bit ECE (écho ECN) est activé, le récepteur informe l'émetteur que le réseau est surchargé et que le débit de transmission doit être réduit. Si l'émetteur l'a fait, il en informe le récepteur en mettant à 1 le bit CWR ( Congestion Window Reduced ).

URG

Si l'indicateur Urgent (= urgent urgent) est défini, les données seront traitées immédiatement après l'en-tête par l'application. L'application interrompt le traitement des données du segment TCP en cours et lit tous les octets après l'en-tête jusqu'à l'octet vers lequel pointe le champ de pointeur urgent . Cette procédure est étroitement liée à une interruption logicielle . Ce drapeau peut être utilisé, par exemple, pour annuler une application sur le récepteur. La procédure est très rarement utilisée, les exemples sont le traitement préféré de CTRL-C (abandon) pour une connexion de terminal via rlogin ou telnet .

En règle générale, ce drapeau n'est pas évalué.

ACK

Le drapeau d' accusé de réception , en conjonction avec le numéro d' accusé de réception , a pour tâche de confirmer la réception des segments TCP pendant le transfert de données. Le numéro d' accusé de réception n'est valide que si le drapeau est activé.

PSH

RFC 1122 et RFC 793 spécifient le drapeau push de telle manière que lorsque le drapeau est défini, les tampons sortants et entrants sont contournés. Étant donné qu'avec TCP, aucun datagramme n'est envoyé, mais un flux de données, le drapeau PSH permet de traiter le flux plus efficacement, car l'application réceptrice peut être réveillée de manière plus ciblée et n'a pas à découvrir pour chaque segment de données entrant qui certaines parties des données n'ont pas encore été reçues, ce qui serait toutefois nécessaire pour pouvoir continuer.

Ceci est utile si, par exemple, vous souhaitez envoyer une commande au destinataire lors d'une session Telnet . Si cette commande devait être stockée temporairement dans le buffer, elle serait traitée avec un (fort) retard.

Le comportement du drapeau PSH peut différer de l'explication ci-dessus, selon l'implémentation TCP.

TVD

L' indicateur de réinitialisation est utilisé lorsqu'une connexion doit être interrompue. Cela arrive, par exemple, en cas de problèmes techniques ou pour rejeter des connexions non souhaitées (comme des ports non ouverts, ici - contrairement à UDP - aucun paquet ICMP avec "Port Unreachable" n'est envoyé).

SYN

Les paquets avec le drapeau SYN établissent une connexion. Le serveur répond généralement soit avec SYN + ACK lorsqu'il est prêt à accepter la connexion, sinon avec RST. Utilisé pour synchroniser les numéros de séquence lors de l'établissement d'une connexion (d'où le nom SYN).

AILETTE

Ce drapeau final ( finish ) est utilisé pour libérer la connexion et indique qu'il n'y a plus de données en provenance de l'émetteur. Les drapeaux FIN et SYN ont des numéros de séquence afin qu'ils soient traités dans le bon ordre.

(Recevoir) Fenêtre (2 octets)

Est - après multiplication avec le facteur d' échelle de fenêtre - le nombre d' octets de données ( octets ), en commençant par l' octet de données indiqué par le champ d'accusé de réception , que l'expéditeur de ce paquet TCP est prêt à recevoir.

Somme de contrôle (2 octets)

La somme de contrôle est utilisée pour détecter les erreurs de transmission et est calculée à l'aide de l'en-tête TCP, des données et d'un pseudo-en-tête. Cet en-tête se compose de l'IP de destination, de l'IP source, de l'identifiant du protocole TCP (0x0006) et de la longueur de l'en-tête TCP incluant les données utilisateur (en octets).

Pointeur urgent (2 octets)

Avec le numéro de séquence, cette valeur indique la position du premier octet après les données urgentes dans le flux de données. Les données urgentes commencent immédiatement après l'en-tête. La valeur n'est valide que si l'indicateur URG est défini.

Options (0-40 octets)

Le champ d'option varie en taille et contient des informations supplémentaires. Les options doivent être un multiple de 32 bits. S'ils ne le sont pas, ils doivent être remplis de bits zéro ( padding ). Ce champ permet de négocier des données de connexion qui ne sont pas contenues dans l'en-tête TCP, comme la taille maximale du champ de données utilisateur.

Transfert de données

Taille du segment TCP/IP

Un segment TCP a généralement une taille maximale de 1500 octets. Cependant, un segment TCP doit s'intégrer dans la couche de transmission sous-jacente, le protocole Internet (IP) ; voir également Unité de transmission maximale (MTU).

Les paquets IP, quant à eux, sont théoriquement spécifiés jusqu'à 65 535 octets (64  KiB ), mais sont eux-mêmes généralement transmis via Ethernet , et avec Ethernet la taille des données utilisateur (couche 3) (si l'on fait abstraction des trames jumbo ) est de 64 (éventuellement avec remplissage) jusqu'à 1500 octets. Les protocoles TCP et IP définissent chacun un en-tête d'une taille de 20 octets. Pour les données utilisateur (d'application), il reste 1460 octets dans un paquet TCP / IP (= 1500 octets Ethernet [données utilisateur] - 20 octets de données d'en-tête TCP - 20 octets de données d'en-tête IP). Étant donné que la plupart des connexions Internet utilisent DSL , le protocole point à point (PPP) est également utilisé entre IP et Ethernet, qui utilise 8 octets supplémentaires pour la trame PPP. Les données utiles sont donc réduites à un total de 1500 - 20 - 20 - 8 = 1452 octets MSS (taille de segment maximale). Cela correspond à un taux de données utilisateur maximal de 96,8 %.

Répartition des données applicatives sur segments TCP/IP

Le destinataire et l'expéditeur se mettent d'accord sur la taille du MSS via le champ d'option avant l'échange de données . L'application qui souhaite envoyer des données, comme un serveur Web, stocke, par exemple, un bloc de données de 7 kilo-octets dans le tampon. Afin d'envoyer 7 kilo-octets de données avec un champ de données utilisateur de 1460 octets, le logiciel TCP divise les données en plusieurs paquets, ajoute un en-tête TCP et envoie les segments TCP. Ce processus est appelé segmentation. Le bloc de données dans la mémoire tampon est divisé en cinq segments (voir Fig. 6). Chaque segment reçoit un en-tête TCP du logiciel TCP. Les segments TCP sont envoyés les uns après les autres. Ceux-ci n'arrivent pas nécessairement au destinataire dans le même ordre qu'ils ont été envoyés, car chaque segment TCP peut emprunter un chemin différent sur Internet. Chaque segment est numéroté afin que le logiciel TCP du récepteur puisse à nouveau trier les segments. Le numéro de séquence est utilisé lors de l'attribution des segments dans le récepteur.

Le logiciel TCP du destinataire confirme les segments TCP qui sont arrivés correctement (c'est-à-dire avec la somme de contrôle correcte). Dans le cas contraire, les packages seront à nouveau demandés.

Exemple de transmission de données TCP/IP

L'expéditeur envoie son premier segment TCP avec un numéro de séquence SEQ = 1 (varie) et une longueur de données utile de 1460 octets au destinataire. Le destinataire le confirme avec un en-tête TCP sans données avec ACK = 1461 et demande ainsi le deuxième segment TCP de l'octet numéro 1461 à l'expéditeur. Celui-ci l'envoie ensuite au destinataire avec un segment TCP et SEQ = 1461. Cela le confirme à nouveau avec un ACK = 2921 et ainsi de suite. Le destinataire n'a pas besoin d'accuser réception de chaque segment TCP s'ils sont contigus. S'il reçoit les segments TCP 1 à 5, il n'a besoin de confirmer que le dernier segment TCP. Par exemple, si le segment TCP 3 est manquant parce qu'il a été perdu, il ne peut que confirmer 1 et 2, mais pas encore 4 et 5. Comme l'expéditeur ne reçoit pas de confirmation pour le 3, son minuteur expire et il envoie à nouveau le 3. Si le 3 arrive au récepteur, il confirme les cinq segments TCP, à condition que les deux côtés prennent en charge l'option TCP SACK (Selective ACK). L'expéditeur démarre un temporisateur de retransmission pour chaque segment TCP qu'il envoie pendant le trajet.

Minuterie de retransmission

Pour déterminer quand un paquet a été perdu dans le réseau, l'expéditeur utilise un délai d' attente pendant lequel l'ACK de l'autre côté doit être arrivé. Si le délai d'attente est trop court, les paquets qui sont réellement arrivés correctement sont répétés ; Si le timeout est trop élevé, le paquet à répéter sera envoyé inutilement en retard en cas de pertes réelles. En raison des différents temps de transit des paquets IP sous-jacents, seul un temporisateur adapté de manière dynamique à la connexion a du sens. Les détails sont énoncés dans la RFC 6298 comme suit :

• Le timeout (RTO = retransmission timeout) est calculé à partir de deux variables d'état portées par l'émetteur :
  • le temps d'aller-retour estimé (SRTT = RTT lissé)
  • ainsi que leur variance (RTTVAR).
• Initialement, on estime que RTO = 1s (afin de créer une compatibilité avec l'ancienne version du document, des valeurs> 1s sont également possibles.)
• Après avoir mesuré le RTT du premier paquet envoyé, le paramètre suivant est défini :
  • SRTT : = RTT
  • RTTVAR : = 0,5 * RTT
  • RTO : = RTT + 4 * RTTVAR (Si 4 * RTTVAR est inférieur à la précision de mesure de la minuterie, celui-ci est ajouté à la place.)
• A chaque nouvelle mesure du RTT' les valeurs sont mises à jour (ici RTTVAR doit être calculé avant SRTT) :
  • RTTVAR : = (1-β) * RTTVAR + * |SRTT - RTT '| (La variance est également lissée avec un facteur ; puisque la variance indique un écart moyen (qui est toujours positif), le montant de l'écart entre le RTT estimé et réel est utilisé ici, pas la simple différence. Il est recommandé que = 1/4 à sélectionner.)
  • SRTT : = (1-α) * SRTT + α * RTT '(Le nouveau RTT' n'est pas simplement défini, mais il est lissé avec un facteur α. Il est recommandé de choisir α = 1/8.)
  • RTO : = SRTT + 4 * RTTVAR (Si 4 * RTTVAR est inférieur à la précision de mesure du temporisateur, celui-ci est ajouté à la place. Une valeur minimale de 1 s s'applique au RTO - quel que soit le calcul ; une valeur maximale peut également être attribué, à condition que ce soit au moins 60 s.)

En choisissant des puissances de 2 (4 ou 1/2, 1/4 etc.) comme facteurs, les calculs dans la mise en œuvre peuvent être effectués en utilisant de simples opérations de décalage .

Pour mesurer le RTT, il faut utiliser l' algorithme de Karn de Phil Karn ; ré. Cela signifie que seuls les paquets sont utilisés pour la mesure, dont la confirmation arrive sans que le paquet n'ait été renvoyé entre-temps. La raison en est que s'il devait être retransmis, il ne serait pas clair lequel des paquets envoyés à plusieurs reprises a été effectivement confirmé, de sorte qu'une déclaration sur le RTT n'est en fait pas possible.

Si un paquet n'a pas été confirmé dans le délai imparti, le RTO est doublé (à condition qu'il n'ait pas encore atteint la limite supérieure facultative). Dans ce cas, les valeurs trouvées pour SRTT et RTTVAR peuvent (également facultativement) être réinitialisées à leur valeur initiale, car elles pourraient éventuellement interférer avec le recalcul du RTO.

Relation entre le contrôle de flux et le contrôle de congestion

Les deux sections suivantes expliquent les concepts TCP pour le contrôle de flux et le contrôle d'encombrement (ou contrôle d'encombrement). La fenêtre glissante et la fenêtre de congestion sont introduites. L'expéditeur sélectionne le minimum des deux fenêtres comme taille réelle de la fenêtre de transmission. Les protocoles dits ARQ (Automatic Repeat reQuest) sont utilisés pour assurer une transmission fiable des données par retransmission .

Contrôle de flux

Au fur et à mesure que l'application lit les données du tampon, le niveau du tampon change constamment. Il est donc nécessaire de contrôler le flux de données en fonction du niveau de remplissage. Cela se fait avec la fenêtre coulissante et sa taille. Comme le montre la figure 8, nous étendons la mémoire tampon de l'émetteur à 10 segments. Sur la figure 8a, les segments 1 à 5 sont actuellement transmis. La transmission est comparable à la figure 7. Bien que le tampon du récepteur sur la figure 7 soit plein à la fin, il demande les données suivantes de l'octet 7301 à l'expéditeur avec ACK = 7301. Par conséquent, le destinataire ne peut plus traiter le prochain segment TCP. Les exceptions, cependant, sont les segments TCP avec le drapeau URG défini. Avec le champ fenêtre , il peut dire à l'expéditeur qu'il ne doit plus envoyer de données. Cela se fait en entrant la valeur zéro dans le champ de la fenêtre (fenêtre zéro). La valeur zéro correspond à l'espace libre dans le buffer. L'application réceptrice lit maintenant les segments 1 à 5 de la mémoire tampon, ce qui libère à nouveau 7 300 octets de mémoire. Il peut ensuite demander les segments restants 6 à 10 à l'expéditeur avec un en-tête TCP qui contient les valeurs SEQ = 1, ACK = 7301 et Window = 7300. L'expéditeur sait maintenant qu'il peut envoyer un maximum de cinq segments TCP au destinataire et déplace la fenêtre de cinq segments vers la droite (voir Fig. 8b). Les segments 6 à 10 sont désormais tous envoyés ensemble sous forme de rafale . Si tous les segments TCP arrivent au récepteur, il les accuse de réception avec SEQ = 1 et ACK = 14601 et demande les données suivantes.

Syndrome de la fenêtre stupide

Le récepteur envoie une fenêtre zéro à l'émetteur car sa mémoire tampon est pleine. Cependant, l'application du destinataire ne lit que deux octets du tampon. Le destinataire envoie un en-tête TCP avec Window = 2 (Window Update) à l'expéditeur et demande les deux octets en même temps. L'expéditeur se conforme à la demande et envoie les deux octets dans un paquet de 42 octets (avec en-tête IP et en-tête TCP) au destinataire. Cela signifie que la mémoire tampon du récepteur est à nouveau pleine et qu'il envoie à nouveau une fenêtre zéro à l'expéditeur. Par exemple, l'application lit maintenant cent octets dans le tampon. Le destinataire envoie à nouveau un en-tête TCP avec une petite valeur de fenêtre à l'expéditeur. Ce jeu continue encore et encore et gaspille de la bande passante car seuls de très petits paquets sont envoyés. La solution de Clark est que le destinataire envoie une fenêtre zéro et doit attendre avec la mise à jour de la fenêtre jusqu'à ce que l'application ait lu au moins la taille de segment maximale (taille de segment maximale, dans nos exemples précédents 1460 octets) à partir du tampon ou que le tampon soit à moitié vide - selon la première éventualité (Dave Clark, 1982). L'expéditeur peut également envoyer des paquets trop petits et ainsi gaspiller de la bande passante. Ce fait est éliminé avec l' algorithme de Nagle . C'est pourquoi il se complète avec la solution de Clark.

Contrôle de la congestion

Sur Internet, dans lequel de nombreux réseaux aux propriétés différentes sont connectés, la perte de données de paquets individuels est tout à fait normale. Si une connexion est fortement chargée, de plus en plus de paquets sont rejetés et doivent être répétés en conséquence. La répétition à son tour augmente la charge, sans mesures appropriées, il y aura une congestion des données.

Le taux de perte est surveillé en permanence par un réseau IP . En fonction du taux de perte, le taux de transmission est influencé par des algorithmes adaptés : Normalement, une connexion TCP/IP est démarrée lentement (démarrage lent) et le taux de transmission est progressivement augmenté jusqu'à ce que les données soient perdues. La perte de données réduit le taux de transmission, sans perte, il est à nouveau augmenté. Dans l'ensemble, le débit de données s'approche initialement du maximum respectif disponible, puis y reste approximativement. La surcharge est évitée.

Algorithme de contrôle de surcharge

Si des paquets sont perdus à une certaine taille de fenêtre, cela peut être déterminé si l'expéditeur ne reçoit pas d'accusé de réception (ACK) dans un certain temps ( timeout ). Il faut supposer que le paquet a été rejeté par un routeur du réseau en raison d'une charge réseau excessive . Cela signifie que la mémoire tampon d'un routeur est pleine ; c'est, pour ainsi dire, un embouteillage dans le réseau. Afin de résoudre la congestion, tous les émetteurs participants doivent réduire la charge de leur réseau. À cette fin, quatre algorithmes sont définis dans la RFC 2581 : démarrage lent , évitement d'encombrement , retransmission rapide et récupération rapide , le démarrage lent et l' évitement d'encombrement étant utilisés ensemble. Les deux algorithmes de retransmission rapide et de récupération rapide sont également utilisés ensemble et sont une extension des algorithmes de démarrage lent et d' évitement d'encombrement .

Démarrage lent et évitement de la congestion

Au début d'une transmission de données, l'algorithme de démarrage lent est utilisé pour déterminer la fenêtre de congestion (littéralement : fenêtre de surcharge) afin d'éviter une éventuelle situation de surcharge. Vous voulez éviter les embouteillages, et comme la charge actuelle du réseau n'est pas connue, vous commencez avec de petites quantités de données. L'algorithme commence par une petite fenêtre d'un MSS (Maximum Segment Size) dans laquelle les paquets de données sont transmis de l'émetteur au récepteur.

Le destinataire renvoie maintenant un accusé de réception (ACK) à l'expéditeur. Pour chaque ACK reçu, la taille de la fenêtre de congestion est augmentée d'un MSS. Étant donné qu'un ACK est envoyé pour chaque paquet envoyé si le transfert est réussi, cela conduit à un doublement de la fenêtre de congestion dans un temps d'aller-retour. Il y a donc une croissance exponentielle à ce stade. Si la fenêtre par exemple, l'envoi de deux paquets est autorisé, l'expéditeur reçoit deux ACK et augmente donc la fenêtre de 2 à 4. Cette croissance exponentielle se poursuit jusqu'à ce que le seuil dit de démarrage lent soit atteint (Engl. Threshold , Threshold') . La phase de croissance exponentielle est également appelée phase de démarrage lent .

Après cela, la fenêtre d'encombrement n'est augmentée que d'un MSS si tous les paquets ont été transmis avec succès depuis la fenêtre. Il n'augmente donc que d'un MSS par temps d'aller-retour, c'est-à-dire uniquement de manière linéaire. Cette phase est connue sous le nom de phase d'évitement de la congestion . La croissance est arrêtée lorsque la fenêtre de réception spécifiée par le récepteur est atteinte (voir contrôle de flux).

Si un délai d'attente se produit, la fenêtre d'encombrement est remise à 1 et le seuil de démarrage lent est réduit à la moitié de la taille du vol (la taille du vol est le nombre de paquets qui ont été envoyés mais pas encore acquittés). La phase de croissance exponentielle est ainsi raccourcie, de sorte que la fenêtre ne croît que lentement en cas de pertes de paquets fréquentes.

Retransmission rapide et récupération rapide

La retransmission rapide et la récupération rapide (« récupération rapide ») sont utilisées pour réagir plus rapidement à la situation d'encombrement après la perte d'un paquet. Pour ce faire, un récepteur informe l'expéditeur si des paquets arrivent hors séquence et qu'il y a donc une perte de paquets entre les deux. Pour ce faire, le destinataire confirme à nouveau le dernier colis correct pour chaque colis supplémentaire qui arrive dans le désordre. On parle de Dup-Acks ( double acquittement ), c'est-à - dire plusieurs messages successifs qui ACKen le même segment de données. L'expéditeur remarque les accusés de réception dupliqués et après le troisième duplicata, il renvoie immédiatement le paquet perdu avant l'expiration du délai. Comme il n'est pas nécessaire d'attendre l'expiration du timer, le principe est appelé Fast Retransmit . Les Dup-Acks indiquent également que bien qu'un paquet ait été perdu, les paquets suivants sont arrivés. Par conséquent, la fenêtre de transmission n'est réduite de moitié qu'après l'erreur et ne redémarre pas avec un démarrage lent comme avec le délai d'attente. De plus, la fenêtre de transmission peut être augmentée du nombre de Dup-Acks, car chacun représente un autre paquet qui a atteint le destinataire, bien que hors séquence. Étant donné que cela signifie que la pleine puissance de transmission peut être à nouveau atteinte plus rapidement après l'erreur, le principe est appelé récupération rapide .

ACK sélectifs (SACK)

Les ACK sélectifs sont utilisés pour renvoyer plus d'informations de contrôle sur le flux de données du récepteur à l'expéditeur. Après la perte d'un paquet, le destinataire insère un en-tête supplémentaire dans le champ d'option TCP, à partir duquel l'expéditeur peut voir exactement quels paquets sont déjà arrivés et lesquels sont manquants (contrairement aux ACK cumulatifs standard de TCP, voir ci-dessus). Les paquets ne sont toujours considérés comme confirmés que lorsque le destinataire a envoyé à l'expéditeur un ACK pour les paquets.

TCP-Tahoe et TCP-Reno

Les variantes de contrôle de congestion TCP Tahoe et Reno , nommées d' après des emplacements dans le Nevada , sont deux méthodes différentes de la façon dont TCP réagit à un événement de surcharge sous la forme de délais d' attente ou de dup-acks .

Le TCP Tahoe désormais plus utilisé réduit la fenêtre de congestion pour la prochaine unité de transmission à 1 dès qu'il y a un timeout. Ensuite, le processus de démarrage lent TCP recommence (avec un seuil réduit, voir ci-dessous) jusqu'à un nouveau timeout ou DUP ACKs l'événement se produit ou la valeur seuil ( seuil ) pour la transition vers la phase d'évitement de congestion est atteinte. Cette valeur de seuil a été fixée à la moitié de la taille de la fenêtre d'encombrement actuelle après l'événement de surcharge. L'inconvénient de cette procédure est, d'une part, qu'une perte de paquets n'est détectée que par un timeout, ce qui prend parfois beaucoup de temps, et d'autre part, la forte réduction de la fenêtre de congestion à 1.

Le développement ultérieur de Tahoe est TCP-Reno. Une distinction est faite ici entre les événements de timeout et les dup-acks : alors que TCP-Reno procède de la même manière que TCP Tahoe lorsqu'un timeout se produit, il utilise une variante différente pour déterminer la fenêtre de congestion suivante lorsque trois doubles ack se produisent. L'idée de base est que la perte d'un segment sur le chemin du destinataire peut être reconnue non seulement par un timeout, mais aussi par le destinataire renvoyant plusieurs fois les mêmes ACK pour le segment immédiatement avant le segment perdu (à chaque fois qu'il reçoit un autre segment après le "gap"). La fenêtre de congestion suivante est donc fixée à la moitié de la valeur de la fenêtre de congestion au moment de l'événement de surcharge ; puis la phase d'évitement de la congestion est rétablie. Comme mentionné dans l'article ci-dessus, ce comportement est décrit comme une récupération rapide .

Le contrôle des surcharges comme domaine de recherche

La conception exacte du contrôle de surcharge TCP était et est un domaine de recherche extrêmement actif avec de nombreuses publications scientifiques. Même aujourd'hui, de nombreux scientifiques du monde entier travaillent à l'amélioration du contrôle de la surcharge TCP ou tentent de l'adapter à certaines conditions externes. Dans ce contexte, il convient de mentionner en particulier les conditions particulières des différentes technologies de transmission sans fil, qui conduisent souvent à des délais de propagation longs ou fortement fluctuants ou à des pertes de paquets élevées. En cas de perte de paquets, TCP suppose par défaut que le chemin de transmission est occupé à un moment donné (encombrement des données). C'est surtout le cas avec les réseaux filaires, car les paquets sont rarement perdus sur la ligne , mais les paquets qui ne sont pas arrivés sont presque toujours rejetés par un routeur surchargé. La bonne réaction à une telle « congestion de données » est donc de réduire le débit de transmission. Cependant, cette hypothèse ne s'applique plus aux réseaux sans fil. En raison du support de transmission beaucoup plus peu fiable, les pertes de paquets se produisent souvent sans qu'un des routeurs ne soit surchargé. Dans ce scénario, cependant, réduire le taux d'envoi n'a pas de sens. Au contraire, augmenter le débit de transmission, par exemple en envoyant plusieurs paquets, pourrait augmenter la fiabilité de la connexion.

Souvent, ces modifications ou extensions du contrôle de surcharge sont basées sur des bases mathématiques ou techniques de contrôle complexes. La conception des améliorations correspondantes est tout sauf facile, car il est généralement nécessaire que les connexions TCP avec des mécanismes de contrôle de congestion plus anciens ne soient pas significativement désavantagées par les nouvelles méthodes, par exemple si plusieurs connexions TCP « se battent » pour la bande passante sur un support partagé. Pour toutes ces raisons, le contrôle de congestion TCP utilisé en réalité est également rendu beaucoup plus compliqué qu'il n'est décrit plus haut dans l'article.

En raison des nombreuses recherches sur le contrôle de surcharge TCP, divers mécanismes de contrôle de surcharge se sont imposés comme des quasi-standards au fil du temps. En particulier, TCP Reno , TCP Tahoe et TCP Vegas doivent être mentionnés ici.

Dans ce qui suit, certaines approches plus récentes ou plus expérimentales seront brièvement décrites à titre d'exemple. Une approche est, par exemple, RCF (Router Congestion Feedback). Le routeur envoie des informations plus complètes aux expéditeurs ou récepteurs TCP le long du chemin afin qu'ils puissent mieux coordonner leur contrôle d'encombrement de bout en bout. En conséquence, il a été prouvé que des augmentations considérables du débit sont possibles. Des exemples de ceci peuvent être trouvés dans la littérature sous les mots-clés XCP ( protocole de contrôle explicite ), EWA ( adaptation de fenêtre explicite ), FEWA ( fuzzy EWA ), FXCP ( fuzzy XCP ) et ETCP (Enhanced TCP ) (statut : mi-2004) . De plus, la notification explicite d'encombrement (ECN) est une implémentation d'une RFC. En termes simples, ces méthodes simulent un contrôle de surcharge de type ATM .

D'autres approches poursuivent la séparation logique de la boucle de contrôle d'une connexion TCP en deux ou plusieurs boucles de contrôle aux points cruciaux du réseau (par exemple avec ce que l'on appelle le TCP divisé ). Il existe également la méthode consistant à regrouper logiquement plusieurs connexions TCP dans un expéditeur TCP afin que ces connexions puissent échanger des informations sur l'état actuel du réseau et réagir plus rapidement. La méthode EFCM ( Ensemble Flow Congestion Management ) doit être mentionnée ici en particulier . Tous ces processus peuvent être résumés sous le terme Network Information Sharing .

Somme de contrôle TCP et pseudo-en-têtes TCP

Le pseudo-en-tête est une combinaison de parties d'en-tête d'un segment TCP et de parties de l'en-tête du paquet IP d'encapsulation. C'est un modèle sur lequel le calcul de la somme de contrôle TCP ( la somme de contrôle en anglais peut être décrite graphiquement).

Si IP est utilisé avec TCP, il est souhaitable d'inclure l'en- tête du paquet IP dans la sauvegarde de TCP. Cela garantit la fiabilité de sa transmission. C'est pourquoi le pseudo-en-tête IP est créé. Il se compose de l'adresse IP de l'expéditeur et du destinataire, d'un octet zéro, d'un octet qui spécifie à quel protocole appartiennent les données utilisateur du paquet IP et la longueur du segment TCP avec l'en-tête TCP. Étant donné que le pseudo-en-tête implique toujours des paquets IP qui transportent des segments TCP, cet octet est défini sur la valeur 6. Le pseudo en-tête est placé devant l'en-tête TCP pour le calcul de la somme de contrôle. La somme de contrôle est ensuite calculée. La somme est stockée dans le champ "checksum" et le fragment est envoyé. Aucun pseudo-en-tête n'est jamais envoyé.

pseudo-en-tête TCP (IPv4)

Décalage de bits	Bits 0-3				4-7				8-15								16-31
0	Adresse IP de l'expéditeur
32	Adresse IP du destinataire
64	00000000								6 (=TCP)								Longueur TCP
96	Port source																Le port de destination
128	Numéro de séquence
160	Numéro d'accusé de réception
192	Décalage des données				Réservé				Drapeaux								La fenêtre
224	Somme de contrôle																Pointeur urgent
256	Options (facultatif)
256/288 +	Données

Le calcul de la somme de contrôle pour IPv4 est défini dans la RFC 793 :

La somme de contrôle est le complément à un de 16 bits de la somme des compléments à un de tous les mots de 16 bits dans l'en-tête et la charge utile du protocole sous-jacent. Si un segment contient un nombre impair d'octets, un octet de remplissage est ajouté. Le rembourrage n'est pas transmis. Lors du calcul de la somme de contrôle, le champ de somme de contrôle lui-même est rempli de zéros.

Contrairement à cela, le pseudo-en-tête pour IPv6 selon RFC 2460 se présente comme suit :

« Tout protocole de transport ou autre protocole de couche supérieure qui inclut les adresses de l'en-tête IP dans son calcul de somme de contrôle doit être modifié pour une utilisation sur IPv6, pour inclure les adresses IPv6 128 bits au lieu des adresses IPv4 32 bits. "

pseudo-en-tête TCP pour IPv6

Décalage de bits	0-7								8-15								16-23								24-31
0	Adresse source
32
64
96
128	Adresse de destination
160
192
224
256	Longueur TCP
288	Valeurs zéro																								En-tête suivant
320	Port source																Le port de destination
352	Numéro de séquence
384	Numéro d'accusé de réception
416	Décalage des données				Réservé				Drapeaux								La fenêtre
448	Somme de contrôle																Pointeur urgent
480	Options (facultatif)
480/512 +	Données

Le destinataire crée également le pseudo-en-tête, puis effectue le même calcul sans définir le champ de somme de contrôle à zéro. Cela devrait rendre le résultat FFFF ( hexadécimal ). Si ce n'est pas le cas, le segment TCP est rejeté sans message. En conséquence, le temporisateur RTT de l'expéditeur expire et le segment TCP est à nouveau envoyé.

La raison de cette procédure compliquée est que des parties de l'en-tête IP changent pendant le routage dans le réseau IP. Le champ TTL est décrémenté de un à chaque saut IP. Si le champ TTL devait être inclus dans le calcul de la somme de contrôle, IP détruirait la sécurité du transport via TCP. Par conséquent, seule une partie de l'en-tête IP est incluse dans le calcul de la somme de contrôle. D'une part, en raison de sa longueur de seulement 16 bits et en raison de la règle de calcul simple, la somme de contrôle est susceptible d'erreurs indétectables. De meilleures méthodes comme CRC-32 ont été considérées comme trop laborieuses au moment de la définition.

Intégrité et fiabilité des données

Contrairement à UDP sans connexion , TCP implémente un flux de données bidirectionnel, orienté octet et fiable entre deux points de terminaison. Le protocole sous-jacent ( IP ) est orienté paquet, ce qui signifie que les paquets de données peuvent se perdre, arriver dans le mauvais ordre et même être reçus deux fois. TCP a été conçu pour faire face à l'incertitude des couches sous-jacentes. Il vérifie donc l'intégrité des données grâce à la somme de contrôle dans l'en-tête du paquet et assure l'ordre grâce aux numéros de séquence . L'expéditeur répète l'envoi des paquets si aucun accusé de réception n'est reçu dans un certain laps de temps ( timeout ). Au niveau du récepteur, les données des paquets sont combinées dans un tampon dans le bon ordre pour former un flux de données et les paquets en double sont rejetés.

Le transfert de données peut bien entendu être perturbé, retardé ou complètement interrompu à tout moment après l'établissement d'une connexion. Le système de transmission s'exécute alors dans un délai d'attente. L'« établissement de la connexion » effectué en amont ne garantit donc pas une transmission ultérieure sécurisée en permanence.

Confirmation

La longueur respective du tampon, jusqu'à laquelle il n'y a pas d'espace dans le flux de données, est confirmée ( fenêtrage ). Cela signifie que la bande passante du réseau peut également être utilisée sur de longues distances. Dans le cas d'une connexion outre-mer ou satellite, l'arrivée du premier signal ACK prend parfois plusieurs 100 millisecondes pour des raisons techniques, durant lesquelles plusieurs centaines de paquets peuvent être envoyés dans certaines circonstances. L'expéditeur peut remplir la mémoire tampon du récepteur avant que le premier accusé de réception n'arrive. Tous les packages dans le tampon peuvent être confirmés ensemble. Des accusés de réception peuvent être ajoutés aux données dans l'en- tête TCP du flux de données opposé ( piggybacking ) si le destinataire a également des données prêtes pour l'expéditeur.

Voir également

• CYCLADES - Le modèle pour TCP avec son datagramme CIGALE.
• Liste des ports standardisés
• Protocole de transmission de contrôle de flux (SCTP)

Littérature

• Douglas Comer : Interconnexion avec TCP/IP. Principes, protocoles et architectures. Prentice Hall, 2000, ISBN 0-13-018380-6 .
• Craig Hunt : Administration du réseau TCP/IP. O'Reilly, Pékin 2003, ISBN 3-89721-179-3 .
• Richard Stevens : TCP/IP illustré. Tome 1. Les protocoles . Addison-Wesley, Boston 1994, 2004. ISBN 0-201-63346-9 .
• Richard Stevens : TCP/IP illustré. Volume 2. La mise en œuvre . Addison-Wesley, Boston 1994, ISBN 0-201-63354-X .
• Andrew S. Tanenbaum : Réseaux informatiques. 4e édition. Pearson Studium, Munich 2003, ISBN 978-3-8273-7046-4 , pages 580 et suivantes.
• James F. Kurose, Keith W. Ross : Réseaux informatiques. Une approche descendante axée sur Internet. problème de Bafög. Pearson Studium, Munich 2004, ISBN 3-8273-7150-3 .
• Michael Tischer, Bruno Jennrich : Stagiaire Internet. Technologie & programmation. Data-Becker, Düsseldorf 1997, ISBN 3-8158-1160-0 .

liens web

RFC

• RFC 793 (protocole de contrôle de transmission)
• RFC 1071 (calcul de la somme de contrôle pour IP, UDP et TCP)
• RFC 1122 (corrections de bogues pour TCP)
• RFC 1323 (extensions à TCP)
• RFC 2018 (TCP SACK - Options d'accusé de réception sélectif)
• RFC 3168 (Notification explicite d'encombrement)
• RFC 5482 (Option de délai d'attente utilisateur TCP)
• RFC 5681 (Contrôle d'encombrement TCP)
• RFC 7414 (aperçu des RFC TCP)

Autres

• Évitement et contrôle de la congestion (étape TCP 1988 ; PDF ; 220 ko)
• Les guerriers du net (film sur TCP)
• Introduction à TCP/IP - introduction en ligne aux protocoles TCP/IP. Heiko Holtkamp, ​​​​AG Réseaux informatiques et systèmes distribués, Faculté technique, Université de Bielefeld.

Preuve individuelle

1. A ne pas confondre avec la commutation de paquets . La tâche de TCP n'est pas de transmettre des paquets, mais les octets d'un flux de données. La commutation de paquets est assurée par le protocole Internet (IP). Par conséquent, IP est à commutation de paquets mais TCP est à commutation de paquets.
2. ↑ Les numéros de port. Internet Assigned Numbers Authority (IANA), 18 juin 2010, consulté le 7 août 2014 .  
3. ↑ RFC 793. Internet Engineering Task Force (IETF), 1981. "Une requête OPEN passive signifie que le processus veut accepter les requêtes de connexion entrantes plutôt que d'essayer d'initier une connexion."
4. ↑ RFC 793. Internet Engineering Task Force (IETF), 1981. « Brièvement, les significations des états sont : LISTEN - représente l'attente d'une demande de connexion de n'importe quel TCP et port distant.
5. ^ W. Richard Stevens : TCP/IP Illustrated, Tome 1 : Les protocoles. Addison-Wesley, chapitre 18.
6. ↑ Steven M. Bellovin : RFC 1948 - Se défendre contre les attaques par numéros de séquence . Groupe de travail sur l'ingénierie Internet (IETF), 1996
7. ↑ RFC 6298 - Calcul du temporisateur de retransmission de TCP
8. ^ Stevens, W. Richard, Allman, Mark, Paxson, Vern : TCP Congestion Control. Consulté le 9 février 2017 .