SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark

---

Muchos incidentes de "HTTP/2 no funciona" son en realidad problemas de negociación de TLS ALPN. Los usuarios buscan "TLS ALPN pcap", "HTTP2 alternativo a HTTP/1.1", "ALPN h2 no negociado", "extensión ClientHello ALPN", "protocolo seleccionado ServerHello" y "por qué mi navegador usa HTTP/1.1" cuando un punto final debería admitir HTTP/2 pero el tráfico disminuye.

La cirugía PCAP es útil porque la evidencia ALPN reside en el apretón de manos TLS. Si la captura incluye ClientHello y ServerHello, a menudo puede probar si el cliente ofreció "h2", si el servidor lo seleccionó, si un proxy terminó TLS o si la conexión nunca tuvo la oportunidad de negociar HTTP/2.

¿Qué hace ALPN?

ALPN significa Negociación de protocolo de capa de aplicación. Permite que el cliente y el servidor acuerden un protocolo de aplicación durante la configuración de TLS.

Valores ALPN comunes:

• h2 para HTTP/2 sobre TLS.
• http/1.1 para HTTP/1.1.
• Otros identificadores de protocolo para sistemas especializados.

Si el cliente no ofrece h2, el servidor no puede seleccionarlo. Si el servidor no selecciona h2, la conexión no utilizará HTTP/2 incluso si el servidor admite HTTP/2 en otro lugar.

Síntomas comunes

Las fallas de ALPN aparecen como:

• El navegador utiliza HTTP/1.1 en lugar de HTTP/2.
• La conexión gRPC falla.
• CDN funciona pero el origen no.
• Protocolo de degradación de proxy inverso.
• El equilibrador de carga finaliza TLS y reenvía HTTP/1.1.
• La aplicación móvil dice error de protocolo.
• Las métricas del servidor no muestran tráfico h2.
• HTTP/2 funciona con un nombre de host pero no con otro.

Estos síntomas a menudo se depuran en la capa HTTP, pero la respuesta puede estar en la negociación TLS.

ClienteHola evidencia

ClientHello puede mostrar si el cliente ofreció ALPN y qué protocolos anunció.

Preguntas útiles:

• ¿Está presente la extensión ALPN?
• ¿La oferta incluye h2?
• ¿También incluye http/1.1?
• ¿El SNI está presente y es correcto?
• ¿Qué versión de TLS se ofrece?
• ¿Se realiza la captura antes de que un proxy finalice TLS?

Si h2 está ausente en ClientHello, el servidor no puede elegir HTTP/2. El motivo puede ser la configuración de la biblioteca del cliente, una pila TLS antigua, una opción HTTP/2 deshabilitada o un cliente proxy que abre una nueva conexión ascendente.

ServidorHola evidencia

El lado del servidor debe seleccionar un protocolo de la lista ALPN del cliente.

Problemas:

• El servidor selecciona solo http/1.1.
• El servidor omite la respuesta ALPN.
• El protocolo de enlace del servidor falla antes de la selección de ALPN.
• Las rutas de certificado o SNI no coinciden con un host virtual predeterminado.
• El terminador TLS admite h2 en el lado público pero no en el lado ascendente.

La evidencia de paquetes puede separar el soporte del servidor del enrutamiento y el comportamiento del proxy.

SNI y ALPN juntos

SNI y ALPN suelen estar conectados. El nombre de host seleccionado por SNI puede determinar qué configuración de certificado, host virtual y protocolo se aplican.

Ejemplo de fallo:

• El cliente ofrece h2.
• El cliente envía un SNI incorrecto.
• El servidor devuelve el certificado predeterminado.
• El host virtual predeterminado no habilita HTTP/2.
• La conexión vuelve a http/1.1.

En este caso, el problema no es "HTTP/2 roto globalmente". Es enrutamiento de nombre de host.

Terminación de proxy y balanceador de carga

Las implementaciones modernas a menudo dividen TLS:

client -> CDN or load balancer -> reverse proxy -> origin

Each segment may have different ALPN behavior. The public side may negotiate HTTP/2 while the upstream side uses HTTP/1.1. Or the reverse proxy may accept h2 from clients but downgrade to HTTP/1.1 when talking to the application.

When analyzing a pcap, identify which segment you captured. A trace on the origin server may not show the public client handshake at all.

gRPC and ALPN

gRPC usually requires HTTP/2. If ALPN does not negotiate h2, gRPC clients may fail with protocol errors, unavailable errors, or connection reset messages.

For gRPC troubleshooting, preserve:

• DNS answer.
• TCP handshake.
• TLS ClientHello.
• TLS ServerHello.
• ALPN protocol selected.
• Any TLS alert.
• First HTTP/2 frames if decrypted or visible through logs.

Even without decrypting payload, ALPN can prove whether HTTP/2 was negotiated.

Fallback is not always failure

HTTP clients may intentionally fall back to HTTP/1.1 when:

• Server does not advertise h2.
• Client policy disables HTTP/2.
• TLS version or cipher constraints are incompatible.
• Proxy strips or terminates the connection.
• ALPN extension is missing.
• A middlebox interferes with handshake.

The diagnostic question is whether fallback was expected for that route.

Debug checklist

Use this workflow:

1. Capture from TCP handshake through TLS handshake.
2. Confirm SNI hostname.
3. Check ClientHello ALPN list.
4. Confirm whether h2 is offered.
5. Check ServerHello selected ALPN.
6. Compare certificate with SNI.
7. Identify CDN, proxy, or load balancer termination.
8. Compare public-side and origin-side captures if needed.
9. Check whether the client library enables HTTP/2.
10. Preserve the handshake when trimming the pcap.

Final diagnosis

TLS ALPN and HTTP/2 issues should be diagnosed from handshake evidence. The key facts are whether the client offered h2, whether the server selected it, whether SNI routed to the right virtual host, and whether a proxy changed protocol between network segments.

PCAP Surgery helps keep the exact handshake packets needed to prove HTTP/2 negotiation, fallback, or proxy termination behavior.

<!-- pcap-localized-evidence-foundation-v1:start -->

Respuesta basada en paquetes para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark»

La respuesta directa es que una etiqueta del analizador o un mensaje de la aplicación no determina la causa. Empieza por punto de captura y dirección; demuestra la última frontera correcta y la primera fallida. En «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark», otro revisor debe poder encontrar el packet, hueco o intervalo que sostiene cada frase y saber qué evidencia podría refutarla.

Situar la captura en el camino

Registra client, server y cualquier proxy, load balancer, NAT o firewall. Indica interface, lugar, reloj, sistema y direcciones visibles. Una captura junto al client demuestra lo que llegó allí, no que el server no enviara. Una junto al server demuestra salida en ese punto, no tránsito completo. Antes de comparar dos puntos corrige clock offset y alinea flow tuple, TCP sequence o transaction ID.

Comprueba calidad: snap length, dropped packets, offload, capture filter, ring buffer y hora inicial. Un checksum incorrecto en host puede ser offload artifact. Un segmento grande puede provenir de GRO/TSO y no existir así en el cable. Un packet ausente en un archivo limitado no es network loss hasta demostrar que el punto debía verlo.

Leer fronteras en orden

Frontera	Evidencia correcta	Evidencia de fallo
Link e IP	dirección, addresses y ruta coherentes	ARP/NDP ausente, ICMP, MTU, asimetría
TCP	SYN, SYN-ACK, ACK y sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello y progreso	alert o límite SNI/ALPN/certificate
Aplicación	request completo y response relacionado	status, gap o cierre temprano
Usuario	response time o failure window	stall ligado a una frontera

Detente en la primera frontera sin éxito. Si TCP no termina, no empieces por HTTP. Si request llega al proxy pero no al upstream, el límite está en proxy o su camino. Si llega al upstream sin response antes del timeout, usa ACK y progreso de bytes para separar application delay de network loss.

Separar observación e hipótesis

La observación se puede señalar: «Client envió hasta cierta sequence; sender repitió un segmento tres veces y no apareció ACK avanzado en este punto». La hipótesis es «el camino perdió el segmento». Otra captura o dropped records pueden refutarla. Para cada hipótesis escribe una prueba favorable y una contraria.

Retransmission o duplicate ACK no asigna culpable. Reordering, loss, capture artifact y receiver delay producen marcas similares. Relaciona dirección, sequence, ACK, SACK, RTT, window y tiempo de aplicación. En DNS o DHCP enlaza transaction ID, addresses e intentos; en HTTP, request y response; en TLS, dirección del handshake.

Preservar el original

Calcula checksum y conserva el original sin cambios. Filtra, recorta y redacta una working copy. Registra input, transformación, hora, packet count antes/después, checksum y motivo. Tras reescribir timestamps o eliminar packets, esa copia pierde capacidad para algunas conclusiones de tiempo o secuencia.

Sustituye addresses e identificadores de forma constante para seguir el mismo endpoint. No elimines ports, directions o lengths necesarios. Guarda aparte el mapa secreto. Revisa límites de captura y exportación y el flujo general de PCAP Surgery.

QA antes de publicar

¿Título y respuesta tratan el mismo flow? ¿Cada duración nombra reloj y puntos? ¿Está identificada la primera frontera fallida? ¿Existe explicación alternativa? ¿Se repite cambiando una variable? ¿Se conserva el original? Declara el límite: «Esta captura demuestra comportamiento junto al client durante este intervalo; no demuestra la ejecución interna del server».

Semrush no se distribuye por plantilla. El término validado PCAP analyzer pertenece solo a la página del producto; este artículo conserva su pregunta técnica y no inventa volumen ni KD.

<!-- pcap-localized-evidence-foundation-v1:end --><!-- pcap-localized-flow-verdicts-v1:start -->

Libro de flow y prueba de descarte

Para «SNI vs ALPN: análisis de protocolo de enlace TLS y negociación HTTP/2 en PCAP de Wireshark», crea una fila por dirección: endpoints con alias, primer/último packet, bytes enviados y reconocidos, resets, retransmissions, requests y responses. No mezcles conexiones por compartir hostname; source port, inicio e initial sequence separan sessions. Con NAT o proxy documenta la relación de flows sin esperar iguales sequence o ports.

Calcular TCP, no contar etiquetas

Sigue next expected sequence del receiver. El payload mueve sequence por su longitud; SYN y FIN consumen un número. Duplicate ACK estable tras segmentos superiores apoya loss o reordering. SACK blocks muestran ranges recibidos, no dónde se perdieron. Si retransmission aparece junto al sender y no junto al receiver, prueba el tramo; si falta el segmento original en sender capture, revisa capture loss u offload.

Separa fast retransmit tras duplicate ACKs de RTO tras silencio. Compara RTT previo, advertised window, zero-window probes, burst y tamaño. No cada label es pérdida independiente: overlap, spurious retransmission o captura iniciada a mitad cambian la clasificación.

Medir tiempo con fronteras

Usa request first byte, request complete, response first byte y response complete. TTFB no equivale a tiempo de server sin punto y transporte. Retransmission antes de response añade posible network delay; request reconocido y silencio largo apoya application wait. Indica valor, unidad, clock y punto.

Con dos puntos alinea un packet distintivo en ambas direcciones, estima offset y usa intervals internos. Si clock es incierto, da un range. Compara ventanas correctas y fallidas de duración y carga similares.

Preguntas por protocolo

DNS: ¿ID, nombre y tipo coinciden, y retry cambia resolver o source port? DHCP: ¿Discover, Offer, Request y ACK pertenecen al mismo client identifier? TLS: ¿último handshake message por dirección y alert visible o cifrado? HTTP: ¿quién genera 4xx/5xx y existe upstream flow? TCP close: ¿quién envía FIN/RST y qué bytes quedan sin ACK?

Prueba decisiva y entrega

Elige dos hipótesis y una prueba que las separe. Captura al otro extremo separa network loss de measurement loss; desactivar offload en test comprueba artifact; request idéntico por path fijo prueba intermittency; log upstream contra packet boundary prueba application delay. Escribe resultados esperados antes.

Acepta cuando otro reviewer repite el cálculo con metadata, encuentra la misma frontera y entiende límites. Entrega original/derived checksum, filter, packet ranges y pasos de trim/redaction. Termina con owner, acción y condición medible.

<!-- pcap-localized-flow-verdicts-v1:end -->