Códecs HTTP/2 en Envoy: por qué oghttp2 rinde peor que nghttp2

Una actualización rutinaria de Envoy en entornos de producción elevó el uso de CPU cerca de un 20% tras migrar el códec HTTP/2 por defecto de nghttp2 a oghttp2, el códec en C++ de Google heredado de la pila QUICHE. Las pruebas, reproducidas en Intel Sapphire Rapids, AMD Zen 4, AWS Graviton4 y Google Axion, confirman regresiones de entre el 15% y el 25% en RPS por núcleo para tráfico proxied con cabeceras densas, y del 7% al 19% bajo churn de conexiones. La causa principal no está en el decodificador Huffman de QUICHE, ya de por sí más lento, sino en las capas superiores: HttpHeaderBlock y los mecanismos de representación que dominan los flamegraphs. El artículo repasa cómo funciona la compresión HPACK (RFC 7541), con su tabla estática de 61 entradas y su tabla dinámica sincronizada, y por qué la decodificación Huffman —núcleo caliente en cada proxy de edge— se lleva la mayor parte del tiempo. Frente al decodificador bit a bit de oghttp2, nghttp2 emplea desde 2014 una máquina de estados finitos precalculada (256 estados × 16 nibbles, 16 KiB en L1), que recorre varios bits por consulta y reduce ramas y cargas dependientes. La versión v1.37.0 de Envoy ya revirtió la opción por defecto a nghttp2, pero el texto deja abierta la puerta a una segunda parte con optimizaciones para acelerar el códec rápido todavía más.