Un experimento en Android sugiere que SO_RCVBUF no refleja el control de flujo TCP real
Medir el búfer de recepción con getsockopt no dice cuánto puede enviar el emisor: 16 MiB transferidos tardan lo mismo y llegan idénticos con y sin el ajuste.
Un usuario de r/networking ha publicado las primeras medidas de un experimento sobre control de flujo TCP en el lado receptor de un Android de serie. La conclusión inmediata es que leer SO_RCVBUF con getsockopt no sirve para saber cuánto se le está permitiendo enviar realmente al par.
En la primera tanda, el socket arranca con un readback de 4 MiB. Al pedir 64 KiB, el sistema devuelve 128 KiB. Con una transferencia de 16 MiB, la referencia por defecto tarda 4,187 segundos y la modificada 4,201. El SHA-256 del archivo recibido es idéntico en los dos casos. Mover el búfer de recepción no cambió ni el tiempo ni el contenido, que es justo lo que el autor quería comprobar: el número que devuelve el socket no establece el control de flujo efectivo.
Lo que falta por medir
El planteamiento sigue abierto. El siguiente paso es capturar desde el SYN y comparar cómo se negocia el factor de escala de ventana, cómo evolucionan la ventana anunciada y su borde derecho, cómo responde el rendimiento y cuánto tarda en recuperarse de una ventana cero. Solo con esa traza se puede hablar de lo que al emisor se le permite enviar.
La hipótesis de fondo la conoce quien haya peleado con esto: el autotuning del kernel Linux ajusta el búfer sobre la marcha, así que getsockopt(SO_RCVBUF) acaba siendo un mal proxy del valor real. En un Android de serie, con su propia pila y sus propios límites, el margen para fijarlo a mano es todavía más estrecho.
El hilo está en fase de petición de ayuda. El autor pregunta si alguien ha hecho pruebas equivalentes en el lado receptor y ha medido la ventana anunciada en lugar de conformarse con el readback. Es una pregunta razonable y con pocas respuestas publicadas: la mayor parte del material sobre ajuste de TCP se centra en el emisor, en el control de congestión y en el tamaño de la ventana de envío.
Para quien administra servidores que hablan con clientes móviles, el interés está en la asimetría. Del lado del servidor se puede medir, ajustar y monitorizar; del lado del cliente Android no hay acceso a la traza ni al kernel. Si la ventana anunciada depende de un autotuning opaco, cualquier cálculo de capacidad por cliente que se apoye en la configuración del socket se queda en una estimación.
Falta la segunda tanda de capturas, y con lo publicado no se puede concluir más que esto: en esta prueba concreta, tocar SO_RCVBUF no cambió ni el tiempo ni el resultado, y el valor leído no cuadra con el solicitado. Es un dato pequeño, de un solo dispositivo y sin traza de red todavía.
