TCP flux vs message UDP
TCP est orienté flux, ce qui signifie que les données sont transférées sous forme de flux continu d'octets. Mais ce qui me dérange, c'est que TCP crée des segments et les transmet à IP. IP crée des paquets encapsule des segments et les transfère. Alors, où exactement le flux continu ici?
UDP, quant à lui, est orienté message. Il reçoit des messages de la couche application, crée des datagrammes et les transfère à IP. Jusqu'ici, il est identique à TCP, à la place d'un datagramme créé et poussé vers le bas. Qu'est-ce qui fait de ce protocole un message orienté?
L'interface/API présentée à l'utilisateur (programmeur) de ces protocoles est:
UDP
Orienté message, vous disposez d'une API (send/recv et similaire) qui vous permet d'envoyer un datagramme, et de recevoir un datagramme. 1 appel send () donne 1 datagramme envoyé et 1 appel recv () recevra exactement 1 datagramme.
TCP
Orienté flux, vous avez une API (send/recv et similaire) qui vous permet d'envoyer ou de recevoir un flux d'octets. Il n'y a pas de préservation des limites des messages. TCP peut regrouper les données de nombreux appels send () dans un segment ou décomposer les données d'un appel send () en plusieurs segments. top of TCP, et recv () vous renvoie simplement des données, sans relation avec le nombre d'appels de send () qui ont généré les données que vous avez récupérées.
TCP est un protocole orienté connexion, ce qui signifie qu’il établit d’abord une connexion avec le récepteur, puis envoie les données par segments (PDU pour la couche de transport), qui sont acheminées par des paquets IP. De cette façon, cela s'appelle stream car il garde le flux de données entre deux extrémités pendant le transfert.
UDP est un protocole de transport sans connexion (tout comme IP) avec une unité de données appelée datagramme. Donc, contrairement à TCP, UDP transfère des données sans établir de connexion, il suffit d’envoyer des messages datagrammes à la couche IP pour les transférer.
TCP est orienté flux, car il est capable d’assembler des données dans un format contigu. Par exemple. vous avez eu des données du nombre 1 à 4000 octets. Maintenant, il sera divisé en segments tcp où chaque segment aura un numéro de séquence, le premier étant 1-1200 octets, le second 1201 - 2400, etc.
Il peut être livré hors service lors de son envoi via des datagrammes ip, mais est ensuite assemblé en données contiguës en y apparaissant sous forme de flux. Le numéro de séquence permet de réorganiser les paquets.
Une explication un peu plus profonde est:
Un flux d'octets est constitué d'un gros bloc de données sans segment ni autres irrégularités. Avec des datagrammes (plus petits), des morceaux de données sont envoyés et reçu à la fois dans son ensemble. En pratique, cela signifie que avec les datagrammes chaque appel d'envoi/écriture envoie un paquet et chaque lecture/réception. L'appel reçoit un paquet, alors qu'avec le protocole de flux, les données peuvent être envoyer et recevoir de quelque manière que ce soit. Par exemple. Un expéditeur peut appeler send () dix fois, tandis que le destinataire reçoit toutes ces données en un seul appel. Avec datagrammes dix appels à envoyer signifie dix paquets et dix appels à recevoir
Beaucoup de confusion ici. Laissez-moi clarifier.
TCP/IP est un protocole orienté flux, orienté paquet et connexion .UDPest simplement un protocole orienté paquet. N'établit pas la connexion en premier.
Supposons que vous utilisez un programme Java pour vous connecter à un réseau dans votre application en appelant Java.net.Socket class du côté client et Java.net.ServerSocket du côté du serveur. Une fois la connexion établie, la transmission des données commence. La question vient, est-ce que les données sont envoyées en flux (Codata ou flux infini) ou en paquets si j'ai choisi TCP? La réponse est que les données reçues par la méthode TCP sont stream mais TCP convertit le flux en paquet avant d'envoyer la pile de niveau inférieur. Fondamentalement, la couche d'application ci-dessus envoie les données en flux à la couche TCP et TCP les décompose en paquets destinés à la couche réseau et effectue la transmission de paquets en continu lors de la réception depuis le serveur (réception). côté parce que votre application Java ne peut comprendre que Stream. La transmission de fichier est préférable via TCP plutôt que UDP car vous ne pouvez pas vous permettre de perdre des paquets.
UDP, quant à lui, est un protocole orienté paquet où l’application, telle que la classe Java Java.net.DatagramPacket; Java.net.DatagramPacket; import Java.net.DatagramsSocket crée d'abord un paquet avant de parler à UDP, et le paquet est envoyé avec des informations supplémentaires par les protocoles UDP/IP côté serveur. Notez que certaines applications peuvent présenter les données sous forme de flux lorsque le protocole sous-jacent est UDP. Cependant, il s’agit de la superposition d’un protocole supplémentaire au-dessus du protocole UDP, et ce n’est pas quelque chose d’inhérent au protocole UDP lui-même. Le straming en direct de la télévision est généralement UDP, car vous ne craignez pas la perte de paquets.
La particularité de TCP est que ce comportement est transparent pour l'utilisateur, respectivement. l'application.
La seule chose que l'application doit faire est d'appeler send() et recv() afin d'envoyer et d'obtenir des données.
Les couches ci-dessous garantissent que les données sont reçues dans l'ordre exact dans lequel elles ont été envoyées et que les données manquantes sont retransmises si elles "restent manquantes".
UDP, OTOH, conserve les données d’un appel send() ensemble, même s’il est fractionné en plusieurs paquets IP. De cette façon, ces données peuvent être vues comme un seul datagramme.