Quel protocole est le meilleur ? : TCP vs UDP, découvrez quand utiliser chacun d’eux

Protocole TCP : qu’est-ce que c’est et comment ça marche ?

Le protocole TCP (Transmission Control Protocol) est l’un des protocoles fondamentaux d’Internet, il nous permet que les applications puissent communiquer avec des garanties indépendamment des couches inférieures du modèle TCP/IP. Cela signifie que les routeurs (couche réseau dans le modèle TCP/IP) n’ont qu’à envoyer les segments (unité de mesure dans TCP), sans se soucier de savoir si ces données arriveront correctement ou non. TCP prend en charge plusieurs protocoles de couche d’application, tels que HTTP (web), HTTPS (web sécurisé), POP3 (courrier entrant) et SMTP (courrier sortant) ainsi que leurs versions sécurisées utilisant TLS. TCP est également utilisé dans des protocoles aussi importants que FTP, FTPES et SFTP pour transférer des fichiers d’une source à une destination, et même le protocole SSH pour gérer en toute sécurité les ordinateurs localement et à distance utilise le protocole TCP.

Principales caractéristiques

Étant donné que TCP sert un grand nombre de protocoles de couche application, il est essentiel que les données (segments) parviennent au destinataire correctement , sans erreur et dans l’ordre. Si dans la transmission des segments, ils sont corrompus ou perdus, le protocole TCP initie automatiquement la retransmission , sans intervention de la couche application. De cette façon, il est garanti que les données parviennent au destinataire sans erreur, car ce protocole est responsable de la résolution de tout type de problème.

Le MSS (Maximum Segment Size) est la taille maximale en octets que TCP peut recevoir dans un seul segment, il est similaire au MTU, mais le MSS est au niveau de la couche transport. Afin d’obtenir les meilleures performances, le MSS doit être suffisamment petit pour éviter la fragmentation IP. Le MSS est normalement annoncé de chaque côté du canal de communication, via l’en-tête TCP lui-même. Habituellement, la taille du MSS est le MTU (1500 octets normalement) moins l’en-tête TCP (qui a une longueur variable d’au moins 20 octets) moins l’en-tête IP (qui a une longueur variable d’au moins 20 octets). MSS = MTU (1 500 octets) – En-tête TCP 20 octets – En-tête IP 20 octets

TCP a un mécanisme de gestion des erreurs complexe , une technique de fenêtre glissante est utilisée pour que tous les segments arrivent correctement. Cette fonctionnalité utilise différentes méthodes pour détecter les erreurs possibles qui se produisent :

• Somme de contrôle
• Numérotation de tous les segments pour un suivi correct
• Confirmations sélectives d’ACK, bien qu’il permette également aux segments de «s’accumuler» de sorte qu’un seul ACK en confirme plusieurs.
• Temporisateurs : si un long délai s’écoule, TCP retransmet automatiquement le segment qui a été « perdu ».
• Les segments en double sont supprimés : dans le cas où un segment en double arrive (parce qu’un segment a pris plus de temps que la normale et a été envoyé à nouveau), il le supprime.

Bien sûr, si TCP détecte une erreur, il lancera automatiquement la retransmission sans absolument rien à faire par la couche application.

Une autre caractéristique très importante de l’information qui voyage d’une origine à une destination, est que les données arrivent dans l’ordre, c’est-à-dire dans le même ordre qu’ils ont été émis, puisque le protocole IP est un protocole au mieux, il fait tout ce qu’il peut pour s’assurer que les paquets arrivent en ordre et corrects, mais il n’est pas fiable puisqu’il ne garantit pas n’importe quoi. TCP a une fenêtre glissante sur l’expéditeur et le destinataire, de telle sorte que, si nous recevons un segment qui n’est pas en ordre, il «attendra» automatiquement jusqu’à ce que le segment manquant arrive, ou bien, il demandera une retransmission seulement de le segment manquant. A chaque segment reçu par le récepteur, un ACK sera envoyé indiquant à l’expéditeur que tout arrive correctement, cependant, dans la vraie vie, les implémentations TCP permettent d’envoyer un ACK pour confirmer la réception de plusieurs segments simultanément, avec l’objectif de ne pas saturer le réseau de tant de confirmations.

Le protocole TCP permet le contrôle de fluxEn d’autres termes, il est capable de pallier l’éventuelle saturation du réseau ou de l’hôte distant. Dans le cas où un appareil transmet à une vitesse de 500 Mbps et que l’appareil de destination ne peut recevoir des informations qu’à 100 Mbps, le protocole TCP s’adapte dynamiquement. De cette façon, le protocole TCP essaiera toujours de tirer le meilleur parti de la bande passante disponible entre la source et la destination. Le fonctionnement de cette fenêtre glissante est complexe, mais cela fonctionne essentiellement dans le sens où le récepteur dispose d’une fenêtre TCP disponible avec un nombre d’octets qu’il peut stocker dans un tampon, l’expéditeur pourra envoyer des données pour remplir cette quantité. Pour que l’expéditeur envoie plus de données, il est nécessaire que le destinataire lui envoie un ACK indiquant que tout est correct et qu’il procède à son «téléchargement» vers la couche application.

TCP a également un contrôle de congestion, cela nous permet de ne pas perdre de paquets sur Internet car il y a de la congestion dans les routeurs. Si le routeur est incapable de traiter ou de transférer les paquets au rythme auquel il les reçoit, le routeur lui-même les rejettera et il sera perdu, car sa mémoire tampon se remplira. Il ne faut pas confondre le contrôle de flux (que nous avons expliqué ci-dessus) avec le contrôle de congestion. La fenêtre de congestion (elle est complémentaire de la fenêtre de réception) est ce qui permet de gérer le contrôle de congestion dans TCP. Dans une situation de non-congestion, l’avantage de congestion est le même que la fenêtre de réception, si une congestion se produit, la taille de l’avantage de congestion diminue, et s’il disparaît, il augmente. Le nombre maximum d’octets que l’expéditeur peut envoyer est le minimum des deux tailles de fenêtre (si la fenêtre d’encombrement est de 1500 octets,

Afin d’éviter la congestion, et afin que nous puissions compresser le maximum de bande passante disponible entre l’origine et la destination, il y a un total de trois phases. La phase de démarrage lent est responsable de la croissance exponentielle de la fenêtre de congestion (elle ne peut donc pas vraiment être considérée comme un démarrage lent), puis la phase d’ évitement de congestion qui est responsable de l’augmentation linéaire de la fenêtre de congestion et, enfin, la phase constante où la réception est la même que la fenêtre d’encombrement.

Actuellement, TCP dispose de différents algorithmes pour gérer efficacement la congestion, les premiers étaient TCP Tahoe et Reno, bien que nous en ayons également d’autres tels que TCP Vegas, mais, au fil des ans, avec les nouveaux réseaux de données TCP / IP, d’autres algorithmes sont apparus. plus efficace. Par exemple, nous avons TCP BRR qui nous permet d’envoyer des informations le plus rapidement possible, car il est beaucoup plus efficace que le protocole TCP d’origine (nous aurons une vitesse plus élevée). Nous avons également TCP Cubic qui est le contrôle de congestion utilisé par les systèmes d’exploitation Linux et Unix.

Enfin, une autre caractéristique intéressante de TCP est qu’il nous permet de multiplexer des données , de cette façon, nous pouvons recevoir des informations de différents hôtes simultanément. Il nous permet également le Full-Duplex, car nous pouvons envoyer et recevoir des données simultanément via le même canal de communication.

Etablissement de la connexion entre client et serveur, et déconnexion en TCP

La principale caractéristique du protocole TCP est qu’il s’agit d’un protocole orienté connexion , afin d’établir une connexion entre client et serveur, il est absolument nécessaire d’établir une connexion préalable avec ledit serveur.

Cette connexion précédente est appelée 3-way handshake et consiste essentiellement en ce que le client (celui qui initie la connexion) envoie un message SYN au serveur (celui qui reçoit la connexion). Par la suite, le serveur enverra un message de type SYN-ACK, indiquant qu’il peut commencer à envoyer des informations, enfin, le client envoie un ACK indiquant qu’il l’a bien reçu, et il commence à envoyer toutes les informations entre client et serveur bidirectionnel. chemin. Un détail très important de TCP est qu’il génère des numéros de séquence de chaque côté, aidant à ce que de fausses connexions ne puissent pas être établies entre eux, bien que si l’attaquant est «au milieu», alors une attaque MitM de type ARP pourrait être effectuée. ou similaire, mais pas sur Internet.

Une des vulnérabilités de TCP réside dans l’envoi d’un grand nombre de segments TCP SYN, dans le but de « saturer » les connexions vers le récepteur. Voici quelques solutions possibles pour atténuer cette attaque par déni de service :

• Limitez le nombre de connexions, qu’elles soient globales ou IP.
• Acceptez uniquement les connexions aux adresses IP de confiance.
• Retarder l’allocation des ressources à l’aide de « cookies », également appelés cookies SYN.

Pour mettre fin à la connexion , celui qui veut mettre fin à la connexion envoie un message FIN, et l’hôte qui le reçoit enverra un message ACK avec un autre message FIN, de telle sorte que l’ordinateur qui a initié la terminaison de connexion lui en envoie un dernier ACK et le socket ouvert sera fermé. Un détail important est que nous pouvons avoir une connexion «à moitié ouverte», si un hôte met fin à la connexion et l’autre pas, le côté qui a mis fin à la connexion ne pourra pas envoyer plus de données, mais celui qui n’a pas fermé il pourra continuer à envoyer des informations.

En-tête TCP

TCP ajoute au moins 20 octets d’ en- tête dans chaque segment, car nous avons un champ «facultatif». Dans cet en-tête TCP, nous trouverons le port source et le port de destination de la connexion (socket), nous trouverons également le numéro de séquence, le numéro ACK, et les différents FLAGS TCP tels que SYN, ACK, RST, FIN, URG et autres. Dans cet en-tête, nous avons également une partie très importante pour le fonctionnement de la fenêtre glissante, à savoir que nous aurons un champ de 16 bits qui indique la taille de la fenêtre de réception que nous avons expliquée précédemment.

Les ports (Source Port et Destination Port) sont indispensables au bon fonctionnement de TCP. TCP utilise ces numéros de port pour identifier un socket, c’est-à-dire une application qui émet ou reçoit des données. Les ports TCP vont de 0 à 65535, mais nous avons trois types de ports différents :

• Ports connus : 0 à 1023. Ces ports sont réservés par l’IANA pour certaines applications, comme le serveur HTTP, FTP, SSH, et bien d’autres ports bien connus.
• Ports enregistrés : 1024 à 49151. Ces ports sont réservés à des applications spécifiques, telles que les systèmes de gestion de bases de données, BitTorrent, et bien d’autres applications.
• Ports privés : de 49152 à 65535. Ces ports ne sont réservés par aucune application, et vous pouvez les utiliser librement sans affecter aucun autre protocole.

Protocole UDP : qu’est-ce que c’est et comment ça marche ?

Le protocole UDP (User Datagram Protocol) est l’un des protocoles fondamentaux sur Internet, il nous permet que les applications puissent communiquer avec des garanties indépendamment des couches inférieures du modèle TCP/IP. Cela signifie que les routeurs (couche réseau dans le modèle TCP/IP) n’ont qu’à envoyer les datagrammes (unité de mesure en UDP). UDP prend en charge plusieurs protocoles de couche d’application tels que le DNS populaire et même le protocole DHCP pour obtenir (et fournir) automatiquement l’adressage IP.

Principales caractéristiques

Le protocole UDP permet l’envoi de datagrammes sans avoir besoin d’établir préalablement une connexion, il suffit d’avoir une socket ouverte à la destination pour accepter les datagrammes de la source. UDP est un protocole non orienté connexion, c’est-à-dire qu’il ne se produit pas comme dans TCP où il y a une phase d’établissement de connexion, ici ils sont envoyés directement sans établissement préalable de « avertissement ».

Ce protocole ne fournit aucun type de contrôle de flux , si un ordinateur est plus rapide qu’un autre et envoie des informations, il est très possible que des informations soient perdues car elles s’effondreront au plus lent, et nous devrons procéder au renvoi des informations. Un détail important est que la gestion de la transmission des datagrammes est effectuée par la couche transport, car UDP est très simple et n’a pas de mécanismes de contrôle de transmission des datagrammes en raison de la perte.

UDP ne fournit pas non plus de contrôle de la congestion , s’il y a de la congestion dans le réseau, des paquets pourraient être perdus, et, logiquement, il ne sera pas responsable de les transmettre comme c’est le cas avec TCP. Par conséquent, comme UDP n’a pas de contrôle d’encombrement, de contrôle de flux ou de contrôle d’erreur, on pourrait dire qu’UDP est un protocole peu fiable. De plus, il ne fournit pas d’ordre dans les datagrammes envoyés, ni d’information si un datagramme est arrivé correctement, puisqu’il n’y a pas de confirmation de livraison ou de réception. Tout type de garanties pour la transmission d’informations doit être mis en œuvre dans des couches supérieures.

Ce protocole est principalement utilisé dans DHCP et DNS où la vitesse est plus importante que la fiabilité. UDP est largement utilisé dans les tâches de contrôle des transmissions audio et vidéo sur un réseau. UDP ajoute uniquement le multiplexage d’application et la somme de contrôle d’en-tête et de charge utile.

En-tête UDP

UDP ajoute 8 octets d’ en- tête dans chaque datagramme. Dans cet entête UDP on retrouvera le port source et le port destination de la connexion (socket), la longueur du datagramme et la somme de contrôle dudit datagramme pour vérifier que ni l’entête ni les données du datagramme n’ont d’erreurs. Les ports (Source Port et Destination Port) sont indispensables au bon fonctionnement d’UDP. UDP utilise ces numéros de port pour identifier un socket, c’est-à-dire une application qui émet ou reçoit des données.

TCP vs UDP dans les différents protocoles VPN

OpenVPN

OpenVPN est un protocole pour créer des réseaux privés virtuels qui nous permettent d’assurer une communication point à point, puisque tout le trafic du tunnel est crypté et authentifié. OpenVPN permet l’utilisation de réseaux privés virtuels de type accès distant, pour les clients mobiles qui souhaitent se connecter à un serveur VPN à distance et naviguer sur Internet via l’IP publique du serveur, cela inclut également l’accès aux ressources partagées du réseau domestique ou des professionnels. Ce protocole nous permet également de configurer un tunnel Site-to-Site, afin d’intercommuniquer entre différents sites et de partager des fichiers de manière totalement sécurisée et confidentielle grâce aux protocoles cryptographiques intégrés.

OpenVPN utilise un canal de contrôle et un canal de données, dans le canal de contrôle, nous pouvons utiliser TLS 1.2 et également la dernière version TLS 1.3, pour protéger de manière adéquate tout le trafic de négociation. Dans le canal de données, nous pouvons utiliser l’algorithme de cryptage symétrique AES-256-GCM, bien que dans les dernières versions, ils aient également intégré la compatibilité avec CHACHA20-POLY1305, un algorithme de cryptage symétrique qui inclut également AEAD grâce à Poly1305 pour l’authentification du Les données. De cette façon, l’ensemble de l’établissement et les données transférées dans le tunnel VPN seront parfaitement protégés. Dans RedesZone, vous disposez d’un didacticiel complet sur la façon de configurer un serveur OpenVPN et de vous y connecter facilement.

OpenVPN nous permet d’utiliser à la fois les protocoles TCP et UDPPour le tunnel de données, comme vous l’avez vu, TCP et UDP sont très différents, et il est toujours conseillé d’utiliser UDP car il est très rapide, l’établissement des communications est nettement plus rapide avec UDP que si on utilise TCP. Si nous utilisons TCP, nous aurons à notre disposition un contrôle de flux, un contrôle de congestion, un contrôle d’erreur et de nombreuses autres caractéristiques qui rendent une connexion fiable. Cependant, lorsque nous utilisons un VPN, nous avons toujours des protocoles dans la couche application qui demanderont à nouveau les données si elles arrivent endommagées, nous avons donc une redondance, et ce qui nous intéresse le plus dans un VPN, c’est la vitesse dans l’établissement et aussi la vitesse dans transfert de données. Pour cette raison, il est préférable d’utiliser UDP, s’il y a un problème dans le transfert,

Un aspect très important est qu’un serveur OpenVPN avec UDP pourra accepter plus de connexions entrantes simultanément si vous utilisez UDP que si vous utilisez TCP, de plus, nous aurons également une bande passante plus élevée car aucune «charge» supplémentaire n’est ajoutée, en raison car UDP est beaucoup plus «léger».

WireGuard

WireGuard est un nouveau protocole VPN qui utilise une cryptographie entièrement renouvelée et simple, car il n’utilise que les algorithmes de cryptage symétrique, asymétrique et de hachage les plus sécurisés et efficaces qui existent actuellement. Dans RedesZone, nous avons déjà parlé en détail et nous vous avons appris comment configurer WireGuard pour se connecter en toute sécurité à notre maison.

WireGuard utilise uniquement le protocole de couche de transport UDP, cette décision est due au fait que UDP est beaucoup plus rapide que TCP, à la fois dans l’établissement de la connexion et plus tard dans la communication puisque son en-tête est beaucoup plus petit. L’un des points forts de WireGuard est qu’il nous permet de «roaming VPN» facilement et très rapidement, cela signifie que si nous sommes connectés à notre Wi-Fi et que nous avons un tunnel VPN établi, si nous passons au réseau 4G, cela Le tunnel VPN se renégocie très rapidement sans que vous le sachiez presque. Si au lieu d’utiliser UDP, vous utilisiez TCP, ce roaming VPN serait plus lent, car la communication TCP devrait être établie au préalable puis TLS.

TCP vs UDP sur le Web

Actuellement, lorsque nous naviguons sur différents sites Web, nous utilisons le protocole TCP, car HTTP et HTTPS utilisent TCP en dessous. Si nous utilisons HTTP, le port par défaut est TCP 80, en cas d’utilisation de HTTPS, le port par défaut est TCP 443. Lors de l’utilisation de TLS 1.2 ou TLS 1.3, ci-dessous, nous utilisons toujours le protocole TCP.

L’une des nouveautés de HTTP/3 est l’utilisation de QUIC, un nouveau protocole de communication qui commence à être largement utilisé, qui fonctionne sur UDP au lieu de TCP, pour fournir une plus grande vitesse. QUIC sera chargé de fournir la connectivité du client au serveur Web, et il le fera en utilisant TLS 1.2 ou TLS 1.3, car logiquement, nous avons également un support pour ces protocoles de communication sécurisés.

Comme vous l’avez vu, TCP et UDP sont deux protocoles Internet fondamentaux, et chacun d’eux gère différents protocoles de la couche application.