La couche transport est la quatrième couche (couche 4) du modèle OSI à sept couches. La couche transport fournit des services de communication de bout en bout pour les applications. La couche 4 s’occupe de l’assemblage et du désassemblage des données grâce à des services tels que le support orienté connexion, la fiabilité, le contrôle de flux et le multiplexage.
La couche transport est surtout connue pour le protocole TCP, qui est un protocole orienté connexion. Le protocole TCP de cette couche garde la trace des segments et retransmet les segments qui échouent en transit.
Les protocoles de la couche transport peuvent également prévoir l’accusé de réception d’une transmission de données réussie. La plupart des blocs de données sont beaucoup trop volumineux pour une seule trame, de sorte que le bloc de données d’application doit être désassemblé en blocs de données plus petits avant d’être envoyé sur le réseau.
Le système cible qui reçoit toutes les trames doit être capable de reconnaître les paquets entrants comme une seule transmission de données et de réassembler les paquets correctement en fonction des informations incluses dans les paquets par le système émetteur. En outre, le système récepteur doit vérifier que tous les paquets de cette donnée sont arrivés correctement et informer le système émetteur qu’il n’y a pas d’erreur.
Protocoles de la couche transport
Le modèle OSI définit cinq classes de protocoles de transport : TP0, qui fournit le moins de récupération d’erreurs, à TP4, qui est conçu pour les réseaux moins fiables, tels qu’Internet. Le TP4 est le plus proche du protocole TCP. Le protocole TCP est utilisé sur les réseaux moins fiables parce que le protocole lui-même est utilisé pour s’assurer que les paquets sont tous livrés et sans erreur.
Lorsque des paquets sont manquants ou contiennent des erreurs, le protocole TCP informe l’expéditeur que les paquets doivent être retransmis. En cas d’utilisation de protocoles moins fiables, tels que le protocole UDP, c’est à l’application de déterminer si les paquets ont été livrés et s’ils sont exempts d’erreurs. UDP fournit une livraison « best-effort ». Gardez à l’esprit que TCP/IP n’est pas la seule suite de protocoles qui peut être mise en correspondance dans le modèle OSI.
Les protocoles les plus courants que l’on trouve dans la couche transport des différentes suites sont TCP (Transmission Control Protocol), UDP (User Datagram Protocol), ATP (AppleTalk Transaction Protocol) et SPX (Sequenced Packet Exchange). Il en existe beaucoup d’autres, mais ce sont les plus couramment utilisés.
Lorsque l’on travaille avec TCP/IP, en ce qui concerne les protocoles orientés connexion (TCP) et sans connexion (UDP), il peut y avoir une certaine confusion quant aux différences entre eux. La meilleure analogie que l’on puisse utiliser pour discuter de ces différences est le système de distribution du courrier américain.
Le courrier prioritaire serait l’équivalent du protocole TCP. Lorsque vous expédiez un article en courrier prioritaire, celui-ci est suivi et, dans certains cas, assuré. Pendant que l’article prioritaire est en transit, il peut être facilement suivi en ce qui concerne son dernier emplacement connu et son heure de livraison.
La date et l’heure de livraison sont enregistrées, de même que la signature du destinataire, dans certains cas. Si le colis n’arrive pas ou est perdu, vous pouvez déterminer le dernier endroit où il s’est trouvé et qui l’a manipulé. En outre, vous pouvez déterminer si le colis a été endommagé d’une manière ou d’une autre.
Dans le cas de l’envoi de courrier ordinaire, ce processus peut être comparé à l’envoi de paquets sur le réseau en utilisant UDP. Les paquets UDP sont envoyés sans garantie de livraison et l’expéditeur ne sait pas non plus si les paquets ont atteint leur destination, un peu comme lorsque vous envoyez une lettre par la poste. Vous devez compter sur le destinataire pour vous informer de l’existence ou non d’un problème de réception de votre paquet, s’il sait même qu’il attend un paquet.
Si TCP est si génial, pourquoi toutes les communications sur un réseau TCP/IP ne doivent-elles pas utiliser TCP ? Eh bien, en fonction de la taille et du contenu des données que vous transmettez, le coût de la connexion elle-même (poignée de main à trois voies, maintien de la connexion, etc.) peut être trop coûteux en termes de ressources. Il peut être plus simple d’exiger que l’application prenne en charge cette responsabilité.
Par exemple, si l’application d’envoi n’a pas reçu de réponse de l’application de réception, vous pouvez simplement demander à l’application de supposer que les données n’ont jamais atteint le destinataire et de renvoyer les informations. En outre, certaines applications peuvent ne pas savoir à qui elles envoient le paquet.
Par exemple, dans le cas des paquets DHCP, lorsqu’un hôte TCP/IP arrive sur le réseau, il envoie des paquets de diffusion UDP à tout serveur DHCP disponible. Lorsqu’un hôte TCP/IP est connecté pour la première fois à un réseau, il n’a pas d’adresse IP tant qu’il n’en loue pas une auprès d’un serveur DHCP ou qu’il n’est pas configuré de manière statique avec une adresse IP.
Ainsi, sans IP et sans connaissance du réseau auquel il est connecté, il ne peut pas initier de communication avec un pair du réseau en utilisant un protocole orienté connexion.