Fragen? Antworten! Siehe auch: Alternativlos
Die gibt er dann mit einem magischen setsockopt dem Kernel, und dann kann man mit dem Socket einfach wie früher read, write und sendfile machen und der Kernel übernimmt die symmetrische Krypto und die TLS-Paketierung.
Warum würde man das machen wollen? Nun, es gibt zwei Gründe. Erstens kann man so wieder sendfile machen. sendfile kriegt einen Socket, einen File Descriptor, ein Offset und eine Länge, und schickt dann das Segment aus der Datei über den Socket raus. Im Gegensatz zu traditionellem read und write spart das einmal eine Kopie der Daten. Das Google-Stichwort ist dann auch Zero-Copy.
Nun, zero copy macht Kernel-TLS natürlich auch nicht draus, der muss ja die Daten verschlüsseln und das macht ja auch eine Kopie. Allerdings gibt es Netzwerk-Karten, die TLS Offload beherrschen. Ich habe sowas nicht, aber es existiert, und dann kann der Kernel die Krypto direkt durchreichen an die Hardware, und kann es möglicherweise gar einrichten, dass die Netzwerkkarte sich die zu schickenden Daten direkt per DMA vom NVMe holt, oder halt aus dem RAM, ohne dass der Kernel die anfassen muss.
Naja gut, denkt ihr euch jetzt vielleicht, aber macht das wirklich so viel aus? Nicht bei Fast Ethernet und Gigabit geht auch noch ohne. Aber bei 10 und 100 GBit kriegt man die Leitungen ohne Zero Copy nicht saturiert. Und natürlich hat man mehr Ressourcen für andere Arbeit auf dem Server, je weniger man mit sinnlosem Hin- und Herkopieren von Daten verbraucht.
gatling habe ich damals explizit mit dem Ziel geschrieben, mich mal in Zero-Copy-TCP einzuarbeiten, aber das ist mit TLS erstmal wertlos. Bis jetzt.
Zu meiner großen Freude unterstützt OpenSSL seit Version 3 das zumindest auf dem Papier. Allerdings konnte ich das nicht funktionieren sehen. Heute habe ich das mal debugged. Auflösung: Die Kernelheader in /usr/include/linux waren zu alt :-)
Heute habe ich das zu Laufen gekriegt, und hatte bei wget einer 1 GB-Datei über das Loopback-Device sowas wie 1 GB/sec Durchsatz.
Das war mit dem alten TLS-Code, der mmap+SSL_write machte. Da hat man dann kein sendfile. Daher hat OpenSSL 3 eine Funktion namens SSL_sendfile nachgereicht. Die konnte man in meiner Abstraktion in libowfat nicht benutzen, daher hab ich die heute ein bisschen erweitert und dann in gatling per Callback SSL_sendfile eingebaut, und dann hatte ich im selben Test 1,9 GB/sec Durchsatz.
Fand ich sehr beeindruckend, muss ich euch sagen. Schön zu sehen, dass sich die Technologie auch ein bisschen weiterentwickelt.
In der Praxis wird das bei meinem Blog oder so nicht viel bewirken, weil der Großteil der CPU-Zeit da für das Handshake draufgeht, nicht für die symmetrische Krypto. Trotzdem. Hocherfreulich, wenn in der IT mal was schneller wird, und nicht immer nur langsamer und bloatiger.
Update: Richtig konsequent zuende getrieben hat das Netflix, wobei die allerdings FreeBSD und nicht Linux verwenden. Die haben dazu einen ziemlich sehenswerten Vortrag gehalten: Folien, Video.
Update: Oh und natürlich hilft Kernel-TLS mit Offloading auch auf schwachbrüstigen Embedded-SOCs, die auf Kosten- und Stromsparen ausgelegt werden, nicht auf CPU-Power.