WEBVTT

00:00.090 --> 00:01.020
Jason: En esta lección,

00:01.020 --> 00:03.480
vamos a discutir los tipos de protocolo IP,

00:03.480 --> 00:05.637
incluyendo TCP, UDP, y los conceptos

00:05.637 --> 00:07.650
de métodos sin conexión versus métodos

00:07.650 --> 00:10.020
orientados a la conexión.

00:10.020 --> 00:12.300
¿Qué es el TCP?

00:12.300 --> 00:15.270
TCP es un Protocolo de Control de Transmisión.

00:15.270 --> 00:17.340
Es un protocolo orientado a la conexión,

00:17.340 --> 00:18.990
lo que significa que es una forma

00:18.990 --> 00:22.080
fiable de transportar segmentos a través de nuestra red.

00:22.080 --> 00:23.580
Ahora, si un segmento se cae,

00:23.580 --> 00:25.770
el protocolo pedirá acuse de recibo cada

00:25.770 --> 00:26.603
vez.

00:26.603 --> 00:28.890
Y si no recibe ese acuse de recibo,

00:28.890 --> 00:31.530
volverá a enviar esa información.

00:31.530 --> 00:34.410
Es por eso que llamamos a esto un protocolo de conexión completa,

00:34.410 --> 00:36.960
porque tiene este tipo de información de dos vías donde

00:36.960 --> 00:38.280
te estoy enviando información

00:38.280 --> 00:40.200
y estoy verificando que realmente la recibiste

00:40.200 --> 00:43.170
escuchando que la recibiste y me das una respuesta.

00:43.170 --> 00:44.640
Ahora vamos a mirar este pequeño diagrama

00:44.640 --> 00:46.230
aquí en la pantalla por un segundo.

00:46.230 --> 00:48.210
Vas a ver que tengo un cliente a la izquierda

00:48.210 --> 00:49.800
y un servidor a la derecha.

00:49.800 --> 00:52.860
Ahora, el cliente va a enviar lo que se llama un paquete

00:52.860 --> 00:54.510
syn, o un paquete de sincronización,

00:54.510 --> 00:55.950
al servidor.

00:55.950 --> 00:57.240
Ahora, cuando el servidor

00:57.240 --> 00:58.170
recibe eso, va a enviar

00:58.170 --> 01:00.720
de vuelta un acuse de recibo de sincronización al cliente,

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

01:02.580 --> 01:04.740
Ahora, cuando el cliente recibe ese acuse de recibo,

01:04.740 --> 01:07.380
va a enviar de vuelta su propio acuse de recibo al servidor.

01:07.380 --> 01:09.060
Es lo que se conoce como "ack".

01:09.060 --> 01:11.940
Ahora, cuando hacemos esto syn, syn ack, ack, esto es lo

01:11.940 --> 01:15.030
que nos referimos como un apretón de manos de tres vías.

01:15.030 --> 01:16.807
Básicamente, el cliente dice: "Oye,

01:16.807 --> 01:19.440
servidor, ¿estás listo para obtener información? Y entonces el servidor dice:

01:19.440 --> 01:21.367
"Claro.

01:21.367 --> 01:21.367
¿Por qué no?

01:21.367 --> 01:22.920
"Envíame información. Y el cliente dice:

01:22.920 --> 01:25.440
"Vale, aquí viene. Y entonces la transmisión va a comenzar porque

01:25.440 --> 01:27.630
hemos establecido ese apretón de manos

01:27.630 --> 01:29.940
a tres bandas y sabemos que ambas partes

01:29.940 --> 01:32.737
están listas para comunicarse.

01:32.737 --> 01:33.937
"Ahora, ¿estás listo? "Sí, así

01:33.937 --> 01:35.107
es. "Aquí

01:35.107 --> 01:36.810
viene. Cada vez que estos datos, que

01:36.810 --> 01:39.150
llamamos segmento, se envían a través

01:39.150 --> 01:40.710
de la red, se recibe un acuse

01:40.710 --> 01:43.080
de recibo que nos indica que se ha producido

01:43.080 --> 01:45.030
una comunicación bidireccional

01:45.030 --> 01:46.980
satisfactoria.

01:46.980 --> 01:48.600
Ahora bien, si este servidor está

01:48.600 --> 01:50.370
esperando recibir 100 piezas de información,

01:50.370 --> 01:52.500
pero sólo recibió 98 de ellas, va a decirle

01:52.500 --> 01:53.587
al cliente: "Oye, me

01:53.587 --> 01:56.347
dijiste que me ibas a enviar 100 cosas, "pero sólo me

01:56.347 --> 01:58.177
enviaste 98".

01:58.177 --> 02:00.450
"Mándame esas dos cosas que me faltan. Y entonces, se produce

02:00.450 --> 02:02.730
una retransmisión.

02:02.730 --> 02:03.563
De esta manera, la comunicación

02:03.563 --> 02:05.310
puede ir para nosotros y siempre podemos asegurarnos

02:05.310 --> 02:06.240
de que estamos recibiendo

02:06.240 --> 02:07.470
lo que se supone que debemos porque

02:07.470 --> 02:09.450
tenemos este reenvío de los paquetes a través de la

02:09.450 --> 02:10.920
red.

02:10.920 --> 02:13.170
Ahora se utiliza para todos los datos de

02:13.170 --> 02:16.830
la red que deben asegurarse para llegar a su destino final.

02:16.830 --> 02:19.470
Me gusta pensar en esto como en el correo certificado.

02:19.470 --> 02:22.440
Si quiero enviar un mensaje a Hacienda, por ejemplo, quiero

02:22.440 --> 02:23.970
asegurarme de que lo reciban

02:23.970 --> 02:25.620
y no se pierda en el correo.

02:25.620 --> 02:27.630
Así que puede que pague un poco más para obtener

02:27.630 --> 02:29.160
un recibo certificado que, cuando

02:29.160 --> 02:31.080
llegue allí, tengan que firmar y me lo

02:31.080 --> 02:32.820
envíen por correo.

02:32.820 --> 02:33.653
Así, cuando me devuelvan

02:33.653 --> 02:34.740
el recibo, sabré que

02:34.740 --> 02:37.500
Hacienda ha recibido mi paquete postal.

02:37.500 --> 02:39.960
Así funciona el TCP.

02:39.960 --> 02:41.220
Ahora, por otro lado,

02:41.220 --> 02:44.250
tenemos otro protocolo conocido como UDP.

02:44.250 --> 02:47.250
UDP es lo que llamamos un protocolo sin conexión, lo que significa

02:47.250 --> 02:49.770
que no tiene que esperar conexiones.

02:49.770 --> 02:52.830
UDP significa Protocolo de Datagramas de Usuario.

02:52.830 --> 02:54.270
Y la razón por la que lo llamamos

02:54.270 --> 02:56.160
datagrama es porque si estás usando UDP,

02:56.160 --> 02:57.750
estás usando este tipo de datos.

02:57.750 --> 02:59.220
Se llama datagrama.

02:59.220 --> 03:01.317
Ahora, cuando hablamos de UDP,

03:01.317 --> 03:03.060
UDP no es fiable y transmite

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

03:05.490 --> 03:06.510
Y si se caen, el remitente

03:06.510 --> 03:09.000
ni siquiera sabrá que ha ocurrido.

03:09.000 --> 03:10.830
Ahora bien, ¿por qué querría enviar cosas

03:10.830 --> 03:12.300
de las que el remitente no se entera

03:12.300 --> 03:14.220
y no recibo ningún tipo de acuse de recibo?

03:14.220 --> 03:17.850
Bueno, UDP es realmente bueno para el streaming de audio y visual

03:17.850 --> 03:19.920
porque envías muchos datos y hay mucha

03:19.920 --> 03:22.620
menos sobrecarga cuando usas UDP, porque no tenemos

03:22.620 --> 03:24.810
ese constante handshake de tres vías para

03:24.810 --> 03:25.950
establecerlo y no tenemos

03:25.950 --> 03:27.840
todas las comprobaciones y balances

03:27.840 --> 03:30.840
que están asociados al uso de TCP.

03:30.840 --> 03:32.520
Así que usando UDP, realmente

03:32.520 --> 03:35.190
puedes aumentar el rendimiento de tu red porque

03:35.190 --> 03:37.800
vas a tener cero retransmisiones.

03:37.800 --> 03:39.870
Acabarás dejando caer información.

03:39.870 --> 03:41.490
¿No es eso malo?

03:41.490 --> 03:43.530
¿Por qué querríamos soltar información?

03:43.530 --> 03:45.300
Bueno, para ciertas aplicaciones,

03:45.300 --> 03:46.740
realmente no importa.

03:46.740 --> 03:49.440
Por ejemplo, estás viendo este vídeo ahora mismo.

03:49.440 --> 03:52.110
Y si lo dejara durante 1/100 de segundo,

03:52.110 --> 03:53.520
¿te darías cuenta?

03:53.520 --> 03:54.960
Bueno, probablemente no lo

03:54.960 --> 03:56.820
harías y por eso UDP es tan bueno porque

03:56.820 --> 03:59.520
podemos dejar caer 1/100 del tiempo aquí y realmente

03:59.520 --> 04:01.320
nunca lo vas a notar, y no habrá una

04:01.320 --> 04:03.120
retransmisión.

04:03.120 --> 04:04.740
Pero con TCP, va a dar lugar a mucho más

04:04.740 --> 04:06.300
buffering porque tienes que esperar,

04:06.300 --> 04:07.440
y luego conseguir que te lo

04:07.440 --> 04:08.670
reenvíen, y luego ponerlo

04:08.670 --> 04:09.810
en el lugar correcto, y luego

04:09.810 --> 04:11.250
reproducirlo.

04:11.250 --> 04:13.770
Y así, debido a ese reconocimiento y esa sobrecarga,

04:13.770 --> 04:15.870
por cada segundo de este video, va a terminar

04:15.870 --> 04:17.880
haciéndolo mucho más grande y usando mucho

04:17.880 --> 04:19.830
más ancho de banda.

04:19.830 --> 04:21.150
Y esa es una de las grandes razones

04:21.150 --> 04:24.660
por las que utilizamos UDP para la transmisión de vídeo y audio.

04:24.660 --> 04:28.740
Hagamos un pequeño resumen de TCP frente a UDP.

04:28.740 --> 04:31.410
Porque este es un concepto muy, muy importante.

04:31.410 --> 04:33.600
De hecho, si tienes tus notas fuera ahora mismo,

04:33.600 --> 04:35.160
yo apuntaría este gráfico que te

04:35.160 --> 04:36.420
voy a contar ahora mismo mientras

04:36.420 --> 04:38.520
hablamos de TCP frente a UDP.

04:38.520 --> 04:40.770
Porque realmente es así de importante.

04:40.770 --> 04:43.380
Ahora, en primer lugar, TCP es fiable, tiene

04:43.380 --> 04:44.820
un handshake de tres vías,

04:44.820 --> 04:47.040
mientras que UDP no es muy fiable.

04:47.040 --> 04:48.540
Es un protocolo poco fiable

04:48.540 --> 04:51.180
porque no hay un apretón de manos a tres bandas.

04:51.180 --> 04:53.490
TCP es lo que llamamos un protocolo orientado

04:53.490 --> 04:55.560
a la conexión o a la conexión completa, porque

04:55.560 --> 04:56.880
tenemos ese apretón de manos

04:56.880 --> 04:57.960
a tres bandas en los acuses

04:57.960 --> 05:00.660
de recibo, pero UDP no tiene conexión.

05:00.660 --> 05:02.550
Es un método de disparar y olvidar.

05:02.550 --> 05:04.200
Simplemente empiezo a enviar

05:04.200 --> 05:06.660
información y espero que la recibas.

05:06.660 --> 05:10.170
TCP utiliza la retransmisión de segmentos y el control de flujo que

05:10.170 --> 05:12.030
se maneja a través de ventanas.

05:12.030 --> 05:13.230
En cambio, en UDP

05:13.230 --> 05:16.230
no hay retransmisión ni ventanas.

05:16.230 --> 05:17.160
Con TCP, tenemos segmentación

05:17.160 --> 05:19.140
de nuestra secuenciación de todos nuestros

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

05:20.820 --> 05:23.370
Con UDP, no hay secuenciación.

05:23.370 --> 05:25.530
Ahora, lo que esto significa es que a medida que

05:25.530 --> 05:27.570
envíe todo, voy a enviarlo en el orden correcto,

05:27.570 --> 05:28.710
del uno al 100.

05:28.710 --> 05:31.260
Haré esto tanto para TCP como para UDP.

05:31.260 --> 05:32.910
Ahora bien, si te pierdes algunas de esas

05:32.910 --> 05:34.350
piezas, o llegan en un orden diferente

05:34.350 --> 05:36.480
porque toman un camino diferente a través de la

05:36.480 --> 05:38.520
red, con TCP, están secuenciadas, por lo que sabe

05:38.520 --> 05:40.137
que tienes de una a 1000 y las vuelve a

05:40.137 --> 05:42.420
poner en la secuencia correcta.

05:42.420 --> 05:43.440
Con UDP, cualquiera

05:43.440 --> 05:44.850
que sea la forma en que se reciba,

05:44.850 --> 05:46.650
así es como se transmitirá.

05:46.650 --> 05:48.030
Y así, puede venir

05:48.030 --> 05:49.230
en uno, 50, dos,

05:49.230 --> 05:50.910
500, tres, cuatro, cinco,

05:50.910 --> 05:53.820
seis, 20, en cualquier orden aleatorio

05:53.820 --> 05:55.230
así.

05:55.230 --> 05:56.580
Y así es como vas a oírlo.

05:56.580 --> 05:59.010
En el caso del vídeo, es posible que oigas algunos

05:59.010 --> 06:00.780
saltos o chirridos agudos, o algo parecido,

06:00.780 --> 06:01.740
porque uno de esos fotogramas

06:01.740 --> 06:04.320
puede haberse desordenado.

06:04.320 --> 06:05.550
Ahora, cuando volvamos

06:05.550 --> 06:08.010
a TCP, va a reconocer cada uno de esos segmentos.

06:08.010 --> 06:09.780
Y así tenemos reconocimiento.

06:09.780 --> 06:10.680
Si no lo recibo, sé

06:10.680 --> 06:11.513
que no lo he recibido

06:11.513 --> 06:13.650
y puedo hacer que me lo retransmitan y volver

06:13.650 --> 06:15.000
a recibirlo.

06:15.000 --> 06:17.190
Con UDP, no hay acuse de recibo.

06:17.190 --> 06:20.220
De nuevo, UDP tiene mucha menos sobrecarga porque

06:20.220 --> 06:21.540
no hay conexión, ni ventanas,

06:21.540 --> 06:23.790
ni retransmisión, ni secuenciación,

06:23.790 --> 06:26.610
ni acuse de recibo.

06:26.610 --> 06:28.620
Ahora bien, si tienes que hacer llegar

06:28.620 --> 06:30.870
algo y quieres asegurarte de que la persona

06:30.870 --> 06:34.590
lo ha recibido, tienes que utilizar TCP como protocolo de elección.

06:34.590 --> 06:36.930
Y por eso vamos a usar TCP para cosas como

06:36.930 --> 06:39.510
la banca, los sitios web, el comercio electrónico

06:39.510 --> 06:40.770
y cosas así.

06:40.770 --> 06:42.900
Pero si tenemos algo que contiene muchos datos,

06:42.900 --> 06:44.550
como audio o vídeo en streaming, UDP

06:44.550 --> 06:46.560
funciona realmente bien porque no necesitamos

06:46.560 --> 06:47.490
obtener cada fragmento

06:47.490 --> 06:49.320
de ese archivo.

06:49.320 --> 06:50.880
Podemos saltarnos un poco aquí

06:50.880 --> 06:52.510
y allá, y eso está bien.

06:52.510 --> 06:54.570
-: [Otro Instructor] Ahora, cuando se trata de TCP

06:54.570 --> 06:56.820
y UDP, hablamos sobre el hecho de que estos son protocolos

06:56.820 --> 06:58.560
de conexión completa u orientados a la conexión,

06:58.560 --> 07:00.510
y protocolos sin conexión.

07:00.510 --> 07:02.190
Así que déjame darte un par de ejemplos

07:02.190 --> 07:05.340
de protocolos que utilizan TCP o UDP para que puedas entender

07:05.340 --> 07:07.680
por qué usamos cada uno.

07:07.680 --> 07:08.513
En primer lugar,

07:08.513 --> 07:09.420
veamos TCP y nuestros

07:09.420 --> 07:12.750
protocolos orientados a la conexión o de conexión completa.

07:12.750 --> 07:17.520
Esto incluye cosas como SSH y HTTP o HTTPS.

07:17.520 --> 07:20.940
Ahora bien, ¿por qué necesitaríamos la conexión orientada en estos casos?

07:20.940 --> 07:23.490
Bueno, en el caso de usar algo como SSH, estoy haciendo

07:23.490 --> 07:25.710
comunicación bidireccional y control de

07:25.710 --> 07:28.320
servidor remoto o estación de trabajo remota, y poder

07:28.320 --> 07:30.390
hacerlo sobre el puerto 22.

07:30.390 --> 07:31.830
Quiero asegurarme de que lo hago

07:31.830 --> 07:34.920
de una manera orientada a la conexión o llena de conexión.

07:34.920 --> 07:37.110
De esta manera, cuando envío un comando y digo,

07:37.110 --> 07:38.190
reinicia el servidor,

07:38.190 --> 07:40.080
sé que ese comando realmente llegó allí

07:40.080 --> 07:42.060
y el reinicio del servidor sucederá.

07:42.060 --> 07:44.820
Del mismo modo, cuando estamos tratando con HTTPS, queremos

07:44.820 --> 07:46.680
asegurarnos de que estamos teniendo una

07:46.680 --> 07:50.040
conexión completa o protocolo orientado a la conexión utilizando TCP.

07:50.040 --> 07:51.120
La razón de esto es, de nuevo,

07:51.120 --> 07:52.440
que queremos asegurarnos de que

07:52.440 --> 07:54.690
lo que estamos enviando es realmente recibido allí.

07:54.690 --> 07:56.790
Y eso puede incluir cosas como la autenticación

07:56.790 --> 07:58.500
cuando intentamos entrar en un sitio web

07:58.500 --> 08:00.090
con nuestro nombre de usuario y contraseña,

08:00.090 --> 08:01.500
o tal vez la información que recibimos

08:01.500 --> 08:03.030
de ese sitio web, como los saldos de

08:03.030 --> 08:06.180
nuestras cuentas y nuestra información bancaria.

08:06.180 --> 08:07.013
Ahora, por otro lado,

08:07.013 --> 08:08.970
si estamos utilizando UDP como nuestro protocolo,

08:08.970 --> 08:11.400
estamos tratando de una manera sin conexión.

08:11.400 --> 08:12.390
Ya he mencionado que

08:12.390 --> 08:13.470
lo utilizamos todo el

08:13.470 --> 08:15.600
tiempo para transmitir audio y vídeo.

08:15.600 --> 08:16.680
Pero además de eso,

08:16.680 --> 08:19.230
también lo usamos para cosas como DHCP, y el Protocolo

08:19.230 --> 08:23.130
Trivial de Transferencia de Archivos, conocido como TFTP.

08:23.130 --> 08:24.030
Ahora, si recuerdas,

08:24.030 --> 08:27.480
DHCP es usado como el Protocolo de Control Dinámico de

08:27.480 --> 08:30.660
Host y opera sobre los puertos 67 y 68.

08:30.660 --> 08:32.310
Ahora, cuando te unes a una red,

08:32.310 --> 08:33.690
tu dispositivo, si está configurado

08:33.690 --> 08:35.850
para una asignación dinámica de su dirección

08:35.850 --> 08:38.520
IP, enviará un mensaje de difusión en esa red en busca

08:38.520 --> 08:40.650
de un servidor DHCP.

08:40.650 --> 08:43.860
Por eso lo utilizamos como protocolo sin conexión.

08:43.860 --> 08:47.220
Porque si se envía esa información y nadie responde, su cliente

08:47.220 --> 08:49.530
simplemente volverá a enviarla con la esperanza

08:49.530 --> 08:51.510
de que haya alguien más.

08:51.510 --> 08:53.070
Así es como funciona DHCP.

08:53.070 --> 08:55.080
Va a permitir que un mensaje de difusión para salir,

08:55.080 --> 08:57.090
y luego esperar a que una respuesta para volver.

08:57.090 --> 08:58.170
Si no recibe esa respuesta

08:58.170 --> 08:59.340
en un plazo de tiempo determinado,

08:59.340 --> 09:01.560
simplemente volverá a emitir su mensaje y, de

09:01.560 --> 09:04.590
nuevo, buscará un nuevo servidor DHCP.

09:04.590 --> 09:06.960
Ahora, de manera similar, cuando tenemos TFTP

09:06.960 --> 09:09.060
o el Protocolo Trivial de Transferencia

09:09.060 --> 09:11.250
de Archivos, que opera sobre el puerto 69,

09:11.250 --> 09:13.380
va a funcionar de una manera sin conexión

09:13.380 --> 09:15.690
usando UDP como su transporte.

09:15.690 --> 09:16.680
La razón de esto es porque

09:16.680 --> 09:20.250
TFTP es el Protocolo Trivial de Transferencia de Archivos, y por lo

09:20.250 --> 09:22.740
tanto, no necesitamos tener las garantías de que

09:22.740 --> 09:24.960
cada paquete fue enviado y recibido con esos

09:24.960 --> 09:26.250
acuses de recibo, y eso crea

09:26.250 --> 09:29.190
mucha más sobrecarga si usamos TCP.

09:29.190 --> 09:30.600
Así que usando UDP, podemos tener

09:30.600 --> 09:32.430
una transferencia de archivos más rápida

09:32.430 --> 09:34.500
cuando estamos usando algo como TFTP, en lugar

09:34.500 --> 09:38.163
de usar un protocolo más lleno de conexiones, como FTP.