¿Qué sucede cuando el servidor tcp/udp publica más rápido de lo que consume el cliente?

Question

Estoy tratando de entender qué sucede cuando un servidor publica (a través de tcp, udp, etc.) más rápido de lo que un cliente puede consumir los datos.

Dentro de un programa entiendo que si una cola se ubica entre el productor y el consumidor, comenzará a agrandarse. Si no hay cola, el productor simplemente no podrá producir nada nuevo, hasta que el consumidor pueda consumir (sé que puede haber muchas más variaciones).

No tengo claro qué sucede cuando los datos abandonan el servidor (que puede ser un proceso, máquina o centro de datos diferente) y se envían al cliente. Si el cliente simplemente no puede responder a los datos entrantes lo suficientemente rápido, suponiendo que el servidor y el consumidor están muy poco vinculados, ¿qué ocurre con los datos en vuelo?

¿Dónde puedo leer para obtener más información sobre este tema? ¿Tengo que leer los detalles de bajo nivel de TCP/UDP?

Gracias

Answer 1

Con TCP hay un TCP Window que se utiliza para controlar el flujo. TCP solo permite que una determinada cantidad de datos permanezca sin acuse de recibo a la vez. Si un servidor está produciendo datos más rápido de lo que consume un cliente, la cantidad de datos no reconocidos aumentará hasta que la ventana TCP esté "llena" en este punto, la pila TCP emisora ​​esperará y no enviará más datos hasta que el cliente reconoce algunos de los datos que están pendientes.

Con UDP no hay tal sistema de control de flujo; es poco confiable después de todo. Las pilas UDP tanto en el cliente como en el servidor pueden dejar caer datagramas si les da la gana, al igual que todos los enrutadores entre ellos. Si envía más datagramas de los que el enlace puede entregar al cliente o si el enlace ofrece más datagramas de los que su código de cliente puede recibir, algunos de ellos serán desechados. El código del servidor y del cliente probablemente nunca lo sabrá a menos que haya creado alguna forma de protocolo confiable sobre UDP básico. Aunque en realidad puede encontrar que los datagramas NO son descartados por la pila de red y que los controladores de NIC simplemente mastican todo el grupo no paginado disponible y, finalmente, bloquean el sistema (consulte this blog posting for more details).

De vuelta con TCP, la forma en que el código del servidor se ocupa de que la ventana TCP esté llena depende de si está utilizando E/S de bloqueo, E/S sin bloqueo o E/S asíncronas.

• Si está utilizando bloqueo de E/S, sus llamadas de envío se bloquearán y su servidor se ralentizará; efectivamente su servidor ahora está en paso cerrado con su cliente. No puede enviar más datos hasta que el cliente haya recibido los datos pendientes.

• Si el servidor está utilizando E/S sin bloqueo, es probable que obtenga un error que le indica que la llamada se habría bloqueado; puede hacer otras cosas, pero su servidor deberá volver a enviar los datos en una fecha posterior ...

• Si está utilizando la E/S asíncrona, entonces las cosas pueden ser más complejas. Con la E/S asincrónica con puertos de finalización de E/S en Windows, por ejemplo, no notará nada diferente. Tus envíos superpuestos se aceptarán bien, pero es posible que notes que tardan más en completarse. Los envíos superpuestos se están poniendo en cola en la máquina del servidor y están utilizando la memoria para los búferes superpuestos y, probablemente, también usan el "grupo no paginado". Si sigue emitiendo envíos superpuestos, corre el riesgo de agotar la memoria de grupo no paginado o utilizar una cantidad potencialmente ilimitada de memoria como búferes de E/S. Por lo tanto, con E/S asíncronas y servidores que PODRÍAN generar datos más rápido de lo que sus clientes pueden consumir, debe escribir su propio código de control de flujo que maneje utilizando las terminaciones de sus escrituras. Escribí sobre este problema en mi blog here y here y mi marco de trabajo de servidor proporciona un código que lo trata automáticamente.

En cuanto a los datos 'en vuelo' se refiere a la pilas TCP en ambos pares se asegurará de que los datos lleguen a lo esperado (es decir, en el orden y con falta nada), que van a hacer esto mediante el reenvío de datos como y cuando se requiera.

Answer 2

El servidor no puede ser más rápido que el cliente durante mucho tiempo. Después de que ha sido más rápido que el cliente por un tiempo, el sistema en el que está alojado lo bloqueará cuando escriba en el socket (las escrituras pueden bloquear en un buffer completo de la misma forma que las lecturas pueden bloquear en un buffer vacío).

Answer 3

El TCP Wikipedia article muestra el formato del encabezado TCP, que es donde se guardan el tamaño de la ventana y el número de secuencia de acuse de recibo. El resto de los campos y la descripción allí deberían proporcionar una buena visión general de cómo funciona la regulación de la transmisión. RFC 793 especifica las operaciones básicas; las páginas 41 y 42 detallan el control de flujo.

Answer 4

TCP tiene una función llamada flow control.

Como parte del protocolo TCP, el cliente le dice al servidor la cantidad de datos que se pueden enviar sin llenar el búfer. Si el buffer se llena, el cliente le dice al servidor que aún no puede enviar más datos. Una vez que el buffer se vacía un poco, el cliente le dice al servidor que puede comenzar a enviar datos nuevamente. (Esto también se aplica a cuando el cliente envía datos al servidor).

UDP por otro lado es completamente diferente. El UDP en sí mismo no hace nada como esto y comenzará a eliminar datos si entra más rápido que el proceso. Depende de la aplicación agregar lógica al protocolo de la aplicación si no puede perder datos (es decir, si requiere una secuencia de datos 'confiable').

Answer 5

Si realmente quieres entender TCP, necesitas leer una implementación junto con el RFC; las implementaciones reales de TCP no son exactamente como se especifica. Por ejemplo, Linux tiene un concepto de "presión de memoria" que protege contra quedarse sin el núcleo (bastante pequeño) del núcleo de la memoria DMA, y también evita que un socket ejecute otros fuera del espacio del búfer.

Answer 6

Con TCP, esto no puede suceder.

En caso de UDP, los paquetes se perderán.