Ein Vergleich des UDP-Protokollkopfes (Abschnitt 4.3 User Datagram Protocol) mit dem TCP-Protokollkopf (Segmentkopf) zeigt die Komplexität des Protokolls. Da TCP ein Transportprotokoll ist, also Daten einer Anwendung zustellen muss, sind auch auch hier die Portnummern von Sender- und Empfängeranwendung zu finden, aber darüberhinaus auch Angaben für das Bestätigungsverfahren und noch weitere Felder. Im Folgenden soll der Segmentkopf kurz vorgestellt werden.
Auffällig ist das Fehlen einer Längenangabe für das Segment. Theoretisch kann es beliebig groß werden. Allerdings legt das Protokoll eine maximale Segmentgröße mit einer Voreinstellung von 536 Bytes fest, worauf bereits im Abschnitt 4.4.1 (Byteströme und Segmente) hingewiesen wurde. Dort wurde auch festgestellt, dass die beiden miteinander kommunizierenden TCP-Systeme im gegenseitigen Einvernehmen davon abweichen können, wofür ein Optionen-Feld im Protokollkopf definiert werden kann. Die folgende Darstellung zeigt den TCP-Header in der für Protokollköpfe üblichen Breite von 4 Bytes:
Jeder Segmentkopf beginnt mit den beiden 16 Bits großen Feldern für die Portnummern der beiden beteiligten Anwendungen. Wie bei UDP können auch bei TCP Portnummern nicht größer als 65.535 werden.
Den beiden Portnummern folgen im TCP-Header zwei jeweils 32 Bits große Felder, von denen das erste die jeweils aktuelle Sequenznummer und das zweite eine Bestätigungsnummer enthält, wobei diese vom Empfänger nur dann ausgewertet wird, wenn ein bestimmtes Kontrollbit gesetzt worden ist. Auf die Kontrollbits wird im übernächsten Absatz eingegangen.
Nach dem Feld für eine Bestätigungsnummer kommt ein 4 Bits großes Feld namens Data Offset, das in der Grafik DO genannt wird. Dieses Feld wird benötigt, weil es im Segmentkopf ein Optionenfeld gibt, dessen genaue Länge nicht feststeht. Das DO-Feld enthält eine positive ganze Zahl, die, wenn sie mit 4 multipliziert wird, die Größe des Headers in Bytes angibt. In einem 4 Bits großen Feld kann höchstens die Zahl 15 stehen, was dazu führt, dass ein Segmentkopf höchstens 60 Bytes groß werden kann. Gibt es keine Optionen, dann hat das DO-Feld den Wert 5. Das ist der kleinste Wert, der in diesem Feld stehen darf. Der Segmentkopf hat dann eine Länge von 20 Bytes. Das hat zur Folge, dass der Platz für mögliche Optionen auf 40 Bytes beschränkt ist.
Dem DO-Feld folgen 12 Kontrollbits (Flags), von denen lediglich sechs verwendet werden. Der Rest ist für zukünftige Entwicklungen reserviert. Es handelt sich um die folgenden Bits:
An die 12 Kontrollbits schließt sich ein 16 Bits großes Feld namens Sliding Window an. Mit diesem Begriff ist eine Technik verbunden, mit der ein Empfänger eines Segments, der ja den für das Segment erforderlichen Speicherplatz bereit stellen muss, dem Sender einen Kreditrahmen für die Anzahl der maximal an ihn zu sendenden Bytes vorgibt. Anschaulich heißt das, dass vor einer Segmentübermittlung der Empfänger dem Sender mitteilt, wieviel Platz er zur Zeit zur Verfügung stellen kann. Der Sender überträgt dann nicht mehr Bytes als die Fenstergröße angibt. Diese kann im laufenden Betrieb an veränderte Umstände angepasst werden.
Im Segmentkopf folgt auf das Sliding-Window-Feld eine 16 Bits große Prüfzahl, die vom Empfänger immer ausgewertet wird. Wird beim Empfang eines Segments ein Prüfzahlfehler festgestellt, dann wird der Empfang des Segments bzw. der Empfang der darin enthaltenen Anwendungsdaten nicht bestätigt. Das Segment wird ohne jede Meldung verworfen. Auf eine genaue Berechnung der Prüfzahl soll hier nicht eingegangenen werden. Festzuhalten ist aber, dass diese Prüfzahl wie beim UDP-Header folgende Angaben umfasst:
Nach der Prüfzahl kommt ein 16 Bits großes Feld, das einen Zeiger auf wichtige Daten enthält. Das heißt, dass es bei TCP möglich ist, in ein Segment Anwendungsdaten aufzunehmen, die vom Empfänger mit Vorrang zu behandeln sind. Gibt es solche Daten, dann müssen sie am Anfang des Anwendungsdatenbereichs des Segments stehen und es muss das URG-Bit im Feld der Kontrollbits gesetzt sein. Der Wert des Zeiger-auf-wichtige-Daten-Felds addiert zum Wert des Sequenznummernfeldes ergibt die Sequenznummer des ersten Bytes an Anwendungsdaten nach den wichtigen Daten. Mit diesem Mechanismus kann beispielsweise neben einem Strom an Anwendungsdaten ein Strom an Kontrolldaten übertragen werden.
Das letzte Feld im TCP-Header ist das Feld für Optionen. Bei der Beschreibung des DO-Feldes ist bereits dargelegt worden, dass es maximal 40 Bytes aufnehmen kann. Der Inhalt ist nicht genormt, meist fehlt er, denn Optionen können nur dann sinnvoll verwendet werden, wenn sie vom jeweiligen Partner ausgewertet werden. Eine bereits angesprochene, allerdings ebenfalls nicht genormte Option ist die Angabe einer maximalen Segmentgröße in den ersten Segmenten. Öfter diskutiert werden auch die Angabe eines Zeitstempels (Timestamp) oder Zugriffsberechtigungen. Die in der Grafik angegebenen Füllbits sind 0-Bits und dienen dazu, gegebenenfalls eine Zeilenbreite von 32 Bits herzustellen (Padding).
Mit netstat steht ein weit verbreitetes Netzwerkdiagnose-Werkzeug insbesondere für UDP und TCP zur Verfügung. Es ist kein Bestandteil der Protokollsoftware, gehört jedoch als Standard zum Lieferumfang der Internet-Protokolle. Der unterschiedliche Leistungsumfang der Implementierungen und ihre Parametrisierungsmöglichkeiten machen betriebssystembezogene Programmbeschreibungen erforderlich. Ein Aufruf ohne Parameter (unter Windows) zeigt die aktuellen UDP- und TCP-Verbindungen in der folgenden Form an, wobei den IP-Adressen durch Doppelpunkt gestrennt die jeweilige Portnummer folgt: