1
00:00:00,240 --> 00:00:07,590
Le informazioni possono essere segmentate o suddivise in blocchi più piccoli o la trasmissione attraverso un mezzo

2
00:00:08,010 --> 00:00:15,040
fisico l'unità di trasmissione massima o vuota di un'interfaccia in uscita dipende dal supporto fisico.

3
00:00:15,090 --> 00:00:20,640
Ad esempio ti svuotano di febbre Ethan È 5400 byte.

4
00:00:20,850 --> 00:00:29,380
Tuttavia TZP può teoricamente supportare sessantacinquemilaquattrocentonovantacinque byte in un unico pacchetto.

5
00:00:29,460 --> 00:00:35,370
Quando viene inviato agli strati inferiori del modello di ozono che dovrà essere suddiviso

6
00:00:35,560 --> 00:00:42,330
in frammenti per la trasmissione attraverso il supporto fisico che, ad esempio, supporta solo 50 o 100 byte.

7
00:00:42,330 --> 00:00:49,890
I dati vengono quindi suddivisi in blocchi più piccoli e il ricevitore che utilizza TZP dovrà rimettere insieme

8
00:00:49,890 --> 00:00:51,180
quei frammenti.

9
00:00:51,510 --> 00:00:58,950
La dimensione massima del segmento o MSA è la maggiore quantità di dati in byte che TZP è disposto a inviare in

10
00:00:58,950 --> 00:01:02,010
un singolo segmento per ottenere le migliori prestazioni.

11
00:01:02,010 --> 00:01:08,700
L'MSA è abbastanza piccolo da evitare la frammentazione di Arpey che può portare a ritrasmissioni eccessive

12
00:01:08,700 --> 00:01:15,550
se c'è una perdita di pacchetti di supporto DCP, qualcosa chiamato Dimensione massima del segmento e pausa.

13
00:01:15,600 --> 00:01:23,400
MT La scoperta o Porth discovery della unità di trasmissione massima con il mittente e il ricevitore possono

14
00:01:23,400 --> 00:01:31,260
determinare automaticamente quale unità di trasmissione massima si trova su un percorso tra loro e TZP metterà solo

15
00:01:31,260 --> 00:01:39,840
abbastanza dati in un singolo pacchetto che si adatta a vuoto evitando così la frammentazione dei pacchetti e evitando così

16
00:01:39,840 --> 00:01:46,620
il sovraccarico associato alla frammentazione e la raccolta dei frammenti di IP nella tua scoperta è

17
00:01:46,620 --> 00:01:55,440
opzionale nella versione 4 di IP che ora è diventata obbligatoria nella versione 6 di IP a causa dell'efficienza che porta

18
00:01:55,860 --> 00:02:02,820
alla trasmissione TZP e del fatto che IP la versione 6 non supporta la frammentazione sui

19
00:02:03,420 --> 00:02:12,190
router lungo il percorso tra due host UDP non supporta questo e richiede protocolli di livello superiore per risolvere il controllo

20
00:02:12,550 --> 00:02:22,000
del flusso dei frammenti GCP utilizza il controllo del flusso end to end per evitare che il mittente invii i dati troppo

21
00:02:22,000 --> 00:02:27,370
rapidamente per il ricevitore per riceverlo e elaborarlo in modo affidabile.

22
00:02:27,580 --> 00:02:33,700
Se la stessa trasmette i dati più velocemente di quanto il ricevitore sia in

23
00:02:33,700 --> 00:02:40,780
grado di gestire, i dati che richiederanno una ritrasmissione di ritrasmissione perderanno tempo e risorse di rete, motivo

24
00:02:40,780 --> 00:02:49,410
per cui la maggior parte dei meccanismi di controllo del flusso tenta di massimizzare il trasferimento violando minimizzando i requisiti di ritrasmissione.

25
00:02:49,470 --> 00:02:57,930
Ad esempio, è possibile avere un PC con un potente invio di dati a un PDA palmare che può elaborare solo i

26
00:02:57,930 --> 00:03:00,400
dati a una velocità molto inferiore.

27
00:03:00,420 --> 00:03:07,710
Il PDA dovrebbe quindi regolare il flusso di dati in modo che non venga travolto nel controllo del

28
00:03:07,710 --> 00:03:15,400
flusso di base TZP sia implementato dai riconoscimenti ricevuti dal ricevitore che riceve i dati trasmessi. EECP usa qualcosa chiamato

29
00:03:15,400 --> 00:03:19,440
una finestra scorrevole per controllare il flusso dei dati.

30
00:03:19,530 --> 00:03:25,810
Windowing consentirà al computer ricevente di pubblicizzare la quantità di dati che è possibile ricevere prima di

31
00:03:25,810 --> 00:03:28,330
trasmettere una conferma al computer mittente.

32
00:03:28,780 --> 00:03:34,720
In ogni segmento TZP il ricevitore specificherà nel campo della finestra di ricezione.

33
00:03:34,870 --> 00:03:41,200
La quantità di dati aggiuntivi ricevuti in byte che è disposta a bufferizzare per la connessione

34
00:03:41,200 --> 00:03:48,400
che l'host mittente può inviare solo fino a quella quantità di dati prima di Miss White quando il riconoscimento

35
00:03:48,400 --> 00:03:54,610
e l'aggiornamento della dimensione della finestra dall'host ricevente UDP non implementa il controllo di flusso.

36
00:03:55,520 --> 00:04:02,090
E in un ambiente VOIP come un esempio che utilizza UDP anche se non c'è alcuna connessione

37
00:04:02,090 --> 00:04:08,990
fisica tra due portatili coinvolti in una chiamata telefonica, la chiamata rimarrà attiva e il mittente continuerà a inviare

38
00:04:08,990 --> 00:04:11,010
allegramente enormi quantità di dati.

39
00:04:11,180 --> 00:04:18,770
Anche se il ricevitore non è in grado di elaborare i dati ricevuti, UDP si affida ai protocolli Hi-Lo per implementare

40
00:04:18,770 --> 00:04:20,280
il controllo del flusso.

41
00:04:20,480 --> 00:04:28,850
Ancora una volta TZP è orientato alla connessione e UDP è la connessione meno TZP stabilirà la connessione

42
00:04:29,300 --> 00:04:33,080
e manterrà la connessione durante l'intera trasmissione.

43
00:04:33,080 --> 00:04:37,220
Una volta completata la trasmissione, la sessione termina.

44
00:04:37,280 --> 00:04:43,980
UDP non imposta le sessioni e invierà semplicemente i dati nella speranza che il destinatario lo riceva.

45
00:04:45,180 --> 00:04:52,770
Ancora una volta TZP implementa l'affidabilità in cui ogni segmento trasmesso viene riconosciuto e

46
00:04:52,770 --> 00:04:59,070
se il segmento scompare viene ritrasmesso UDP non implementa l'affidabilità.

47
00:04:59,220 --> 00:05:07,890
E ancora una volta si affida ai protocolli Hailo per implementare qualsiasi affidabilità, se necessario, in alcuni casi,

48
00:05:07,890 --> 00:05:12,940
come Voice over IP o video trasmessi su un'infrastruttura IP.

49
00:05:13,140 --> 00:05:15,550
L'affidabilità non è richiesta.

50
00:05:15,600 --> 00:05:25,910
Non ha senso ritrasmettere gli ultimi pacchetti vocali, quindi un rapido confronto tra UDP e TZP o un protocollo affidabile

51
00:05:25,910 --> 00:05:33,870
e uno sforzo migliore o un TZP inaffidabile ancora una volta è orientato alla connessione.

52
00:05:34,120 --> 00:05:41,440
Nessun dato viene trasmesso prima che venga stabilita una sessione di handshake a tre vie prima che i

53
00:05:41,440 --> 00:05:42,930
dati vengano trasmessi.

54
00:05:42,940 --> 00:05:49,130
Vi sono conferme dei dati ricevuti e numeri di sequenza per tracciare la trasmissione dei dati.

55
00:05:49,510 --> 00:05:56,850
D'altra parte, UDP è meno connesso e non traccia i dati e non garantisce la consegna dei dati.

56
00:05:57,850 --> 00:06:00,080
TCAP è una sequenza di numeri.

57
00:06:00,190 --> 00:06:12,190
UDP non include le applicazioni che utilizzano TZP include le e-mail HGP e le applicazioni FGP che utilizzano UDP includono applicazioni di streaming vocale come

58
00:06:12,190 --> 00:06:18,370
Voice over IP e applicazioni di streaming video a causa della natura del

59
00:06:18,370 --> 00:06:20,400
VoIP o del video.

60
00:06:20,530 --> 00:06:28,270
Non c'è motivo di ritrasmettere in un ambiente VOIP a chi parla sarà richiesto di ripetere ciò che hanno

61
00:06:28,270 --> 00:06:28,820
detto.

62
00:06:28,840 --> 00:06:33,960
Se l'ascoltatore non è stato in grado di decifrare ciò che è stato comunicato.

63
00:06:34,450 --> 00:06:41,890
Se hai mai usato Skype a volte può sembrare che la persona che parla sia sott'acqua o suoni

64
00:06:41,890 --> 00:06:45,570
più come una macchina della persona che conosci.

65
00:06:46,300 --> 00:06:52,240
Ma potresti ancora essere in grado di capire cosa hanno detto e quindi anche se i dati sono andati

66
00:06:52,240 --> 00:06:54,080
persi, la conversazione può continuare.

67
00:06:54,190 --> 00:07:01,580
Oppure, se dovesse andare male, chiederebbe all'oratore di ripetere ciò che hanno detto in un ambiente di streaming video.

68
00:07:01,600 --> 00:07:08,020
Potresti notare che parte dell'immagine non viene aggiornata correttamente ma puoi comunque seguire ciò che accade

69
00:07:08,020 --> 00:07:13,990
nel video a causa della natura sensibile al tempo di voce e video.

70
00:07:14,050 --> 00:07:19,350
È inutile ritrasmettere i dati e quindi TZP non viene utilizzato in questi ambienti.

71
00:07:19,360 --> 00:07:24,780
UDP è usato così UDP è un protocollo di livello di trasporto.

72
00:07:24,810 --> 00:07:32,430
Risiede a livello per quando il modello fornisce alle applicazioni l'accesso al livello di rete su tutto

73
00:07:32,440 --> 00:07:38,390
il livello 3 senza il sovraccarico sui meccanismi di responsabilità come discusso.

74
00:07:38,390 --> 00:07:42,380
Questo è l'ideale per applicazioni voice over IP o video.

75
00:07:42,530 --> 00:07:49,730
È la connessione meno dove un datagramma in un modo la destinazione centrale senza notifica anticipata al

76
00:07:49,730 --> 00:07:51,430
dispositivo di destinazione.

77
00:07:51,500 --> 00:07:55,440
Non c'è comunicazione prima della trasmissione dei dati.

78
00:07:55,820 --> 00:08:01,690
I dati arrivano al destinatario e si prevede che il destinatario gestisca tali dati.

79
00:08:02,030 --> 00:08:08,940
UDP è in grado di fornire un controllo degli errori molto limitato il datagramma UDP include un controllo

80
00:08:08,940 --> 00:08:16,080
facoltativo di un valore che il dispositivo ricevente può utilizzare per testare l'integrità dei dati l'intestazione UDP include

81
00:08:16,080 --> 00:08:23,490
anche un numero di porta di destinazione e se tale datagramma è diretto ad un attivo codice sul dispositivo

82
00:08:23,490 --> 00:08:29,900
ricevente può essere trasmesso un messaggio di ritorno per indicare che quel codice è irraggiungibile.

83
00:08:29,910 --> 00:08:32,830
Ho intenzione di discutere i numeri di porta in modo più dettagliato in un momento.

84
00:08:33,090 --> 00:08:36,100
È un concetto molto importante da capire.

85
00:08:36,150 --> 00:08:39,170
UDP fornisce il meglio se alla consegna.

86
00:08:39,180 --> 00:08:47,160
Non vi è alcuna garanzia che i dati vengano consegnati, i pacchetti possono essere indirizzati erroneamente duplicati o persi durante il

87
00:08:47,160 --> 00:08:48,840
tragitto verso la destinazione.

88
00:08:48,870 --> 00:08:57,970
Non c'è alcuna garanzia di ricezione dei protocolli che dovranno implementare l'affidabilità se necessario.

89
00:08:58,030 --> 00:09:01,600
Non sono inoltre presenti funzionalità di recupero dati in UDP.

90
00:09:01,600 --> 00:09:07,800
Ancora una volta i protocolli Hiler dovranno recuperare dagli ultimi pacchetti corrotti.

91
00:09:07,960 --> 00:09:17,440
TFT come esempio ha un meccanismo integrato per gestire la perdita di dati e TFT P usando UDP ha i propri

92
00:09:17,530 --> 00:09:25,480
meccanismi di sequencing e di ritrasmissione in quanto non può fare affidamento su UDP per implementare l'affidabilità.

93
00:09:25,480 --> 00:09:27,650
La testa UDP è molto semplice.

94
00:09:27,820 --> 00:09:35,810
Ha una porta 16 bit numero 16 ma porta a numero di destinazione in modo tale da specificare il numero

95
00:09:35,810 --> 00:09:40,780
di porta utilizzato dall'origine e un numero di porta utilizzato dalla destinazione.

96
00:09:41,000 --> 00:09:47,500
Ha un campo di lunghezza ETP a 16 bit che specifica la lunghezza in byte dell'intero datagramma.

97
00:09:47,510 --> 00:09:54,020
In altre parole l'intestazione e i dati la lunghezza minima per il datagramma UDP è di 8 byte

98
00:09:54,020 --> 00:09:55,990
perché è la lunghezza dell'intestazione.

99
00:09:56,030 --> 00:10:01,550
Teoricamente la dimensione massima è di sessantacinquemilacinquecentotrentacinque byte.

100
00:10:01,740 --> 00:10:08,940
Ma la versione 4 di IP imporrà un limite massimo di sessantacinquemilaseicentosette byte.

101
00:10:09,080 --> 00:10:13,970
Facoltativamente è possibile utilizzare un checksum UDP per il controllo degli errori.

102
00:10:13,970 --> 00:10:19,150
È facoltativo un IP versione 4 ma non è opzionale una versione IP 6.