Che cosa significa HTTP/2 per un server proxy inverso?

Question

In che modo HTTP/2 influisce sull'implementazione di un server proxy? Soprattutto, ad esempio, quando un client invia una richiesta HTTP/2 a un server di contenuti che supporta solo HTTP/1.x, nel caso in cui il server proxy trasformi la richiesta HTTP/2 in richiesta HTTP/1.x prima di indirizzare la richiesta del client a il server dei contenuti? E dopo aver ricevuto risposta dal server di contenuti, il server proxy dovrebbe trasformare la risposta nel formato HTTP/2 prima di inviarlo al client?

Answer 1

Sì, è esattamente come dici tu. Per un'analisi leggermente più profonda, check this post. In breve, la conversione da HTTP/2 a HTTP/1.1 deve avvenire in una direzione e da HTTP/1.1 a HTTP/2 deve avvenire nell'altro caso. In pratica, ciò significa che sebbene HTTP/2 il protocollo non abbia bisogno di un parser tradizionale basato su testo, un server HTTP/2 completo necessita di un parser HTTP/1.1, non solo per lavorare con client che sono HTTP/1.1 solo (tra questi crawler) ma anche per parlare con applicazioni interne.

L'utilizzo di uno dei più importanti protocolli di applicazione è FastCGI. FastCGI richiede anche l'analisi di risposte HTTP/1.1 dall'applicazione e la conversione in risposte HTTP/2 al client.

Answer 2

Come è stato discusso, la vostra comprensione è corretta. Tuttavia, ho pensato che valesse la pena sottolineare che ci sono ancora enormi vantaggi per HTTP/2 alla tua connessione edge (cioè il tuo reverse proxy) come i problemi risolti da HTTP/2 (principalmente latenza) sono meno di un problema rispetto al solito hop più breve, in genere con larghezza di banda elevata, dal proxy inverso al server dei contenuti.

Ad esempio se si dispone di un ritardo di 100 ms sul proxy inverso sul bordo e solo 1 ms di ritardo tra il proxy inverso e il server di contenuto, allora il server di contenuti sta comunicando HTTP/1.1 al server proxy probabilmente vinto " Ho un grande impatto sulle prestazioni grazie alla latenza estremamente veloce di 1 ms. Quindi il client finale (che parla HTTP/2 al proxy inverso) vede ancora una prestazione enorme su HTTP/1.1.