Was passiert, wenn ein HTTP/1.1-Client mit einem HTTP/2-Server kommuniziert und was passiert, wenn ein HTTP/2-Client mit einem HTTP/1.1-Server kommuniziert?

Question

HTTP/2 ist definitiv der Trend der Zukunft, weil es jetzt der Standard des HTTP-Protokolls ist. Wie wir in Can I use sehen können, unterstützen 70,15 Prozent der Browser das HTTP/2. Aber HTTP/2 ist so neu, dass es Browser gibt, die nur HTTP/1.x unterstützen, und es gibt viele Server, die nur HTTP/1.x unterstützen. Ich wusste, dass ein Client den HTTP-Aktualisierungsmechanismus verwenden kann, um ein geeignetes Protokoll für die Kommunikation mit dem Server auszuhandeln. Wenn der Server beispielsweise HTTP/2 unterstützt, wechselt das Kommunikationsprotokoll zu HTTP/2, andernfalls wird HTTP/1.x verwendet. Aber das gilt nur für die Beziehung, in der der Browser die verwendeten Clients sowohl HTTP/2 als auch HTTP/1.x unterstützt, oder?

Aber was passiert, wenn ein Benutzer in einem Browser, der nur HTTP/1.x unterstützt, mit einem HTTP/2-Server kommunizieren möchte? Wird der Server die Anfrage ignorieren oder einen Fehler an den Benutzer zurücksenden?

Und was ist, wenn ein Benutzer auf einem Browser, der nur HTTP/2 unterstützt, mit HTTP/1.1 nur Server kommunizieren möchte? Ich denke, der Prozess könnte so gehen: Der Benutzer sendet eine Verbindung Vorwort an den Server, der Server kann die Anfrage nicht erkennen, so dass der Benutzer eine Verbindung Fehlermeldung erhalten. Ist das richtig?

Oder gibt es einen Browser, der nur HTTP/2 unterstützt?

Answer 1

Wenn ein Browser nur HTTP/1.1 unterstützt und der Server nur HTTP/2 unterstützt, können sie nicht kommunizieren. Der Server erkennt nicht, was der Client sendet (insbesondere gibt es kein Verbindungsvorwort, das der Server gemäß der Spezifikation als Verbindungsfehler behandelt) und schließt die Verbindung.

"Ein Browser, der nur HTTP/2 unterstützt" existiert nicht; Wenn sie HTTP/2 unterstützen, unterstützen sie auch HTTP/1.1. Aber nehmen wir an, dass ein solcher Browser existiert.

In diesem letzteren Fall wird der Server das Verbindungsvorwort sehen und die Methode PRI nicht erkennen. Was genau der Server in diesem Fall macht, hängt vom Server ab. Es kann eine 400 Bad Request zurückgeben, oder vielleicht nur die Verbindung schließen, oder es kann einen internen Serverfehler auslösen.

Answer 2

Es ist wichtig zu berücksichtigen, dass die meisten Implementierungen von HTTP/2 es über TLS 1.2 mit ALPN-Protokoll (Application Layer Protocol Negotiation) verwenden. Somit startet der Client einfach die Standard-TLS-Verbindung. Als Teil dieser Kommunikation sendet der Client „Client Hallo“ an den Server mit einigen Informationen:

Es ist wie:.. „Hallo, Tom Es ist Bob Ich spreche Deutsch, Russisch und Englisch Lassen Sie uns reden ein bisschen". Und der Server senden "Server Hallo":

"Hallo, Bob Ich schlage vor, Deutsch oder Englisch zu sprechen". Dann, eines der Client senden mehr kurze Nachricht „OK, dann lassen Sie uns Deutsch sprechen“, und er anfangen, Deutsch zu sprechen, ohne den Server einer Antwort zu warten:

Die gesamte Kommunikation sieht aus wie auf dem Bild unten

Da sowohl der Client als auch der Server die Kommunikation starten, mit nur 1.2 TLS, die die beiden kennen.Sie starten die Hauptkommunikation nach der Protokollaushandlung. Das Problem, das Sie beschreiben, könnte also in der Praxis nicht existieren.