1 00:00:00,240 --> 00:00:07,590 Informațiile pot fi segmentate sau împărțite în bucăți mai mici sau transmise pe un mediu fizic, 2 00:00:08,010 --> 00:00:15,040 unitatea maximă de transmisie sau golirea unei interfețe de ieșire depinde de mediul fizic. 3 00:00:15,090 --> 00:00:20,640 Ca exemplu, vă golesc de fântână Ethan Este 5400 de octeți. 4 00:00:20,850 --> 00:00:28,650 Cu toate acestea, TZP poate susține teoretic șaizeci și cinci de mii patru sute nouăzeci și cinci de octeți într-un singur 5 00:00:28,650 --> 00:00:29,380 pachet. 6 00:00:29,460 --> 00:00:35,370 Când aceasta este trimisă la straturile inferioare ale modelului de ozon care va trebui să 7 00:00:35,560 --> 00:00:42,330 fie împărțită în fragmente de transmisie pe mediul fizic care, de exemplu, suportă numai 50 sau 100 de octeți. 8 00:00:42,330 --> 00:00:49,890 Datele sunt așadar împărțite în bucăți mai mici, iar receptorul care utilizează TZP va trebui să pună din 9 00:00:49,890 --> 00:00:51,180 nou aceste fragmente. 10 00:00:51,510 --> 00:00:58,950 Dimensiunea maximă a segmentului sau MSA este cea mai mare cantitate de date în octeți pe care TZP este dispusă să o 11 00:00:58,950 --> 00:01:02,010 trimită într-un singur segment pentru cea mai bună performanță. 12 00:01:02,010 --> 00:01:08,700 MSA este suficient de mic pentru a evita fragmentarea Arpey care poate duce la retransmiteri 13 00:01:08,700 --> 00:01:15,550 excesive dacă există o pierdere de pachete DCP care acceptă ceva numit Maximum size segment și pauză. 14 00:01:15,600 --> 00:01:23,400 MT Descoperirea sau descoperirea maximă a unității de transmisie Porth cu expeditorul și receptorul poate determina 15 00:01:23,400 --> 00:01:31,260 automat ce unitate de transmisie maximă se află pe o cale între ele și TZP va pune 16 00:01:31,260 --> 00:01:39,840 doar suficiente date într-un singur pachet care se potrivește golului, evitând astfel fragmentarea pachetelor și evitând astfel cheltuielile asociate 17 00:01:39,840 --> 00:01:46,620 cu fragmentarea și punerea împreună a fragmentelor IP în descoperirea dvs. este opțională în 18 00:01:46,620 --> 00:01:55,440 versiunea IP 4 care a devenit acum obligatorie în versiunea IP 6 din cauza eficienței pe care aceasta o 19 00:01:55,860 --> 00:02:02,820 aduce la transmisia TZP și faptul că IP versiunea 6 nu suportă fragmentarea pe routere 20 00:02:03,420 --> 00:02:12,190 de-a lungul căii dintre două gazde UDP nu suportă acest lucru și necesită protocoale de nivel superior pentru a 21 00:02:12,550 --> 00:02:22,000 sorta controlul fluxului de fragmente GCP folosește controlul final al fluxului pentru a evita ca expeditorul să trimită date prea repede 22 00:02:22,000 --> 00:02:27,370 pentru receptor să o primească și să o proceseze fiabil. 23 00:02:27,580 --> 00:02:33,700 Dacă aceleași date transmit mai repede decât receptorul se poate ocupa, receptorul 24 00:02:33,700 --> 00:02:40,780 va scădea datele care vor necesita o retransmisie de retransmisie va pierde timpul și resursele de 25 00:02:40,780 --> 00:02:49,410 rețea, motiv pentru care majoritatea mecanismelor de control al fluxului încearcă să maximizeze transferul violat, minimizând cerințele de retransmisie. 26 00:02:49,470 --> 00:02:57,930 De exemplu, aveți un PC cu o putere puternică pe care o trimiteți la un PDA portabil, care poate procesa date numai 27 00:02:57,930 --> 00:03:00,400 la o rată mult mai mică. 28 00:03:00,420 --> 00:03:07,710 De aceea PDA trebuie să reglementeze fluxul de date astfel încât să nu fie copleșit în controlul 29 00:03:07,710 --> 00:03:15,400 fluxului de bază TZP este implementat prin recunoașterea de către receptorul recepționat a datelor transmise. CEEP folosește ceva numit 30 00:03:15,400 --> 00:03:19,440 o fereastră glisantă pentru a controla fluxul de date. 31 00:03:19,530 --> 00:03:25,810 Fereastra va permite computerului receptor să facă publicitate cât de mult poate primi date înainte de a transmite 32 00:03:25,810 --> 00:03:28,330 o confirmare către computerul care trimite. 33 00:03:28,780 --> 00:03:34,720 În fiecare segment TZP, receptorul va specifica în câmpul fereastra de primire. 34 00:03:34,870 --> 00:03:41,200 Cantitatea de date suplimentare primite în octeți care doresc să tamponeze pentru conexiunea gazdei de 35 00:03:41,200 --> 00:03:48,400 trimitere poate trimite doar până la acea cantitate de date înaintea lui Miss White atunci când confirmarea 36 00:03:48,400 --> 00:03:54,610 și actualizarea dimensiunii ferestrei de la UDP gazdă primită nu implementează controlul fluxului. 37 00:03:55,520 --> 00:04:02,090 Și într-un mediu VOIP ca exemplu care folosește UDP, chiar dacă nu există nici o conexiune fizică 38 00:04:02,090 --> 00:04:08,990 între două telefoane implicate într-un apel telefonic, apelul va rămâne în așteptare și expeditorul va continua cu merite să 39 00:04:08,990 --> 00:04:11,010 trimită cantități imense de date. 40 00:04:11,180 --> 00:04:18,770 Chiar dacă receptorul nu poate procesa datele primite, UDP se bazează pe protocoalele Hi-Lo pentru implementarea 41 00:04:18,770 --> 00:04:20,280 controlului fluxului. 42 00:04:20,480 --> 00:04:28,850 Încă o dată, TZP este orientată spre conexiune și UDP este conectată mai puțin. TZP va stabili conexiunea 43 00:04:29,300 --> 00:04:33,080 și va menține conexiunea în timpul întregii transmisii. 44 00:04:33,080 --> 00:04:37,220 Odată ce transmisia este finalizată, sesiunea este terminată. 45 00:04:37,280 --> 00:04:43,980 UDP nu configurează sesiunile și va trimite doar datele cu speranța că receptorul o va primi. 46 00:04:45,180 --> 00:04:52,770 Încă o dată, TZP implementează fiabilitatea în care fiecare segment transmis este recunoscut și dacă 47 00:04:52,770 --> 00:04:59,070 segmentul a dispărut, acesta este retransmis UDP nu pune în aplicare fiabilitatea. 48 00:04:59,220 --> 00:05:07,890 Și încă o dată se bazează pe protocoalele Hailo pentru a implementa orice fiabilitate, dacă este necesar în anumite cazuri, cum 49 00:05:07,890 --> 00:05:12,940 ar fi voice over IP sau video transmis printr-o infrastructură IP. 50 00:05:13,140 --> 00:05:15,550 Fiabilitatea nu este necesară. 51 00:05:15,600 --> 00:05:25,910 Nu există niciun punct de retransmitere a ultimelor pachete de voce, astfel încât o comparație rapidă între UDP și TZP sau un protocol fiabil 52 00:05:25,910 --> 00:05:33,870 și cel mai bun efort sau un protocol fiabil TZP încă o dată este orientat spre conexiune. 53 00:05:34,120 --> 00:05:41,440 Nu sunt transmise date înainte de stabilirea unei sesiuni, înainte de transmiterea 54 00:05:41,440 --> 00:05:42,930 oricăror date. 55 00:05:42,940 --> 00:05:49,130 Există confirmări ale datelor primite și ale numerelor de secvențe pentru a urmări transmiterea datelor. 56 00:05:49,510 --> 00:05:56,850 UDP, pe de altă parte, este mai puțin conectată și nu urmărește datele și nu asigură transmiterea datelor. 57 00:05:57,850 --> 00:06:00,080 TCAP este o secvență de numere. 58 00:06:00,190 --> 00:06:12,190 UDP nu aplicațiile care utilizează TZP includ emailurile HGP și aplicațiile FGP care utilizează UDP includ aplicații de streaming vocal cum ar 59 00:06:12,190 --> 00:06:18,370 fi voice over IP și aplicații de streaming video din cauza naturii 60 00:06:18,370 --> 00:06:20,400 VoIP sau video. 61 00:06:20,530 --> 00:06:28,270 Nu există niciun motiv pentru retransmiterea într-un mediu VOIP, vorbitorul va trebui să repete ceea ce a 62 00:06:28,270 --> 00:06:28,820 spus. 63 00:06:28,840 --> 00:06:33,960 Dacă ascultătorul nu a putut să descifreze ceea ce a fost comunicat. 64 00:06:34,450 --> 00:06:41,890 Dacă ați folosit vreodată Skype, s-ar putea să pară că persoana vorbită este sub apă sau sună mai mult 65 00:06:41,890 --> 00:06:45,570 ca o mașină decât persoana pe care o cunoașteți. 66 00:06:46,300 --> 00:06:52,240 Dar ați putea totuși să înțelegeți ceea ce au spus și astfel, chiar dacă datele au 67 00:06:52,240 --> 00:06:54,080 dispărut, conversația poate continua. 68 00:06:54,190 --> 00:07:01,580 Sau, dacă se face destul de rău, îl întrebați pe vorbitor să repete ceea ce au spus într-un mediu de streaming video. 69 00:07:01,600 --> 00:07:08,020 Este posibil să observați că o parte a imaginii nu este reîmprospătătoare în mod corespunzător, dar totuși 70 00:07:08,020 --> 00:07:13,990 puteți să urmăriți ce se întâmplă în videoclip din cauza naturii voce și a videoclipului. 71 00:07:14,050 --> 00:07:19,350 Este inutil retransmiterea datelor și astfel TZP nu este utilizat în aceste medii. 72 00:07:19,360 --> 00:07:24,780 UDP este utilizat astfel încât UDP este un protocol de strat de transport. 73 00:07:24,810 --> 00:07:32,430 Se află la nivelul stratului pentru modelul pe care îl furnizează aplicațiilor cu acces la stratul de 74 00:07:32,440 --> 00:07:38,390 rețea tot stratul 3, fără mecanismele de răspundere generală, așa cum sa discutat. 75 00:07:38,390 --> 00:07:42,380 Acesta este ideal pentru aplicații de voce prin IP sau video. 76 00:07:42,530 --> 00:07:49,730 Este o conexiune mai mică în cazul în care datagrama într-o singură direcție destinația centrală fără notificare prealabilă 77 00:07:49,730 --> 00:07:51,430 către dispozitivul de destinație. 78 00:07:51,500 --> 00:07:55,440 Nu există comunicare înainte de transmiterea datelor. 79 00:07:55,820 --> 00:08:01,690 Datele ajung doar la receptor și este de așteptat ca receptorul să se ocupe de aceste date. 80 00:08:02,030 --> 00:08:08,940 UDP este capabil să furnizeze o verificare foarte limitată a erorilor, datagrama UDP include o verificare opțională a unei 81 00:08:08,940 --> 00:08:16,080 anumite valori pe care dispozitivul de recepție îl poate utiliza pentru a testa integritatea datelor, antetul UDP include și un 82 00:08:16,080 --> 00:08:23,490 număr de port destinație și dacă acea datagramă este direcționată spre o rețea activă codul de pe dispozitivul de recepție 83 00:08:23,490 --> 00:08:29,900 poate fi transmis un mesaj de retur pentru a indica faptul că acest cod este inaccesibil. 84 00:08:29,910 --> 00:08:32,830 Voi discuta mai multe detalii în câteva momente. 85 00:08:33,090 --> 00:08:36,100 Este un concept foarte important de înțeles. 86 00:08:36,150 --> 00:08:39,170 UDP oferă cel mai bine dacă la livrare. 87 00:08:39,180 --> 00:08:47,160 Nu există nici o garanție că pachetele furnizate de date pot fi direcționate în mod nedorit duplicate sau pierdute 88 00:08:47,160 --> 00:08:48,840 în drum spre destinație. 89 00:08:48,870 --> 00:08:57,970 Nu există nici o garanție de primire a protocoalelor va trebui să pună în aplicare fiabilitatea, dacă este necesar. 90 00:08:58,030 --> 00:09:01,600 Ele nu sunt, de asemenea, caracteristici de recuperare a datelor în UDP. 91 00:09:01,600 --> 00:09:07,800 Din nou, protocoalele Hiler vor trebui să se recupereze din ultimele pachete corupte. 92 00:09:07,960 --> 00:09:17,440 TFT, ca exemplu, are un mecanism construit pentru a face față pierderii de date, iar TFT P utilizând UDP are propriile sale 93 00:09:17,530 --> 00:09:25,480 blocate în mecanismele de secvențiere și retransmisie, deoarece nu se poate baza pe UDP pentru a implementa fiabilitatea. 94 00:09:25,480 --> 00:09:27,650 Capul UDP este foarte simplu. 95 00:09:27,820 --> 00:09:35,810 Acesta are un port de 16 biți de port sursă 16, dar Port la numărul de destinație, astfel încât să fie specificat numărul 96 00:09:35,810 --> 00:09:40,780 de port utilizat de către sursă și un număr de port utilizat de destinație. 97 00:09:41,000 --> 00:09:47,500 Are un câmp de lungime ETP pe 16 biți care specifică lungimea în octeți a întregii datagrame. 98 00:09:47,510 --> 00:09:54,020 Cu alte cuvinte, antetul și datele, lungimea minimă pentru datagrama UDP este de 8 octeți, deoarece 99 00:09:54,020 --> 00:09:55,990 aceasta este lungimea antetului. 100 00:09:56,030 --> 00:10:01,550 Teoretic, dimensiunea maximă este de șaizeci și cinci de mii cinci sute treizeci și cinci de octeți. 101 00:10:01,740 --> 00:10:08,940 Dar versiunea IP 4 va impune o limită maximă de șaizeci și cinci de mii cinci sute șapte octeți. 102 00:10:09,080 --> 00:10:13,970 Opțional, pentru verificarea erorilor poate fi utilizată o sumă de control UDP. 103 00:10:13,970 --> 00:10:19,150 Aceasta este opțională o versiune IP 4 dar nu este opțională o versiune IP 6.