Quick UDP Internet Connections: Unterschied zwischen den Versionen

Aus Foxwiki
K Textersetzung - „Kryptografies“ durch „Kryptografie“
 
(34 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
'''Quick UDP Internet Connections''' (QUIC) - auf UDP aufbauendes, zuverlässiges, verbindungsorientiertes und verschlüsseltes Netzwerkprotokoll auf Transportschicht
 
== Beschreibung ==
== Beschreibung ==
'''QUIC''' ist ein auf dem [[User Datagram Protocol]] (UDP) aufbauendes [[Zuverlässigkeit (Telekommunikation)|zuverlässiges]], [[Nachrichtenverbindung|verbindungsorientiertes]] und [[Kryptografiesprotokoll|verschlüsseltes]] [[Netzwerkprotokoll]] auf [[Transportschicht]].
* [[Netzwerkprotokoll]]  
* Es integriert [[Transport Layer Security]] (TLS) zur [[Kryptografie|kryptographischen]] Absicherung der Kommunikation und verfolgt das Ziel, eine höhere Performanz als das [[Transmission Control Protocol]] (TCP) zu bieten.
* [[Transportschicht]]
* QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet.
* nutzt [[User Datagram Protocol]] (UDP)
* [[Zuverlässigkeit (Telekommunikation)|zuverlässig]]
* [[Nachrichtenverbindung|verbindungsorientiert]]
* [[Kryptografieprotokoll|verschlüsselt]]


Familie = [[Internetprotokollfamilie]]
; Integriert [[Transport Layer Security]] (TLS)
  Einsatzfeld = Zuverlässiger und verschlüsselter bidirektionaler Datentransport
* zur [[Kryptografie|kryptographischen]] Absicherung der Kommunikation und verfolgt das Ziel, eine höhere Performanz als das [[Transmission Control Protocol]] (TCP) zu bieten.
aufbauend auf = [[User Datagram Protocol|UDP]]
* QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet
Einführung = Mai 2021
entwickelt aus = [[SPDY]]
Entwickler = [[Google LLC]], [[Internet Engineering Task Force|IETF]]


{| {{{2|class="float-right"}}} cellspacing="3"
{| {{{2|class="float"}}} cellspacing="3"
|+ QUIC im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]]:
|+ QUIC im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]]:
|- style="background:#DDDDFF;"
|- style="background:#DDDDFF;"
Zeile 37: Zeile 38:
|}
|}


; Entwicklung
; Ursprünglich von Google entwickelt
QUIC wurde ursprünglich von der Firma [[Google Inc.]] entwickelt.
* Der Name stand ursprünglich als Akronym für {{EnS|'''''Q'''uick '''U'''DP '''I'''nternet '''C'''onnections''}}, wird jedoch in diesem Zusammenhang nicht mehr verwendet.  
* Der Name stand ursprünglich als Akronym für {{EnS|'''''Q'''uick '''U'''DP '''I'''nternet '''C'''onnections''}}, wird jedoch in diesem Zusammenhang nicht mehr verwendet.  
* Seit Februar 2017 arbeitete die [[Internet Engineering Task Force]] (IETF) an einer Standardisierung des QUIC-Protokolles.  
* Seit Februar 2017 arbeitete die [[Internet Engineering Task Force]] (IETF) an einer Standardisierung des QUIC-Protokolles.  
* Der Standard wurde im Mai 2021 als RFC 8999, RFC 9000, RFC 9001 und RFC 9002 veröffentlicht.
* Der Standard wurde im Mai 2021 als RFC 8999, RFC 9000, RFC 9001 und RFC 9002 veröffentlicht.
Familie = [[Internetprotokolle]]
Einsatzfeld = Zuverlässiger und verschlüsselter bidirektionaler Datentransport
aufbauend auf = [[User Datagram Protocol|UDP]]
Einführung = Mai 2021
entwickelt aus = [[SPDY]]
Entwickler = [[Google LLC]], [[Internet Engineering Task Force|IETF]]
== Quick UDP Internet Connections ==
=== HTTP im Vergleich mit dem QUIC-Protokoll ===
; HTTP stützt sich auf das [[Transmission Control Protocol]] (TCP).
* TCP bestätigt den Erhalt jedes Datenpakets.
* Dies führt dazu, dass im Falle eines Paketverlustes alle anderen Pakete auf die erneute Übertragung des verloren gegangenen warten müssen, wenn der Empfängercache überläuft (''Head-of-Line Blocking''<ref>{{Internetquelle |url=https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-http/ |titel=Was ist HTTP? |abruf=2021-03-25 |sprache=de}}</ref>)
; Schnelleres Versenden von Datenpaketen
Das [[Quick UDP Internet Connections|QUIC-Protokoll]] soll in seiner Gesamtheit ein schnelleres Versenden von Datenpaketen über das verbindungslose [[User Datagram Protocol|UDP]] ermöglichen.
* Funktionen, die UDP fehlen – wie beispielsweise Empfangsbestätigungen – müssen vom übergeordneten Protokoll bereitgestellt werden.
; QUIC regelt die Verbindungskontrolle selbst
* Sender und Empfänger tauschen bei einer Datenverbindung lediglich beim ersten Handshake das Zertifikat und den Schlüssel aus, wodurch sich die Latenz verringert.
* Bei weiteren Sendevorgängen „erinnert“ sich QUIC an die in der Vergangenheit bestehende Verbindung und greift auf die gespeicherten Daten zu.
; Kryptografieprotokoll
* Als Kryptografieprotokoll wird aktuell die [[Transport Layer Security|TLS]] Version 1.3 verwendet.
* Im QUIC-Protokoll besteht außerdem die Möglichkeit des ''[[Multiplexverfahren|Multiplexing]]''.
* Dabei können über eine Client-Server-Verbindung mehrere Datenströme gleichzeitig übertragen werden, was die Ladezeit nochmals deutlich reduziert.


== Hintergrund und Eigenschaften ==
== Hintergrund und Eigenschaften ==
[[Datei:Tcp-vs-quic-handshake.svg|mini|500px|Verbindungsaufbau von QUIC im Vergleich zu TCP mit TLS1.2]]
[[Datei:Tcp-vs-quic-handshake.svg|mini|500px|Verbindungsaufbau von QUIC im Vergleich zu TCP mit TLS1.2]]


Als Weiterentwicklung von [[HTTP]] hat Google bereits das Protokoll [[SPDY]] ausgearbeitet, dessen Neuerungen aber aufgrund von Beschränkungen des darunterliegenden [[Transmission Control Protocol]] nicht in vollem Umfang genutzt werden können.  
; Als Weiterentwicklung von [[HTTP]] hat Google bereits das Protokoll [[SPDY]] ausgearbeitet
* dessen Neuerungen aber aufgrund von Beschränkungen des darunterliegenden [[Transmission Control Protocol]] nicht in vollem Umfang genutzt werden können.  
* Diese Beschränkungen soll das auf [[User Datagram Protocol|UDP]] basierende QUIC aufheben.
* Diese Beschränkungen soll das auf [[User Datagram Protocol|UDP]] basierende QUIC aufheben.
* Die ursprüngliche Form von QUIC wurde von Google am 20. Juli 2016 zur Standardisierung eingebracht.
* QUIC schreibt vor, dass die gesendeten Daten mit [[Transport Layer Security|TLS]] 1.3 verschlüsselt übertragen werden.


Die ursprüngliche Form von QUIC wurde von Google am 20. Juli 2016 zur Standardisierung eingebracht.
; Es kommen zwei unterschiedliche Header zum Einsatz
 
QUIC schreibt vor, dass die gesendeten Daten mit [[Transport Layer Security|TLS]] 1.3 verschlüsselt übertragen werden.
 
Es kommen zwei unterschiedliche Header zum Einsatz.
* Der erste Header enthält mehr Informationen und dient dem Verbindungsaufbau.  
* Der erste Header enthält mehr Informationen und dient dem Verbindungsaufbau.  
* Sobald die Verbindung hergestellt wurde, wird der kürzere Header verwendet.  
* Sobald die Verbindung hergestellt wurde, wird der kürzere Header verwendet.  
Zeile 60: Zeile 85:
* Hierdurch wird einerseits die Privatsphäre der Nutzer besser gewahrt, aber anderseits das Netzwerk-Monitoring und -Management erschwert.
* Hierdurch wird einerseits die Privatsphäre der Nutzer besser gewahrt, aber anderseits das Netzwerk-Monitoring und -Management erschwert.


QUIC bietet höherliegenden Schichten [[Multiplexverfahren|gemultiplexte]] Verbindungen an, so dass mehrere Datenströme unabhängig voneinander empfangen und gesendet werden können.  
; QUIC bietet höherliegenden Schichten [[Multiplexverfahren|gemultiplexte]] Verbindungen
* so dass mehrere Datenströme unabhängig voneinander empfangen und gesendet werden können.  
* Dies kann von [[HTTP/2]] genutzt werden, [[HTTP/3]] wird sogar immer über QUIC genutzt.  
* Dies kann von [[HTTP/2]] genutzt werden, [[HTTP/3]] wird sogar immer über QUIC genutzt.  
* Im Gegensatz dazu kann es bei Multiplexing über [[Transmission Control Protocol|TCP]] zu Verzögerungen auf Grund von [[Head-of-Line-Blocking]] aller gemultiplexten Streams kommen, wenn eines der TCP-Pakete verzögert wird oder verloren geht.
* Im Gegensatz dazu kann es bei Multiplexing über [[Transmission Control Protocol|TCP]] zu Verzögerungen auf Grund von [[Head-of-Line-Blocking]] aller gemultiplexten Streams kommen, wenn eines der TCP-Pakete verzögert wird oder verloren geht.


; Weiteren Ziele
Zu den weiteren Zielen von QUIC gehören eine reduzierte [[Verbindungsaufbau|Verbindungs]]- und [[Paketumlaufzeit|Transportlatenz]] sowie eine Geschwindigkeitsabschätzung in beide Richtungen, um Überlastungen zu vermeiden.  
Zu den weiteren Zielen von QUIC gehören eine reduzierte [[Verbindungsaufbau|Verbindungs]]- und [[Paketumlaufzeit|Transportlatenz]] sowie eine Geschwindigkeitsabschätzung in beide Richtungen, um Überlastungen zu vermeiden.  
* Außerdem werden die Algorithmen zur [[Network congestion avoidance|Staukontrolle]] an beiden Endpunkten in den [[User-Space]] (anstatt Kernel-Space) verlagert, was eine schnellere Verbesserung dieser Algorithmen ermöglichen soll.  
* Außerdem werden die Algorithmen zur [[Network congestion avoidance|Staukontrolle]] an beiden Endpunkten in den [[User-Space]] (anstatt Kernel-Space) verlagert, was eine schnellere Verbesserung dieser Algorithmen ermöglichen soll.  
Zeile 69: Zeile 96:


Seit Anfang 2021 sind die grundlegenden Protokollspezifikationen von QUICv1 standardisiert.  
Seit Anfang 2021 sind die grundlegenden Protokollspezifikationen von QUICv1 standardisiert.  
* Zu den wichtigsten weiterhin diskutierten vielfältigen Erweiterungen gehört Multipath, also – analog zu [[Multipath TCP]] (MPTCP) – der parallele Verbindungsaufbau zwischen Endgeräten und einem netzseitigen Server über mehrere (z.&nbsp;B. leitungsgebundene und drahtlose) Pfade.
* Zu den wichtigsten weiterhin diskutierten vielfältigen Erweiterungen gehört Multipath, also – analog zu [[Multipath TCP]] (MPTCP) – der parallele Verbindungsaufbau zwischen Endgeräten und einem netzseitigen Server über mehrere (z.&nbsp;B.&nbsp;leitungsgebundene und drahtlose) Pfade.


== Unterstützung ==
== Unterstützung ==
QUIC muss von der Anwendung unterstützt werden.
; QUIC muss von der Anwendung unterstützt werden
* Der erste Browser, der clientseitig QUIC unterstützt, war [[Google Chrome]] ab Version 29.
* Der erste Browser, der clientseitig QUIC unterstützt, war [[Google Chrome]] ab Version 29


Beispielimplementierungen für Client und Server finden sich im [[Repository]] von Chromium.
; Beispielimplementierungen für Client und Server finden sich im [[Repository]] von Chromium
* Hierbei handelt es sich allerdings noch um die ursprünglich von Google implementierte Variante.
* Hierbei handelt es sich allerdings noch um die ursprünglich von Google implementierte Variante
* Ab Version 72 hat auch [[Firefox]] experimentelle Unterstützung für die vom IETF entwickelte Version implementiert.
* Ab Version 72 hat auch [[Firefox]] experimentelle Unterstützung für die vom IETF entwickelte Version implementiert


Im Oktober 2020 gab Facebook bekannt, dass es sowohl seine Apps auf Android und iOS als auch seine Server-Infrastruktur auf QUIC umgestellt habe und mittlerweile 75 % seines Internet-Datenverkehrs darüber erfolge.  
Im Oktober 2020 gab Facebook bekannt, dass es sowohl seine Apps auf Android und iOS als auch seine Server-Infrastruktur auf QUIC umgestellt habe und mittlerweile 75 % seines Internet-Datenverkehrs darüber erfolge.  
Zeile 84: Zeile 111:
== Anhang ==
== Anhang ==
=== Siehe auch ===
=== Siehe auch ===
 
{{Special:PrefixIndex/Quick UDP Internet Connections}}
==== Unterseiten ====
{{Special:PrefixIndex/QUIC}}


==== Sicherheit ====
==== Sicherheit ====
Zeile 92: Zeile 117:


===== RFC =====
===== RFC =====
{| class="wikitable float-right"
{| class="wikitable options"
|-
|-
| colspan="2" style="text-align: center;" class="hintergrundfarbe6"| Internet-Standards
! RFC !! Beschreibung
|-
|-
| RFC 8999
| RFC 8999 || Versionsunabhängige Eigenschaften
| Versionsunabhängige Eigenschaften
|-
|-
| RFC 9000
| RFC 9000 || Hauptdefinition
| Hauptdefinition
|-
|-
| RFC 9001
| RFC 9001 || Benutzung von [[Transport Layer Security|TLS]]
| Benutzung von [[Transport Layer Security|TLS]]
|-
|-
| RFC 9002
| RFC 9002 || [[Paketverlust|Verlusterkennung]] und [[Datenflusssteuerung|Staukontrolle]]
| [[Paketverlust|Verlusterkennung]] und [[Datenflusssteuerung|Staukontrolle]]
|}
|}


Zeile 119: Zeile 140:


===== Weblinks =====
===== Weblinks =====
# https://de.wikipedia.org/wiki/QUIC
# [https://http3-explained.haxx.se/ HTTP/3 explained] freies und offenes Buch über http/3 und QUIC in verschiedenen Sprachen
# [https://http3-explained.haxx.se/ HTTP/3 explained] freies und offenes Buch über http/3 und QUIC in verschiedenen Sprachen
# [https://www.sueddeutsche.de/digital/internet-schneller-google-tcp-protokoll-verschluesselung-1.5171790 Revolution in den Tiefen des Internets]
# [https://www.sueddeutsche.de/digital/internet-schneller-google-tcp-protokoll-verschluesselung-1.5171790 Revolution in den Tiefen des Internets]


<noinclude>
<noinclude>
=== Testfragen ===
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>


[[Kategorie:Netzwerk/Protokoll (Transportschicht)]]
[[Kategorie:QUIC]]
[[Kategorie:Kryptografiesprotokoll]]
[[Kategorie:Transport Layer Security]]
[[Kategorie:Abkürzung]]


</noinclude>
</noinclude>

Aktuelle Version vom 27. Juli 2024, 10:35 Uhr

Quick UDP Internet Connections (QUIC) - auf UDP aufbauendes, zuverlässiges, verbindungsorientiertes und verschlüsseltes Netzwerkprotokoll auf Transportschicht

Beschreibung

Integriert Transport Layer Security (TLS)
QUIC im TCP/IP-Protokollstapel:
Anwendung HTTP/3 DNS over QUIC
Transport QUIC
Transport UDP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus
Token
Ring
FDDI
Ursprünglich von Google entwickelt
  • Der Name stand ursprünglich als Akronym für , wird jedoch in diesem Zusammenhang nicht mehr verwendet.
  • Seit Februar 2017 arbeitete die Internet Engineering Task Force (IETF) an einer Standardisierung des QUIC-Protokolles.
  • Der Standard wurde im Mai 2021 als RFC 8999, RFC 9000, RFC 9001 und RFC 9002 veröffentlicht.
Familie = Internetprotokolle
Einsatzfeld = Zuverlässiger und verschlüsselter bidirektionaler Datentransport
aufbauend auf = UDP
Einführung = Mai 2021
entwickelt aus = SPDY
Entwickler = Google LLC, IETF

Quick UDP Internet Connections

HTTP im Vergleich mit dem QUIC-Protokoll

HTTP stützt sich auf das Transmission Control Protocol (TCP).
  • TCP bestätigt den Erhalt jedes Datenpakets.
  • Dies führt dazu, dass im Falle eines Paketverlustes alle anderen Pakete auf die erneute Übertragung des verloren gegangenen warten müssen, wenn der Empfängercache überläuft (Head-of-Line Blocking[1])
Schnelleres Versenden von Datenpaketen

Das QUIC-Protokoll soll in seiner Gesamtheit ein schnelleres Versenden von Datenpaketen über das verbindungslose UDP ermöglichen.

  • Funktionen, die UDP fehlen – wie beispielsweise Empfangsbestätigungen – müssen vom übergeordneten Protokoll bereitgestellt werden.
QUIC regelt die Verbindungskontrolle selbst
  • Sender und Empfänger tauschen bei einer Datenverbindung lediglich beim ersten Handshake das Zertifikat und den Schlüssel aus, wodurch sich die Latenz verringert.
  • Bei weiteren Sendevorgängen „erinnert“ sich QUIC an die in der Vergangenheit bestehende Verbindung und greift auf die gespeicherten Daten zu.
Kryptografieprotokoll
  • Als Kryptografieprotokoll wird aktuell die TLS Version 1.3 verwendet.
  • Im QUIC-Protokoll besteht außerdem die Möglichkeit des Multiplexing.
  • Dabei können über eine Client-Server-Verbindung mehrere Datenströme gleichzeitig übertragen werden, was die Ladezeit nochmals deutlich reduziert.

Hintergrund und Eigenschaften

Verbindungsaufbau von QUIC im Vergleich zu TCP mit TLS1.2
Als Weiterentwicklung von HTTP hat Google bereits das Protokoll SPDY ausgearbeitet
  • dessen Neuerungen aber aufgrund von Beschränkungen des darunterliegenden Transmission Control Protocol nicht in vollem Umfang genutzt werden können.
  • Diese Beschränkungen soll das auf UDP basierende QUIC aufheben.
  • Die ursprüngliche Form von QUIC wurde von Google am 20. Juli 2016 zur Standardisierung eingebracht.
  • QUIC schreibt vor, dass die gesendeten Daten mit TLS 1.3 verschlüsselt übertragen werden.
Es kommen zwei unterschiedliche Header zum Einsatz
  • Der erste Header enthält mehr Informationen und dient dem Verbindungsaufbau.
  • Sobald die Verbindung hergestellt wurde, wird der kürzere Header verwendet.
  • Bei einem bekannten Host wird die Kryptografie bei einer erneuten Verbindungsherstellung zudem nicht neu ausgehandelt, sondern ab dem ersten Paket verschlüsselt übertragen.
  • Da der Header zu einem großen Teil verschlüsselt wird, sind – im Vergleich zu älteren Protokollen – weniger Metadaten aus dem Header auslesbar.
  • Hierdurch wird einerseits die Privatsphäre der Nutzer besser gewahrt, aber anderseits das Netzwerk-Monitoring und -Management erschwert.
QUIC bietet höherliegenden Schichten gemultiplexte Verbindungen
  • so dass mehrere Datenströme unabhängig voneinander empfangen und gesendet werden können.
  • Dies kann von HTTP/2 genutzt werden, HTTP/3 wird sogar immer über QUIC genutzt.
  • Im Gegensatz dazu kann es bei Multiplexing über TCP zu Verzögerungen auf Grund von Head-of-Line-Blocking aller gemultiplexten Streams kommen, wenn eines der TCP-Pakete verzögert wird oder verloren geht.
Weiteren Ziele

Zu den weiteren Zielen von QUIC gehören eine reduzierte Verbindungs- und Transportlatenz sowie eine Geschwindigkeitsabschätzung in beide Richtungen, um Überlastungen zu vermeiden.

  • Außerdem werden die Algorithmen zur Staukontrolle an beiden Endpunkten in den User-Space (anstatt Kernel-Space) verlagert, was eine schnellere Verbesserung dieser Algorithmen ermöglichen soll.
  • Zusätzlich kann das Protokoll mit einer Vorwärtsfehlerkorrektur (FEC) versehen werden, um die Leistung bei zu erwartenden Fehlern weiter zu verbessern, was als nächster Schritt in der Evolution des Protokolls angesehen wird.

Seit Anfang 2021 sind die grundlegenden Protokollspezifikationen von QUICv1 standardisiert.

  • Zu den wichtigsten weiterhin diskutierten vielfältigen Erweiterungen gehört Multipath, also – analog zu Multipath TCP (MPTCP) – der parallele Verbindungsaufbau zwischen Endgeräten und einem netzseitigen Server über mehrere (z. B. leitungsgebundene und drahtlose) Pfade.

Unterstützung

QUIC muss von der Anwendung unterstützt werden
  • Der erste Browser, der clientseitig QUIC unterstützt, war Google Chrome ab Version 29
Beispielimplementierungen für Client und Server finden sich im Repository von Chromium
  • Hierbei handelt es sich allerdings noch um die ursprünglich von Google implementierte Variante
  • Ab Version 72 hat auch Firefox experimentelle Unterstützung für die vom IETF entwickelte Version implementiert

Im Oktober 2020 gab Facebook bekannt, dass es sowohl seine Apps auf Android und iOS als auch seine Server-Infrastruktur auf QUIC umgestellt habe und mittlerweile 75 % seines Internet-Datenverkehrs darüber erfolge.

  • Für die Benutzer ergäben sich daraus eindeutig messbare Verbesserungen u. a. hinsichtlich Fehlerraten und Latenzzeiten.

Anhang

Siehe auch

Sicherheit

Dokumentation

RFC
RFC Beschreibung
RFC 8999 Versionsunabhängige Eigenschaften
RFC 9000 Hauptdefinition
RFC 9001 Benutzung von TLS
RFC 9002 Verlusterkennung und Staukontrolle
Man-Pages
Info-Pages

Links

Einzelnachweise
Projekt
Weblinks
  1. https://de.wikipedia.org/wiki/QUIC
  2. HTTP/3 explained freies und offenes Buch über http/3 und QUIC in verschiedenen Sprachen
  3. Revolution in den Tiefen des Internets