Quelle est la différence entre les flux et les datagrammes dans la programmation réseau?

Quelle est la différence entre les sockets (flux) et les sockets (datagrammes)? Pourquoi utiliser l'un sur l'autre?

Il y a longtemps, j'ai lu une excellente analogie pour expliquer la différence entre les deux. Je ne me souviens pas où je l'ai lu, donc malheureusement je ne peux pas attribuer l'idée à l'auteur, mais j'ai également ajouté beaucoup de mes propres connaissances à l'analogie de base de toute façon. Alors voilà:

Un socket de flux est comme un appel téléphonique - un côté passe l'appel, l'autre répond, vous vous dites bonjour (SYN / ACK en TCP), puis vous échangez des informations. Une fois que vous avez terminé, vous dites au revoir (FIN / ACK dans TCP). Si un côté n'entend pas un au revoir, ils rappelleront généralement l'autre car il s'agit d'un événement inattendu; généralement, le client se reconnectera au serveur. Il existe une garantie que les données n'arriveront pas dans un ordre différent de celui dans lequel vous les avez envoyées, et il existe une garantie raisonnable que les données ne seront pas endommagées.

Un socket de datagramme est comme passer une note en classe. Considérez le cas où vous n'êtes pas directement à côté de la personne à qui vous passez la note; la note voyagera de personne à personne. Il peut ne pas atteindre sa destination et il peut être modifié au moment où il y arrive. Si vous passez deux notes à la même personne, elles peuvent arriver dans un ordre que vous n'aviez pas prévu, puisque l'itinéraire que les notes empruntent dans la classe peut ne pas être le même, une personne peut ne pas passer une note aussi vite qu'une autre, etc. .

Donc, vous utilisez une socket de flux lorsque les informations sont en ordre et intactes est important. Les protocoles de transfert de fichiers en sont un bon exemple. Vous ne voulez pas télécharger un fichier avec son contenu mélangé au hasard et endommagé!

Vous utiliseriez une prise de datagramme lorsque la commande est moins importante que la livraison en temps opportun (pensez aux protocoles VoIP ou de jeu), lorsque vous ne voulez pas la surcharge plus élevée d'un flux (c'est pourquoi DNS est principalement un protocole de datagramme, de sorte que les serveurs peuvent répondre à de très nombreuses demandes à la fois très rapidement), ou lorsque vous ne vous souciez pas trop de savoir si les données atteignent leur destination.

Pour développer le cas de la VoIP / jeu, ces protocoles incluent leur propre mécanisme de classement des données. Mais si un paquet est endommagé ou perdu, vous ne voulez pas attendre le protocole de flux (généralement TCP) pour émettre une demande de réenvoi - vous devez récupérer rapidement. TCP peut prendre jusqu'à un certain nombre de minutes pour récupérer, et pour les protocoles en temps réel comme les jeux ou la VoIP, même trois secondes peuvent être inacceptables! L'utilisation d'un protocole de datagramme comme UDP permet au logiciel de récupérer extrêmement rapidement d'un tel événement, en ignorant simplement les données perdues ou en les redemandant plus tôt que TCP.

La VoIP est un bon candidat pour ignorer simplement les données perdues - une partie entendrait juste un court intervalle, semblable à ce qui se passe quand on parle à quelqu'un sur un téléphone portable quand sa réception est mauvaise. Les protocoles de jeu sont souvent un peu plus complexes, mais les mesures prises seront généralement soit d'ignorer les données manquantes (si les données reçues par la suite remplacent les données qui ont été perdues), soit de demander à nouveau les données manquantes, soit de demander une mise à jour complète de l'état pour assurez-vous que l'état du client est synchronisé avec celui du serveur.

Prise de flux:

• Canal dédié et de bout en bout entre le serveur et le client.
• Utilisez le protocole TCP pour la transmission de données.
• Fiable et sans perte.
• Données envoyées / reçues dans le même ordre.
• Long temps pour récupérer des données perdues / erronées

Prise de datagramme:

• Canal non dédié et de bout en bout entre le serveur et le client.
• Utilisez UDP pour la transmission de données.
• Pas fiable à 100% et peut perdre des données.
• Les données envoyées / reçues de la commande peuvent ne pas être les mêmes.
• Peu importe ou récupération rapide des données perdues / erronées.

Si c'est la programmation réseau, je pense que partir de sockets serait un bon début.
socket = ip + port
il existe trois types de
flux de sockets (TCP, commande et livraison garanties, pas de duplication, pas de longueur ou de limites de caractères pour les données, orienté connexion, fiable, simultanéité)
datagramme (UDP, par paquets, sans connexion, datagramme limite de taille, les données peuvent être perdues ou dupliquées, ordre non garanti, non fiable)
raw (accès direct aux protocoles de couche inférieure IP, ICMP)
Je ne vois pas de règle stricte pour le type de protocole de transport quant au socket doit utiliser quel protocole de transport et la fiabilité ne doit pas être trompée car UDP est réalisable au cas où les deux extrémités seraient actives.
La fiabilité se réfère davantage à la fiabilité de la livraison car il existe des vérifications de numéros de séquence en utilisant TCP comme protocole de transport qui n'existent pas dans UDP.Il est préférable d'utiliser un analyseur de protocole réseau comme Wilshark tcpdump, etc. pour voir ce que votre logiciel fait exactement; sorte de vérification ou fusion de la théorie sur le papier avec votre travail en action.