HTTP/1.1, HTTP/2 y HTTP/3

radio_button_unchecked Presentación del capítulo

HTTP a menudo se presenta a través de breves ejemplos GET y POST , pero esta vista es insuficiente para quienes operan puertas de enlace empresariales. En producción, HTTP es un protocolo con su propia semántica, estrictas reglas de delimitación, mecanismos de negociación, caché, condiciones, intermediarios y diferentes mapeos de transporte. Una llamada que parece ser una solicitud única se puede recibir en HTTP/3 en el borde, convertirse a HTTP /2 hasta la puerta de enlace y reenviarse en HTTP /1.1 al backend . Cada salto tiene su propia conexión, estado, timeout , compresión de campo y riesgo operativo.

Las versiones HTTP /1.1, HTTP /2 y HTTP/3 no representan tres API diferentes. Comparten métodos, códigos de estado, campos y conceptos de representación definidos por la semántica HTTP , pero codifican y transportan estos elementos de diferentes maneras. HTTP /1.1 utiliza una sintaxis textual sobre una secuencia TCP ; HTTP /2 introduce tramas binarias y flujos multiplexados a través de una conexión; HTTP/3 lleva la semántica HTTP a QUIC , que funciona sobre UDP e integra TLS 1.3 en el transporte.

Para un ingeniero de API Gateway , la distinción entre semántica y control de versiones por cable es fundamental. Un error 405 no es consecuencia de TCP o QUIC ; indica que el método no está permitido por el recurso. Un timeout HTTP sin respuesta apunta a otra capa. Es posible que la puerta de enlace haya generado un 502 después de una conexión fallida con el canal ascendente. El comportamiento intermitente en HTTP /2 puede implicar límites de flujo, ventana de flujo, drenaje o una traducción inapropiada a HTTP /1.1 en el siguiente salto.

Este capítulo construye un modelo mental completo: primero establece la semántica común, luego profundiza en el formato y las conexiones de HTTP /1.1, luego explica la arquitectura de frame y flujo de HTTP /2 y finalmente presenta QUIC y HTTP/3 . El objetivo no es memorizar listas, sino comprender qué propiedades permanecen estables, cuáles cambian entre versiones y qué evidencia se debe recopilar en cada punto de una arquitectura empresarial.

Principio central

La semántica HTTP pertenece a la operación; la versión HTTP y la conexión pertenecen a cada salto. Un proxy finaliza un mensaje, aplica reglas y crea un mensaje nuevo para el siguiente destino.

Objetivos de aprendizaje

• Explicar la arquitectura semántica de HTTP y separar el significado, la representación y el mapeo de transporte.
• Interprete el método, el objetivo de la solicitud, la autoridad , los campos, el contenido , los avances y los códigos de estado.
• Distinguir seguridad, idempotencia y capacidad de caché de los métodos principales.
• Diseñe el almacenamiento en caché y la revalidación mediante Cache -Control, Age, ETag , Last-Modified y solicitudes condicionales.
• Interprete la sintaxis HTTP /1.1, incluidos CRLF, longitud de contenido , codificación de transferencia y mensajes sin contenido .
• Comprenda las conexiones persistentes, la canalización, el mantenimiento de actividad, los tiempos de espera y el bloqueo de cabecera de línea .
• Reconozca los riesgos de análisis divergente, request smuggling, división de respuestas y campos salto por salto.
• Explicar tramas, flujos, multiplexación , control de flujo , GOAWAY y HPACK en HTTP /2.
• Comprenda ALPN , h2, h2c, fusión de conexiones y límites de concurrencia.
• Explique QUIC , integración de TLS 1.3, Connection IDs , migración, pérdida y transmisiones independientes.
• Comprenda tramas HTTP/3 , flujos de control, QPACK , Alt-Svc y descubrimiento de HTTPS /SVCB.
• Compare HTTP /1.1, HTTP /2 y HTTP/3 en cuanto a latencia, observabilidad, seguridad y funcionamiento.
• Aplicar los conceptos a Axway API Gateway , Azure API Management y arquitecturas con múltiples proxies .
• Diagnostica fallas a través de seguimientos, encabezados, registros, métricas de conexión y capturas de tráfico.

Estructura del capítulo

radio_button_uncheckedHTTP : protocolo de aplicación y arquitectura semántica

RFC 9110 define HTTP como un protocolo de aplicación sin estado para sistemas distribuidos y establece conceptos comunes a todas las versiones. "Sin estado" no significa que las aplicaciones no puedan mantener la sesión o el estado comercial. Significa que el protocolo no requiere que el servidor preserve, entre solicitudes independientes, el contexto necesario para interpretar el siguiente mensaje. El estado se puede representar en recursos, bases de datos, cookies , tokens , cachés o sesiones, pero cada solicitud debe contener suficiente información para ser procesada según el contrato.

La unidad semántica principal es un mensaje de solicitud o respuesta. Una solicitud expresa un método aplicado a un objetivo, acompañado de campos y, opcionalmente, contenido . Una respuesta comunica el resultado a través de un código de estado, campos y posible contenido . HTTP no determina que el contenido sea JSON ni que la API sea REST . El protocolo puede transportar HTML , imágenes, XML , Protobuf, archivos, eventos y otros formatos registrados o acordados entre las partes.

La semántica también define propiedades que guían a los intermediarios. Los cachés necesitan saber cuándo se puede reutilizar una respuesta; los servidores proxy deben diferenciar los campos destinados al siguiente salto de los metadatos de un extremo a otro; los clientes deben decidir cuándo se puede repetir una operación después de un fallo; Las puertas de enlace deben preservar la autoridad , el método y el contenido sin crear ambigüedad. Estas propiedades son más importantes para la interoperabilidad que la apariencia textual que se ve en un ejemplo de HTTP /1.1.

Lectura para puertas de enlace

Cuando una puerta de enlace recibe HTTP /2 y llama a un backend en HTTP /1.1, no "reenvía fotogramas". Decodifica un mensaje, ejecuta políticas y genera otro mensaje compatible con el siguiente protocolo.

radio_button_unchecked Evolución: de los mensajes mínimos al transporte multiplexado

HTTP /0.9 tenía una forma extremadamente simple: una solicitud GET seguida de la ruta y una respuesta compuesta por el documento. No hubo códigos de estado, campos, negociación de tipos ni conexión persistente. Esta simplicidad se adaptaba a los primeros documentos web, pero no ofrecía mecanismos adecuados para aplicaciones distribuidas complejas. HTTP /1.0 introdujo versiones de línea iniciales, códigos de estado, campos y tipos de medios, lo que le permite representar metadatos y contenido diferente.

HTTP /1.1 consolidó conexiones persistentes de forma predeterminada, el campo Host, almacenamiento en caché más completo, solicitudes condicionales, transferencias fragmentadas y reglas de framing . El protocolo ahora admite múltiples sitios en la misma dirección IP y reduce el costo de abrir una conexión por objeto. Aun así, la dependencia de un flujo TCP ordenado y un formato secuencial ha creado límites para páginas y API con muchas operaciones simultáneas.

HTTP /2 conservó la semántica y reemplazó el formato de mensaje de texto con frames binarios asociados con transmisiones. Esto nos permitió intercalar múltiples intercambios en la misma conexión y comprimir campos repetitivos con HPACK . HTTP/3 mantuvo el modelo de flujos y frames, pero reemplazó TCP con QUIC . Por lo tanto, la pérdida en un flujo no necesariamente impide la entrega de datos disponibles de otros flujos, y el protocolo de enlace criptográfico se convierte en parte del establecimiento de transporte.

Compatibilidad semántica

Un método GET sigue siendo GET en HTTP /1.1, HTTP /2 y HTTP/3 . Lo que cambia es cómo se representan y transportan el método, el objetivo, los campos y el contenido .

radio_button_unchecked Modelo de transacción: solicitud, respuesta y mensajes autodescriptivos.

Una transacción HTTP comienza cuando un cliente envía una solicitud a un servidor de origen o intermediario. La solicitud contiene información de control y metadatos que le permiten determinar el recurso, la operación y la forma de respuesta esperada. El servidor produce una o más respuestas informativas y una respuesta final. En HTTP /1.1, los elementos aparecen como líneas y campos; en HTTP /2 y HTTP/3 , se convierten en pseudocampos y frames.

El contenido de un mensaje es conceptualmente diferente de su representación en el cable. Campos como Content-Type y Content-Encoding describen la representación . El framing le indica cómo ubicar el contenido dentro de la conexión. En HTTP /1.1, Content-Length o fragmentado pueden delimitar el cuerpo; En HTTP /2 y HTTP/3 , el contenido se carga en frames de DATOS y el final de la transmisión indica su finalización. Confundir metadatos de representación con frames produce errores y vulnerabilidades de interoperabilidad.

Los avances son campos enviados después del contenido . Pueden transportar metadatos calculados al final de la transmisión, como la integridad o el estado de los protocolos creados en HTTP . No todos los intermediarios conservan los remolques y el contrato debe considerar esta posibilidad. En las puertas de enlace, convertir la transmisión en búfer completo puede cambiar la latencia, la memoria consumida y la capacidad de entregar avances al cliente.

POST /v1/payments HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Content-Length: 42
{"amount":100.00,"currency":"BRL"}

radio_button_unchecked Identificadores, URI , autoridad y destino de la solicitud

Un URI identifica un recurso o referencia utilizada en la interacción. En el uso común de API , el URI incluye esquema, autoridad , ruta y consulta. En ` https :// api .example.com:443/v1/accounts/123? view=summary`, el esquema es HTTPS , la autoridad contiene host y puerto, la ruta identifica una jerarquía lógica y la consulta agrega parámetros. El fragmento, cuando está presente en un URI , lo procesa el cliente y no se envía en la solicitud HTTP .

HTTP /1.1 utiliza diferentes formas de solicitud-objetivo según el método y el tipo de intermediario. El formulario de origen envía ruta y consulta; la forma absoluta es típica en proxies directos; CONNECT utiliza el formulario de autoridad ; y la forma de asterisco aparece en OPCIONES `*`. El campo Host es obligatorio en HTTP /1.1 e informa a la autoridad prevista. En HTTP /2 y HTTP/3 , pseudocampos como `:scheme`, `:authority`, `:path` y `:method` representan estos componentes.

Las puertas de enlace deben tratar a la autoridad con cuidado porque participa en el enrutamiento, la selección de certificados, las políticas y la protección contra ataques al encabezado del host. Un proxy puede recibir una dirección pública y llamar a un host interno diferente; Esto no autoriza a sustituir indiscriminadamente el significado de la autoridad original. En algunas arquitecturas, el backend necesita conocer el host externo a través de campos "reenviados" o equivalentes, pero estos campos solo deben ser confiables cuando los ingresan intermediarios controlados.

radio_button_unchecked Métodos: intención, seguridad semántica e idempotencia .

El método expresa la intención de la solicitud. GET solicita la transferencia de una representación ; HEAD solicita los mismos metadatos sin contenido de respuesta; POST pide al recurso que procese el contenido según su semántica; PUT reemplaza o crea estado en el URI de destino; DELETE solicita la eliminación de la asociación actual; OPCIONES describe las opciones de comunicación; CONNECT establece un túnel; TRACE ejecuta un diagnóstico de bucle invertido y normalmente está deshabilitado en entornos corporativos.

Un método seguro se define como esencialmente de sólo lectura: el cliente no solicita un cambio en el estado del servidor. Esto no impide los registros, las métricas o la facturación operativa, pero sí significa que el efecto deseado no es un cambio empresarial. Idempotencia significa que repetir la misma intención varias veces debería producir el mismo efecto deseado que una sola ejecución. PUT y DELETE son semánticamente idempotentes, aunque las respuestas observables y los efectos secundarios pueden variar .

La distinción es decisiva para los retries . Una puerta de enlace puede repetir una solicitud GET después de un fallo de conexión con menos riesgo semántico. Volver a intentar la POST de pago puede duplicar la operación si el backend procesó el contenido antes de que se perdiera la respuesta. Las API financieras a menudo introducen una clave de idempotencia de la aplicación, manteniendo el resultado asociado con una clave única. Esta estrategia complementa, pero no cambia, la semántica del método HTTP .

Reintentar no es sólo una decisión técnica

Antes de configurar los retries en la puerta de enlace, clasifique la operación, determine el punto en el que el flujo ascendente puede haber tenido efecto y defina cómo se detectarán los duplicados.

radio_button_unchecked Códigos de estado y autoría de respuesta

El código de estado describe el resultado del intento de interpretar y satisfacer la solicitud. Las respuestas 1xx son informativas; 2xx indica éxito; 3xx aconseja la redirección o el uso de otra representación ; 4xx indican que la solicitud no puede atenderse en las condiciones presentadas; 5xx informe del servidor o fallo del intermediario. La clase es relevante, pero el código específico y los campos asociados proporcionan la semántica completa.

En arquitecturas con proxies , el código final puede ser creado por cualquier intermediario. Un 401 puede provenir de una política de autenticación de puerta de enlace sin que se llame al backend . Un 429 puede representar el límite de velocidad del borde. Un 502 normalmente indica que una puerta de enlace no obtuvo una respuesta válida desde el nivel ascendente; un 504 representa el timeout que actúa como puerta de enlace. Los registros deben registrar la autoría, la etapa de la política y el estado ascendente por separado.

Las frases de motivo HTTP /1.1 son informativas y no deben controlar la lógica. HTTP /2 y HTTP/3 llevan el código en `:status` y no llevan la frase de motivo. Los clientes deben tomar decisiones basándose en el número y los campos, no en textos como "OK" o "No autorizado". En las API , las respuestas de error pueden agregar un formato de problema, correlación y detalles, pero el cuerpo no reemplaza la semántica de estado.

radio_button_unchecked Campos HTTP : metadatos, alcance y normalización

Los campos HTTP son pares nombre-valor extensibles. Llevan información sobre control, representación , almacenamiento en caché, autenticación, negociación e intermediarios. Los nombres no distinguen entre mayúsculas y minúsculas, aunque los valores pueden tener reglas específicas. Un campo puede permitir una sola aparición, varias ocurrencias o una lista que se puede componer. Las implementaciones no deben concatenar campos indiscriminadamente, especialmente `Set- Cookie `, cuya semántica requiere un tratamiento específico.

RFC 9110 distingue los campos de un extremo a otro de la información relacionada con la conexión. HTTP /1.1 utiliza el campo Conexión para declarar nombres de campos que se aplican solo al siguiente salto. Los intermediarios deben eliminar estos campos antes de reenviar. HTTP /2 y HTTP/3 prohíben varios campos específicos de la conexión, ya que los flujos y los frames reemplazan mecanismos como `Transfer-Encoding: fragmentado`. Replicar encabezados HTTP /1.1 sin comprender su alcance puede provocar fallas en el protocolo.

La normalización es necesaria pero peligrosa. Las puertas de enlace pueden cambiar las mayúsculas, el orden, combinar líneas, eliminar espacios opcionales o reconstruir mensajes. Las solicitudes no deben depender del orden de los campos. Por otro lado, las firmas HTTP y los esquemas de autenticación pueden definir una canonicalización explícita. Se debe ejecutar una política de puerta de enlace que modifique los valores firmados antes de firmar o preservar exactamente los componentes cubiertos.

radio_button_unchecked Representaciones, tipos de medios y negociación de contenidos .

Un recurso es una abstracción; la representación es una secuencia de bytes y metadatos que describe un estado de ese recurso. El mismo recurso se puede representar como JSON , XML , CSV o imagen. `Content-Type` informa el tipo de medio de la representación enviada, mientras que `Accept` expresa qué tipos el cliente considera aceptables. Enviar JSON sin `Content-Type: application/ json ` obliga al receptor a inferir o rechazar el contenido .

La negociación de contenido puede ocurrir de manera proactiva, utilizando los campos Aceptar, Aceptar-Codificación y Aceptar-Idioma, o reactivamente, cuando el servidor ofrece alternativas. El campo Variar informa qué dimensiones de la solicitud influyeron en la selección de la respuesta y es esencial para las cachés. Si una respuesta varía según "Aceptar-Codificación", un caché no debe entregar bytes comprimidos con gzip a un cliente que no los acepta.

Content-Encoding describe transformaciones aplicadas a la representación , como gzip o br. No debe confundirse con Transfer-Encoding, que en HTTP /1.1 participa en el framing de mensajes. Las puertas de enlace que descomprimen contenido para su inspección deben decidir si recomprimir, corregir la Content-Length, preservar ETag cuando sea semánticamente válido y considerar límites de expansión para evitar ataques de descompresión.

GET /reports/2026 HTTP/1.1
Host: api.example.com
Accept: application/json, application/xml;q=0.8
Accept-Encoding: br, gzip
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Vary: Accept, Accept-Encoding

radio_button_unchecked Caché HTTP : frescura, reutilización e invalidación

El almacenamiento en caché HTTP no es sólo una optimización del navegador. Las CDN , los proxies inversos y las puertas de enlace pueden almacenar respuestas y atender solicitudes sin llamar al backend . RFC 9111 define cuándo una respuesta puede almacenarse, considerarse nueva, reutilizarse o revalidarse. Cache -Control incluye directivas como max-age, no- cache , no-store, private, public y must-revalidate. "no- cache " no significa "no almacenar"; significa que la respuesta debe validarse antes de su reutilización, excepto para reglas específicas.

La antigüedad de una respuesta considera el tiempo desde su generación y permanencia en cachés. El campo Edad informa la edad estimada. Las cachés compartidas deben respetar las políticas de autorización y privacidad. En las API bancarias, almacenar respuestas personalizadas sin la clave de caché adecuada puede provocar fugas entre usuarios. La clave normalmente incluye URI y dimensiones indicadas por Vary, pero las puertas de enlace pueden agregar reglas específicas según la identidad, el inquilino o el producto.

Invalidar la caché es difícil porque pueden existir copias en varios niveles. Las estrategias incluyen TTL corto, control de versiones de URI , depuración explícita y revalidación. La elección debe equilibrar la coherencia, el coste y la disponibilidad. Un backend no disponible puede protegerse mediante respuestas almacenadas, pero servir información antigua en operaciones financieras puede ser inaceptable. La política de caché es una decisión de dominio, no sólo de rendimiento.

radio_button_unchecked Solicitudes condicionales y control de concurrencia

Las solicitudes condicionales le permiten realizar una operación solo si el estado del recurso satisface una condición. `If-None-Match` se utiliza para revalidar el caché o garantizar la creación solo cuando no existe ninguna representación actual. `If-Match` requiere que la entidad actual coincida con una ETag y es útil para evitar la pérdida de actualizaciones. Los campos basados ​​en fechas, como If-Modified-Since y If-Unmodified-Since, tienen menor granularidad y confiabilidad que los validadores opacos.

ETag es un identificador de la representación seleccionada. Una ETag fuerte indica equivalencia byte a byte adecuada para operaciones como rangos; uno débil indica suficiente equivalencia semántica para ciertos usos de la caché. No es necesario que sea un hash criptográfico ni que revele una versión interna. Las puertas de enlace que transforman el contenido pueden invalidar la ETag del backend , porque la representación entregada al cliente ya no es la misma.

En control optimista, el cliente lee una representación con ETag , la cambia localmente y envía PUT o PATCH con If-Match. Si otro actor modificó el recurso, el servidor responde 412 Precondición fallida. Esto evita sobrescribir silenciosamente una actualización simultánea. La política debe implementarse en el componente que controla el estado del negocio; una puerta de enlace puede validar la presencia y el formato, pero no conoce la versión actual del recurso por sí sola.

GET /accounts/123
<- ETag: "v17"
PATCH /accounts/123
If-Match: "v17"
Content-Type: application/merge-patch+json
{"nickname":"Reserva"}
<- 204 No Content   o   412 Precondition Failed

radio_button_uncheckedHTTP /1.1: sintaxis textual y flujo de bytes

HTTP /1.1 representa los mensajes como una línea de inicio, una secuencia de campos, una línea vacía y contenido opcional. Las líneas están delimitadas por CRLF. Una solicitud comienza con método, destino de solicitud y versión; una respuesta comienza con la versión y el estado. Aunque las herramientas muestran mensajes en un formato legible, la implementación debe manejar octetos, límites, espacios y caracteres prohibidos de acuerdo con la especificación. La excesiva tolerancia hacia los mensajes no válidos es una fuente recurrente de inconsistencia entre intermediarios.

El receptor necesita determinar dónde termina cada mensaje en una conexión persistente. TCP entrega un flujo de mensajes sin límites: un `recv()` puede devolver parte de una línea, varias líneas o datos de mensajes consecutivos. El analizador HTTP acumula bytes, reconoce la sección del campo y aplica reglas de framing . La conexión no puede simplemente utilizar el " fin del paquete" como límite, ya que los paquetes IP y los segmentos TCP son detalles inferiores que se pueden dividir o combinar.

En las API , existen límites de tamaño para la fila inicial, los campos y el contenido en todos los clientes, WAF , puertas de enlace y servidores. La puerta de enlace puede rechazar un campo aceptado por el borde; una carga útil permitida por la puerta de enlace puede exceder el backend . Es necesario coordinar los ajustes. Los errores 400, 413, 414 y 431 ayudan a diferenciar entre solicitudes con formato incorrecto, contenido extenso, URI largos y campos excesivos.

HTTP-message = start-line CRLF
               *( field-line CRLF )
               CRLF
               [ message-body ]

radio_button_uncheckedFraming en HTTP /1.1: Content-Length, chunked y ausencia de cuerpo

Content-Length informa la Content-Length en octetos. Cuando es válido, el receptor lee exactamente esa cantidad después de la línea vacía. `Transfer-Encoding: fragmentado` codifica el contenido en bloques, cada uno precedido por un tamaño hexadecimal y terminando con un fragmento cero y avances opcionales. Chunked le permite transmitir sin conocer el tamaño total de antemano, pero es un mecanismo salto por salto y no aparece en HTTP /2 o HTTP/3 .

No todas las respuestas tienen cuerpo. Las respuestas a HEAD no incluyen contenido , aunque los campos describen lo que habría devuelto un GET . Los códigos 1xx, 204 y 304 tienen reglas específicas sin contenido . Las respuestas exitosas a CONNECT cambian la conexión al modo túnel. En otros casos, cerrar la conexión puede limitar la respuesta, pero esto impide la reutilización y es menos sólida.

Múltiples longitudes de contenido con valores diferentes, una combinación incorrecta de longitud de contenido y codificación de transferencia o una sintaxis fragmentada no válida deben tratarse como un error. Si un proxy y un backend eligen reglas diferentes, es posible que no estén de acuerdo sobre dónde termina la solicitud. El resultado puede variar desde la corrupción de la conexión hasta el request smuggling. La estrategia segura es un análisis estricto y una normalización consistente antes del reenvío.

radio_button_unchecked Conexiones persistentes, reutilización, pooling y tiempos de espera

HTTP /1.1 utiliza conexiones persistentes de forma predeterminada. Después de una respuesta, el cliente y el servidor pueden reutilizar TCP / TLS para nuevas solicitudes, lo que reduce los protocolos de enlace y la latencia. La reutilización sólo es segura cuando el mensaje anterior ha sido completamente delimitado y consumido. Si un cliente abandona un cuerpo sin leerlo, la conexión puede desalinearse para la siguiente transacción.

Las puertas de enlace mantienen grupos de conexiones para los servidores. El grupo separa la conexión del cliente de la conexión ascendente: cientos de clientes pueden compartir un grupo de conexiones persistentes, según la competencia y la capacidad. Los parámetros relevantes incluyen el máximo por objetivo, el tiempo de inactividad, la vida útil, el timeout de conexión, el timeout de lectura y la validación antes de la reutilización. Un equilibrador de carga puede finalizar conexiones inactivas antes de la puerta de enlace, provocando reinicios al reutilizar sockets aparentemente válidos.

Los tiempos de espera deben formar un presupuesto coherente. El cliente tiene que esperar más tiempo que el borde; el borde, más que la puerta de entrada; la puerta de enlace, tiempo suficiente para el backend , pero menos que el límite total del consumidor. Si todos usan el mismo valor, los componentes pueden caducar simultáneamente y producir tormentas de retries . Los registros deben distinguir el tiempo de conexión, el envío, la espera del primer byte y la lectura del contenido .

radio_button_uncheckedPipelining y bloqueo head -of-line en HTTP /1.1

La canalización le permite enviar múltiples solicitudes a través de una conexión sin esperar cada respuesta. Sin embargo, las respuestas deben emitirse en el mismo orden. Si la primera solicitud lleva tiempo, las respuestas listas de solicitudes posteriores se retrasan. Este bloqueo se conoce como encabezado de línea en el nivel HTTP /1.1. La complejidad de los retries , los servidores intermediarios y las implementaciones inconsistentes han limitado la adopción práctica de la canalización.

Los clientes a menudo han solucionado el problema abriendo múltiples conexiones paralelas por fuente. Esto aumenta los apretones de manos, el uso de puertos, la congestión de las colas y la presión sobre los equilibradores. Para las API , varias conexiones pueden distribuir la carga de manera diferente a una conexión HTTP /2 con muchas transmisiones. Las métricas basadas únicamente en "conexiones activas" no representan correctamente la competencia cuando las versiones coexisten.

HTTP /2 fue diseñado para multiplexar solicitudes independientes sin imponer un orden global de respuestas. Aun así, todas las tramas viajan a través de un flujo TCP , por lo que una pérdida de segmento puede retrasar la entrega de bytes posteriores de todos los flujos. HTTP/3 traslada el aislamiento de flujo al transporte QUIC .

radio_button_unchecked Intermediarios, campos salto a salto y transformación

El proxy es un participante HTTP que recibe un mensaje y reenvía otro. Puede seleccionar el siguiente destino, aplicar autenticación, transformar contenido , almacenar en caché o registrar telemetría. Una puerta de enlace actúa como intermediario con políticas basadas en API . No es necesario que el mensaje de salida sea byte por byte igual que la entrada, pero debe preservar la semántica definida y cumplir con los requisitos de seguridad.

Los campos salto a salto pertenecen a una única conexión y no deben reenviarse automáticamente. En HTTP /1.1, Connection declara opciones aplicables al salto; TE tiene uso restringido; Transfer-Encoding y Upgrade describen la conexión actual. HTTP /2 y HTTP/3 eliminan o reemplazan estos conceptos. Una puerta de enlace traduce el framing y no debe enviar "Transfer-Encoding: fragmentada" en una secuencia HTTP /2.

Las transformaciones pueden cambiar la Content-Length, la codificación del contenido , la etiqueta ET , la firma, la capacidad de caché y la transmisión. Una política que convierte XML a JSON necesita definir un nuevo tipo de contenido y recalcular la longitud. Si la puerta de enlace almacena en búfer para validar el esquema, la primera respuesta puede ser más lenta y el consumo de memoria puede aumentar con las cargas útiles. La arquitectura debe documentar qué transformaciones están permitidas y en qué salto.

Regla de funcionamiento

Capture el mensaje lógico antes y después de cada política relevante. Comparar solo los paquetes perimetrales con los registros de backend ignora las transformaciones introducidas en el camino.

radio_button_unchecked Parsing divergente y seguridad de mensajes HTTP /1.1

El request smuggling ocurre cuando dos participantes interpretan los límites de los mensajes de manera diferente. Un atacante envía una cadena ambigua; el primer proxy considera una parte como un cuerpo, mientras que el segundo interpreta los bytes restantes como una nueva solicitud. Esto puede eludir controles, envenenar el caché, mezclar respuestas entre usuarios o tomar rutas imprevistas. Las variaciones clásicas explotan los conflictos entre Content-Length y Transfer-Encoding, pero el problema general es el desacuerdo en el análisis.

La división de respuestas explora la inserción de delimitadores de línea en valores que terminan incrustados en los encabezados, creando campos o respuestas adicionales. Las implementaciones deben rechazar CR y LF no permitidos. La normalización inconsistente de espacios, nombres y caracteres también puede crear discrepancias. El principio es aceptar sólo sintaxis válida, rechazar ambigüedades y evitar reenviar mensajes parcialmente interpretados.

HTTP /2 y HTTP/3 tienen frames binarios, pero pueden participar en ataques cuando un intermediario convierte mensajes a HTTP /1.1 de forma insegura. Una solicitud H2 puede contener metadatos que, cuando se serializan, crean ambigüedades en el backend H1. Por lo tanto, la seguridad requiere validación en el punto de traducción, no sólo en el borde. Las actualizaciones recientes de especificaciones también refinan los requisitos de actualización y los datos anticipados; Los operadores deben realizar un seguimiento de las erratas y RFC que actualizan el comportamiento.

Defensa en profundidad

Utilice analizadores conformes, elimine combinaciones ambiguas, normalice una vez, mantenga actualizados el frontend y el backend y pruebe explícitamente las traducciones H2/H3 a H1.

radio_button_uncheckedHTTP /2: capa de framing binario

HTTP /2 es una expresión optimizada de la semántica HTTP . Una vez establecida la conexión, los participantes intercambian tramas binarias con un encabezado fijo que informa la longitud, el tipo, las banderas y el ID de la transmisión. Los frames HEADERS contienen bloques de campos comprimidos; LOS DATOS transportan contenido ; AJUSTES negocia parámetros; WINDOW_UPDATE controla el flujo; RST_STREAM finaliza una transmisión; GOAWAY inicia la terminación coordinada de la conexión.

Un mensaje HTTP se asigna a una secuencia de fotogramas en una secuencia. La corriente tiene un identificador y un ciclo de vida independientes. La solicitud y la respuesta de una operación utilizan la misma secuencia. Se pueden entrelazar tramas de diferentes flujos, lo que permite la concurrencia sin abrir una conexión TCP para cada llamada. El receptor reconstruye cada mensaje utilizando el ID de transmisión y indicadores como END_HEADERS y END_STREAM.

El protocolo comienza con un prefacio de conexión y un intercambio de AJUSTES. Los parámetros incluyen el tamaño de la tabla de campos, el número máximo de transmisiones simultáneas, el tamaño de la ventana inicial y el tamaño máximo del frame. Es necesario confirmar la CONFIGURACIÓN. La configuración es direccional: lo que anuncia un punto final limita el comportamiento del par cuando le envía.

radio_button_uncheckedStreams , estados y cierre

Las transmisiones pueden estar inactivas, abiertas, medio cerradas, reservadas o cerradas, según las tramas enviadas y recibidas. END_STREAM cierra la dirección del remitente y permite que continúe la otra dirección. RST_STREAM finaliza inmediatamente la transmisión e informa un código de error. Los errores de transmisión no tienen por qué interrumpir toda la conexión; Los errores de conexión requieren GOAWAY y apagado.

GOAWAY contiene el ID de transmisión más grande que puede haberse procesado y un código de error. El par no debe crear nuevos flujos en la conexión y puede repetir operaciones de flujo por encima del límite, considerando la idempotencia . En implementaciones y drenajes, las puertas de enlace deben emitir GOAWAY y permitir la finalización de los flujos aceptados. La terminación abrupta de TCP convierte el mantenimiento planificado en fallas de red indistinguibles.

La cantidad de transmisiones en competencia está limitada por SETTINGS_MAX_CONCURRENT_STREAMS y los recursos locales. Un cliente puede mantener una conexión, pero ser bloqueado esperando que el crédito abra una nueva transmisión. Las métricas deben mostrar transmisiones activas, pendientes y rechazadas, no solo conexiones. Un solo cliente con HTTP /2 puede generar una alta competencia por una conexión.

radio_button_uncheckedMultiplexación , control de flujo y presión de memoria.

La multiplexación permite entrelazar tramas, pero no elimina la necesidad de contrapresión. HTTP /2 aplica control de flujo a DATOS a nivel de conexión y flujo. El receptor anuncia crédito; a medida que consume bytes, envía WINDOW_UPDATE. Si la aplicación no lee una secuencia, su ventana puede restablecerse. Si la ventana de conexión se restablece, se impide que todas las transmisiones envíen DATOS, incluso si algunos consumidores son rápidos.

El control de flujo no es lo mismo que el control de congestión TCP . El primero protege los buffers del receptor y de la aplicación; el segundo adapta el envío a la capacidad de la red. Ambos actúan simultáneamente. El aumento de las ventanas puede mejorar el rendimiento en rutas de productos con un alto retardo de ancho de banda, pero aumenta la memoria potencial. Las puertas de enlace deben limitar las transmisiones, los frames, los campos y el contenido para evitar que unos pocos clientes monopolicen los recursos.

El HTTP /2 original tenía un mecanismo de dependencia y ponderación de prioridades que resultó difícil de implementar de manera interoperable. La especificación actual elimina el antiguo modelo central y permite un esquema extensible. Los operadores no deben asumir que la prioridad del cliente se respetará de extremo a extremo, especialmente cuando hay servidores proxy que reordenan o convierten protocolos.

Síntoma clásico

Una conexión TCP en buen estado, un ping HTTP /2 que responde y algunas transmisiones detenidas pueden indicar una ventana de flujo agotada o una aplicación que ha dejado de consumir contenido .

radio_button_uncheckedHPACK : compresión de campos con estado por conexión

Las API repiten campos como método, esquema, host, tipo de contenido y autenticación. Enviarlos completos con cada solicitud aumenta los gastos generales. HPACK comprime bloques de campos utilizando una tabla estática de entradas comunes, una tabla dinámica construida durante la conexión, representaciones literales y codificación Huffman. Se puede hacer referencia a una entrada repetida mediante el índice en lugar de transmitir el nombre y el valor.

La tabla dinámica es direccional y está sincronizada por el orden de los bloques en la conexión. El codificador decide qué valores ingresar; el decodificador mantiene la misma secuencia. Cambiar el tamaño de la tabla o recibir un índice no válido puede generar un error de compresión y finalizar la conexión. Los intermediarios finalizan HPACK : la puerta de enlace decodifica los campos del cliente y crea su propia codificación cuando se conecta al backend .

Los campos sensibles como Autorización o cookies no deben indexarse cuando hacerlo aumenta el riesgo o la retención. HPACK incluye representación "nunca indexada". La compresión también interactúa con ataques de canal lateral cuando los secretos y los datos controlados comparten contexto. Los límites de tamaño de la lista de campos siguen siendo necesarios, porque una representación compacta puede expandirse a una gran cantidad de metadatos.

radio_button_unchecked Negociación: TLS , ALPN , h2 y h2c

En la web segura, HTTP /2 normalmente se negocia a través de TLS a través de ALPN . El cliente anuncia protocolos, por ejemplo `h2` y ` http /1.1`; el servidor selecciona uno y lo informa en el protocolo de enlace. Esto evita enviar una solicitud en el formato incorrecto. El certificado y el nombre aún deben ser válidos para el origen . Una vez que se selecciona h2, el cliente envía el prefacio y los frames HTTP /2.

HTTP /2 también puede funcionar sin TLS usando el identificador h2c, con conocimiento previo o Actualización desde HTTP /1.1, pero este modo es menos común en el tráfico público. En las redes internas, algunos componentes usan h2c para gRPC , mientras que TLS termina en sidecar o puerta de enlace. Esta decisión reduce el cifrado en un paso y debe evaluarse según la confianza, el cumplimiento y la observabilidad.

La fusión de conexiones permite reutilizar una conexión HTTP /2 para múltiples fuentes cuando se cumplen los requisitos de resolución, certificado y autoridad . Esto mejora la eficiencia, pero puede sorprender al equilibrio basado en conexiones. Las puertas de enlace y las CDN deben evitar que se proporcione autoridad no autorizada en la conexión. El origen lógico sigue estando determinado por la semántica, no solo por la dirección IP conectada.

radio_button_uncheckedHTTP/3 : semántica HTTP sobre QUIC

HTTP/3 asigna la semántica HTTP a QUIC . QUIC es un transporte orientado a conexión encapsulado en UDP , con flujos, control de flujo , detección de pérdidas, control de congestión, seguridad y migración de rutas. TLS 1.3 está integrado en el protocolo de enlace; No existe ningún modo HTTP/3 sin protección criptográfica según la especificación. La aplicación ve flujos confiables y ordenados individualmente, no datagramas UDP sin procesar.

Al igual que HTTP /2, HTTP/3 usa ENCABEZADOS y frames de DATOS, pero los frames viajan en flujos QUIC . Cada solicitud utiliza un flujo bidireccional iniciado por el cliente. Los flujos unidireccionales transportan control y QPACK . Las funciones que QUIC ya ofrece, como la identificación de flujo y el control de flujo , no están duplicadas por la capa HTTP . Por lo tanto, algunos frames y mecanismos HTTP /2 desaparecen o cambian.

Usar UDP no significa que HTTP/3 no sea confiable. QUIC implementa confirmación, retransmisión y ordenación de transmisiones. La diferencia es que estas funciones están en el espacio del usuario, integradas con criptografía y capaces de evolucionar sin depender de la implementación TCP del sistema operativo. Los firewalls y middleboxes que bloquean UDP pueden impedir QUIC , lo que requiere un respaldo a HTTP /2 o HTTP /1.1.

modelo mental

HTTP/3 no es " HTTP /2 sobre UDP ". Reutiliza ideas de flujos y frames, pero delega en QUIC propiedades que en HTTP /2 dependen de TCP y TLS separados.

radio_button_uncheckedHandshake QUIC , TLS 1.3 y 0- RTT

El protocolo de enlace QUIC negocia los parámetros de transporte y ejecuta TLS 1.3. En una nueva conexión, el cliente puede enviar un paquete inicial que contiene datos ClientHello; el servidor responde y las claves evolucionan a través de niveles de cifrado. En condiciones normales, los datos de la aplicación se pueden enviar con un número reducido de viajes de ida y vuelta. QUIC protege casi todo el contenido de control, reduciendo la visibilidad pasiva disponible para los middleboxes.

En las conexiones reanudadas, 0- RTT puede permitir que el cliente envíe datos de la aplicación antes de reconocer completamente el nuevo protocolo de enlace. Estos datos no tienen la misma protección de reproducción que los datos 1- RTT . Los servidores deben aceptar 0- RTT solo para operaciones seguras de reproducción o aplicar mecanismos anti-reproducción e idempotencia . Un POST financiero no debe considerarse seguro sólo porque utiliza TLS .

QUIC aplica protección de amplificación antes de validar la dirección del cliente: el servidor limita los bytes enviados en relación con los recibidos. Los tokens de retry pueden ayudar a validar el origen y controlar el abuso, a costa de viajes de ida y vuelta adicionales. Las puertas de enlace en el borde deben escalar el estado de intercambio, los umbrales y la protección DoS sin tratar todo el UDP como tráfico sin sesión.

radio_button_uncheckedStreams QUIC y eliminación de cabecera de línea entre streams

Cada flujo QUIC ofrece una entrega confiable y ordenada dentro del flujo mismo. Los paquetes pueden transportar tramas de múltiples flujos. Si se pierde un paquete con datos del flujo B, el receptor puede continuar entregando datos completos de los flujos A y C. Sólo el punto faltante de B impide el avance ordenado de ese flujo. Esto elimina el bloqueo transversal causado por TCP de flujo único sobre HTTP /2.

La mejora no elimina todos los bloqueos. Una corriente permanece ordenada; La pérdida de los primeros bytes impide la entrega de bytes posteriores del mismo flujo. El control del flujo de conexión también puede bloquear todas las transmisiones si el receptor no concede crédito. Las dependencias de QPACK pueden suspender la decodificación de un bloque de campos. Por lo tanto, las métricas y los seguimientos deben distinguir la pérdida de paquetes, el flujo bloqueado por datos, el flujo bloqueado por campos y la ventana de conexión.

QUIC numera datos y reconoce paquetes, pero retransmite información en paquetes nuevos, no en "el mismo paquete". Los números de paquetes nunca se reutilizan en el mismo espacio. La detección de pérdidas y el control de la congestión se especificaron en documentos asociados. La implementación en el espacio del usuario permite la evolución, pero también requiere una observabilidad específica de la biblioteca o proxy que finaliza QUIC .

radio_button_uncheckedConnection IDs , reenlace NAT y migración de ruta

TCP identifica una conexión por su conjunto de direcciones y puertos. Si un dispositivo móvil cambia de Wi-Fi a celular, la tupla cambia y normalmente se pierde la conexión. QUIC utiliza Connection IDs elegidos por los puntos finales, lo que le permite asociar paquetes de una nueva ruta a la conexión existente. El nuevo camino se valida con desafíos antes de ser utilizado por completo.

Los Connection IDs también permiten a los equilibradores reenviar paquetes sin depender exclusivamente de la tupla. El diseño debe considerar la privacidad y evitar que un identificador estable permita el seguimiento entre redes; Los puntos finales pueden proporcionar múltiples ID y retirarlas. Las puertas de enlace y los balanceadores de carga compatibles con QUIC deben coordinar el enrutamiento, las claves de retry /restablecimiento y la afinidad.

La migración no es garantía de continuidad en ningún entorno. Las políticas pueden desactivarlo; los cortafuegos pueden bloquear el nuevo camino; el servidor puede requerir validación; Los cambios de MTU y RTT alteran el rendimiento. Los registros deben registrar la migración y la validación de rutas para diferenciar el intercambio de red legítimo de la inestabilidad o el ataque.

radio_button_unchecked Frames y streams de control en HTTP/3

Una conexión HTTP/3 tiene un flujo de control por punto final. Envía AJUSTES, GOAWAY y otros frames de control. Cerrar prematuramente el flujo de control es un error de conexión. Las solicitudes utilizan flujos bidireccionales del cliente; cada uno lleva ENCABEZADOS, DATOS y avances según lo permitido. Los fotogramas de un mensaje no pueden aparecer en ningún orden arbitrario.

Como QUIC proporciona control de flujo y restablecimiento de flujo, HTTP/3 utiliza mecanismos de transporte durante parte del ciclo de vida. Los errores tienen códigos HTTP/3 y QUIC . Una cancelación puede implicar restablecer el envío y solicitar detenerlo en la dirección opuesta. La observabilidad debe asociar el flujo QUIC , la solicitud HTTP y la correlación de la aplicación, ya que una única Connection IDs puede realizar muchas operaciones.

HTTP/3 elimina características de HTTP /2 que dependían del flujo TCP , pero conserva el concepto de drenaje. GOAWAY limita los nuevos flujos de solicitudes aceptadas. Durante la implementación, el borde debe anunciar el cierre, mantener la conexión mientras finalizan las operaciones permitidas y dirigir nuevas llamadas a otra conexión. El cierre abrupto del estado UDP provoca la pérdida de todas las operaciones activas.

radio_button_uncheckedQPACK : compresión de campo adecuada para streams QUIC

HPACK depende del orden único de conexión TCP para sincronizar la tabla dinámica. En QUIC , las transmisiones se pueden entregar de forma independiente; una actualización de tabla perdida no debería bloquear innecesariamente todas las transmisiones. QPACK utiliza flujos de codificador y decodificador unidireccionales para transmitir instrucciones y reconocimientos, lo que permite que bloques de campos en flujos de solicitud hagan referencias controladas.

Un bloque puede depender de entradas que aún no se han recibido y bloquearse hasta que lleguen las instrucciones. El decodificador anuncia límites para la cantidad de transmisiones bloqueadas y el codificador elige entre una mejor compresión y el riesgo de bloqueo. Las representaciones literales y las tablas estáticas le permiten evitar dependencias. Al igual que con HPACK , los valores confidenciales se pueden marcar para no indexarlos.

Las puertas de enlace finalizan QPACK y crean un nuevo contexto en la siguiente conexión. Una falla de QPACK es un error de conexión y puede afectar muchas solicitudes. La supervisión únicamente del estado HTTP no revela esta clase de error, porque es posible que el mensaje no se reconstruya. Los registros del terminador HTTP/3 deben exponer códigos de error de descompresión y transmisiones bloqueadas.

radio_button_unchecked Descubrimiento y fallback de HTTP/3 , Alt-Svc, HTTPS /SVCB

Un cliente necesita saber qué origen ofrece HTTP/3 y en qué punto final. RFC 9114 define la publicidad mediante servicios alternativos: una respuesta HTTP /1.1 o HTTP /2 puede incluir `Alt-Svc: h3=":443"`. El cliente almacena la alternativa por un tiempo limitado y prueba QUIC . DNS también puede proporcionar registros HTTPS /SVCB con parámetros de protocolo y punto final. El soporte varía entre los clientes y la infraestructura.

La fuente lógica sigue siendo la misma, incluso si el servicio alternativo está en un host o puerto diferente. El cliente necesita validar la autoridad y el certificado según las reglas. Alt-Svc no es una redirección de aplicaciones y no cambia el URI mostrado. Si el intento de QUIC falla, los clientes normalmente continúan o recurren a HTTP /2/1.1, pero los detalles de la caché de fallas y el tiempo dependen de la implementación.

Al solucionar problemas, confirme que el cliente recibió un anuncio, que se intentó UDP , que se negoció ALPN h3 y que se produjo el fallback. Una captura solo del tráfico TCP puede mostrar que la llamada funciona y ocultar los intentos QUIC fallidos. El bloqueo de UDP /443 puede aumentar la latencia inicial incluso cuando el fallback mantiene la disponibilidad. Los registros HTTPS /SVCB incorrectos pueden dirigir a los clientes modernos a un punto final diferente al utilizado por los clientes heredados.

HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=86400
# El cliente puede intentar una conexión QUIC al mismo origen en el puerto 443.

radio_button_unchecked Comparación arquitectónica entre HTTP /1.1, HTTP /2 y HTTP/3

Elegir una versión no es sólo buscar “la más nueva”. HTTP /1.1 tiene una amplia compatibilidad y una observabilidad sencilla, pero requiere más conexiones para la concurrencia y sufre de bloqueo secuencial. HTTP /2 reduce la sobrecarga y permite muchos flujos en una conexión, siendo esencial para gRPC , pero concentra las operaciones en un TCP y requiere métricas de flujo y flujo. HTTP/3 mejora el comportamiento ante pérdidas y movilidad, pero depende de UDP , finaliza el cifrado en el componente que necesita interpretar HTTP y cambia las prácticas de red.

Las ganancias dependen del perfil. En una red estable y con baja latencia, una API pequeña puede mostrar una diferencia modesta. En conexiones móviles con pérdida, HTTP/3 puede reducir el impacto entre transmisiones y preservar la conexión durante el cambio de ruta. En una arquitectura empresarial con muchos intermediarios, el beneficio de extremo a extremo puede reducirse si el borde recibe H3 pero el resto usa H1.1 con grupos saturados.

Los protocolos también afectan la capacidad. Diez mil solicitudes pueden utilizar miles de conexiones H1, cientos de conexiones H2 o H3, según la simultaneidad y los límites. El equilibrio por conexiones es menos representativo en la multiplexación . Un solo cliente puede concentrar transmisiones en una instancia. Los algoritmos, los límites y la observabilidad deben evolucionar con el protocolo.

radio_button_uncheckedAPI Gateways y traducción de protocolos por salto

En una cadena empresarial, cada componente puede negociar su propia versión. Un cliente utiliza HTTP/3 con una CDN ; CDN utiliza HTTP /2 con API Gateway ; la puerta de enlace utiliza HTTP /1.1 con el backend . Es necesario preservar la semántica, pero se reconstruyen el framing , la compresión, la multiplexación y la conexión. No hay ningún flujo H3 que "atraviese" una puerta de enlace que finalice HTTP .

La traducción cambia el comportamiento. Muchas solicitudes multiplexadas desde una conexión H2 pueden requerir múltiples conexiones H1 al backend o serializarse según la pooling . Los remolques pueden perderse si el siguiente protocolo o producto no los conserva. Un reinicio de transmisión puede convertirse en una cancelación de socket , mientras que el backend ya ha procesado la operación. GOAWAY por un lado no tiene correspondencia directa en una conexión independiente por el otro lado.

Las políticas deben ser semánticas. La limitación de velocidad por conexión no es apropiada cuando una conexión contiene cientos de transmisiones. Los límites de carga útil deben considerar el tamaño sin comprimir. La caché debe utilizar la autoridad correcta y Vary. La observabilidad debe registrar la versión entrante, la versión saliente, la reutilización, el ID de transmisión cuando esté disponible, el retry y el estado creado por la puerta de enlace.

pregunta de arquitectura

¿Cuál es la versión negociada en cada conexión real: client-edge, edge- gateway , gateway -mesh y mesh- backend ? La respuesta "la API usa HTTP /2" suele estar incompleta.

radio_button_unchecked Aplicación en Axway API Gateway

Axway API Gateway utiliza servicios HTTP para recibir tráfico y configuraciones de hosts remotos para conexiones salientes. En un diseño real, las configuraciones de escucha, interfaz, TLS , política, enrutamiento y destino participan en diferentes saltos. La investigación debe separar la versión y los campos recibidos por el oyente de lo que se produce al conectarse al host remoto. Es necesario consultar la documentación y la versión instalada, ya que las capacidades y los estándares pueden variar según la versión.

Al reenviar a un backend , la conexión persistente y la pooling influyen en la latencia, la distribución y el consumo de sockets . Las configuraciones heredadas pueden utilizar comportamientos HTTP conservadores y los equipos deben validar explícitamente la versión saliente deseada. Las transformaciones y los filtros pueden cambiar el contenido , los campos y la transmisión. Los registros de acceso a transacciones y el seguimiento de políticas deben registrar el estado final, el tiempo de conexión, el tiempo de respuesta y el error de enrutamiento.

Un escenario común es que el cliente observa HTTP /2 en el borde, pero el backend registra HTTP /1.0 o HTTP /1.1. Esto no es necesariamente un error; podría ser una decisión o un incumplimiento del salto de salida. El riesgo surge cuando la aplicación depende de trailers , streaming o competencia que no sobrevive a la traducción. Las pruebas deben cubrir el protocolo real, no sólo el punto final público.

radio_button_unchecked Aplicación en Azure API Management

En Azure API Management, la puerta de enlace recibe llamadas, aplica políticas y las enruta a los backends . La compatibilidad con HTTP /2 entrante, saliente y gRPC depende del tipo y generación de puerta de enlace, nivel y configuración. La política "forward- request " tiene un atributo de versión HTTP para los escenarios admitidos. A medida que la plataforma evoluciona, la documentación oficial debe tratarse como la fuente de verdad para la instancia utilizada.

La versión entrante no implica una versión saliente. La documentación actual describe comportamientos en los que ciertas generaciones admiten HTTP /2 y pueden degradar el reenvío, mientras que otras le permiten configurar HTTP /2 para el backend . Esto afecta a gRPC , avances y streaming . Las pruebas deben registrar "contexto"/rastros, diagnósticos de backend y métricas de instancia para confirmar la ruta efectiva.

Políticas como rewrite- uri , set- header , set- body , cache , retry y rate-limit operan en el mensaje lógico y pueden cambiar las características observadas. El retry debe considerar la idempotencia . Set- body generalmente implica acceso al contenido y puede requerir almacenamiento en búfer. La caché debe respetar la identidad y Vary. Al combinar Application Gateway , Front Door, APIM y backend , cada servicio finaliza su propia conexión y puede tener un timeout diferente.

radio_button_unchecked Observabilidad: qué medir en cada versión

Las métricas comunes incluyen tasa de solicitudes, estado, latencia, bytes y errores. Para HTTP /1.1, agregue conexiones abiertas, nuevas conexiones por segundo, reutilización, espera de grupo y restablecimientos. Para HTTP /2, mida las transmisiones activas por conexión, el umbral de simultaneidad, RST_STREAM, GOAWAY , la ventana de transmisión y los errores de compresión. Para HTTP/3 , incluya retries QUIC , éxito/retroceso, protocolo de enlace, pérdida, RTT , migración, transmisiones bloqueadas y errores QPACK .

La latencia debe descomponerse. DNS , conexión, TLS / QUIC , tiempo de política, espera del grupo, tiempo hasta el primer byte ascendente y transferencia de contenido responden a diferentes preguntas. Una métrica "total" alta no identifica la causa. El seguimiento distribuido comienza cuando hay un mensaje HTTP ; Las fallas anteriores pueden requerir terminadores y registros de red. La puerta de enlace debe crear o propagar de manera confiable identificadores de correlación.

Las capturas de tráfico siguen siendo útiles, pero el cifrado limita el contenido . En TLS sobre TCP , el terminador puede proporcionar un registro de claves en un laboratorio controlado. QUIC cifra más elementos de control, por lo que las métricas de qlog y biblioteca son valiosas. En la producción bancaria, la recaudación debe respetar los datos sensibles: no registrar tokens , cookies , PAN, cargas útiles o encabezados completos sin enmascaramiento y base legal.

radio_button_unchecked Método de troubleshooting HTTP de un extremo a otro

El primer paso es determinar si hubo una respuesta HTTP válida. Pueden ocurrir errores de DNS , TCP , UDP , TLS o QUIC antes de cualquier estado. Las herramientas a veces convierten los fallos en mensajes genéricos, pero la puerta de enlace no puede haber producido 504 si la llamada ni siquiera llegó a ella. Identifique el último componente que tiene evidencia del intento y el primero que no.

Cuando exista estatus, determine la autoría. Compare el estado público, el estado ascendente, el error interno y la política ejecutada. Se puede conservar un 503 del backend ; La puerta de enlace podría crear otros 503 porque no había puntos finales en buen estado disponibles. Los encabezados como Server no son prueba suficiente, ya que pueden eliminarse o falsificarse. Utilice correlación y marcas de tiempo entre registros controlados.

Luego registre la versión y la conexión en cada salto. Confirme ALPN , protocolo de salida, reutilización, reinicio de transmisión, GOAWAY , retry y timeout . Compare el método, la autoridad , la ruta, los campos relevantes y la longitud antes y después de la puerta de enlace. Para fallas intermitentes, busque patrones por conexión, instancia, transmisión, tamaño de carga útil, versión, red y tiempo de implementación.

radio_button_unchecked Estudio de caso 1: POST duplicado después de 504

Un cliente envía POST para crear una transferencia. La puerta de enlace lo reenvía al backend , que confirma la transacción en el banco, pero tarda un poco en generar la respuesta. El timeout de la puerta de enlace expira y devuelve 504. El cliente lo interpreta como un error y repite la llamada. Dado que POST no es idempotente por definición y no existe una clave de deduplicación, el backend crea una segunda transferencia.

El problema no se resuelve simplemente aumentando el timeout . La arquitectura debe definir la semántica de idempotencia : el cliente envía una clave única; conservas de entrada; El backend registra la clave y el resultado de forma atómica. Al repetir, devuelve el resultado anterior. La puerta de enlace puede utilizar el retry solo para fallas claramente anteriores al envío o en operaciones clasificadas. Los registros deben mostrar el ID de la solicitud, la clave de idempotencia , el intento y el resultado del backend .

Aprendizaje

Tiempo de espera significa que no hay confirmación para el observador, ni prueba de que no haya efecto en el sistema remoto.

radio_button_unchecked Estudio de caso 2: Saturación del backend público HTTP /2 y HTTP /1.1

Un borde recibe miles de flujos HTTP /2 en unas pocas conexiones y los reenvía a la puerta de enlace. La puerta de enlace llama a un backend HTTP /1.1 con un grupo de 100 conexiones. Durante el pico, las transmisiones ingresan rápidamente pero esperan la conexión ascendente. Las métricas TCP entrantes parecen estables porque hay pocas conexiones H2; la cola y la latencia crecen en el grupo saliente.

La solución requiere medir la competencia por flujo y grupo de espera, aplicar límites de admisión, ajustar la capacidad de backend y considerar HTTP /2 saliente cuando sea compatible. Aumentar el grupo sin evaluar los recursos puede sobrecargar el servicio. La limitación de la velocidad por conexión sería ineficaz, ya que una conexión H2 concentra muchos flujos. El objetivo es alinear la competencia lógica con la capacidad real de producción.

Aprendizaje

En protocolos multiplexados, la conexión ya no es una buena aproximación para el número de operaciones simultáneas.

radio_button_unchecked Estudio de caso 3: HTTP/3 anunciado pero UDP bloqueado

Una CDN comienza a anunciar "Alt-Svc: h3". Los clientes modernos prueban QUIC en UDP /443, pero una red corporativa bloquea UDP . Después de un retraso, el cliente vuelve a HTTP /2 y la API funciona. Los usuarios reportan lentitud sólo en el primer acceso; las pruebas que fuerzan HTTP /2 no se reproducen. Los registros de API muestran solicitudes normales, porque el intento falla antes de que llegue el mensaje HTTP .

La investigación debe analizar los paquetes DNS , Alt-Svc, UDP y el tiempo de reserva. La solución puede implicar habilitar QUIC , eliminar publicidad de redes específicas cuando sea posible o aceptar respaldo con monitoreo. No se debe concluir que HTTP/3 provocó un error de aplicación. El problema radica en el descubrimiento y establecimiento del transporte, antes de la transacción HTTP observada por la puerta de enlace.

Aprendizaje

La disponibilidad alternativa puede ocultar una falla en la ruta y agregar latencia invisible en los registros de la aplicación.

radio_button_unchecked Estudio de caso 4: La traducción de H2 a H1 crea un framing inseguro

Un proxy acepta HTTP /2 y convierte pseudocampos y DATOS a HTTP /1.1. Una combinación con formato incorrecto pasa la validación H2, pero genera dos señales de longitud incompatibles en H1. El backend interpreta el mensaje de manera diferente y los bytes controlados constituyen la siguiente solicitud en la conexión persistente. La vulnerabilidad sólo aparece cuando la ruta incluye la traducción específica.

La mitigación requiere validar el mensaje lógico antes de serializar H1, emitir exactamente un mecanismo de framing , rechazar campos prohibidos, actualizar intermediarios y probar variaciones de contrabando. Deshabilitar la reutilización puede reducir el impacto, pero no reemplaza la corrección. Es posible que WAF basado únicamente en texto de entrada H2 no vea el mensaje generado en el backend .

Aprendizaje

El punto de mayor riesgo suele ser el límite entre dos analizadores o versiones, no un analizador aislado.

radio_button_unchecked Laboratorios de lectura práctica y diagnóstico.

Laboratorio 1: Comparar HTTP /1.1 y HTTP /2 con cURL

Utilice un punto final de laboratorio que admita ambas versiones. Ejecute llamadas forzando HTTP /1.1 y HTTP /2 y habilite la salida detallada. Tenga en cuenta la resolución, conexión, TLS , ALPN , línea de solicitud mostrada, reutilización y sincronización. Repita varias llamadas en el mismo proceso para comprobar la reutilización. No utilice puntos finales productivos ni tokens reales.

curl -v --http1.1 https://SEU-ENDPOINT-DE-LAB/status
curl -v --http2   https://SEU-ENDPOINT-DE-LAB/status
# También tiempos récord:
curl -sS -o /dev/null -w "connect=%{time_connect} tls=%{time_appconnect} ttfb=%
{time_starttransfer} total=%{time_total}\n" https://SEU-ENDPOINT-DE-LAB/status

Laboratorio 2: Inspeccionar ALPN con OpenSSL

Conéctese a un servidor de laboratorio y anuncie h2 y HTTP /1.1. Confirme el protocolo seleccionado. Luego fuerce solo http /1.1 y compare. El objetivo es darse cuenta de que ALPN ocurre en el protocolo de enlace TLS antes de los mensajes HTTP . En entornos proxy , ejecute desde diferentes puntos de red para identificar diferentes puntos finales.

openssl s_client -connect SEU-ENDPOINT-DE-LAB:443 -servername SEU-ENDPOINT-DE-LAB -alpn
"h2,http/1.1"
# Buscar: Protocolo ALPN: h2

Laboratorio 3: caché y revalidación

Cree un servicio de laboratorio que devuelva ETag y Cache -Control. Haga un GET , almacene el ETag y envíe If-None-Match. Confirma 304 sin contenido . Modifique el recurso y repita. Agregue un proxy de caché controlado y observe Age and Vary. Documente cómo la autenticación cambia la posibilidad de caché compartida.

curl -i https://SEU-ENDPOINT-DE-LAB/resource
curl -i -H "If-None-Match: \"ETAG-RECEBIDA\"" https://SEU-ENDPOINT-DE-LAB/resource

Laboratorio 4: Framing HTTP /1.1 en un entorno aislado

En un servidor local creado para estudio, envíe mensajes con la Content-Length correcta y fragmentos válidos. Observe cómo el servidor lee el cuerpo. Luego pruebe las entradas no válidas sólo en un laboratorio autorizado y confirme que sean rechazadas, sin intentar explotar sistemas de terceros. El objetivo es comprender el análisis y la validación, no ejecutar ataques.

printf "POST /echo HTTP/1.1\r\nHost: localhost\r\nContent-Length: 5\r\n\r\nhello" | nc
127.0.0.1 8080

Laboratorio 5: Observar HTTP/3 y respaldo

Utilice una herramienta de laboratorio y un punto final con soporte HTTP/3 conocido. Registre el intento de QUIC , el protocolo final y el fallback cuando UDP esté bloqueado en un entorno de prueba. Compare el tiempo con el primer byte. No cambie los firewalls corporativos sin autorización. En clientes que admiten qlog, genere un seguimiento local y vea el protocolo de enlace y las transmisiones.

curl -v --http3 https://SEU-ENDPOINT-DE-LAB/status
curl -v --http3-only https://SEU-ENDPOINT-DE-LAB/status
# La disponibilidad de opciones depende de la compilación de cURL y la biblioteca QUIC.

Laboratorio 6: Mapeo de versiones por salto en la puerta de enlace

Publique una API de laboratorio que devuelva encabezados de protocolo, host y correlación observados por el backend . Llame al punto final público en diferentes versiones y compare registros de escucha, seguimientos de políticas y resultados de backend . Dibuje cada conexión independiente y anote TLS , ALPN , versión, grupo, timeout y transformación. Este mapa es más útil que declarar una única "versión API ".

1. Registre el protocolo de borde de cliente.
2. Registre el protocolo de puerta de enlace de borde.
3. Registre el protocolo de puerta de enlace- backend .
4. Compare los campos Host/: autoridad y Reenviado.
5. Ejecute llamadas con contenido grande y observe el almacenamiento en búfer.
6. Ejecute un despliegue controlado y observe el drenaje/ GOAWAY o los reinicios.

radio_button_unchecked Checklist de arquitectura HTTP para API empresariales

radio_button_unchecked Resumen del capítulo

HTTP proporciona una semántica estable para la interacción entre clientes, servidores e intermediarios. Los métodos expresan intención; los estados comunican resultados; los campos describen el control y la representación ; La caché y las condiciones permiten la reutilización y la simultaneidad. Estos conceptos son independientes de JSON , REST o la versión de transporte.

HTTP /1.1 codifica mensajes de texto en una secuencia TCP y requiere reglas de framing estrictas. Las conexiones persistentes ahorran apretones de manos, pero la pooling , los tiempos de espera y el análisis divergente crean riesgos. HTTP /2 introduce tramas, flujos, multiplexación , control de flujo y HPACK , lo que reduce la sobrecarga y el encabezado de línea a nivel HTTP , aunque la pérdida de TCP todavía afecta a todos los flujos.

HTTP/3 usa QUIC sobre UDP , integra TLS 1.3, aísla la pérdida por transmisión, admite Connection IDs y usa QPACK . El descubrimiento puede realizarse a través de registros Alt-Svc y HTTPS /SVCB, con respaldo a versiones anteriores. En las puertas de enlace, cada salto negocia su propia versión; el profesional necesita observar el mensaje lógico y la conexión de cada segmento.

La troubleshooting confiable comienza clasificando si la falla ocurrió antes o después de que hubo una respuesta HTTP , identificando quién creó el estado y asignando versiones, tiempos de espera, grupos, transmisiones y transformaciones. La arquitectura debe proteger la semántica, la idempotencia y la seguridad durante las traducciones entre protocolos.

radio_button_unchecked Ejercicios de repaso

1. Explique la diferencia entre la semántica HTTP y el mapeo de versiones específicas.
2. ¿Por qué apátrida no significa que una aplicación no puede mantener una sesión?
3. Diferenciar recurso, representación , contenido y framing .

1. ¿Qué componentes de una URI participan en una solicitud HTTP y cuáles no se envían?
2. Diferenciar el método seguro del método idempotente y dar ejemplos.
3. ¿Por qué repetir POST después del timeout puede producir duplicidad incluso cuando el cliente recibió 504?
4. ¿Quién puede crear un 502 en una cadena con múltiples proxies ?
5. ¿Por qué no debería utilizarse la frase de motivo en la lógica del cliente?
6. Diferenciar tipo de contenido , codificación de contenido y codificación de transferencia.
7. Explique por qué Vary es necesario en la negociación de contenido en caché.
8. ¿Qué significa "Control de caché: sin caché"?
9. ¿Cómo ayudan ETag e If-Match a evitar la pérdida de actualizaciones?
10. ¿Por qué TCP no conserva los límites de los mensajes HTTP ?
11. ¿Qué riesgos existen cuando la Content-Length y la codificación de transferencia se interpretan de manera diferente?
12. ¿Por qué una conexión persistente sólo se puede reutilizar después de consumir por completo el mensaje anterior?
13. Describir el encabezado de línea en la canalización HTTP /1.
15. ¿Cómo asigna HTTP /2 una solicitud a frames y transmisiones?
16. Diferenciar entre control de flujo HTTP /2 y control de congestión TCP .
17. ¿Cuál es la función de SETTINGS_MAX_CONCURRENT_STREAMS?
18. ¿Cómo ayuda GOAWAY con las implementaciones y el drenaje?
19. ¿Cómo reduce HPACK los gastos generales y por qué crea un estado por conexión?
20. ¿Cuál es el papel de ALPN en la negociación HTTP /2?
21. ¿Por qué HTTP /2 sigue sujeto al encabezado de línea de TCP ?
22. ¿Por qué es incorrecto afirmar que HTTP/3 es “ UDP no confiable”?
23. ¿Cómo permite QUIC la migración de rutas?
24. ¿Cuál es el riesgo de 0- RTT para operaciones con efectos?
25. ¿En qué se diferencia conceptualmente QPACK de HPACK ?
26. ¿Cómo puede Alt-Svc anunciar HTTP/3 sin cambiar el origen lógico?
27. ¿Por qué una API puede usar HTTP/3 públicamente y HTTP /1.1 en el backend ?
28. ¿Qué métricas adicionales se necesitan en HTTP /2 y HTTP/3 ?
29. Proponer un presupuesto de timeout para el cliente, el borde, la puerta de enlace y el backend .
30. Diseñe una estrategia de retry segura para pagos GET y POST .
31. Explique cómo una traducción de H2 a H1 puede crear un riesgo de request smuggling.
32. Describe la evidencia necesaria para demostrar qué versión se utilizó en cada salto.

radio_button_unchecked Preguntas de discusión arquitectónica

• En una organización con miles de API , ¿qué criterios justifican habilitar HTTP /2 o HTTP/3 en el borde y el backend ?
• ¿Cómo deberían los equilibradores distribuir la carga cuando pocas conexiones transportan muchos flujos?
• ¿Qué campos deberían eliminarse o reconstruirse en una cadena con CDN , WAF , puerta de enlace y malla de servicios?
• ¿Cómo garantizar la idempotencia de las operaciones financieras cuando pueden ocurrir tiempos de espera y retries en varios componentes?
• ¿Qué nivel de observabilidad de QUIC es aceptable en un entorno regulado sin exponer datos confidenciales?
• ¿Cuándo es necesario el almacenamiento en búfer en la puerta de enlace y cuándo destruye los beneficios del streaming ?
• ¿Cómo probar la seguridad del análisis y la traducción de protocolos en una cinta transportadora automatizada?

radio_button_unchecked Glosario

radio_button_unchecked Referencias oficiales y lecturas recomendadas.

Las referencias a continuación priorizan las especificaciones y la documentación oficial. Se deben consultar los RFC con sus erratas y cualquier documento que las actualice. La documentación del producto debe validarse para la versión, el nivel y la puerta de enlace utilizados en el entorno.

1. RFC 9110 - Semántica HTTP - https ://www. rfc -editor.org/ rfc /rfc9110. html
2. RFC 9111 - Almacenamiento en caché HTTP - https ://www. rfc -editor.org/ rfc /rfc9111. html
3. RFC 9112 - HTTP /1.1 - https ://www. rfc -editor.org/ rfc /rfc9112. html
4. RFC 9113- HTTP /2- https ://www. rfc -editor.org/ rfc /rfc9113. html
5. RFC 9114- HTTP/3 - https ://www. rfc -editor.org/ rfc /rfc9114. html
6. RFC 7541 - HPACK : Compresión de encabezado para HTTP /2 - https ://www. rfc -editor.org/ rfc /rfc7541. html
7. RFC 9204 - QPACK : Compresión de campos para HTTP/3 - https ://www. rfc -editor.org/ rfc /rfc9204. html
8. RFC 9000 - QUIC : un transporte seguro y multiplexado basado en UDP - https ://www. rfc -editor.org/ rfc /rfc9000. html
9. RFC 9001: uso de TLS para proteger QUIC : https ://www. rfc -editor.org/ rfc /rfc9001. html
10. RFC 9002 - Control de congestión y detección de pérdidas QUIC - https ://www. rfc -editor.org/ rfc /rfc9002. html
11. RFC 7838 - Servicios alternativos HTTP - https ://www. rfc -editor.org/ rfc /rfc7838. html
12. RFC 9460 - Enlace de servicios y registros de recursos DNS HTTPS - https ://www. rfc -editor.org/ rfc /rfc9460. html
13. RFC 9651 - Valores de campos estructurados para HTTP - https ://www. rfc -editor.org/ rfc /rfc9651. html
14. RFC 7301: Negociación del protocolo de capa de aplicación TLS : https ://www. rfc -editor.org/ rfc /rfc7301. html
15. RFC 9308 - Aplicabilidad del protocolo de transporte QUIC - https ://www. rfc -editor.org/ rfc /rfc9308. html
16. RFC 9312 - Manejabilidad del protocolo de transporte QUIC - https ://www. rfc -editor.org/ rfc /rfc9312. html
17. Registro de nombres de campos HTTP de IANA : https ://www. iana .org/assignments/ http -fields/ http -fields.xhtml
18. Registro de códigos de estado HTTP de IANA : https ://www. iana .org/assignments/ http -status-codes/ http -status-codes.xhtml
19. Axway: configurar servicios HTTP : https ://docs.axway.com/bundle/axway-open-docs/page/docs/apim_policydev/apigw_gw_instances/general_services/index. html
20. Axway: configurar los ajustes del host remoto: https ://docs.axway.com/bundle/axway-open-docs/page/docs/apim_policydev/apigw_gw_instances/general_remote_hosts/index. html
21. Microsoft: puerta de enlace API en Azure API Management: https ://learn.microsoft.com/en-us/azure/ api -management/ api -management- gateways -overview
22. Microsoft: política de solicitud de reenvío: https ://learn.microsoft.com/en-us/azure/ api -management/forward- request -policy
23. Microsoft: administrar protocolos y cifrados en API Management: https ://learn.microsoft.com/en-us/azure/ api -management/ api -management-howto-manage-protocols-ciphers

Orden de lectura sugerido

1. Lea las secciones introductorias y la terminología de RFC 9110 antes de estudiar versiones específicas.
2. Estudie RFC 9112 centrándose en el framing de mensajes, la conexión y la seguridad del análisis.
3. Lea la descripción general, frames, flujos, control de flujo y errores de RFC 9113; consultar HPACK en paralelo.
4. Estudie QUIC en las secciones de conexión, flujos, control de flujo y migración de RFC 9000, seguido de la integración de TLS en RFC 9001.
5. Lea RFC 9114 y QPACK , que enumeran lo que se delega a QUIC .
6. Consulte Alt-Svc y HTTPS /SVCB para comprender el descubrimiento y el fallback.
7. Finalmente, mapear las capacidades y limitaciones de la versión de Axway y Azure APIM utilizada en el trabajo.

Cierre

Dominar HTTP significa dominar el límite entre la intención comercial y el transporte. El próximo capítulo profundizará en HTTPS y TLS , explicando cómo la identidad, la confidencialidad y la integridad protegen cada una de estas conexiones.