Transmission Control Protocol (TCP) ist eines der Kernprotokolle des Internetprotokoll-Gefolges. TCP ist einer der zwei ursprünglichen Bestandteile des Gefolges, Internet Protocol (IP) ergänzend, und deshalb wird das komplette Gefolge allgemein TCP/IP genannt. TCP stellt zuverlässige, bestellte Übergabe eines Stroms von Bytes aus einem Programm auf einem Computer zu einem anderen Programm auf einem anderen Computer zur Verfügung. TCP ist das Protokoll, das durch Hauptinternetanwendungen wie das World Wide Web, die E-Mail, die Fernverwaltung und die Dateiübertragung verwendet ist. Andere Anwendungen, die zuverlässigen Datenstrom-Dienst nicht verlangen, können User Datagram Protocol (UDP) verwenden, das einen Datenpaket-Dienst zur Verfügung stellt, der reduzierte Latenz über die Zuverlässigkeit betont.

Historischer Ursprung

Im Mai 1974 hat das Institut für Elektrische und Elektronische Ingenieure (IEEE) eine Zeitung betitelt "Ein Protokoll für die Gegenseitige Paket-Netzverbindung veröffentlicht." Die Autoren von Papier, Vint Cerf und Bob Kahn, haben ein Zwischennetzwerkanschlussprotokoll beschrieben, um Mittel zu teilen, die Paketvermittlungs-unter den Knoten verwenden. Ein Hauptkontrollbestandteil dieses Modells war das Übertragungskontrollprogramm, das sowohl Verbindungsorientierte Verbindungen als auch Datenpaket-Dienstleistungen zwischen Gastgebern vereinigt hat. Das monolithische Übertragungskontrollprogramm wurde später in eine Modularchitektur geteilt, die aus dem Übertragungskontrollprotokoll an der Verbindungsorientierten Schicht und dem Internetprotokoll beim Zwischennetzwerkanschluss (Datenpaket) Schicht besteht. Das Modell ist bekannt informell als TCP/IP geworden, obwohl formell es künftig das Internetprotokoll-Gefolge genannt wurde.

Netzfunktion

Das Protokoll entspricht wirklich der Transportschicht des TCP/IP Gefolges. TCP stellt einen Nachrichtendienst an einem Zwischenniveau zwischen einem Anwendungsprogramm und Internet Protocol (IP) zur Verfügung. D. h. wenn ein Anwendungsprogramm wünscht, einen großen Klotz von Daten über das Internet mit IP zu senden, anstatt die Daten in IP-sized Stücke zu brechen und eine Reihe von IP-Bitten auszugeben, kann die Software eine einzelne Bitte zu TCP ausgeben und kann TCP die IP Details behandeln lassen.

IP Arbeiten durch das Austauschen der Information haben Pakete genannt. Ein Paket ist eine Folge von Oktetten und besteht aus einem von einem Körper gefolgten Kopfball. Der Kopfball beschreibt den Bestimmungsort des Pakets und, fakultativ, die Router, um zu verwenden, um nachzuschicken, bis es seinen Bestimmungsort erreicht. Der Körper enthält die Daten, die IP übersendet.

Wegen der Netzverkehrsstauung, des Verkehrslastausgleichens oder des anderen unvorhersehbaren Netzverhaltens, können IP Pakete verloren, kopiert, oder in Unordnung geliefert werden. TCP entdeckt diese Probleme, bittet um Weitermeldung von verlorenen Daten, ordnet in Unordnung Daten um, und hilft sogar, Netzverkehrsstauung zu minimieren, um das Ereignis der anderen Probleme zu reduzieren. Sobald der TCP Empfänger die Folge von ursprünglich übersandten Oktetten wieder versammelt hat, passiert es ihnen zum Anwendungsprogramm. So abstrahiert TCP die Kommunikation der Anwendung von den zu Grunde liegenden Netzwerkanschlussdetails.

TCP wird umfassend durch viele der populärsten Anwendungen des Internets, einschließlich des World Wide Web (WWW), der E-Mails, des Dateiübertragungsprotokolls, Sicheren Shell, des Gleicher-zu-Gleicher-Dateiteilens und einiger strömender Mediaanwendungen verwertet.

TCP wird für die genaue Übergabe aber nicht rechtzeitige Übergabe, und deshalb optimiert, TCP übernimmt manchmal relativ lange Verzögerungen (in der Ordnung von Sekunden), während er auf in Unordnung Nachrichten oder Weitermeldungen von verlorenen Nachrichten wartet. Es ist für Echtzeitanwendungen wie Begleitkommentar IP nicht besonders passend. Für solche Anwendungen werden Protokolle wie Real-time Transport Protocol (RTP), das User Datagram Protocol (UDP) überfährt, gewöhnlich stattdessen empfohlen.

TCP ist ein zuverlässiger Strom-Zustelldienst, der versichert, dass alle erhaltenen Bytes mit Bytes gesandt und in der richtigen Ordnung identisch sein werden. Da Paket-Übertragung nicht zuverlässig ist, wird eine Technik, die als positive Anerkennung mit der Weitermeldung bekannt ist, verwendet, um Zuverlässigkeit von Paket-Übertragungen zu versichern. Diese grundsätzliche Technik verlangt, dass der Empfänger mit einer Anerkennungsnachricht erwidert, weil es die Daten erhält. Der Absender behält eine Aufzeichnung jedes Pakets, das sie sendet. Der Absender behält auch einen Zeitmesser davon, als das Paket gesandt wurde, und ein Paket wiederübersendet, wenn der Zeitmesser abläuft, bevor die Nachricht anerkannt worden ist. Der Zeitmesser ist erforderlich, im Falle dass ein Paket verloren wird oder verdorben ist.

TCP besteht aus einer Reihe von Regeln: Für das Protokoll, die mit dem Internetprotokoll, und für den IP verwendet werden, um Daten "in einer Form von Nachrichteneinheiten" zwischen Computern über das Internet zu senden. Während IP wirkliche Übergabe der Daten behandelt, geht TCP die individuellen Einheiten der Datenübertragung, genannt Segmente nach, dass eine Nachricht in für die effiziente Routenplanung durch das Netz geteilt wird. Zum Beispiel, wenn eine HTML-Datei von einem Webserver gesandt wird, teilt die TCP Softwareschicht dieses Servers die Folge von Oktetten der Datei in Segmente und vorwärts sie individuell zur IP Softwareschicht (Internetschicht). Die Internetschicht fasst jedes TCP Segment in ein IP Paket durch das Hinzufügen eines Kopfballs kurz zusammen, der (unter anderen Daten) den Bestimmungsort IP Adresse einschließt. Wenn auch jedes Paket dieselbe Bestimmungsort-Adresse hat, können sie auf verschiedenen Pfaden durch das Netz aufgewühlt werden. Wenn das Kundenprogramm auf dem Bestimmungsort-Computer sie erhält, versammelt die TCP Schicht (Transportschicht) die individuellen Segmente wieder und stellt sicher, dass ihnen richtig bestellt wird und freier Fehler, weil es sie zu einer Anwendung verströmt.

TCP Segment-Struktur

Übertragungskontrollprotokoll akzeptiert Daten von einem Datenstrom, segmentiert ihn in Klötze, und fügt einen TCP Kopfball hinzu, der ein TCP Segment schafft. Das TCP Segment wird dann in ein Datenpaket von Internet Protocol (IP) kurz zusammengefasst. Ein TCP Segment ist "das Paket der Information dass TCP-Gebrauch, um Daten mit seinen Gleichen auszutauschen."

Der Begriff TCP Paket, obwohl manchmal informell verwendet, stimmt mit aktueller Fachsprache nicht überein, wo sich Segment auf den TCP PDU (Protokoll-Dateneinheit), Datenpaket zum IP PDU und Rahmen zu den Daten bezieht, verbindet Schicht PDU:

Ein TCP Segment besteht aus einem Segment-Kopfball und einer Datenabteilung. Der TCP Kopfball enthält 10 obligatorische Felder und ein fakultatives Erweiterungsfeld (Optionen, Orangenhintergrund im Tisch).

Die Datenabteilung folgt dem Kopfball. Sein Inhalt ist die für die Anwendung getragenen Nutzlast-Daten. Die Länge der Datenabteilung wird im TCP Segment-Kopfball nicht angegeben. Es kann durch das Abziehen der vereinigten Länge des TCP Kopfballs und des kurz zusammenfassenden IP Kopfballs von der IP Gesamtdatenpaket-Länge (angegeben im IP Kopfball) berechnet werden.

• Quellhafen (16 Bit) - identifiziert den Senden-Hafen
• Bestimmungsort-Hafen (16 Bit) - identifiziert den Empfang-Hafen
• Folge-Zahl (32 Bit) - hat eine Doppelrolle:

:* Wenn die Fahne (1) gesetzt wird, dann ist das die anfängliche Folge-Zahl. Die Folge-Zahl des wirklichen ersten Datenbytes und die anerkannte Zahl im entsprechenden ACK sind dann diese Folge-Zahl plus 1.

:* Wenn die Fahne (0) klar ist, dann ist das die angesammelte Folge-Zahl des ersten Datenbytes dieses Pakets für die aktuelle Sitzung.

• Anerkennungszahl (32 Bit) - wenn die Fahne dann der Wert dieses Feldes gesetzt wird, ist die folgende Folge-Zahl, die der Empfänger erwartet. Das erkennt Einnahme aller vorherigen Bytes (wenn irgendwelcher) an. Das bis zu jedem Ende gesandte erste erkennt die anfängliche Folge-Zahl des anderen Endes selbst, aber keine Daten an.
• Daten gleichen (4 Bit) aus - gibt die Größe des TCP Kopfballs in 32-Bit-Wörtern an. Der minimale Größe-Kopfball ist 5 Wörter, und das Maximum ist 15 Wörter, die so die minimale Größe von 20 Bytes und das Maximum von 60 Bytes geben, bis zu 40 Bytes von Optionen im Kopfball berücksichtigend. Dieses Feld bekommt seinen Namen von der Tatsache, dass es auch der Ausgleich vom Anfang des TCP Segmentes zu den wirklichen Daten ist.
• Vorbestellt (3 Bit) - für den zukünftigen Gebrauch und sollte auf die Null gesetzt werden
• Fahnen (9 Bit) (auch bekannt als Kontrollbit) - enthalten 9 1-Bit-Fahnen

:* (1 Bit) - ECN-nonce Verbergen-Schutz (hinzugefügt zum Kopfball durch RFC 3540).

:* (1 Bit) - Fahne von Congestion Window Reduced (CWR) wird vom Senden-Gastgeber veranlasst anzuzeigen, dass es ein TCP Segment mit dem Fahne-Satz erhalten hat und im Verkehrsstauungskontrollmechanismus (hinzugefügt zum Kopfball durch RFC 3168) geantwortet hatte.

:* (1 Bit) - ECN-Echo zeigt an

::* Wenn die Fahne (1) gesetzt wird, dass der TCP-Gleiche fähig ECN ist.

::* Wenn die Fahne (0) klar ist, dass ein Paket mit der Verkehrsstauung Erfahrene Fahne im IP Kopfball-Satz während der normalen Übertragung (hinzugefügt zum Kopfball durch RFC 3168) erhalten wird.

:* (1 Bit) - zeigt an, dass das Dringende Zeigestock-Feld bedeutender ist

:* (1 Bit) - zeigt an, dass das Anerkennungsfeld bedeutend ist. Alle Pakete nach dem anfänglichen vom Kunden gesandten Paket sollten diese Fahne setzen lassen.

:* (1 Bit) - Stoß-Funktion. Bittet, die gepufferten Daten zur Empfang-Anwendung zu stoßen.

:* (1 Bit) - Rücksetzen die Verbindung

:* (1 Bit) - Synchronisiert Folge-Zahlen. Nur das erste von jedem Ende gesandte Paket sollte diese Fahne setzen lassen. Eine andere Fahne-Änderung, die gestützt auf dieser Fahne bedeutet, und sind einige nur dafür gültig, wenn es gesetzt wird, und andere, wenn es klar ist.

:* (1 Bit) - Keine Daten mehr vom Absender

• Fenstergröße (16 Bit) - die Größe des erhalten Fensters, das die Zahl von Bytes angibt (außer der Folge-Zahl im Anerkennungsfeld), den der Absender dieses Segmentes zurzeit bereit ist zu erhalten (sieh Fluss-Kontrolle und Fensterschuppen)
• Kontrollsumme (16 Bit) - Das 16-Bit-Kontrollsumme-Feld wird für die Fehlerüberprüfung des Kopfballs und der Daten verwendet
• Dringender Zeigestock (16 Bit) - wenn die Fahne gesetzt wird, dann ist dieses 16-Bit-Feld ein Ausgleich von der Folge-Zahl, die das letzte dringende Datenbyte anzeigt
• Optionen (Variable 0-320 Bit, die durch 32 teilbar sind) - Die Länge dieses Feldes wird durch das Datenausgleich-Feld bestimmt. Optionen haben bis zu drei Felder: Auswahl-Art (1 Byte), Auswahl-Länge (1 Byte), Auswahl-Daten (Variable). Das mit der Auswahl freundliche Feld zeigt den Typ der Auswahl an, und ist das einzige Feld, das nicht fakultativ ist. Je nachdem, mit welcher Auswahl wir uns befassen, können die folgenden zwei Felder gesetzt werden: Das Feld der Auswahl-Länge zeigt die Gesamtlänge der Auswahl an, und das Feld der Auswahl-Daten enthält den Wert der Auswahl, wenn anwendbar. Zum Beispiel zeigt ein mit der Auswahl freundliches Byte von 0x01 an, dass das Keine-Op Auswahl verwendet nur für das Polstern ist, und keine Auswahl-Länge oder Byte der Auswahl-Daten im Anschluss daran hat. Ein mit der Auswahl freundliches Byte 0 ist das Ende der Optionsauswahl, und ist auch nur ein Byte. Ein mit der Auswahl freundliches Byte von 0x02 zeigt an, dass das die Maximale Segment-Größe-Auswahl ist, und von einem Byte gefolgt wird, das die Länge des FRAU-Feldes angibt (sollte 0x04 sein). Bemerken Sie, dass diese Länge die Gesamtlänge des gegebenen Optionsfeldes einschließlich Bytes der Auswahl-Art und Auswahl-Länge ist. So, während die FRAUEN schätzen, wird normalerweise in zwei Bytes ausgedrückt, die Länge des Feldes wird 4 Bytes (+2 Bytes der Art und Länge) sein. Kurz gesagt, ein FRAU-Auswahl-Feld mit einem Wert von 0x05B4 wird als (0x02 0x04 0x05B4) in der TCP Optionsabteilung auftauchen.

Wenn man

• auspolstert - wird Das TCP Kopfball-Polstern verwendet, um sicherzustellen, dass die TCP Kopfball-Enden und Daten an einer 32-Bit-Grenze beginnen. Das Polstern wird aus Nullen zusammengesetzt.

Einige Optionen können nur gesandt werden, wenn gesetzt wird; sie werden unten als angezeigt. Auswahl-Art und Standardlängen gegeben als (Auswahl-Art, Auswahl-Länge).

:*0 (8 Bit) - Ende von Optionen verzeichnen

:*1 (8 Bit) - Keine Operation (NOP Auspolsternd) kann Das verwendet werden, um Auswahl-Felder an 32-Bit-Grenzen für die bessere Leistung auszurichten.

:*2,4, SS (32 Bit) - Maximale Segment-Größe (sieh maximale Segment-Größe)

:*3,3, S (24 Bit) - Fensterskala (sieh Fenster für Details klettern)

:*4,2 (16 Bit) - Auswählende Anerkennung hat erlaubt. (Sieh auswählende Anerkennungen für Details)

:*5, N, BBBB, EEEE... (variable Bit, N ist entweder 10, 18, 26, oder 34) - Auswählende Anerkennung (SACK) wird Diesen ersten zwei Bytes von einer Liste von 1-4 Blöcken gefolgt, die auswählend anerkennen werden, angegeben, weil 32 Bit Zeigestöcke/beenden beginnen.

:*8,10, TTTT, EEEE (80 Bit) - Zeitstempel und Echo des vorherigen Zeitstempels (sieh TCP Zeitstempel für Details)

:*14,3, S (24 Bit) - TCP Stellvertreter-Kontrollsumme-Bitte.

:*15, N... (variable Bit) - TCP Stellvertreter-Kontrollsumme-Daten.

: (Die restlichen Optionen sind veraltet, noch nicht standardisierten experimentell oder unbestimmt)

Protokoll-Operation

TCP Protokoll-Operationen können in drei Phasen geteilt werden. Verbindungen müssen in einem Mehrschritt-Händedruck-Prozess richtig hergestellt werden (Verbindungserrichtung) vor dem Eingehen in die Daten übertragen Phase. Nachdem Datenübertragung vollendet wird, haben die Verbindungsbeendigungsenden virtuelle Stromkreise gegründet und veröffentlichen alle zugeteilten Mittel.

Eine TCP Verbindung wird durch ein Betriebssystem durch eine Programmierschnittstelle geführt, die den lokalen Endpunkt für Kommunikationen, die Internetsteckdose vertritt. Während der Lebenszeit einer TCP Verbindung erlebt es eine Reihe von Zustandsänderungen:

1. DAS HÖREN: Im Falle eines Servers, auf eine Verbindung wartend, bitten von jedem entfernten Kunden.
2. GESYN-SANDT: Das Warten für den entfernten Gleichen, um ein TCP Segment mit dem SYN und ACK Fahne-Satz zurückzusenden. ('GESYN-SANDT' Staat wird gewöhnlich von TCP Kunden gesetzt)
3. SYN-ERHALTEN: Das Warten für den entfernten Gleichen, um eine Anerkennung zurückzusenden, eine Verbindungsanerkennung dem entfernten Gleichen zurückgesendet. ('SYN-ERHALTENER' Staat wird gewöhnlich durch TCP Server gesetzt)
4. GEGRÜNDET: Der Hafen ist bereit, Daten von\zu dem entfernten Gleichen zu erhalten zu/senden.
5. FIN-WAIT-1: Angezeigt, auf den der Server für den Anwendungsprozess auf seinem Ende wartet, um Zeichen zu geben, dass es bereit ist zu schließen.
6. FIN-WAIT-2: Zeigt An, dass der Kunde auf das Finanzsegment des Servers wartet (der anzeigt, dass der Anwendungsprozess des Servers bereit ist zu schließen und der Server bereit ist, seine Seite der Verbindungsbeendigung zu beginnen)

,

1. NAHE - WARTEN SIE: Der Server erhält Benachrichtigung aus der lokalen Anwendung, dass es getan wird. Der Server sendet seine Flosse dem Kunden.
2. LETZT-ACK: Zeigt An, dass der Server im Prozess ist, sein eigenes Finanzsegment zu senden (der anzeigt, dass der Anwendungsprozess des Servers bereit ist zu schließen und der Server bereit ist, seine Seite der Verbindungsbeendigung zu beginnen)

,

1. ZEIT - WARTET: Vertritt das Warten für genug Zeit, um zu gehen, um sicher zu sein, dass der entfernte Gleiche die Anerkennung seiner Verbindungsbeendigungsbitte erhalten hat. Gemäß RFC 793 kann eine Verbindung in der ZEIT bleiben - WARTEN auf ein Maximum von vier Minuten bekannt als ein MSL (maximale Segment-Lebenszeit).
2. GESCHLOSSEN: Verbindung wird geschlossen

Verbindungserrichtung

Um eine Verbindung herzustellen, verwendet TCP einen dreiseitigen Händedruck.

Bevor ein Kunde versucht, mit einem Server in Verbindung zu stehen, muss der Server zuerst zu einem Hafen binden, um ihn für Verbindungen zu öffnen: Das wird einen passiven offenen genannt.

Sobald das passive offene gegründet wird, kann ein Kunde einen aktiven offenen beginnen.

Um eine Verbindung das dreiseitige (oder 3-Schritte-) herzustellen, kommt Händedruck vor:

1. SYN: Das aktive offene wird vom Kunden durchgeführt, der einen SYN an den Server sendet. Der Kunde setzt die Folge-Zahl des Segmentes auf einen zufälligen Wert A.
2. SYN-ACK: Als Antwort antwortet der Server mit einem SYN-ACK. Die Anerkennungszahl wird auf einen mehr gesetzt als die erhaltene Folge-Zahl (+ 1), und die Folge-Zahl, die der Server für das Paket wählt, ist eine andere Zufallszahl, B.
3. ACK: Schließlich sendet der Kunde einen ACK an den Server zurück. Die Folge-Zahl wird auf den erhaltenen Anerkennungswert gesetzt d. h. + 1, und die Anerkennungszahl wird auf einen mehr gesetzt als die erhaltene Folge-Zahl d. h. B + 1.

An diesem Punkt haben sowohl der Kunde als auch Server eine Anerkennung der Verbindung erhalten.

Verbindungsbeendigung

Der Verbindungsbeendigungsphase-Gebrauch, höchstens, ein vierwegiger Händedruck, mit jeder Seite der Verbindung, die unabhängig endet. Wenn ein Endpunkt seine Hälfte der Verbindung aufhören möchte, übersendet er ein FINANZ-Paket, das das andere Ende mit einem ACK anerkennt. Deshalb verlangt eine typische Träne unten ein Paar der FLOSSE und ACK Segmente von jedem TCP Endpunkt. Nach beiden wird FIN/ACK-Austausch geschlossen, die endende Seite wartet auf eine Pause vor dem Endschließen der Verbindung, während deren Zeit der lokale Hafen für neue Verbindungen nicht verfügbar ist; das verhindert Verwirrung wegen verzögerter Pakete, die während nachfolgender Verbindungen liefern werden.

Eine Verbindung kann "halb offen" sein, in welchem Fall eine Seite sein Ende begrenzt hat, aber der andere hat nicht. Die Seite, die geendet hat, kann irgendwelche Daten in die Verbindung nicht mehr senden, aber die andere Seite kann. Die endende Seite sollte fortsetzen, die Daten zu lesen, bis die andere Seite ebenso endet.

Es ist auch möglich, die Verbindung durch einen 3-wegigen Händedruck zu begrenzen, wenn Gastgeber A eine FLOSSE sendet und Antworten des Gastgebers B mit FIN & ACK (bloß 2 Schritte in einen verbindet) und veranstalten Sie Antworten mit einem ACK. Das ist vielleicht der grösste Teil der üblichen Methodik.

Es ist für beide Gastgeber möglich, FLOSSEN gleichzeitig dann zu senden, beide haben gerade zu ACK. Das konnte vielleicht als ein 2-wegiger Händedruck betrachtet werden, da die FIN/ACK Folge in der Parallele für beide Richtungen getan wird.

Ein Gastgeber TCP Stapel können eine nahe Halbduplexfolge, als Linux oder HP-UX durchführen, tut. Wenn solch ein Gastgeber aktiv eine Verbindung schließt, aber noch alle eingehenden Daten der von der Verbindung bereits erhaltene Stapel nicht gelesen hat, sendet dieser Gastgeber einen RST statt einer FLOSSE (Abschnitt 4.2.2.13 RFC 1122). Das erlaubt einer TCP Anwendung, sicher zu sein, dass die entfernte Anwendung alle Daten der erstere gesandt — das Warten auf die FLOSSE von der entfernten Seite gelesen hat, wenn es aktiv die Verbindung schließt. Jedoch kann der entfernte TCP-Stapel nicht zwischen einer Verbindung unterscheiden, die RST und diesem Datenverlust RST Abbricht. Beider veranlassen den entfernten Stapel, alle Daten wegzuwerfen, die er erhalten hat, aber dass die Anwendung noch nicht gelesen hat.

Einige Anwendungsprotokolle können die OSI Musterschichten mit dem TCP verletzen offene/nahe handshaking für das Anwendungsprotokoll öffnen handshaking/schließen — diese können das RST Problem auf dem aktiven Ende finden. Als ein Beispiel:

s = stehen Sie (entfernt) in Verbindung;

senden Sie (s, Daten);

Ende (N);

Für einen üblichen Programm-Fluss wie obengenannter versichert ein TCP/IP-Stapel wie das, das oben beschrieben ist, nicht, dass alle Daten in die andere Anwendung ankommen.

Quellengebrauch

Die meisten Durchführungen teilen einen Zugang in einem Tisch zu, der eine Sitzung zu einem Laufen Betriebssystemprozess kartografisch darstellt. Weil TCP Pakete keinen Sitzungsbezeichner einschließen, identifizieren beide Endpunkte die Sitzung mit der Adresse und Hafen des Kunden. Wann auch immer ein Paket erhalten wird, muss die TCP Durchführung einen lookup auf diesem Tisch durchführen, um den Bestimmungsort-Prozess zu finden.

Die Zahl von Sitzungen in der Server-Seite wird nur durch das Gedächtnis beschränkt und kann wachsen, als neue Verbindungen ankommen, aber der Kunde muss einen zufälligen Hafen vor dem Senden des ersten SYN zum Server zuteilen. Dieser Hafen bleibt zugeteilt während des ganzen Gespräches, und beschränkt effektiv die Zahl von aus dem Amt scheidest Verbindungen von jeder der IP-Adressen des Kunden. Wenn eine Anwendung scheitert, unerforderliche Verbindungen richtig zu schließen, kann ein Kunde an Mitteln knapp werden und unfähig werden, neue TCP Verbindungen sogar aus anderen Anwendungen herzustellen.

Beide Endpunkte müssen auch Raum für nicht anerkannte Pakete und erhalten (aber ungelesen) Daten zuteilen.

Datenübertragung

Es gibt einige Hauptmerkmale, die TCP abgesondert vom Benutzerdatenpaket-Protokoll setzen:

• Bestellte Datenübertragung — der Bestimmungsort-Gastgeber ordnet gemäß der Folge-Zahl um
• Die Weitermeldung von verlorenen Paketen — jeder kumulative nicht anerkannte Strom wird wiederübersandt
• Fehlerfreie Daten übertragen
• Fluss-Kontrolle — beschränkt die Rate ein Absender überträgt Daten, um zuverlässige Übergabe zu versichern. Der Empfänger deutet ständig der Absender darauf an, wie viel Daten (kontrolliert vom gleitenden Fenster) erhalten werden können. Wenn sich der Empfang-Gastgeber-Puffer füllt, enthält die folgende Anerkennung 0 in der Fenstergröße, um Übertragung aufzuhören und den Daten im Puffer zu erlauben, bearbeitet zu werden.
• Verkehrsstauungskontrolle

Zuverlässige Übertragung

TCP verwendet eine Folge-Zahl, um jedes Byte von Daten zu identifizieren. Die Folge-Zahl identifiziert die Ordnung der von jedem Computer gesandten Bytes, so dass die Daten in der Ordnung, unabhängig von jeder Zersplitterung, disordering, oder Paket-Verlust wieder aufgebaut werden können, der während der Übertragung vorkommen kann.

Für jedes übersandte Nutzlast-Byte muss die Folge-Zahl erhöht werden. In den ersten zwei Schritten des 3-wegigen Händedrucks tauschen beide Computer eine anfängliche Folge-Zahl (ISN) aus. Diese Zahl kann willkürlich sein, und sollte tatsächlich unvorhersehbar sein, um gegen TCP Folge-Vorhersageangriffe zu verteidigen.

TCP verwendet in erster Linie ein kumulatives Anerkennungsschema, wohin der Empfänger eine Anerkennung sendet, die bedeutet, dass der Empfänger alle Daten erhalten hat, die der anerkannten Folge-Zahl vorangehen. Der Absender setzt das numerische Folge-Feld auf die Folge-Zahl des ersten Nutzlast-Bytes im Datenfeld des Segmentes, und der Empfänger sendet eine Anerkennung, die die Folge-Zahl des folgenden Bytes angibt, das sie annehmen zu erhalten. Zum Beispiel, wenn ein Senden-Computer ein Paket sendet, das vier Nutzlast-Bytes mit einem numerischen Folge-Feld 100 enthält, dann sind die Folge-Zahlen der vier Nutzlast-Bytes 100, 101, 102 und 103. Wenn dieses Paket den Empfang-Computer erreicht, würde es eine Anerkennungszahl 104 zurücksenden, da das die Folge-Zahl des folgenden Bytes ist, das es annimmt, im folgenden Paket zu erhalten.

Zusätzlich zu kumulativen Anerkennungen können TCP Empfänger auch auswählende Anerkennungen senden, um weitere Auskunft zu geben.

Wenn der Absender ableitet, dass Daten im Netz verloren worden sind, übersendet es die Daten wieder.

Fehlerentdeckung

Folge-Zahlen und Anerkennungsdeckel, der Doppelpakete, Weitermeldung von verlorenen Paketen und Übertragung der bestellten Daten verwirft.

Um Genauigkeit zu sichern, wird ein Kontrollsumme-Feld eingeschlossen (sieh TCP Segment-Struktur für Details auf checksumming).

Die TCP Kontrollsumme ist eine schwache Kontrolle nach modernen Standards. Datenverbindungsschichten mit hohen Bit-Fehlerraten können zusätzliche Verbindungsfehlerfähigkeiten der Korrektur/Entdeckung verlangen. Die schwache Kontrollsumme wird für durch die übliche Anwendung eines CRC oder besserer Integritätskontrolle an der Schicht 2, sowohl unter TCP als auch unter IP, solchem teilweise ersetzt, der in PPP oder dem Rahmen von Ethernet verwendet wird. Jedoch bedeutet das nicht, dass die TCP 16-Bit-Kontrollsumme überflüssig ist: Bemerkenswert ist die Einführung von Fehlern in Paketen zwischen GeCRC-schützten Sprüngen üblich, aber die TCP der Länge nach 16 Bit Kontrollsumme fängt die meisten dieser einfachen Fehler. Das ist der Länge nach Grundsatz bei der Arbeit.

Fluss-Kontrolle

TCP verwendet der Länge nach Fluss-Kontrollprotokoll, um zu vermeiden, den Absender zu haben, sendet Daten zu schnell für den TCP Empfänger, um ihn zuverlässig zu erhalten und zu bearbeiten. Einen Mechanismus für die Fluss-Kontrolle zu haben, ist in einer Umgebung notwendig, wo Maschinen von verschiedenen Netzgeschwindigkeiten kommunizieren. Zum Beispiel, wenn ein PC Daten an einen tragbaren PDA sendet, der erhaltene Daten langsam bearbeitet, muss der PDA Datenfluss regeln, um nicht überwältigt zu werden.

TCP verwendet ein gleitendes Fensterfluss-Kontrollprotokoll. In jedem TCP Segment gibt der Empfänger im erhalten Fenster an schicken den Betrag von zusätzlichen erhaltenen Daten aufs Feld (in Bytes), dass es zum Puffer für die Verbindung bereit ist. Der Senden-Gastgeber kann nur bis zu dieser Datenmenge senden, bevor sie auf eine Bestätigung und Fensteraktualisierung vom Empfang-Gastgeber warten muss.

Wenn ein Empfänger eine Fenstergröße 0 ankündigt, hört der Absender auf, Daten zu senden, und fängt den andauern Zeitmesser an. Der andauern Zeitmesser wird verwendet, um TCP vor einer Situation des toten Punktes zu schützen, die entstehen konnte, wenn eine nachfolgende Fenstergröße-Aktualisierung vom Empfänger verloren wird, und der Absender mehr Daten bis zum Empfang einer neuen Fenstergröße-Aktualisierung vom Empfänger nicht senden kann. Wenn der andauern Zeitmesser abläuft, versucht der TCP Absender Wiederherstellung, indem er ein kleines Paket sendet, so dass der Empfänger durch das Senden einer anderen Anerkennung antwortet, die die neue Fenstergröße enthält.

Wenn ein Empfänger eingehende Daten in der kleinen Zunahme bearbeitet, kann er wiederholt inserieren ein kleiner erhalten Fenster. Das wird das dumme Fenstersyndrom genannt, da es ineffizient ist, um nur einige Bytes von Daten in einem TCP Segment in Anbetracht des relativ großen oben des TCP Kopfballs zu senden. TCP Absender und Empfänger verwenden normalerweise Fluss-Kontrolllogik, um wiederholt spezifisch zu vermeiden, kleine Segmente zu senden. Die Absenderseite dumme Fenstersyndrom-Aufhebungslogik wird den Algorithmus von Nagle genannt.

Verkehrsstauungskontrolle

Der Endhauptaspekt von TCP ist Verkehrsstauungskontrolle. TCP verwendet mehrere Mechanismen, hohe Leistung zu erreichen und Verkehrsstauungszusammenbruch zu vermeiden, wo Netzleistung um mehrere Größenordnungen fallen kann. Diese Mechanismen kontrollieren die Rate von Daten, die ins Netz eingehen, den Datenfluss unter einer Rate behaltend, die Zusammenbruch auslösen würde. Sie geben auch eine ungefähr max-minutige schöne Zuteilung zwischen Flüssen nach.

Anerkennungen für Daten gesandt, oder fehlen von Anerkennungen, werden von Absendern verwendet, um Netzbedingungen zwischen dem TCP Absender und Empfänger abzuleiten. Verbunden mit Zeitmessern können TCP Absender und Empfänger das Verhalten des Datenflusses verändern. Das wird mehr allgemein Verkehrsstauungskontrolle und/oder Netzverkehrsstauungsaufhebung genannt.

Moderne Durchführungen von TCP enthalten vier verflochtene Algorithmen: Langsamer Anfang, Verkehrsstauungsaufhebung, übersendet schnell, und schnelle Wiederherstellung (RFC 5681) wieder.

Außerdem verwenden Absender eine Weitermeldungspause (RTO), der auf der geschätzten Rückfahrzeit (oder RTT) zwischen dem Absender und Empfänger, sowie der Abweichung in dieser Zeit der Hin- und Rückfahrt basiert. Das Verhalten dieses Zeitmessers wird in RFC 6298 angegeben. Es gibt Subtilität nach der Bewertung von RTT. Zum Beispiel müssen Absender sorgfältig sein, wenn sie RTT Proben für wiederübersandte Pakete berechnen; normalerweise verwenden sie den Algorithmus von Karn oder TCP Zeitstempel (sieh RFC 1323). Diese individuelle RTT Proben sind dann mit der Zeit durchschnittlich, um Smoothed Round Trip Time (SRTT) mit dem Algorithmus von Jacobson zu schaffen. Dieser SRTT-Wert ist, was schließlich als die Rückfahrzeitschätzung verwendet wird.

Wenn Sie

TCP erhöhen, um Verlust zuverlässig zu behandeln, minimieren Sie Fehler, führen Sie Verkehrsstauung und gehen Sie schnell in sehr schnelllaufenden Umgebungen sind andauernde Gebiete der Forschung und Standardentwicklung. Infolgedessen gibt es mehrere TCP Verkehrsstauungsaufhebungsalgorithmus-Schwankungen.

Maximale Segment-Größe

Die maximale Segment-Größe (MSS) ist die größte Datenmenge, die in Bytes angegeben ist, die TCP bereit ist, in einem einzelnen Segment zu erhalten. Für die beste Leistung sollten die FRAUEN klein genug gesetzt werden, um IP Zersplitterung zu vermeiden, die zu Paket-Verlust und übermäßigen Weitermeldungen führen kann. Um zu versuchen, das normalerweise zu vollbringen, werden die FRAUEN von jeder Seite mit der FRAU-Auswahl bekannt gegeben, wenn die TCP Verbindung hergestellt wird, in welchem Fall es aus der Größe der maximalen Übertragungseinheit (MTU) der Datenverbindungsschicht der Netze abgeleitet wird, denen der Absender und Empfänger direkt beigefügt werden. Außerdem können TCP Absender Pfad MTU Entdeckung verwenden, um den minimalen MTU entlang dem Netzpfad zwischen dem Absender und Empfänger abzuleiten, und das zu verwenden, um die FRAUEN dynamisch anzupassen, um IP Zersplitterung innerhalb des Netzes zu vermeiden.

FRAU-Ansage wird auch häufig "FRAU-Verhandlung" genannt. Genau genommen, die FRAUEN wird zwischen dem Schöpfer und dem Empfänger nicht "verhandelt", weil das andeuten würde, dass sowohl Schöpfer als auch Empfänger verhandeln und sich über eine Single, vereinigte FRAUEN einigen werden, der für die ganze Kommunikation in beiden Richtungen der Verbindung gilt. Tatsächlich werden zwei völlig unabhängige Werte von FRAUEN für die zwei Richtungen des Datenflusses in einer TCP Verbindung erlaubt. Diese Situation kann zum Beispiel entstehen, wenn eines der Geräte, die an einer Verbindung teilnehmen, ein äußerst beschränktes Betrag-Gedächtnis vorbestellt (vielleicht noch kleiner hat als der gesamte entdeckte Pfad MTU), um eingehende TCP Segmente zu bearbeiten.

Auswählende Anerkennungen

Das Verlassen rein auf das kumulative durch das ursprüngliche TCP Protokoll verwendete Anerkennungsschema kann zu Wirkungslosigkeit führen, wenn Pakete verloren werden. Nehmen Sie zum Beispiel an, dass 10,000 Bytes in 10 verschiedenen TCP Paketen gesandt werden, und das erste Paket während der Übertragung verloren wird. In einem reinen kumulativen Anerkennungsprotokoll kann der Empfänger nicht sagen, dass er Bytes 1,000 bis 9,999 erfolgreich erhalten hat, aber gescheitert hat, das erste Paket zu erhalten, Bytes 0 bis 999 enthaltend. So kann der Absender dann alle 10,000 Bytes wiedersenden müssen.

Um dieses Problem zu beheben, verwendet TCP die auswählende Anerkennung (SACK) Auswahl, definiert RFC 2018, der dem Empfänger erlaubt, diskontinuierliche Blöcke von Paketen anzuerkennen, die richtig, zusätzlich zur Folge-Zahl des letzten aneinander grenzenden Bytes erhalten nacheinander, als in der grundlegenden TCP Anerkennung erhalten wurden. Die Anerkennung kann mehrere SACK-Blöcke angeben, wo jeder SACK-Block durch das Starten und Ende von Folge-Zahlen einer aneinander grenzenden Reihe befördert wird, die der Empfänger richtig erhalten hat. Im Beispiel oben würde der Empfänger SACK mit der Folge Nummern 1000 und 9999 senden. Der Absender übersendet so nur das erste Paket, Bytes 0 bis 999 wieder.

Eine Erweiterung auf die SACK-Auswahl ist die Auswahl des DOPPEL-SACKS, die in RFC 2883 definiert ist. In Unordnung kann Paket-Übergabe häufig den TCP Absender des verlorenen Pakets falsch anzeigen, und abwechselnd übersendet der TCP Absender das verdächtigte wieder, um verlorenes Paket zu sein und die Datenübergabe zu verlangsamen, um Netzverkehrsstauung zu verhindern. Der TCP Absender macht die Handlung der Verlangsamung auf, die eine Wiederherstellung des ursprünglichen Schritts der Datenübertragung, nach dem Empfang eines D-SACKS ist, der anzeigt, dass das wiederübersandte Paket doppelt ist.

Die SACK-Auswahl ist nicht obligatorisch, und sie wird nur verwendet, wenn beide Parteien sie unterstützen. Das wird verhandelt, wenn Verbindung hergestellt wird. Sacken Sie EIN verwendet den fakultativen Teil des TCP Kopfballs (sieh TCP Segment-Struktur für Details). Der Gebrauch des SACKS ist weit verbreitet — alle populären TCP-Stapel unterstützen es. Auswählende Anerkennung wird auch in Stream Control Transmission Protocol (SCTP) verwendet.

Fensterschuppen

Für den effizienteren Gebrauch von hohen Bandbreite-Netzen kann eine größere Fenster-Größe TCP verwendet werden. Das Fenster-Größe-Feld TCP kontrolliert den Datenfluss, und sein Wert wird auf zwischen 2 und 65,535 Bytes beschränkt.

Da das Größe-Feld nicht ausgebreitet werden kann, wird ein Skalenfaktor verwendet. Die Fenster-Skala-Auswahl TCP, wie definiert, RFC 1323, ist eine Auswahl, die verwendet ist, um die maximale Fenstergröße von 65,535 Bytes bis 1 Gigabyte zu vergrößern. Das Schuppen bis zu größeren Fenstergrößen ist ein Teil dessen, was für die TCP-Einstimmung notwendig ist.

Die Fensterskala-Auswahl wird nur während des TCP 3-wegigen Händedrucks verwendet. Der Fensterskala-Wert vertritt die Zahl von Bit, um das 16-Bit-Fenstergröße-Feld nach links auszuwechseln. Der Fensterskala-Wert kann von 0 (keine Verschiebung) zu 14 für jede Richtung unabhängig gesetzt werden. Beide Seiten müssen die Auswahl in ihren SYN Segmenten senden, um Fenster zu ermöglichen, das in jeder Richtung klettert.

Einige Router und Paket-Brandmauern schreiben den Fensterskalenfaktor während einer Übertragung um. Das veranlasst das Senden und Empfangen von Seiten, verschiedene Fenster-Größen TCP anzunehmen. Das Ergebnis ist nichtstabiler Verkehr, der sehr langsam sein kann. Das Problem ist auf etwas Senden und Empfang von Seiten hinter dem Pfad von fehlerhaften Routern sichtbar.

TCP Zeitstempel

TCP Zeitstempel, definiert RFC 1323, können TCP helfen zu bestimmen, in dem Ordnungspakete gesandt wurden.

TCP Zeitstempel werden zur Systemuhr und dem Anfang an einem zufälligen Wert nicht normalerweise ausgerichtet. Viele Betriebssysteme werden den Zeitstempel für jeden vergangenen milisecond erhöhen; jedoch stellt der RFC nur fest, dass die Ticks proportional sein sollten.

Es gibt zwei Zeitstempel-Felder:

ein 4-Byte-Absenderzeitstempel-Wert (mein Zeitstempel)

ein 4-Byte-Echo antwortet Zeitstempel-Wert (der neuste Zeitstempel, der von Ihnen erhalten ist).

TCP Zeitstempel werden in einem Algorithmus verwendet, der als Schutz Gegen Gewickelte Folge-Zahlen oder TATZEN bekannt ist (sieh RFC 1323 für Details). TATZEN werden verwendet, wenn die Fenster-Größe TCP die möglichen Zahlen von Folge-Zahlen (2^32 oder 4 Milliarden/Rauhmaschinen) überschreitet. Im Fall, wo ein Paket potenziell wiederübersandt wurde, antwortet es auf die Frage: "Sind diese Folge-Zahl im ersten 4 GB oder das zweite?" Und der Zeitstempel wird verwendet, um das Band zu brechen.

RFC 1323 stellt falsch im Abschnitt 2.2 fest, dass die Fensterskala auf 2^14 beschränkt werden muss, um weniger als 1 GB zu bleiben (der richtig ist, aber die Folge-Zahl-Grenze ist 4 GB); jedoch würden eine Skala 16 und eine Fenstergröße 65535 65536 weniger sein als 2^32 mögliche Folge-Zahlen und so ein annehmbarer noch übermäßiger Wert. Wegen dieses Fehlers haben viele Systeme die Max-Skala auf 2^14 beschränkt, um dem RFC "zu folgen".

Außerdem verwendet der Entdeckungsalgorithmus von Eifel (RFC 3522) TCP Zeitstempel, um zu bestimmen, ob Weitermeldungen vorkommen, weil Pakete verloren werden oder einfach in Unordnung.

Aus Band-Daten

Man ist im Stande, den Schlange gestandenen Strom zu unterbrechen oder abzubrechen, anstatt auf den Strom zu warten, um fertig zu sein. Das wird durch das Spezifizieren der Daten als dringend getan. Das sagt dem Empfang-Programm, es sofort zusammen mit dem Rest der dringenden Daten zu bearbeiten. Wenn beendet, informiert TCP die Anwendung und nimmt zurück zur Strom-Warteschlange die Tätigkeit wieder auf.

Ein Beispiel ist, wenn TCP für eine entfernte Anmeldungssitzung verwendet wird, kann der Benutzer eine Tastatur-Folge senden, die unterbricht oder das Programm am anderen Ende abbricht. Diese Signale sind meistenteils erforderlich, wenn ein Programm auf der entfernten Maschine scheitert, richtig zu funktionieren. Ohne die Signale muss gesandt werden, auf das Programm zu warten, um seine aktuelle Übertragung zu beenden.

TCP OOB Daten wurde für das moderne Internet nicht entworfen. Der dringende Zeigestock verändert nur die Verarbeitung auf dem entfernten Gastgeber und beschleunigt keine Verarbeitung im Netz selbst. Wenn es dem entfernten Gastgeber kommt, gibt es zwei ein bisschen verschiedene Interpretationen des Protokolls, was bedeutet, dass nur einzelne Bytes von OOB Daten zuverlässig sind. Das nimmt an, dass es überhaupt zuverlässig ist, weil es eines der am wenigsten allgemein verwendeten Protokoll-Elemente ist und dazu neigt, schlecht durchgeführt zu werden.

Das Zwingen der Datenübergabe

Normalerweise wartet TCP seit 200 Millisekunden, oder für ein volles Paket von Daten, um zu senden (versucht der Algorithmus von Nagle =, kleine Nachrichten in ein einzelnes Paket zu gruppieren). Das schafft geringe aber potenziell ernste Verzögerungen, wenn wiederholt, ständig während einer Dateiübertragung. Zum Beispiel sendet ein typischer Block würde 4 Kilobytes, sein typische FRAUEN sind 1460, so gehen 2 Pakete auf einem 10Mbit/s ethernet Einnahme von ~1.2 Millisekunden jeder aus, der von einem Drittel gefolgt ist, das restlichen 1176 nach einer Pause der 197 Millisekunde trägt, weil TCP auf einen vollen Puffer wartet.

Im Fall von telnet wird jeder Benutzeranschlag zurück durch den Server zurückgeworfen, bevor der Benutzer es auf dem Schirm sehen kann. Diese Verzögerung würde sehr ärgerlich werden.

Das Setzen der Steckdose-Auswahl überreitet den Verzug, den 200 Millisekunden Verzögerung senden. Anwendungsprogramme verwenden diese Steckdose-Auswahl, Produktion zu zwingen, nach dem Schreiben eines Charakters oder Linie von Charakteren gesandt zu werden.

Der RFC definiert das Stoß-Bit als "eine Nachricht an den Empfang TCP Stapel, um dem Daten sofort bis zur Empfang-Anwendung zu senden". Es gibt keine Weise, es im Benutzerraum verwendende Steckdosen von Berkeley anzuzeigen oder zu kontrollieren, und es wird vom Protokoll-Stapel nur kontrolliert.

Verwundbarkeit

TCP kann in einer Vielfalt von Wegen angegriffen werden. Die Ergebnisse einer gründlichen Sicherheitsbewertung von TCP, zusammen mit möglichen Milderungen für die identifizierten Probleme, wurden 2009 veröffentlicht, und werden zurzeit innerhalb des IETF verfolgt.

Leugnung des Dienstes

Durch das Verwenden eines spoofed IP Adresse und wiederholt das Senden hat vorsätzlich SYN Pakete gesammelt, Angreifer können den Server veranlassen, große Beträge von der gefälschten Verbindungen nachgehenden Mitteln zu verbrauchen. Das ist als ein SYN-Überschwemmungsangriff bekannt. Vorgeschlagene Lösungen dieses Problems schließen SYN Plätzchen und Kryptografische Rätsel ein. Sockstress ist ein ähnlicher Angriff, der mit dem Systemquellenmanagement gelindert werden könnte. Ein fortgeschrittener Angriff von DoS, der mit der Ausnutzung des TCP verbunden ist, dauert An Zeitmesser wurde an Phrack #66. analysiert

Verbindungsentführung

Ein Angreifer, der im Stande ist, eine TCP Sitzung zu lauschen und Pakete umzuadressieren, kann eine TCP Verbindung entführen. Um so zu tun, erfährt der Angreifer die Folge-Zahl aus der andauernden Kommunikation und schmiedet ein falsches Segment, das wie das folgende Segment im Strom aussieht. Solch eine einfache Entführung kann auf ein Paket hinauslaufen, das an einem Ende falsch wird akzeptiert. Wenn der Empfang-Gastgeber das Extrasegment auf die andere Seite der Verbindung anerkennt, wird Synchronisation verloren. Entführung könnte mit ARP oder Routenplanungsangriffen verbunden werden, die erlauben, Kontrolle des Paket-Flusses zu nehmen, um dauerhafte Kontrolle der entführten TCP Verbindung zu bekommen.

Das Personifizieren einer verschiedenen IP-Adresse war vor RFC 1948 nicht schwierig, als die anfängliche Folge-Zahl leicht erratbar war. Das hat einem Angreifer erlaubt, eine Folge von Paketen blind zu senden, die der Empfänger glauben würde, um aus einer verschiedenen IP-Adresse ohne das Bedürfnis zu kommen, ARP oder Routenplanungsangriffe einzusetzen: Es ist genug sicherzustellen, dass der legitime Gastgeber der personifizierten IP-Adresse unten ist, oder bringen Sie es zu dieser Bedingung mit der Leugnung von Dienstangriffen. Das ist, warum die anfängliche Folge-Zahl aufs Geratewohl gewählt wird.

TCP Häfen

TCP verwendet Hafen-Zahlen, um das Senden und den Empfang von Anwendungsendpunkten auf einem Gastgeber oder Internetsteckdosen zu identifizieren. Jede Seite einer TCP Verbindung hat einen verbundenen nicht unterzeichneten 16-Bit-Hafen Nummer (0-65535), die durch das Senden oder den Empfang der Anwendung vorbestellt ist. Wenn man ankommt, werden TCP Datenpakete als das Gehören einer spezifischen TCP Verbindung durch seine Steckdosen, d. h. die Kombination von Quellgastgeber-Adresse, Quellhafen, Bestimmungsort-Gastgeber-Adresse und Bestimmungsort-Hafen identifiziert. Das bedeutet, dass ein Server-Computer mehrere Kunden mit mehreren Dienstleistungen gleichzeitig versorgen kann, so lange ein Kunde darauf aufpasst, irgendwelche gleichzeitigen Verbindungen zu einem Bestimmungsort-Hafen von verschiedenen Quellhäfen zu beginnen.

Hafen-Zahlen werden in drei grundlegende Kategorien kategorisiert: wohl bekannt, eingeschrieben und dynamisch/privat. Die wohl bekannten Häfen werden von Internet Assigned Numbers Authority (IANA) zugeteilt und werden normalerweise durch die Systemebene oder Wurzelprozesse verwendet. Wohl bekannte Anwendungen, die als Server laufen und passiv auf Verbindungen normalerweise horchen, verwenden diese Häfen. Einige Beispiele schließen ein: FTP (20 und 21), SSH (22), TELNET (23), SMTP (25) und HTTP (80). Eingetragene Häfen werden normalerweise durch Endbenutzer-Anwendungen als ephemere Quellhäfen verwendet, wenn man sich mit Servern in Verbindung setzt, aber sie können auch genannte Dienstleistungen identifizieren, die von einem Dritten eingeschrieben worden sind. Dynamische/private Häfen können auch durch Endbenutzer-Anwendungen verwendet werden, aber sind weniger allgemein so. Dynamische/private Häfen enthalten keine Bedeutung außerhalb jeder besonderen TCP Verbindung.

Entwicklung

TCP ist ein kompliziertes Protokoll. Jedoch, während bedeutende Erhöhungen gemacht und im Laufe der Jahre vorgeschlagen worden sind, hat sich seine grundlegendste Operation bedeutsam seit seiner ersten Spezifizierung RFC 675 1974 und der v4 Spezifizierung RFC 793 nicht geändert, im September 1981 veröffentlicht. RFC 1122, Gastgeber-Voraussetzungen für Internetgastgeber, hat mehrere TCP Protokoll-Durchführungsvoraussetzungen geklärt. RFC 2581, TCP Verkehrsstauungskontrolle, einer der wichtigsten TCP-zusammenhängenden RFCs in den letzten Jahren, beschreibt aktualisierte Algorithmen, die übermäßige Verkehrsstauung vermeiden. 2001 wurde RFC 3168 geschrieben, um ausführliche Verkehrsstauungsankündigung (ECN), eine Verkehrsstauungsaufhebung Signalmechanismus zu beschreiben.

Der ursprüngliche TCP Verkehrsstauungsaufhebungsalgorithmus war als "TCP Tahoe" bekannt, aber viele alternative Algorithmen sind (einschließlich TCP Renos, TCP Vegas, SCHNELLEN TCP, TCP Neuer Reno und TCP Hybla) seitdem vorgeschlagen worden.

TCP Interaktiv (iTCP) ist eine Forschungsanstrengung in TCP Erweiterungen, die Anwendungen erlaubt, TCP Ereignisse zu unterschreiben und Dressierer-Bestandteile einzuschreiben, die Anwendungen zu verschiedenen Zwecken einschließlich der geAnwendungsholfenen Verkehrsstauungskontrolle starten können.

Mehrpfad TCP (MPTCP) ist eine andauernde Anstrengung innerhalb des IETF, der darauf zielt, einer TCP Verbindung zu erlauben, vielfache Pfade zu verwenden, um Quellengebrauch und Zunahme-Überfülle zu maximieren.

Die Überfülle, die durch den Mehrpfad angeboten ist, den TCP im Zusammenhang von Radionetzen ermöglicht von Mitteln statistisch gleichzeitig zu senden, und so TCP Durchfluss drastisch vergrößert. Mehrpfad TCP bringt auch Leistungsvorteile in datacenter Umgebungen. Die Bezugsdurchführung des Mehrpfads TCP wird im Kern von Linux entwickelt

TCP Plätzchen-Transaktionen (TCPCT) sind eine Erweiterung vorgeschlagen im Dezember 2009, um Server gegen Angriffe der Leugnung des Dienstes zu sichern. Verschieden von SYN Plätzchen kollidiert TCPCT andere TCP Erweiterungen wie Fensterschuppen nicht. TCPCT wurde wegen Notwendigkeiten von DNSSEC entworfen, wo Server große Anzahl von kurzlebigen TCP Verbindungen behandeln müssen.

tcpcrypt ist eine Erweiterung vorgeschlagen im Juli 2010, um Transportniveau-Verschlüsselung direkt in TCP selbst zur Verfügung zu stellen. Es wird entworfen, um durchsichtig zu arbeiten und jede Konfiguration nicht zu verlangen. Verschieden von TLS (SSL), tcpcrypt selbst stellt Beglaubigung nicht zur Verfügung, aber stellt einfache Primitive unten der Anwendung zur Verfügung, um das zu tun., der erste tcpcrypt IETF Entwurf ist veröffentlicht worden, und Durchführungen bestehen für mehrere Hauptplattformen.

TCP über Radionetze

TCP ist für verdrahtete Netze optimiert worden. Wie man betrachtet, ist jeder Paket-Verlust das Ergebnis der Netzverkehrsstauung, und die Stausfenster-Größe wird drastisch vorsichtshalber reduziert. Jedoch, wie man bekannt, erfahren Radioverbindungen sporadische und gewöhnlich vorläufige Verluste wegen des Verblassens, der Beschattung, der Hand von, und andere Radioeffekten, die als Verkehrsstauung nicht betrachtet werden können. Nach (falsch) ziehen sich der Stausfenster-Größe wegen des Radiopaket-Verlustes zurück, es kann eine Verkehrsstauungsaufhebungsphase mit einer konservativen Abnahme in der Fenstergröße geben. Das veranlasst die Radioverbindung, zu gering genutzt zu sein. Umfassende Forschung ist auf dem Thema dessen getan worden, wie man diese schädlichen Effekten bekämpft. Angedeutete Lösungen können als der Länge nach Lösungen kategorisiert werden (die Modifizierungen am Kunden oder Server verlangen), Verbindungsschicht-Lösungen (wie RLP in Zellnetzen), oder Vertretung Lösungen gestützt hat (die einige Änderungen im Netz verlangen, ohne Endknoten zu modifizieren).

Hardware-Durchführungen

Eine Weise, die in einer Prozession gehenden Macht-Voraussetzungen von TCP zu überwinden, soll Hardware-Durchführungen davon, weit bekannt als TCP Offload Engines (TOE) bauen. Das Hauptproblem von ZEHEN besteht darin, dass sie hart sind, in Rechensysteme zu integrieren, umfassende Änderungen im Betriebssystem des Computers oder Geräts verlangend. Eine Gesellschaft, um solch ein Gerät zu entwickeln, war Alacritech.

Das Beseitigen

Ein Paket sniffer, der TCP Verkehr auf einer Netzverbindung abfängt, kann im Beseitigen bei Netzen, Netzstapeln und Anwendungen nützlich sein, die TCP durch die Vertretung dem Benutzer verwenden, welche Pakete eine Verbindung durchführen. Einige Netzwerkanschlussstapel unterstützen die SO_DEBUG Steckdose-Auswahl, die auf der Steckdose mit setsockopt ermöglicht werden kann. Diese Auswahl lädt alle Pakete ab, TCP, setzt und Ereignisse auf dieser Steckdose fest, die im Beseitigen nützlich ist. Netstat ist ein anderes Dienstprogramm, das für das Beseitigen verwendet werden kann.

Alternativen

Für viele Anwendungen ist TCP nicht passend. Ein großes Problem (mindestens mit normalen Durchführungen) besteht darin, dass die Anwendung an den Paketen nicht kommen kann, die nach einem verlorenen Paket kommen, bis die wiederübersandte Kopie des verlorenen Pakets erhalten wird. Das verursacht Probleme für Echtzeitanwendungen wie strömende Medien, Echtzeitmehrfachabspiellaufwerk-Spiele und Begleitkommentar IP (VoIP), wo es allgemein nützlicher ist, die meisten Daten auf eine rechtzeitige Mode zu bekommen, als es alle Daten in Ordnung bringen soll.

Sowohl aus historischen Gründen als auch aus Leistungsgründen ziehen die meisten Speicherbereich-Netze (OHNE) es vor, Faser-Kanalprotokoll (FCP) statt TCP/IP zu verwenden.

Auch für eingebettete Systeme, das Netzstarten und die Server, die einfachen Bitten von riesigen Zahlen von Kunden dienen (z.B. DNS Server) die Kompliziertheit von TCP kann ein Problem sein. Schließlich sind einige Tricks wie das Übertragen von Daten zwischen zwei Gastgebern, die beide hinter NAT sind (das Verwenden BETÄUBEN oder ähnliche Systeme), ohne ein relativ kompliziertes Protokoll wie TCP im Weg viel einfacher.

Allgemein, wo TCP unpassend ist, wird User Datagram Protocol (UDP) verwendet. Das stellt die Anwendung gleichzeitig sendend und Kontrollsummen zur Verfügung, die TCP tut, aber Bauen-Ströme oder Weitermeldung behandelt, dem Anwendungsentwickler die Fähigkeit gebend, sie in einem Weg zu codieren, der für die Situation passend ist, oder sie durch andere Methoden wie Vorwärtsfehlerkorrektur oder Interpolation zu ersetzen.

SCTP ist ein anderes IP Protokoll, das orientierte TCP ähnliche Dienstleistungen des zuverlässigen Stroms zur Verfügung stellt. Es ist neuer und beträchtlich komplizierter als TCP, und hat weit verbreitete Aufstellung noch nicht gesehen. Jedoch wird es besonders entworfen, um in Situationen verwendet zu werden, wo Zuverlässigkeit und Nah-Echtzeitrücksichten wichtig sind.

Venturi Transport Protocol (VTP) ist ein patentiertes Eigentumsprotokoll, das entworfen wird, um TCP durchsichtig zu ersetzen, um wahrgenommene mit dem Radiodatentransport verbundene Wirkungslosigkeit zu überwinden.

TCP hat auch Probleme in hohen Bandbreite-Umgebungen. Der TCP Verkehrsstauungsaufhebungsalgorithmus arbeitet sehr gut für ad hoc Umgebungen, wo der Datenabsender im Voraus nicht bekannt ist, aber wenn die Umgebung voraussagbar ist, kann gestütztes Protokoll eines Timings wie Asynchronous Transfer Mode (ATM) vermeiden, dass TCP'S oben wiederübersendet.

Mehrzwecktransaktionsprotokoll (MTP/IP) wird Eigentumssoftware patentiert, die entworfen wird, um hohen Durchfluss und Transaktionsleistung in einem großen Angebot an Netzbedingungen, besonders diejenigen anpassungsfähig zu erreichen, wo, wie man wahrnimmt, TCP ineffizient ist.

Kontrollsumme-Berechnung

TCP Kontrollsumme für IPv4

Wenn TCP IPv4 durchgeht, wird die Methode, die verwendet ist, um die Kontrollsumme zu schätzen, in RFC 793 definiert:

Das Kontrollsumme-Feld ist die 16 Bit jemandes Ergänzung von jemandes Ergänzungssumme aller 16-Bit-Wörter im Kopfball und Text. Wenn ein Segment eine ungerade Zahl des Kopfballs und der Textoktette enthält, um checksummed zu sein, wird das letzte Oktett rechts mit Nullen ausgepolstert, um ein 16-Bit-Wort zu Kontrollsumme-Zwecken zu bilden. Das Polster wird als ein Teil des Segmentes nicht übersandt. Während man die Kontrollsumme schätzt, wird das Kontrollsumme-Feld selbst durch Nullen ersetzt.

Mit anderen Worten, nach dem passenden Polstern, werden alle 16-Bit-Wörter mit jemandes Ergänzungsarithmetik hinzugefügt. Die Summe ist dann bitwise ergänzt und eingefügt als das Kontrollsumme-Feld. Ein Pseudokopfball, der den IPv4 in der Kontrollsumme-Berechnung verwendeten Paket-Kopfball nachahmt, wird im Tisch unten gezeigt.

Die Quelle und Bestimmungsort-Adressen sind diejenigen des IPv4 Kopfballs. Der Protokoll-Wert ist 6 für TCP (vgl Liste von IP Protokoll-Zahlen). Das TCP Länge-Feld ist die Länge des TCP Kopfballs und der Daten.

TCP Kontrollsumme für IPv6

Wenn TCP IPv6 durchgeht, wird die Methode, die verwendet ist, um die Kontrollsumme zu schätzen, laut RFC 2460 geändert:

:Any-Transport oder anderes Protokoll der oberen Schicht, das die Adressen vom IP Kopfball in seiner Kontrollsumme-Berechnung einschließt, müssen für den Gebrauch über IPv6 modifiziert werden, um die IPv6 128-Bit-Adressen statt IPv4 32-Bit-Adressen einzuschließen.

Ein Pseudokopfball, der den IPv6 Kopfball für die Berechnung der Kontrollsumme nachahmt, wird unten gezeigt.

• Quelladresse - diejenige im IPv6 Kopfball
• Bestimmungsort-Adresse - der endgültige Bestimmungsort; wenn das IPv6 Paket keinen Routenplanungskopfball enthält, verwendet TCP die Bestimmungsort-Adresse im IPv6 Kopfball sonst am entstehenden Knoten, es verwendet die Adresse im letzten Element des Routenplanungskopfballs, und am Empfang-Knoten, es verwendet die Bestimmungsort-Adresse im IPv6 Kopfball.
• TCP Länge - die Länge des TCP Kopfballs und der Daten
• Folgender Kopfball - der Protokoll-Wert für TCP

Kontrollsumme lädt ab

Viele TCP/IP Softwarestapel-Durchführungen stellen Optionen zur Verfügung, Hardware-Hilfe zu verwenden, um die Kontrollsumme im Netzadapter vor der Übertragung auf das Netz oder auf den Empfang vom Netz für die Gültigkeitserklärung automatisch zu schätzen. Das kann OS erleichtern, um wertvolle Zentraleinheitszyklen zu verwenden, die Kontrollsumme berechnen. Folglich wird gesamte Netzleistung vergrößert.

Diese Eigenschaft kann Paket verursachen, das Analysatoren, die Ausgangsnetzverkehr stromaufwärts des Netzadapters und unbewusst oder unsicher über den Gebrauch der Kontrollsumme entdecken, abladen, um ungültige Kontrollsumme in Ausgangspaketen zu melden.

Siehe auch

• Verbindungsfreies Netzprotokoll
• T/TCP Variante von TCP
• TCP und UDP Hafen
• TCP und UDP Hafen-Zahlen für eine lange Liste von Häfen/Dienstleistungen
• TCP Verkehrsstauungsaufhebungsalgorithmen
• Der Algorithmus von Nagle
• Der Algorithmus von Karn
• Maximale Übertragungseinheit
• IP Zersplitterung
• Maximale Segment-Größe
• Dummes Fenstersyndrom
• TCP Segment
• TCP Folge-Vorhersageangriff
• SYN überschwemmen
• SYN Plätzchen
• TCP, der für hohe Leistungsnetze Stimmt
• Pfad MTU Entdeckung
• tcphdr - der Unix TCP Kopfball-Struktur auf der C Programmiersprache
• Stream Control Transmission Protocol (SCTP)
• Mehrzwecktransaktionsprotokoll (MTP/IP)
• Transportprotokoll-Vergleich-Tisch
• Sockstress

Weiterführende Literatur

• W. Richard Stevens. TCP/IP Illustriert, Band 1: Die Protokolle. Internationale Standardbuchnummer 0-201-63346-9
• W. Richard Stevens und Gary R. Wright. TCP/IP Illustriert, Band 2: Die Durchführung. Internationale Standardbuchnummer 0 201 63354 X
• W. Richard Stevens. TCP/IP Illustriert, Band 3: TCP für Transaktionen, HTTP, NNTP und die UNIX Bereichsprotokolle. Internationale Standardbuchnummer 0-201-63495-3

Links

RFC

• RFC 675 - Spezifizierung des Internetübertragungskontrollprogramms, Version im Dezember 1974
• RFC 793 - TCP v4
• RFC 1122 - schließt einige Fehlerkorrekturen für TCP ein
• RFC 1323 - TCP-Erweiterungen
• RFC 1379 - TCP für Transaktionen — Konzepte Erweiternd
• RFC 1948 - Gegen Folge-Zahl-Angriffe Verteidigend
• RFC 2018 - TCP Auswählende Anerkennungsoptionen
• RFC 4614 - Ein Fahrplan für TCP Spezifizierungsdokumente
• RFC 5681 - TCP Verkehrsstauungskontrolle
• RFC 6298 - Computerwissenschaft des Weitermeldungszeitmessers von TCP

Andere

• Mündliches Geschichtsinterview mit Robert E. Kahn, Institut von Charles Babbage, Universität Minnesotas, Minneapolis. Konzentriert sich auf die Rolle von Kahn in der Entwicklung des Computers, der von 1967 bis zum Anfang der 1980er Jahre vernetzt. Mit seiner Arbeit an Bolt Beranek und Newman (BBN) beginnend, bespricht Kahn seine Beteiligung, weil der ARPANET Vorschlag, seine Entscheidung geschrieben wurde, aktiv in seiner Durchführung und seiner Rolle in der öffentlichen Demonstration des ARPANET zu werden. Das Interview geht in die Beteiligung von Kahn mit dem Netzwerkanschluss weiter, wenn er sich zu IPTO 1972 bewegt, wo er für die administrative und technische Evolution des ARPANET, einschließlich Programme im Paket-Radio, der Entwicklung eines neuen Netzprotokolls (TCP/IP) und dem Schalter zu TCP/IP verantwortlich war, um vielfache Netze zu verbinden.
• IANA Hafen-Anweisungen
• Die Übersicht von John Kristoff von TCP (Grundsätzliche Konzepte hinter TCP, und wie es verwendet wird, um Daten zwischen zwei Endpunkten zu transportieren)
• TCP übersenden schnell belebte Simulation wieder: Verlangsamen Sie Anfang, Fenster gleiten lassend, hat Ack, Stausfenster kopiert
• TCP, Übertragungskontrollprotokoll
• Kontrollsumme-Beispiel
• Die Seite des Ingenieurs Francesco Buffa über das Übertragungskontrollprotokoll
• TCP Tutorenkurs
• Linktionary auf TCP Segmenten
• TCP Gleitende Fenstersimulation hat (ns2) belebt
• Mehrpfad TCP im Kern von Linux