SNI vs ALPN: analisi dell'handshake TLS e negoziazione HTTP/2 nei PCAP Wireshark

Molti incidenti "HTTP/2 non funzionante" sono in realtà problemi di negoziazione TLS ALPN. Gli utenti cercano "TLS ALPN pcap", "HTTP2 fallback su HTTP/1.1", "ALPN h2 non negoziato", "ClientHello estensione ALPN", "ServerHello protocollo selezionato" e "perché il mio browser utilizza HTTP/1.1" quando un endpoint dovrebbe supportare HTTP/2 ma il traffico ritorna.

La chirurgia PCAP è utile perché le prove ALPN risiedono nell'handshake TLS. Se l'acquisizione include ClientHello e ServerHello, puoi spesso provare se il client ha offerto "h2", se il server lo ha selezionato, se un proxy ha terminato TLS o se la connessione non ha mai avuto la possibilità di negoziare HTTP/2.

Cosa fa l'ALPN

ALPN significa negoziazione del protocollo a livello di applicazione. Consente al client e al server di concordare un protocollo applicativo durante la configurazione TLS.

Valori ALPN comuni:

• "h2" per HTTP/2 su TLS.
• "http/1.1" per HTTP/1.1.
• Altri identificatori di protocollo per sistemi specializzati.

Se il client non offre "h2", il server non può selezionarlo. Se il server non seleziona "h2", la connessione non utilizzerà HTTP/2 anche se il server supporta HTTP/2 altrove.

Sintomi comuni

Gli errori ALPN vengono visualizzati come:

• Il browser utilizza HTTP/1.1 anziché HTTP/2.
• La connessione gRPC non riesce.
• La CDN funziona ma l'origine no.
• Il proxy inverso esegue il downgrade del protocollo.
• Il sistema di bilanciamento del carico termina TLS e inoltra HTTP/1.1.
• L'app mobile segnala un errore di protocollo.
• Le metriche del server non mostrano traffico h2.
• HTTP/2 funziona con un nome host ma non con un altro.

Questi sintomi vengono spesso sottoposti a debug a livello HTTP, ma la risposta potrebbe trovarsi nella negoziazione TLS.

Prova ClientHello

ClientHello può mostrare se il client offriva ALPN e quali protocolli pubblicizzava.

Domande utili:

• E' presente l'estensione ALPN?
• L'offerta comprende h2?
• Include anche http/1.1?
• La SNI è presente e corretta?
• Quale versione TLS viene offerta?
• L'acquisizione viene eseguita prima che un proxy termini TLS?

Se "h2" è assente da ClientHello, il server non può scegliere HTTP/2. Il motivo potrebbe essere la configurazione della libreria client, il vecchio stack TLS, l'opzione HTTP/2 disabilitata o un client proxy che apre una nuova connessione upstream.

Prova ServerHello

Il lato server dovrebbe selezionare un protocollo dall'elenco ALPN del client.

Problemi:

• Il server seleziona solo "http/1.1".
• Il server omette la risposta ALPN.
• L'handshake del server non riesce prima della selezione ALPN.
• Il certificato o la mancata corrispondenza SNI instradano verso un host virtuale predefinito.
• Il terminatore TLS supporta h2 sul lato pubblico ma non sul lato upstream.

L'evidenza dei pacchetti può separare il supporto del server dal routing e dal comportamento del proxy.

SNI e ALPN insieme

SNI e ALPN sono spesso collegati. Il nome host selezionato da SNI può determinare quali impostazioni di certificato, host virtuale e protocollo applicare.

Esempio di fallimento:

• Il cliente offre "h2".
• Il cliente invia un SNI errato.
• Il server restituisce il certificato predefinito.
• L'host virtuale predefinito non abilita HTTP/2.
• La connessione ritorna a "http/1.1".

In questo caso il problema non è "HTTP/2 danneggiato a livello globale". È il routing del nome host.

Terminazione del proxy e del bilanciamento del carico

Le distribuzioni moderne spesso dividono 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 -->

Risposta basata sui pacchetti per «SNI vs ALPN: analisi dell'handshake TLS e negoziazione HTTP/2 nei PCAP Wireshark»

La risposta diretta è che un label dell’analizzatore o un messaggio applicativo non determina la causa. Parti da punto di cattura e direzione, poi dimostra l’ultimo confine riuscito e il primo fallito. In «SNI vs ALPN: analisi dell'handshake TLS e negoziazione HTTP/2 nei PCAP Wireshark» un altro revisore deve trovare il packet, il gap o l’intervallo che sostiene ogni frase e sapere quale prova potrebbe smentirla.

Posizionare la cattura sul percorso

Registra client, server e ogni proxy, load balancer, NAT o firewall. Indica interface, luogo, clock, sistema e direzioni visibili. Una cattura presso il client prova ciò che arriva lì, non che il server non abbia inviato. Presso il server prova l’uscita in quel punto, non l’intero percorso. Prima di confrontare due punti correggi clock offset e allinea flow tuple, TCP sequence o transaction ID.

Controlla snap length, dropped packets, offload, capture filter, ring buffer e orario iniziale. Un checksum errato sul host può essere offload artifact. Un segmento grande può derivare da GRO/TSO e non esistere così sul cavo. Un packet assente da un file limitato non è network loss finché non dimostri che il punto doveva vederlo.

Leggere i confini in ordine

Confine	Prova di riuscita	Prova di guasto utile
Link e IP	direzione, address e route coerenti	ARP/NDP assente, ICMP, MTU, asimmetria
TCP	SYN, SYN-ACK, ACK e sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello e progresso	alert o confine SNI/ALPN/certificate
Applicazione	request completo e response associata	status, gap o chiusura precoce
Utente	response time o failure window	stall legato a un confine

Fermati al primo confine senza successo. Se TCP non si completa, non iniziare da HTTP. Se request arriva al proxy ma non all’upstream, il limite è nel proxy o nel percorso. Se arriva all’upstream senza response entro timeout, ACK e avanzamento dei bytes separano application delay da network loss.

Separare osservazione e ipotesi

Un’osservazione è localizzabile: “Client ha inviato fino a una sequence, sender ha ripetuto un segmento tre volte e qui non compare ACK avanzato”. L’ipotesi è “il percorso ha perso il segmento”. Un’altra cattura o dropped records possono smentirla. Per ogni ipotesi scrivi prova favorevole e prova contraria.

Retransmission e duplicate ACK non assegnano colpa. Reordering, loss, capture artifact e receiver delay generano label simili. Collega direzione, sequence, ACK, SACK, RTT, window e tempo applicativo. Per DNS/DHCP collega transaction ID, address e tentativi; per HTTP request e response; per TLS la direzione del handshake.

Preservare l’originale

Calcola checksum e conserva l’originale immutato. Filtra, taglia e oscura una working copy. Registra input, trasformazione, ora, packet count prima/dopo, checksum risultante e motivo. Dopo timestamp rewrite o rimozione di packets la copia non sostiene più alcune conclusioni temporali o di sequenza.

Sostituisci address e identificatori in modo stabile per seguire lo stesso endpoint. Non eliminare port, directions o lengths necessari. Separa la mappa segreta. Consulta limiti di cattura ed export e il flusso PCAP Surgery.

QA prima della pubblicazione

Titolo e risposta riguardano lo stesso flow? Ogni durata nomina clock e punti? Il primo confine fallito è chiaro? Esiste un’alternativa? Si cambia una variabile? L’originale è conservato? Limita la conclusione: “Questa cattura prova il comportamento presso il client nell’intervallo, non l’esecuzione interna del server”.

Il termine Semrush validato PCAP analyzer appartiene solo alla pagina prodotto. Questo articolo resta sulla domanda tecnica e non inventa volume o KD.

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

Registro del flow e test di esclusione

Per «SNI vs ALPN: analisi dell'handshake TLS e negoziazione HTTP/2 nei PCAP Wireshark» crea una riga per direzione: endpoints con alias, primo/ultimo packet, bytes inviati e confermati, reset, retransmissions, requests e responses. Non unire connessioni per lo stesso hostname; source port, inizio e initial sequence separano sessions. Con NAT o proxy documenta la relazione senza aspettare sequence o ports uguali.

Calcolare TCP invece di contare label

Segui next expected sequence del receiver. Il payload avanza sequence della sua lunghezza; SYN e FIN consumano un numero. Duplicate ACK stabile dopo segmenti superiori sostiene loss o reordering. SACK blocks mostrano ranges arrivati, non il punto di perdita. Retransmission visibile al sender ma non al receiver richiede test del tratto; originale assente al sender capture richiede controllo di capture loss o offload.

Separa fast retransmit dopo duplicate ACKs da RTO dopo silenzio. Confronta RTT precedente, advertised window, zero-window probes, burst e dimensione. Non ogni label è perdita: overlap, spurious retransmission o cattura iniziata a metà cambiano la classificazione.

Misurare il tempo con confini

Usa request first byte, request complete, response first byte e response complete. TTFB non equivale a tempo server senza punto e trasporto. Retransmission prima di response può aggiungere network delay; request confermata e lungo silenzio sostiene application wait. Scrivi valore, unità, clock e punto.

Con due punti allinea un packet distintivo nelle due direzioni, stima offset e usa intervals interni. Se clock è incerto, fornisci un range. Confronta finestre buone e guaste di durata e carico simili.

Domande di protocollo

DNS: ID, nome e tipo coincidono, retry cambia resolver o source port? DHCP: Discover, Offer, Request e ACK sono dello stesso client identifier? TLS: ultimo handshake message per direzione e alert visibile o cifrato? HTTP: chi genera 4xx/5xx e c’è upstream flow? TCP close: chi invia FIN/RST e quali bytes restano senza ACK?

Test decisivo e consegna

Scegli due ipotesi e un test che le separa. Cattura all’altro estremo separa network loss e measurement loss; disattivare offload in test verifica artifact; request identico su path fisso verifica intermittency; log upstream contro packet boundary verifica application delay. Scrivi prima gli esiti attesi.

Accetta quando un reviewer ripete il calcolo dai metadata, trova lo stesso confine e capisce i limiti. Consegna checksum original/derived, filter, packet ranges e passi trim/redaction. Chiudi con owner, azione e condizione misurabile.

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