Resumen

  • Alt-Svc permite que un origen anuncie otro protocolo, host y puerto donde sus recursos pueden estar disponibles sin cambiar el URI de origen.
  • Un anuncio vigente no demuestra que un cliente concreto alcanzó la alternativa, la autenticó para el origen, negoció el protocolo esperado o completó allí una solicitud.
  • La elección del cliente es opcional, el contexto de red importa y un fallo puede provocar una ruta de respaldo cuyas propiedades deben observarse.
  • Un recibo de ruta alternativa debe unir edad del anuncio, identidad del origen, autenticación, resultado ALPN, elección del cliente, resultado de solicitud y respaldo en un mismo punto de observación.

Imaginemos un servicio que devuelve Alt-Svc: h3=":443"; ma=86400. Un tablero de despliegue ve la cabecera en el origen y declara completada la migración a HTTP/3. Sin embargo, en una red de acceso no se puede establecer la conexión alternativa. Los clientes continúan silenciosamente por la conexión original, las solicitudes siguen funcionando y la disponibilidad agregada permanece verde. El anuncio era real, pero el cambio de ruta afirmado nunca ocurrió para esa población.

Es un caso hipotético, no un incidente atribuido a un proveedor. El mecanismo funciona según lo previsto. El error de medición consiste en confundir elegibilidad con ejecución.

La ruta alternativa conserva el origen

El RFC 7838 define los servicios HTTP alternativos para que los recursos de un origen estén disponibles de forma autoritativa en otra ubicación, quizá con otra configuración de protocolo. La alternativa combina protocolo de aplicación, host y puerto. Es información de ruta para el mismo origen, no una redirección que cambie el URI.

El contexto de seguridad conserva esa identidad. El software superior sigue viendo el esquema, host y puerto originales. Cuando TLS autentica la conexión, la alternativa debe presentar credenciales válidas para el nombre del origen, no solo para el host alternativo.

El anuncio no demuestra esa autenticación. Solo registra una nominación del origen. La prueba de uso seguro comienza con la conexión que el cliente estableció y la identidad que verificó realmente.

Elegibilidad, negociación y uso son hechos distintos

Los servicios alternativos son opcionales para el cliente. Este puede elegir entre alternativas vigentes según sus criterios y mantener la conexión existente mientras establece otra. El orden preferido por el servidor no documenta la decisión del cliente.

El RFC 7301 define la negociación del protocolo de aplicación dentro de TLS. RFC 7838 exige considerar fallida una alternativa si no se negocia el protocolo esperado. Un socket alcanzable o un handshake TLS terminado no bastan si no se seleccionó el protocolo anunciado.

Para HTTP/3, el RFC 9114 transporta la semántica HTTP sobre QUIC y utiliza el token ALPN h3. Ver h3 en Alt-Svc no equivale a establecer QUIC, negociar HTTP/3 y completar una solicitud. Cada transición requiere una medida separada.

Cuando se usa una alternativa, Alt-Used puede comunicarlo al servidor. La observación depende del lugar de medición: origen, CDN, cliente y sonda sintética ven partes diferentes. Toda afirmación seria debe identificar ese lugar.

Vigencia no significa salud

Alt-Svc tiene su propio periodo de vigencia. ma controla cuánto tiempo puede usarse para abrir conexiones nuevas, independientemente del caché HTTP ordinario. Un valor nuevo sustituye las alternativas almacenadas y clear las invalida.

La vigencia solo mantiene elegible el anuncio según esas reglas. No garantiza alcance actual, rutas desde todas las redes, permiso de QUIC en cada frontera de política, capacidad o latencia. Son propiedades del camino presente.

Los clientes normalmente eliminan alternativas sin persist=1 cuando detectan un cambio de red. Incluso una alternativa persistente solo sugiere que podría seguir siendo útil; no certifica la política ni el alcance de la red nueva.

El respaldo puede conservar el servicio y ocultar el fallo

RFC 7838 permite volver al origen u otra alternativa cuando el servicio elegido falla o no responde. Así se protege la disponibilidad, pero se puede ocultar una migración fallida. Una solicitud exitosa no prueba el camino pretendido si no se identifica la ruta real.

El respaldo también puede perder propiedades de seguridad y convertirse en una superficie de degradación. El recibo debe registrar qué alternativa falló, cómo falló, qué ruta la sustituyó, si estaba permitido y qué propiedad cambió.

Disponibilidad, adopción de la alternativa y seguridad del respaldo son tres métricas diferentes. Una sola tasa verde no representa las tres.

Cierre el cambio con un recibo de ruta alternativa

Abra el recibo al observar el anuncio. Registre origen, valor Alt-Svc exacto, fuente de la respuesta, hora, edad calculada, ma, persist, contexto de red y cohorte. Conserve si llegó directamente o mediante una respuesta almacenada, y si otro valor lo sustituyó o borró.

Por cada intento, registre host y puerto alcanzados, autenticación del nombre de origen, ALPN ofrecido y negociado, resultado de conexión, razón de elección, estado y latencia de solicitud, observación de Alt-Used y ruta de respaldo. Fallos y omisiones explican por qué un anuncio vigente no se convirtió en tráfico.

Cierre la afirmación solo para la población y el periodo cubiertos. El anuncio prueba nominación; la autenticación, autoridad del origen; ALPN, selección del protocolo; y la solicitud, uso y resultado. La ruta queda demostrada cuando esos hechos están unidos en un punto de observación identificado.

Fuentes