¿Cómo hacer la red de ordenadores --tcp transmisión de datos fiable

I. Introducción

En estos días, escribieron cuatro TCPseries de blog, éste es el quinto capítulo, también se espera que sea el último en este momento, y me empiezan a terminar el estudio de esta capa de red. Porque si mis otros TCPaspectos de interés del blog, van a mi blog personal se pueden encontrar en la red informática de esa categoría. Este blog sólo para hablar TCPes el medio por el cual para garantizar la transmisión de datos fiable.

En segundo lugar, el texto

existen problemas de transmisión 2.1 red

Investigación TCPantes de cómo garantizar una transmisión de datos fiable, enumeraremos los que hay un problema de transmisión de red, sólo para encontrar el problema, se puede abordar el problema, encontrar maneras de hacer frente. TCPEs confiar en la capa de red IPde protocolo para enviar datos, mientras que el IPprotocolo es un protocolo fiable, que no es sólo la mejor transmisión de esfuerzo, pero no garantiza la integridad de datos puede alcanzar, incluso puede garantía de que los datos lleguen. Mientras tanto, la unidad de red máxima (MTU) permitido la transmisión está limitada, típicamente 1500bytes. Por lo tanto, TCPcon el fin de transmitir datos más grandes que esto, es necesario dividir los datos en un segmento de datos se transmite. Por estas razones, la red transmitirá los siguientes problemas:

Los datos se corrompe durante la transmisión, los bits 0en 1, o 1en 0;
La pérdida de datos durante la transmisión no llega a un destino;
Una pluralidad de segmentos de paquetes de orden llega en el lado receptor, el lado de recepción no pueden correctamente los datos de composición;

TCPLa realización es básicamente acerca de las tres preguntas anteriores, así como la forma de mejorar la velocidad de transferencia alcanzado. Aquí tenemos que hablar TCPcon el fin de hacer frente a estos problemas anteriores lo que había sido cosa hecha.

2.2 TCP resolver la corrupción de datos

Primero discutimos la primera pregunta, los datos están dañados. Compruebe si los datos son el modo de comprobación de los datos corruptos, lo que sigue es un formato de paquete TCP, que se puede ver a 16bits del campo, llamados suma de comprobación , que se utiliza si la parte de datos de comprobación de errores receptor.

El nombre del campo se llama una suma de comprobación , debido TCPa la forma es comprobar el algoritmo de control de datos, el proceso del algoritmo es el siguiente:

El campo de suma de comprobación se ajusta 0, a continuación, las partes de datos a 16bits como una unidad, dividida;
Después de varias unidades dividieron adición binaria, si el resultado además de la primera carry 17bits, en los 17bits a la primera bit (de hecho, del complemento y de cálculo resultados, también conocido como de rebobinado), añade la final invertida ( 0convertido en 1, 1se convierte en 0), y después en el campo de suma de comprobación;
Después de que el segmento se envía al destino, el host de destino también por encima de dos pasos, entonces el resultado de la operación con el campo de cabecera de comprobación se añaden, a continuación, negada si el resultado es 0, que los datos hay error;

Esto es como jugar un papel en el control de ella? Es muy simple, se supone en el proceso de transmisión de datos, los datos no está en error, el extremo de transmisión y extremo receptor, el resultado obtenido es el mismo. La comprobación sobre el terreno es el resultado de anti-código, es decir, el resultado es 1la posición, es en el campo anti-código 0, y el resultado de 0la posición, es decir, anti-código 1. Es decir, en el caso en el que se añaden ningún error en los datos, y una comprobación sobre el terreno los resultados, debe ser completa 1, y luego re-invertida, es decir, 0la. Siempre y cuando no se obtiene el resultado final 0, el destinatario se considera errores de datos (después de error de cómo hacer frente a, no encuentro información relevante, vergüenza).

Sin embargo, el algoritmo anterior podrá verificar si los datos es un error? La respuesta es no. Debido a esta comprobación fundamental, pero es en realidad la suma de datos, y luego determinar que no hay ningún cambio en ella. Y todos sabemos que 1+2 == 2+1, 1 + 4 == 2 + 3basándose únicamente en la suma, no hay garantía de que no hay ningún cambio en los datos. Mientras se han producido muchos errores en los datos, y se anulan entre sí, este algoritmo no detectará. Pero TCPsigue utilizando este algoritmo, yo personalmente creo que la razón es simple, y la probabilidad de error en la red de datos no es muy alta, pero muchos de la probabilidad de error y se anulan entre sí, incluso más pequeño, por lo que la fiabilidad de este algoritmo es todavía relativamente alta a.

2.3 TCP problema de pérdida de paquetes para resolver

TCPLa solución es la pérdida de datos de tiempo de espera de retransmisión . TCPMantendrá un temporizador, y el establecimiento de un tiempo de espera, cuando se envía un TCPsegmento trasero, no ha sido paquete ACK dentro del tiempo de espera, el remitente que los datos se pierde, entonces la retransmisión del segmento faltante, hasta recepción. Debido a TCPla utilización de una transmisión de la tubería , al mismo tiempo, puede haber más se han enviado pero no recibido ACKsegmento, por lo que lógicamente hablando, TCPpara mantener varios temporizadores, un enlace para cada segmento, pero esto no tendrá un costo mayor, pero también muy complejo para la gestión de temporizadores. Así que TCP, de hecho, sólo se mantendrá un temporizador, el registro actual es el primero en ser enviado, pero que aún no ha recibido ACKlos paquetes de segmentos. Cuando este segmento de tiempo de espera, el remitente retransmitirá segmento, y reiniciar el temporizador, si el segmento recibido del ACKpaquete, también se reinicia el temporizador, pero esta vez es el más antiguo enviado pero que todavía no reconoce los paquetes segmento ha cambiado, esta vez registrada es el tiempo de transmisión de este nuevo segmento de. Además, la activación de retransmisión rápida , el temporizador se reiniciará. Acerca de TCPtransmisión de la tubería, lo que puedo hacer referencia a esta entrada del blog: https://www.cnblogs.com/tuyang1129/p/12450978.html .

Aquí hay un problema complejo, el tiempo de espera será cómo configurar? No es difícil pensar que el tiempo de espera debe ser un poco más grande que los datos de tiempo de ida y vuelta (RTT), por ejemplo, los datos del emisor al receptor al ACKmensaje, la proporción 200msque el tiempo de espera debe ser ligeramente mayor que este valor, por ejemplo 400ms. Pero la red es inestable, para cada paquete, ya que los diferentes caminos a través de los diferentes niveles de congestión de la red, más o menos tiempo de ida y vuelta van a cambiar. Así que para este tiempo de espera, debe ser calculado en base al promedio de RTT. Pero los promedios estadísticos directa demasiado difícil para TCPél, un conjunto de complejos algoritmos para calcular el tiempo de espera.

Para calcular el RTTpromedio aproximado, debemos primero tener el valor de la muestra, suponiendo que la muestra RTT definido SampleRTT. TCPDurante los procedimientos de operación, se puede medir en cualquier momento SampleRTT, es decir, una medición enviado de forma de paquetes al receptor desde ACKel tiempo utilizado, a continuación, se utiliza para calcular RTTel promedio ponderado. A continuación, durante un período de tiempo, una vez más, y la nueva medida SampleRTTpara la actualización de la media ponderada. Suponiendo que la media ponderada RTTse define como EstimatedRTTen la TCPespecificación, el cálculo EstimatedRTTfórmula es:

EstimatedRTT = （1- α）*EstimatedRTT + α * SampleRTT(Una fórmula)

En donde SampleRTTes la última muestra medida RTTpuede determinarse dinámicamente por la anterior fórmula RTTmedia ponderada. Debido a la medida más adelante SampleRTT, cuanto más cerca de la red en la situación actual, por lo que la actualización del EstimatedRTTproceso, la última SampleRTTsupone que ocupar más peso, por lo que en el TCPpliego de condiciones, se recomienda αestablecer el valor 1/8, por lo que la fórmula anterior es:

EstimatedRTT = 0.875 * EstimatedRTT + 0.125 * SampleRTT

Y SampleRTTla EstimatedRTTfluctuación de la figura siguiente:

Además de buscar RTTel promedio ponderado de las redes RTTcambios también son necesarias, después de todo, puede verse en la figura, la muestra RTTde fluctuación es muy grave, solamente EstimatedRTT, no es suficiente para hacernos una estimación precisa de tiempo de espera. Así que tenemos que encontrar SampleRTTel EstimatedRTTgrado de desviación, que es similar a la varianza , la varianza de forma dinámica conjunto de tiempo de espera. Suponiendo que la varianza se define como DevRTTse TCPdefine en la especificación DevRTTse calcula como sigue:

DevRTT = （1 - β）* DevRTT + β * | SampleRTT - EstimatedRTT |(D Oficial)

Como puede verse a partir de la ecuación anterior, si la SampleRTTfluctuación es grande, DevRTTun valor grande será, y viceversa será pequeño. En la TCPespecificación del βvalor recomendado es 0.25. Ahora sabemos que el RTTpromedio ponderado, pero también sabemos RTTlas fluctuaciones, es el momento de considerar cómo establecer el tiempo de espera. No es difícil pensar, el tiempo de espera se debe exigir que RTTel promedio ponderado, que es EstimatedRTTmás grande, por lo que la mayoría de los segmentos de RTTmenor que este valor, a fin de evitar tiempo de retransmisión frecuente. Ese número debe ser grande? Considere esto, cuando el picado de la red, representa el real RTTdebe ser de EstimatedRTTmás lejos, mientras que menos volátil, el real RTTdebería estar cerca EstimatedRTT, pero esto fluctuaciones de valor, hemos calculado, que es una fórmula DevRTT, por lo supone que el tiempo de tiempo de espera se define como TimeoutInterval, TCPespecificación recomienda su valor se calcula utilizando:

TimeoutInterval = EstimatedRTT + 4 * DevRTT(Fórmula III)

Por lo tanto, si un promedio ponderado o una fluctuación en una red se tienen en cuenta. La TCPnorma inicial recomendada TimeoutIntervalpara el 1s(entonces ver en esta parte del libro, sólo para comprender profundamente las matemáticas poderosas, teoría de Barbara en práctica). Por supuesto, el cálculo para el período de tiempo de espera, hay dos excepciones:

Cuando un tiempo de espera de segmento, el remitente retransmitirá este segmento, mientras que de nuevo en el contador de tiempo, el tiempo de espera se establece en los últimos dos veces , en lugar de utilizar el valor calculado con la fórmula 3, o si el tiempo de espera, tiempo de retransmisión continua a triplicar de nuevo hasta que el mensaje se recibe correctamente, mientras recibido con éxito, se vuelve a calcular utilizando la fórmula de tres de tiempo de espera. El objetivo es evitar que múltiples derivaciones de tiempo de espera para una retransmisión continua, lo que resulta en la congestión de la red es más grave, después de todo, el tiempo de espera es el resultado de la congestión de la red.
Registros de muestra RTT, la selección no serán retransmitidos segmento como una muestra, es porque, cuando se produce el evento de tiempo de espera, el remitente no sabe o porque los datos se pierde debido a la latencia y los tiempos de espera de la red. Si el segmento se retrasa debido a un tiempo de espera, la retransmisión de paquetes, el tiempo de retardo del ACKpaquete llega, el paquete retransmitido emisor error se recibe correctamente, entonces se detecta un error SampleRTT.

En, corta TCPel mecanismo de tiempo de retransmisión, una buena solución para el problema de la pérdida de datos se produce en la red. Por otra parte, con el fin de mejorar la eficiencia, TCPhay una retransmisión rápida mecanismo, dependiendo de las circunstancias particulares, antes de perder el tiempo de espera para determinar segmento, y luego volvió a transmitir, pero no se describe en detalle aquí.

2.4 TCP cómo resolver los datos lleguen fuera de orden

El tercer problema es que los datos lleguen fuera del problema de orden. Debido a las limitaciones de la red, TCPel más grande de los datos ha de ser dividida en una segmentos de paquete más pequeños, encapsulados en TCPsegmentos, uno por uno de la transmisión. Debido a la incertidumbre de la red de transmisión (por ejemplo, a través de camino diferente, un paquete es entonces segmento retransmitido se pierde, etc.), estos segmentos pueden no ser del todo en el orden de llegada. Por lo tanto, con el fin de ser capaz de recibir los datos completos en el receptor, y se pueden combinar secuencialmente estos mensajes, TCPdebe haber un mecanismo para resolver este problema.

TCPEl método utilizado es que cada TCPsegmento se le asigna un número de serie, se incrementa de forma secuencial el número de serie de cada segmento, de manera que el lado de recepción de acuerdo con el número de serie, se determina el segmento recibido a la que parte de los datos, y si ha recibido todas las piezas. Se va de lo anterior TCPpodemos ver la estructura de paquete de la figura, que tiene un 32位campo de número de secuencia. Sin embargo, el TCPnúmero de segmentos de no 0，1，2，3.... tan simple, que aquí nos preocupa que TCPes la forma de lograr una serie de mecanismos tales.

En primer lugar hay que aclarar un punto, TCP es un byte se numeran, en lugar de segmentos están numerados . TCPLos datos a transmitir a cada byte de un número dado, como el primer byte 0número, el segundo es un 1número, y así sucesivamente. Y cada segmento está generalmente acondicionada más de un byte de datos, por lo que TCPel segmento, los datos se encapsulan en este segmento, el primer byte del número de secuencia. Por ejemplo, digamos que un remitente para enviar 250bytes de datos, se supone que el número de secuencia inicial a partir 0del comienzo, entonces este 250número de bytes, respectivamente 0-249. Supongamos que cada segmento permite hasta paquete de 100bytes de datos, por lo que el primer segmento del paquete 1al 100número de secuencia de bytes de estos bytes 0-99, el primer segmento se 0pone en él No. parte de cabecera, y un segundo segmento de encapsulado 100-199número de bytes, por lo que su número de serie 100, y el tercer segmento encapsulado 200-249número de bytes, por lo que su número de serie 200. Lo anterior es TCPel método de procesamiento de un número del remitente.

Hablemos de TCPcómo funciona esto en el mecanismo número de destinatario. De manera similar a lo anterior tres ejemplo segmento, suponiendo que el emisor enviará el anterior tres segmentos, el primer receptor recibe un segmento, encontrado que el número de paquetes es 0, contiene 100bytes de datos, entonces el receptor confirmará al remitente que el mensaje ha sido recibido, y el reconocimiento es utilizar TCPel encabezado del número de reconocimiento de campo. Destinatario recibe el número de secuencia 0, la longitud de 100los segmentos de bytes, se ACKrellena el número de secuencia de paquete de confirmación 100, dijo que ha recibido es menor que el número 100de todos los bytes, los siguientes paquetes recibidos deseados los números de grupo es 100, y los segundos segmentos llegan fuera de orden, número de secuencia 100, una longitud de 100byte, a continuación, envía de vuelta de nuevo para el destinatario ACKdel mensaje, esta vez para el número de acuse de recibo 200, dijo que recibió 200todo byte anterior, es deseable el siguiente número de secuencia de mensaje es 200; y el número de secuencia recibido 200, la longitud 50de vuelta segmento byte, el número de secuencia de acuse de recibo se envía 250paquetes ACK.

Estos se recibe secuencialmente el segmento, se supone en el caso anterior, el orden de llegada de los paquetes es de tres 0 -> 100, es decir, de pedido, a continuación, se produce el siguiente -> 200:

Destinatario recibe el número 0, la longitud de los 100bytes del segmento, loopback número de acuse de recibo de 100la ACKmensaje;
Recepción de un número de secuencia 200, una longitud de 50segmentos de bytes, entonces los deseos receptores para recibir el 100número de paquetes llegan fuera de orden para que se produzca la situación determinada, no entrega de datos a la sección superior, pero en recibir tampón;
Recibido número de secuencia 100, la longitud del 100segmento, 100que está a la espera de los números de segmento destinatario ha recibido, por lo que se recibe y se entrega a la capa superior, mientras que el número de serie se encuentra en el búfer de 200segmento, que es positivo el receptor está esperando el siguiente mensaje es recibido, entonces sacada, la entrega superior, mientras que el remitente para enviar ACKel mensaje, ACKel número de secuencia de acuse de recibo 250que indique que han recibido 250todos los bytes de la anterior, la llegada siguiente mensaje esperado el número es el texto 250;

A través del mecanismo anterior, el destinatario resuelto satisfactoriamente el problema de los datos que llegan fuera de orden. Por supuesto, el uso de este mecanismo de números, de hecho, más que simple, que implica también el mecanismo de transporte por tubería TCP, si usted quiere saber, puede hacer referencia a mi otro blog - https://www.cnblogs.com /tuyang1129/p/12450978.html .

También hay un problema, en el ejemplo anterior, supongo que ese número es de 0principio, pero no es el caso. En una implementación real, el número se calcula generalmente por un valor aleatorio algoritmo especial, hay dos razones para esto:

Suponga que cada TCPnúmero se conectan desde el 0principio, se supone que el servidor Xianxiang cliente envía un mensaje, no hay confirmación se recibe, desconecte inmediatamente, pero después de la desconexión, y establece inmediatamente una conexión, y en este momento, por primera vez enviado el segmento justo llegar al servidor, lo que sucedería. El servidor va a pensar que esto es para establecer los datos enviados a través de la conexión, y porque los dos números iniciales están conectados 0, el receptor pondrá esta recepción segmento. A fin de reducir la probabilidad de ocurrencia de situaciones similares, TCPel número de secuencia inicial aleatoria, de modo que dos número de secuencia inicial diferente conectado a una gran probabilidad, a continuación, cuando se produce esta situación, el receptor no puede recibir el segmento;
La segunda razón es por razones de seguridad, si los números iniciales son fijos, que cada segmento del número de serie puede especular dibujado, por lo que los hackers pueden utilizar para simular el emisor envía un paquete TCP, realizar ataques, como el envío de un gran número de solicitudes de conexión, ocupando recursos del servidor;

control de flujo de 2,5 TCP y el control de congestión

control de flujo de control y la congestión, estrictamente hablando, no es un TCPmecanismo de transporte fiable, pero, una especie de relación, por lo que menciono.

Control de flujo: TCPla recepción de un buffer de recepción Fangkuai Wei celebración para recibir los datos enviados por el remitente. Sin embargo, el búfer de recepción no es infinito, si el búfer está lleno, más tiempo recibir datos en este momento, no va a ser capaz de recibir, sólo puede ser desechada. Por lo tanto, con el fin de reducir la ocurrencia de esta situación, TCPla necesidad receptor para informar al remitente que puede llegar hasta a la cantidad de datos que se recibe, TCPel remitente sobre la base de esta información, tiene una opción para enviar datos, que es el control de flujo;
El control de congestión: control de flujo y similares, pero no para limitar la cantidad de datos se envía al destinatario, pero el router. Routers también buffer de recepción, si demasiado de datos está presente en el tampón de recepción del router, también afectan a la red de transmisión, por lo que la tasa de pérdida de paquetes de red y control de congestión es controlar los datos de transmisión de acuerdo con el estado de congestión de la red;

Estos dos mecanismos, de control de flujo es relativamente simple. Podemos ver que en TCPel formato del mensaje, hay una sección llamada el tamaño de la ventana, que es parte del receptor indica al emisor que puede presentar un máximo de la cantidad de datos que se recibe, y el remitente enviaremos longitud de datos es menor que el tamaño de la ventana . Sin embargo, hay un caso especial, si el tamaño de la ventana es 0, para la ventana actual está llena, el emisor no envía datos en circunstancias normales, pero en realidad, el remitente sigue transmitiendo un byte de datos en el lado receptor, como una tipo de tentación. Debido a que el receptor por lo general no envía el mensaje al remitente, el tamaño de la ventana por lo general se realiza en ACKel paquete, si el tamaño de la ventana es en este momento 0, el emisor no enviará datos, el receptor no será capaz de enviar al remitente ACKinforme Wen, esta vez, incluso si la caché se limpia, el remitente no sabe. Por lo tanto, incluso si el tamaño de la ventana 0, el emisor aún tendrá que enviar datos, exploratorios, si la memoria caché ha sido aprobado por el mensaje tentaciones ACKde paquetes, el remitente será capaz de saber.

El control de congestión es TCPun mecanismo relativamente complejo, no pocas palabras para decir con claridad, esta parte he escrito un blog específicamente explicó, interesados pueden leer sobre: https://www.cnblogs.com/tuyang1129 /p/12439862.html .

En tercer lugar, el resumen

Para la TCPdescripción de transmisión fiable describe aquí. El contenido de arriba es TCPuna introducción básica a los principios de la transmisión fiable, pero la aplicación específica puede ser mejorado y optimizado en estas bases. TCPUna variedad de mecanismos complementarios, ya que si TCPno hay mucho que entender, puede haber algunas presentaciones no entienden, así que si usted quiere realmente llegar a conocer TCPel conocimiento y otras redes informáticas pertinentes, se recomienda comprar un libro de estudio sistemático. Espero que esta ayuda blog de la gente ve si el contenido del blog está mal, corregir mi esperanza.

En cuarto lugar, la referencia

"Computer Network - enfoque de arriba hacia abajo (séptima edición del libro original)"