 Hallo, ihr hört den Vortrag Transmission Control Protocol in der Übersetzung von Stefan und Lukaro. Hannes ist der Vortragende und er arbeitet unter anderem an MirageOS und beschäftigt sich mit verschiedenen Programmierdisziplinen wie Netzwerk, Protokollen, Sicherheit und ähnlichen. Herzlichen Applaus für Hannes. Danke. Heute möchte ich über das Transmission Control Protocol reden. Worum geht es dabei? Das hier ist ein Foundation Talk. Wenn ihr euch schon ganz super mit TCP-IP auskennt, dann sind für euch vielleicht nur die letzten fünf Minuten von Interesse. Wenn ihr euer Laptop verbinden wollt oder eine Website ansteuern wollt, um die Website zu lesen, dann muss der Client, der Webbrowser auf eurem Laptop, ein Request, eine Anfrage an den Webserver stellen. Und diese Anfrage wird per HTTP-Protokoll übertragen und das ist die hauptsächliche Methode, wie man eine Webseite abrufen kann. Aber wie genau wird diese Anfrage eigentlich übertragen? Darum soll es hier heute im Detail gehen. Lass uns erst mal auf die Netzwerktopologie schauen. Links haben wir den Laptop, den Client und das Laptop ist wahrscheinlich über ein WLAN mit dem Internet verbunden. Was ist denn jetzt eigentlich das Internet? Jedes Clientgerät, ein Laptop, ein Mobiltelefon ist mit einem Router verbunden und der Router ist auch ein Computer, der aber über Informationen verfügt, wie man andere Systeme im Internet erreicht. Und dazu hat er mehrere Verbindungen über Kabel, über Glasfasern. Und in diesem Bild sieht man nur zwei Router, aber in Wirklichkeit sind das natürlich viel, viel mehr. Das können im Prinzip beliebig viele sein. In diesem Fall ist hier der Router B per Ethernet verbunden. Per Ethernet und Ethernet ist ein Protokoll, das über ein Kabel gesprochen wird. Ich werde mich heute nicht damit beschäftigen, wie die verschiedenen Kabel und Glasfasern und Satellitenverbindungen funktionieren, sondern ich fange an mit einer Schicht, die darüber liegt, die über dieser physischen Schicht liegt. Das nennt sich Data Link Layer. Und was ist ein Data Link Layer? Die Aufgabe des Data Link Layers ist, über ein lokalenes Netzwerk eine Verbindung herzustellen. Das heißt, das WLAN in diesem Fall ist der Data Link Layer zwischen Laptop und Router A und Router B und der Server haben auch ein Data Link Layer, in dem Fall das Ethernet. Und die Aufgabe ist ganz einfach. Es geht darum, Datenpakete, IP-Pakete zwischen zwei Stationen im lokalen Netz auszutauschen. Und das definiert, wie Daten übertragen werden können, wie groß die am Stück sein können und ähnlich ist. Und darüber gibt es den Internet Layer. Und in dem Diagramm habt ihr gesehen, gibt es zwei Router A und B und die verwenden den Internet Layer, um Daten zwischen ihren Anschlüssen zu übertragen. Und dazu gehört, dass die verschiedenen Geräte alle jeweils eine Adresse haben, damit man den entsprechenden Daten zustellen kann. Und der IP Layer ist ebenfalls dafür zuständig, das sogenannte Routing zu erledigen, also die Entscheidung über welche Netzwerkschnittstelle ein Paket weitergeleitet werden soll. Wenn eine höhere Schicht Daten übertragen möchte, die viel größer sind, Daten, die viel größer sind als das, was über diesen Data Link Layer übertragen werden kann, dann sorgt der IP Layer auch dafür, dass diese Daten in Teilen aufgeteilt werden beim Sender und beim Empfänger wieder zusammengesetzt werden. Zu den Adress-Informationen gehört im Zweifelsfall auch sogenannte Ports Anschlüsse, die auf der Sender- und Empfängerseite die Adressierung spezifischer Dienste erlauben. Es gibt zwei Protokolle, TCP und UDP, das sind die am meisten gebräuchlichen darüber hinaus gibt es viele weitere. Und UDP ist das Erste von den beiden. UDP hat einige Vorteile, es ist relativ klein, hat wenig overhead, lässt sich leicht verarbeiten, ist aber auch unzuverlässig, die Daten können verloren gehen, die Reihenfolge der Daten ist letztendlich nicht definiert. TCP hingegen ist verlässlich, die Daten kommen da genauso wieder raus, wie man sie reingesteckt hat, aber dafür muss auch eine Verbindung aufgebaut werden und die beiden Geräte müssen miteinander tatsächlich sich darüber austauschen, wie die Daten übertragen werden. Schließlich haben wir ganz oben die Anwendungsschicht, das sind die eigentlichen Anwendungen und dazu gehört dann zum Beispiel HTTP oder auch TLS, das definiert, wie über so eine Verbindung dann tatsächlich Daten ausgetauscht werden. Die unteren Schichten übertragen einfach beliebige Daten, und in diesem Bild können wir jetzt auch die verschiedenen Schichten sehen. Links haben wir wieder das Laptop und da sehen wir alle vier Schichten auf der kleinen Seite. Die Router hingegen, die verwenden jetzt nur Datalink und Internet Layer und der Server hat dann wieder alle vier Layer. Die Transport-Portschicht ist rechner zu rechner und die TCP-Schicht ist dann der Transport über das Internet zwischen zwei Endsystemen, nämlich dem Kleint und dem Server in diesem Fall. Und oben drauf dann eben der Web Browser, der mit dem Web Server redet. Die Router in der Mitte, die brauchen sich nicht anzugucken, was genau da übertragen wird. Die müssen nicht wissen, dass das HTTP ist. Die Router verwenden den Internet Layer einfach, um Pakete in die richtige Richtung weiterzuleiten. So, Datelint schickt ein erstes Paket, zum Beispiel ein TCP-Symbol und der schickt das an den Router A und der Router A guckt sich einfach nur an, wo soll das hingehen und sagt, okay, Router B ist die richtige Station und schickt es an den Router B weiter und der Router B guckt sich wieder nur an, wo soll es hingehen und schickt es dann an den Server weiter. So, wie schaut so ein Paket aus, das auf dem Datalink Layer tatsächlich übertragen wird? Ganz oben auf dem Application Layer haben wir die eigentlichen Daten, die übertragen werden sollen, also den GetRequest. Darunter haben wir die Transportschicht TCP, die jetzt entsprechende Informationen für TCP hinzufügt, bevor das Paket an den Internet Layer weitergegeben wird und der Internet Layer, der fügt nun wiederum selber entsprechende IP-Informationen hinzu und auf der untersten Ebene kommt dann je nachdem, was das für eine Technologie ist, dann kommen unterschiedliche weiteren Daten hinzu, die die Übertragung auf dem tatsächlichen physischen Medium ermöglichen. Man kann also von diesen, diesen Bildern sehen, auf jeder Ebene werden Headerinformationen hinzugefügt, auf der Internet Layer Ebene zum Beispiel wird das TCP Paket übernommen und weitere Informationen für IP hinzugefügt. Ich werde jetzt nicht auf die Datalink Layer Spezialitäten eingehen, aber wir wollen uns hier mal anschauen, wie bei IP Version 4 der Header aussieht. Der Header enthält mindestens 20 Byte an Informationen und ein ganz wichtiges Feld ist die Versionsinformation hier in diesem Beispiel Version 4, da könnte aber auch eine 6 drinstehen, dann gibt es verschiedene Bits, dann kommt ein Feld für weitere Informationen, über die wir heute nicht reden und in den nächsten 2 Byte steht drin wie groß das IP Paket insgesamt ist. Dann haben wir eine 16-Bit Nummer für die Identifizierung dieses Pakets, weitere Flex für die Fragmentierung dienen, nämlich wenn also Daten übertragen werden sollen, die größer sind, als in ein einzelnes IP Paket passt, dann kann das aufgeteilt werden und wird dann beim Empfänger wieder zusammengesetzt. Das nächste Feld ist ein 8-Bit Feld, das sogenannte Time to Live Feld, das ist ein Zähler, wie viele Weiterleitungen durch Router soll dieses Paket überleben. Jeder Router, der das Paket weiterleitet, dekrimentiert diese Zahl und wenn die auf Null sinkt, dann wird das Paket verworfen. Die Protokollnummer, das ist also sowas wie TCP oder UDP, dann gibt es eine Prüfzumme für die Headerdaten, 16-Bit. Dann haben wir die Quelle und die Zieladresse dieses Pakets jeweils als 32-Bit. Und in unserem Beispiel hier ist die Quelladresse, die IP Adresse von meinem Laptop und die Zieladresse ist der Server der Webserver. Im Anschluss daran gibt es gegebenenfalls Optionen, die optional vorhanden sein können und dann kommen die eigentlichen Daten. Die Protokollnummer, da gibt es eine Reihe, die definiert sind. Heute werden wir über ICMP, das Internet Control Message Protokoll reden und TCP. Es gibt noch weitere Protokolle, die auch über in einem IP Paket transportiert werden können, aber da gehen wir heute nicht drauf ein. Und es gibt 255 Möglichkeiten für Protokolle. Ja, was ist ICMP? ICMP ist ein Protokoll, was ich noch gar nicht angesprochen habe, aber es ist das Internet Control Message Protokoll, also ein Zusatzprotokoll des Internets und es setzt auf IP auf. Eine Aufgabe ist, Federnachrichten zu übermitteln, also zum Beispiel Zielrechner ist nicht erreichbar oder Lebensdauer ist überschritten und das andere ist Betriebsinformationen zu übermitteln, also zum Beispiel Diagnoseinformationen. Ein Programm, was ihr vielleicht kennt, ist PING und die Verwendungsdeck von PING ist ICMP Echo Request zu senden, also tatsächliche ICMP-Nachrichten und die fordern den Empfänger auf eine ähnliche Nachricht, wo sich nur ein Bit verändert hat, zurückzuschicken und das ist dann der ICMP Echo Reply, also die Echo Antwort. Und wenn man einen anderen Computer pingen kann, dann kann man sicherstellen, dass der andere Host zumindest eine IP-Verbindung hat. Okay, lasst uns jetzt das in die nächste Ebene angucken, das ist die Transport-Ebene. Und zuerst werden wir uns UDP anschauen. UDP ist nur acht Bit lang der UDP-Header und hat nur einen Quail-Port, einen C-Port, die Länge von dem gesamten UDP-Rahmen und die eine Prüfsumme. Und die Prüfsumme ist wieder 16 Bit lang und wird berechnet über die gesamte Datenmenge und der gesamte, ja, also es enthält auch die Informationen über Quelle und Zieladresse und so in sich drin. Ja, wie wir schon gehört haben, ist UDP unzuverlässig ungeordnet, also die Reihenfolgehaltung ist nicht da gegeben, aber dafür hat es einen geringen Verwaltungsaufwand, also es ist wenig Overhead vorhanden. Es werden nur acht Bit zu der Datenlänge zugefügt, während der IP schon 20 Bit mindestens hinzugefügt. Das ist ein leicht einfaches Unix-Programm, was einen UDP-Client darstellt. So würde das jetzt nicht kompilieren, weil ich was ausgelassen habe. Aber um das Prinzip zu verstehen, wie man diesen IP-Stack verwenden würde, reicht es aus. Also der IP-Stack ist normalerweise im Kernel eingebettet und als ein Programmierer oder ein API-Programmierer, ein Schnittstellenprogrammierer, hat man jetzt hier die Schnittstelle, die von der Unix-Socket-Schnittstelle zur Verfügung gestellt hat und es sind immer dieselben fünf oder sieben Funktionen. Die erste ist Socket. Die Funktion Socket öffnet ein Dateideskriptor und man spezifiziert den Adressbereich und den Typ des Sockets. Die Adressfamilie ist hier das Internet und das ist ein Datagrammsocket, also degramm abgekürzt. Wenn das erstellt wird, dann für ein UDP-Client braucht man nur die Funktion SendTo, die diesen Socket-File-Deskriptor, also den Dateideskriptor, den wir gerade erzeugt haben braucht und halt eben nur die Daten, die es zur anderen Seite senden soll. Weil es uns nur verletzt ist, dass es einfach los schicken und gucken, ob es ankommt und danach schließt man einfach den Socket wieder, weil wir hier ein guter Programmierer sind und vorbildlich handeln wollen. Und wenn man ein UDP-Server implementieren möchte, sieht das ungefähr so aus. Also, wieder macht man einen Socket auf und dann gibt es die Funktion bind, die an eine bestimmte IP-Adresser auf dem Server bindet oder eben darauf lauscht. Und dann gibt es die Funktion receiveform, die wieder den Socket-Dateideskriptor und einen Puffer und ein Datei, also eine Maximalkröße und einen Offset nimmt. Und receiveform wird erst, also die Funktionen gibt erst dann was zurück, wenn wirklich ein UDP-Frame auf dieser Adresse und dem angegebenen Port angekommen ist. Und dann werden wir das eben ausgeben, was wir erhalten haben und auch jetzt auch hier schließt mir wieder den Stateideskriptor. Ja, das ist UDP im Wesentlichen. UDP wird für verschiedene Protokolle verwendet und es ist wichtig, dass es das gibt. TCP dagegen ist deutlich komplizierter. Also anstatt von 8 bytes haben wir hier weitere 20 bytes an Headerinformationen. Was enthält denn der TCP-Header? Also erstmal natürlich wieder ein Quailport und ein C-Port, genauso wie bei UDP. Beide sind wieder 16 bit lang. Dann enthält es zwei Sequenznummern, einmal die Sequenznummer selbst und einmal die Anerkennungsnummer, acknowledgement number. Das ist die letzte Sequenznummer, die wir von der anderen Seite erhalten haben. Also damit können wir sicherstellen, können wir sagen, was das letzte Paket war, was wir von der Gegenstelle erhalten haben. Dann gibt es das Data Offset, also das beschreibt, wie lange die Headerinformation ist. Also TCP-Header kann auch weitere optional Informationen enthalten, bevor der eigentliche Datensatz kommt und deshalb muss man das Data Offset Feed benutzen, um zu sagen, wo die tatsächlichen Daten anfangen. Dann hat TCP mehrere Flags. Manche von diesen Flags sind nur einzelne bits, die umgeschaltet werden. Manche davon habe ich hier unten gezeigt, wo ich später noch mehr zu erzählen möchte. Das erste ist der ACK oder Acknowledgements, dann die Synchronisierung oder Synchronisation und dann finish, also beenden, finden. Da gibt es dann noch Reset, also für Fehlerbehandlungen, aber das werde ich jetzt nicht im Detail behandeln. Dann gibt es einen 16-Bit-Feld für die Windows Size, also die Fenstergröße. Das ist im Prinzip die Größe des Empfängerapuffers und wieder eine 16-bit lange Prüfsumme. Und dann haben wir noch ein bisschen Speicherplatz für dringende Sachen, die ich jetzt nicht im Detail besprechen würde. Und wenn man jetzt TCP auf einem Unix-Client programmiert, dann hat man wieder eine ähnliche Schnittstelle wie für UDP. Zuerst wird man wieder die Funktion Socket aufgerufen, um eine Theta-Skripper zu erzeugen, wieder die Adress-Familie Internet und in diesem Fall Socket Stream als Typ. Also, weil wir wollen einen Byte Stream, also einen TCP-Byte Stream haben, das ist halt eben der Name des TCP-Types im Vergleich zu datagram-basierten UDP-Sockets. Und wenn als TCP-Client verwenden wir die Funktion Connect, um zu einem entferten Rechner zu verbinden, mit dem Socket-File der Theta-Skriptor. Und Connect wird auch erst dann zurückgeben oder abschließen, wenn eine tersellische TCP-Sitzung aufgemacht wurde. Und dann können wir jetzt hier wieder eine Funktion Receive aufrufen mit dem Datei-Deskriptor und einem Puffer, um Sachen zu empfangen und dann beenden wir das Programm und schließen den Datei-Deskriptor wieder. Und der TCP-Listener oder der TCP-Server ist auch wieder ähnlich. Wir machen wieder einen Socket auf und wir verwenden wieder die Funktion bind, um wieder die IP Adress und die Portnummer anzugeben, auf der wir lauschen wollen. Dann verwenden wir die Funktion Listen, auch wieder unter der Verbindung des Datei-Deskriptors. Und dann gehen wir in eine Schleife. Und jetzt warten wir einfach für Verbindungen von Clients, die auftauchen können irgendwann. Und für jede Verbindung von irgendeinem Client werden wir die Funktion Accept aufrufen und die Funktion Accept ist erst dann fertig, wenn tatsächlich eine TCP-Verbindung zum Client erfolgreich hergestellt wurde. Und da kommt dann wieder ein neuer Datei-Deskriptor raus, nicht der gleiche wie der Socket-Datei-Deskriptor, den wir am Anfang als verwendet haben. Und wir können da mehrmals accept auf dem selben Socket-Datei-Deskriptor aufrufen, um verschiedene Verbindungen aufzubauen. Dann wird jetzt alles auf dem neuen Datei-Deskriptor abgehandelt, wird es wahrscheinlich jetzt zu einem anderen Prozess oder zu einem anderen Fett übergeben, um halt also in KRONE Datenzugriffe zu ermöglichen, eine weitere Verbindung zu ermöglichen, während die eine Verbindung behandelt wird. Das haben wir jetzt in dem Beispiel weggelassen aus Einfachhaltsgründen. Und dann wird es jetzt einfach ausgegeben und dann senden wir halt eine Antwort mit der Funktion Send, mit dem neuen Datei-Deskriptor, und zwar den String Hello World. Und dann wird der Datei-Deskriptor wieder geschlossen und in dem Fall würde jetzt die Schleife wieder von vorne beginnen, um wieder eine neue Verbindung zu akzeptieren. Ja, das ist im Prinzip ein TCP-Listener, TCP Server, wie man das sehen würde, in verschiedenen Netzwerkprogrammen, die auf UNIX Basisprogramm jetzt sind. Und TCP, wie ich schon bereits erwähnte, hat es muss verschiedene Sachen, Aufgaben übernehmen, um eine Sitzung aufzumachen und auch später wieder zu schließen. Und die Hauptaufgabe ist, sich zu synchronisieren, also die Startsequenznummer zu synchronisieren zwischen dem Client und dem Server. Wir haben gesehen hier im header, da ist diese Sequenznummer und wir müssen diese Information zur anderen Seite übermitteln. Also das ist im Prinzip eine TCP-Zustandsmaschine, ein TCP-Zustandsautomat und das ist im Prinzip einfach nur ein Auszug aus der TCP-Spezifikation und das wird auch in vielen anderen Dokumenten aufgegriffen, wie zum Beispiel auch im Stevens, ja, genau. Und man kann sehen, dass ein Status ist der Status Listen, also Lauschen. Und Listen ist das, was in der Server-Implementierung abgerufen wird, wenn man das aufruft, dann ist man halt eben im Zustand Listen. Und ja, normalerweise endet man im Status closed, nachdem man die Funktion closed aufgerufen hat. Ja, ich werde da jetzt ein bisschen mehr die Verbindungserstellung angucken und auch die Verbindungstrennung. Und wir haben hier, auf der kleinen Seite, fangen wir an mit dem Zustand closed, also ein Socket im Zustand closed und dann machen wir den Unix Aufruf Connect und auf diesem Socket und dieser Socket verbindet sich und ja, er sendet ein Start TCP-Segment zum Server, wo das Synchronized Fleck, also das Synnfleck gesetzt ist oder auf 1 gesetzt ist und die Sequenz-Nummer ist jetzt irgendeine aberitäre Nummer, irgendwas, wo auch immer wir halt anfangen, 32-Bit Integer-Nummer. Also wir nennen sie jetzt einfach A. Und der Zustand des Status-Scripter geht dann von closed auf sunset. Ja, wie der Name schon sagt, es sagt einfach, dass wir die Synchronized Message, also die Synchronized Nachricht gerade eben gesendet haben. Also der Anticipesegment, was gar keine tatsächlichen Daten enthält, sondern einfach nur ein TCP-Header. Und auf der anderen Seite haben wir uns ja schon vorbereitet auf diesen Zustand. Wir haben auch mit einem closed Socket angefangen und dann haben wir die Funktion Listen aufgerufen und dann sind wir am Zustand Listen. Und im Zustand Listen können wir jetzt die Funktion Accept aufrufen und Accept wartet bis, ja, ein Synchronized Fleck, also ein erreicht und sobald ein Paket erreicht, dann wird ein erneutert heißes t- Datascripter aufgemacht und der ist dann im Zustand Listen received. Und der Server antwortet auch mit einem TCP-Segment auch ohne Daten, aber er sendet eben auch das Synchronized Fleck und das Acknowledgement Fleck. Also er bestätigt quasi das Empfang vom Kleint und er bestätigt quasi, dass er die Sequenzenummer A erhalten hat, indem er sagt, als nächstes erwartet die Sequenzenummer A plus 1. Und dann geht auch der Kleint in den Zustand established, also Verbindung hergestellt und auch er sendet jetzt wieder eine Nachricht mit dem Acknowledgement, also Bestätigungspit gesetzt und er setzt jetzt wieder die Sequenzenummer auf A plus 1. Und ja, das ist jetzt einfach das nächste TCP, das nächste IP-Paket und deshalb hat es eine neue Sequenzenummer. Und die Bestätigungsnummer wird hier auf B plus 1 gesetzt, um zu sagen, ich erwarte als nächstes die Nummer B plus 1 vom Server. Und dann ist auch der Server im Zustand Verbindung hergestellt. So, diese Sequenzenummer, damit es gut funktioniert, suchen sich beide Seiten jeweils eine zufällige Sequenzenummer raus. Für jedes Byte, was übertragen wird, wird die Sequenzenummer um 1 erhöht. Und beide Seiten bestätigen der sendenden Seite den Empfang, indem sie die empfangende Sequenzenummer bestätigen in einem Sohnpaket. Da die Zeit nicht mehr reicht, springe ich mal über das Beenden der Verbindung hinweg. Eine der wichtigsten Funktionen von TCP ist die Flusssteuerung. Es gibt einen Empfangspuffer für jede Verbindung, damit der Rechner Daten per TCP empfangen kann, auch wenn die Applikation vielleicht gerade nicht in der Lage ist, die Daten zu verarbeiten. Aber der Puffer ist natürlich in der Größe begrenzt, damit nicht jemand über das Netzwerk sämtliches Ram verbrauchen kann. Und eine ganz wichtige Funktion von TCP ist, dass der Sender nicht mehr Daten sendet, als der Empfänger tatsächlich im Moment aufnehmen kann. Das ist das sogenannte Empfangsfenster. Und dieses sogenannte Sliding Window ist die Datenmenge, die vom Sender tatsächlich unbestätigt an den Empfänger gesendet werden kann. Wenn die erreicht ist, dann hört der Sender auf zu senden, bis er entsprechende Empfangsbestätigung erreicht hat, empfangen hat. Ein weiterer wichtiger Aspekt ist, dass die tatsächliche Leitung, die Verbindung zwischen den beiden Rechnern nicht überlastet wird. Eine bestimmte Netzwerktechnologie kann nur eine bestimmte Menge an Daten gleichzeitig übertragen. Und wenn da mehrere Rechner miteinander reden, dann müssen die sich irgendwie die Bandbreite teilen. Und Congestion Control, also quasi die Staukontrolle, soll dafür sorgen, dass jeder Rechner tatsächlich eine fairen Anteil abbekommt. Die sogenannte Acknowledgements, die Empfangsbestätigung, da gibt es drei verschiedene Varianten. Die ganz einfache Version, immer wenn Daten empfangen werden, wird eine Empfangsbestätigung zurückgeschickt. Zusätzlich ist TCP in der Lage, wenn einzelne Pakete verloren gehen, auch nur bestimmte Teile zu bestätigen. Also wenn in der Mitte ein Paket verloren geht, dann können die späteren Daten bereits zwischengespeichert und bestätigt werden. Aber die früheren Daten müssen dann vom Sender nochmal gesendet werden. Dann gibt es Erweiterungen, um das Empfangsfenster automatisch an die Netzwerkleidung anzupassen. Es gibt Angriffe auf TCP, den Nile of Service, also den Rechner dazu bringen, dass er keine Netzwerkverbindungen mehr verarbeiten kann. Man kann Verbindungen übernehmen, indem man sich entweder als Sender oder Empfänger ausgibt. Und wenn man die Sequenznummern erraten kann, dann kann man gegebenenfalls Daten in die Verbindung einspeisen, die sogenannte Blind in Window Attack. Und eine Blind in Window Attack ist, wenn man die Sequenznumbers noch nicht mal wirklich im Vorhinein ermitteln muss, sondern über Tricks quasi die Daten da trotzdem reinbekommt. Das TCP ist spezifiziert in den üblichen Internet-RFCs Request for Commence. Und ich habe im letzten Jahr in der Universität Cambridge ein formales Modell für TCP entwickelt, mit einer sehr präzisen Spezifikation, mit der man eine Implementation überprüfen kann, indem man sie von außen über diese Spezifikation prüft. Die zwei Schnittstellen für die Prüfung sind einmal das House Interface, das Socket Interface und dann die Pakete, die von Systemen tatsächlich gesendet und empfangen werden. Hier gibt es zwei Spiele dieser Spezifikation, die hier in der typischen Netzwerkdiagramm-Darstellung die einzelnen Schritte und die übertragenden Informationen darstellen. Und hier sehen wir, wie verschiedene Segmente übertragen werden. Was wir mit der Network Semantik erreicht haben, konnten wir das Modell validieren, indem wir Pakettraces aufgezeichnet und verarbeitet haben. Wir haben ein Paper publizieren können. Die Spezifikation ist in 384 Seiten ausgedruckt. Das Ganze sind etwa 10.000 Zeilen Code. Die Statemachine, das Zustandsdiagramm, haben wir etwas überarbeitet, dass mehr der tatsächlichen Spezifikation entspricht. Dazu haben wir ein paar weitere Zustände eingeführt und weitere Übergänge zwischen den... Die übliche Literatur enthält ein Zustandsdiagramm, das unvollständig ist. Zusammengefasst, TCP wird es in sehr vielen Systemen implementiert. Es ist eine Schichtenarchitektur. Die oberen Schichten haben kein Wissen über die Art und Weise der unteren Schichten und mit Network Semantics kann man das schön prüfen. Damit, vielen Dank und Fragen, bitte. Ja, danke. Also, wenn ihr irgendwelche Fragen habt, dann geht einfach zu den Mikrofonen. Wir haben zwei hier und zwei auf der rechten Seite. Und gibt es vielleicht ein paar Fragen vom Internet? Nein. Keine Fragen? Ja, eine Frage. Ja, komm, traurig. Nicht schüchtern sein. Hallo, ja, danke. Das war ein sehr schöner Vorteil, ein sehr interessanter Vortrag. Das Modell... Ist es möglich daraus, eine Implementierung aus der Spezifikation zu synthetisieren? Im Moment wird das für die Validierung verwendet. Und wir sind nicht abhängig von der Implementierung. Und in der Implementierung muss man sich entscheiden, in welchen Zustand man tatsächlich wechselt, ob man Abricht oder Daten überträgt. Wir wollen in die Richtung weiter arbeiten. Und denkst du, dass zu einer Implementierung gemacht werden kann, kann sie auch effizient gemacht werden? Ja. Ja, danke. Ja, deine Frage, bitte. Ja, deine Frage, bitte. Wie unabhängig ist TCP vom IP-Protokoll? Kann man auch TCP über andere Protokolle machen, also zum Beispiel über Bluetooth oder so? Da TCP für die Fehlerbehandlung ICMP benötigt, ich habe jetzt noch keine TCP Implementierung gesehen, die nicht auf IP basiert. Ich könnte mir das vorstellen, das könnte funktionieren. Okay, deine Frage, bitte. Okay, hier die Frage, bitte. Ja, danke. Ja, danke. Ja, danke. Ja, danke. Okay, deine Frage, bitte. Okay, hier die Frage, bitte. Ja, danke, hallo. Also, du hast HALL4 für den Spezifikationsteil benutzt. Musstest du die höhere Logik benutzen von HALL oder konntest du einfach die Politik HALL4 verwenden? Ich glaube, wir brauchen ein paar höherwertige Funktionen für die Zustandsübergänge. Ja, es wäre interessant, sich mal zu treffen. Das Paper wurde publiziert und ist auch auf SIHUB zu finden. Weitere Fragen? Nein. Ja, danke, Hannes. Einen großen Applaus für Hannes, bitte. Ja, und?