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

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

Il y a longtemps, j’ai lu une grande analogie pour expliquer la différence entre les deux. Je ne me souviens pas de l’endroit où je l’ai lu, alors je ne peux malheureusement pas créditer l’auteur pour cette idée, mais j’ai aussi ajouté beaucoup de mes propres connaissances à l’analogie de base. Alors voilà:

Un socket de stream est comme un appel téléphonique – un côté place l’appel, les autres réponses, vous vous dites bonjour (SYN / ACK dans TCP), puis vous échangez des informations. Une fois que vous avez terminé, vous dites au revoir (FIN / ACK dans TCP). Si l’une des parties n’entend pas un au revoir, elle appellera généralement l’autre parce que c’est 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 que vous leur avez envoyé, et il existe une garantie raisonnable que les données ne seront pas endommagées.

Un socket 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 transmettez 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 transmettez deux notes à la même personne, elles peuvent arriver dans un ordre que vous n’aviez pas prévu, car l’itinéraire emprunté par les notes dans la classe peut ne pas être le même, une personne peut ne pas transmettre une note aussi rapidement qu’une autre, etc. .

Donc, vous utilisez un socket de stream lorsque des informations dans l’ordre et intact sont importantes. 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 un socket datagramme lorsque la commande est moins importante que la livraison rapide (pensez aux protocoles VoIP ou de jeu), lorsque vous ne souhaitez pas avoir un temps de traitement plus élevé (c’est pourquoi DNS est avant tout un protocole de datagramme). répondre à beaucoup, à beaucoup de demandes à la fois très rapidement), ou lorsque vous ne vous souciez pas trop des données si elles atteignent leur destination.

Pour étendre le cas de la VoIP / du 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 sur le protocole de stream (généralement TCP) pour émettre une demande de ré-envoi – vous devez récupérer rapidement. TCP peut prendre 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 tel que le protocole 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 demandant plus rapidement que TCP.

La voix sur IP est un bon candidat pour ignorer simplement les données perdues – une partie entendrait simplement un court intervalle, semblable à ce qui se passe lorsque l’on parle à quelqu’un sur un téléphone portable quand sa réception est médiocre. Les protocoles de jeu sont souvent un peu plus complexes, mais les mesures à prendre consistent généralement à ignorer les données manquantes (si les données reçues par la suite remplacent les données perdues), à demander à nouveau les données manquantes ou à demander une mise à jour complète de l’état. Assurez-vous que l’état du client est synchronisé avec celui du serveur.

Socket Stream:

  • Canal dédié et point à point 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 la commande similaire.
  • Long temps de récupération des données perdues / erronées

Socket Datagramme:

  • Pas de canal dédié et point à point entre le serveur et le client.
  • Utilisez UDP pour la transmission des données.
  • Pas fiable à 100% et risque de perdre des données.
  • Les données envoyées / reçues peuvent ne pas être les mêmes
  • Ne vous souciez pas ou récupérez rapidement les données perdues / erronées