1
00:00:00,000 --> 00:00:05,000
En su forma básica, TCP puede tener un tamaño de ventana de

2
00:00:06,000 --> 00:00:10,000
1, lo que significa que para cada segmento transmitido por

3
00:00:11,000 --> 00:00:16,000
el emisor, el receptor envía un acuse de recibo para ese segmento individual.

4
00:00:17,000 --> 00:00:19,000
Sin embargo, esto ralentiza dramáticamente

5
00:00:20,000 --> 00:00:23,000
el rendimiento porque el emisor no puede transmitir

6
00:00:24,000 --> 00:00:29,000
más datos hasta que recibe el acuse de recibo de ese único segmento transmitido.

7
00:00:30,000 --> 00:00:32,000
El rendimiento sería muy bajo dependiendo del temporizador

8
00:00:33,000 --> 00:00:34,000
de ida y vuelta

9
00:00:35,000 --> 00:00:38,000
entre el envío de datos y la recepción del acuse de recibo.

10
00:00:39,000 --> 00:00:42,000
Sin embargo, el TCP permite mayores tamaños de ventana para permitir la transmisión de más

11
00:00:43,000 --> 00:00:44,000
segmentos antes de recibir un

12
00:00:49,000 --> 00:00:50,000
acuse de recibo. 12 La ventana

13
00:00:51,000 --> 00:00:52,000
es la cantidad de segmentos

14
00:00:53,000 --> 00:00:56,000
de datos que el emisor puede enviar sin obtener un acuse de recibo del receptor.

15
00:00:57,000 --> 00:00:58,000
En este caso, lo

16
00:00:59,000 --> 00:01:02,000
hemos establecido en 1, lo que significa que cuando el servidor A

17
00:01:03,000 --> 00:01:07,000
desea enviar tráfico al servidor B puede enviar 1 segmento porque el tamaño de la ventana

18
00:01:03,000 --> 00:01:07,000
está configurado en 1 servidor B, una vez que recibe ese segmento, envía un acuse de recibo.

19
00:01:14,000 --> 00:01:18,000
En este ejemplo, supongamos que el host A envía el segmento con el número de secuencia

20
00:01:19,000 --> 00:01:21,000
de 1 host que confirmaría el segmento 2.

21
00:01:22,000 --> 00:01:24,000
El anfitrión A enviará luego el segmento

22
00:01:25,000 --> 00:01:29,000
2 y el anfitrión B, una vez que reciba con éxito ese segmento reconocerá

23
00:01:30,000 --> 00:01:32,000
o ACK para el segmento 3.

24
00:01:33,000 --> 00:01:36,000
El anfitrión A enviará el segmento 3 al host B.

25
00:01:37,000 --> 00:01:41,000
Este proceso continuará por la duración de la sesión, esto

26
00:01:42,000 --> 00:01:46,000
es obviamente muy confiable, sin embargo, el rendimiento es muy bajo.

27
00:01:47,000 --> 00:01:50,000
A necesitaría almacenar en búfer los segmentos salientes hasta que

28
00:01:51,000 --> 00:01:54,000
reciba un acuse de recibo para el segmento transmitido.

29
00:01:55,000 --> 00:01:57,000
ahora por argumento sake supongamos que el

30
00:01:58,000 --> 00:02:00,000
tráfico tarda 1 segundo en comenzar con

31
00:04:04,000 --> 00:04:06,000
el tamaño de ventana pequeño y luego

32
00:04:07,000 --> 00:04:10,000
aumenta exponencialmente el tamaño de la ventana para medir la cantidad

33
00:04:11,000 --> 00:04:15,000
de datos que el receptor puede recibir y lo que la red puede manejar.

34
00:04:16,000 --> 00:04:20,000
Probablemente lo hayas notado, cuando descargas un archivo desde Internet,

35
00:04:21,000 --> 00:04:23,000
inicialmente la velocidad de descarga

36
00:04:24,000 --> 00:04:27,000
es lenta pero luego aumenta con el tiempo.

37
00:04:28,000 --> 00:04:31,000
Esto se debe a que inicialmente el tamaño de la ventana

38
00:04:32,000 --> 00:04:35,000
es pequeño, pero luego aumenta exponencialmente hasta que se descarta un

39
00:04:36,000 --> 00:04:40,000
paquete o el host receptor no puede manejar la cantidad de datos que está recibiendo.

40
00:04:41,000 --> 00:04:43,000
Por lo que notará inicialmente, que la velocidad de descarga

41
00:04:44,000 --> 00:04:47,000
es muy lenta aumenta muy rápidamente y luego llega a un punto y luego se

42
00:04:48,000 --> 00:04:49,000
mantiene alrededor de esa velocidad.

43
00:04:50,000 --> 00:04:51,000
Entonces, una vez más, supongamos

44
00:04:52,000 --> 00:04:55,000
que los hosts en este ejemplo tienen un tamaño de ventana fijo de 3.

45
00:04:56,000 --> 00:05:01,000
Eso significa que A puede enviar 3 segmentos antes de recibir un acuse de recibo.

46
00:05:02,000 --> 00:05:05,000
Entonces, en este caso, el host A envía los acuses

47
00:05:06,000 --> 00:05:10,000
de recibo B del segmento 1, 2 y 3 para el segmento 4,

48
00:05:11,000 --> 00:05:15,000
lo que permite a A saber que recibió con éxito los hosts del

49
00:05:16,000 --> 00:05:21,000
segmento 1, 2 y 3, luego envía los segmentos 4, 5 y 6 porque tiene un tamaño

50
00:05:22,000 --> 00:05:25,000
de ventana fijo. de 3 y el anfitrión B reconoce

51
00:05:26,000 --> 00:05:31,000
el segmento 7, lo que le permite a A saber que recibió los segmentos 4,5 y 6.

52
00:05:32,000 --> 00:05:37,000
Recuerde con agradecimientos, confirme el próximo segmento que desea recibir, no el

53
00:05:41,000 --> 00:05:44,000
segmento que ya recibió. 80 Entonces, el host B no reconoce el segmento

54
00:05:45,000 --> 00:05:46,000
6, pero reconoce el segmento 7.

55
00:05:47,000 --> 00:05:52,000
Como mencioné, una ventana deslizante permite a los hosts medir la cantidad de datos

56
00:05:53,000 --> 00:05:57,000
que el receptor puede recibir y lo que la red puede manejar.

57
00:05:58,000 --> 00:06:01,000
Por lo tanto, en este ejemplo supongamos que el host está utilizando

58
00:06:02,000 --> 00:06:05,000
una ventana deslizante de la manera en que determinan lo que la

59
00:06:06,000 --> 00:06:10,000
red puede manejar, es cuando un paquete se deja caer por la red, el host se ralentizará.

60
00:06:11,000 --> 00:06:13,000
Esta información se trata con más

61
00:06:14,000 --> 00:06:17,000
detalle en los cursos que contienen la calidad del servicio.

62
00:06:18,000 --> 00:06:20,000
Con este curso asuma que

63
00:06:21,000 --> 00:06:23,000
cuando un paquete se cae,

64
00:06:24,000 --> 00:06:32,000
reducen su tamaño de ventana dramáticamente en resumen, el tamaño de ventana es la ventana otorgada al remitente por el receptor

65
00:06:33,000 --> 00:06:38,000
o una ventana calculada llamada ventana de congestión o CWND, la ventana de

66
00:06:39,000 --> 00:06:45,000
congestión o CWND es inicialmente establecido a un valor muy bajo en el establecimiento de la

67
00:06:46,000 --> 00:06:49,000
conexión y luego aumenta a una velocidad exponencial.

68
00:06:50,000 --> 00:06:53,000
Para cada segmento perdido, la ventana de congestión es la

69
00:06:54,000 --> 00:06:57,000
mitad después de que el segmento perdido ha sido retransmitido

70
00:06:58,000 --> 00:07:01,000
con éxito; la ventana de congestión vuelve a crecer hasta

71
00:07:02,000 --> 00:07:05,000
que alcanza un valor de la mitad de la ventana

72
00:07:06,000 --> 00:07:11,000
de congestión original; luego ralentiza su crecimiento, utilizando un algoritmo llamado evitación de la congestión.

73
00:07:12,000 --> 00:07:17,000
Crece exponencialmente hasta la mitad del tamaño original de la ventana de congestión

74
00:07:18,000 --> 00:07:21,000
y luego aumenta lentamente a la velocidad lineal.

75
00:07:22,000 --> 00:07:27,000
En la calidad del servicio Weighted Random Early Detection o WRED se puede utilizar

76
00:07:28,000 --> 00:07:33,000
para mejorar la eficiencia de las transmisiones TCP a través del enlace ya que

77
00:07:34,000 --> 00:07:39,000
los paquetes se eliminan aleatoriamente de varios flujos o varias sesiones que pasan por

78
00:07:40,000 --> 00:07:41,000
una interfaz individual

79
00:07:42,000 --> 00:07:45,000
en lugar de paquetes de múltiples remitentes al mismo tiempo.

80
00:07:46,000 --> 00:07:49,000
esto evita un problema llamado sincronización global en el que los paquetes de varias

81
00:07:50,000 --> 00:07:54,000
sesiones TCP caen al mismo tiempo y, por lo tanto, el host múltiple reduce el tamaño de la ventana

82
00:08:02,000 --> 00:08:04,000
y la ralentización al mismo tiempo. 110 y luego aumente

83
00:08:05,000 --> 00:08:08,000
gradualmente su tamaño de ventana y, por lo tanto, su rendimiento al mismo tiempo.

84
00:08:09,000 --> 00:08:14,000
Así que tienes muchos hosts desacelerando y acelerando al mismo tiempo

85
00:08:15,000 --> 00:08:17,000
con WRED. Algunos hosts

86
00:08:18,000 --> 00:08:24,000
se ralentizarán y otros hosts aumentarán su rendimiento debido a caídas al azar.

87
00:08:25,000 --> 00:08:30,000
Consulte la documentación de calidad de servicio para obtener más detalles sobre WRED. En

88
00:08:34,000 --> 00:08:39,000
este ejemplo, supongamos que comenzamos con el tamaño de ventana inicial de 3.

89
00:08:40,000 --> 00:08:49,000
Por lo tanto, A transmite 3 segmentos a B, sin embargo, solo el segmento 1 y 2 llegan al servidor B

90
00:08:50,000 --> 00:08:52,000
El segmento 3 se pierde.

91
00:08:53,000 --> 00:09:00,000
El servidor B puede reducir su tamaño de ventana en este ejemplo a 2 y confirmar el segmento 3.

92
00:09:01,000 --> 00:09:08,000
Recuerde que el acuse de recibo es para el próximo paquete que los hosts esperan recibir y dado que

93
00:09:10,000 --> 00:09:12,000
el host B no recibió el

94
00:09:13,000 --> 00:09:17,000
segmento 3, está acusando recibo exitoso del segmento 1 y 2.

95
00:09:18,000 --> 00:09:25,000
El host A volverá a transmitir el segmento 3 y, en este ejemplo, enviará el segmento 4, pero también solicitará un tamaño de

96
00:09:26,000 --> 00:09:27,000
ventana de 3.

97
00:09:28,000 --> 00:09:32,000
Ambos segmentos son recibidos con éxito por el servidor B, por lo que el

98
00:09:33,000 --> 00:09:35,000
servidor B confirmará el segmento 5, pero

99
00:09:36,000 --> 00:09:39,000
en este ejemplo, todavía quiere un tamaño de ventana de 2.

100
00:09:40,000 --> 00:09:45,000
El host A solo enviará 2 segmentos porque el tamaño de la ventana negociada es

101
00:09:46,000 --> 00:09:51,000
2, pero A aún puede solicitar que el tamaño de la ventana aumente a 3.

102
00:09:52,000 --> 00:09:57,000
Con la ventana deslizante, hay una negociación dinámica de un tamaño de ventana y el

103
00:09:58,000 --> 00:10:02,000
tamaño de la ventana puede cambiar drásticamente durante una sesión, dependiendo de

104
00:10:03,000 --> 00:10:07,000
lo que el receptor pueda procesar y lo que la red pueda manejar.