Les informations peuvent être segmentées ou divisées en fragments plus petits ou être transmises sur un
support physique. L'unité de transmission maximale ou vider une interface sortante dépend du support physique.
A titre d'exemple, ils vous vident de la première Ethan. Il s'agit de 5400 octets.
Cependant, TZP peut théoriquement prendre en charge soixante cinq mille quatre cent quatre vingt quinze octets dans un seul
paquet.
Lorsque cela est envoyé aux couches inférieures du modèle d'ozone, vous devrez le diviser en fragments
pour le transmettre sur le support physique, qui ne prend en charge que 50 ou 100 octets, par exemple.
Les données sont donc divisées en fragments plus petits et le récepteur utilisant TZP devra rassembler ces fragments
à nouveau.
La taille maximale du segment ou MSA est la plus grande quantité de données en octets que TZP est prête à envoyer
dans un seul segment pour des performances optimales.
Le MSA est suffisamment petit pour éviter la fragmentation d'Arpey, ce qui peut entraîner des retransmissions excessives en cas
de perte de paquets. Le protocole DCP prend en charge ce que l'on appelle Taille maximale du segment et pause.
MT Votre découverte ou découverte d'unité de transmission maximum avec l'expéditeur et le destinataire peuvent déterminer automatiquement quelle
est l'unité de transmission maximale sur un chemin entre eux et TZP ne mettra que suffisamment de données dans
un seul paquet qui correspond à ce vide, évitant ainsi la fragmentation des paquets et Ainsi, éviter la surcharge associée
à la fragmentation et l'assemblage des fragments IP dans votre découverte est facultatif dans IP version
4, qui est désormais obligatoire dans IP version 6 en raison de l'efficacité apportée à la transmission TZP et du fait
que IP la version 6 ne prend pas en charge la fragmentation sur les routeurs le long
du chemin entre deux hôtes. UDP ne le supporte pas et nécessite des protocoles de niveau supérieur pour trier le contrôle
de flux des fragments. GCP utilise un contrôle de flux de bout en bout pour éviter que l'expéditeur envoie les données trop rapidement
au destinataire. pour le recevoir et le traiter de manière fiable.
Si le même message transmet les données plus rapidement que le récepteur ne peut le
gérer, le récepteur supprimera les données qui nécessiteront une retransmission, les retransmissions perdant du temps et des ressources réseau,
raison pour laquelle la plupart des mécanismes de contrôle de flux tentent de maximiser le transfert viol en minimisant les exigences de retransmission.
Vous pouvez par exemple avoir un PC avec un puissant vous envoyer des données à un PDA portable qui ne peut traiter des données
à un taux beaucoup plus bas
Le PDA doit donc réguler le flux de données afin que le contrôle de flux TZP de base
ne soit pas surchargé par des accusés de réception du destinataire lors de la réception des données transmises. EECP utilise
une fenêtre glissante pour contrôler le flux de données.
Windowing permettra à l'ordinateur destinataire d'annoncer le volume de données pouvant être reçu avant de transmettre un
accusé de réception à l'ordinateur émetteur.
Dans chaque segment TZP, le destinataire spécifiera dans le champ de la fenêtre de réception.
La quantité de données supplémentaires reçues en octets qu'il est disposé
à mettre en mémoire tampon pour la connexion, l'hôte émetteur ne peut envoyer
que la quantité de données qu'il a avant celle-ci.
Et dans un environnement VOIP, par exemple, qui utilise UDP même s’il n’ya pas de connexion physique
entre deux combinés impliqués dans un appel téléphonique, l’appel restera actif et l’expéditeur continuera joyeusement à envoyer
d’énormes quantités de données.
Même si le récepteur ne peut pas traiter les données reçues, UDP s'appuie sur les protocoles Hi-Lo pour mettre en œuvre
le contrôle de flux.
Une fois encore, TZP est orienté connexion et UDP est moins de connexion. TZP établira la connexion et
maintiendra la connexion pendant toute la transmission.
Une fois la transmission terminée, la session est terminée.
UDP ne configure pas de sessions et enverra simplement les données dans l’espoir que le destinataire les recevra.
Une fois encore, TZP implémente la fiabilité dans laquelle chaque segment transmis fait l'objet d'un accusé de réception
et si le segment a disparu, il est retransmis. UDP n'implémente pas la fiabilité.
Et une fois de plus, nous nous appuyons sur les protocoles Hailo pour mettre en œuvre une fiabilité éventuelle dans certains cas, tels
que la voix sur IP ou la vidéo transmise sur une infrastructure IP.
La fiabilité n'est pas requise.
Il ne sert à rien de retransmettre les derniers paquets vocaux. Par conséquent, une comparaison rapide entre UDP et TZP ou un protocole
fiable et un protocole au mieux des efforts ou peu fiable TZP est à nouveau orienté connexion.
Aucune donnée n'est transmise avant qu'une session ne soit établie. Une négociation à trois volets a lieu avant toute
transmission de données.
Il y a des accusés de réception des données reçues et des numéros de séquence pour suivre la transmission des données.
UDP, d’autre part, nécessite moins de connexion et ne suit pas les données et n’assure pas la livraison des données.
TCAP est une séquence de nombres.
UDP ne comprend pas les applications utilisant TZP, notamment la messagerie électronique HGP, tandis que les applications FGP utilisant UDP incluent les applications de diffusion vocale en continu telles que la
voix sur IP et les applications de diffusion vidéo en raison de la nature de la
VoIP ou de la vidéo.
Il n'y a aucune raison de retransmettre dans un environnement VOIP, le locuteur sera tenu de répéter ce qu'il a
dit.
Si l'auditeur était incapable de déchiffrer ce qui était communiqué.
Si vous avez déjà utilisé Skype à l'occasion, vous aurez peut-être l'impression que la personne qui parle parle est sous l'eau ou ressemble davantage
à une machine que la personne que vous connaissez qui parle.
Mais vous pouvez toujours être en mesure de comprendre ce qu'ils ont dit et ainsi, même si des données ont
été perdues, la conversation peut continuer.
Ou, si cela devient suffisamment grave, vous demanderez à l’orateur de répéter ce qu’il a dit dans un environnement de streaming vidéo.
Vous remarquerez peut-être qu'une partie de l'image n'est pas actualisée correctement, mais vous pouvez toujours suivre ce qui se passe
dans la vidéo en raison de la nature sensible du temps de la voix et de la vidéo.
Il est inutile de retransmettre des données et le TZP n'est donc pas utilisé dans ces environnements.
UDP est utilisé, donc UDP est un protocole de couche de transport.
Il réside au niveau de la couche lorsque le modèle fournit aux applications un accès à la couche réseau pour
toutes les couches 3 sans les mécanismes de surcharge des responsabilités comme indiqué ci-dessus.
C'est idéal pour les applications de voix sur IP ou vidéo.
C'est la connexion moins où un sens datagramme la destination centrale sans notification préalable à
l'appareil de destination.
Il n'y a pas de communication avant la transmission des données.
Les données arrivent juste au destinataire et il est prévu que le destinataire les traite.
UDP est capable de fournir une erreur très limitée en vérifiant que le datagramme UDP inclut
une valeur optionnelle permettant au périphérique destinataire de vérifier l'intégrité des données, l'en-tête UDP inclut également un
numéro de port de destination et si ce datagramme est dirigé vers Sur le code du périphérique récepteur,
un message de retour peut être transmis pour indiquer que ce code est inaccessible.
Je vais discuter des numéros de port plus en détail dans un instant.
C'est un concept très important à comprendre.
UDP fournit le meilleur si à la livraison.
Rien ne garantit que les données sont livrées, les paquets peuvent être mal dupliqués ou perdus sur le chemin
de la destination.
Il n'y a aucune garantie que la réception des protocoles nécessitera la fiabilité si nécessaire.
Ce ne sont pas non plus des fonctionnalités de récupération de données dans UDP.
Une fois encore, les protocoles Hiler devront récupérer les derniers paquets corrompus.
Par exemple, TFT a un mécanisme intégré pour gérer la perte de données et TFT P utilisant UDP a ses propres mécanismes de
séquençage et de retransmission, car il ne peut pas compter sur UDP pour mettre en œuvre la fiabilité.
La tête UDP est très simple.
Il a un numéro de port source 16 bits 16 mais le numéro de port à destination ainsi le numéro de port
utilisé par la source et un numéro de port utilisé par la destination.
Il possède un champ de longueur ETP de 16 bits qui spécifie la longueur en octets de tout le datagramme.
En d'autres termes, l'en-tête et les données ont une longueur minimale de 8 octets pour le datagramme UDP, car
c'est la longueur de l'en-tête.
Théoriquement, la taille maximale est de soixante-cinq mille cinq cent trente cinq octets.
Mais la version IP 4 imposera une limite maximale de soixante-cinq mille cinq cent sept octets.
Vous pouvez éventuellement utiliser une somme de contrôle UDP pour la vérification des erreurs.
Ceci est facultatif pour une version IP 4, mais pas pour une version IP 6.