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 de l'endroit où je l'ai lu et je ne peux donc malheureusement pas en attribuer l'idée à l'auteur, mais j'ai néanmoins ajouté beaucoup de mes propres connaissances à l'analogie fondamentale. Alors, voici:
Une prise 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 l'une des parties n'entend pas au revoir, elle rappellera généralement l'autre parce qu'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 que vous avez envoyé, 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 transmettez la note; la note voyagera de personne à personne. Il peut ne pas atteindre sa destination, et il peut être modifié par le temps qu'il y arrive. Si vous transmettez deux notes à la même personne, elles risquent d'arriver dans un ordre que vous ne souhaitiez pas, car l'itinéraire emprunté par les notes dans la salle de classe peut ne pas être identique, une personne peut ne pas transmettre une note aussi rapidement que l'autre, etc. .
Vous utilisez donc un socket de flux lorsqu'il est important d'avoir des informations en ordre et intact. Les protocoles de transfert de fichiers sont un bon exemple ici. Vous ne voulez pas télécharger un fichier dont le contenu est mélangé de manière aléatoire et endommagé!
Vous utiliseriez un socket de datagramme lorsque l'ordre est moins important que la livraison dans les délais (pensez aux protocoles VoIP ou de jeu), lorsque vous ne voulez pas la surcharge d'un flux (c'est pourquoi DNS est principalement un protocole de datagramme, afin que les serveurs puissent répondre à beaucoup, beaucoup de demandes à la fois très rapidement), ou quand vous ne vous souciez pas trop si les données atteignent jamais leur destination.
Pour développer le cas 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 sur le protocole de flux (généralement TCP) pour émettre une demande de réexpédition - vous devez récupérer rapidement. TCP peut prendre un certain nombre de minutes à récupérer, et pour des protocoles en temps réel comme le jeu ou la VoIP, trois secondes peuvent être inacceptables! L'utilisation d'un protocole de datagramme comme UDP permet au logiciel de récupérer une telle événement très rapidement, en ignorant simplement les données perdues ou en les demandant à nouveau plus tôt que TCP ne le ferait).
La VoIP est un bon candidat pour simplement ignorer les données perdues - une partie entend seulement un court intervalle, similaire à ce qui se produit lorsque vous parlez à quelqu'un sur un téléphone portable lorsque la réception est mauvaise. 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 ultérieurement 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.
Prise de courant:
- Canal dédié et de bout en bout entre le serveur et le client.
- Utilisez le protocole TCP pour la transmission des données.
- Fiable et sans perte.
- Données envoyées/reçues dans le même ordre.
- Long temps pour récupérer les 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.
- Non 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 inquiétez pas ou ne récupérez pas rapidement les données perdues/erronées.
Si c’est la programmation réseau, je pense que partir des sockets serait un bon début.
socket = ip + port
il existe trois types de prises
stream (TCP, commande et livraison garanties, aucune duplication, aucune limite de longueur ou de caractère pour les données, en mode connexion, fiable, accès concurrentiel)
datagramme (UDP, sur la base de paquets, sans connexion, limite de taille de datagramme, les données peuvent être perdues ou dupliquées, la commande n'est pas garantie, pas 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 indiquant quel socket doit utiliser quel protocole de transport et quelle fiabilité ne doit pas être confondu, car UDP est réaliste si les deux extrémités sont actives.
Fiabilité fait référence à plus de fiabilité de livraison puisqu'il existe des vérifications de numéro 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 de réseau comme Warshark tcpdump, etc., pour voir ce que votre logiciel fait exactement: type de vérification ou fusion de la théorie sur papier avec votre travail en action.