Alle gängigen Netzwerkprotokolle ab der vierten Schicht des TCP/IP-Modells finden ihre Implementierung im Kernel des Betriebssystems (Kernel Space). Dieses Vorgehen wird gewählt, um bei der Menge an Netzwerkpaketen eine schnelle und effiziente Verarbeitung zu gewährleisten. Auf der anderen Seite gibt es den User Space dem die Protokolle aus der Applikations-Schicht zugeordnet sind. Dieser Beitrag soll die Unterschiede beider Bereiche herausstellen und am Beispiel von QUIC die Vorteile einer Implementierung im User Space beleuchten.
Der Kernel
Bei dem Kernel handelt es sich um die Komponente eines Betriebssystems, die den grundlegenden Zugriff auf die Hardware ermöglicht. Zu den Aufgaben des Kernels zählen die Verwaltung des Speichers, die Auswahl einer Ausführungsreihenfolge von Prozessen auf dem Prozessor (Scheduling), das Handling von Interrupts, die Bereitstellung einer Interprozesskommunikation, sowie die Verwaltung weiterer Services wie z.B. die Netzwerkkommunikation. Es gibt sicherlich viele weitere Bereiche in denen der Kernel tätig ist, jedoch soll es erstmal bei diesen Ausblick bleiben.
Dieser vollständige Zugriff auf die Hardware des Computers birgt die Gefahr, dass bei falscher Verwendung, z.B. das ständige Beschreiben des gleichen Speicherblocks auf einer SSD, es zu irrevesiblen Schäden kommen kann. Die Auslieferung des Kernels durch die Entwickler des Betriebssystems stellt sicher, dass wirklich nur privilegierte Anwendungen direkt auf die Hardware zugreifen können.
Kernel und User Space
Die Trennung des privilegierten Systemzustands inklusive eines geschützten Speicherbereiches vom Rest des Systems, erlaubt auch weniger vertrauenswürdigen Anwendungen eine Ausführung auf dem Computersystem. Ersteres wird als Kernel Space bezeichnet, während die Umgebung der Anwendungen den User Space darstellt. Ohne Zugriff auf den Kernel, um beispielsweise Dateien zu erstellen oder zu editieren, sind jedoch die User-Space-Anwendungen nutzlos. System Calls stellen daher einen Mechanismus dar, die es den Anwendungen aus dem User Space ermöglichen, über vordefinierte Funktionen auf den Kernel zuzugreifen. Die nachstehende Abbildung veranschaulicht den Ablauf eines System Calls:
Angenommen ein Programm möchte eine Datei lesen. Dazu führt das Programm den System Call read() aus. Es folgt ein Kontextwechsel vom User Space in den Kernel Space, der dem Programm ab diesen Zeitpunkt die Kontrolle entzieht. Die erforderlichen Daten werden vom Speicher gelesen und nach einem Wechsel zurück in den User Space dem Programm zur Verfügung gestellt. Ein simpler, aber effektiver Mechanismus.
Das Problem an dieser Sache ist, dass die Kontextwechsel immer mit zusätzlichen CPU-Zyklen und damit einem Performanceverlust behaftet sind. Bei vielen Zugriffen auf die Kernel-Funktionen, wie es beim Netzwerk mit dem Senden und Empfangen von Paketen der Fall ist, kommt ein gewisser Overhead zustande. Nicht zuletzt deshalb wurde für den Linux Kernel im Jahr 2015 vorgeschlagen den Teil der symmetrischen Ver- und Entschlüsselung des Verschlüsselungsprotokoll TLS in den Kernel Space zu verschieben (siehe LWN). Im Linux Kernel 4.13 ist dieses Kernel TLS (KTLS) dann auch eingeflossen (siehe Heise).
QUIC User Space Motivation
Was sind die Gründe dafür ein Transportprotokoll wie QUIC im User Space zu implementieren, wo doch selbst im TCP/IP-Modell höher angesiedelte Protokolle bereits zum Teil im Kernel implementiert werden (siehe KTLS darüber)? Es folgt eine Auflistung der Vorteile aus inklusive eigener Ergänzungen:
Einsatz moderner Softwareentwicklungsmethodiken
Durch Unit- und Ende-zu-Ende-Tests wird es den Entwicklern ermöglicht schnell und ohne viel Aufwand Fehler im Code auszumachen, die unter den beschränkten Möglichkeiten des Kernel Spaces womöglich zu spät entdeckt worden wären. Dies resultiert letztendlich in einer höheren Robustheit der Software.
Erweitertes Logging
Ein Nachteil am Kernel Space ist, dass Applikationen unter einer strengeren Speicherbeschränkung stehen, als im User Space. Für QUIC konnten die Entwickler deshalb auf ein erweitertes Logging in Verbindung mit einer Server-Logging-Infrastruktur zurückgreifen. Das erweiterte Logging hat bereits dazu geführt, dass ein Jahrzehnt alter Bug in der Congestion Control Cubic aufgedeckt werden konnte, wodurch die Performance von QUIC deutlich erhöht wurde.
Unabhängigkeit vom Betriebssystem
Dieser Punkt gilt als der wahrscheinlich wichtigste Vorteil - die Unabhängigkeit vom Betriebssystem (weiter mit OS abgekürzt). Neue OS-Versionen werden meist in einem mehrjährigen Zyklus veröffentlicht und unterstehen der vollständigen Kontrolle der Entwickler des OS. Dies erschwert das Einspielen neuer Applikationsversionen und erfordert bei einem neuen Protokoll, wie QUIC, die Motivation und Bereitschaft bei den Beteiligten des OS überhaupt ein neues Protokoll zu integrieren.
Mit der Kopplung am OS werden auch die Nachteile einer langsamen und geringen Ausbreitung neuer Versionen mitgenommen. Das Einspielen neuer Updates für wichtige Sicherheitslücken oder neue Funktionen ist auf den Update- oder Realease-Zyklus des OS beschränkt. Auch kann niemand garantieren, dass das Update sofort bei einer breiten Masse an Computern ankommt, womit man dem Problem der Fragmentierung gegenübersteht.
Durch die Integrierung von QUIC im open source Webbrowser-Projekt Chromium, welcher auch vom weit genutzten Chrome verwendet wird, können die Entwickler auf einen vollkommen unabhängigen und iterativen Entwicklungsprozess für QUIC setzen. Die Bereitstellung von Chrome und Chromium über die gängigsten OS hinweg erreicht bei einem Update von QUIC wesentlich mehr Nutzer, als es bei einem einzigen OS der Fall wäre. Besonders bei Sicherheitslücken ist das eine Eigenschaft von großem Vorteil.
Negative Auswirkungen der User-Space-Implementierung
Auch wenn bei der Entwicklung von QUIC der Fokus auf eine schnelle Entwicklung gelegt wurde, darf der Aspekt des Overheads durch die Kontextwechsel zwischen User und Kernel Space nicht ignoriert werden. In Messungen aus wurde im Vergleich zu einem Protokollstack bestehend aus TLS und TCP eine 3,5 mal höhere CPU-Auslastung beobachtet. Nach der Durchführung von Optimierungen konnte die Auslastung auf das 2-fache gesenkt werden.
Als mögliche Lösung des Problems wurde in die Nutzung des Frameworks netmap aufgeführt. Dieses Framework ermöglicht User-Space-Applikationen einen schnellen Zugriff auf Netzwerkpakete in dem es den Overhead der durch Speicherallokation, System Calls und der Kopie von Speicherinhalten entsteht, reduziert oder gar beseitigt. In Messungen des Netmap-Papers konnte der Transport eines Netzwerkpakets vom Kabel bis zur User-Space-Anwendung um mindestens eine Größenordnung beschleunigt werden.
Fazit
Die Implementierung von Anwendungen hat sowohl im Kernel als auch im User Space ihre Vor- und Nachteile. Der Kernel Space bietet die bessere Performance, schränkt jedoch dafür die Entwicklungsmöglichkeiten ein und ist vom OS abhängig, während es beim User Space anders herum ist. Der Schritt QUIC im User Space zu implementieren stellt sich vor dem Hintergrund einer schnellen Entwicklung, als ein gewagter aber sinnvoller Weg dar. Mit dem Netmap-Framework wurde außerdem eine Lösung vorgestellt, die die Performancenachteile durch den Kontextwechsel drastisch reduzieren kann. Es bleibt abzuwarten, ob eine Umsetzung des Netmap-Frameworks in Zukunft geplant ist. Falls doch, so würde dem weltweiten Einsatz von QUIC kaum noch etwas entgegenstehen.