WEBVTT

00:00.090 --> 00:01.020
Jason: Bu derste,

00:01.020 --> 00:03.480
TCP, UDP dahil olmak üzere IP protokol

00:03.480 --> 00:05.637
türlerini ve bağlantısız ve bağlantı

00:05.637 --> 00:07.650
yönelimli yöntemler kavramlarını

00:07.650 --> 00:10.020
tartışacağız.

00:10.020 --> 00:12.300
Şimdi, TCP nedir?

00:12.300 --> 00:15.270
TCP bir İletim Kontrol Protokolüdür.

00:15.270 --> 00:17.340
Bağlantı odaklı bir protokoldür, bu da

00:17.340 --> 00:18.990
segmentleri ağımız boyunca taşımanın

00:18.990 --> 00:22.080
güvenilir bir yolu olduğu anlamına gelir.

00:22.080 --> 00:23.580
Şimdi, bir segment düşürülürse,

00:23.580 --> 00:26.603
protokol aslında her seferinde onay isteyecektir.

00:26.603 --> 00:28.890
Ve bu onayı alamazsa, o bilgi parçasını

00:28.890 --> 00:31.530
yeniden gönderecektir.

00:31.530 --> 00:34.410
Bu yüzden buna bağlantı dolu protokol diyoruz çünkü

00:34.410 --> 00:36.960
iki yönlü bir bilgi türü var; ben size bilgi gönderiyorum

00:36.960 --> 00:38.280
ve sizin de bunu aldığınızı

00:38.280 --> 00:40.200
dinleyerek doğruluyorum ve siz de

00:40.200 --> 00:43.170
bana bir yanıt veriyorsunuz.

00:43.170 --> 00:44.640
Şimdi bir saniyeliğine ekrandaki

00:44.640 --> 00:46.230
bu küçük diyagrama bakalım.

00:46.230 --> 00:48.210
Sol tarafta bir istemci ve sağ tarafta bir

00:48.210 --> 00:49.800
sunucu olduğunu göreceksiniz.

00:49.800 --> 00:52.860
Şimdi, istemci sunucuya syn paketi ya da senkronizasyon

00:52.860 --> 00:54.510
paketi adı verilen bir paket

00:54.510 --> 00:55.950
gönderecektir.

00:55.950 --> 00:57.240
Şimdi, sunucu bunu aldığında,

00:57.240 --> 00:58.170
istemciye syn ack

00:58.170 --> 01:00.720
olarak bilinen bir senkronizasyon onayı

01:00.720 --> 01:02.580
gönderecektir.

01:02.580 --> 01:04.740
Şimdi, istemci bu onayı aldığında, sunucuya

01:04.740 --> 01:07.380
kendi onayını geri gönderecektir.

01:07.380 --> 01:09.060
Bu, ack olarak bilinir.

01:09.060 --> 01:11.940
Şimdi, bu syn, syn ack, ack'ı yaptığımızda, bu üç

01:11.940 --> 01:15.030
yönlü el sıkışma olarak adlandırdığımız şeydir.

01:15.030 --> 01:16.807
Esasen, istemcinin "Hey sunucu,

01:16.807 --> 01:21.367
biraz bilgi almaya hazır mısın? Ve sonra sunucu der ki, "Elbette.

01:21.367 --> 01:21.367
Neden olmasın?

01:21.367 --> 01:22.920
"Bana biraz bilgi gönderin. Müşteri de diyor

01:22.920 --> 01:25.440
ki, "Tamam, işte geliyor. Ve sonra aktarım başlayacak çünkü üç

01:25.440 --> 01:27.630
yönlü el sıkışmayı gerçekleştirdik

01:27.630 --> 01:29.940
ve her iki tarafın da iletişim kurmaya

01:29.940 --> 01:32.737
hazır olduğunu biliyoruz.

01:32.737 --> 01:35.107
"Şimdi, hazır mısın? "Evet, öyleyim.

01:35.107 --> 01:35.107
"İşte

01:35.107 --> 01:36.810
geliyor. Şimdi, segment olarak adlandırdığımız

01:36.810 --> 01:39.150
bu veri ağ üzerinden her gönderildiğinde,

01:39.150 --> 01:40.710
alınan bir onay olacak ve bu

01:40.710 --> 01:43.080
bize iki yönlü iletişimin başarılı bir

01:43.080 --> 01:46.980
şekilde gerçekleştiğini söyleyecektir.

01:46.980 --> 01:48.600
Şimdi, bu sunucu 100 parça bilgi

01:48.600 --> 01:50.370
almayı bekliyorsa, ancak bunlardan

01:50.370 --> 01:52.500
yalnızca 98'ini aldıysa, istemciye "Hey,

01:52.500 --> 01:53.587
bana 100 şey göndereceğini

01:53.587 --> 01:56.347
söylemiştin, ancak bana yalnızca 98'ini gönderdin"

01:56.347 --> 01:58.177
diyecektir.

01:58.177 --> 02:00.450
"Eksik olan şu iki şeyi bana gönderin. Ve sonra, bir yeniden

02:00.450 --> 02:02.730
iletim gerçekleşir.

02:02.730 --> 02:03.563
Bu şekilde, iletişim

02:03.563 --> 02:05.310
bizim için devam edebilir ve her zaman

02:05.310 --> 02:06.240
almamız gerekeni aldığımızdan

02:06.240 --> 02:07.470
emin olabiliriz çünkü paketleri

02:07.470 --> 02:10.920
ağ üzerinden yeniden göndeririz.

02:10.920 --> 02:13.170
Şimdi bu, nihai hedefine ulaşması için güvence

02:13.170 --> 02:16.830
altına alınması gereken tüm ağ verileri için kullanılır.

02:16.830 --> 02:19.470
Bunu iadeli taahhütlü posta gibi düşünmek istiyorum.

02:19.470 --> 02:22.440
Örneğin IRS'ye bir mesaj göndermek istersem, bunu aldıklarından

02:22.440 --> 02:23.970
ve postada kaybolmadığından

02:23.970 --> 02:25.620
emin olmak isterim.

02:25.620 --> 02:27.630
Bu yüzden biraz daha fazla para ödeyerek,

02:27.630 --> 02:29.160
oraya ulaştığında imzalamaları

02:29.160 --> 02:31.080
gereken ve bana geri postalanacak olan

02:31.080 --> 02:32.820
onaylı bir makbuz alabilirim.

02:32.820 --> 02:33.653
Bu şekilde, makbuzu

02:33.653 --> 02:34.740
geri aldığımda, IRS'nin

02:34.740 --> 02:37.500
posta paketimi aldığını biliyorum.

02:37.500 --> 02:39.960
TCP bu şekilde çalışır.

02:39.960 --> 02:41.220
Öte yandan, UDP olarak

02:41.220 --> 02:44.250
bilinen başka bir protokolümüz daha var.

02:44.250 --> 02:47.250
UDP bağlantısız protokol olarak adlandırdığımız bir protokoldür,

02:47.250 --> 02:49.770
yani bağlantı beklemek zorunda değildir.

02:49.770 --> 02:52.830
UDP, Kullanıcı Datagram Protokolü anlamına gelir.

02:52.830 --> 02:54.270
Buna datagram dememizin nedeni,

02:54.270 --> 02:56.160
UDP kullanıyorsanız bu tür bir veri kullanıyor

02:56.160 --> 02:57.750
olmanızdır.

02:57.750 --> 02:59.220
Buna datagram deniyor.

02:59.220 --> 03:01.317
Şimdi, UDP hakkında konuştuğumuzda,

03:01.317 --> 03:03.060
UDP güvenilmezdir ve datagram

03:03.060 --> 03:05.490
adı verilen segmentleri iletir.

03:05.490 --> 03:06.510
Ve eğer düşürülürlerse,

03:06.510 --> 03:09.000
gönderenin bundan haberi bile olmaz.

03:09.000 --> 03:10.830
Şimdi, neden gönderenin haberdar olmadığı

03:10.830 --> 03:12.300
ve herhangi bir makbuz almadığım

03:12.300 --> 03:14.220
bir şey göndermek isteyeyim ki?

03:14.220 --> 03:17.850
UDP, ses ve görüntü akışı için gerçekten iyidir çünkü çok fazla

03:17.850 --> 03:19.920
veri gönderirsiniz ve UDP kullandığınızda

03:19.920 --> 03:22.620
çok daha az ek yük vardır, çünkü bunu oluşturmak

03:22.620 --> 03:24.810
için sürekli üç yönlü el sıkışmamız

03:24.810 --> 03:25.950
yoktur ve TCP kullanarak

03:25.950 --> 03:27.840
ilişkili olan tüm kontrol ve dengelere

03:27.840 --> 03:30.840
sahip değiliz.

03:30.840 --> 03:32.520
Dolayısıyla, UDP kullanarak ağınızın

03:32.520 --> 03:35.190
performansını gerçekten artırabilirsiniz çünkü

03:35.190 --> 03:37.800
sıfır yeniden iletiminiz olacaktır.

03:37.800 --> 03:39.870
Sonunda bilgiyi düşürürsünüz.

03:39.870 --> 03:41.490
Şimdi, bu kötü bir şey değil mi?

03:41.490 --> 03:43.530
Neden bilgiyi bırakmak isteyelim ki?

03:43.530 --> 03:45.300
Bazı uygulamalar için gerçekten

03:45.300 --> 03:46.740
fark etmez.

03:46.740 --> 03:49.440
Örneğin, şu anda bu videoyu yayınlıyorsunuz.

03:49.440 --> 03:52.110
Peki ya saniyenin yüzde biri kadar bir süre için bıraksam,

03:52.110 --> 03:53.520
fark eder miydiniz?

03:53.520 --> 03:54.960
Muhtemelen yapmazsınız ve UDP'nin

03:54.960 --> 03:56.820
bu kadar iyi olmasının nedeni budur çünkü

03:56.820 --> 03:59.520
burada zamanın 1/100'ünü düşürebiliriz ve bunu gerçekten

03:59.520 --> 04:01.320
asla fark etmeyeceksiniz ve bir yeniden

04:01.320 --> 04:03.120
iletim olmayacak.

04:03.120 --> 04:04.740
Ancak TCP ile, çok daha fazla ara belleğe alma

04:04.740 --> 04:06.300
işlemine yol açacaktır çünkü beklemeniz

04:06.300 --> 04:07.440
ve ardından size yeniden gönderilmesini

04:07.440 --> 04:08.670
sağlamanız ve ardından doğru yere

04:08.670 --> 04:09.810
koymanız ve ardından geri oynatmanız

04:09.810 --> 04:11.250
gerekir.

04:11.250 --> 04:13.770
Dolayısıyla, bu onaylama ve ek yük nedeniyle, bu videonun

04:13.770 --> 04:15.870
her bir saniyesi için, videoyu çok daha büyük

04:15.870 --> 04:17.880
hale getirecek ve çok daha fazla bant genişliği

04:17.880 --> 04:19.830
kullanacaktır.

04:19.830 --> 04:21.150
Video akışı ve ses akışı

04:21.150 --> 04:24.660
için UDP kullanmamızın en büyük nedenlerinden biri de budur.

04:24.660 --> 04:28.740
Şimdi burada TCP ve UDP'nin kısa bir özetini yapalım.

04:28.740 --> 04:31.410
Çünkü bu gerçekten çok önemli bir kavram.

04:31.410 --> 04:33.600
Aslında, şu anda notlarınızı çıkarmış olsaydınız,

04:33.600 --> 04:35.160
TCP'ye karşı UDP hakkında konuşurken

04:35.160 --> 04:36.420
size şimdi anlatacağım bu

04:36.420 --> 04:38.520
tabloyu not ederdim.

04:38.520 --> 04:40.770
Çünkü gerçekten bu kadar önemli.

04:40.770 --> 04:43.380
Şimdi, ilk olarak, TCP güvenilirdir, UDP'nin

04:43.380 --> 04:44.820
çok güvenilir olmadığı yerde

04:44.820 --> 04:47.040
üç yönlü bir el sıkışması vardır.

04:47.040 --> 04:48.540
Güvenilir olmayan bir protokoldür

04:48.540 --> 04:51.180
çünkü üç yönlü el sıkışma yoktur.

04:51.180 --> 04:53.490
TCP, bağlantı yönelimli ya da bağlantı

04:53.490 --> 04:55.560
dolu bir protokoldür, çünkü onaylarda

04:55.560 --> 04:57.960
üç yönlü el sıkışma vardır, ancak UDP

04:57.960 --> 05:00.660
bağlantısızdır.

05:00.660 --> 05:02.550
Bu bir ateşle ve unut yöntemidir.

05:02.550 --> 05:04.200
Ben sadece bilgi göndermeye başlıyorum

05:04.200 --> 05:06.660
ve umarım siz de bunu alırsınız.

05:06.660 --> 05:10.170
TCP, pencereleme yoluyla işlenen segment yeniden iletimini

05:10.170 --> 05:12.030
ve akış kontrolünü kullanır.

05:12.030 --> 05:13.230
Öte yandan UDP'de

05:13.230 --> 05:16.230
yeniden iletim ve pencereleme yoktur.

05:16.230 --> 05:17.160
TCP ile, tüm farklı

05:17.160 --> 05:19.140
segmentlerimizin sıralamasında

05:19.140 --> 05:20.820
segmentasyonumuz var.

05:20.820 --> 05:23.370
UDP ile sıralama yoktur.

05:23.370 --> 05:25.530
Şimdi, bunun anlamı, her şeyi gönderirken,

05:25.530 --> 05:28.710
birden 100'e kadar uygun sırayla göndereceğim.

05:28.710 --> 05:31.260
Bunu hem TCP hem de UDP için yapacağım.

05:31.260 --> 05:32.910
Şimdi, bu parçalardan bazılarını

05:32.910 --> 05:34.350
kaçırırsanız veya ağ üzerinde

05:34.350 --> 05:36.480
farklı bir yol izledikleri için farklı bir

05:36.480 --> 05:37.500
sırayla gelirlerse,

05:37.500 --> 05:38.520
TCP ile sıralanırlar,

05:38.520 --> 05:40.137
bu yüzden 1000'e bir tane olduğunu

05:40.137 --> 05:42.420
bilir ve onları doğru sıraya koyar.

05:42.420 --> 05:43.440
UDP ile, ne olarak

05:43.440 --> 05:44.850
gelirlerse gelsinler,

05:44.850 --> 05:46.650
o şekilde yayınlayacaktır.

05:46.650 --> 05:48.030
Ve böylece, bir, 50,

05:48.030 --> 05:49.230
iki, 500, üç, dört,

05:49.230 --> 05:50.910
beş, altı, 20, bunun gibi

05:50.910 --> 05:55.230
herhangi bir rastgele sırayla gelebilir.

05:55.230 --> 05:56.580
Ve bu şekilde duyacaksınız.

05:56.580 --> 05:59.010
Dolayısıyla videoda biraz atlama veya biraz

05:59.010 --> 06:00.780
tiz gıcırtı ya da buna benzer bir şey

06:00.780 --> 06:01.740
duyabilirsiniz, çünkü

06:01.740 --> 06:04.320
bu karelerden biri sıra dışı olabilir.

06:04.320 --> 06:05.550
Şimdi, TCP'ye geri döndüğümüzde,

06:05.550 --> 06:08.010
bu segmentlerin her birini onaylayacaktır.

06:08.010 --> 06:09.780
Ve böylece onay almış olduk.

06:09.780 --> 06:10.680
Eğer alamazsam, alamadığımı

06:10.680 --> 06:11.513
biliyorum ve bana yeniden

06:11.513 --> 06:15.000
iletilmesini sağlayabilirim ve sonra tekrar alabilirim.

06:15.000 --> 06:17.190
UDP ile onaylama yoktur.

06:17.190 --> 06:20.220
Yani yine, UDP'nin çok daha az ek yükü vardır

06:20.220 --> 06:21.540
çünkü bağlantı, pencereleme,

06:21.540 --> 06:23.790
yeniden iletim, sıralama ve onaylama

06:23.790 --> 06:26.610
yoktur.

06:26.610 --> 06:28.620
Şimdi, oraya bir şey götürmeniz gerekiyorsa

06:28.620 --> 06:30.870
ve kişinin bunu aldığından emin olmak istiyorsanız,

06:30.870 --> 06:34.590
tercih ettiğiniz protokol olarak gerçekten TCP'yi kullanmanız gerekir.

06:34.590 --> 06:36.930
İşte bu yüzden TCP'yi bankacılık, web

06:36.930 --> 06:39.510
siteleri, e-ticaret ve bunun gibi şeyler için

06:39.510 --> 06:40.770
kullanacağız.

06:40.770 --> 06:42.900
Ancak ses veya video akışı gibi çok fazla veri

06:42.900 --> 06:44.550
içeren bir şeyimiz varsa, UDP bu

06:44.550 --> 06:46.560
konuda gerçekten başarılıdır çünkü bu

06:46.560 --> 06:47.490
dosyanın her bir parçasını

06:47.490 --> 06:49.320
almamız gerekmez.

06:49.320 --> 06:50.880
Burada ve orada biraz atlayabiliriz

06:50.880 --> 06:52.510
ve bu sorun değil.

06:52.510 --> 06:54.570
-: [Başka bir Eğitmen] Şimdi, TCP ve UDP söz konusu

06:54.570 --> 06:56.820
olduğunda, bunların bağlantı dolu veya bağlantı

06:56.820 --> 06:58.560
odaklı protokoller ve bağlantısız protokoller

06:58.560 --> 07:00.510
olduğundan bahsettik.

07:00.510 --> 07:02.190
Şimdi size TCP ya da UDP kullanan

07:02.190 --> 07:05.340
birkaç protokol örneği vereyim, böylece neden her birini

07:05.340 --> 07:07.680
kullandığımızı anlayabilirsiniz.

07:07.680 --> 07:08.513
İlk olarak, TCP'ye

07:08.513 --> 07:09.420
ve bağlantı odaklı

07:09.420 --> 07:12.750
ya da bağlantı dolu protokollerimize bakalım.

07:12.750 --> 07:17.520
Bu, SSH ve HTTP veya HTTPS gibi şeyleri içerir.

07:17.520 --> 07:20.940
Şimdi, bu durumlarda neden bağlantı odaklı olmaya ihtiyacımız olsun ki?

07:20.940 --> 07:23.490
SSH gibi bir şey kullandığımda, iki yönlü iletişim

07:23.490 --> 07:25.710
ve uzak sunucu veya uzak iş istasyonunun kontrolünü

07:25.710 --> 07:28.320
yapıyorum ve bunu 22 numaralı bağlantı noktası üzerinden

07:28.320 --> 07:30.390
yapabiliyorum.

07:30.390 --> 07:31.830
Bunu bağlantı odaklı veya bağlantı

07:31.830 --> 07:34.920
dolu bir şekilde yaptığımdan emin olmak istiyorum.

07:34.920 --> 07:37.110
Bu şekilde, bir komut gönderip sunucuyu yeniden

07:37.110 --> 07:38.190
başlat dediğimde, o komutun

07:38.190 --> 07:40.080
gerçekten oraya ulaştığını ve sunucunun

07:40.080 --> 07:42.060
yeniden başlatılacağını biliyorum.

07:42.060 --> 07:44.820
Benzer şekilde, HTTPS ile uğraşırken, TCP kullanarak

07:44.820 --> 07:46.680
bağlantı dolu veya bağlantı odaklı

07:46.680 --> 07:50.040
bir protokole sahip olduğumuzdan emin olmak isteriz.

07:50.040 --> 07:51.120
Bunun nedeni, yine, gönderdiğimiz

07:51.120 --> 07:52.440
şeyin gerçekten oraya ulaştığından

07:52.440 --> 07:54.690
emin olmak istememizdir.

07:54.690 --> 07:56.790
Ve bu, kullanıcı adımızı ve şifremizi kullanarak

07:56.790 --> 07:58.500
bir web sitesine giriş yapmaya çalışırken

07:58.500 --> 08:00.090
kimlik doğrulama gibi şeyleri içerebilir

08:00.090 --> 08:01.500
veya belki de hesap bakiyelerimiz

08:01.500 --> 08:03.030
ve bankacılık bilgilerimiz gibi

08:03.030 --> 08:06.180
o web sitesinden geri aldığımız bilgilerdir.

08:06.180 --> 08:07.013
Öte yandan, protokol

08:07.013 --> 08:08.970
olarak UDP kullanıyorsak, bağlantısız

08:08.970 --> 08:11.400
bir şekilde işlem yapıyoruz demektir.

08:11.400 --> 08:12.390
Şimdi, bunu ses ve video akışı

08:12.390 --> 08:13.470
gibi şeyler için her zaman kullandığımız

08:13.470 --> 08:15.600
gerçeğinden zaten bahsetmiştim.

08:15.600 --> 08:16.680
Ancak buna ek olarak,

08:16.680 --> 08:19.230
DHCP ve TFTP olarak bilinen Trivial File

08:19.230 --> 08:23.130
Transfer Protocol gibi şeyler için de kullanıyoruz.

08:23.130 --> 08:24.030
Şimdi, hatırlarsanız,

08:24.030 --> 08:27.480
DHCP Dinamik Ana Bilgisayar Kontrol Protokolü olarak kullanılır

08:27.480 --> 08:30.660
ve 67 ve 68 numaralı portlar üzerinden çalışır.

08:30.660 --> 08:32.310
Şimdi, bir ağa katıldığınızda,

08:32.310 --> 08:33.690
cihazınız IP adresinin

08:33.690 --> 08:35.850
dinamik olarak atanması için ayarlanmışsa,

08:35.850 --> 08:38.520
o ağda bir DHCP sunucusu arayan bir yayın mesajı

08:38.520 --> 08:40.650
gönderecektir.

08:40.650 --> 08:43.860
İşte bu yüzden bağlantısız bir protokol olarak kullanıyoruz.

08:43.860 --> 08:47.220
Çünkü bu bilgi gönderilir ve kimse yanıt vermezse, müşteriniz

08:47.220 --> 08:49.530
başka birinin orada olacağı umuduyla bunu

08:49.530 --> 08:51.510
tekrar gönderecektir.

08:51.510 --> 08:53.070
DHCP bu şekilde çalışır.

08:53.070 --> 08:55.080
Bir yayın mesajının dışarı çıkmasına izin verecek ve

08:55.080 --> 08:57.090
ardından bir yanıtın geri gelmesini bekleyecektir.

08:57.090 --> 08:58.170
Belirli bir süre içinde

08:58.170 --> 08:59.340
bu yanıtı alamazsa,

08:59.340 --> 09:01.560
mesajını yeniden yayınlayacak ve tekrar

09:01.560 --> 09:04.590
yeni bir DHCP sunucusu arayacaktır.

09:04.590 --> 09:06.960
Şimdi, benzer şekilde, 69 numaralı bağlantı noktası

09:06.960 --> 09:09.060
üzerinden çalışan TFTP veya Trivial File

09:09.060 --> 09:11.250
Transfer Protocol'e sahip olduğumuzda, aktarım

09:11.250 --> 09:13.380
olarak UDP'yi kullanarak bağlantısız bir

09:13.380 --> 09:15.690
şekilde çalışacaktır.

09:15.690 --> 09:16.680
Bunun nedeni, TFTP'nin

09:16.680 --> 09:20.250
Önemsiz Dosya Aktarım Protokolü olmasıdır ve bu nedenle, her

09:20.250 --> 09:22.740
bir paketin bu onaylarla gönderilip alındığına

09:22.740 --> 09:24.960
dair güvencelere sahip olmamız gerekmez

09:24.960 --> 09:26.250
ve TCP kullanırsak bu çok

09:26.250 --> 09:29.190
daha fazla ek yük oluşturur.

09:29.190 --> 09:30.600
Böylece UDP kullanarak, FTP

09:30.600 --> 09:32.430
gibi daha bağlantı dolu bir protokol

09:32.430 --> 09:34.500
kullanmak yerine TFTP gibi bir şey kullandığımızda

09:34.500 --> 09:38.163
daha hızlı bir dosya aktarımı yapabiliriz.