WEBVTT

00:00.090 --> 00:01.020
Jason: Nesta lição,

00:01.020 --> 00:03.480
discutiremos os tipos de protocolo IP,

00:03.480 --> 00:05.637
incluindo TCP, UDP e os conceitos de

00:05.637 --> 00:07.650
métodos sem conexão versus métodos

00:07.650 --> 00:10.020
orientados à conexão.

00:10.020 --> 00:12.300
Agora, o que é TCP?

00:12.300 --> 00:15.270
TCP é um protocolo de controle de transmissão.

00:15.270 --> 00:17.340
É um protocolo orientado à conexão, o

00:17.340 --> 00:18.990
que significa que é uma maneira

00:18.990 --> 00:22.080
confiável de transportar segmentos em nossa rede.

00:22.080 --> 00:23.580
Agora, se um segmento for descartado,

00:23.580 --> 00:25.770
o protocolo solicitará o reconhecimento todas

00:25.770 --> 00:26.603
as vezes.

00:26.603 --> 00:28.890
E se não receber essa confirmação,

00:28.890 --> 00:31.530
ele reenviará a informação.

00:31.530 --> 00:34.410
É por isso que chamamos esse protocolo de conexão completa, porque

00:34.410 --> 00:36.960
ele tem esse tipo de informação bidirecional em que estou

00:36.960 --> 00:38.280
enviando informações e estou

00:38.280 --> 00:40.200
verificando se você realmente as recebeu,

00:40.200 --> 00:43.170
ouvindo que você as recebeu e me dando uma resposta.

00:43.170 --> 00:44.640
Agora vamos dar uma olhada neste pequeno

00:44.640 --> 00:46.230
diagrama aqui na tela por um segundo.

00:46.230 --> 00:48.210
Você verá que tenho um cliente à esquerda

00:48.210 --> 00:49.800
e um servidor à direita.

00:49.800 --> 00:52.860
Agora, o cliente enviará o que é chamado de pacote syn,

00:52.860 --> 00:54.510
ou pacote de sincronização,

00:54.510 --> 00:55.950
para o servidor.

00:55.950 --> 00:57.240
Agora, quando o servidor receber

00:57.240 --> 00:58.170
isso, ele enviará de

00:58.170 --> 01:00.720
volta uma confirmação de sincronização para o cliente,

01:00.720 --> 01:02.580
conhecida como syn ack.

01:02.580 --> 01:04.740
Agora, quando o cliente receber essa confirmação,

01:04.740 --> 01:07.380
ele enviará de volta sua própria confirmação para o servidor.

01:07.380 --> 01:09.060
Isso é conhecido como ack.

01:09.060 --> 01:11.940
Agora, quando fazemos esse syn, syn ack, ack,

01:11.940 --> 01:15.030
isso é o que chamamos de handshake de três vias.

01:15.030 --> 01:16.807
Essencialmente, o cliente diz: "Ei, servidor,

01:16.807 --> 01:21.367
você está pronto para obter algumas informações? E então o servidor diz: "Claro.

01:21.367 --> 01:21.367
Por que não?

01:21.367 --> 01:22.920
"Envie-me algumas informações. E o cliente diz:

01:22.920 --> 01:25.440
"Ok, aqui vai. E, então, a transmissão começará porque

01:25.440 --> 01:27.630
estabelecemos esse aperto de mão

01:27.630 --> 01:29.940
de três vias e sabemos que ambos os lados

01:29.940 --> 01:32.737
estão prontos para se comunicar.

01:32.737 --> 01:35.107
"Agora, você está pronto? "Sim, estou.

01:35.107 --> 01:35.107
"Aí

01:35.107 --> 01:36.810
vem. Agora, toda vez que esses dados,

01:36.810 --> 01:39.150
que chamamos de segmento, forem enviados

01:39.150 --> 01:40.710
pela rede, haverá uma confirmação

01:40.710 --> 01:43.080
de que foram recebidos e isso nos diz que houve

01:43.080 --> 01:46.980
uma comunicação bidirecional bem-sucedida.

01:46.980 --> 01:48.600
Agora, se esse servidor estiver

01:48.600 --> 01:50.370
esperando receber 100 informações,

01:50.370 --> 01:52.500
mas só tiver recebido 98 delas, ele dirá

01:52.500 --> 01:53.587
ao cliente: "Ei, você

01:53.587 --> 01:56.347
me disse que ia me enviar 100 coisas", mas só me enviou

01:56.347 --> 01:58.177
98.

01:58.177 --> 02:00.450
"Envie-me as duas coisas que estão faltando. Em seguida, ocorre uma

02:00.450 --> 02:02.730
retransmissão.

02:02.730 --> 02:03.563
Dessa forma, a comunicação

02:03.563 --> 02:05.310
pode ser feita por nós e sempre podemos

02:05.310 --> 02:06.240
ter certeza de que estamos

02:06.240 --> 02:07.470
recebendo o que deveríamos,

02:07.470 --> 02:09.450
pois temos esse reenvio dos pacotes pela

02:09.450 --> 02:10.920
rede.

02:10.920 --> 02:13.170
Agora, ele é usado para todos os dados de rede

02:13.170 --> 02:16.830
que precisam ser assegurados para chegar ao destino final.

02:16.830 --> 02:19.470
Gosto de pensar nisso como uma correspondência certificada.

02:19.470 --> 02:22.440
Se eu quiser enviar uma mensagem para o IRS, por exemplo, quero ter

02:22.440 --> 02:23.970
certeza de que eles a receberão e que

02:23.970 --> 02:25.620
ela não se perderá no correio.

02:25.620 --> 02:27.630
Portanto, talvez eu pague um pouco mais para obter

02:27.630 --> 02:29.160
um recibo certificado que, quando chegar

02:29.160 --> 02:31.080
lá, eles tenham que assinar e que seja enviado

02:31.080 --> 02:32.820
de volta para mim pelo correio.

02:32.820 --> 02:33.653
Dessa forma, quando

02:33.653 --> 02:34.740
eu receber o recibo de volta,

02:34.740 --> 02:37.500
saberei que o IRS recebeu meu pacote postal.

02:37.500 --> 02:39.960
É assim que o TCP funciona.

02:39.960 --> 02:41.220
Agora, por outro lado,

02:41.220 --> 02:44.250
temos outro protocolo conhecido como UDP.

02:44.250 --> 02:47.250
O UDP é o que chamamos de protocolo sem conexão, o que significa

02:47.250 --> 02:49.770
que ele não precisa esperar por conexões.

02:49.770 --> 02:52.830
UDP significa User Datagram Protocol (Protocolo de Datagrama do Usuário).

02:52.830 --> 02:54.270
E o motivo pelo qual o chamamos de

02:54.270 --> 02:56.160
datagrama é que, se você estiver usando UDP,

02:56.160 --> 02:57.750
estará usando esse tipo de dados.

02:57.750 --> 02:59.220
Ele é chamado de datagrama.

02:59.220 --> 03:01.317
Agora, quando falamos de UDP, o UDP

03:01.317 --> 03:03.060
não é confiável e transmite

03:03.060 --> 03:05.490
segmentos chamados datagramas.

03:05.490 --> 03:06.510
E se forem descartados,

03:06.510 --> 03:09.000
o remetente nunca saberá que isso aconteceu.

03:09.000 --> 03:10.830
Agora, por que eu gostaria de enviar coisas para

03:10.830 --> 03:12.300
as quais o remetente não tem conhecimento

03:12.300 --> 03:14.220
e eu não recebo nenhum tipo de recibo?

03:14.220 --> 03:17.850
Bem, o UDP é realmente bom para streaming de áudio e vídeo porque

03:17.850 --> 03:19.920
você envia muitos dados e há muito menos

03:19.920 --> 03:22.620
sobrecarga quando você usa o UDP, porque não temos

03:22.620 --> 03:24.810
aquele constante handshake de três vias

03:24.810 --> 03:25.950
para estabelecê-lo

03:25.950 --> 03:27.840
e não temos todas as verificações

03:27.840 --> 03:30.840
e balanços associados ao uso do TCP.

03:30.840 --> 03:32.520
Portanto, ao usar o UDP, você

03:32.520 --> 03:35.190
pode realmente aumentar o desempenho da sua

03:35.190 --> 03:37.800
rede porque não haverá retransmissões.

03:37.800 --> 03:39.870
Você acabará descartando informações.

03:39.870 --> 03:41.490
Isso não é uma coisa ruim?

03:41.490 --> 03:43.530
Por que gostaríamos de descartar informações?

03:43.530 --> 03:45.300
Bem, para determinados aplicativos,

03:45.300 --> 03:46.740
isso realmente não importa.

03:46.740 --> 03:49.440
Por exemplo, você está transmitindo este vídeo agora mesmo.

03:49.440 --> 03:52.110
E se eu me afastasse por 1/100 de segundo,

03:52.110 --> 03:53.520
você perceberia?

03:53.520 --> 03:54.960
Bem, provavelmente não,

03:54.960 --> 03:56.820
e é por isso que o UDP é tão bom,

03:56.820 --> 03:59.520
pois podemos perder 1/100 do tempo aqui e você

03:59.520 --> 04:01.320
nem vai perceber, e não haverá

04:01.320 --> 04:03.120
retransmissão.

04:03.120 --> 04:04.740
Mas, com o TCP, haverá muito mais

04:04.740 --> 04:06.300
buffering, porque você terá

04:06.300 --> 04:07.440
que esperar, receber

04:07.440 --> 04:08.670
o arquivo de volta, colocá-lo

04:08.670 --> 04:11.250
no lugar certo e reproduzi-lo.

04:11.250 --> 04:13.770
Assim, devido a esse reconhecimento e a essa sobrecarga,

04:13.770 --> 04:15.870
para cada segundo desse vídeo, ele acabará

04:15.870 --> 04:17.880
se tornando muito maior e usando muito

04:17.880 --> 04:19.830
mais largura de banda.

04:19.830 --> 04:21.150
E esse é um dos principais motivos

04:21.150 --> 04:24.660
pelos quais usamos o UDP para streaming de vídeo e streaming de áudio.

04:24.660 --> 04:28.740
Agora, vamos fazer um pequeno resumo sobre TCP e UDP.

04:28.740 --> 04:31.410
Porque esse é um conceito muito, muito importante.

04:31.410 --> 04:33.600
Na verdade, se você estiver com suas anotações

04:33.600 --> 04:35.160
em mãos, eu anotaria este gráfico

04:35.160 --> 04:36.420
que vou lhe contar agora, quando

04:36.420 --> 04:38.520
falarmos sobre TCP versus UDP.

04:38.520 --> 04:40.770
Porque é realmente muito importante.

04:40.770 --> 04:43.380
Agora, primeiro, o TCP é confiável, ele tem um

04:43.380 --> 04:44.820
handshake de três vias, enquanto

04:44.820 --> 04:47.040
o UDP não é muito confiável.

04:47.040 --> 04:48.540
É um protocolo não confiável

04:48.540 --> 04:51.180
porque não há handshake de três vias.

04:51.180 --> 04:53.490
O TCP é o que chamamos de orientado à conexão

04:53.490 --> 04:55.560
ou um protocolo cheio de conexões porque

04:55.560 --> 04:56.880
temos esse handshake de

04:56.880 --> 04:57.960
três vias nas confirmações,

04:57.960 --> 05:00.660
mas o UDP não tem conexão.

05:00.660 --> 05:02.550
É um método do tipo "dispare e esqueça".

05:02.550 --> 05:04.200
Eu simplesmente começo a enviar

05:04.200 --> 05:06.660
informações e espero que você as receba.

05:06.660 --> 05:10.170
O TCP usa a retransmissão de segmentos e o controle de fluxo que está sendo

05:10.170 --> 05:12.030
tratado por meio do janelamento.

05:12.030 --> 05:13.230
O UDP, por outro lado,

05:13.230 --> 05:16.230
não há retransmissão nem janelamento.

05:16.230 --> 05:17.160
Com o TCP, temos a segmentação

05:17.160 --> 05:19.140
de nosso sequenciamento de todos os nossos

05:19.140 --> 05:20.820
diferentes segmentos.

05:20.820 --> 05:23.370
Com o UDP, não há sequenciamento.

05:23.370 --> 05:25.530
Agora, o que isso significa é que, quando

05:25.530 --> 05:27.570
eu enviar tudo, vou enviar na ordem correta,

05:27.570 --> 05:28.710
de 1 a 100.

05:28.710 --> 05:31.260
Farei isso tanto para TCP quanto para UDP.

05:31.260 --> 05:32.910
Agora, se você perder algumas dessas peças,

05:32.910 --> 05:34.350
ou se elas chegarem em uma ordem diferente

05:34.350 --> 05:36.480
porque seguem um caminho diferente na rede, com o

05:36.480 --> 05:38.520
TCP, elas são sequenciadas, de modo que ele sabe

05:38.520 --> 05:40.137
que você tem uma para 1.000 e as coloca

05:40.137 --> 05:42.420
de volta na sequência correta.

05:42.420 --> 05:43.440
Com o UDP, seja qual

05:43.440 --> 05:44.850
for a forma de entrada, é

05:44.850 --> 05:46.650
assim que ele a transmitirá.

05:46.650 --> 05:48.030
Portanto, ele pode

05:48.030 --> 05:49.230
vir em um, 50, dois,

05:49.230 --> 05:50.910
500, três, quatro, cinco,

05:50.910 --> 05:53.820
seis, 20, em qualquer ordem aleatória como

05:53.820 --> 05:55.230
essa.

05:55.230 --> 05:56.580
E é assim que você vai ouvir.

05:56.580 --> 05:59.010
Portanto, com o vídeo, você pode ouvir um pouco

05:59.010 --> 06:00.780
de saltos ou chiados agudos, ou algo

06:00.780 --> 06:01.740
assim, porque um desses

06:01.740 --> 06:04.320
quadros pode ter saído de ordem.

06:04.320 --> 06:05.550
Agora, quando voltarmos

06:05.550 --> 06:08.010
ao TCP, ele reconhecerá cada um desses segmentos.

06:08.010 --> 06:09.780
E assim temos o reconhecimento.

06:09.780 --> 06:10.680
Se eu não receber a mensagem,

06:10.680 --> 06:11.513
sei que não a recebi e posso

06:11.513 --> 06:13.650
fazer com que ela seja retransmitida para mim e depois recebê-la

06:13.650 --> 06:15.000
novamente.

06:15.000 --> 06:17.190
Com o UDP, não há confirmação.

06:17.190 --> 06:20.220
Portanto, novamente, o UDP tem muito menos sobrecarga

06:20.220 --> 06:21.540
porque não há conexão,

06:21.540 --> 06:23.790
janelamento, retransmissão, sequenciamento

06:23.790 --> 06:26.610
e confirmação.

06:26.610 --> 06:28.620
Agora, se você precisa enviar algo para

06:28.620 --> 06:30.870
lá e quer ter certeza de que a pessoa o recebeu,

06:30.870 --> 06:34.590
você realmente precisa usar o TCP como protocolo de escolha.

06:34.590 --> 06:36.930
E é por isso que realmente usaremos o TCP para

06:36.930 --> 06:39.510
serviços bancários, sites, comércio eletrônico

06:39.510 --> 06:40.770
e coisas do gênero.

06:40.770 --> 06:42.900
Mas se tivermos algo que contenha muitos dados,

06:42.900 --> 06:44.550
como streaming de áudio ou vídeo,

06:44.550 --> 06:46.560
o UDP se sairá muito bem com isso, pois não

06:46.560 --> 06:47.490
precisaremos obter

06:47.490 --> 06:49.320
cada parte do arquivo.

06:49.320 --> 06:50.880
Podemos pular um pouco

06:50.880 --> 06:52.510
aqui e ali, e tudo bem.

06:52.510 --> 06:54.570
-: [Outro instrutor] Agora, no que diz respeito

06:54.570 --> 06:56.820
ao TCP e ao UDP, falamos sobre o fato de que esses são protocolos

06:56.820 --> 06:58.560
com conexão completa ou orientados à conexão

06:58.560 --> 07:00.510
e protocolos sem conexão.

07:00.510 --> 07:02.190
Então, vou lhe dar alguns exemplos

07:02.190 --> 07:05.340
de protocolos que usam TCP ou UDP para que você possa entender

07:05.340 --> 07:07.680
por que usamos cada um deles.

07:07.680 --> 07:08.513
Primeiro, vamos dar

07:08.513 --> 07:09.420
uma olhada no TCP e em

07:09.420 --> 07:12.750
nossos protocolos orientados à conexão ou cheios de conexão.

07:12.750 --> 07:17.520
Isso inclui coisas como SSH e HTTP ou HTTPS.

07:17.520 --> 07:20.940
Por que precisaríamos de orientação para conexão nesses casos?

07:20.940 --> 07:23.490
Bem, no caso de usar algo como o SSH, estou fazendo

07:23.490 --> 07:25.710
comunicação bidirecional e controle do

07:25.710 --> 07:28.320
servidor remoto ou da estação de trabalho remota,

07:28.320 --> 07:30.390
e posso fazer isso pela porta 22.

07:30.390 --> 07:31.830
Quero ter certeza de que estou fazendo

07:31.830 --> 07:34.920
isso de uma maneira orientada para a conexão ou completa.

07:34.920 --> 07:37.110
Dessa forma, quando eu enviar um comando e disser "reiniciar

07:37.110 --> 07:38.190
o servidor", saberei que

07:38.190 --> 07:40.080
esse comando realmente chegou lá e a reinicialização

07:40.080 --> 07:42.060
do servidor ocorrerá.

07:42.060 --> 07:44.820
Da mesma forma, quando estamos lidando com HTTPS, queremos

07:44.820 --> 07:46.680
ter certeza de que estamos usando um protocolo

07:46.680 --> 07:50.040
de conexão completa ou orientado para conexão usando TCP.

07:50.040 --> 07:51.120
A razão para isso é que, novamente,

07:51.120 --> 07:52.440
queremos ter certeza de que o que

07:52.440 --> 07:54.690
estamos enviando é realmente recebido lá.

07:54.690 --> 07:56.790
E isso pode incluir coisas como autenticação

07:56.790 --> 07:58.500
quando tentamos fazer login em um site

07:58.500 --> 08:00.090
usando nosso nome de usuário e senha,

08:00.090 --> 08:01.500
ou talvez sejam as informações

08:01.500 --> 08:03.030
que recebemos desse site, como

08:03.030 --> 08:06.180
saldos de contas e informações bancárias.

08:06.180 --> 08:07.013
Por outro lado, se

08:07.013 --> 08:08.970
estivermos usando o UDP como protocolo,

08:08.970 --> 08:11.400
estaremos lidando de maneira sem conexão.

08:11.400 --> 08:12.390
Já mencionei o fato de que

08:12.390 --> 08:13.470
usamos isso o tempo todo para

08:13.470 --> 08:15.600
coisas como streaming de áudio e vídeo.

08:15.600 --> 08:16.680
Mas, além disso,

08:16.680 --> 08:19.230
também o usamos para coisas como DHCP e

08:19.230 --> 08:23.130
o Trivial File Transfer Protocol, conhecido como TFTP.

08:23.130 --> 08:24.030
Agora, se você

08:24.030 --> 08:27.480
se lembra, o DHCP é usado como Dynamic Host Control

08:27.480 --> 08:30.660
Protocol e opera nas portas 67 e 68.

08:30.660 --> 08:32.310
Agora, quando você entra em uma rede,

08:32.310 --> 08:33.690
seu dispositivo, se estiver

08:33.690 --> 08:35.850
configurado para uma atribuição dinâmica de

08:35.850 --> 08:38.520
seu endereço IP, enviará uma mensagem de difusão nessa

08:38.520 --> 08:40.650
rede procurando um servidor DHCP.

08:40.650 --> 08:43.860
E é por isso que o usamos como um protocolo sem conexão.

08:43.860 --> 08:47.220
Porque se essa informação for enviada e ninguém responder, seu cliente

08:47.220 --> 08:49.530
simplesmente a enviará novamente na esperança

08:49.530 --> 08:51.510
de que outra pessoa esteja presente.

08:51.510 --> 08:53.070
É assim que o DHCP funciona.

08:53.070 --> 08:55.080
Ele permitirá que uma mensagem de transmissão seja enviada

08:55.080 --> 08:57.090
e, em seguida, aguardará o retorno de uma resposta.

08:57.090 --> 08:58.170
Se não obtiver essa resposta

08:58.170 --> 08:59.340
em um determinado período

08:59.340 --> 09:01.560
de tempo, ele simplesmente retransmitirá sua mensagem

09:01.560 --> 09:04.590
e, novamente, procurará um novo servidor DHCP.

09:04.590 --> 09:06.960
Da mesma forma, quando temos o TFTP

09:06.960 --> 09:09.060
ou o Trivial File Transfer Protocol,

09:09.060 --> 09:11.250
que opera na porta 69, ele funcionará

09:11.250 --> 09:15.690
sem conexão usando o UDP como transporte.

09:15.690 --> 09:16.680
O motivo disso é que

09:16.680 --> 09:20.250
o TFTP é o Trivial File Transfer Protocol e, portanto, não precisamos

09:20.250 --> 09:22.740
ter a garantia de que cada pacote foi enviado

09:22.740 --> 09:24.960
e recebido com essas confirmações,

09:24.960 --> 09:26.250
o que gera muito mais sobrecarga

09:26.250 --> 09:29.190
se usarmos o TCP.

09:29.190 --> 09:30.600
Portanto, ao usar o UDP, podemos

09:30.600 --> 09:32.430
ter uma transferência de arquivos mais

09:32.430 --> 09:34.500
rápida quando estivermos usando algo como

09:34.500 --> 09:38.163
TFTP, em vez de usar um protocolo mais cheio de conexões, como o FTP.