Wir verwenden immer noch TCP. Und wo stehen wir jetzt? Wir befinden uns auf der Transportschicht. Wir versuchen, Daten zwischen einer Anwendung auf einem Computer und einer Anwendung auf einem anderen Computer auszutauschen. Wir wollen diese Verbindung zuverlässig oder schnell gestalten. Im vorherigen Video haben wir also Mechanismen wie die Sequenznummer und die Bestätigungsnummer vorgestellt. Und wir haben die Idee, dass es eine Auszeit geben könnte. Lass uns eine Erinnerung einrichten. Wir haben also einen Sender und einen Empfänger. Das ist ziemlich merkwürdig, nicht wahr? Lass uns das in Ordnung bringen. Wir hatten also die Sequenznummer (SEQ) und die Bestätigungsnummer. Ich werde so tun, als wären das einfach nur ganze Zahlen. Das stimmt in Wirklichkeit nicht, aber tun wir mal so, als ob . In einem groben Modell würden wir Folgendes senden: Dies sind unsere Daten und dies sind die Daten mit der Sequenznummer eins. Und ich lasse hier etwas Platz, und Sie werden sehen, warum. Und ich werde eine Bestätigung zurücksenden, um mitzuteilen, dass wir die Daten erhalten haben. Das wird aber sehr langsam sein, wenn wir nur ein Datenpaket senden. Ein Datenpaket also etwa 1.500 Bytes groß. Das sind nicht viele Daten. Und wenn Sie eine dieser E-Mails senden, auf eine Bestätigung warten, eine weitere senden und wieder auf eine Bestätigung warten, wird das furchtbar langsam sein. Wir möchten viele davon gleichzeitig verschicken. Äh, sagen wir 1 2 3 4. Also, das wäre… Hier ist unser Traum. Wir senden diese fünf und bestätigen dann fünf weitere, wobei diese Bestätigung eine kumulative Bestätigung darstellt. Wir sagen: Okay, wir haben alles auf fünf hochgerechnet. Dies können wir nun als einen Flug von Datenpaketen bezeichnen. Es handelt sich also um Flüge oder Pakete, die sich noch im Flug befinden und für die wir noch keine Bestätigung erhalten haben. Sie als Absender können sich also sicher sein, dass Sie so und so viele Pakete versendet haben. Nun, soweit Sie wissen, existieren sie da draußen auf der Welt. Du weißt nicht, wie groß das Netzwerk ist, mit dem du verbunden bist, denn schließlich musst du dich mit allen verbinden, richtig? Sie könnten in Melbourne sein, sie könnten in Peking sein, sie könnten gleich nebenan sein. Es könnte eine riesige, wunderbare Glasfaserverbindung geben, oder es könnte sich um ein schreckliches Stück nasser Schnur handeln, das etwa zwei Bytes pro Jahr benötigt, und man muss mit dem arbeiten, was auch immer das ist. Vielleicht läuft es ja über einen Satelliten und das dauert sehr, sehr lange . Wie gehen wir damit um, dass wir die Größe dieses Netzwerks nicht kennen? Wir wissen nicht, wie lange es dauern wird, bis dies wieder der Fall ist. Wie können wir das effizient umsetzen? Bei Stauvermeidungsmechanismen besteht zudem das Problem der Umlaufzeit. Unser Ziel ist es, zu erkennen, wann es zu einer Überlastung des Netzwerks kommt. Mhm. Aber es gibt kein solches Netzwerk. Es ist nicht so, als gäbe es dort einen Stauanzeiger wie auf der Autobahn, der sagt: „Langsam fahren. Stau voraus.“ Ja? Wir brauchen einen Mechanismus, der das quasi automatisch erledigt. Welche Anzeichen könnten wir also verwenden, um auf ein Problem hinzuweisen? Nun, ich nehme an, Sie müssen die Zeit messen, die es dauert, bis die Bestätigung eintrifft. Ja, ja, ja. Das ist also wirklich wichtig. Wir nennen das also RTT, die Round-Trip-Time, und diese Round-Trip- Time ist für uns wirklich entscheidend, nicht wahr? Das ist also eine Sache, die wir auf jeden Fall tun können. In Ordnung. Neben den Hin- und Rückreisezeiten gibt es noch ein paar andere Dinge, die wir tun könnten. In Ordnung. Mhm. Ja, nun ja, man könnte sich ansehen, was sonst noch so los ist, zum Beispiel frühere Erfahrungen. Ja, ja, ja, absolut. Wir können uns also unsere bisherigen Erfahrungen mit der Hin- und Rückreisezeit ansehen. Wir begeben uns also in eine Welt, in der wir die Umlaufzeit messen und uns fragen: Schwankt sie? Die RFC, mit der wir es zu tun haben, die RFC, denken Sie daran, sind unsere Regeln, unsere Bitte um Kommentare ist so etwas wie die Bibel für uns Internetnutzer, die unsere Regeln festlegt. Und hier befassen wir uns mit RFC 5681 über Staukontrolle. Die TCP-Standards schreiben nun bestimmte Dinge vor, die Sie tun müssen. Sie haben diese Art von schöner Sprache, in der es heißt: Du solltest dies tun, du musst dies tun und du kannst dies tun. Es gibt eine Art Hierarchie. Ähm, einige Dinge im Übertragungssteuerungsprotokoll sind unerlässlich. Manche Dinge sind möglich. Ein gewisser Spielraum besteht. Wir nennen sie Aromen. Mit der Weiterentwicklung des Lebens und des Internets ändern wir also auch die von uns verwendete TCP-Variante . Heutzutage verwendet fast alles einen sogenannten Cubic-Aromen. Das ist derzeit die beliebteste Variante. Und der Geschmack hängt im Grunde davon ab, wie wir auf diese Signale reagieren. Wann sagen wir, dass ein Datenpaket verloren gegangen ist? Und wie reagieren wir darauf? Der wichtigste Reaktionsmechanismus besteht in der Idee eines Überlastungsfensters. Als wir das letzte Mal so etwas gemacht haben, haben wir dieses Fenster abgespielt, und ich sagte: „Nicht jenes Fenster.“ [Gelächter] Und mit „Fenster“ meinen wir die Anzahl der Pakete, die sich derzeit im Netzwerk befinden. Es handelt sich um die Anzahl der Bytes, von denen wir glauben, dass das Netzwerk sie verarbeiten kann. Es gibt zwei Fenster. Nun, ich werde diesen Punkt nur kurz behandeln, denn er ist eigentlich nicht so wichtig. Dieses Fenster hier ist also unser Empfangsfenster. In den Anfängen des Internets befand sich der Empfänger wahrscheinlich im selben Labor wie Sie, nur um das Experiment zu ermöglichen. Vielleicht lief er etwas langsam und sagte dann: „Hey, ich habe Platz für 100 Kilobyte Daten. Senden Sie mir nicht mehr als 100 Kilobyte. Ich kann das nicht verarbeiten.“ Und das wird im Paketheader gesendet. Das bedeutet also, dass Sie nicht mehr als diese Anzahl Bytes an Daten in der Welt haben möchten, da Ihr Empfänger sie sonst möglicherweise verwerfen muss, weil er damit nicht umgehen kann. Das ist in der Realität nicht wirklich so wichtig, oder besser gesagt, es ist in der Welt nicht so wichtig wie das Staufenster. Das Überlastungsfenster wird vom Sender und Empfänger überwacht, und sie prüfen ständig, „Wie viele Daten kann dieses Netzwerk meiner Meinung nach senden?“ Es gibt zwei Signale, die wir uns ansehen könnten. Die meisten von ihnen schauen sich einfach nur ein verlorenes Signal an. Die meisten TCP-Varianten prüfen also lediglich, ob tatsächlich ein Paket verloren gegangen ist? Ja? Diese Bestätigungen sind also nummeriert, und wenn wir keine Bestätigung erhalten, wenn keine Rückmeldung kommt, oder, wie wir auch gesagt haben, „wenn die falsche Nummer einer Bestätigung zurückkommt“. Stellen wir uns also vor, dieses Paket stirbt zweimal. Dann teile ich es mit . Also, hier ist die Zahl zwei, hier die Zahl drei, vier und fünf. Paket zwei ist irgendwo verloren gegangen. Also, was ich hier tatsächlich zurücksenden werde, ist ACK eins ACK eins ACK eins nochmals. Also, ich sage immer wieder ACK eins, ich habe Paket eins erhalten. Ich habe ein weiteres Paket erhalten, es war nicht das, was ich wollte. Ja? Denken Sie daran, dass wir in diesen Dingen nicht zu viele Informationen vermitteln können. Das sollte man sich einfach vor Augen halten. Wir können nichts Kompliziertes sagen wie: Ich habe die Pakete 1, 3, 5, 7 und 8 erhalten, aber zwei fehlen, und könnten Sie mir bitte helfen? Zu viele Daten. Ja, so ist dieser Mechanismus nicht konzipiert. Das alles steckt in einer Kopfzeile. Wir wollen keine Informationen im Umfang eines Telegramms versenden. Wir möchten so wenige Informationen wie möglich übermitteln, um unsere Aufgabe zu erledigen. Deshalb verwenden wir eher ungewöhnliche Signale. Es gibt auch andere Mechanismen, die das leisten könnten. Jetzt ist nicht die Zeit, sich damit zu befassen. Wir senden also diese ACK-Nachricht und senden sie wiederholt, um mitzuteilen, dass dieses zweite Paket fehlt. Bis wir also ein ACK erhalten, das die Sequenzpakete eins und drei weitere bestätigt. Dies ist ein dreifaches Duplikat. Und nun vermuten wir äh [schnaubt], dass mit Paket zwei wohl etwas Schlimmes passiert ist . Dafür muss ich einige Dinge erledigen. Was ich dafür tun muss, ist natürlich, dass das zweite Paket erneut verschickt werden muss. Aber jetzt muss ich mir überlegen, ob ich das Netzwerk überlaste. Sende ich zu viele Daten? Noch schlimmer als ein dreifaches Duplikat zu erhalten, wäre es vielleicht, wenn ich sie alle verschicken würde. Und nichts. Gar nichts . Nichts kommt zurück. Wenn ich jetzt also alle Daten sende, kommt nichts zurück. Ich glaube, du hast… Nun, vielleicht ist mein Netzwerk katastrophal überlastet, oder? Wenn ein Datenpaket verloren geht, beispielsweise weil ein Puffer übergelaufen ist oder weil es einfach nur zufällig beschädigt wurde oder irgendetwas schiefgelaufen ist. Aber wenn ich gar nichts bekomme, wenn ich nur eine Auszeit kassiere, denke ich jetzt: „Mein Gott, hier herrscht aber ein ziemliches Gedränge.“ Hier kommen also die verschiedenen TCP-Varianten ins Spiel . Wir brauchen also noch ein Blatt Papier. Wir müssen uns überlegen, wie ich meine Fenstergröße weiterentwickeln kann. Also, grob gesagt, ich nenne es mal so, obwohl es eigentlich eher eine Art Uhr zwischen den Bestätigungen ist. Und das ist das Ausmaß des Staus, des C W N D. Nun, ich fange hier etwas ungewöhnlich an, aber Sie werden gleich sehen, warum. Wenn ich alle meine Pakete versende, zählen wir sie alle heraus, zählen sie alle zurück, und das ist ein Erfolg. Ich werde mein Fenster ein Stückchen hochkurbeln. Ich habe also eine Runde Päckchen gezählt, alle sind zurückgekommen. Großartige Neuigkeiten. Das Netzwerk ist also vielleicht doch etwas größer, als ich dachte. Man kann es also gewissermaßen pushen. Ja, ja, ja, ich werde es versuchen [räuspert sich]. Ja, 65 Meilen pro Stunde sind gut. Versuchen wir es mit 70. 70 war gut, versuchen wir es mit 75. Wir werden also die Fenstergröße schrittweise erhöhen. Okay, es wird immer größer. Aber wenn wir verlieren, werden wir den Ball wieder zu Boden werfen. Wir werden es wahrscheinlich halbieren . Also, wir halbieren vielleicht unser Fenster und vergrößern es dann langsam wieder . Wenn ich das dreifache Duplikat bekomme, werde ich es halbieren. Bam, bam, bam. Und fang an, es langsam wieder hochzutreiben. Theoretisch erhalten wir so eine Art Sägezahnmuster. Im Falle eines katastrophalen Verlustes müssten wir vielleicht von vorne anfangen, aber ich habe diesen Teil ausgelassen, weil ich noch nicht wirklich darüber gesprochen habe, wie wir angefangen haben. Denn was wir erreichen wollen, ist Folgendes: Diese Fenster können recht groß sein und eine beträchtliche Menge an Daten enthalten. Und wenn wir damit anfangen, es langsam aufzubauen. Oh, ich habe dem Ganzen keinen Namen gegeben. Wir sollten diesen Namen verwenden. Wir nennen dies AIMD, additive Steigerung multiplikative Abnahme. Ich werde das Fenster um ein Paket vergrößern, wenn wir alle erfolgreich zurückbekommen, aber wenn ich eine Überlastung feststelle, werde ich den Vorgang schnell beenden. In Ordnung? Ich möchte die Dinge nicht schleichend verschlechtern und das ohnehin schon überlastete Netzwerk weiterhin überfordern. Also, additive Steigerung, ich tauche um eins auf. Multiplikative Verringerung, also halbieren. Aber zu Beginn wollen wir etwas aggressiver vorgehen. Denn wenn wir anfangen und ein Paket senden, und dann zwei, drei, vier, fünf Pakete, dann ist das Leben zu kurz. Ja , genau. Das Leben ist viel zu kurz. Es wird noch eine Weile dauern, bis wir tausend Pakete versenden. Wir haben also vielleicht einen der schlimmsten Namen in der Computerbranche, und wir haben das, was wir hier „langsamer Start“ nennen. Wir nennen es einen langsamen Start, weil es ungeheuer schnell geht. Ich weiß. Ich habe es nicht benannt. Ähm nein, es geht darum, den langsamen Start zu überwinden. Also, ich werde jetzt die Fensterpaketnummern angeben, was ich eigentlich nicht tun sollte. Eigentlich müsste es in Bytes angegeben werden, aber um es einfacher zu machen. Also, ich werde ein Paket senden. Schau, ob es wiederkommt. Ich werde jetzt zwei schicken. Nun werde ich [räuspert sich] vier senden. Jetzt schicke ich acht. So, ich schicke jetzt 16. Hoch hoch hoch hoch hoch, es geht nach rechts. Die Anfangsphase ist also durch exponentielles Wachstum gekennzeichnet. Nur um uns aus dieser Sackgasse herauszuholen, in der alles wirklich sehr, sehr langsam vorangeht. Und wenn wir dann den ersten Verlust hatten und die Verbindung ordnungsgemäß funktioniert, werden wir zur additiven Zunahme und multiplikativen Abnahme übergehen. Man könnte also bis auf 1024 hochschnellen, dann aber Verluste erleiden, also werden wir wieder nach unten gehen und zu diesem AIMD zurückkehren. Und hier kommen wir zu den Geschmacksrichtungen, denn erstens, wie bereits erwähnt, gilt: „Okay, wenn wir diese Duplikate zurückbekommen, können wir auf einen Verlust schließen.“ Es könnte aber auch zu einem Timeout- Verlust kommen, weshalb wir das Spiel etwas später beenden werden. Wie lange müssen wir warten? Mhm. Wir denken also an die Gesamtreisezeit zurück. Äh, hier kommen verschiedene Algorithmen zum Einsatz, aber wir werden ein Vielfaches dieser Umlaufzeit warten. Wir werden also messen: „Oh, es hat 0,1 Sekunden gedauert, bis alle diese Pakete verarbeitet waren.“ Ich werde ein Vielfaches davon abwarten und dann sagen: „Wenn wir bis dahin keine Bestätigung erhalten haben, ist etwas wirklich Schlimmes passiert.“ Das war’s . Genau dort wird das Timeout an die Umlaufzeit angepasst . Das bedeutet, dass wir denselben Algorithmus sowohl für ein Rechenzentrum als auch für eine Strecke nach Australien einsetzen können, wo die Laufzeiten sehr, sehr unterschiedlich sind. Derselbe Algorithmus oder sogar bis hin zu einem Satelliten kann mehr oder weniger derselbe Algorithmus funktionieren. Ähm, besorgt euch was Vernünftiges, denn sie müssen sich erst an die Hin- und Rückreisezeit gewöhnen. Die Leute sehen das und wollen sofort daran herumtüfteln und sagen: „Oh, na ja , schau dir das mal an.“ Ja, das scheint eine Verschwendung zu sein, nicht wahr? Und im Laufe der Jahre wird sich genau zeigen, wo man seinen langsamen Start beendet, wann man ihn halbiert und wann man ihn erhöht. Und deshalb haben wir am Ende all diese Geschmacksrichtungen, wie zum Beispiel… Und ich sagte ja schon, in dem Moment, in dem… Oh, die Geschmacksrichtung des Monats ist tatsächlich Cubic, was die meisten… äh… ich glaube, die Leute werden mich umbringen, wenn ich das falsch wiedergebe. Ich glaube, Windows, Mac und Linux verwenden alle diese. Es gibt noch andere Dinge, die sie verwenden können. Manche dieser Algorithmen analysieren die Umlaufzeit und sagen: „Oh, die Umlaufzeit steigt. Ich werde die Verbindung sperren, falls dies auf eine Überlastung hindeutet.“ Das ist also eine andere Möglichkeit. Die meisten von ihnen arbeiten jedoch mit dem Verlustsignal. Die Leute sehen sich das an und denken: „Das könnte ich besser machen. Da lässt sich bestimmt noch was verbessern. Was wäre, wenn wir die Bandbreite halbieren oder sogar um drei Viertel reduzieren?“ Wir sollten uns also die Situation in der Praxis ansehen und feststellen, dass sie nicht so perfekt aussieht wie hier. Und wir werden auch sehen, warum … Wenn wir an die Anfänge dieses Netzwerks denken, waren die frühen Netzwerke wirklich langsam, nicht wahr? Man konnte froh sein, wenn ein paar Kilobit pro Sekunde durchkamen. Heutzutage hingegen denkt man: „ Ich habe zwar einen Gigabit- Anschluss, aber der reicht nicht wirklich aus.“ Und ja , wir alle wollen mehr Bandbreite, richtig? Und dann heißt es: „Oh, könnte ich nicht zehn Glasfaserkabel zu mir nach Hause bekommen?“ Wir werden uns das mal in der Praxis ansehen, ein paar echte Datenpakete analysieren und feststellen, dass die Situation für TCP nicht so reibungslos ist, wie sie scheint. Ich habe es hier vorgestellt. Was bedeuten also die verschiedenen Farben ? Sie geben Aufschluss über die Art der Protokolle und welches Protokoll jeweils verwendet wird . Wir werden später sehen, dass einige schwarze Symbole auf ein schwerwiegendes Problem hinweisen. Dieses hier zeigt an, dass ich es markiert habe. Wir werden nun diesem Datenstrom folgen, von dem ich hoffe, dass er der richtige ist. Ja, das ist er. Ich lade hier eine große Datendatei – ich glaube, sie ist etwas über ein Gigabyte groß – von meinem virtuellen Server in Manchester herunter, über eine relativ kurze Netzwerkverbindung. Wireshark soll diesen TCP-Datenstrom rekonstruieren. Wireshark findet also alle zugehörigen Pakete, sodass wir uns die Kommunikation ansehen können, beginnend mit SYN-ACK-ACK. Wir werden sehen, dass die Dinge etwas komplexer sind, als wir es im Unterricht lehren. Hier finden wir die Pakete direkt am Anfang des Datenstroms, genau wie ich es beschrieben habe. Wir haben also eine SYN-ACK- und eine ACK-Nachricht. Sofort ändert sich die Situation, da wir jetzt die Transportschichtsicherheit (TLS) darüber haben . Diese Schicht sorgt für die Sicherheit, gehört aber nicht zu Schicht 4. Daher kümmern wir uns heute nicht darum. Sie gewährleistet jedoch die Sicherheit. Wir haben also eine Menge Verschlüsselungsalgorithmen. [schnaubt] Und nun wieder etwas TLS . Hier sehen wir die Quell-IP 5.28.62.245. Das ist mein Server in Manchester. 192.168.68 ist eine lokale Adresse, die manch einer wiedererkennen dürfte. Das ist eine lokale Adresse in einem Heimnetzwerk. Das ist also mein Rechner zu Hause. Und hier steht, dass der Server Byte Daten und eine 66 Byte Bestätigung als Antwort gesendet hat. Wenn Sie im Netzwerkbereich arbeiten, würden Sie sich bei dieser Zahl 2766 sofort Sorgen machen, denn Das ist größer als es sein sollte. Ähm, und es stellt sich heraus, dass ich eine Menge Mesh-Technologie in meinem Heimnetzwerk habe. Dadurch werden Pakete auf eine Weise zusammengefügt, die ich nicht erwartet hatte. Wir sehen also bereits etwas, das nicht mehr dem sauberen, reinen Netzwerksignal entspricht, das wir normalerweise senden würden. Das ist nicht das, was über das Internet gesendet wurde . Mein Heimnetzwerk verbindet sie irgendwie. Außerdem wird das Ganze regelmäßig von diesen TLS-Paketen getaktet. Sie sorgen also für zusätzliche Sicherheit . Hier sehen wir vier wieder zusammengesetzte TCP-Segmente mit 8.000 Bytes. TLS fügt also die zusätzlichen Sicherheitsinformationen zu den Daten in diesen TCP- Paketen hinzu. Hier sehen wir ein Paket. Wir sehen die zugehörige Sequenznummer und die Bestätigung, die zurückkommt. Als ich von Sequenznummer und Bestätigung sprach, meinte ich, dass ich eine vereinfachte Version zeige, denn diese Sequenznummern und Bestätigungen sind nicht einfach nur 1, 2, 3, 4. Sie geben an, welche Bytes wir gerade betrachten. Und im Fall der Bestätigung, welches Byte wir erwarten. Schauen wir uns an, wie sich dieses TCP-Fenster entwickelt. Ich habe ein kleines Code-Snippet geschrieben, das die Aufzeichnungsdatei meines Heimnetzwerks durchläuft. Es fragt alle 100 Millisekunden ab: Wie viele Bytes haben wir gesendet? Es läuft gerade . Seit Beginn der Datei sind 23, 24 Sekunden vergangen. Hier ist die Anzahl der übertragenen Bytes. Es ist nur ein kleines Python-Snippet, das ich schnell zusammengeschrieben habe. Ich gebe Shawn den GitHub-Link, falls er es in seinem eigenen Netzwerk ausprobieren möchte. Anschließend wird ein einfaches Diagramm im Matplotlib-Stil ausgegeben. Vergrößern wir es. Und hier sehen wir Folgendes. Ist das nicht eine schöne Sägezahnkurve? Wenn diese Kurve beginnt, dauert es tatsächlich eine Weile. Also, das hier – das ist nicht meine beste Skala. Megabyte pro 100 Millisekunden. Aber das zeigt, wie viele Daten in dieser 100- Millisekunden-Stichprobe enthalten waren. Und die orange Linie ist der Mittelwert aus 10 Stichproben, um eine schönere Kurve zu erhalten. Wenn sie so stark abfällt, bedeutet das, dass in dieser 100-Millisekunden-Stichprobe überhaupt keine Daten vorhanden waren. Oder nun ja, nicht ganz keine, aber eine sehr geringe Datenmenge . Aber wir sehen nicht diesen additiven Anstieg und multiplikativen Abfall. Wir sehen ein viel zackigeres, komplexeres Verhalten, weil so viele Dinge gleichzeitig passieren. Wir konkurrieren mit vielen anderen um den Platz . Wenn viele Leute dieses erste Diagramm sehen, denken sie: „ Oh, wir könnten es effizienter gestalten, wenn…“ „ Wir optimieren hier und da noch etwas.“ Ich zeige euch noch ein Beispiel. Also, das hier war der Download einer Datendatei mit Wget. Wget ist einfach ein Befehl, der eine benannte Datei aus einem Netzwerk herunterlädt. Hier lade ich also die neueste Ubuntu-Distribution von deren Website herunter, und das Ganze wiederholt sich, sodass ich wieder denselben Verlauf erlebe. Wir werden dieses zackige Verhalten sehen, bei dem wir im echten Leben nicht beobachten, dass die Geschwindigkeit an eine Grenze stößt und wieder abfällt. Aber was ihr hier seht, und was ich absolut liebe, ist der langsame Start, nicht wahr? Ja. Wir können den – ich war ehrlich gesagt so glücklich, als ich das sah. Es ist einfach wunderschön. Ich schwöre, ich schwöre, das sind echte Daten. Ich habe das nicht gefälscht. Es ist echt. Ja, also ein wunderschöner, langsamer Start, der uns langsam nach oben bringt. Also, angesichts meiner Dummheit … Skaliert man das, erreicht man etwa 10 Megabyte pro Sekunde, bevor der Slow- Start-Mechanismus hier Probleme bereitet. Wir sehen also den schönen Slow-Start- Mechanismus, der im vorherigen Diagramm nicht zu sehen war. Ich denke, wir haben großes Glück, das in freier Wildbahn zu beobachten. Und dann passiert eben das Leben, nicht wahr? Wie Sie schon sagten, im Internet ist ständig etwas los, die Bandbreite steigt und halbiert sich . Sie steigt und halbiert sich wieder. Vielleicht steigt sie beim nächsten Mal etwas höher und dann wieder niedriger. Ja, ja, ja, ja. Meine abschließende Botschaft dazu ist: Wenn wir über TCP nachdenken, denken viele, es sei total unkompliziert. Nun ja, wenn man beispielsweise ein Signal sendet, das besagt, dass Route 5 zu 53 % ausgelastet ist, und wir nicht wissen, wie viele Pakete genau überwacht werden, dann hat man zwei Probleme. Man hat ein Problem. Ein Großteil des Mechanismus ist fest vorgegeben, richtig? Im vorherigen Video habe ich den Paketheader gezeigt. Dort ist etwas Platz, und es gibt ein paar Bits, die man nutzen könnte, wenn man wollte. Das würde aber wahrscheinlich Probleme verursachen, da Zwischengeräte und Firewalls diese Daten überwachen und auf Unregelmäßigkeiten achten . Wenn man also daran herumexperimentiert, blockieren einige Zwischengeräte möglicherweise den Datenverkehr und fragen sich: „Was passiert hier?“ Da ist doch was faul, oder? „Das werden wir loswerden .“ Man hat also nicht viel Spielraum für Anpassungen, und außerdem befindet man sich in einer ziemlich unübersichtlichen Welt. Das reale Internet ist wirklich viel komplexer als die Skizzen, die wir im Unterricht anfertigen. Ähm, und so ähnlich ist es auch mit dem TCP- Protokoll, das aus den 80er-Jahren stammt. Es war das erste Protokoll, das funktionierte, und dann wurde es sozusagen angepasst, so als ob wir das Modell T gebaut hätten und die Leute dann fragen würden: „ Warum hat es keinen Getränkehalter?“ Warum hat es kein Bluetooth? Warum ändert sich der TCP-Header nicht? Ändert er sich wirklich sehr, sehr langsam? Darin können sich die Dinge ändern , aber seit den 80er Jahren hat sich eigentlich nicht viel verändert. Es hat sich einige Flaggen erworben und sich etabliert. Und man kann nicht zu viel signalisieren. Man kann nicht sagen: „Ich werde einen Mechanismus einbauen, der all diese neumodischen Dinge tun wird, die ich mir ausgedacht habe, und der dieses Problem lösen wird.“ Also, ähm, in der realen Welt erfüllt TCP seinen Zweck und das schon seit fast 50 Jahren sehr, sehr gut. Ähm, es gibt so viele Dinge, die ich in diesem Video ausgelassen habe. Es gäbe noch so vieles hinzuzufügen. Aber ich denke, wir haben jetzt die Mechanismen gesehen, die dafür sorgen, dass es funktioniert. Wir haben gesehen, dass es im wirklichen Leben ziemlich kompliziert ist. Es ist eine chaotische Welt, mit der es zu tun hat . Und es geht nicht nur darum, dass die Daten einfach in irgendeinem Rechenzentrum landen. Es muss damit umgehen können, wenn es um die Kommunikation innerhalb des Heimnetzwerks, über einen Satelliten oder Ähnliches geht. Trotz ihres Alters leistet sie also eine sehr, sehr, sehr gute und komplexe Arbeit. Das Besondere an einem VPN ist, dass wir so etwas wie einen Durchgang schaffen, sodass der erste Router, an dem unser Datenverkehr ankommt, in einem anderen Land liegt. Also unser