1
00:00:00,240 --> 00:00:07,590
Les informations peuvent être segmentées ou divisées en fragments plus petits ou être transmises sur un

2
00:00:08,010 --> 00:00:15,040
support physique. L'unité de transmission maximale ou vider une interface sortante dépend du support physique.

3
00:00:15,090 --> 00:00:20,640
A titre d'exemple, ils vous vident de la première Ethan. Il s'agit de 5400 octets.

4
00:00:20,850 --> 00:00:28,650
Cependant, TZP peut théoriquement prendre en charge soixante cinq mille quatre cent quatre vingt quinze octets dans un seul

5
00:00:28,650 --> 00:00:29,380
paquet.

6
00:00:29,460 --> 00:00:35,370
Lorsque cela est envoyé aux couches inférieures du modèle d'ozone, vous devrez le diviser en fragments

7
00:00:35,560 --> 00:00:42,330
pour le transmettre sur le support physique, qui ne prend en charge que 50 ou 100 octets, par exemple.

8
00:00:42,330 --> 00:00:49,890
Les données sont donc divisées en fragments plus petits et le récepteur utilisant TZP devra rassembler ces fragments

9
00:00:49,890 --> 00:00:51,180
à nouveau.

10
00:00:51,510 --> 00:00:58,950
La taille maximale du segment ou MSA est la plus grande quantité de données en octets que TZP est prête à envoyer

11
00:00:58,950 --> 00:01:02,010
dans un seul segment pour des performances optimales.

12
00:01:02,010 --> 00:01:08,700
Le MSA est suffisamment petit pour éviter la fragmentation d'Arpey, ce qui peut entraîner des retransmissions excessives en cas

13
00:01:08,700 --> 00:01:15,550
de perte de paquets. Le protocole DCP prend en charge ce que l'on appelle Taille maximale du segment et pause.

14
00:01:15,600 --> 00:01:23,400
MT Votre découverte ou découverte d'unité de transmission maximum avec l'expéditeur et le destinataire peuvent déterminer automatiquement quelle

15
00:01:23,400 --> 00:01:31,260
est l'unité de transmission maximale sur un chemin entre eux et TZP ne mettra que suffisamment de données dans

16
00:01:31,260 --> 00:01:39,840
un seul paquet qui correspond à ce vide, évitant ainsi la fragmentation des paquets et Ainsi, éviter la surcharge associée

17
00:01:39,840 --> 00:01:46,620
à la fragmentation et l'assemblage des fragments IP dans votre découverte est facultatif dans IP version

18
00:01:46,620 --> 00:01:55,440
4, qui est désormais obligatoire dans IP version 6 en raison de l'efficacité apportée à la transmission TZP et du fait

19
00:01:55,860 --> 00:02:02,820
que IP la version 6 ne prend pas en charge la fragmentation sur les routeurs le long

20
00:02:03,420 --> 00:02:12,190
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

21
00:02:12,550 --> 00:02:22,000
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

22
00:02:22,000 --> 00:02:27,370
au destinataire. pour le recevoir et le traiter de manière fiable.

23
00:02:27,580 --> 00:02:33,700
Si le même message transmet les données plus rapidement que le récepteur ne peut le

24
00:02:33,700 --> 00:02:40,780
gérer, le récepteur supprimera les données qui nécessiteront une retransmission, les retransmissions perdant du temps et des ressources réseau,

25
00:02:40,780 --> 00:02:49,410
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.

26
00:02:49,470 --> 00:02:57,930
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

27
00:02:57,930 --> 00:03:00,400
à un taux beaucoup plus bas

28
00:03:00,420 --> 00:03:07,710
Le PDA doit donc réguler le flux de données afin que le contrôle de flux TZP de base

29
00:03:07,710 --> 00:03:15,400
ne soit pas surchargé par des accusés de réception du destinataire lors de la réception des données transmises. EECP utilise

30
00:03:15,400 --> 00:03:19,440
une fenêtre glissante pour contrôler le flux de données.

31
00:03:19,530 --> 00:03:25,810
Windowing permettra à l'ordinateur destinataire d'annoncer le volume de données pouvant être reçu avant de transmettre un

32
00:03:25,810 --> 00:03:28,330
accusé de réception à l'ordinateur émetteur.

33
00:03:28,780 --> 00:03:34,720
Dans chaque segment TZP, le destinataire spécifiera dans le champ de la fenêtre de réception.

34
00:03:34,870 --> 00:03:41,200
La quantité de données supplémentaires reçues en octets qu'il est disposé

35
00:03:41,200 --> 00:03:48,400
à mettre en mémoire tampon pour la connexion, l'hôte émetteur ne peut envoyer

36
00:03:48,400 --> 00:03:54,610
que la quantité de données qu'il a avant celle-ci.

37
00:03:55,520 --> 00:04:02,090
Et dans un environnement VOIP, par exemple, qui utilise UDP même s’il n’ya pas de connexion physique

38
00:04:02,090 --> 00:04:08,990
entre deux combinés impliqués dans un appel téléphonique, l’appel restera actif et l’expéditeur continuera joyeusement à envoyer

39
00:04:08,990 --> 00:04:11,010
d’énormes quantités de données.

40
00:04:11,180 --> 00:04:18,770
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

41
00:04:18,770 --> 00:04:20,280
le contrôle de flux.

42
00:04:20,480 --> 00:04:28,850
Une fois encore, TZP est orienté connexion et UDP est moins de connexion. TZP établira la connexion et

43
00:04:29,300 --> 00:04:33,080
maintiendra la connexion pendant toute la transmission.

44
00:04:33,080 --> 00:04:37,220
Une fois la transmission terminée, la session est terminée.

45
00:04:37,280 --> 00:04:43,980
UDP ne configure pas de sessions et enverra simplement les données dans l’espoir que le destinataire les recevra.

46
00:04:45,180 --> 00:04:52,770
Une fois encore, TZP implémente la fiabilité dans laquelle chaque segment transmis fait l'objet d'un accusé de réception

47
00:04:52,770 --> 00:04:59,070
et si le segment a disparu, il est retransmis. UDP n'implémente pas la fiabilité.

48
00:04:59,220 --> 00:05:07,890
Et une fois de plus, nous nous appuyons sur les protocoles Hailo pour mettre en œuvre une fiabilité éventuelle dans certains cas, tels

49
00:05:07,890 --> 00:05:12,940
que la voix sur IP ou la vidéo transmise sur une infrastructure IP.

50
00:05:13,140 --> 00:05:15,550
La fiabilité n'est pas requise.

51
00:05:15,600 --> 00:05:25,910
Il ne sert à rien de retransmettre les derniers paquets vocaux. Par conséquent, une comparaison rapide entre UDP et TZP ou un protocole

52
00:05:25,910 --> 00:05:33,870
fiable et un protocole au mieux des efforts ou peu fiable TZP est à nouveau orienté connexion.

53
00:05:34,120 --> 00:05:41,440
Aucune donnée n'est transmise avant qu'une session ne soit établie. Une négociation à trois volets a lieu avant toute

54
00:05:41,440 --> 00:05:42,930
transmission de données.

55
00:05:42,940 --> 00:05:49,130
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.

56
00:05:49,510 --> 00:05:56,850
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.

57
00:05:57,850 --> 00:06:00,080
TCAP est une séquence de nombres.

58
00:06:00,190 --> 00:06:12,190
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

59
00:06:12,190 --> 00:06:18,370
voix sur IP et les applications de diffusion vidéo en raison de la nature de la

60
00:06:18,370 --> 00:06:20,400
VoIP ou de la vidéo.

61
00:06:20,530 --> 00:06:28,270
Il n'y a aucune raison de retransmettre dans un environnement VOIP, le locuteur sera tenu de répéter ce qu'il a

62
00:06:28,270 --> 00:06:28,820
dit.

63
00:06:28,840 --> 00:06:33,960
Si l'auditeur était incapable de déchiffrer ce qui était communiqué.

64
00:06:34,450 --> 00:06:41,890
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

65
00:06:41,890 --> 00:06:45,570
à une machine que la personne que vous connaissez qui parle.

66
00:06:46,300 --> 00:06:52,240
Mais vous pouvez toujours être en mesure de comprendre ce qu'ils ont dit et ainsi, même si des données ont

67
00:06:52,240 --> 00:06:54,080
été perdues, la conversation peut continuer.

68
00:06:54,190 --> 00:07:01,580
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.

69
00:07:01,600 --> 00:07:08,020
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

70
00:07:08,020 --> 00:07:13,990
dans la vidéo en raison de la nature sensible du temps de la voix et de la vidéo.

71
00:07:14,050 --> 00:07:19,350
Il est inutile de retransmettre des données et le TZP n'est donc pas utilisé dans ces environnements.

72
00:07:19,360 --> 00:07:24,780
UDP est utilisé, donc UDP est un protocole de couche de transport.

73
00:07:24,810 --> 00:07:32,430
Il réside au niveau de la couche lorsque le modèle fournit aux applications un accès à la couche réseau pour

74
00:07:32,440 --> 00:07:38,390
toutes les couches 3 sans les mécanismes de surcharge des responsabilités comme indiqué ci-dessus.

75
00:07:38,390 --> 00:07:42,380
C'est idéal pour les applications de voix sur IP ou vidéo.

76
00:07:42,530 --> 00:07:49,730
C'est la connexion moins où un sens datagramme la destination centrale sans notification préalable à

77
00:07:49,730 --> 00:07:51,430
l'appareil de destination.

78
00:07:51,500 --> 00:07:55,440
Il n'y a pas de communication avant la transmission des données.

79
00:07:55,820 --> 00:08:01,690
Les données arrivent juste au destinataire et il est prévu que le destinataire les traite.

80
00:08:02,030 --> 00:08:08,940
UDP est capable de fournir une erreur très limitée en vérifiant que le datagramme UDP inclut

81
00:08:08,940 --> 00:08:16,080
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

82
00:08:16,080 --> 00:08:23,490
numéro de port de destination et si ce datagramme est dirigé vers Sur le code du périphérique récepteur,

83
00:08:23,490 --> 00:08:29,900
un message de retour peut être transmis pour indiquer que ce code est inaccessible.

84
00:08:29,910 --> 00:08:32,830
Je vais discuter des numéros de port plus en détail dans un instant.

85
00:08:33,090 --> 00:08:36,100
C'est un concept très important à comprendre.

86
00:08:36,150 --> 00:08:39,170
UDP fournit le meilleur si à la livraison.

87
00:08:39,180 --> 00:08:47,160
Rien ne garantit que les données sont livrées, les paquets peuvent être mal dupliqués ou perdus sur le chemin

88
00:08:47,160 --> 00:08:48,840
de la destination.

89
00:08:48,870 --> 00:08:57,970
Il n'y a aucune garantie que la réception des protocoles nécessitera la fiabilité si nécessaire.

90
00:08:58,030 --> 00:09:01,600
Ce ne sont pas non plus des fonctionnalités de récupération de données dans UDP.

91
00:09:01,600 --> 00:09:07,800
Une fois encore, les protocoles Hiler devront récupérer les derniers paquets corrompus.

92
00:09:07,960 --> 00:09:17,440
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

93
00:09:17,530 --> 00:09:25,480
séquençage et de retransmission, car il ne peut pas compter sur UDP pour mettre en œuvre la fiabilité.

94
00:09:25,480 --> 00:09:27,650
La tête UDP est très simple.

95
00:09:27,820 --> 00:09:35,810
Il a un numéro de port source 16 bits 16 mais le numéro de port à destination ainsi le numéro de port

96
00:09:35,810 --> 00:09:40,780
utilisé par la source et un numéro de port utilisé par la destination.

97
00:09:41,000 --> 00:09:47,500
Il possède un champ de longueur ETP de 16 bits qui spécifie la longueur en octets de tout le datagramme.

98
00:09:47,510 --> 00:09:54,020
En d'autres termes, l'en-tête et les données ont une longueur minimale de 8 octets pour le datagramme UDP, car

99
00:09:54,020 --> 00:09:55,990
c'est la longueur de l'en-tête.

100
00:09:56,030 --> 00:10:01,550
Théoriquement, la taille maximale est de soixante-cinq mille cinq cent trente cinq octets.

101
00:10:01,740 --> 00:10:08,940
Mais la version IP 4 imposera une limite maximale de soixante-cinq mille cinq cent sept octets.

102
00:10:09,080 --> 00:10:13,970
Vous pouvez éventuellement utiliser une somme de contrôle UDP pour la vérification des erreurs.

103
00:10:13,970 --> 00:10:19,150
Ceci est facultatif pour une version IP 4, mais pas pour une version IP 6.