El polling se come 819 Mbps solo en cabeceras: la cuenta que empuja a WebSocket
Un analisis tecnico pone cifras al coste de simular tiempo real sobre peticion-respuesta y repasa la mecanica de tramas del RFC 6455.
El modelo peticion-respuesta sobre HTTP/1.1 no aguanta un sistema bidireccional en tiempo real. Ese es el punto de partida de un analisis tecnico que pone numeros al problema y detalla despues como WebSocket se libra de el. Los remedios clasicos son dos: el polling corto, con el cliente lanzando peticiones cada intervalo, y el long polling o Comet, donde el servidor mantiene la peticion abierta hasta que hay un cambio de estado o vence un timeout. Los dos siguen siendo semiduplex.
La cuenta de las cabeceras
Cada peticion HTTP/1.1 arrastra cabeceras redundantes -User-Agent, Cookie, Accept, las de CORS- que ocupan entre 500 bytes y 2 KB por trama. Con N clientes, f actualizaciones por segundo y H bytes de cabecera, el ancho de banda desperdiciado es N x f x H. Con 100.000 usuarios conectados, 1 Hz y 1.024 bytes de media, salen unos 102,4 MB/s, o lo que es lo mismo, cerca de 819,2 Mbps gastados en metadatos antes de mover un solo byte de payload.
Despues esta el coste en la capa L7. Cada peticion obliga a parsear cabeceras ASCII de longitud variable, cambiar de contexto entre los hilos del proxy y el kernel, y reservar memoria para objetos de vida corta que acaban empujando el recolector de basura. El long polling anade rotacion de conexiones: cada payload entregado cierra o deja ocioso el socket, y en rafaga eso se parece a un SYN flood, con el sobrecoste de handshake de TLS 1.3 y el agotamiento de puertos de origen en el balanceador, unos 65.535 por IP de salida.
Lo que hace WebSocket
WebSocket arranca como una peticion HTTP/1.1 normal con Upgrade: websocket y una clave Sec-WebSocket-Key. El servidor contesta 101 Switching Protocols con el Sec-WebSocket-Accept correspondiente y a partir de ahi el protocolo muta: TCP persistente, full-duplex, con tramas propias.
La cabecera de trama lleva un bit FIN, tres RSV, cuatro bits de opcode (0x1 texto, 0x2 binario, 0x8 cierre, 0x9 ping, 0xA pong), un bit MASK, la longitud del payload y, cuando toca, la clave de enmascarado de 32 bits. El enmascarado es obligatorio en cliente a servidor, y no es un capricho: evita ataques de envenenamiento de cache en middleboxes. El ciclo de vida pasa por CONNECTING, OPEN y los estados de cierre local y remoto.
Una advertencia sobre el material: pese al titulo, el texto se corta antes de entrar en SSE y gRPC-Web, asi que la comparacion que promete no llega a entregarse.
El objetivo declarado es bajar de 10 ms de latencia entre clientes distribuidos, y para eso hay que abandonar el ciclo sin estado. Lo que no aparece en el analisis es la otra mitad de la factura: operar esas conexiones largas supone estado en el balanceador, reconexion con backoff y despliegues que obligan a drenar miles de sockets abiertos sin cortar a nadie.
