2. Introduction
La RFC 793 contient une discussion sur les objectifs de conception de TCP et fournit des exemples de son fonctionnement, y compris des exemples d'établissement de connexion (Connection Establishment), de terminaison de connexion (Connection Termination) et de retransmission de paquets (Packet Retransmission) pour réparer les pertes.
Ce document décrit la fonctionnalité de base attendue dans les implémentations TCP modernes et remplace la spécification du protocole dans la RFC 793. Il ne réplique ni ne tente de mettre à jour le contenu d'introduction et de philosophie des sections 1 et 2 de la RFC 793. D'autres documents sont référencés pour fournir des explications sur la théorie de fonctionnement, la justification et une discussion détaillée des décisions de conception. Ce document se concentre uniquement sur le comportement normatif du protocole.
La « feuille de route TCP (TCP Roadmap) » [49] fournit un guide plus étendu des RFC qui définissent TCP et décrivent divers algorithmes importants. La feuille de route TCP contient des sections sur les améliorations fortement encouragées qui améliorent les performances et d'autres aspects de TCP au-delà du fonctionnement de base spécifié dans ce document. À titre d'exemple, la mise en œuvre du contrôle de congestion (Congestion Control) (par exemple, [8]) est une exigence TCP, mais c'est un sujet complexe en soi et non décrit en détail dans ce document, car il existe de nombreuses options et possibilités qui n'affectent pas l'interopérabilité de base. De même, la plupart des implémentations TCP d'aujourd'hui incluent les extensions haute performance dans [47], mais celles-ci ne sont pas strictement requises ou discutées dans ce document. Les considérations multi-chemins (Multipath) pour TCP sont également spécifiées séparément dans [59].
Une liste des modifications par rapport à la RFC 793 est contenue dans la section 5.
2.1. Langage d'exigence (Requirements Language)
Les mots-clés « MUST » (doit), « MUST NOT » (ne doit pas), « REQUIRED » (requis), « SHALL » (doit), « SHALL NOT » (ne doit pas), « SHOULD » (devrait), « SHOULD NOT » (ne devrait pas), « RECOMMENDED » (recommandé), « NOT RECOMMENDED » (non recommandé), « MAY » (peut) et « OPTIONAL » (optionnel) dans ce document doivent être interprétés comme décrit dans le BCP 14 [3] [12] quand, et seulement quand, ils apparaissent en majuscules, comme indiqué ici.
Chaque utilisation des mots-clés RFC 2119 dans le document est individuellement étiquetée et référencée dans l'annexe B, qui résume les exigences d'implémentation.
Les phrases utilisant « MUST » sont étiquetées comme « MUST-X » avec X étant un identifiant numérique permettant de localiser facilement l'exigence lorsqu'elle est référencée depuis l'annexe B.
De même, les phrases utilisant « SHOULD » sont étiquetées avec « SHLD-X », « MAY » avec « MAY-X » et « RECOMMENDED » avec « REC-X ».
Aux fins de cet étiquetage, « SHOULD NOT » et « MUST NOT » sont étiquetés de la même manière que les instances « SHOULD » et « MUST ».
2.2. Concepts clés de TCP (Key TCP Concepts)
TCP fournit un service de flux d'octets (Byte-Stream Service) fiable (Reliable) et ordonné (In-Order) aux applications.
Le flux d'octets de l'application est transmis sur le réseau via des segments TCP (TCP Segments), chaque segment TCP étant envoyé sous forme de datagramme du protocole Internet (Internet Protocol, IP).
La fiabilité de TCP consiste à détecter les pertes de paquets (via les numéros de séquence (Sequence Numbers)) et les erreurs (via les sommes de contrôle par segment (Per-Segment Checksums)), ainsi qu'à corriger via la retransmission (Retransmission).
TCP prend en charge la livraison unicast (Unicast Delivery) des données. Il existe des applications anycast (Anycast) qui peuvent utiliser TCP avec succès sans modifications, bien qu'il existe un certain risque d'instabilité en raison de changements dans le comportement de transfert de couche inférieure [46].
TCP est orienté connexion (Connection Oriented), bien qu'il n'inclue pas intrinsèquement une capacité de détection de vivacité (Liveness Detection Capability).
Le flux de données est pris en charge de manière bidirectionnelle (Bidirectionally) sur les connexions TCP, bien que les applications soient libres d'envoyer des données uniquement de manière unidirectionnelle, si elles le choisissent.
TCP utilise des numéros de port (Port Numbers) pour identifier les services d'application (Application Services) et pour multiplexer des flux distincts (Distinct Flows) entre les hôtes.
Une description plus détaillée des fonctionnalités TCP par rapport aux autres protocoles de transport peut être trouvée dans la section 3.1 de [52]. Une description plus approfondie des motivations pour développer TCP et son rôle dans la pile de protocoles Internet peut être trouvée dans la section 2 de [16] et les versions antérieures de la spécification TCP.