Protocoles de transport

Les protocoles de transport permettent les communications entre extrémités. Les deux principaux protocoles de transport employés dans le monde IP sont TCP et UDP.

4.1 Couche de transport non fiable: UDP (User Datagram Protocol)

UDP est un protocole de niveau transport sans connexion, il assure le multiplexage des communications sur différents ports logiques. La connaissance du numéro de port du destinataire est nécessaire avant de communiquer. Un certain numéros de ports sont prédéfinis. UDP supporte la communication point à point entre deux machines, un numéro de port sera affecté à chaque extrémité.

Un total de contrôle est mis en œuvre sur l'en-tête. La communication sur un port ouvert est bidirectionnelle. UDP n'effectue ni contrôle de flux, ni contrôle d'erreurs, ni mise en ordre de messages, ni gestion de fenêtre. Les messages UDP sont reçus par groupe de données tels qu’ils sont envoyés.

4.1.1 Structure d'un datagramme UDP

Mot1                    Port UDP source, port UDP destination
Mot2                    Longueur du message UDP (16 bits), Total de contrôle (16 bits)
Mots suivants       Données
Le numéro de port destinataire désigne le processus récepteur qui devra être en attente sur le port adressé. Lors de tests faits sur un réseau local où le degré de fiabilité est élevé UDP donne de bons résultats sans précaution particulière au niveau de la programmation, il n'en va pas de même lors de communications distantes empruntant une interconnexion où des datagrammes risquent d'être perdus ou n'arrivent pas forcément dans l'ordre d'émission. Le total de contrôle est calculé de façon optionnelle il porte à la fois sur les données et un pseudo en-tête comportant les adresses IP source et destination. Le contrôle est fait par une addition XOR. Si le champ contrôle est à zéro, cela veut dire que le calcul de contrôle n'est pas effectué. La taille maximale d'un datagramme est 64Koctets, cependant la taille réelle dépend de l'implémentation de la pile IP. La taille minimum requise est de 576 octets, certaines piles ont une valeur maximum de 8192 octets.

4.1.2 Services basés sur UDP

Les services qui utilisent UDP sont du type questions-réponses et comportent peu de données . De ce fait, l'erreur ou la perte d'un datagramme sont aisément repérable par l'application à l'aide d'un mécanisme de time-out. Il s’agit également de services qui demandent une exécution rapide mais sont tolérants aux fautes tels que les transferts audio-vidéo sur Internet.
DNS        (Domain Name Service)                                        port 53
TFTP       (Trivial File Transfert Protocol)                               port 69
NFS        (Network File System) en partie                            port 2049
SNMP     (Simple Network Management Protocol)
RAT        (Real Audio Tool), transfert audio basé sur RTP/UDP   
Le client connaît à priori le port d'écoute du serveur. UDP récepteur reçoit les datagrammes tels qu'ils sont émis.

4.1.3 Encapsulation

Un processus utilisateur envoie un message sur un port  spécifique avec les niveaux d'encapsulation suivants:   
un message utilisateur; un datagramme UDP; un datagramme IP; un ou plusieurs paquets (fragments)  physiques.
Soit les en-têtes successifs: En-têtes: physique (Ethernet, TokenRing, X25, etc.) - IP - UDP - En tête application (DNS, TFTP, NFS, SNMP selon le cas) - Données utilisateur.

4.2 Couche de transport fiable: TCP (Transmission Control Protocol)

TCP est un protocole de niveau transport avec connexion équivalent à TP4 (Transport Protocol) de la norme OSI. TCP assure un service de remise fiable, c'est à dire sans perte, ni duplication. TCP est utilisable avec un grand nombre de systèmes de remise de paquets, par exemple le service de remise de datagrammes IP. TCP est donc mis en œuvre sur tous les types de supports: LL, X25, Frame Relay, Ethernet etc... L'objectif principal de TCP est d'utiliser la bande passante disponible sur le chemin suivi et de l'attribuer de façon équitable aux utilisateurs concurrents. TCP s'adapte donc au débit disponible sur le chemin emprunté.
TCP suppose que chaque segment non acquitté est perdu pour cause de congestion et ralentit donc le débit d'émission, cette hypothèse n'est pas toujours vraie, le perte pouvant être due à une erreur, par exemple dans le cas des réseaux sans fil. Pour des support avec un taux d'erreurs de niveau 2 élevé, la correction au niveau 2 est souhaitable.
TCP possède les caractéristiques essentielles suivantes:
Les mécanismes de base suivants sont implémentés par TCP : un total de contrôle, une numérotation en séquence des segments qui détecte les pertes, les duplications et les erreurs de séquencement, un acquittement par segment, une temporisation de réémission.
Une phase d'ouverture établit une connexion préalable à la communication entre les deux points d'extrémité, après cet établissement les deux ports d'extrémités sont reconnus depuis leurs stations respectives, mais non de proche en proche dans le réseau. Le chemin suivi par des segments consécutifs n'est donc pas forcément identique, mais déterminé par le routage IP. Les règles de découpage en fragments sont d'ailleurs appliquées à ces segments.
TCP découpe les messages utilisateurs en segments dont la taille est adaptée au MTU du chemin parcouru, alors qu'IP découpe en fragments adaptés au support physique local. Les connexions TCP sont bidirectionnelles. TCP émet les données sous forme de flux, les frontières des séquences ne sont pas forcément les même du côté émetteur et récepteur. C’est une autre différence entre UDP et TCP. En effet, les frontières de messages UDP arrivent inchangées chez le récepteur.
Avec TCP, la perte d'un segment est détectée par l’émetteur. Si l'acquittement n'arrive pas en un temps donné, les données manquantes sont retransmises. Comme TCP considère que les pertes sont dues à une congestion du réseau, la vitesse d’émission est ajustée pour diminuer la probabilité de perte.
TCP effectue le contrôle de flux et le contrôle de congestion. Le contrôle de flux assure qu’il n’y aura pas de perte chez le récepteur à l’aide de l’échange de la taille de fenêtre, des acquittements en séquence ou sélectifs. Le contrôle de congestion adapte le débit d'émission à la charge du réseau avec différents mécanismes: slow start, congestion detection et avoidance, fast retransmit et fast recovery, ECN.
Les données émises sont acquittées et la transmission est anticipée grâce à un mécanisme de gestion de fenêtre, les transferts sont donc tamponnés. Si toutefois l'émetteur souhaite une transmission sans attendre que le tampon d'émission ne soit plein, il force l'émission de données avec l'appel "push". Cet appel force également l'envoi de messages urgents (out of order).
Les connexions sont full duplex, en cas de communications bidirectionnelles, la technique dite du "piggy backing" réduit le trafic sur le réseau, c'est à dire que les acquittements sont renvoyés en même temps que des messages de données.
Des segments TCP successifs sont rangés dans des datagrammes IP différents. Les données échangées ne sont pas structurées, la mise en forme de l'information relève de l'application. Au démarrage, le mécanisme de slow-start évite d'inonder le réseau.

4.2.1 Structure d'un segment TCP

L'en tête TCP comprend cinq mots.
  •     Mot1    port TCP source (16 bits) ; port TCP destination (16 bits)
  •     Mot2    Numéro de séquence (numéro du premier octet du segment dans le flux d'émission)
  •     Mot3    Numéro d'accusé de réception (32 bits) (numéro du prochain octet acquitté par le récepteur)
  •     Mot4    Longueur de l'en-tête en mots de 32 bits (4 bits), Réservé (6 bits), Bits de code (6 bits), Fenêtre (16 bits)
  •     Mot5    Total de contrôle (16 bits), Pointeur d'urgence (16 bits) : pointeur des données urgentes dans le segment
  •     Mot6    Options (24 bits) Bourrage (8 bits) (optionnel)
Le champs bits de code détermine le rôle et le contenu du segment:
URG    Pointeur de données urgentes valide
ACK    Champ d'accusé de réception valide
PSH    Données à transmettre immédiatement à  l'application (PUSH)
RST    Réinitialiser la connexion, arrêt inopiné
SYN    Synchroniser les numéros de séquence, utilisé à l'initialisation de la connexion
FIN    Fin du flot d'émission
La fenêtre d'anticipation est gérée en nombre d'octets. Le nombre d'octets transmis par anticipation est limité par la taille du tampon du destinataire précisé dans le champ fenêtre.
Total de contrôle : le total de contrôle correspond à une addition complément à 1, il porte à la fois sur l'en-tête et les données. Grâce à lui le destinataire vérifie l'absence d'erreur de transmission. Ce calcul requiert une opération sur chaque mot du segment, dans certains cas, il est invalidé pour améliorer les performances. L'opération serait rapide si elle était câblée ou faite à la volée, mais la position du contrôle dans l'en-tête et non en fin de données nécessite le stockage des informations et le calcul par le processeur ce n'est qu'après le calcul que le segment est envoyé.
Il existe différentes options. Celles qui précisent les paramètres du type : MSS (maximum segment size) ou bien mise à l’échelle de la taille de la fenêtre (0..14). L’option qui demande la négociation d’acquittements sélectifs : SACK. L'option "time stamp" demande l'ajout du temps local à l'en-tête, ce temps sera renvoyé par le destinataire avec l'acquittement. La différence entre le temps au retour et la valeur de temps retournée donne le RTT à l'émetteur.

4.2.2 Applications basées sur TCP

Telnet, rlogin: connexion à distance         TCP     port 23
FTP    (File Transfert Protocol)                TCP     port 21
SMTP (Simple Mail Transfert Protocol)    TCP     port 25
POP3 (Post Office Protocol)                   TCP     port 110
IMAP                                                   TCP     port 143
Xwindow                                               TCP     port 6000

4.3 Mécanismes  de TCP

Du côté de l'émetteur :
TCP reçoit un message de la couche application et émet des segments vers la couche IP,
IP reçoit des segments de la couche TCP et émet des fragments vers la couche liaison de données, l'unité gérée par IP est le datagramme.

Du côté du récepteur :
IP reçoit des fragments de la couche liaison de données,
TCP reçoit des segments de la couche IP,
TCP envoie un segment à la couche application (quelque soit l’application, les données échangées sont vues comme des flux entrants et sortants)
Le découpage des données est donc possible au niveau d'IP ou de TCP. TCP découpe les messages en segments. La taille  des segments d'émission et de réception dépend de la taille des tampons des correspondants et du MTU du chemin emprunté.
Les désavantages du découpage sont :
  • si le contrôle est fait à un niveau supérieur, tous les éléments découpés sont à retransmettre en cas d'erreur. La probabilité de perte des fragments est non nulle, une taille de segment supérieure à celle du fragment augmente donc la probabilité de retransmission du segment. TCP connaît la taille optimale à l’aide des messages ICMP « too big » et s’adapte donc aux changements de route.
  • pour chaque élément découpé, les en-têtes réseaux et données sont ajoutés, leur surcoût relatif est donc plus important.
Au démarrage, TCP émet une requête SYN et attend une réponse du même type, ce n'est qu'ensuite que le premier segment de données sera émis, un RTT s’écoule donc avant tout envoi des données.

La connexion TCP est identifiée par les couplets : @ip émetteur et destinataire, ports émetteur et destinataire. L’adresse IP ne change donc pas en cours de communication.

4.3.1 Fenêtre glissante

Avec un protocole du type TCP, l'émetteur attend un acquittement pour toute trame émise, ce temps d'attente sera relativement long, surtout dans une interconnexion. Pour améliorer cet état de fait, TCP autorise un certain degré d'anticipation dans l'émission des données. Le concept de fenêtre glissante divise les données en trois catégories: celles émises et acquittées, celles émises et non acquittées, celles non transmises.

Comme TCP est bidirectionnel,  il gère pour une communication donnée les fenêtres d'émission et de réception de chaque extrémité. Une fenêtre est gérée à l'aide de trois pointeurs d'octets, le premier sépare les données émises et acquittées de celles en cours d'émission, le second définit le début des données qui restent à émettre et le troisième indique la limite droite des données émessible avant acquittement. Chaque accusé de réception indique le nombre d'octets correctement reçus et le champs taille du tampon de réception indique le nombre d'octets supplémentaires que le récepteur est prêt à accepter, la taille de la fenêtre TCP est donc variable. Lorsque ses tampons de réception se remplissent, le récepteur diminue la taille de la fenêtre. L'accusé de réception indique toujours le numéro du prochain octet attendu par l'émetteur de l'accusé de réception. Le numéro de séquence émis ainsi que l'accusé de réception sont codés sur 32 bits. Par contre, la taille de la fenêtre d'anticipation est codée sur 16 bits.

Avantages et inconvénients de la fenêtre glissante


  • Avec la fenêtre, l’émission anticipe les acquittements, grâce à elle l'émetteur et le récepteur ne sont donc plus asservis l'un à l'autre.
  • Avec un bon réglage de la taille de la fenêtre, le surcoût du temps d'attente des accusés de réception devient transparent.
  • La somme des données en circulation dans l'interconnexion est plus ou moins importante et détermine le risque de congestion.

4.3.2 Acquittement

Un acquittement est émis pour chaque segment reçu. En cas d’absence d’acquittement pour un segment alors que trois Ack dupliqués du segment précédent ont été reçus en tant qu'acquittements des segments suivants, TCP émetteur retransmet le segment sans attendre l’expiration d’un timer, ce mécanisme est dit retransmission rapide (Fast Retransmit). Après une retransmission rapide, le mécanisme de recouvrement rapide (fast recovery) est déclenché. La taille de la fenêtre est réduite à une demi-fenêtre de congestion (1/2 cwnd), sans pour autant enter en slow-start, l’accroissement de la taille est linéaire. Du côté TCP récepteur,  l'ensemble des segments reçus est acquitté en une fois si cela est possible. Par contre, sur une détection de perte par time out, le redémarrage se fait en en slow start avec un segment. TCP s’adapte donc au débit disponible sur le chemin emprunté. TCP suppose que toute perte est  provoquée par un phénomène de congestion.

Certaines versions de TCP autorisent un acquittement sélectif à la place de l’application séquentiel habituel.

4.3.3 Taille de segment

Avec le champs « option », les correspondants négocient la taille maximale du segment (MSS: maximum segment size). Cette taille maximale est choisie entre le minimum de la taille des tampons d’émission et de réception, du MTU, et le produit débit par RTT. Le choix de la taille du segment est déterminant pour les performances des communications. Pour les petits segments, le surcoût sera important tant pour la prise en compte logicielle de chaque segment, que pour les données transmises, en effet il y aura pour chaque segment transmis un en-tête TCP (20 octets min), IP (20 octets min) et réseau (24 octets pour Ethernet), soit 64 octets en tout. Pour une taille de segment importante, on n'évitera pas forcément la fragmentation IP  selon le MTU des réseaux traversés.
Le découpage  par IP d'un segment en fragments augmente la probabilité de perte, la perte d'un fragment provoque la ré-émission du segment complet par TCP. Ce phénomène est encore accentué dans le futur découpage sur ATM, où il faut retransmettre l’intégralité du segment en cas de perte de cellule.
En outre, le mécanisme d'accusé de réception de TCP qui acquitte tous les octets précédents dans le flot est pénalisant lorsque seul un segment sur plusieurs a été perdu et que ceux qui le suivent sont retransmis également pour n'avoir pas été acquittés à temps, bien qu'arrivés. La taille de segment par défaut préconisée par TCP pour IPv4 est de 536 octets (576 diminué des en-têtes IP et TCP).
Le bit « push » est mis à 1 pour le dernier paquet d’un message, tandis que le bit « no delay » force l’envoi en invalidant l’algorithme de Nagle. L’algorithme de Nagle quant à lui concatène les données qui proviennent de l’application et décide à quel moment les envoyer dans le flux. Il envoie les données lorsque la taille est suffisante ou bien lorsqu’un time-out est dépassé (200 msec).

4.3.4 Slow-start

Le slow-start n'intervient que si les machines ne sont pas sur le même réseau IP. Son objectif est d'éviter l'engorgement de routeur s'il faut passer par des liens à débit plus faible. Il adapte le flux à la capacité du réseau. Le “slow start ” démarre avec une la taille de la fenêtre d’un segment. La fenêtre augmente ensuite au fur et à mesure de la réception des acquittements. Au démarrage, l’anticipation se fait sur un segment, à chaque acquittement le nombre courant de segments anticipés est doublé, la croissance de la fenêtre d’anticipation sera donc exponentielle. L’axiome de base de cet algorithme est que la vitesse d’émission est égale à la vitesse de réception qui est reflétée par les acquittements. Par contre, après une première absence d’acquittement détectée par time-out ou par acquittement dupliquée, le mécanisme dit d’évitement de congestion (congestion avoidance) prend le pas sur le slow-start et augmente la taille de la fenêtre  de façon linéaire au delà du seuil de détection de congestion. Le seuil de détection de congestion est déterminé à la détection de perte d'un segment et correspond à la taille de la fenêtre /2.
Deux tailles interviennent, la fenêtre d'anticipation dont la taille est transmise au correspondant à chaque émission, la fenêtre de congestion dont la taille est déterminée localement par le mécanisme de slow-start et différents paramètres dont le RTT. Un émetteur n'anticipe que du minimum d'une de ces deux valeurs. Un émetteur prend comme taille de fenêtre la valeur minimale entre la fenêtre de congestion et la  fenêtre d'anticipation.

4.3.5 Temporisations et retransmissions

Un temporisateur détecte que l'acquittement n'a pas été obtenu au bout d'un temps donné et de met en oeuvre la retransmission du segment. L’absence d’acquittement indique la perte du segment, la perte de l’acquittement ou bien un délai anormalement élevé. TCP gère donc une temporisation qui déclenche la retransmission sur non réception de l'acquittement au bout d'un temps donné. L'algorithme de Karn gère les temporisations et détermine le temps de boucle.
La valeur de cette temporisation est déterminée par le temps de boucle aller-retour. Ce temps de boucle est mis à jour par TCP à chaque réception d'acquittement. Un temps de boucle moyen (RTT: round trip time) est calculé en utilisant un facteur de pondération pour éviter une influence trop immédiate de la nouvelle valeur. La temporisation est calculée en multipliant RTT par un coefficient dont la valeur préconisée vaut 2.
RTT=(a*anc_RTT)+(1-a)*nv_RTT
La mesure du temps de boucle est ambiguë à cause du facteur cumulatif des acquittements, quelquefois une seule valeur acquitte plusieurs segments. En outre, en cas de retransmission, l'acquittement vaut pour le segment initial ou le segment retransmis. Si l'on associe l'accusé de réception au premier segment, le délai de retransmission est rallongé. Par contre si l'on associe l'accusé de réception au segment retransmis, le délai de retransmission est raccourci et conduit à une sous-estimation du temps de boucle.
Pour éviter ces problèmes, TCP ne met pas à jour le RTT pour les segments retransmis. Le RTT calculé pour un segment non retransmis sera multiplié par un coefficient donné (souvent 2) en cas de retransmission et sera diminué progressivement en cas de fonctionnement correct.
Au démarrage, pour tenir compte de la capacité du réseau, TCP met en œuvre le mécanisme dit du slow-start qui minimise la taille de la fenêtre d’anticipation. Il envoie peu de données et double la quantité à chaque acquittement tant qu’il n’y a pas de pertes, dès qu’il y a des pertes TCP rétrograde.  Différentes temporisations sont utilisées par TCP, notamment celles d’ouverture de connexion, d’attente d’acquittement, de fermeture (Linger).

4.3.6 Congestion

La congestion survient lorsqu'un routeur est saturé. Les congestions sont causées pour diverses raisons : le trafic d'un lien de débit supérieur est envoyé vers un lien de débit inférieur,  le trafic entrant d'un routeur se concentre sur un lien de sortie spécifique, trop de données sont en circulation à un instant précis, la fenêtre est trop grande, les retransmissions sont trop fréquentes. L'utilisation de routes alternatives remédie à ce type de problèmes.
Une réaction aux congestions est d'envoyer un message ICMP de ralentissement à l'émetteur du message, IP récepteur transmet ce message à TCP. La congestion se traduit pour TCP par l’allongement du RTT et la perte de segment. En réaction à une perte de segment TCP divise par deux la fenêtre de congestion. De plus, le mécanisme de "slow start" employé au démarrage d'une connexion est également employé après une perte de segment pour à nouveau augmenter la taille de la fenêtre. Cependant, lorsque la fenêtre de congestion a atteint un seuil, TCP bascule en phase d'évitement de congestion durant laquelle le pas d'augmentation est un segment. Le démarrage lent, la diminution dichotomique, l'évitement de la congestion, le calcul de la temporisation adaptent le flux TCP au débit disponible.
TCP considère que toute perte est générée par une congestion et diminue donc la taille de la fenêtre d'anticipation. Ce mécanisme n'est pas adapté aux liens à taux d'erreur élevés, notamment des liens radios GSM, GPRS ou WiFi. L'augmentation du taux de perte et celle du délai sont souvent liés. Des niveaux 2 fiabilisés sont préconisées pour ces environnements
Il existe également une concurrence entre le trafic TCP et le trafic UDP. Le trafic TCP se régule alors que le trafic UDP a tendance à employer toute la bande passante disponible. La congestion est gérée au niveau réseau à l'aide de messages ICMP de limitation de débits, ces messages ne sont pris en compte par TCP et non pas par UDP. Le contrôle de flux est mis en œuvre au niveau transport.
Face à l'augmentation des vitesses de transmission, TCP demande un temps de traitement non négligeable et le contrôle de trafic de bout en bout empêche d'exploiter pleinement la vitesse offerte par le support. Ce n'est pas toujours gênant, car les liens haut-débits existent surtout pour la concentration de trafic, ce n'est pas forcément le rôle d'une seule session de les saturer, au contraire. Néanmoins, avec l’augmentation des performances de processeurs, certaines stations sont capables de générer de débits TCP supérieurs à cent mégabits.
Des mécanismes de notification de congestion pour TCP et IP ont été établis [ECN]. Ils ressemblent à celui du relais de trame où les bits EFCN et BFCN signalent la congestion au  destinataire à l’aide du bit EFCN, celui-ci la signale à son tour à l’émetteur à l’aide du bit BFCN. Les deux bits libres du champ TOS de l'en-tête IP sont utilisés pour un mécanisme similaire:
Bit 6 ECN: Explicit Congestion Notification,
Bit 7 CE: Congestion Experienced.
Le bit ECN positionné indique que les correspondants TCP sont ECN capables. Le bit CE est validé par un routeur qui détecte un risque de surcharge, le récepteur met le bit CE à 1 dans la réponse. Cette approche ne change pas forcément la situation par rapport aux demandes de ralentissement ICMP, au contraire un délai supplémentaire est nécessaire pour aviser l’émetteur. Cependant, la remontée du signal vers le destinataire et le retour dans son acquittement sont jugés préférables à l'émission immédiate d'un message de contrôle supplémentaire lors d'une situation de congestion. Le message ICMP de ralentissement d'IPv4 est d'ailleurs obsolète, il n'existe plus dans IPv6. ECN prend toute son importance avec un déploiement simultané de RED, c'est l'algorithme RED qui détermine la mise à un du bit ECN par le routeur sur les datagrammes qui sont marqués CN compatible. Ce marquage évite de passer tout de suite à la phase d'élimination sélective.
D'autres possibilités d'amélioration existent pour TCP: utiliser les acquittements sélectifs, augmenter la taille des tampons, démarrer le slow-start avec deux ou quatre segments au lieu de un. Différentes méthodes sont employées pour les gestions de file d'attente sur les routeurs: RED, WRED, WRR (round robin). Le mode de gestion de ces files favorise le trafic TCP réputé poli par rapport à des trafics plus agressifs du type UDP. La méthode RED (Random Early Discard) assure une élimination préventive, elle a été introduire pour éviter les phénomènes de synchronisation entre flux TCP concurrents d'un même routeur. En effet, si un segment est éliminé de tous les flux TCP transitant par un même routeur, ils vont tous ralentir simultanément et augmenter à nouveau de pair, jusqu'au prochain écroulement. Alors qu'avec la mise en œuvre de RED, un seul flux sera affecté.
Le respect d’une contrainte globale et d’une contrainte locale évite la congestion. La somme des données en circulation est inférieure à la taille mémoire de l'ensemble des routeurs, en négligeant la capacité de mémorisation des supports. La somme des données en transit à un instant donné sur un routeur est inférieure à la taille mémoire de ce routeur. La deuxième contrainte est plus forte. La saturation d'un seul routeur suffit pour bloquer progressivement une partie voire la totalité de l’interconnexion.

4.3.7 Compression des en-têtes

Une méthode de compression des en-tête TCP et IP est définie par le RFC 1144,  cette méthode est d'autant plus intéressante que la répartition moyenne des tailles de datagrammes est de l'ordre suivant :
30% moins de 10 octets,
20% de taille intermédiaire
50% de taille supérieure à 512 octets dont 5% à 1500 octets.
Les petits messages accroissent le poids relatif de l'en-tête.

4.4 SCTP

SCTP (Stream Control Transfert Protocol) définit dans le RFC 2960 est un protocole de transport. Il gère plusieurs  connections simultanées par association et le multihoming. Contrairement à TCP, SCTP ne concatène pas les données à l'émission, les messages sont donc reçus tels qu'ils sont émis.
L'unité de transport est un datagramme, chacun comporte un ou plusieurs chunks. Le contrôle d'erreur se fait par datagramme. Chaque chunk comporte un en-tête spécifique qui supporte le contrôle de flux, les acquittements.

4.5 Conclusion

UDP n'effectue pas de contrôle alors que TCP fiabilise la communication. En mode UDP, les datagrammes sont transmis vers l'application tel qu'ils sont émis, alors que les flux TCP sont transmis sans respecter les frontières d'émission.TCP effectue: un contrôle de flux, un contrôle d'erreurs sur l'en-tête et les données, une mise en ordre des messages. TCP évite les pertes et les duplications. Les mécanismes supports sont: le démarrage lent, le redémarrage rapide, le calcul de RTT (Karn), la concaténation des petits paquets (Nagle), fenêtre annoncée et fenêtre de congestion. Il existe différentes variantes de l’implémentation de TCP. UDP est un protocole plus léger que TCP, et pour cause, puisqu'il n'effectue aucun contrôle. Il est employé pour des applications à questions réponses courtes du type DNS, SNMP où les pertes se détectent aisément par l’absence de réponse. Par contre, pour des trafics de données intensifs et sensibles aux erreurs tels que les transferts de fichiers, TCP fiabilise la communication.