WEBVTT 00:00.090 --> 00:01.020 Jason: In deze les 00:01.020 --> 00:03.480 gaan we het hebben over IP-protocoltypes, 00:03.480 --> 00:05.637 waaronder TCP, UDP en de concepten 00:05.637 --> 00:07.650 van verbindingsloze versus verbindingsgerichte 00:07.650 --> 00:10.020 methoden. 00:10.020 --> 00:12.300 Wat is TCP nu eigenlijk? 00:12.300 --> 00:15.270 TCP is een transmissiecontroleprotocol. 00:15.270 --> 00:17.340 Het is een verbindingsgeoriënteerd protocol, 00:17.340 --> 00:18.990 wat betekent dat het een betrouwbare 00:18.990 --> 00:22.080 manier is om segmenten over ons netwerk te transporteren. 00:22.080 --> 00:23.580 Als er nu een segment wordt gedropt, 00:23.580 --> 00:25.770 zal het protocol elke keer om bevestiging 00:25.770 --> 00:26.603 vragen. 00:26.603 --> 00:28.890 En als het die bevestiging niet krijgt, gaat 00:28.890 --> 00:31.530 het dat stukje informatie opnieuw versturen. 00:31.530 --> 00:34.410 Daarom noemen we dit een verbindingsvol protocol omdat het een 00:34.410 --> 00:36.960 soort tweerichtingsverkeer heeft waarbij ik je informatie 00:36.960 --> 00:38.280 stuur en ik verifieer of je het 00:38.280 --> 00:40.200 echt hebt ontvangen door te luisteren of 00:40.200 --> 00:43.170 je het hebt ontvangen en je mij een antwoord geeft. 00:43.170 --> 00:44.640 Laten we nu even kijken naar dit kleine 00:44.640 --> 00:46.230 diagram hier op het scherm. 00:46.230 --> 00:48.210 Je zult zien dat ik links een client 00:48.210 --> 00:49.800 heb en rechts een server. 00:49.800 --> 00:52.860 Nu stuurt de client een zogenaamd syn pakket, 00:52.860 --> 00:54.510 of synchronisatie pakket, 00:54.510 --> 00:55.950 naar de server. 00:55.950 --> 00:57.240 Als de server dat ontvangt, 00:57.240 --> 00:58.170 stuurt hij een synchronisatiebevestiging 00:58.170 --> 01:02.580 terug naar de client, bekend als een syn ack. 01:02.580 --> 01:04.740 Als de client die bevestiging krijgt, stuurt 01:04.740 --> 01:07.380 hij zijn eigen bevestiging terug naar de server. 01:07.380 --> 01:09.060 Dit staat bekend als de ack. 01:09.060 --> 01:11.940 Als we nu deze syn, syn ack, ack doen, dan 01:11.940 --> 01:15.030 noemen we dit een driezijdige handdruk. 01:15.030 --> 01:16.807 In wezen is het de client die zegt: "Hé 01:16.807 --> 01:21.367 server, ben je klaar om informatie te krijgen? En dan zegt de server: "Natuurlijk. 01:21.367 --> 01:21.367 Waarom niet? 01:21.367 --> 01:22.920 "Stuur me wat informatie. En de klant zegt: 01:22.920 --> 01:25.440 "Oké, hier komt het. En dan begint de transmissie omdat we 01:25.440 --> 01:27.630 die driezijdige handdruk hebben 01:27.630 --> 01:29.940 vastgesteld en we weten dat beide kanten 01:29.940 --> 01:32.737 klaar zijn om te communiceren. 01:32.737 --> 01:33.937 "Ben je er klaar voor? "Ja, dat 01:33.937 --> 01:35.107 ben ik. "Hier komt 01:35.107 --> 01:36.810 het. Elke keer dat deze gegevens, die 01:36.810 --> 01:39.150 we een segment noemen, over het netwerk worden 01:39.150 --> 01:40.710 verzonden, wordt er een bevestiging 01:40.710 --> 01:43.080 ontvangen die ons vertelt dat er succesvolle 01:43.080 --> 01:45.030 communicatie in twee richtingen heeft 01:45.030 --> 01:46.980 plaatsgevonden. 01:46.980 --> 01:48.600 Als deze server verwacht 100 01:48.600 --> 01:50.370 stukjes informatie te krijgen, 01:50.370 --> 01:52.500 maar er maar 98 van krijgt, zal hij tegen 01:52.500 --> 01:53.587 de client zeggen: "Hé, 01:53.587 --> 01:56.347 je zei dat je me 100 dingen zou sturen, "maar je hebt 01:56.347 --> 01:58.177 er maar 98 gestuurd. 01:58.177 --> 02:00.450 "Stuur me die twee dingen die ik mis. En dan vindt er een hertransmissie 02:00.450 --> 02:02.730 plaats. 02:02.730 --> 02:03.563 Op deze manier kan de 02:03.563 --> 02:05.310 communicatie voor ons verlopen en kunnen 02:05.310 --> 02:06.240 we er altijd zeker van 02:06.240 --> 02:07.470 zijn dat we krijgen wat we zouden 02:07.470 --> 02:09.450 moeten krijgen, omdat we de pakketten opnieuw 02:09.450 --> 02:10.920 over het netwerk sturen. 02:10.920 --> 02:13.170 Nu wordt dit gebruikt voor alle netwerkgegevens 02:13.170 --> 02:16.830 waarvan verzekerd moet worden dat ze op hun eindbestemming komen. 02:16.830 --> 02:19.470 Ik zie dit als een soort aangetekende post. 02:19.470 --> 02:22.440 Als ik bijvoorbeeld een bericht naar de belastingdienst wil sturen, wil 02:22.440 --> 02:23.970 ik er zeker van zijn dat ze het krijgen 02:23.970 --> 02:25.620 en dat het niet zoekraakt in de post. 02:25.620 --> 02:27.630 Dus ik betaal misschien wat extra geld voor een gewaarmerkt 02:27.630 --> 02:29.160 ontvangstbewijs dat ze moeten ondertekenen 02:29.160 --> 02:31.080 als het daar aankomt, en dat wordt dan naar mij 02:31.080 --> 02:32.820 teruggestuurd. 02:32.820 --> 02:33.653 Op deze manier weet ik, 02:33.653 --> 02:34.740 als ik dat bonnetje terugkrijg, 02:34.740 --> 02:37.500 dat de belastingdienst mijn postpakket heeft ontvangen. 02:37.500 --> 02:39.960 Zo werkt TCP. 02:39.960 --> 02:41.220 Aan de andere kant hebben 02:41.220 --> 02:44.250 we een ander protocol dat bekend staat als UDP. 02:44.250 --> 02:47.250 UDP is wat we noemen een verbindingsloos protocol, wat betekent 02:47.250 --> 02:49.770 dat het niet hoeft te wachten op verbindingen. 02:49.770 --> 02:52.830 UDP staat voor User Datagram Protocol. 02:52.830 --> 02:54.270 En de reden waarom we het een datagram 02:54.270 --> 02:56.160 noemen is omdat je dit soort gegevens gebruikt 02:56.160 --> 02:57.750 als je UDP gebruikt. 02:57.750 --> 02:59.220 Het heet een datagram. 02:59.220 --> 03:01.317 Als we het nu over UDP hebben, UDP is onbetrouwbaar 03:01.317 --> 03:03.060 en het verzendt segmenten die datagrammen 03:03.060 --> 03:05.490 worden genoemd. 03:05.490 --> 03:06.510 En als ze worden gedropt, 03:06.510 --> 03:09.000 weet de afzender niet eens dat het is gebeurd. 03:09.000 --> 03:10.830 Nu, waarom zou ik dingen willen verzenden waarvan 03:10.830 --> 03:12.300 de afzender niet op de hoogte is en ik 03:12.300 --> 03:14.220 geen enkele vorm van ontvangst krijg? 03:14.220 --> 03:17.850 Welnu, UDP is echt goed voor audio en visuele streaming omdat je veel gegevens 03:17.850 --> 03:19.920 verstuurt en er veel minder overhead is 03:19.920 --> 03:22.620 wanneer je UDP gebruikt, omdat we niet die constante 03:22.620 --> 03:24.810 driewegs handdruk hebben om het tot stand 03:24.810 --> 03:25.950 te brengen en we niet alle 03:25.950 --> 03:27.840 checks and balances hebben die geassocieerd 03:27.840 --> 03:30.840 worden met het gebruik van TCP. 03:30.840 --> 03:32.520 Dus door UDP te gebruiken kun 03:32.520 --> 03:35.190 je de prestaties van je netwerk echt verhogen 03:35.190 --> 03:37.800 omdat je geen heruitzendingen hebt. 03:37.800 --> 03:39.870 Uiteindelijk laat je alleen maar informatie vallen. 03:39.870 --> 03:41.490 Is dat niet slecht? 03:41.490 --> 03:43.530 Waarom zouden we informatie willen laten vallen? 03:43.530 --> 03:45.300 Nou, voor bepaalde toepassingen 03:45.300 --> 03:46.740 maakt het echt niet uit. 03:46.740 --> 03:49.440 Je streamt nu bijvoorbeeld deze video. 03:49.440 --> 03:52.110 En als ik 1/100 van een seconde weg zou vallen, 03:52.110 --> 03:53.520 zou je het dan merken? 03:53.520 --> 03:54.960 Nou, dat zou je waarschijnlijk 03:54.960 --> 03:56.820 niet en daarom is UDP zo goed omdat we hier 03:56.820 --> 03:59.520 1/100 van de tijd kunnen laten vallen en je zult het eigenlijk 03:59.520 --> 04:01.320 nooit merken en er zal geen heruitzending 04:01.320 --> 04:03.120 plaatsvinden. 04:03.120 --> 04:04.740 Maar met TCP zal het leiden tot veel meer 04:04.740 --> 04:06.300 bufferen omdat je moet wachten, en het 04:06.300 --> 04:07.440 dan opnieuw naar je toegestuurd 04:07.440 --> 04:08.670 moet krijgen, en het dan op de juiste 04:08.670 --> 04:09.810 plaats moet zetten, en het dan 04:09.810 --> 04:11.250 moet afspelen. 04:11.250 --> 04:13.770 En dus, vanwege die erkenning en die overhead, 04:13.770 --> 04:15.870 wordt deze video voor elke seconde uiteindelijk 04:15.870 --> 04:17.880 veel groter en gebruikt hij veel meer 04:17.880 --> 04:19.830 bandbreedte. 04:19.830 --> 04:21.150 En dat is een van de belangrijkste 04:21.150 --> 04:24.660 redenen waarom we UDP gebruiken voor het streamen van video en audio. 04:24.660 --> 04:28.740 Laten we nu een korte samenvatting geven van TCP versus UDP. 04:28.740 --> 04:31.410 Want dit is echt een heel belangrijk concept. 04:31.410 --> 04:33.600 Als je nu je aantekeningen bij de hand hebt, zou 04:33.600 --> 04:35.160 ik deze grafiek opschrijven die 04:35.160 --> 04:36.420 ik je nu ga vertellen terwijl 04:36.420 --> 04:38.520 we het hebben over TCP versus UDP. 04:38.520 --> 04:40.770 Omdat het echt zo belangrijk is. 04:40.770 --> 04:43.380 Ten eerste is TCP betrouwbaar, het heeft een 04:43.380 --> 04:44.820 drie-wegs handdruk, waar 04:44.820 --> 04:47.040 UDP niet erg betrouwbaar is. 04:47.040 --> 04:48.540 Het is een onbetrouwbaar protocol 04:48.540 --> 04:51.180 omdat er geen driewegs handdruk is. 04:51.180 --> 04:53.490 TCP is wat we noemen een verbindingsgeoriënteerd 04:53.490 --> 04:55.560 of een verbindingsvol protocol omdat 04:55.560 --> 04:56.880 we die driewegs handdruk 04:56.880 --> 04:57.960 hebben in de bevestigingen, 04:57.960 --> 05:00.660 maar UDP is verbindingsloos. 05:00.660 --> 05:02.550 Het is een methode van vuur en vergeten. 05:02.550 --> 05:04.200 Ik begin gewoon informatie 05:04.200 --> 05:06.660 te sturen en hopelijk krijg je die. 05:06.660 --> 05:10.170 TCP gebruikt segment heruitzending en flow control dat wordt 05:10.170 --> 05:12.030 afgehandeld door windowing. 05:12.030 --> 05:13.230 UDP daarentegen kent 05:13.230 --> 05:16.230 geen hertransmissie en geen windowing. 05:16.230 --> 05:17.160 Met TCP hebben we segmentatie 05:17.160 --> 05:19.140 van onze opeenvolging van al onze verschillende 05:19.140 --> 05:20.820 segmenten. 05:20.820 --> 05:23.370 Met UDP is er geen opeenvolging. 05:23.370 --> 05:25.530 Wat dit betekent is dat als ik alles verstuur, 05:25.530 --> 05:27.570 ik het in de juiste volgorde verstuur, van 05:27.570 --> 05:28.710 één tot honderd. 05:28.710 --> 05:31.260 Ik doe dit voor zowel TCP als UDP. 05:31.260 --> 05:32.910 Nu, als je een aantal van die stukjes 05:32.910 --> 05:34.350 mist, of ze komen in een andere 05:34.350 --> 05:36.480 volgorde aan omdat ze een ander pad nemen over 05:36.480 --> 05:37.500 het netwerk, met TCP zijn 05:37.500 --> 05:38.520 ze in volgorde, dus het 05:38.520 --> 05:40.137 weet dat je er één naar 1000 hebt en 05:40.137 --> 05:42.420 het zet ze terug in de juiste volgorde. 05:42.420 --> 05:43.440 Met UDP, hoe ze ook 05:43.440 --> 05:44.850 binnenkomen, dat is hoe 05:44.850 --> 05:46.650 het wordt uitgezonden. 05:46.650 --> 05:48.030 En dus kan het komen 05:48.030 --> 05:49.230 in één, 50, twee, 05:49.230 --> 05:50.910 500, drie, vier, vijf, 05:50.910 --> 05:55.230 zes, 20, in elke willekeurige volgorde. 05:55.230 --> 05:56.580 En zo zul je het horen. 05:56.580 --> 05:59.010 Dus bij video kan het zijn dat je een beetje springerigheid 05:59.010 --> 06:00.780 hoort, of een beetje hoge piepjes, of iets 06:00.780 --> 06:01.740 dergelijks, omdat een 06:01.740 --> 06:04.320 van die frames misschien niet in de juiste volgorde staat. 06:04.320 --> 06:05.550 Als we nu teruggaan naar 06:05.550 --> 06:08.010 TCP, zal het elk van deze segmenten erkennen. 06:08.010 --> 06:09.780 En dus hebben we erkenning. 06:09.780 --> 06:10.680 Als ik het niet krijg, 06:10.680 --> 06:11.513 weet ik dat ik het niet 06:11.513 --> 06:13.650 kreeg en kan ik het opnieuw naar me toe laten zenden 06:13.650 --> 06:15.000 en het dan opnieuw krijgen. 06:15.000 --> 06:17.190 Met UDP is er geen bevestiging. 06:17.190 --> 06:20.220 Dus nogmaals, UDP heeft veel minder overhead omdat 06:20.220 --> 06:21.540 er geen verbinding is, 06:21.540 --> 06:23.790 geen windowing, geen heruitzending, 06:23.790 --> 06:26.610 geen sequencing en geen bevestiging. 06:26.610 --> 06:28.620 Als je nu iets daar moet krijgen en je wilt 06:28.620 --> 06:30.870 er zeker van zijn dat de persoon het heeft gekregen, 06:30.870 --> 06:34.590 dan moet je echt TCP gebruiken als het protocol van je keuze. 06:34.590 --> 06:36.930 En daarom gaan we TCP echt gebruiken voor dingen 06:36.930 --> 06:39.510 als bankieren en websites en e-commerce en dat 06:39.510 --> 06:40.770 soort dingen. 06:40.770 --> 06:42.900 Maar als we iets hebben dat veel data bevat, 06:42.900 --> 06:44.550 zoals audio of video streaming, dan 06:44.550 --> 06:46.560 doet UDP het daar erg goed mee omdat we niet 06:46.560 --> 06:47.490 elk stukje van dat bestand 06:47.490 --> 06:49.320 hoeven te ontvangen. 06:49.320 --> 06:50.880 We kunnen hier en daar een stukje 06:50.880 --> 06:52.510 overslaan, en dat is prima. 06:52.510 --> 06:54.570 -: [Een andere docent] Nu, als het gaat om TCP en UDP, 06:54.570 --> 06:56.820 hebben we het gehad over het feit dat dit verbindingsvolle 06:56.820 --> 06:58.560 of verbindingsgeoriënteerde protocollen 06:58.560 --> 07:00.510 zijn, en verbindingsloze protocollen. 07:00.510 --> 07:02.190 Ik zal je een paar voorbeelden geven 07:02.190 --> 07:05.340 van protocollen die TCP of UDP gebruiken, zodat je begrijpt 07:05.340 --> 07:07.680 waarom we ze allebei gebruiken. 07:07.680 --> 07:08.513 Laten we eerst eens 07:08.513 --> 07:09.420 kijken naar TCP en onze 07:09.420 --> 07:12.750 verbindingsgeoriënteerde of verbindingsvolle protocollen. 07:12.750 --> 07:17.520 Dit omvat dingen als SSH en HTTP of HTTPS. 07:17.520 --> 07:20.940 Waarom zouden we in deze gevallen verbindingsgericht moeten zijn? 07:20.940 --> 07:23.490 Nou, in het geval ik iets als SSH gebruik, doe ik 07:23.490 --> 07:25.710 aan communicatie in twee richtingen en 07:25.710 --> 07:28.320 controle van een server of werkstation op afstand, 07:28.320 --> 07:30.390 en dat kan ik doen via poort 22. 07:30.390 --> 07:31.830 Ik wil er zeker van zijn dat ik dat 07:31.830 --> 07:34.920 op een verbindingsgerichte of verbindingsvolle manier doe. 07:34.920 --> 07:37.110 Op die manier, als ik een commando verstuur en zeg, 07:37.110 --> 07:38.190 reboot de server, weet ik 07:38.190 --> 07:40.080 dat dat commando er echt is gekomen en dat 07:40.080 --> 07:42.060 de server opnieuw wordt opgestart. 07:42.060 --> 07:44.820 Op dezelfde manier, als we te maken hebben met HTTPS, willen 07:44.820 --> 07:46.680 we er zeker van zijn dat we een verbindingsvol 07:46.680 --> 07:50.040 of verbindingsgeoriënteerd protocol hebben dat TCP gebruikt. 07:50.040 --> 07:51.120 De reden hiervoor is, nogmaals, 07:51.120 --> 07:52.440 dat we er zeker van willen zijn dat 07:52.440 --> 07:54.690 wat we verzenden ook echt ontvangen wordt. 07:54.690 --> 07:56.790 En dat kunnen dingen zijn als authenticatie wanneer 07:56.790 --> 07:58.500 we proberen in te loggen op een website 07:58.500 --> 08:00.090 met onze gebruikersnaam en wachtwoord, 08:00.090 --> 08:01.500 of misschien is het de informatie 08:01.500 --> 08:03.030 die we terugkrijgen van die website, 08:03.030 --> 08:06.180 zoals ons rekeningsaldo en onze bankgegevens. 08:06.180 --> 08:07.013 Aan de andere kant, 08:07.013 --> 08:08.970 als we UDP als protocol gebruiken, hebben 08:08.970 --> 08:11.400 we te maken met een verbindingsloze manier. 08:11.400 --> 08:12.390 Nu heb ik al gezegd dat 08:12.390 --> 08:13.470 we dit altijd gebruiken 08:13.470 --> 08:15.600 voor dingen als audio en video streaming. 08:15.600 --> 08:16.680 Maar daarnaast gebruiken 08:16.680 --> 08:19.230 we het ook voor dingen als DHCP en het Trivial 08:19.230 --> 08:23.130 File Transfer Protocol, bekend als TFTP. 08:23.130 --> 08:24.030 Nu, als je het je 08:24.030 --> 08:27.480 herinnert, wordt DHCP gebruikt als het Dynamic Host Control 08:27.480 --> 08:30.660 Protocol en het werkt over poort 67 en 68. 08:30.660 --> 08:32.310 Wanneer je lid wordt van een netwerk, 08:32.310 --> 08:33.690 zal je apparaat, als het is ingesteld 08:33.690 --> 08:35.850 voor een dynamische toewijzing van zijn IP-adres, 08:35.850 --> 08:38.520 een broadcast-bericht uitzenden op dat netwerk op zoek 08:38.520 --> 08:40.650 naar een DHCP-server. 08:40.650 --> 08:43.860 En daarom gebruiken we het als een verbindingsloos protocol. 08:43.860 --> 08:47.220 Want als die informatie wordt verstuurd en niemand reageert, zal je klant 08:47.220 --> 08:49.530 die informatie gewoon opnieuw versturen in de hoop 08:49.530 --> 08:51.510 dat iemand anders er wel zal zijn. 08:51.510 --> 08:53.070 Zo werkt DHCP. 08:53.070 --> 08:55.080 Er wordt een broadcast-bericht verzonden 08:55.080 --> 08:57.090 en er wordt gewacht op een antwoord. 08:57.090 --> 08:58.170 Als het geen antwoord krijgt 08:58.170 --> 08:59.340 binnen een bepaalde tijd, 08:59.340 --> 09:01.560 zal het eenvoudigweg zijn bericht opnieuw uitzenden 09:01.560 --> 09:04.590 en opnieuw een nieuwe DHCP server zoeken. 09:04.590 --> 09:06.960 TFTP of het Trivial File Transfer 09:06.960 --> 09:09.060 Protocol, dat werkt op poort 09:09.060 --> 09:11.250 69, werkt op een verbindingsloze 09:11.250 --> 09:15.690 manier met UDP als transport. 09:15.690 --> 09:16.680 De reden hiervoor 09:16.680 --> 09:20.250 is dat TFTP het Trivial File Transfer Protocol is, en daarom hoeven 09:20.250 --> 09:22.740 we niet de zekerheid te hebben dat elk pakket 09:22.740 --> 09:24.960 verzonden en ontvangen is met die bevestigingen, 09:24.960 --> 09:26.250 en dat zorgt voor veel meer 09:26.250 --> 09:29.190 overhead als we TCP gebruiken. 09:29.190 --> 09:30.600 Dus door UDP te gebruiken, kunnen 09:30.600 --> 09:32.430 we een snellere bestandsoverdracht 09:32.430 --> 09:34.500 hebben als we iets als TFTP gebruiken, in 09:34.500 --> 09:38.163 plaats van een protocol met meer verbindingen, zoals FTP.