Transaction TCP (T/TCP), (RFC 1379, RFC 1644)

TCP baut eine symmetrische Transportverbindung zwischen zwei Kommunikationspartnern auf. Tatsächlich läuft eine Kommunikation im Internet selten symmetrisch ab. Auf eine kurze Anfrage hin (Request) erfolgt eine umfangreiche Antwort (Response). Diese als Transaktionsprinzip bezeichnete Arbeitsweise tritt hauptsächlich in der Client/Server-Kommunikation auf, wie z.B. bei HTTP (Hypertext Transfer Protokoll) im World Wide Web. Allerdings wird die Effizienz des Datentransfers in dieser transaktionsorientierten Verarbeitung durch die Arbeitsweise von TCP (Verbindungsaufbau mit dem Drei-Wege-Handshake, Datentransfer, Verbindungsabbau mit Vier-Wege-Handshake) durch einen erheblichen Protokolloverhead herabgesetzt. Zur effizienten Abwicklung von Transaktionsprozessen bietet T/TCP zwei TCP- Erweiterungen (siehe RFC 1644 and RFC6247):

  • Connection Count
    Jedes TCP-Segment führt einen Transaktionszähler für jeden Request/Response als Option im TCP-Header mit, der zur Identifikation der Transaktion dient.
  • TCP Accelerated Open (TAO)
    Dieses Verfahren umgeht den Drei-Wege-Handshake bei der Eröffnung einer neuen Verbindung und nutzt dazu den Connection Count.

TCP-Nachrichtenformat im Detail – Urgent Pointer, Optionen und Füllbits

Nun kommen wir zu den letzten Felder des TCP Formats. Alle andern Felder haben wir schon in den vorherigen Posts besprochen (TCP Nachrichtenformat im Detail ):

  • Urgent Pointer
    Das TCP-Protokoll sieht eine Möglichkeit vor, mit der dringliche Daten (Out-of- Band Data), wie z.B. Interrupts, zusammen mit den regulär zu sendenden Daten direkt an den Kommunikationspartner übertragen werden können. Diese dringenden Daten sollen dem empfangenden Prozess so schnell wie möglich übergeben werden, ohne dass sie z.B. erst im Eingangspuffer abgelegt werden. Das 16 Bits lange Feld des Urgent Pointers dient dabei als Offset-Angabe und ist nur dann aktiv, wenn das URG-Bit auf Eins gesetzt ist. Dringliche Daten folgen in der Regel stets direkt nach dem TCP-Header und stehen somit am Anfang der TCP- Nutzdaten. Erst danach, d.h. nach der im Urgent Pointer angegebenen Bytelänge, starten die regulären Nutzdaten.
  • Optionen
    Die hier anzugebenden Optionen gestatten unter TCP die Einbindung zusätzlicher Funktionalität, die nicht durch die restlichen Headerfelder abgedeckt wird. Das erste Byte im Optionen-Feld legt den Optionstyp fest (siehe RFC 1323 und RFC 2018), der folgende Bedeutung haben kann:

    • Maximum Segment Size (MSS)
      Mit Hilfe dieser Option können die beiden Kommunikationspartner beim Verbindungsaufbau eine maximale Segmentgröße aushandeln (RFC 879). Je größer dabei die verwendete Segmentlänge ist, desto weniger mindert der 20 Bytes Overhead des TCP-Headers die Effizienz der Datenübertragung. Wird diese Option beim Verbindungsaufbau nicht verwendet, kommt eine Standardlänge der Nutzdaten von 536 Bytes zum Einsatz. Jeder Rechner im Internet muss daher in der Lage sein, ein TCP-Segment mit einer Länge von 536 + 20 = 556 Bytes entgegenzunehmen. Die Übertragungseffizienz hängt von der Wahl der jeweils günstigsten MSS ab. Ist diese zu niedrig angesetzt, wächst anteilig der durch den TCP-Header bedingte Overhead. Ist sie andererseits zu hoch gewählt, führt dies auf der Internetschicht zu vermehrter IP- Fragmentierung, bei der ebenfalls neuer Overhead durch zusätzlich benötigte IP-Datagrammheader entsteht. Darüberhinaus besteht bei Verlust eines Segments die Gefahr, dass ein komplettes TCP-Segment neu übertragen werden muss.
    • Window Scale (WSopt)
      Über diese Option können die beiden Kommunikationspartner während des Verbindungsaufbaus aushandeln, ob die reguläre maximale Fenstergröße von 16 Bits Länge um einen konstanten Skalierungsfaktor hochgesetzt werden soll. Der Wert kann jeweils unabhängig für das Senden und das Empfangen ausgehandelt werden. Speziell für hohe Bandbreiten empfiehlt sich eine größere Fenstergröße, da sonst der Sender beim Warten auf die Quittierung sehr viel Zeit untätig verbringt. Besonders kritisch ist die Situation z.B. bei Satellitenverbindungen, bei denen eine extrem hohe Wartezeit entlang der Übertragungsstrecke entsteht. Der maximale Wert für WSopt beträgt 14, was einer neuen maximalen Fenstergröße von 1 GByte entspricht.
    • Timestamps Option (TSopt)
      Diese Option dient der Ermittlung der Netzumlaufzeit und bestehen aus den beiden Teilen Timestamp Value (TSval) und Timestamp Echo Reply (TSecr). Aus der Differenz der von Sender und Empfänger gesetzten Zeitstempel kann ein exakter Messwert für die Netzumlaufzeit (Round Trip Time) eines TCP-Segments ermittelt werden, der in die Berechnung der mittleren Netzumlaufzeit eingeht.
    • Selective Acknowledgement
      Das als Selective Acknowledgement bezeichnete Verfahren findet Einsatz bei der TCP-Überlastkontrolle (siehe RFC 2018) und trägt dafür Sorge, dass nach kumulativ auftretenden Timeouts lediglich ein einzelnes Datenpaket neu übertragen werden muss, da die übrigen Datenpakete zwar verspätet aber doch beim Empfänger angekommen sind.
    • Connection Count (CC)
      Dieses Optionsfeld dient der Unterstützung einer transaktionsorientierten Erweiterung von TCP, die als Transaction TCP (T/TCP) bezeichnet wird.
  • Füllbits
    Mit Füllbits wird die Länge des TCP-Segmentheaders zur Wortgrenze von 32 Bits aufgefüllt.

TCP-Nachrichtenformat im Detail – Fenstergröße und Prüfsumme

Nachdem wir uns nun bereits sechs Felder des TCP Nachrichtenformats im Detail angesehen haben und wollen uns nun auf die nächsten zwei Felder konzentrieren:

  • Fenstergröße
    Die 16 Bits lange Fenstergröße dient der Flusssteuerung mit Hilfe des Sliding-Window Protokolls, mit dem der Empfänger den an ihn gesendeten Datenstrom steuert. Das Sendefenster gibt an, wieviele Bytes, beginnend ab der Bestätigungsnummer, der Empfänger noch in seinem Eingangspuffer aufnehmen kann. Empfängt der sendende Rechner ein TCP-Segment mit der Sendefenstergröße Null, muss dieser das Senden so lange einstellen, bis er wieder ein positives Sendefenster erhält.
  • Prüfsumme
    Um eine hohe Zuverlässigkeit der übertragenen TCP-Segmente zu gewährleisten, wurde eine 16 Bits lange Prüfsumme mit in den TCP-Segmentheader aufgenommen. Die Prüfsumme berechnet sich aus dem TCP-Header, wobei die Prüfsumme und eventuell enthaltene Füllbits als Null angenommen werden, den TCP- Nutzdaten und dem Inhalt des sogenannten Pseudoheaders. Der Pseudoheader ist eigentlich nicht Teil der im TCP-Segment enthaltenen Information, sondern wird nur temporär aus den zu übertragenden IP- und TCP-Daten berechnet. Eingang in den Pseudoheader finden die IP-Adressen von Sender und Empfänger, die Protokollnummer, die TCP identifiziert, und die Länge des vollständigen TCP-Segments. Der Pseudoheader dient der Erkennung eventuell fehlgeleiteter TCP-Segmente, widerspricht aber eigentlich dem Gedanken der Protokollhierarchie, da er die IP-Adressen der Netzwerk-Protokollschicht mit einbezieht.

    Das Datenformat des Pseudoheaders unterscheidet sich je nachdem, ob IPv4 oder IPv6 als Netzwerkprotokoll verwendet wird. Die erste Grafik zeigt den bereits beschriebenen Aufbau des TCP Pseudoheaders unter IPv4. Bei IPv6 folgen gemäß RFC 2640 den jeweils 128 Bits langen IPv6-Adressen für Sender und Empfänger die Länge des TCP-Segments und anstelle der IPv4-Protokollangabe ein IPv6- Next-Header-Feld, das den Typ der transportierten Daten (hier TCP) angibt, wie in der nächsten Grafik zu sehen.

TCP-Nachrichtenformat im Detail – Data Offset und Control Bits

Wir haben uns bereits kurz mit den ersten vier Feldern (Source Port, Destination Port, Sequenznummer und Bestätigungsnummer) des TCP Nachrichtenformat im Detail befasst und wollen nun auf die nächsten beiden Felder eingehen:

  • Data Offset
    4 Bits langes Feld (Data Offset oder auch Header-Length, HLEN), das die Länge des TCP-Headers in 32-Bits Worten angibt und als Offsetangabe den Anfang der eigentlichen Nutzdaten im übertragenen Segment kennzeichnet. Auf das Data Offset Feld folgt ein 6 Bits langes Feld, das nicht genutzt wird.
  • Control Bits
    Die folgenden sechs Kontrollbits legen fest, welche Felder jeweils im Header gültig sind, und dienen damit der Steuerung der Verbindung. Die Kontrollbits haben folgende Bedeutung, wenn sie auf den Wert Eins gesetzt werden:

    • Urgent Bit (URG)
      Aktiviert den Urgent-Pointer im TCP-Header.
    • Acknowledgement Bit (ACK)
      Aktiviert das Feld f¨ur die Bestätigungsnummer.
    • Push Bit (PSH)
      Aktiviert die sogenannte Push-Funktion, die veranlasst, dass die im Nutzdatenteil übermittelten Daten sofort an die nächsthöhere Protokollschicht übergeben werden. Die gesendeten Daten werden also nicht in einen Eingangspuffer geschrieben, der erst geleert wird, wenn er vollständig gefüllt ist. Diese Funktion dient der beschleunigten Übertragung von Daten, die möglichst schnell und zuverlässig ablaufen soll.
    • Reset Bit (RST)
      Setzt eine Verbindung zurück, die durch ein außergewöhnliches Ereignis (z.B. Rechner-Absturz) durcheinander geraten ist. RST wird auch dazu genutzt, eine ungültige Sequenznummer zur¨uckzuweisen oder einen Verbindungsaufbau abzulehnen.
    • Synchronisations Bit (SYN)
      Signalisiert einen Verbindungsaufbau. Bei einer Verbindungsanfrage ist stets SYN=1 und ACK=0 gesetzt, um anzuzeigen, dass das Bestätigungsfeld noch inaktiv ist. Erst die Antwort auf die Verbindungsanfrage enthält eine Bestätigung, daher sind dort SYN=1 und ACK=1 gesetzt. Innerhalb eines Verbindungsaufbaus mit gesetztem SYN-Bit dient das ACK-Bit also zur Unterscheidung, ob es sich um eine Anfrage oder um die Antwort darauf handelt.
    • Finish Bit (FIN)
      Signalisiert einen einseitigen Verbindungsabbau, der Sender hat keine weiteren Daten mehr zur Übertragung.

TCP-Nachrichtenformat im Detail – Von Source Port bis Bestätigungsnummer

Wir haben uns bereits kurz mit dem TCP Nachrichtenformat befasst und wollen nun detaillierter auf die einzelnen Felder des Formats eingehen:

  • Source Port
    Das 16 Bits lange Feld identifiziert den Quell-Port, also den Anfangspunkt der TCP-Verbindung, der mit einem bestimmten Anwendungsprozess assoziiert ist, der die Verbindung gestartet hat. Dies kann im Fall einer aktiven Verbindungsaufnahme eine frei gewählte Portnummer (Ephemeral Port Number) sein bzw. im Fall eines Antwortsegments auch eine wohlbekannte bzw. registrierte Portnummer, die einer bestimmten (Server-)Anwendung zugeordnet ist.
  • Destination Port
    16 Bits langes Feld für den Ziel-Port, also den Endpunkt der TCP-Verbindung, an den die Daten adressiert sind. Mit dem Ziel-Port ist ebenfalls wieder ein Anwendungsprozess assoziiert, der die über die Verbindung übertragenen Daten entgegennimmt. Im Falle einer aktiven Verbindungsaufnahme kann es sich um eine wohlbekannte bzw. registrierte Portnummer handeln, die die adressierte Server-Anwendung bezeichnet. Bei einem Antwortsegment kann es sich um eine freigewählte Portnummer handeln, die im vorangegangenen, empfangenen Segment mitgeteilt wurde.
  • Sequenznummer
    Anhand der 32 Bits langen Sequenznummer werden die gesendeten Daten-Segmente in Senderichtung durchnummeriert. Beim Aufbau einer TCP-Verbindung generieren beide Kommunikationspartner jeweils eine Start-Sequenznummer (Initial Segment Number, ISN). Diese Start-Sequenznummern werden im Drei-Wege-Handshake beim Verbindungsaufbau ausgetauscht und gegenseitig bestätigt. Damit Sequenznummern für eine bestimmte Verbindung stets eindeutig bleiben, muss ausgeschlossen werden, dass sich Sequenznummern innerhalb der festgesetzten Lebenszeit eines TCP-Segments wiederholen. Der Sender erhöht dazu die aktuelle Sequenznummer um die Anzahl der bereits gesendeten Bytes.
  • Bestätigungsnummer
    Auf die Sequenznummer folgt die ebenfalls 32 Bits lange Bestätigungsnummer (Acknowledgement-Number). Diese dient auf Empfängerseite als Bestätigung empfangener Datensegmente. Die Bestätigungsnummer wird vom jeweiligen Empfänger gesetzt, um dem Sender mitzuteilen, bis zu welcher Sequenznummer die gesendeten Daten bisher korrekt empfangen wurden.

Lastverhalten

Bei nur geringer Auslastung besteht bei Ethernet nahezu keine Wartezeit. Der Zugriff auf das Übertragungsmedium erfolgt sofort. Bei Token Ring dagegen muss auch bei sehr geringer Belastung mindestens die Dauer der gesamten Rotation des Tokens abgewartet werden, bevor ein Rechner eine Zugriffsberechtigung erhält. Dieses Verhalten ändert sich bei sehr hoher Auslastung. Während sich bei Ethernet die Anzahl der möglichen Kollisionen bei steigender Last erhöht und damit die Effizienz beeinträchtigt werden kann, zeigt Token Ring ein sehr gutes Lastverhalten und verliert auch mit zunehmender Auslastung nicht weiter an Effizienz.

Overhead

Um zu verhindern, dass in Folge einer Kollision unvollständige Datenpakete bei Ethernet auf das Übertragungsmedium gelangen können, ist hier die minimale Datenpaketlänge auf 64 Bytes festgelegt. Besteht die zu versendende Nutzdateninformation, wie etwa im Fall einer Terminaleingabe aus einzelnen Buchstaben, so tritt ein signifikanter Overhead auf. Bei Token Ring dagegen sind beliebig kurze Datenpakete möglich. Ebenso sind bei Token Ring sehr lange Datenpakete möglich, deren Länge nur von der maximalen THT (Token Holding Time) beschränkt wird.

Verkabelung

Token Ring Netzwerke können theoretisch über jedes beliebigen Übertragungsmedium – angefangen von der Brieftaube (siehe RFC 1149) bis hin zur Glasfaser – aufgebaut werden. Das gewöhnlich verwendete Twisted-Pair Kabel (verdrilltes Kupferkabel) ist preiswert und einfach zu verlegen. Busverkabelungen im Ethernet (10Base-2, 10Base-5) sind kostenintensiv und unterliegen vielen Restriktionen hinsichtlich der Konfektionierung und Verlegung. Seit der Einführung von Twisted-Pair Verkabelungen für Ethernet (10Base-T) besteht dieses Problem allerdings nicht mehr. Token Ring besitzt überdies die Fähigkeit, Fehler im Übertragungsmedium zu lokalisieren und im begrenzten Umfang zu umgehen. Die Kabellänge bei Ethernet ist beschränkt auf 2.5 km (10 Mbps), sie beeinflusst die Mindestlänge der Datenpakete.

Aufbau Netzwerkadapter

Im Gegensatz zu einem Token Ring, der über einfache Punkt-zu-Punkt Verbindungen aufgebaut werden kann, dessen Netzwerkadapter für die einzelnen, angeschlossenen Rechnern sehr einfach aufgebaut sind und die vollständig digital arbeiten, werden im Ethernet komplexere Komponenten (Transceiver) gebraucht, um einen Zugang zum Netzwerk zu gewährleisten. Ein Ethernet-Transceiver enthält substantiell analoge Komponenten, die in der Lage sein müssen, auch schwache Signale anderer an das Ethernet angeschlossener Rechner zu erkennen. Darüber hinaus müssen Transceiver auch während des Sendevorgangs entfernte Kollisionen auf dem Übertragungsmedium feststellen können.

ZigBee – IEEE 802.15.4

Zigbee

Das Ziel des 2003 von der IEEE 802.15.4 Arbeitsgruppe verabschiedeten Standards war die Spezifikation einer Familie von kabellos miteinander vernetzten Geräten im Heimbereich (Wireless Home Area Networks, WHAN), die sich durch eine möglichst geringe Leistungsaufnahme und eine möglichst mehrjährige Batterielebensdauer auszeichnen. Anders als bei WLAN oder Bluetooth sollen auch Geräte mit einer deutlich geringeren Komplexität in die Lage versetzt werden, eine möglichst kostengünstige kabellose Kommunikationsinfrastruktur aufzubauen. Zu diesen einfachen Geräten gehören kabellose Lichtschalter, Strommesszähler für den Haushalt, Fernsteuerung und Kopplung von Unterhaltungselektronik und Haushaltsgeräten, aber auch Sensoren und Aktoren zur Überwachung und Steuerung industrieller Prozesse.