{"id":52181,"date":"2019-11-02T00:00:00","date_gmt":"2019-11-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/http-3-razrushenie-osnov-i-divnyj-novyj-mir"},"modified":"2020-02-18T13:59:51","modified_gmt":"2020-02-18T10:59:51","slug":"http-3-razrushenie-osnov-i-divnyj-novyj-mir","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: Zerschlagung der Grundlagen und eine wundersame neue Welt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Seit mehr als 20 Jahren besuchen wir Webseiten \u00fcber das HTTP-Protokoll. Die meisten Benutzer machen sich \u00fcberhaupt keine Gedanken dar\u00fcber, was es ist und wie es funktioniert. Andere wissen, dass es irgendwo unter HTTP TLS gibt, und darunter TCP, und darunter IP und so weiter. Und die dritten \u2013 die H\u00e4retiker \u2013 glauben, dass TCP altmodisch ist und etwas Schnelleren, Zuverl\u00e4ssigeres und Sichereres wollen. Doch in ihren Versuchen, ein neues, ideales Protokoll zu erfinden, sind sie zu den Technologien der 80er Jahre zur\u00fcckgekehrt und versuchen, auf deren Basis ihre wunderbare neue Welt aufzubauen.
\n\"HTTP\/3:
\n<\/a><\/noindex><\/p>\n

Ein wenig Geschichte: HTTP\/1.1<\/h2>\n

\nIm Jahr 1997 erhielt das Protokoll f\u00fcr den Austausch von Textinformationen HTTP Version 1.1 sein RFC. Zu diesem Zeitpunkt wurde das Protokoll bereits seit mehreren Jahren von Browsern verwendet, und der neue Standard hielt noch f\u00fcnfzehn Jahre lang. Das Protokoll arbeitete ausschlie\u00dflich nach dem Prinzip von Anfrage-Antwort und war haupts\u00e4chlich f\u00fcr die \u00dcbertragung von Textinformationen gedacht.<\/p>\n

HTTP wurde entwickelt, um \u00fcber dem TCP-Protokoll zu arbeiten, das die zuverl\u00e4ssige Zustellung von Paketen an den Empf\u00e4nger garantiert. Die Funktionsweise von TCP beruht auf der Herstellung und Aufrechterhaltung einer zuverl\u00e4ssigen Verbindung zwischen Endpunkten und der Aufteilung des Datenverkehrs in Segmente. Segmente haben ihre eigene sequenzielle Nummer und Pr\u00fcfziffer. Wenn eines der Segmente nicht ankommt oder mit einer falschen Pr\u00fcfziffer ankommt, wird die \u00dcbertragung gestoppt, bis das verlorene Segment wiederhergestellt ist.<\/p>\n

In HTTP\/1.0 wurde die TCP-Verbindung nach jeder Anfrage geschlossen. Dies war \u00e4u\u00dferst verschwenderisch, da die Herstellung einer TCP-Verbindung (3-Way-Handshake) kein schneller Prozess ist. In HTTP\/1.1 wurde ein Keep-Alive-Mechanismus eingef\u00fchrt, der es erm\u00f6glicht, eine Verbindung f\u00fcr mehrere Anfragen wiederzuverwenden. Da es jedoch leicht zum Engpass werden kann, erlauben verschiedene Implementierungen von HTTP\/1.1 die Er\u00f6ffnung mehrerer TCP-Verbindungen zu einem Host. Beispielsweise sind in Chrome und in den neuesten Versionen von Firefox bis zu sechs Verbindungen zul\u00e4ssig.
\n\"HTTP\/3:
\nDie Verschl\u00fcsselung sollte ebenfalls anderen Protokollen \u00fcberlassen werden, und daf\u00fcr wurde \u00fcber TCP das TLS-Protokoll verwendet, das die Daten recht zuverl\u00e4ssig sch\u00fctzte, jedoch auch die Zeit, die zur Herstellung einer Verbindung ben\u00f6tigt wurde, weiter erh\u00f6hte. Letztendlich sah der Handshake-Prozess folgenderma\u00dfen aus:
\n \"HTTP\/3:
\nCloudflare-Illustration<\/i><\/p>\n

So hatte HTTP\/1.1 eine Reihe von Problemen:<\/p>\n