WEBVTT

00:00.090 --> 00:01.020
네 제이슨 이 수업에서는

00:01.020 --> 00:03.480
TCP, UDP를 포함한 ip 프로토콜

00:03.480 --> 00:05.637
유형과 연결 없는 것과 연결 지향적인

00:05.637 --> 00:10.020
메서드의 개념에 대해 이야기하겠습니다

00:10.020 --> 00:12.300
Tcp가 뭐죠?

00:12.300 --> 00:15.270
Tcp는 전송 제어 프로토콜이에요

00:15.270 --> 00:17.340
네 연결 지향 프로토콜이니

00:17.340 --> 00:18.990
네트워크를 통해 세그먼트를

00:18.990 --> 00:22.080
전송할 수 있죠

00:22.080 --> 00:23.580
네 이제 코너가 삭제되면

00:23.580 --> 00:25.770
프로토콜은 매번 인정을 요구합니다

00:25.770 --> 00:26.603
????

00:26.603 --> 00:28.890
그 인정을 받지 못하면 그

00:28.890 --> 00:31.530
정보를 다시 보낼 겁니다

00:31.530 --> 00:34.410
네 그래서 연결 전체 프로토콜이라

00:34.410 --> 00:36.960
불러요 양방향 정보 유형이거든요

00:36.960 --> 00:38.280
제가 정보를 보내고

00:38.280 --> 00:40.200
여러분이 듣고 응답해서

00:40.200 --> 00:43.170
받았는지 확인하는 거죠

00:43.170 --> 00:44.640
이제 여기 화면에 있는 이 작은 다이어그램을

00:44.640 --> 00:46.230
잠시 살펴보겠습니다.

00:46.230 --> 00:48.210
왼쪽이 클라이언트 오른쪽이

00:48.210 --> 00:49.800
서버인 게 보일 겁니다

00:49.800 --> 00:52.860
네 이제 클라이언트는 신 패킷, 혹은

00:52.860 --> 00:54.510
동기화 패킷을 서버에

00:54.510 --> 00:55.950
보냅니다 ,

00:55.950 --> 00:57.240
네 이제 서버가 그걸 받으면

00:57.240 --> 00:58.170
클라이언트에

00:58.170 --> 01:00.720
동기화 승인을 다시 보냅니다 동기 ack라고

01:00.720 --> 01:02.580
알려진 거죠 ?

01:02.580 --> 01:04.740
네 이제 클라이언트가 저 승인을 받으면

01:04.740 --> 01:07.380
서버로 고유한 승인을 다시 보낼 겁니다 ???

01:07.380 --> 01:09.060
이건 액이라고 해요

01:09.060 --> 01:11.940
이제 우리가 이 syn, syn ack, ack를 수행할

01:11.940 --> 01:15.030
때 이것이 우리가 3방향 핸드셰이크라고 부르는 것입니다.

01:15.030 --> 01:16.807
기본적으로 클라이언트는 "안녕 서버님,

01:16.807 --> 01:21.367
정보를 얻을 준비가 되셨나요?"라고 말합니다. 그럼 서버가 대답하죠

01:21.367 --> 01:21.367
왜요?

01:21.367 --> 01:22.920
정보를 보내달라고 했어요 그러자 고객이

01:22.920 --> 01:25.440
말했죠 그럼 변신이 시작될

01:25.440 --> 01:27.630
거예요 3자 악수를

01:27.630 --> 01:29.940
했으니 서로 연락할

01:29.940 --> 01:32.737
준비가 된 거죠

01:32.737 --> 01:35.107
'준비되셨나요?' "예, 그렇습니다.

01:35.107 --> 01:35.107
시작이군요

01:35.107 --> 01:36.810
네 이제 저희가 세그먼트라고

01:36.810 --> 01:39.150
부르는 이 데이터가 네트워크를 통해

01:39.150 --> 01:40.710
전송될 때마다 성공적으로

01:40.710 --> 01:43.080
양방향 통신이 이뤄졌다는 사실을

01:43.080 --> 01:45.030
수신했다는 사실을 인식하게

01:45.030 --> 01:46.980
될 겁니다

01:46.980 --> 01:48.600
네 이제 이 서버가 100개의

01:48.600 --> 01:50.370
정보를 받을 거로 기대하는데

01:50.370 --> 01:52.500
98개만 받았다면 클라이언트에게

01:52.500 --> 01:53.587
이렇게 말할 거예요

01:53.587 --> 01:56.347
100개만 보낸다고 했잖아 , 근데 왜 98명밖에

01:56.347 --> 01:58.177
안 보냈잖아

01:58.177 --> 02:02.730
'제가 빠진 두 가지를 보내주세요' 그리고 재발합니다

02:02.730 --> 02:03.563
네 이렇게 하면

02:03.563 --> 02:05.310
통신이 잘 되고 필요한

02:05.310 --> 02:06.240
걸 늘 확보할

02:06.240 --> 02:07.470
수 있죠 네트워크에

02:07.470 --> 02:10.920
걸쳐 패킷을 새로 추가했으니까요

02:10.920 --> 02:13.170
최종 목적지에 도달하기 위해 확인돼야

02:13.170 --> 02:16.830
하는 모든 네트워크 데이터에 사용됩니다

02:16.830 --> 02:19.470
전 이걸 등기 우편이라고 생각해요

02:19.470 --> 02:22.440
네 예를 들어 국세청에 메시지를 보내고 싶으면 잘 전달됐는지

02:22.440 --> 02:23.970
확인한 후 우편으로 보내죠 ,

02:23.970 --> 02:25.620
분실되지 않도록요

02:25.620 --> 02:27.630
따라서 영수증이 도착하면 서명을 해야 하고

02:27.630 --> 02:29.160
그 영수증이 나에게 다시 우편으로

02:29.160 --> 02:31.080
발송되는 인증 영수증을 얻기 위해 약간의 추가

02:31.080 --> 02:32.820
비용을 지불할 수도 있습니다.

02:32.820 --> 02:33.653
이렇게 하면 영수증을

02:33.653 --> 02:34.740
돌려받을 때 irs가

02:34.740 --> 02:37.500
내 우편물을 받았다는 것을 알 수 있습니다.

02:37.500 --> 02:39.960
이것이 tcp가 작동하는 방식입니다.

02:39.960 --> 02:41.220
다른 한편으로는

02:41.220 --> 02:44.250
udp라는 프로토콜이 있습니다

02:44.250 --> 02:47.250
Udp는 우리가 연결 없는 프로토콜이라고 부르는 것입니다.

02:47.250 --> 02:49.770
즉, 연결을 기다릴 필요가 없습니다.

02:49.770 --> 02:52.830
Udp는 사용자 데이터그램 프로토콜의 약자입니다

02:52.830 --> 02:54.270
이걸 데이터그램이라고 부르는

02:54.270 --> 02:56.160
이유는 udp를 사용하면 이런 유형의 데이터를

02:56.160 --> 02:57.750
사용하기 때문입니다

02:57.750 --> 02:59.220
데이터그램이란 거예요

02:59.220 --> 03:01.317
Udp에 대해 이야기할 때 udp는

03:01.317 --> 03:03.060
신뢰할 수 없고 데이터그램이라는

03:03.060 --> 03:05.490
세그먼트를 전송합니다

03:05.490 --> 03:06.510
삭제돼도 보낸 사람은

03:06.510 --> 03:09.000
그런 일이 있었다는 것도 모를 거예요

03:09.000 --> 03:10.830
자 그럼 왜 제가 물건을 보낸 사람이

03:10.830 --> 03:12.300
모르고 영수증도 없는 곳에

03:12.300 --> 03:14.220
보내고 싶겠어요?

03:14.220 --> 03:17.850
음 udp는 시청각 스트리밍에 아주 좋습니다 많은

03:17.850 --> 03:19.920
데이터를 보내고 udp를 사용하면

03:19.920 --> 03:22.620
오버헤드가 줄어들거든요 왜냐하면 그걸

03:22.620 --> 03:25.950
설정하기 위한 3자 악수가 지속되지 않고 tcp를

03:25.950 --> 03:27.840
사용함으로써 연결되는 모든

03:27.840 --> 03:30.840
견제와 균형도 없거든요

03:30.840 --> 03:32.520
따라서 udp를 사용하면

03:32.520 --> 03:35.190
재전송이 전혀 발생하지 않으므로 네트워크

03:35.190 --> 03:37.800
성능을 실제로 향상시킬 수 있습니다.

03:37.800 --> 03:39.870
정보를 드롭할 뿐이죠

03:39.870 --> 03:41.490
나쁜 거 아닌가요?

03:41.490 --> 03:43.530
왜 정보를 흘리겠어요?

03:43.530 --> 03:45.300
어떤 응용 프로그램에서는

03:45.300 --> 03:46.740
상관없습니다

03:46.740 --> 03:49.440
예를 들어 지금 이 영상을 스트리밍하고 있죠

03:49.440 --> 03:52.110
내가 100분의 1초 동안 탈퇴하면 알아채기나

03:52.110 --> 03:53.520
하겠어요?

03:53.520 --> 03:54.960
음 아마 그렇게 안 되겠죠

03:54.960 --> 03:56.820
그래서 udp가 좋은 겁니다

03:56.820 --> 03:59.520
100분의 1을 떨어뜨릴 수 있지만 눈치채지도

03:59.520 --> 04:03.120
못할 것이고 재발급도 없습니다

04:03.120 --> 04:04.740
하지만 tcp를 사용하면 기다려야

04:04.740 --> 04:06.300
하고 다시 전송받아서 올바른

04:06.300 --> 04:07.440
위치에 놓고 재생해야

04:07.440 --> 04:08.670
하기 때문에 훨씬 더 많은

04:08.670 --> 04:11.250
버퍼링이 발생합니다.

04:11.250 --> 04:13.770
그리고 그래서 이 비디오의 매 초마다

04:13.770 --> 04:15.870
오버헤드와 인지 때문에 더

04:15.870 --> 04:17.880
크게 만들고 대역폭을 더 많이

04:17.880 --> 04:19.830
사용할 겁니다

04:19.830 --> 04:21.150
그래서 비디오와 오디오

04:21.150 --> 04:24.660
스트리밍에 udp를 사용하는 겁니다

04:24.660 --> 04:28.740
이제 여기서 tcp와 udp를 간단히 요약해 보겠습니다.

04:28.740 --> 04:31.410
이건 정말 중요한 콘셉트거든요

04:31.410 --> 04:33.600
네 사실 지금 노트를 꺼내놓으셨다면

04:33.600 --> 04:36.420
이 차트를 적어서 지금 말씀드릴게요 tcp

04:36.420 --> 04:38.520
대 udp에 대해서요

04:38.520 --> 04:40.770
그만큼 중요한 일이니까요

04:40.770 --> 04:43.380
먼저 tcp는 신뢰할 수 있습니다 세 가지

04:43.380 --> 04:44.820
악수를 할 수 있는데 udp는

04:44.820 --> 04:47.040
그다지 신뢰할 수 없습니다

04:47.040 --> 04:48.540
셋이 악수하는

04:48.540 --> 04:51.180
건 불가능하거든요

04:51.180 --> 04:53.490
네 네 세 가지 방식으로

04:53.490 --> 04:55.560
악수를 하거든요 ,

04:55.560 --> 04:56.880
감사의 표시로요

04:56.880 --> 04:57.960
udp는 연결

04:57.960 --> 05:00.660
고리가 없어요

05:00.660 --> 05:02.550
포기를 모르는 방법이죠

05:02.550 --> 05:04.200
정보를 보내기 시작할 텐데

05:04.200 --> 05:06.660
여러분이 이해하시길 바라요

05:06.660 --> 05:10.170
Tcp는 창 작업을 통해 처리되는 흐름 제어와 부분

05:10.170 --> 05:12.030
재진입을 이용합니다

05:12.030 --> 05:13.230
반면 udp는

05:13.230 --> 05:16.230
재발견도 없고 창문도 없어요

05:16.230 --> 05:17.160
Tcp를 이용하면

05:17.160 --> 05:19.140
모든 부분의 시퀀싱 세분화를

05:19.140 --> 05:20.820
할 수 있어요

05:20.820 --> 05:23.370
Udp에는 순서가 없습니다.

05:23.370 --> 05:25.530
네 이제 무슨 뜻이냐면 모든 걸 보낼 때

05:25.530 --> 05:27.570
올바른 순서로 보낼 거예요 1부터

05:27.570 --> 05:28.710
100까지요

05:28.710 --> 05:31.260
Tcp와 udp를 다 해볼게요

05:31.260 --> 05:32.910
네 이제 이제 tcp로는

05:32.910 --> 05:34.350
배열을 진행하여

05:34.350 --> 05:36.480
1에서 1,000까지의

05:36.480 --> 05:38.520
상태를 확인하고 올바른

05:38.520 --> 05:40.137
순서로 돌려놓습니다

05:40.137 --> 05:42.420
, 그리고

05:42.420 --> 05:43.440
Udp는 어떤

05:43.440 --> 05:44.850
이름으로 들어오든

05:44.850 --> 05:46.650
그렇게 방송합니다

05:46.650 --> 05:48.030
그래서 숫자가

05:48.030 --> 05:49.230
나올 수 있어요

05:49.230 --> 05:50.910
1 50 2 53 3 4

05:50.910 --> 05:53.820
5 6 5 무작위로 순서가 바뀌죠

05:53.820 --> 05:55.230
이렇게요

05:55.230 --> 05:56.580
그리고 그것이 당신이 그것을 듣게 될 방법입니다.

05:56.580 --> 05:59.010
비디오를 보면 약간 안절부절못하거나 높은음의

05:59.010 --> 06:00.780
삐걱거리는 소리가 들릴 수 있어요

06:00.780 --> 06:01.740
프레임 하나가 순서가

06:01.740 --> 06:04.320
틀렸을 수도 있거든요

06:04.320 --> 06:05.550
Tcp로 돌아가면

06:05.550 --> 06:08.010
각각의 세그먼트를 인식합니다

06:08.010 --> 06:09.780
이제 인정했네요

06:09.780 --> 06:10.680
네 못 받으면

06:10.680 --> 06:11.513
못 받은 걸

06:11.513 --> 06:13.650
아니까 다시 송신해서 받으면

06:13.650 --> 06:15.000
돼요

06:15.000 --> 06:17.190
Udp는 인정받지 못합니다

06:17.190 --> 06:20.220
네 다시 말씀드리지만 오버헤드가 적습니다

06:20.220 --> 06:21.540
왜냐하면 연결이 없고

06:21.540 --> 06:23.790
창문이 없고 재진입도 없고 배열이나

06:23.790 --> 06:26.610
인정이 없기 때문입니다

06:26.610 --> 06:28.620
네 이제 뭔가를 확보해야 하는데

06:28.620 --> 06:30.870
그걸 받은 사람이 누군지 확인하려면

06:30.870 --> 06:34.590
tcp를 선택해야 합니다 , tcp를 선택하세요

06:34.590 --> 06:36.930
이것이 바로 우리가 실제로 은행, 웹사이트,

06:36.930 --> 06:39.510
전자상거래 등의 분야에 tcp를 사용하게 되는

06:39.510 --> 06:40.770
이유입니다.

06:40.770 --> 06:42.900
그러나 오디오나 비디오 스트리밍과 같이

06:42.900 --> 06:44.550
많은 양의 데이터가 있는 경우에는

06:44.550 --> 06:46.560
udp가 해당 파일의 모든 부분을 가져올

06:46.560 --> 06:47.490
필요가 없기 때문에

06:47.490 --> 06:49.320
그 작업에 매우 적합합니다.

06:49.320 --> 06:50.880
여기 저기 건너뛰어도

06:50.880 --> 06:52.510
괜찮아요

06:52.510 --> 06:54.570
네 좋습니다 자 tcp와 udp에

06:54.570 --> 06:56.820
관해 얘기했죠 연결을 완전하게 하거나

06:56.820 --> 06:58.560
연결 지향적인 프로토콜과

06:58.560 --> 07:00.510
연결 없는 프로토콜요

07:00.510 --> 07:02.190
네 tcp나 udp를 사용하는

07:02.190 --> 07:05.340
프로토콜 예제를 몇 개 보여드릴게요 왜 각각을

07:05.340 --> 07:07.680
쓰는지 이해하실 거예요

07:07.680 --> 07:08.513
먼저 tcp와

07:08.513 --> 07:09.420
연결 지향적

07:09.420 --> 07:12.750
혹은 전체 프로토콜을 살펴보죠

07:12.750 --> 07:17.520
Ssh나 http, https 같은 걸 포함합니다

07:17.520 --> 07:20.940
이 경우에 연결에 중점을 두는 게 왜 필요할까요?

07:20.940 --> 07:23.490
네 음 ssh 같은 것을 사용하는 경우,

07:23.490 --> 07:25.710
양방향 통신을 하고 원격 서버나 원격

07:25.710 --> 07:28.320
워크스테이션을 제어하는데 포트 22에서

07:28.320 --> 07:30.390
할 수 있습니다.

07:30.390 --> 07:31.830
연결 지향적이거나

07:31.830 --> 07:34.920
연결을 완전하게 하는 방식으로요

07:34.920 --> 07:37.110
이렇게 하면 커맨드를 보내고 서버를

07:37.110 --> 07:38.190
재부팅하라고 할

07:38.190 --> 07:40.080
때 커맨드가 도달해서 서버를 재부팅할

07:40.080 --> 07:42.060
것을 알 수 있습니다

07:42.060 --> 07:44.820
네 마찬가지로 https에선 tcp를

07:44.820 --> 07:46.680
이용해 연결을 꽉 채우거나

07:46.680 --> 07:50.040
연결 지향적인 프로토콜을 확보하려 해요

07:50.040 --> 07:51.120
네 그 이유는 우리가

07:51.120 --> 07:52.440
보내는 게 정말 저기로

07:52.440 --> 07:54.690
수신되는지 확인하려는 거죠

07:54.690 --> 07:56.790
인증을 포함할 수 있습니다 사용자

07:56.790 --> 07:58.500
이름과 암호로 웹사이트에

07:58.500 --> 08:01.500
로그인할 때요 혹은 웹사이트에서 돌아오는

08:01.500 --> 08:03.030
정보일 수도 있죠 계좌

08:03.030 --> 08:06.180
잔고나 은행 정보 같은 거요

08:06.180 --> 08:07.013
자 반대로 udt를

08:07.013 --> 08:08.970
사용하면 연결이 안 되는 방식으로

08:08.970 --> 08:11.400
진행됩니다

08:11.400 --> 08:12.390
네 자

08:12.390 --> 08:13.470
이제

08:13.470 --> 08:15.600
,

08:15.600 --> 08:16.680
그러나 그 외에도 DHCP

08:16.680 --> 08:19.230
및 TFTP로 알려진 Trivial File Transfer

08:19.230 --> 08:23.130
Protocol과 같은 용도로도 사용합니다.

08:23.130 --> 08:24.030
네 자 기억하시는지

08:24.030 --> 08:27.480
모르겠지만 dhcp는 동적 호스트 컨트롤 프로토콜로

08:27.480 --> 08:30.660
사용되고 포트 67과 68에서 동작합니다 ?

08:30.660 --> 08:32.310
네 이제 네트워크에 합류할 때

08:32.310 --> 08:33.690
여러분의 장치가 ip 주소의

08:33.690 --> 08:35.850
동적 배정을 위해 설정됐다면 dhcp

08:35.850 --> 08:38.520
서버를 찾는 브로드캐스트 메시지를 해당 네트워크에

08:38.520 --> 08:40.650
전송할 겁니다 ?

08:40.650 --> 08:43.860
그래서 연결 없는 프로토콜로 사용합니다

08:43.860 --> 08:47.220
왜냐하면 정보를 전송했는데 아무도 응답하지 않으면 여러분의

08:47.220 --> 08:49.530
클라이언트는 그냥 그걸 다시 전송할 테니까요

08:49.530 --> 08:51.510
다른 사람이 있길 바라면서요

08:51.510 --> 08:53.070
Dhcp가 그렇게 작동합니다

08:53.070 --> 08:55.080
방송 메시지가 발송되게 하고

08:55.080 --> 08:57.090
응답이 오길 기다립니다

08:57.090 --> 08:58.170
특정 시간 내에

08:58.170 --> 08:59.340
그 반응을 얻지

08:59.340 --> 09:01.560
못하면 메시지를 다시 전송해

09:01.560 --> 09:04.590
새 dhcp 서버를 찾을 겁니다

09:04.590 --> 09:06.960
네 자 마찬가지로 포트 69에서

09:06.960 --> 09:09.060
tftp, 또는 사소한 파일

09:09.060 --> 09:11.250
전송 프로토콜이 실행될 경우

09:11.250 --> 09:13.380
연결 없이 작동할 겁니다 udt를

09:13.380 --> 09:15.690
이용해 전송하고요 ?

09:15.690 --> 09:16.680
네 tftp는

09:16.680 --> 09:20.250
사소한 파일 전송 프로토콜이기 때문에 모든 패킷이

09:20.250 --> 09:22.740
해당 확인 문서를 통해 전송되고 수신된다는

09:22.740 --> 09:24.960
확신을 가질 필요가 없습니다 tcp를

09:24.960 --> 09:26.250
사용하면 오버헤드가

09:26.250 --> 09:29.190
더 많이 발생하고요

09:29.190 --> 09:30.600
네 udp를 사용하면

09:30.600 --> 09:32.430
파일 전송이 빨라지죠 tftp

09:32.430 --> 09:34.500
같은 걸 사용하면요 ftp

09:34.500 --> 09:38.163
같은 연결 풀 프로토콜 대신에요
