Revision 709: HTTP/3 und WebTransport, mit Max Inden

0:00Congestion Control ist die Idee, das Internet ist packet-switched, also packet-based. Das bedeutet, wenn ich jetzt mit Cloudflare rede, dann habe ich nicht meine eigene Verbindung, wo ich so viel darauf schicken kann, wie ich will, sondern es werden Pakete geschickt. Okay, ich glaube, wir haben Konsens zwischen uns zwei. Wir wollen den Kram verschlüsseln. Wir sehen aktuell 92 Prozent des kompletten Internet-Traffics verschlüsselt. Sechs Prozent lokal und dann den Remaining ist HTTP ohne Verschlüsselung.

0:26Also HTP, es hat geklappt auf dem Internet. Super. Erster Schritt. Revision 709. Wir sind heute zu zweit. Aus dem Team bin du euch dabei, der Chef. Und das bedeutet, wir haben einen Gast und zwar den Max Inden. Hallo Max. Hallo, moin. Moin. Schön, dass du dabei bist. Du bist aus Berlin zugeschaltet, richtig? Ja, ganz genau. Genau, und du arbeitest bei Mozilla. Aber mehr will ich gar nicht sagen. Erzähl mal, wer du bist und was du machst. Hm, okay, ja, sehr gern.

1:21Genau, ich arbeite bei Mosella als Software Engineer, genauer als Networking Engineer und hier arbeite ich im Networking Stack von Firefox. Fokussiert bin ich vor allen Dingen auf Quick, wo ich mir ganz sicher, dass wir darüber sprechen, und HTP 3 und alles, was da so drumherum sitzt, wie zum Beispiel Web-Transport, Mask, aber generell viel Interesse am Firefox-Motoring-Stack, was natürlich ein riesiges Software-Projekt ist. In der Vergangenheit habe ich viel an Prometheus gearbeitet.

1:53Prometheus ist ein Monitoring-Tool, vor allen Dingen mit der Integration in Kubernetes, unter anderem bei Red Hat & Co. Habe dann viel Peer-to-Peer-Networking-Software gemacht und vom Peer-to-Peer-Bereich bin ich dann über Quick quasi in Firefox reingeschlittert. Genau, und du bist ein Rust-Fan. Ja, ganz großer Fan. Also ganz großer Fan von Memory-Safe-Languages, das ist so mein wichtigstes Argument. Gerne Rust. Natürlich großer Rust-Fan, aber das ist nicht so sehr das, was ich pushen möchte, sondern bitte mehr Memory-Safety.

2:29Ja, okay. Ja, ich weiß gar nicht, was... Also bei Rust weiß man das und ich habe immer das Gefühl, wenn man das will, dann ist Rust einfach die Sprache. Aber genau, es scheint ja durch, es gibt auch andere Sprachen, die das können. Ich weiß nicht. Ja, genau. Da solltet ihr, glaube ich, euch jemand anderen einladen, um auf die Frage rauszugehen. Aber ja. Ja, nee, das wäre auch die Falschen wahrscheinlich dafür. Generell als Podcast und auch die Hörerschaft.

2:58Genau, also ein paar werden es schon wissen, aber. JavaScript wäre eine davon. Echt? Ja, gut, logisch. Ja, okay, verstehe. Ja, macht Sinn. Genau. Ja, aber es ist ja kein, ja, doch, es ist auch eine kompilierte Sprache, aber eben anders kompiliert als Rust. Okay, genau. Genau, und du hast es schon angedeutet, der folgenden Titel hat es auch schon hergegeben, denke ich mal. Wir wollen heute über Networking sprechen mit Fokus auf HTTP3 und QUIC. HTTP 3 hat man schon gehört, Quick vielleicht nicht unbedingt.

3:36Und genau, dann nehmen wir noch so hier und da ein paar so Sidequests mit, die vielleicht nicht unbedingt mit HTTP 3 und Quick direkt zu tun haben, aber die auch in dem modernen Networking-Stack jetzt allerdings drin sind und, mit denen du dich auskennst. Vielleicht starten wir mal einfach damit. Also ich bin 2016 mit einem Talk über HTTP2 rumgethingelt und habe allen Leuten erzählt, HTTP2 ist der Heilsbringer, erlöst uns von allen Problemen, die wir haben mit HTTP2.

4:15Vor allem was so Web-Performance angeht, die HTTP 1 eben so mit sich gebracht hat, dass das ja sehr alt ist, von 1991, glaube ich, oder so. Da müsstest du ja auch wieder jemanden anderen einladen, glaube ich. Doch, ich hatte das bei meinem Talk damals, aber es ist halt zehn Jahre her. Genau, aber so jetzt HTTP 2 haben wir bekommen, mit vielen coolen Features, so Header Compression, dann irgendwie gab es ja noch HTTP 2 Push, war ja auch Server Push, war ja auch noch so ein Feature.

4:51Und eigentlich war alles super, dachten wir. Aber jetzt, zehn Jahre später, gibt es ja HTTP 3. und da wäre jetzt die Frage oder genau, wir wollen darüber sprechen, warum? Warum bübst das denn? Also ich meine, eine höhere oder eine neue Version von was ist natürlich immer nicht schlecht und sagen wir nie nein. Und benutzen wir vielleicht auch, also ich glaube, alle, die Cloudflare vor ihrer Seite schnallen, die nutzen das und die Big Tech nutzt das auch, also ich, so Facebook und Co.

5:27Ja, und die Frage ist halt, Und was ist daran besser? Also warum gibt es das? Und das werden wir heute mal ein bisschen besprechen, denke ich mal. Ja, sehr gerne. Genau, und im Grunde kann man das, also gibt es so zwei Aspekte, die letztendlich, würde ich sagen. Hast du ja auch in der Vorgesprächung gesagt, zu HTTP 3 geführt haben. Das eine ist, die Performance-Versprechen von HTTP 2 konnten nicht so ganz eingelöst werden. Also in der Praxis hat man dann, so wie das halt oft so ist, in der Praxis merkt man dann so, ah, okay, nee, das funktioniert dann doch nicht, wie wir uns das dachten.

6:06Und dann sind auch die Sicherheitsanforderungen der Leute eben im Digitalen gestiegen und man möchte einfach mehr Security und mehr Privacy haben. Und auch das hat da seinen Weg reingefunden. Ja, ich würde es ein bisschen positiver formulieren, würde sagen, HTP 2 hat sehr viel geschafft und hat quasi Appetit auf mehr gemacht und HTP 3 schafft noch mehr. Genau, wo es danach weiterhin geht, das weiß ich nicht, aber ich hoffe, dass wir an HTTP3 und an Quick darunter noch sehr viel arbeiten, also das noch selber sehr viel verbessern.

6:45Ja, vielleicht können wir ja kurz nochmal sagen, also genau, HTTP2 war schon cool, hat so Konzepte wie Multiplexing eingeführt, also sowas wie, also bei HTTP1 gab es ja einfach so ein Gentleman's Agreement, würde ich sagen, an TCP-Connections, die man gleichzeitig zum Server aufgemacht hat und mit steigender Anzahl Files, die aus denen so eine Webseite besteht. Ist man einfach in Bottlenecks reingerannt, war einfach nicht genügend sozusagen Leitungen zur Verfügung standen und da musste erstmal quasi alles fertig durch und dann konnten die nächsten Dateien dann über die dann freigewonnenen Leitungen übertragen werden.

7:26Multiplexing ist das anders angegangen, da gibt es nur noch eine einzige Verbindung und da kann alles sozusagen reingemanscht werden, so ein bisschen wie so eine Zahnpasta, die dann so mit so Farbstreifen rauskommt. Das ist eine schöne Art Metapher, ja. Genau, solche Dinge dann sind auch Header immer weiter gewachsen. Und die haben dann auch zu Latenz geführt, gerade sozusagen vom Client zurück zum Server, weil einfach die Upstreams ja nicht so schnell sind wie die Downstreams.

7:58Und also dieses Header-Bloat ist HTTP 2 angegangen durch Header-Compression. Also die haben ja dann gesagt, so Header, also du kannst mich immer korrigieren, Das ist ja nur das Initiative drin wie du, aber ich glaube, das war ja so, dass wenn Header schon mal gesendet wurden, dann wurden die nicht nochmal gesendet beim nächsten Mal, also dann wurde quasi nur noch so ein Diffing gemacht von den Dingen, die sich dann... Verändert haben. Es kommt ganz auf den Compression-Algorithmus an, ja.

8:27Vielleicht bringen wir nochmal ein bisschen mehr in HTTP 1 und die Idee von Multistreaming, wenn du das schon angerissen hast. Ja, klar. Also HTTP 1, wir haben eine einfache TCP-Connection, upgraden die vielleicht mit TLS und dann können wir einen Request draufschicken und dann kriegen wir eine Response zurück. Das bedeutet, ich schicke einen Request ab, warte einen Roundtrip-Time, also eine RTT, und kriege dann die Response zurück. Das ist im Web-Kontext extrem langsam, weil ich schicke ja nicht einen Request ab, sondern ich schicke ja ganz viele Request ab und die jetzt sequentiell so abzufrühstücken, obwohl ich sie in Teilen auch parallel abfeuern könnte, weil sie nicht aufeinander aufbauen sind.

9:12Oder auch eng sind voneinander, ja. Ja, am liebsten würde ich die natürlich alle auch einmal rausschicken. Das bedeutet, ja, was macht man also? Man hat zwei Optionen. Entweder ich schicke mehrere Requests direkt hintereinander und kriege dann mehrere Responses hintereinander, das wäre Pipelining, oder ich öffne einfach mehrere TCP-Connections. Genau. Beides kommt mit Benefits und Drawbacks. Pipelining hatte riesige Sicherheitslücken, weil nie genau klar war, wo der Request eigentlich aufhört und wo er anfängt, genauso mit den Responses.

9:43Und so konnte man allerlei Tricks machen, wo man etwas abgeschickt hat und es so rausgegeben hat, aber dann die andere Seite es anders importiert hat. Also es hat zu riesigen Security-Volumniabilities geführt. Okay, das wusste ich nicht. Ich wusste nur, oder ich hatte nur irgendwie mitbekommen, dass das Pipelining auch so ein bisschen daran gescheitert ist, dass so Devices sozusagen auf dem Netzwerkweg teilweise mit Pipelining nichts anfangen konnten und das dann quasi kaputt gemacht haben.

10:09Also ich weiß nicht. Und dann, also es war eine geile Idee, aber es dann irgendwie gescheitert. Also ich glaube, in der Praxis ist es dann ... Aus seinen kontrollierten Umgebungen einfach nicht mehr zum Einsatz gekommen, oder? Ja, also das werden wir heute, glaube ich, ganz viel noch besprechen. Das Problem der Middleboxes. Also alle möglichen Geräte, die irgendwann mal installiert wurden, die bestimmt irgendwann mal einen richtig guten Grund hatten, dass sie da standen, aber dann nie geupgradet wurden oder nie aufgeräumt werden.

10:38Und so kann man halt eben kein Protokoll weiterentwickeln. Und das ist jetzt zum Beispiel ein Beispiel. Viele von diesen Middleboxes haben halt eben einen Request erwartet und dann eine Response zurück. Schicke ich jetzt plötzlich zwei Requests auf einmal, könnte es sein, dass die Middlebox das schaffen, vielleicht aber auch nicht, genau. Also das ist der eine Weg, wir können jetzt, wir können, also der eine Weg ist, der allererste Weg ist, ich schicke eine Request, kriege eine Response zurück und dann geht es weiter, macht das also komplett sequenziell.

11:05Zweiter Weg ist das Ganze zu Pipeline und der dritte Weg ist mehrere Connections aufzubauen. Firefox zum Beispiel aktuell, wenn wir einen Server haben, der nur HTTP 1 kann. Da machen wir kein Pipelining. Das ist uns quasi zu unsicher oder zu instabil. Sondern wir machen stattdessen sechs TCP-Connections auf. Bis zu sechs. Wir starten nicht direkt mit sechs, aber bis zu sechs. Das bedeutet, wir können bis zu sechs Requests in parallel übers Netzwerk laufen lassen.

11:35Sechs ist nicht viel. Nee, sechs ist nicht viel. Und wenn wir nachher über HTTP 3 reden, dann ist das eine ganz andere Welt. Genau, aber das ist quasi das, was wir können jetzt in HTTP 1. Und diese dritte Methode, diese sechs TCP-Sockets aufzumachen. Die hat einen großen Nachteil. Und zwar habe ich jetzt sechs separate TCP-Sockets, die alle den gleichen Path, den gleichen Weg benutzen. Das bedeutet, ich habe auch sechsmal einen neuen Congestion-Controller laufen, wo jeweils der Congestion-Controller nichts voneinander weiß.

12:09Das ist diese Phase, die am Anfang der Verbindung erst mal sozusagen austariert, wie schnell oder wie groß sind die Pakete, die ich schicken kann. Und der startet ja langsam und dann wird es immer schneller, oder? Genau. Congestion-Control ist die Idee, das Internet ist packet-switched, also packet-based. Das bedeutet, wenn ich jetzt mit Cloudflare rede, dann habe ich nicht meine eigene Verbindung, wo ich so viel darauf schicken kann, wie ich will, sondern es werden Pakete geschickt.

12:36Und wenn ein Weg überlastet ist, werden Pakete einfach weggeschmissen von den Routern, um zu verhindern, dass die überlastet sind. Genau, und Congestion Control findet in den jeweiligen Endpoints statt, also einmal auf der Server-Seite, einmal auf der kleinen Seite, um halt eben rauszufinden, wie groß ist denn jetzt gerade, wie viele Pakete kann ich denn auf einmal rausschicken? Und das meinst du gerade richtig, genau. Die meisten Congestion-Controller machen am Anfang etwas, das heißt Slow Start.

13:02Der Name ist ziemlich misleading. Die Idee ist, du fängst unten an, recht tief, und gehst dann exponentiell mit deinem Sending Rate hoch. Das Ganze nennt sich Congestion-Control, weil wir versuchen, rauszufinden, der Fahrt zum Server und vom Server zurück, wie viel kann der eigentlich handeln. Genau, und wenn ich jetzt sechsmal diese Control-Loop, diesen Congestion-Controller laufen lasse, wo kein Congestion-Controller voneinander was weiß, dann bedeutet das auch, dass diese sechs miteinander konkurrieren werden.

13:36Und das führt dann zu allerlei Performance-Problemen auf diesen sechs Connections. Und zwar zu Congestion, ja. Ja, okay. Ja, weil die im Prinzip alle auf die gleiche Straße losgelassen werden, und, Ja, und sich gegenseitig ein Stück weit blockieren dann auch. Ja, am Anfang sogar exponentiell. Also die versuchen alle sechs gleichzeitig sehr, sehr viel zu senden. Das ist alles nicht so recht relevant vom Client zum Server, weil der Client eigentlich nur kleine Get-Requests schickt.

14:10Das Web ist hauptsächlich Get-Requests, die ziemlich klein sind. Aber es ist ein Riesenproblem vom Server zum Client. Das ist meistens der congested Path. Und deswegen sieht man auch zum Beispiel Home-Networks. Meistens hat man asymmetrische Uplink-Downlink, dass man viel mehr Download hat als Upload, weil es halt eben einfach im Haupt-Use-Case viel wichtiger ist, was zu downloaden. Ja, genau. Und wahrscheinlich, damit man keine Web-Server zu Hause betreibt.

14:40Da könnte man auch eine Conspiracy sehen. Jeder 24 Stunden wechselt meine Public-IP. Gut, und von hier aus können wir dann jetzt in HTTP 2 springen. Und zwar wäre es nicht super cool, wenn wir dieses Pipelining quasi aufbauen würden. Also wenn wir diese Option 2, also mehrere Requests gleichzeitig über eine Connection, wenn wir das ordentlich bauen würden. Und das ist quasi HTTP 2. Genau, also da gibt es jetzt, da gibt es eben die Option nicht zwei oder mehr, sechs TCP-Verbindungen in dem Fall aufzubauen.

15:18Das macht man einfach nicht. Man hat eben nur eine einzige und nutzt die dann für alles. Es hat einmal diesen Congestion-Control-Slow-Start. Genau, und dann schickt man im Grunde alles darüber. Und man kann ja auch sozusagen, das ist ja der Sinn von Multiplexing, auch Pakete von dem einen Request und vom anderen Request mischen. Mhm. Und das klingt ja alles eigentlich super. Ja, richtig gut, ja. Genau. Sollen wir in das Problem reingehen, warum wir dann HTTW 3 brauchen?

15:56Ja, vielleicht können wir genau, das machen wir auf jeden Fall. Ich wollte nur noch kurz sagen, dass HTTP 2 ja auch mit sich gebracht hat. Dass man das zwingend, also zumindest in the wild zwingend, TLS verschlüsselt überträgt. Auch wieder wegen dieser Mittelboxen, die wahrscheinlich sonst da reingeguckt hätten und, nicht gepeilt hätten, worum es da geht. Also diese ganzen Legacy-Mittelboxen und es dann kaputt gemacht hätten. Und so war eben die Idee, wir packen das einfach in so einen verschlüsselten Stream rein und da kann keiner reingucken und dann kann es auch keiner kaputt machen.

16:37Ja, ich denke, die Hauptmotivation war wirklich die Verschlüsselung selbst. Also es ist gut, dass das Internet verschlüsselt ist und es ist auch gut, dass das Internet Ende zu Ende verschlüsselt ist. Aber es war ja noch die Zeit, wo das mit so Let's Encrypt ja auch noch losging. Also da war das ja nicht selbstverständlich. Also da haben ja, ich weiß nicht mehr, wie hießen die nochmal, alle diese ganzen Zertifikatshändler, die haben ja richtig die Hand aufgehalten.

17:00Komodo, die sind nicht Komodo, so die Buden, die haben sich eine goldene Nase verdient und es war einfach teilweise total anstrengend, Zertifikate zu bekommen. Genau, und da fing das mal mit Let's Encrypt an. Ist ja, glaube ich, auch eine Mozilla, auch wieder Mozilla am Start gewesen, die das losgetreten haben, meine ich, oder? Auf jeden Fall sehr hang-related, ja. Also Mozilla hat irgendwie... Ex-Mosilienz, genau. Mozilla hat einen riesigen Einfluss auf das Web. Total, ja. Das ist der Wahnsinn.

17:30Wir können auch irgendwann über eine coole Poemiersprache namens Rust sprechen. Naja, auch Rust, ja genau. Oder WESM oder was auf ESM basiert. Und ja, ist schon cool. Servo. Wir können ja vielleicht einmal ganz kurz, das ist, glaube ich, ganz spannend. Also, wenn ich jetzt eine Domain habe, also die User gibt oben wikipedia.org ein, dann habe ich als Browser keine Ahnung, spricht jetzt wikipedia.atp1 oder atp2. Weiß ich nicht. So, was ich dann als Browser mache, ich mache erstmal eine TCP-Connection dahin und dann versuche ich halt eben ein TLS-Hand-Check.

18:06Und im TLS-Handshake verhandeln wir, welche HTTP-Version wir benutzen. Und das ist halt super praktisch in HTTP2, weil es halt immer TLS braucht, um halt diesen HTTP2-Upgrade dann auch zu machen. Okay, das heißt also, man verliert dann keine Zeit, weil man das sozusagen beides in einem erledigt. Genau, ja. Nachher mit der dritten HTP-Version machen wir noch mehr in einem. Aber das ist jetzt schon mal ein guter Schritt. Also wir sagen im TLS-Handshake sprechen wir schon mal darüber in den gleichen Roundtrip.

18:38Was könnten wir denn nachher mal sprechen hier auf dieser Leitung? Genau, und wir haben ja gerade gesprochen über das Multiplexing und wie cool das ist. und ich glaube, da wolltest du dann eine Brücke bauen zu HTTP3, oder? Hm, ja. Ich überlege gerade, ob ich noch mehr zu HTTP2 sagen möchte. Aber ich glaube, wir können jetzt gerne mal eine Brücke bauen. Ja, also ich weiß nicht, wie das, also da bin ich mir über HTTP3 nicht sicher. Also HTTP2 hatte ja noch so ein System, so eine Art so ein Baumsystem, mit dem man eben Ressourcenbeziehungen zueinander ausdrücken konnte.

19:19Das auch, glaube ich, krass overengineert war. Also ich glaube, im Nachhinein hat man das vielleicht so ein bisschen bereut, das so aufgebaut zu haben, wie ich das so rausgehört habe. Aber das sind auch Erfahrungswerte aus der Praxis. Also du konntest dann eben sagen, hey, wichtigstes Dokument im Tree ist halt das HTML. Und das hat die höchste Priorität. Das soll auch gegebenenfalls exklusiv über die Leitung gehen, also nicht mit anderem Zeugs multiplex werden, weil das halt einfach so uns so wichtig ist.

19:47Das muss Vorrang bekommen. Und dann konnte man eben sagen, okay, dann haben wir quasi Propriet ZT2s, CSS und blockierendes JavaScript und so weiter und so fort. So wie man das so ein bisschen, generell vom Browser kennt, wie der entscheidet, was für Ressourcen er wann lädt. Ja, genau. Also das hörst du auch häufiger, wenn du dich zum Beispiel in die ITF-HGP-Working-Group setzt, dass das immer so als das Nummer-eins-Thema erwähnt wird, was overingeniert war und hat in der Zeit.

20:19Und da siehst du ja auch, dass Priorities inzwischen viel simpler sind, also dass es einfach eine Zahl von 0 bis 7 ist. Also da hat sich einiges verändert, dass es halt eben viel, viel, viel simpler ist und vor allen Dingen auch in HTTP 3 viel simpler gebaut ist. Ja, es ist auch, glaube ich, so gewesen, dass halt teilweise die Server-Implementationen das auch gar nicht, ja, sagen wir mal richtig, beachtet haben. Also die Browser haben ja im Prinzip gesagt, was sie wie haben möchten, in welcher Priorisierung.

20:46Und dann gab es eben Web-Server, die haben es gut gemacht. Ich glaube, die beste Implementation ist immer noch die von Apache, meine ich. NGX ist auch okay und dann genau, dann wird es schon so langsam so ein bisschen kniffliger, Ja, da kann ich dir nicht so viel von erzählen. Also da war ich sowohl auf der HTP-2-Seite und der HTP-3-Seite nicht involviert. Somit würde ich, glaube ich, eher in das Multistreaming reingehen, weil ich da deutlich mehr erzählen kann.

21:18Diese Revision von Working Draft wird euch präsentiert von Webcafé, der Podcast zu Webentwicklung, Webdesign und Unternehmenskultur. Liebe Hörerinnen, liebe Hörer, falls ihr auf Podcasts zu Webentwicklung steht und ich habe da ja so einen Anfangsverdacht, dann möchte ich euch an dieser Stelle ins Webcafé einladen. In diesem Podcast nehmen euch die Hosts Felix und Kai jede Woche mit auf einer Reise, quer durch den Arbeitsalltag einer Agentur.

21:41Das berührt alles zwischen PHP und TypeScript bis hin zu Herausforderungen der Unternehmens- und Personalführung. Webcafé ist nicht ganz wie Working Draft. Es geht nicht permanent um technisches Tieftauchen und Felix und Kai tun auch alles, um auch Juniorige, Programmiererinnen und Programmierer sowie nicht-technisches Führungspersonal abzuholen. Klingt gut? Dann hört rein! Das Webcafé findet ihr auf webcafé-podcast.de und überall sonst, wo frische Podcasts angeboten werden.

22:07Das war nochmal webcafé-podcast.de oder die Podcast-Plattform eurer Wahl. Wir danken Webcafé für die Unterstützung von dieser Revision von Working Draft. Genau, also wir haben jetzt quasi geschafft von HTP 1, wir haben einfach ganz viele TCP-Connections auf. Sind wir jetzt ein bisschen strukturierter und wir haben eine TCP-Connection auf einem Pfad im Internet und da können wir mehrere Sachen gleichzeitig auf diesem der einen TCP-Connection schicken. Genau.

22:38Das ist also super gut und das nennt sich Multiplexing. Und HTTP 2 hat das nur für Streams. Also kann quasi Byte-Streams multiplexed, also ineinander verflechtet, übers Web schicken. Magst du das einmal kurz erklären? Also es gibt ja den Unterschied, glaube ich, zwischen Streams und Datagramm, richtig? Ja, die Brücke würde ich gleich noch bauen, aber vielleicht erstmal mit den Streams nur, damit wir ein bisschen die Komplexität runterhalten.

23:03Vor allem in einem Podcast ist es, glaube ich, schwer. Da würde ich jetzt direkt zum Whiteboard laufen. Aber das ist natürlich jetzt hier ein bisschen kompliziert. Okay, genau. Also wir haben die Streams. Und das baut alles auf TCP TLS auf. Das bedeutet, ich mache eine TCP Connection, upgrade ich das Ganze mit TLS, habe da dann einen einfachen Byte-Stream. Also TCP ist ein Single-Byte-Stream, ordered, fully ordered. TLS ändert daran nichts, nur dass es seitdem encrypted ist.

23:36Und darauf baue ich jetzt dieses HTTP2-Multiplexing. Das bedeutet, ich nehme verschiedene Teile von verschiedenen Streams und baue die so ineinander zusammen. Aber die Eigenschaft eines Streams ist eben, dass es quasi eine Sequenz in einer gewissen Reihenfolge ist, die auch jetzt nicht sozusagen durcheinander gebracht werden sollte, ne? Genau, ja. Ein Stream wird von Browser immer in Order delivered. Also man kommt nie out of Order und man kann auch nie vorlesen oder zurücklesen oder ähnliches, sondern man bekommt einfach nur die Bytes eins nach dem anderen. Genau.

24:10So, jetzt ist das in dem perfekten Internet quasi die ideale Lösung. Wir haben einen Congestion-Controller, super, eine TCP-Connection, wir haben den Overhead, recht gering, wir haben eine TLS-Session, genau, und können jetzt darüber wunderbar simulieren, dass halt eben wir mehrere Dokumente fetchen wollen oder mehrere CSS-Files oder CSS und JavaScript und so weiter. Also wir können mehrere parallele Efforts darüber laufen lassen. Genial. Jetzt ist allerdings leider das Internet ein Ort, wo sehr viel verloren geht.

24:41Das ist jetzt nicht wahnsinnig in dem Sinne, dass jetzt 10% aller Daten verloren geht, die man so sendet. Aber es kann durchaus mal in so, es passiert meistens in großen Bursts. Also es gehen meistens ganz viele Pakete hintereinander verloren, wenn man sich das im Internet ein bisschen so vorstellen kann. Was passiert jetzt, wenn was verloren geht? Sagen wir, ich habe Stream 1, Stream 2 und Stream 3 und die packe ich jetzt irgendwie ein bisschen zusammen in mehrere Pakete.

25:11Und das Ganze läuft dann auf einem einzelnen ByteStream auf der TCP-Layer. Und sagen wir jetzt mal zum Beispiel, ich stecke erst Daten von Stream 1, dann Daten von Stream 2 und dann Daten von Stream 3. Und jetzt geht bei den Daten von Stream 1 ein TCP-Segment im Internet verloren. Also auf der TCP-Layer bzw. Ein IP-Paket geht verloren im Internet. Auf der TCP-Ebene bedeutet das jetzt, dass nichts an die Application weitergegeben wird, bis nicht dieses eine Paket retransmitted, also wieder gesendet wurde und wieder angekommen ist.

25:51Damit die Reihenfolge die korrekte. Ja, genau. Allerdings weiß TCP ja nicht, dass das jetzt Stream 1, Stream 2 und Stream 3 sind. Das bedeutet zum Beispiel, wenn jetzt bei Stream 2 nichts verloren gegangen ist, würde TCP auf der TCP-Layer, ist das nur ein einzelner Byte-Stream und auf der TCP-Layer würde das Ganze blocken. Das bedeutet, vielleicht liegen Daten vor Stream 2 und Stream 3 in unserem Buffer, aber das Betriebssystem bzw. Unser TCP-Stack würde uns diese Daten nie zur Verfügung stellen, weil der TCP-Stack denkt, hm, erst kam das Stream 1, Stream 1 ist verloren gegangen.

26:31Und ich darf das nur in der richtigen Reihenfolge rausgeben und deswegen blockiere ich jetzt auch Stream 2 und Stream 3. Und dieses ganze Prinzip nennt sich Head-of-Line-Blocking. Also das, was ganz vorne ist, was auch immer mit diesem Item passiert, ganz vorne in der Queue, in der Line, influent die ganzen anderen Sachen in meiner Assembly-Line, wenn man sich das mal so vorstellen möchte. Head-of-Line-Blocking kann auf ganz vielen Ebenen passieren.

27:01Also wir können zum Beispiel, im HTTP-1-Fall, wo wir das Ganze sequenziell laufen lassen haben, also ein Request, Response, nächster Request, Response. Da haben wir auch ein Head-of-Line-Blocking. Wenn der erste Request und dann die erste Response unglaublich lange brauchen, dann sind die Response 2 und 3 auch unglaublich lange. Da haben wir auch einen Fall von Head-of-Line-Blocking. Genau, da hat man natürlich noch dann die anderen fünf Verbindungen, jetzt bei HTTP 1, die man nutzen kann.

27:32Dann ist das nicht so schlimm, ja, genau. Bei HTTP 2 machen wir es ein bisschen besser, indem wir eine TCP-Connection haben, aber dadurch kaufen wir uns auch ein, dass wir dieses Head-of-Line-Blocking auf TCP haben. Ja, wir haben quasi so ein Single-Point-of-Failure und so ein bisschen gebaut aus Versehen, ne? Ja, Single-Point-of-Delay, ja. Das ist nicht voller Failure, aber genau. Und das, wenn du jetzt sagen würdest zum Beispiel, ich will fünf sehr große Dateien von A nach B schicken, ist das gar kein Problem, dass mal kurz ein bisschen was stottert und wir unsere Buffers aufbauen.

28:06Aber im Web zählen halt eben Millisekunden, also als User Experience. Und deswegen ist dieses Head-of-Line-Blocking ein riesiges Problem auf TCP-Ebene. Genau, das heißt dann wahrscheinlich, also man muss dann ein Retransmit machen und alles, was dann irgendwie schon irgendwie da reingesteckt wurde, hinter dem Paket, das verloren gegangen ist, muss dann quasi, wird das dann auch weggeworfen oder? Das wird warten müssen. Das wird im Waffer behalten. Ja, okay.

28:35Und das wird warten müssen. Und das muss dann mindestens einen ganzen Roundtrip warten. Ich sage hier mindestens, weil es ist auch immer sehr schwer zu wissen, wann was verloren geht. Weil dir sagt ja niemand Bescheid, ich habe bei uns deinen Brief weggeschmissen. Sondern du musst erstmal quasi eine kurze Zeit warten und dir denken, der Brief braucht aber ganz schön lange. Bzw. die Bestätigung, das ACK, das Acknowledgement braucht. Genau, das ist ja auch eines dieser Kernfeatures von TCP, dass man immer für jedes Paket sozusagen die Rückmeldung bekommt, dass es angekommen ist, richtig?

29:04Genau, das nennt sich dann Act-Acknowledgement. Genau, das Protokoll ist noch ein bisschen komplexer, aber auf dem Papier oder vereinfacht gesagt, für jede Daten, die ich rausschicke, kriege ich auch immer ein Act zurück, also ein Acknowledgement zurück. Hey, ich habe es übrigens bekommen. Das ist der große Vorteil von TCP versus UDP. Geben wir bestimmt auch noch gleich. Wir machen jetzt einige Fässer auf. Genau, das ist eine super Sache. Also Reliable Transport sind eine super Sache.

29:30Die sollten wir auf jeden Fall nicht immer wieder neu empfinden. Es macht total Sinn, dass das Web auf TCP aufbaut und nicht dass jeder seine eigenen Protokolle entwickelt. Das sagst du jetzt, aber gleich in was anderes erzählen, glaube ich. Ja, genau. Never roll your own crypto und dann. Okay, bauen wir von da aus schon die Brücke rüber. Ja, kann ich mal machen. Wenn wir schon über Latency geredet haben, dann gehen wir vielleicht noch auf ein paar andere Shortcomings von HTTP2 ein.

30:07Und dann können wir später darüber reden, wie HTTP3 das quasi alles löst. Wir haben jetzt ganz häufig diese Roundtrips erwähnt. Also wie lange dauert es, einen Request zu schicken und eine Response zu bekommen. Aber bevor ich überhaupt einen Request schicken kann, muss ich erstmal eine Connection aufbauen. Und auch das ist super relevant im Web, weil die meisten Connections sind super short-lived. Die meisten Connections, die Firefox macht, sehen entweder gar keinen Request oder nur einen Request zum Beispiel.

30:39Also wir bauen unglaublich viele Connections auf. Da können wir auch mal ein bisschen drauf eingehen, warum eigentlich. Also eine Website baut sich von ganz vielen Connections zusammen auf. Diese Zeit, die wir damit verbringen, Connections aufzubauen, ist sehr bemerkbar für Nutzer und Nutzerinnen im Web. Das wollen wir möglichst viel optimieren. Diese Zeit, die wir brauchen, um überhaupt den ersten Request loszuschicken. Wenn wir das ein bisschen aufrollen, wieder von HTTP1, HTTP2 und dann später auch HTTP3.

31:12Das erste Web hat einfach TCP und danach HTTP gesprochen. Das wäre TCP, ist ein Syn-Act. Danach habe ich die TCP-Connection laufen. Das wäre ein Roundtrip. Das können wir uns jetzt mal so ungefähr vorstellen. Weiß ich nicht. In den meisten Fällen denke ich mal so rund um die 20, 30 Millisekunden, einen Roundtrip. Und dann können wir schon ein Request schicken und dann kriegen wir eine Response zurück. Das bedeutet, wir haben, sag ich jetzt mal, 20 Millisekunden dafür gebraucht, die Connection aufzubauen und dann brauchen wir nochmal 20 Millisekunden, um ein Request und die Response zu bekommen.

31:49Super. 40 Millisekunden. Jetzt ist eine super Idee, das Ganze zu encrypten. Deswegen bauen wir noch TLS ein. TLS braucht auch einen Roundtrip. Das bedeutet, wir machen erstmal TCP-Synac, 20 Millisekunden. Dann machen wir einen Roundtrip-TLS, nochmal 20 Millisekunden. Und dann machen wir Request-Response, nochmal 20 Millisekunden. Dann sind wir beim 60 Millisekunden. Das ist deutlich merkbar schon. Nicht so sehr wegen dieser einen Connection, sondern weil eine Website sich meistens aus ganz vielen aufbaut und die aufeinander aufbauen.

32:17Also du lässt erst die Index runter, Das sind anscheinend dann mindestens schon mal 60 Millisekunden. Dann connecten wir uns nochmal zu einem anderen Server und so weiter. Genau. Das ist sehr relevant. Davon hat sich von HTTP 1 auf HTTP 2 nichts geändert. Außer, dass wir diesen TLS Step jetzt als required drin haben. Also auf jeden Fall mindestens 60 Millisekunden, beinahe 20 Millisekunden. Ist der DNS Lookup dann noch irgendwie unsere Story relevant?

32:45Also der kommt ja noch davor, dass man überhaupt weiß, man muss ja dann im, World Wide Web Telefonbuch nachgucken, welche IP-Adresse steckt hinter einer Domain das macht man eben über DNS-Requests und die brauchen halt auch dann ungefähr die Zeit. Sag jetzt mal, die müssen ja, die kommen ja dann nochmal vor dem TTS-Handshake überhaupt. Genau, ja. Der Grund, warum ich das jetzt nicht erwähnt hatte, ist hauptsächlich, weil das nicht so relevant ist.

33:14Es ist auf jeden Fall also in der Idee, wie funktioniert ein Request, super relevant. In der Idee, was ist Latency für mich, nicht so relevant, weil meistens DNS kann man super cachen. Die meisten DNS-Requests sind eigentlich aus dem Cache. Entweder aus dem Firefox-Cache, aus dem OS-Cache oder aus dem Requestive-Resolver-Cache. Und meistens ist der Weg zur Antwort, weil so viele Caches existieren, wenn ich selber die Antwort nicht habe, nicht weit bis zur Antwort.

33:43Okay. Also in unserem 60-Millisekunden-Beispiel ist es nicht sehr viel, was da noch durch DNS draufkommt. Da würde ich denken, dass die meisten zum Beispiel wie ein Recursive Resolver in einer Latency von, das ist jetzt mal sehr wenig geschätzt, aber ich denke mal unter 5 Millisekunden haben. Ja, also in der Praxis spielt es keine Rolle. Weniger. Es kann mal vorkommen, aber im Grunde meistens fällt das nicht ins Gewicht. Ja, ja. Okay, jetzt haben wir von der HTB1 auf HTB2 einfach nur den TLS-Stack damit eingebaut.

34:20Genau, super wichtig. Riesen-Evolution für das Internet. Aber genau, jetzt sind wir immer noch bei diesen drei Roundtrips, bis ich meine Response habe. Und das ist auch nochmal eine weitere Sache, die Quick zum Beispiel verbessert, wo wir dann gleich auch nochmal drüber eingehen können. Dann meintest du gerade eben, wir wollen nicht nur Streams, sondern wir wollten auch Datagrams. Also ich hatte ja gerade eben gesagt? Genau, ich habe das deswegen im Prinzip in den Raum geworfen, weil ja wichtig ist Wissen, dass eben, oder diese Charaktereigenschaft von Streams, dass sie eben eine, Aneinanderreihung von Daten sind, deren Reihenfolge nicht beliebig ist.

35:00Also es ist halt wichtig, dass die auch so quasi in der Reihenfolge. Rausgestreamt und reingestreamt werden, wie sie eben aufgebaut sind und man nicht irgendwelche Daten von hinten zuerst und dann noch was dazwischen und dann was von vorne, sondern das ist einfach so eine Eigenschaft von denen. Und dann im Gegensatz dazu gibt es eben die Datagramme, die im Prinzip einfach nur in sich geschlossene Mini-Daten-Päckchen sind, die aber nicht mit anderen quasi zu einem Stream zusammenhängen oder wie auch immer.

35:34Genau, die sind independent, sie sind unabhängig voneinander. Und in den meisten Fällen, wenn man von Datagrams redet, zum Beispiel auf der Transport Layer, also UDP Datagrams zum Beispiel, dann redet man von unreliable Datagrams. Also wir hatten ja gerade eben über TCPs Acknowledgement Mechanismus geredet, dass halt eben, wenn Sachen verloren gehen, die dann wieder neu geschickt werden. Und das ist ganz anders bei Datagrams, wo die nicht voneinander abhängig sind, also keine Reihenfolge haben und zusätzlich, wenn sie verloren gehen, dann sind sie halt verloren.

36:07Dann kümmert sich niemand mehr darum, die neu zu schicken. Und wir können nachher darauf eingehen, das ist, also in den meisten Fällen möchte man diesen Stream. In den meisten Fällen möchte man, dass die Sachen, die verloren gehen, nochmal neu geschickt werden. Aber in einigen Fällen will man das nicht. Und ich glaube, der Standard-Use-Case ist zum Beispiel Video-Calls. Also jetzt wir zwei, wenn du jetzt ein Wort sagst und einen Bruchteil von diesem Wort in einem TCP-Segment verloren geht und das dann 30, 40, 50 Millisekunden später nochmal geschickt wird zu mir, dann ist das ziemlich egal für mich.

36:44Vielleicht ist das auch ein bisschen weird. Will man das? man will das auch gar nicht. Ja, der Sprung wäre wirklich sehr verwirrend für mich. Und in dem Fall will ich gar nicht den Retransmission. Und wenn ich diesen Retransmission nicht mache, dann speichere ich mir zum Beispiel auch Bandwidth auf meiner Connection. Deswegen brauche ich es. Um da jetzt wieder in den HTTP2 versus HTTP3-Flow reinzukommen. HTTP2 kann das nicht. HTTP2, weil es auf TCP aufbaut und TCP, das einzige Konzept, was uns TCP gibt, ist dieser Single Reliable Ordered String.

37:20Genau, deswegen kann man darauf Data Gamers bauen, aber die sind dann doch wieder reliable. Also HTTP2 kann uns diese Unreliability, die wir in manchen Fällen wollen, gar nicht geben. Genau, und eigentlich, also im Grunde liegt es ja gar nicht an HTTP2, selbst, sondern einfach an der Tatsache, dass das eben, oder an der Designentscheidung, dass das auf TCP fußt, was eben diese, da einfach sehr akribisch ist und eben immer versucht, alles sauber zu schicken, auch wenn man manchmal denkt, so, ja, jetzt lass das mal sein.

38:00Mach mal, hör auf. Ja. Genau, das haben wir. Und vielleicht noch eine letzte Sache, ein Shortcoming von HTP 2, aber was eigentlich wieder eine TCP-Sache ist, ja, TCP-Connections identifizieren sich über Source-IP, Source-Port, IP-Destination-Port. Deswegen zum Beispiel benutzen wir immer einen neuen Port, wenn wir eine neue TCP-Connection aufmachen. Den Destination-Port können wir nicht so gut randomisen, weil wir müssen ja wissen, wo wir uns hinkonnecten.

38:35Aber den Source-Port, der wird dann meistens randomized vom System. Und damit hat man dann sozusagen eine, also die IP-Adressen kann man nicht ändern, die Server-Portnummer, da kann man auch nicht ändern, aber dadurch, dass man eben die kleinen Portnummer ändert, hat man dann wiederum hat man wieder was einzigartiges und man kann die TCP-Streams dann sozusagen voneinander unterscheiden dadurch, ne? Exakt, genau. Ja, und das ist super gut. Also dadurch können wir von einem Computer zum anderen Computer 16-Bit-Connections aufmachen, genau, also riesig viel.

39:10Und ich vermute mal, dass auch so Network Address Translation auch saufdauf Fuß, oder? Bei im TCP-Bereich. Oh, damit machen wir einen Fass auf. Ja, ja, weil ich weiß ja nicht, ob die HörerInnen sich das auch mal gefragt haben, aber so, woher weiß denn, also es sind ja dann viele Clients, die hinter so einem Router sitzen und Requests ins Netz schicken und wenn die zurückkommen, woher weiß man dann, an wen das Ganze wieder zurückgeht? Genau, ja, da sind wilde Tabellen in diesem Netz und da gibt es verschiedene Behaviours. Da können wir auch nachher drauf eingehen, aber ich glaube, das ist jetzt... Nee, müssen wir nicht, aber so, genau, es ist einem ja nicht bewusst, dass es das gibt im Hintergrund, ne? Ja.

39:53Okay, genau, also wir haben diese Identifier, das nennt sich ein For-Tupel, genau, also Programmierung-Tupel. Genau, also IP, Source-Port, Destination-IP, Destination-Port. So, wenn ich jetzt irgendwie etwas daran ändere, dann bricht die TCP-connection. Und daran kann ich ganz einfach was ändern, indem ich an meinem Smartphone, in meinem Wi-Fi bin, dadurch die Source-IP und Source-Port von meinem Wi-Fi habe und dann gehe ich raus, versuche zum Beispiel einen Bus zu kriegen.

40:25Und dann wechselt mein Handy auf den Mobilfunk und dann kriege ich plötzlich nicht mehr die IP von meinem Home-Network, sondern kriege ich eine IP von meinem Carrier-Grade-NAT, also von meinem ISP, zum Beispiel der Deutschen Telekom, die mir dann halt eben eine neue IP zuordnen. Genau. Und plötzlich funktioniert die TCP-Connection nicht mehr, weil der Server schickt natürlich weiter an diese alte TCP-Connection, an die alte IP und da kommt dann einfach nichts mehr an.

40:53Oder ich schicke was raus, aber der Server weiß gar nicht, wer denn diese neue IP da ist. Und das Ding bricht einfach. Und diesen Use Case haben wir von ab und an im Internet, wo man halt eben wechselt. Wo eines dieser vier Dinge sich ändert. Genau, und das ist ein anderes Shortcoming von HTTP2, aber auch hier wieder einfach, weil es auf TCP draufläuft. Genau, also die Konsequenz ist ja, dann muss der Client einfach wieder eine neue TCP-Verbindung initialisieren, ne?

41:24Genau, und da verlieren wir jetzt einmal die, das haben wir ja gerade eben besprochen, diese 60 Millisekunden. 60 jetzt wirklich als Beispiel. Ja, genau, also über Mobilfunk oder über Funktechnologie könnte es dann vielleicht auch ein bisschen mehr sein und wired dann eben halt weniger. Genau, das wäre jetzt zum Beispiel ein weiteres Shortcomings und das können wir lösen, da gibt es technische Lösungen zu und da haben wir jetzt noch eine Brücke zur HTW 3.

41:52Und von meiner Seite aus können wir jetzt einen Sprung in die Zukunft machen. Ja, auf jeden Fall. Also ich meine, wir haben das ja so ein bisschen vielleicht auch, glaube ich, durchscheinen lassen oder es ist vielleicht den HörerInnen auch aufgefallen, verantwortlich für einige dieser Probleme ist, Offenbar TCP. Also mit TCP ist alles gut und schön, aber einfach die Art und Weise, wie das arbeitet, führt eben zu diesen Shortcomings und TCP kann man auch nicht einfach mal eben ändern, weil wir haben die ganzen Legacy-Mittelboxen.

42:36Das ganze Internet läuft so, wie es ist, schon seit immer und da kann man nicht mehr viel dran ändern. Und deswegen musste man sich was anderes einfallen lassen, richtig? Ja, genau. Also man hat es versucht. Also nochmal, der Internet-Stack, IP, Internet-Protokoll, lässt verschiedene Transport-Protokolls zu. Also es ist kein Problem eigentlich, das zu erworben in einem IP-Header, das zu kommunizieren, dass ich ein bestimmtes Transport-Protokoll sprechen möchte und vielleicht auch ein neues Transport-Protokoll sprechen.

43:13Aber wie du jetzt gerade sagst, auf diesen ganzen Internetfaden, das Problem ist, dass diese ganzen Router nicht nur einfach IP sprechen, sondern sich auch noch in dieses Transportprotokoll einmischen. Also zum Beispiel irgendwas am TCP-Stack machen oder an den UDP-Protokoll-Datagrams. Genau. Das ist ein ganz großes Problem. Zum Beispiel wurde versucht, soweit ich weiß, wurde TCP 2 versucht, aber das weiß ich nicht genau. SCTP zum Beispiel wurde versucht, aus dem Internet aufzurollen.

43:43Zum Beispiel als Teil von WebRTC. WebRTC zum Beispiel benutzt SCTP. SCTP konnten wir leider nicht im Internet ausrollen, weil diese ganzen Mittelboxes halt eben annehmen, das Internet hat TCP und UDP, sonst nichts. Jetzt kommt plötzlich wieder das fancy Google-Team mit WebRTC und will SCDB darüber sprechen, das geht leider nicht, weil wir die ganzen Mittelboxer sprechen. Was macht also zum Beispiel WebRTC? Baut das Ganze einfach auf UDP oben drauf. Also TCP, was oben drauf bauen, haben wir gerade eben gelernt.

44:16Mit HTTP gibt es viele Probleme, HTTP 2. Wenn man es allerdings einfach auf UDP drauf baut, hat man eigentlich IP. UDP ist ein ganz kleiner Wrapper um IP drumherum. Genau, es gibt im Grunde ja nur diese zwei, Transport oder wie auch immer Basistechnologien. Ja, exakt. Oder zumindest die kann man nutzen, ohne dass es eben alles kaputt geht wegen irgendwelcher alten Mittelboxen. Genau. Nun muss man natürlich auch ein bisschen die alten Mittelboxes, die wir in Schutz nehmen, das hinterher ist der wilde Westen quasi.

44:56Man muss sich auch irgendwie schützen halt eben als Rechenzentrum. Das bedeutet, ich werde auch nur das reinlassen, was ich auch wirklich kenne. Und dazu gehört halt eben nur UDP und TCP. Genau. Was ich ein bisschen sagen wollte ist, also QUIC ist zum Beispiel nicht das erste Protokoll, was zum Beispiel auf UDP aufbaut. SCTP war das erste, war nicht unbedingt das erste, aber einer der ersten oder einer der bekannten. Ja, genau. So, jetzt wollen wir TCP weiterentwickeln. Also wir wollen einmal diesen Handshake-Feel schneller hinkriegen.

45:27Das ist uns ziemlich wichtig. Wir wollen das Head-of-Line-Blocking lösen. Wir wollen Datagrams zum Beispiel ermöglichen, also nicht nur Streams machen, sondern halt eben auch Datagrams auf der HTTP-Layer. Und vielleicht wollen wir sogar noch Connection-Migration machen, oder zumindest das Ganze deutlich robuster machen, also nicht einfach nur, ob es sind Vortubles. Und da hat sich jetzt zum allerersten Mal halt dem Google ganz früher hingesetzt und hat halt eben Quick designt und ich glaube auch damals in Chrome sogar ausgerollt in Teilen als neues Transport-Protokoll, was quasi einfach nur auf UDP aufbaut, aber im Endeffekt einfach auf IP aufbaut.

46:09Also vergleichbar mit TCP2, sage ich meistens, ist quasi das TCP2. Genau, UDP ist ja relativ, sagen wir mal, feature-arm und einfach gestrickt. Und dadurch, also das ist ja auch irgendwie der Vorteil davon. Also es ist so anspruchslos. Das wird irgendwo hingeschickt, geht verloren, egal. Meldet sich auch nicht zurück, wenn es irgendwo ankommt. Genau. Und Quick, also Google hat das ja schon damals bei HTTP2 gemacht, hatten ja quasi das Speedy-Protokoll entwickelt und das dann auch irgendwie mit ihren Browsern und ihren, glaube ich, eigenen Präsenzen dann so ein bisschen so angetestet, meine ich.

46:50Das werden wir wahrscheinlich für Quick jetzt genauso gemacht haben. Und man nimmt so ein bisschen mehr... Vielleicht Managementarbeit in die eigene Hand, die vorher sozusagen in den Händen von TCP waren, aber das dann eben so ein bisschen zu bürokratisch, sag ich jetzt mal, da vorgegangen ist. So kann man das sagen, ne? Das macht Quick. Genau, das Ganze hat Google dann zur ITF genommen, also der Internet Engineering Task Force, die auch zum Beispiel HTTP standardisieren und TCP.

47:22Und das, wie es immer bei der ITF ist, wenn man ein Protokoll reingibt, bekommt man am Ende was ganz anderes raus. Also die Ideen und die Ziele waren immer noch dieselben, aber es wurde halt eben deutlich als ein wahnsinns tolles Protokoll halt eben bei rumgekommen. Also ich bin sehr begeistert. Ich kann sehr empfehlen, zum Beispiel diese RFCs zu lesen. Ja, das finde ich an den Standardisierungen auch immer super. Ich meine, viele Leute ärgern sich auch, dass es einfach so furchtbar lange dauert.

47:53Also man ist ja dann irgendwie, man wartet ja auf was und ist da. Kannst gar nicht abwarten, dass es fertig wird und dann zieht es sich und zieht es sich. Aber es stellt sich ja doch eigentlich immer heraus, wenn man sich die Zeit lässt, dann wird das einfach nochmal deutlich besser. Und das ist ja auch was, mit dem müssen wir dann für die nächsten Dekaden wieder arbeiten. Also wenn das nicht gut wird, dann ist das schade. Ja, auf jeden Fall. Ich würde sagen, viel hat, gerade in so Standardisierungskörpern, hat man daraus gelernt und hat viele so Mechanismen eingebaut, wie man halt eben möglichst so ein Protokoll upgraden kann in der Zukunft.

48:37Eins hast du zum Beispiel gesagt, wir verschlüsseln jetzt alles, das bedeutet, die ganzen Mittelboxes können sich gar nicht anschauen, was drinnen steckt. Das bedeutet, das, was drinnen steckt, können wir auch verändern in der Zukunft. Das bedeutet, ich sehe die Zukunft deutlich besser als die Vergangenheit, also nach dem Motto Quick 2, ist übrigens schon raus. Quick 3 können wir ziemlich einfach in der Zukunft rausbringen. Das ist sehr, sehr leicht, das weiterzuentwickeln.

49:02Wohingegen, ja, wie du siehst, mit einem Hack auf UDP drauf, das TCP 2, was jetzt das Quick ist, war sehr kompliziert, ja. Okay. Ja, dann steigen wir mal in Quick ein, oder? Ja, gerne. Okay. Super. Also all die Guarantees, die uns früher TCP gibt, gibt uns UDP jetzt nicht. Um die müssen wir uns jetzt alle selber kümmern. Und die ganzen Guarantees, die TCP uns gibt, die kann Quick und Quick kann noch viel mehr. Ja, Turmdorf. Das ist gerade das Schöne. Und daraus gewinnt dann HTTP 3 riesig.

49:41Also ich würde sagen, die meisten Innovationen, aber da bin ich natürlich bei, ist, weil ich sehr weit unten im Stack arbeite, kommen eigentlich aus der Quick-Layer und nicht so mehr aus der HTTP 3-Layer. So wie die Nachteile von HTTP 2 ja auch aus der TCP-Layer kommen, ne? Ja. Ja, auf jeden Fall. Und das klingt ja auch so, als gäbe es so schnell vielleicht keine HTTP 4, weil letztendlich die Weiterentwicklung eher dann in der runterliegenden Protokoll stattfindet in Zukunft.

50:09Das wäre jetzt meine Perspektive. Da bin ich nicht involviert an dem HTTP 4, beziehungsweise ich weiß auch nichts von dem HTTP. Habe ich auch noch nicht gesehen, gehört nichts. Okay. Gut, fangen wir mal an mit dem Anfang einer Connection, also dem Connection Establishment. Früher HTTP 2, haben wir TCP, TLS, HTTP. Das heißt, wir haben drei Roundtrips, um die Response zu unserem Request zu kriegen. Der erste Roundtrip ist TCP, zweiter Roundtrip ist TLS, dritter Roundtrip, die Hälfte ist der Request, die andere Hälfte ist die Response.

50:46Quick macht jetzt was Kluges und packt den TCP-Teil und den TLS-Teil in einen Roundtrip zusammen. Also sagt quasi hey, ich bin das Transportfotokoll und übrigens, ich bin auch eine Security Layer und schafft es, die Connection zu establishen in einem secure way innerhalb von einem einzelnen Roundtrip. Genau. Das ist quasi die große Innovation an der ganzen Sache. Genau. Wenn wir jetzt genauer in den TLS-Handshake, da können wir näher reintauchen.

51:20Ich glaube, da bin ich auf jeweils die falsche Person. Oder zumindest würde ich mich darauf, glaube ich, ein bisschen besser vorbereiten. Nee, das müssen wir nicht machen. Alles gut. Genau. Das können wir jetzt innerhalb von einem einzelnen Roundtrip. Und jetzt, wo wir schon bei Connection Establishment sind, Quick hat noch ein sehr, sehr schönes Feature, meiner Meinung nach. Und zwar, wenn ich eine Connection aufgebaut habe, zum Beispiel zu wikipedia.org, dann wird mir, nachdem ich die aufgebaut habe, wikipedia.org einen Resumption-Token, einen Quick-Resumption-Token geben.

51:54Und dieser Token sagt quasi einfach, hey, nächstes Mal, wenn du was von mir willst, hier hast du einen Token. Wenn du den mit deinem Request mitschickst, dann kannst du direkt deinen Request schicken. Und das nennt sich dann Zero-RTT. Ja, geil. Das heißt also, man kann im Grunde schon das erste Datenpaket losschicken und dem diesen kleinen Rucksack umschnallen und dann der Türsteher weiß dann Bescheid und dann geht's direkt los. Genau, der Türsteher kennt dich dann, ja, genau.

52:24Das ist eine sehr gute Anlage. Ja, mega gut. Genau, also der Standard Connection Establishment nennen wir OneRTT, also wir schicken... Wenn du das erste Mal quasi zusammenkommst, ne? Genau, Transport- und Security-Layer-Sachen schicken wir gleichzeitig hin, kriegen gleichzeitig die Response zu und sind dann in einem Roundtrip fertig und sind bereit, den Request zu schicken. Und beim zweiten, dritten und so weiter kann uns halt eben dieser Server diesen kleinen Token mitgeben von der vorherigen Verbindung und dann können wir den mitschicken bei dem Request und können dann halt eben direkt in Zero-RTT, also direkt loslegen.

53:01Da gibt es Caveats zu, da können wir auch noch, also da gibt es various security considerations, aber die übernimmt der Browser, da muss man sich als Application-Owner obendrauf keine Sorgen machen. Ja, genau, das muss man ja eh nicht. Das ist ja alles, was wir diskutieren, ist untenrum und im Zweifelsfall, also wir benutzen das ja auch schon als Web-Nutzende und kriegen ja gar nichts davon mit, letztlich. Ja, das ist das Schöne am Web, diese Backwards-Compatibility bzw.

53:30Future-Compatibility ist natürlich der Wahnsinn, dass da Leute einfach mit aufsteigen können, ohne wirklich was zu gängen. oder den Vorteil haben. Okay, so, jetzt haben wir eine Connection, die haben wir entweder in oneRTT oder bei der zweiten Connection in zeroRTT geschafft. Ja, das ist natürlich der Wahnsinn. Und von hier aus können wir jetzt eine der zwei großen Primitive von Quick nutzen, nämlich entweder ein Stream oder, wie du gerade eben schon gesagt hattest, wir wollen ja jetzt auch Datagrams.

54:03Das bei Quick kann sowohl Streams, das kann man sich vorstellen wie einfach eine neue TCP-Connection, also eine TCP-Connection auf der TCP-Connection. Und wir haben Datagrams. Zum Ersten zu den Streams. Der große Vorteil an diesen Streams ist, die haben kein Head-of-Line-Blocking auf der Transport-Layer. Weil die nicht alle quasi wie auf einer Perle aufgereiht auf einer quasi auf einer Schiene laufen, sondern die können quasi frei parallel laufen und wenn einer blockiert wird, dann ja, tschüss, wir sehen uns später.

54:35Genau, also ich kann streamen, wenn wir wieder dieses Beispiel von Stream 1, Stream 2 als Stream 3 haben, idealerweise packe ich die jeweils in einzelnes UDP-Datagram, beziehungsweise verschlüssel sie erst auf der Quick-Layer und dann schickt die dann als UDP-Datagrams raus. Und wenn jetzt das erste UDP-Datagram verloren geht, aber dieses UDP-Datagram 2 und 3 in unserem QuickStack auf der Server-Seite ankommt oder in die andere Richtung, dann kann der QuickStack schon mal sagen, als Stream Einstein verloren gegangen zu sein.

55:05Aber Stream 2 und 3 habe ich hier und die kann ich auch schon hochgeben, also an die Application. Genau, und so können wir da direkt weitermachen. Also wir haben dieses ganze Problem von Head-of-Line-Blocking quasi gelöst. Das ist schon riesig. Und dann zusätzlich haben wir jetzt auch noch Datagrams. Und jetzt wird es natürlich ein bisschen verwirrend. Hatten wir nicht auch schon UDP-Datagrams? Also warum benutzen wir nicht einfach das? Das Problem, wenn wir einfach nur UDP-Datagrams benutzen, ist, dass es A, nicht verschlüsselt ist und don't roll your own crypto.

55:35Keine gute Idee. Wir haben schon TLS. Wir haben ja eh schon die Quick Session. Wir haben ja auch schon Asymmetric Crypto gemacht. Also super gut. Das können wir wiederverwenden. Das bedeutet, diese Datagrams, die Quick-Datagrams sind verschlüsselt und werden dann erst in UDP-Datagrams reingepackt. Und was wir ja auch schon ganz am Anfang erwähnt hatten, die werden auch congestion-controlled. Also, das muss ja alles durch den gleichen Pfad im Internet.

56:03Und es macht ja jetzt keinen Sinn, dass ich jetzt mit meinen Streams super vorsichtig bin und mich langsam anpasse, wie groß denn dieser Pfad ist, aber dann zig Millionen Datagrams gleichzeitig auf diesem Pfad schicke. Wenn ich das Ganze auf der Quick Layer konsolidiert habe, kann die Quick Layer das sowohl verschlüsseln als auch dann High-Dem-Congestion-Control. Ja, das heißt, die im Grunde, die orchestriert das, dass das irgendwie. Genau, die sagt im Grunde auch vielleicht auch ein bisschen, wie man das, wir arbeiten ja viel mit Analogien, wenn diese Autobahnauffahrten, wenn viel auf der Autobahn los ist, dann ist ja dann, gibt es ja so diese Ampeln, die dann immer nur so ein oder zwei Autos durchlassen und dann wieder auf Rot springen, also dass sie dann auch sagen so, genau, also die hat halt den, Quick hat den Überblick, Und weiß halt, wie schnell irgendwelche Pakete losgeschickt werden sollten bei der aktuellen Verkehrslage sozusagen.

56:55Ja, die Analogie finde ich sehr gut. Wir haben wirklich so eine Control-Loop in unserem QuickStack in Firefox, weil wirklich der Congestion-Controller sagt, jo, kannst. Ja, geil. Ja, ist ja genau das. Genau, okay. Dann haben wir jetzt, was haben wir jetzt alles geschafft? Wir haben eine Connection-Establishment geschafft, 1RTT oder 0RTT. Und wir haben jetzt diesen neuen Primitiver, einmal die Streams und wir haben die Datagrams. Die Streams, super gut, haben keinen Head-of-Line-Blocking, aber den gleichen Condition-Controller.

57:25Wenn wir uns nochmal zurückhalten, wenn wir diese sechs TCP-Connections für HTTP 1 haben, ist das nicht ein Condition-Controller. Jetzt haben wir quasi den großen Win von, wir haben Multiplexing wie in HTTP 2, aber auch noch den gleichen Condition-Controller. Genau, alles in einem Transport. Und dann jetzt das zweite Primitiv ist, diese Datagrams. Und da können wir nachher noch ganz viel einbauen, weil diese Datagrams erlauben jetzt ganz neue Applikationen auf HTTP.

57:56Genau, ich sag mal ein paar so Media over Quick, Web Transport ist ganz groß jetzt hier, Mask ist zum Beispiel ganz groß in dem Bereich. Also das erlaubt ganz viele neue Sachen. Aber ja, erstmal bauen wir daraus vielleicht gleich erstmal HTTP rein. Wir hatten noch ein anderes Shortcomings, und zwar die Idee von Connection Migrations. Ja, genau. Ja, dieses, ich bin zu Hause und wechsle ins Mobilfunknetz zum Beispiel oder so, und die Verbindung geht flöten.

58:29Genau, also diese Identifikation über dieses Vortupe, ja. Das löst Quick anders. Wir haben immer noch dieses Vortupel, aber es ist nicht so relevant, weil Quick selber auch noch einen Identifier mitschickt. Und das nennt sich die Quick Connection ID. Diese Quick Connection ID, ich glaube, das muss ich nochmal checken, ich glaube, es ist in den meisten Fällen 64-Bit. Genau, die kann halt eben genau diese Connection identifizieren. Wenn ich mich zwischen zwei Netzwerken bewege, habe ich immer noch die gleiche Connection ID und kann dadurch halt eben dem Server sagen, hey, ich bin's übrigens, aber jetzt über eine andere Fahrt. Ich bin da drüben, ja.

59:07Genau, also es kann natürlich dann wahrscheinlich immer noch sein, dass irgendwelche Antworten, die quasi zu deiner alten IP unterwegs sind, die gehen dann halt verloren. Aber sobald du dich einmal gemeldet hast wieder, weiß der Server, ah, okay, alles klar, du bist das. Ich lenke jetzt quasi die Daten um. Genau. Und wir haben ja Reliable Delivery zumindest auf Streams. Und dann wird der Client dem Server übrigens auch noch sagen, hey, das ist ja meine neue Adresse.

59:38Und übrigens, die und die Responses zu diesen Requests habe ich übrigens noch nicht bekommen. Beziehungsweise, ich habe noch keinen Axe dafür bekommen. Oder der Server sagt, dass er noch keinen Axe dafür bekommen muss. Ja. Genau, das war die Connection-Migration-Geschichte. Übrigens sehr wenig genutzt aktuell, leider. Einmal wird es recht wenig auf der Server-Seite angeboten. Und zum Beispiel Browser, unter anderem Firefox, unterstützen nicht jede Form der Connection-Migration.

1:00:09Okay, das heißt also, die Servers beherrschen einfach das, oder die können die beherrschen, dass sie nicht einfach eine Connection oder sie sind nicht darauf vorbereitet bislang? Nicht alle implementieren das, genau. Nicht alle Provider. Es kommt mit ziemlich viel Komplexität. Zum Beispiel, wenn ich jetzt von meinem Home-Network auf mein Mobile-Network wechsle, dann könnte es ja auch gut sein, dass ich ganz anders geroutet werde und vielleicht nicht mehr zu your big CDN Berlin, sondern your big CDN Frankfurt geleitet werde.

1:00:43Jetzt müsste dieser Big CDN irgendwie den kompletten State von dieser Connection von Berlin ganz schnell nach Frankfurt transferieren. Und das ist zum Beispiel riesige Komplexität, die dann halt eben auf der Serverseite gemacht wird. Okay, also das heißt also, dass es in dem Fall ist es vielleicht eher so ein CDN-Anbieter-Problem, weil die ja nochmal bei sich auch wieder ein bisschen heftigeres Setup haben als ein einzelner Server, der irgendwo steht, ne?

1:01:10Ja, die laufen meistens hinter einer Anycast-IP-Adresse. Und genau, das kommt mit sehr viel Komplizität. Aber ich würde mal sagen, das kann man mir ja aus. Connection-IDs an sich geben uns schon sehr viel Robustness. Also wenn sich irgendwas in meinem ID ändert, dann brechen meine Connections nicht unbedingt ab. In manchen Fällen schon, in den meisten Fällen nicht. Also es ist ein riesiger Schritt vor Ort. Und dann das andere, was ich noch erwähnen wollte. Das ist vor allen Dingen relevant im Bereich Censorship-Resistance.

1:01:40Also, wir haben mit dem Internet immer mehr Parteien, die sich irgendwie einmischen. Sei es einfach nur irgendwelche Middleboxes, die irgendwas schneller machen wollen. Oder Firewalls, die Datacenter schützen wollen vor irgendwelchen neuen Protokollen. Aber auch viele State Actors, die halt eben verschiedene Zensuren ausführen. Gut. Auf TCP TLS kann man sich vorstellen, TCP war komplett unencrypted. Da ist nichts passiert. Wie du auch schon sagtest, Quick haben wir jetzt komplett encrypted.

1:02:13Nach dem Connection Establishment, also währenddessen ist noch nicht alles encrypted, natürlich nicht, das ist ja noch der Handshake am Laufen, aber danach sind nur zwei Bits unencrypted im kompletten Quick-Data-Stream, also an den ganzen Datagrams, die wir da schicken. Das heißt, es ist auch viel schwerer für einmal Middlebox, das hatten wir ja besprochen, irgendwie was mit dem Protokoll zu ändern, aber auch zum Beispiel für Sensors viel schwerer zu erkennen, was denn genau auf dieser Connection passiert. Mhm.

1:02:43Okay. Ja, damit habe ich jetzt eigentlich alle Vorteile von Quick. Es gibt viel, viel mehr natürlich. Das sind so viele kleine Details, aber das sind so große. Genau, wir können ja gleich noch vielleicht noch ein bisschen auf Web-Transport eingehen. Aber bevor wir das tun, einfach weil du das gerade erwähnt hattest, wir haben ja gesagt, wir wollen auch durchaus Aspekte des modernen Networking-Stacks hier mit einwerfen, wenn es denn passt. Und du hast ja gesagt, der Handshake ist noch nicht eben encrypted, logischerweise, weil der führte erst zu der Encryption.

1:03:20Aber es gibt jetzt auch die, also Encrypted DNS Resolven, Ja, da kann man einspringen Genau Ich glaube, das gibt es auch schon eine Weile, Also ist jetzt nicht so dass das erst 2025 rauskam, Ne, da gibt es schon ein bisschen länger Genau, um so ein bisschen Historie, also wir haben jetzt geschafft von HTTP 1 komplett unencrypted, bauen wir jetzt ein TLS mit ein. Super. HTTP2 requiren wir das TLS. Das bedeutet, zumindest die ganzen Daten werden verschlüsselt.

1:03:56HTTP3 verschlüsseln wir jetzt auch noch den Großteil vom Transport-Stack. Also in Quick bauen wir jetzt quasi das Transport-Protokoll mit der Encryption zusammen. Super. Aber jetzt alles, was davor passiert, ist immer noch nicht verschlüsselt. Und da, wie du genau sagtest, ist es halt eben hauptsächlich der DNS-Lockup. Der ist aktuell in den meisten Fällen, ich kenne mal da die, ich habe übrigens ziemlich vielen von dem, was wir heute besprochen haben, Daten. Vielleicht soll ich es ein bisschen mehr einbauen.

1:04:22Aktuell macht Firefox an DNS-Requests sind 88% unverschlüsselt. Genau. Das läuft in den meisten Fällen so, dass der zum Beispiel mit meinem Laptop hier zu meinem Router halt eben hingeht und den halt eben fragt, wer ist eigentlich Wikipedia.org und mein Router das dann wahrscheinlich noch nicht weiß und geht dann zum ISP. Genau, weil ich habe nämlich das, wo du es jetzt gerade sagst, ich glaube, das habe ich nämlich in meiner Fritzbox eingestellt.

1:04:48Da konnte ich das nämlich, oder habe ich das umgestellt irgendwann, dass er das auch encrypted macht. Okay. Genau, ich weiß aber nicht mehr, was der DNS-Server war, ob das dann irgendwie Cloudflare war, wahrscheinlich. Ich glaube, es war Cloudflare. Ich sage jetzt einfach mal, es war Cloudflare. Aber gut, das macht Sinn, was du sagst, weil quasi die meisten DNS-Anfragen hinter einem Router landen beim Router und in einem Company-Netzwerk könnte es vielleicht schon wieder relevanter sein.

1:05:18Aber so ansonsten ist in dem Umfeld das vielleicht auch nicht nötig mit der Encryption, weil eben der böse State Actor nicht, also ... Also vielleicht bei manchen Leuten schon, aber bei mir noch nicht rumschüffelt, sondern der grast ja eher so irgendwo an Knotenpunkten im Netz Dinge ab. Das weiß ich nicht. Also gut, die können natürlich theoretisch hier einbrechen, wenn die sagen, hey, hier der Chef, den müssen wir uns mal genauer angucken und da verwandeln wir mal schön den Router.

1:05:55Es ist viel einfacher. Also ich muss ja nur irgendein Gerät in deinem Netzwerk hacken und dieses Gerät läuft ja in deinem Netzwerk und hat somit Zugriff auf deinen Router. Und dein Passwort ist wahrscheinlich nicht besonders komplex, denke ich jetzt einfach mal von deinem Router. Das bedeutet, ich habe sehr, sehr viele Stunden mit diesem Gerät, in dem ich sehr einfach deinen Router hacken kann. Und von da aus konfiguriere ich dann dein DNS und weiß somit deine komplette Browsing-History von all deinen Geräten.

1:06:21Also ich sehe auf jeden Fall den Attack-Vector hier. Also das ist etwas, was wir verschlüsseln sollten, nicht nur im Business-Kontext. Und das ist auch, warum zum Beispiel Mozilla hat diese ganze Idee von Encrypted-DNS so sehr pusht. Warum das relevant ist? Also einmal, es ist recht einfach, in diese Chain reinzukommen, also in diesen DNS Recursive Resolver Chain reinzukommen. Und mein DNS liegt ja meine komplette Browsing History, zumindest alle URLs, auf die ich gehe.

1:06:53Alles muss ja irgendwie immer resolved sein. Ja, zumindest alle Hosts, ne? Also die, die du besuchst. Ja, das ist ja im Grunde wie die Telefon- und Telefonie-Metadaten, wo ja auch gesagt wird, nein, wir speichern ja nur Metadaten, die sind ja gar nicht schlimm. Und man kann ja dann, da haben wir dann auch Forschende verschiedene Sachen dann eben nachweisen können, allein auf Basis dieser Daten, also so irgendwie Beziehungsgeflechte, vielleicht auch irgendwie Bewegungsprofile und so weiter.

1:07:25Und sowas geht dann aufs Internet übertragen weiter. Damit auch. Ja, genau. Okay, also wir wollen, ich glaube, wir haben Konsens zwischen uns zwei. Wir wollen den Kram verschlüsseln. Genau. Und wie machen wir das jetzt am besten? Da gab es ganz viele Überlegungen. Und ich würde sagen, die Nummer eins oder zumindest auf jeden Fall, was Mozilla am meisten verfolgt und was ich denke, was auch im Internet in der langen Frist sich halt eben ausrollen wird.

1:07:56Aktuell sehen wir davon ungefähr 10% von allen Firefox-Usern, ist DOH, DNS over HTTPS. Jetzt fragen sich natürlich viele, warum nehme ich jetzt in meinem schönen OSI-Layer, warum nehme ich jetzt etwas ziemlich weit unten und packe das auf die oberste Ebene, die ich überhaupt habe, auf dieses HTTPS oben drauf. Warum brauchen wir die komplexe Komplexität von HTTPS? Also weil das ja quasi TLS-Zertifikat auf HTTP oder das ist ja in HTTP 3 und QUIC mit drin und das dann wiederum auf UDP und dann quasi man baut diesen Turm und damit macht man das, während bisher DNS-Abfragen einfach UDP-basiert waren, ne? Richtig?

1:08:43Teilweise TCP, aber hauptsächlich UDP, richtig? Genau. Also einfach dieses Request-Response. Genau. Aber wahrscheinlich, weil man das sonst nicht verschlüsseln könnte, oder? Man könnte auf andere Seiten andere Art und Weisen verschlüsseln. Es ist natürlich immer, Verschlüsselung ist sehr kompliziert und Verschlüsselung ohne einen Handshake in einem asymmetric Krypto-Kontext ist doubly so. Also deutlich komplizierter nochmal. Genau, aber möglich. Also man hätte auch eigene Encryption-Protocols bauen können.

1:09:14Oder man hätte auch zum Beispiel auf HTB verzichten können. Also es gibt auch zum Beispiel DOT-Protocols. Genau, also es gibt ganz viele Alternativen, aber was ich denke, was sich durchsetzen wird, ist diese HTTPS, also über HTTPS, muss übrigens nicht über HTTP3, kann auch HTTPS H2 sein, äh, HTTP2. Darauf bauen wir das Ganze jetzt. warum? Einmal wegen der PKI, die Web PKI, die Public Key Infrastructure. Also die ganzen Certificate Authorities, die du ganz am Anfang erwähnt hattest, wie zum Beispiel Let's Encrypt und so weiter, ermöglichen es uns, im Internet uns gegenseitig zu authentifizieren zu können.

1:09:51Genau. Und am besten bauen wir das nicht nochmal neu. Das heißt, wenn wir ein bisschen im DNS-Sec-Feld, DNS-Sec hat sich nicht bis zumindest bis zum End-User durchgesetzt, leider. Und stattdessen machen wir das Ganze quasi jetzt nicht neu, sondern bauen halt eben auch was Bestehendes, nämlich HTTPS. Dann zusätzlich, es gibt riesig viel Software rund um mit HTTPS. Das bedeutet, wenn ich einen DNS-Server bauen möchte, dann kann ich halt eben einfach eine dieser vier Bibliotheken benutzen.

1:10:20Also das ganze Tooling existiert natürlich. Dann können wir jetzt, wenn wir auf HTTPS aufbauen, können wir darüber zum Beispiel auch auf Quick aufbauen, also auf HTTPS 3. Und wie wir ganz am Anfang besprochen hatten, als wir diese Bridge zu Quick gebaut haben, Quick hat zum Beispiel Zero RTT. Das bedeutet, wenn jetzt andere Leute sagen, DOH ist viel zu viel Overhead, also UDP schicke ich einfach nur eine Request-Response, habe ich alles, das ist viel zu schlimm mit DOH.

1:10:50Kann man da gleichzeitig sagen, nein, eigentlich nicht, weil mit DOH über HTTP3 kann ich Zero RTT machen und habe dann genau oder ähnlich viel Overhead, How about the ganzen encryption of it? Also ganz, ganz viele kleine Vorteile, die uns halt eben ermöglichen, einfach dieses DNS auf HTTPS oben drauf zu packen. Und das halt eben die beste Lösung ist unserer Meinung nach. Ja, cool. Genau. Da meintest du jetzt gerade eben, du hast wahrscheinlich irgendeine URL auf deinem Router konfiguriert. Das ist genau das Problem.

1:11:24Es ist nicht so, dass jetzt einfach nur die Clients halt eben mitspielen müssen und halt eben HTTPS können müssen, sondern es sind halt eben leider auch all die Server. Und die meisten ISPs zum Beispiel, die bieten gar kein DOH an. Also die geben dir klassisch DNS Route 53 über Port 53, ja, bieten sie dir an, aber halt eben den DOH Endpoint geben die meisten ISPs gar nicht. Und deswegen hast du wahrscheinlich in deinem Router da zum Beispiel Cloudflare angegeben, weil Cloudflare halt eben einen DOH Endpoint anbietet, also Cloudflare hat ja zum Beispiel 100, 101 und das ist halt eben unter anderem auch über DOH errichtbar.

1:12:04Genau, ich habe in meinem Router dann eben quasi den Standard von meinem ISP, also durchgereichten DNS-Server, den habe ich dann ausgetauscht, eben durch die IP-Adresse von Cloudflare's DNS-Servern, die das dann können. Ja, das ist schon mal eine super Sache. Also das bedeutet, dein Rechner macht eine Standard-DNS-Anfrage zu einem Router und dein Router macht dann die verschlüsselte Verbindung zu Cloudflare. 1A, super. Aber wäre es nicht noch cooler, wenn es in deinem Rechner direkt machen würde?

1:12:35Ich weiß aber nicht, ob man eine Fritzbox quasi auch als DNS-Server EOH unterstützt. Genau. Da gibt es jetzt zwei Wege. Also entweder dein Rechner vermindert sich direkt zu Cloudflare. Das ist ein Weg. Oder dein Rechner verwendet sich zum Router und dann weiter. Genau, wobei zu Cloudflare wäre ja blöd. Das wäre dann irgendwie schwierig für meine lokalen Geräte, wenn ich an die ran will. Ja, also was Firefox zum Beispiel da macht, also by default in den meisten Fällen macht Firefox kein DOH, also eben einfach Standard-DNS.

1:13:08In anderen Fällen, in manchen Ländern, aber auch in verschiedenen Konfigurationen, kann man ganz einfach einstellen in den Settings, kann es zum Beispiel DOH für alle externen IPs machen. Also zum Beispiel, wenn du jetzt auf Wikipedia.org gehst, würdest du dann zum Beispiel Cloudflare als DOH-Provider dem anfragen, hey, wer ist eigentlich Wikipedia.org? Aber gleichzeitig, wenn du auf deinen lokalen Netzwerk zugreifen willst, würde das dann immer noch über deinen lokalen DNS laufen.

1:13:37Das sehen wir aktuell in Firefox rund um die 11%. Andere Browser machen das auch, DOH. Betriebssysteme machen das zum Beispiel auch. Also auf Android gibt es auch eine DOH-Auktion und so weiter. Also langsam bewegt sich dieses Ökosystem in Richtung DOH. Das Problem ist, dass halt eben sehr viele Server oder Recursive Resolver das noch nicht anbieten. Okay. Aber somit haben wir jetzt quasi den ersten Schritt unserer Pipeline, also von, ich gebe was in der UL-Leiste oben ein, drücke Enter, bis halt eben, ich habe eine Request-Response und habe dann eine Index-HTML vor mir.

1:14:18Genau, jetzt haben wir diesen ersten Schritt schon mal verschlüsselt, also wie resolve ich Wikipedia-Dot-All. Genau. Und dann gibt es jetzt noch ein Zwischenstück zwischen der eigentlichen Transport-Connection, also Quick, und DOH. Dann können wir jetzt noch in ECH eingehen, wenn du möchtest. ECH, genau. Und das wäre jetzt noch der letzte kleine Bindeglied dazwischen. Ja, hau raus. Da habe ich noch eine Frage zu ADTV3, die mir noch eingefallen ist aus der Praxis.

1:14:48Genau, tatsächlich. Ja, also wie sich mal wieder herausstellt, das Internet ist deutlich komplexer, als man denkt. Genau, also wir haben DOH, wir resorven damit wikipedia.org und haben das komplett verschlüsselt gemacht. Das Ganze läuft auf HTBS, das Bild nach außen hin, wirkt es einfach so, als hätten wir einfach einen HTTP-Request um ihn gesteckt. Niemand weiß, dass das DOH ist. Ja, okay. Dann ist auch sozusagen die Absicht des Requests nicht so offensichtlich.

1:15:15Genau. Man weiß noch nicht mal, was das denn eigentlich war. Gut, das Ding geht an Cloudflare und das geht an den DOH-Endpoint. Also es ist suggestiv, aber man weiß es nicht sicher. Genau. Das ist auch wiederum ein Censorship-Resistance-Mechanismus. Muss, umso mehr wir auf HTTPS aufbauen, also umso sehr, umso mehr wir auf eine, Ebene bauen, die selbst verschlüsselt ist, HTTPS, umso weniger kann man Zensur ausführen. Ja. Weil alles dann einfach wie HTTPS aussieht. Mhm.

1:15:58Okay, also wir haben den DOH, wir haben die Name Resolution gemacht. Jetzt wollen wir uns an Wikipedia.org verbinden. Und jetzt kommt der kleine Gottschach im Internet. Wenn ich einen TLS-Handshake mache, dann schicke ich in dem TLS-Handshake immer noch die SNI mit, den Server Name Indicator. Und zwar sage ich in dem TLS-Handshake, hey, das hier ist ein TLS-Handshake für wikipedia.org. Ich habe super diese Name-Resolution encrypted gemacht. Schickt dann ins Internet raus, hey, übrigens, diese TCP-Connection, hier will ich den TLS-Handshake mit wikipedia.org machen. Das ist nicht ideal.

1:16:43Und idealerweise würden wir jetzt diese SNI, den Server-Name-Indicator, auch noch verschlüsseln. Genau, und da gab es verschiedene Efforts unter einem Encrypted SNI und so weiter. Und was jetzt inzwischen auch standardisiert ist in RFC, ist Encrypted Client Hello. In dem TLS-Handshake, die erste Message vom Client heißt das Client Hello und dann kommt Server Hello zurück. Und ECH ermöglicht es, diesen Client, diese Client-Message zu verschlüsseln.

1:17:13Das wird von Anfang an schon verschlüsseln und schon dieses Wikipedia.org schon verschlüsselt abschicken. So, wenn wir was verschlüsseln wollen, brauchen wir dafür auch immer einen Schlüssel, weil wir brauchen ja asymmetrische Cryptography-Mannähe. Also so rum ist ja spannend, ja. Den Schlüssel kriege ich aus dem DNS raus. Das bedeutet, ich mache einen DNS-Request für wikipedia.org und frage quasi den DNS-Server, hey, ich brauche übrigens CIP, und ich brauche auch noch den Schlüssel, mit dem ich meinen Title verschlüsseln kann.

1:17:45Ja, okay. Das bekomme ich alles vom DNS, und dann kann ich das Ganze verschlüsseln. So, und dann mache ich meinen Quick-Handshake, und ab dann, sobald meine Connection established ist, werde ich nur noch zwei Bit im Clear Text rauswenden. Und somit bin ich super verschlüsselt unterwegs. Das ist übrigens nicht, dass nur Firefox das macht, das machen auch noch andere Browser. Genau, ich erkläre es nur jetzt halt eben aus der Perspektive von Firefox.

1:18:09Das klingt alles super. Die Adoption von HTTPS ist großartig im Internet. Also ich glaube, da hatte ich auch eine Zahl. Wir sehen aktuell 92 Prozent des kompletten Internet Traffics verschlüsselt. 6 Prozent lokal und dann den Remaining ist HTP ohne Verschlüsselung. Also HTP, es hat geklappt auf dem Internet. Super. Ja. Quick machen wir ungefähr so 25%. Also wir sind auf dem richtigen Weg. Also das werden wir auch. Das ist auf 5V auch schon nicht übel.

1:18:41Genau. DOH machen wir ungefähr 10%. Gar nicht mal so schlecht. ECH machen wir in 0,3% der Fällen. Das machen wir sehr wenig. Ja, aber das liegt ja wahrscheinlich dann wiederum an den Servern von Wikipedia oder so, dass die das ja auch wieder können müssen, oder? Die müssen das können, es ist gerade erst ein RFC geworden und es gibt allerlei Caveats noch drumherum. Okay, naja gut, aber ich hatte ja eingangs erzählt, dass es vor zehn Jahren mit Let's End Quick losging und jetzt sehen wir ja, wo wir stehen.

1:19:17Hat sicherlich auch beigetragen, dass irgendwie Formulare nicht automatisch ausgefüllt wurden, mehr von den Browsern, weil die gesagt haben, das ist jetzt hier irgendwie keine sichere Umgebung und natürlich auch die ganzen Privacy-Leaking-Web-APIs, die dann zurückgestutzt wurden und nicht mehr auf HTTP liefen. Also sowas wie Geolocation, glaube ich, und Co. kannst du ja mittlerweile gar nicht mehr. Also die verweigern einfach ihre Mitarbeit unter HTTP.

1:19:45Und das war dann sozusagen, also das war dann so, der Pull war, hey, das ist cool und verschlüsselt und letzten Glück macht's dir leicht. Und der Push war, den man halt auch immer braucht, waren dann eben so diese, ganzen Death by a thousand Paper Cuts, die der Browser dann durchgeführt hat, dass man dann gesagt hat, so jetzt komm, holen ich mir das Zertifikat. Ja, da haben sich die Browser sehr viel eingesetzt. Und meiner Meinung nach genau das Richtige.

1:20:12Das Internet als heute, zumindest von der Verschlüsselungsperspektive, sind wir an einem ganz anderen Ort. An einem viel besser. Ja, auch vom Timing ganz gut. Also, das ist ja auch genau die Zeit gewesen, wo das ja im Grunde zugenommen hat, mit dem. Ja, dass eben Daten abgegriffen werden, Snowden und Co. 2013 war das ja, glaube ich, schon lange her. Genau, ich hatte noch eine Frage und zwar bei uns im Projekt haben wir, wir haben noch nicht auf HTTP3 umgestellt, wir haben das gerade gemacht, also wir jetzt nicht Cloudflare vor unsere Sachen hängen, sondern das mit eigener Infrastruktur machen.

1:20:55Und da haben wir das Staging-System umgestellt und als ich das ausprobiert habe, im Browser, da sah es gut aus und ich habe dann. Webpage-Tests gegenlaufen lassen und der hat mir gesagt, das wäre HTTP2 und wir sind dann irgendwann auf den Trichter gekommen, dass es so ist, dass die erste Verbindung zu uns, also mit HTTP2 gemacht wird. Weil es ja nur eine TCP-Connection ist, wird die dann weiterverwendet für die gesamte, oder für dann diese, die Seiten für alle anderen Ressourcen.

1:21:42Und dann lernt er dabei, dass dieser Server aber HTTP3 spricht. Merkt sich das? Und ab dem zweiten Request an den Server, ab der zweiten Connection an den Server spricht man HTTP3. Ist korrekt, oder? Ja, genau. Also, das hatten wir auch irgendwann. Das Internet muss sowohl in beider Richtungen immer compatible sein. Von HTTP1 auf HTTP2 haben wir es im TLS-Handshake geschafft. Im TLS gibt es das ALPN, Application Layer Protocol Name, Protocol Negotiation.

1:22:16Haben wir da das Ganze negotiiert und können dann die gleiche TCP-Connection benutzen. Jetzt sind wir allerdings in der Quick World. Das bedeutet, ich kann dann nicht, zum Beispiel in dem TLS-Layer von der TCP-Connection kann ich dann jetzt nicht ALPN sagen, übrigens HTTP3 und dann halt eben die gleiche TCP-Connection für HTTP3 benutzen. Weil HTTP3 immer nur auf Quick läuft. Genau, wir brauchen jetzt einen anderen Upgrade-Path, der ist fundamental anders als von H1 zu H2, HTTP1 zu HTTP2.

1:22:49Genau, und da gibt es jetzt zwei Wege. Und da gibt es verschiedene Behaviors von den Browsern. Ich sage einen. Ja, sehr gut. Einen hast du gerade schon gesagt. Achso, einen habe ich schon gesagt. Okay, dann weiß ich auch den anderen wahrscheinlich. Und zwar kann man das jetzt in seine DNS-Einträge eintragen. Das ist... Dass man HTTP3 spricht und dann wird die erste Connection direkt mit HTTP3 aufgebaut. Genau. Also wir hatten schon ganz lange den HTTP-Header als Service, um halt eben damit ein Server sagen kann, ich bin übrigens auch hier erreichbar.

1:23:23Und das haben dann die HTTP3-Leute genommen und haben sich gedacht, super, nehmen wir einfach das. Der Browser macht erstmal eine HTTP2-Connection, lernt dann, der Server kann übrigens auch HTTP3, speichert sich das ab für alle zukünftigen, Connections, macht vielleicht sogar optimistisch schon mal eine HTTP-3-Connection auf, damit wenn die funktioniert, dass ich die ab jetzt benutze, weil HTTP-3 in den meisten Fällen besser ist als HTTP-2. Also du meinst beim ersten Mal dann quasi beide Parallelen oder was?

1:23:54Genau, das ist teilweise zum Beispiel wird Firefox das machen, dass sich ja dem Firefox macht die HTTP-2-Connection auf, kriegt dann zum Beispiel über die IT-Index-HTML den HTTP-Header als Service h3-443. Also ich kann auch htb3. Und dann würde Firefox schon mal eine htb3-Verbindung dahin aufmachen. In der Annahme, dass wir wahrscheinlich noch mehr Requests senden werden und die ja dann auch über htb3 stattdessen senden können. Und es hat ja auch noch einen Vorteil, dass er nämlich dann das Token bekommt.

1:24:29Den Relumption-Token. Oh, sehr gut. Genau. Dass er im zweiten Besuch dann noch schneller unterwegs ist. Da hab ich gar nicht drüber nachgedacht. Sehr gut. Genau, den kriegen wir auch noch. Genau, das ist der eine Upgrade-Part, also über diesen als Service. Ist nicht ganz ideal, weil es ist immer auf dem zweiten Attempt. User gehen meistens immer auf die gleichen Websites. Meistens machen die User nicht ein, zwei oder drei, sondern zehn, zwanzig, fünfzig innerhalb von einer Woche in terms of connections zu einem Server.

1:25:03Das macht total Sinn, den dann zu speichern und ab da machen wir dann halt eben HCP3. Aber wir können es halt eben noch besser und das hast du auch gerade erwähnt, wir können ja eben HTTPS DNS-Record, so ein bisschen so ein Catch-all-Ding geworden, da können wir ja auch dreien schreiben, ach übrigens, ich spreche auch HTTP3, genau, und dann Firefox macht erstmal, oder die meisten Browser werden dann halt eben erstmal die DNS-Records sich holen, also ein A-Record, einen Quad-A, also IPv4, IPv6 und dann zusätzlich noch ein HTTPS-Record und in dem HTTPS-Record würde dann unter anderem drinstehen, das hier ist mein ECH-Key, also damit kannst du meine SNI verschlüsseln und ich spreche übrigens auch noch HTTB3 und so kann ich dann direkt auf den ersten Connection mit HTTB3 sprechen. Ja.

1:25:52Ja, genau. Das wollte ich nur, das fiel mir noch ein, weil wir das eben in der Praxis hatten und mich das erstmal irritiert hatte. Und dann kam mir darauf, das muss ja so sein, Webpage-Tests sind ja im Prinzip immer frische Instanzen. Die wissen ja von nichts. Das will man ja auch so haben. Man will ja quasi sehen, wie es im Worst-Case aussieht beim ersten Besuch. Und wenn man da keinen Repeated-Visit-Test macht, dann sieht man erstmal so, hm, HTTP2 merkwürdig.

1:26:25Aber das, was dann auch witzig war beim Repeated-Test, ich glaube, da kam Webpatch-Tests auch wiederum nicht mit klar, weil ich habe dann nur noch die HTTP2-Requests im Wasserfall gesehen. Also, und ich habe dann aus der, aus dem Fehlen der anderen Requests, weil die Seite hat ja schon offenbar abrufen können, geschlossen, dass das vielleicht eher ein Shortcoming vom Webpage-Test war und dass dann diese Ressourcen alle auf HTTP3 liefen und er dann einfach, Vielleicht ist auch das Waterfall-Tool oder das Netzwerk-Tool TCP-basiert und das greift dann natürlich nicht mehr.

1:27:02Ja, ich kenne mich selber nicht mit Web-Test aus. Ja, da kann man halt so schöne Sachen sich angucken. Ob ein HTTP-2-Server irgendwie die Prioritäten beachtet, die der Browser mitschickt oder ob der irgendwie einfach alles gleich rüberschiebt und dadurch eben Sachen, die wichtig sind, langsam macht und Sachen, die unwichtig sind, irgendwie schnell Ja. Wenn ich hier noch eine Sache, vielleicht, weil ich gerade eben einige Zahlen erwähnt hatte.

1:27:32Wahrscheinlich die spannendste Zahl dieses ganzen Introduction von ATB3. Wir haben jetzt allerlei Optimisierungen in HTB3 im Vergleich zu ATB3. Und der größte ist dieses OneRTT und ZeroRTT. Also dass ich Transport und TLS zusammen packe und auf die zweite Connection dann auch noch Zero-RTT, also direkt mal Request hin. Und wir tracken zum Beispiel in Firefox die Metrik Time to Request Start. Genau, das ist nicht der First Contentful Paint, aber Time to Request Start. Also nah dran.

1:28:09Und da im 75. Percentteil über die komplette Firefox-Population, sehen wir in HTP 1 und HTP 2 ungefähr 300 Millisekunden, 300 bis 350. Und mit HTP 3 sehen wir 150 Millisekunden. Das ist fast die Hälfte. Ja, das ist viel. Nun muss man statistisch natürlich jetzt dazu sagen, es kann natürlich auch sehr gut sein, dass diese ganzen HTP 3 Server auch einfach die besseren Server sind. Also zum Beispiel eine Firma, die sich leisten kann oder die Engineering Power hat, HTTB 3 auszurollen, die werden wahrscheinlich auch sehr gute Rechenzentren haben.

1:28:48Das ist auch dabei zu bedachten. Das bedeutet, dieser Gewinn an Latency ist nicht nur, weil sie halt eben HTTB 3 benutzen. Aber ich bin mir sehr sicher, dass es ein signifikanter Teil davon ist. Und der größte Teil hier wirklich, wir machen innerhalb von einem Roundtrip können wir schon Request werden. Ja, sehr geil. Alle diese Daten, die ich übrigens teile, sind alle öffentlich verfügbar. Also Priscilla ist ja sehr zurückhaltend immer in Daten sammeln.

1:29:20Wir wissen zum Beispiel nicht, auf welchen Origins-User unterwegs sind, aber alle aggregierten Daten, alle die wir sammeln, sind rein technische Daten, die geben wir dann auch allen zur Verfügung. Also kann man einfach mal online schauen, Firefox-Dataset und kann dann all diese als Public-Dataset halt eben einsehen. Ja. Versuche ich mal zu finden. Genau, ich gucke mal, ob ich das noch mit, also finde und in die Show-Los packen kann. Ja, das packe ich dir ja auch einfach mal in unser Nutzer. Ah ja, super, da unten.

1:30:00Genau, und ich habe jetzt noch eine, also wir sind, genau, wir nehmen ja schon eine Weile auf. Wir haben das super quasi abgezirkelt. Und ich wollte vielleicht noch eine Frage hinten anschließen, dass du, vielleicht kannst du nur ganz kurz was über die Web Transport API erzählen. Die ist jetzt nicht mehr ganz brandneu. Also ich habe mal nachgeguckt, also in Safari wird die zwar nicht unterstützt, aber in Firefox und den Chromium-Browsern sehr wohl. Auch eine ganze Weile schon.

1:30:37Und genau, Web-Transport habe ich persönlich jetzt noch nicht so oft gesehen, aber, ist im Grunde oder benutzt man da, wo man bisher vielleicht Web-Sockets benutzt hat und vielleicht in Zukunft auch für diese Datagram-Szenarien, die ja momentan gar nicht abbildbar sind, glaube ich, oder? Also nicht wirklich. Nicht als Web-Application, ja. Ja, genau. Ja, genau. Also du hattest schon richtig gesagt, ist quasi die. Nächste Evolution von Websockets. Genau.

1:31:14Web-Transport ist aktuell ein Draft bei der W3C und bei der ITF, aber wie du auch schon gesagt hattest, zum Beispiel Firehawks und Chrome haben es schon. Und soweit ich weiß, hat Safari bald Internet-Developer-Flag. Ich weiß nicht genau, wie es bei Safari heißt. Ja, genau, das ist entsprechend markiert, dass man das wahrscheinlich freischalten kann in den Developer-Settings, aber ist noch nicht geschickt. Und jetzt haben wir WebSockets, hat halt eben allerlei Probleme, die es vor allen Dingen halt eben dadurch hat, dass es zum Beispiel auf ATP 2 läuft und somit alles, weil dem auch von TCP wieder mitbekommt, also zum Beispiel Head-of-Line-Blocking.

1:31:53Und dieses Web-Transport ist quasi eine erneuerte API statt Web-Sockets, also einige Vorteile auf der Web-Plattform-Ebene rund um die APIs, also deutlich modernere APIs, aber dadurch, dass es auch auf HTTP3 laufen kann, hat es all diese Vorteile von HTTP3. Zum Beispiel kein Head-of-Line-Blocking. Oder wie du gerade meintest, haben wir jetzt plötzlich Datagrams in der Web-Plattform drin. Man kann solche Sachen wie Latency-Sensitive-Sachen wie zum Beispiel Videocalls ganz anders abbilden oder man kann zum Beispiel Spiel-State vom Online-Gaming irgendwie anders abbilden und so weiter. Also allerlei Use-Cases da.

1:32:37Genau. Aktuell gibt es noch keine großen User von Web Transport, aber das ist vielleicht auch einfach ein Henne-Ei-Problem, weil auf der einen Seite supporten es halt eben noch nicht alle Browser, aber auf der anderen Seite gibt es auch noch nicht so viele User. Der größte Effort in dem Bereich ist Media Overquick. Media Overquick ist bei der ITF eine große Working Group, die halt eben versucht, also den Web-Media-Stack auf einen neueren Transport-Stack, also auf Web-Transport obendrauf zu bauen.

1:33:09Naja, okay, auf Web-Transport aufbauen. Genau, also die letzte Meile zum Browser ist dann halt eben über Web-Transport. Ja, es ist ein ziemlich großes Projekt, wird auch noch viel daran gearbeitet. Zum Beispiel die ITF ist aktuell bei Draft14. Ich denke, da kommt noch mehr. Das heißt Media over Quick oder wie ist es? Genau, M-O-Q, Media oder Quick. Eigentlich sollte es heißen Media oder Web Transport, aber Web Transport im Endeffekt ist einfach nur ein ganz dünner Wrapper um die ganzen Quick Primitiven, nämlich Streams und Datagrams.

1:33:50Wahrscheinlich bräuchte es auch dann für Web-Transport so eine Library. Ich weiß nicht, wie die hieß damals, aber ich weiß noch so um 2011, 12 rum, da gab es doch für Node.js so eine Library, die so, wenn man Web-Sockets hatte, hat das Web-Sockets benutzt und sonst, wenn AJAX möglich war, hat man AJAX benutzt, ist man da auf zurückgefallen und dann gab es irgendwie noch HTTP-Long-Polling, so als Last Resort oder so. Und man bräuchte im Grunde jetzt eine Library, die Web-Transport nutzt und eben vielleicht auf Web-Sockets zurückfällt.

1:34:27Ja, also ich würde sagen, eine erste Iteration werden halt eben die Leute sein, die das einfach direkt ausprobieren, also selber implementieren. Dann denke ich, dass irgendwann halt eben Libraries existieren werden, die halt eben ein bisschen Fallback handeln. Und dann würde ich denken, dass es irgendwann so weit supported ist im Browser und auf dem Server, dass halt eben das gar nicht mehr verändern. Relevant ist, dass hoffentlich halt eben irgendwann alles Web-Transport spricht.

1:34:57So wie das mit Web-Sockets ja auch heutzutage der Fall ist. Ja, ja. Genau. Ja, super. Mensch, das war mega gut. Ja, wir haben riesig viel besprochen. Wie funktioniert das Internet? Genau, wie funktioniert das Internet? Aber das ist ja auch wichtig. Das hatte ich auch in der Vorbesprechung gesagt. die finden das einfach gut, also wir nutzen das alles und im Grunde könnten wir uns auch einfach damit gar nicht befassen. Außer wenn wir uns dann doch damit befassen müssen, weil das ist ja dann immer so, oder wie wenn man irgendwie, eine Kamera bedient, dann will man diese fette Anleitung ja auch nicht lesen, dann will man erst mal machen und tun und dann kommen so Fragen und dann wundert man sich und warum ist dies und das und jenes so und dann, interessiert mich das irgendwie dann doch, was da dahinter steht.

1:35:53Und wenn ich die Mechaniken kenne, dann kann ich auch einfach besser verstehen, warum Dinge sind, wie sie sind. Ja. Und ich finde es auch total spannend, also total interessant, weil, Also mich hat das null gelangweilt. Ich fand es super. Ich hoffe, unsere Hörerinnen auch. Genau, und auch direkt mal der Aufruf, wenn ihr die Folge gut fandet, dann schreibt uns das mal. Oder dem Max würde mich mal interessieren, was ihr von so einem Low-Leveling Thema haltet.

1:36:29Sehr gerne, Jan. Genau. Ja, vielen, vielen Dank, Max, für deine Zeit. Danke für die Einladung. Ja, gerne. Ja, ich würde ja sagen, gerne wieder. Die Frage ist, was und wann? Das wisst ihr nicht. Also HTTP 4, haben wir schon gesagt, das wird es vielleicht so schnell nicht geben. Das nicht. Solche Sachen wie Mask sind, glaube ich, sehr spannend. Also was können wir jetzt alles noch auf HTTPS obendrauf bauen? Genau, das hat allerlei Vorteile. Dann, ja, ein Webtransport gibt es mal ganz viel. mit Media Over Quick unter anderem.

1:37:09Dann ganz groß ist aktuell Happy Eyeballs zum Beispiel, ist auch ein ITF-Effort, wie wir halt eben noch schneller jetzt über verschiedene Protokolle connecten können. Und dann, ja, DOH ist nochmal ein viel größeres Fass, als wir heute aufgemacht haben. Ja, da ist halt so das Problem, da gibt es dann so bei Happy Eyeballs und was was anderes, was du gesagt hattest. Mask? Ja, Mask. Gibt es da eine Connection zur Webplattform, zu so quasi Menschen wie uns, die mit...

1:37:50Ja, also Happy Eyeballs ist ganz viel, wie kann ich, also das ist sehr relevant auf der Serverseite. Also wie kann ich meinen Server so positionieren, dass ein Browser möglichst schnell halt eine Connection aufbauen kann zu meinem Web-Server? Also das ist, glaube ich, ein sehr spannender Aspekt. Mask ist eher für die relevant, die sich mit VPNs beschäftigen oder generell mit Proxying. Also wie kann ich Sachen in einer anderen Sache tunnel? Ja, genau. Das hatte ich nämlich da auch so grob rausgelesen.

1:38:21Es ist so eine Art VPN auf HTTP, in HTTP eingebettet sein soll. Genau, aber vielleicht machen wir so eine richtig knüppelharte Folge nochmal, wo wir dann diese ganzen krassen Sachen machen. Ja, gern. Ja, cool. Dann, genau, vielen Dank auch fürs Zuhören. Wenn ihr Fragen habt oder Lob, dann, wie gesagt, gerne her damit und machen wir jetzt den Deckel drauf. Nächste Woche geht's weiter. Ah ja, genau, da hat sich wieder die Dreifaltigkeit aus Kiki, Stefan und Peter zusammengefunden und Randon und lässt dann ab über Dinge.

1:39:05Mutmaßlich Typescript oder vielleicht loben sie die Dinge auch. Typescript und React könnte das Thema sein. Und das wird bestimmt lustig. Da höre ich selber auch schon auf jeden Fall rein. Genau, danke schön, liebe Grüße nach Berlin und genau, bis bald. Lieben Dank, tschüss. Tschüss. Beep. Beep. Beep. Beep.