Transmissionskontrollprotokoll

Transmissionskontrollprotokoll
Kommunikationsprotokoll
Entwickler (en) Vint Cerf und Bob Kahn
Einführung 1974
Bezogen auf Übertragungskontrollprogramm
RFC (s) RFC 793

Das Transmissionskontrollprotokoll (TCP) ist einer der wichtigsten Protokolle des Internet -Protokollsuite. Es stammt aus der anfänglichen Netzwerkimplementierung, in der es die ergänzt hat Internetprotokoll (IP). Daher wird die gesamte Suite allgemein als als bezeichnet TCP/IP. TCP bietet zuverlässig, bestellt und Fehlerprüflich Lieferung eines Stroms von Oktetten (Bytes) zwischen Anwendungen, die auf Hosts ausgeführt werden, die über ein IP -Netzwerk kommunizieren. Wichtige Internetanwendungen wie die Weltweites Netz, Email, Fernverwaltung, und Datei Übertragung verlassen sich auf TCP, was Teil der ist Transportschicht der TCP/IP -Suite. SSL/TLS Läuft oft über TCP.

TCP ist Verbindungs ​​orientiertund eine Verbindung zwischen Client und Server wird hergestellt, bevor Daten gesendet werden können. Der Server muss zuhören (passiv offen) für Verbindungsanforderungen von Clients, bevor eine Verbindung hergestellt wird. Drei-Wege-Handshake (aktiv offen), Übertragung, und die Fehlererkennung erhöht die Zuverlässigkeit, verlängert sich jedoch, aber verlängert sich Latenz. Anwendungen, die nicht zuverlässig erfordern Datenstrom Service kann die nutzen User Datagram Protocol (UDP), der a liefert verbindungslos Datagramm Service, der Zeit vor der Zuverlässigkeit priorisiert. TCP beschäftigt Vermeidung von Netzwerkstaus. Es gibt jedoch Schwachstellen gegenüber TCP, einschließlich Denial of Service, Verbindungsentführung, TCP Veto und Angriff zurücksetzen.

Historischer Herkunft

Im Mai 1974, Vint Cerf und Bob Kahn beschrieben an Internetbearbeitung Protokoll für das Teilen von Ressourcen mit Verwendung Paketschaltung unter Netzwerkknoten.[1] Die Autoren hatten mit gearbeitet Gérard Le Lann Konzepte aus dem Franzosen einzubeziehen Zykladen Projekt in das neue Netzwerk.[2] Die Spezifikation des resultierenden Protokolls, RFC 675 (Spezifikation des Internetübertragungskontrollprogramms), wurde von Vint Cerf geschrieben, Yogen Dalalund Carl Sunshine und veröffentlicht im Dezember 1974. Es enthält die erste beglaubigte Verwendung des Semesters Internetals Abkürzung für Internetarbeit.[3]

Eine zentrale Kontrollkomponente dieses Modells war die Übertragungskontrollprogramm Dies umfasste sowohl verbindungsorientierte Links als auch Datagrammdienste zwischen Hosts. Das monolithische Übertragungskontrollprogramm wurde später in eine modulare Architektur unterteilt, die aus dem bestand Transmissionskontrollprotokoll und die Internetprotokoll. Dies führte zu einem Netzwerkmodell, das informell bekannt wurde TCP/IPobwohl es formell als DOD -Modell des Verteidigungsministeriums (DOD) bezeichnet wurde, und Arpanet Modell und schließlich auch als die Internet -Protokollsuite.

In 2004, Vint Cerf und Bob Kahn erhielt die Turing Award für ihre grundlegenden Arbeiten an TCP/IP.[4][5]

Netzwerkfunktion

Das Transmission Control Protocol bietet einen Kommunikationsdienst auf einer Zwischenebene zwischen einem Anwendungsprogramm und dem Internet -Protokoll. Es bietet Host-to-Host-Konnektivität am Transportschicht des Internetmodell. Eine Anwendung muss nicht die besonderen Mechanismen zum Senden von Daten über einen Link zu einem anderen Host kennen, wie z. B. die erforderlichen IP -Fragmentierung um die zu unterbringen Maximale Übertragungseinheit des Übertragungsmediums. In der Transportschicht verarbeitet TCP alle Handshaking- und Getriebedetails und präsentiert eine Abstraktion der Netzwerkverbindung zur Anwendung typischerweise über a Netzwerkbuchse Schnittstelle.

In den niedrigeren Ebenen des Protokollstapels aufgrund von Netzüberlastung, Verkehr Lastverteilungoder unvorhersehbares Netzwerkverhalten, IP -Pakete können es sein verirrt, dupliziert, oder außerhalb der Reihenfolge geliefert. TCP erkennt diese Probleme, Anfragen Wiedervermittlung Von verlorenen Daten ordnen Sie Daten außerordentlich um und helfen sogar, die Netzwerküberlastung zu minimieren, um das Auftreten der anderen Probleme zu verringern. Wenn die Daten noch nicht zugegeben bleiben, wird die Quelle über diesen Fehler informiert. Sobald der TCP -Empfänger die ursprünglich übertragene Abfolge von Oktetten wieder zusammengestellt hat, übergibt er sie an die Empfangsanwendung. Somit ist TCP Abstracts Die Kommunikation der Anwendung aus den zugrunde liegenden Netzwerkdetails.

TCP wird ausgiebig von vielen Internetanwendungen verwendet, einschließlich der Weltweites Netz (Www), Email, Dateitransferprotokoll, Sichere Schale, Peer-to-Peer-Dateifreigabe, und Streaming Medien.

TCP wird eher für eine genaue Lieferung als für die rechtzeitige Lieferung optimiert und kann relativ lange Verzögerungen (nach Reihenfolge von Sekunden) verursachen, während Sie auf außerordentliche Nachrichten oder Wiederauflagen verlorener Nachrichten warten. Daher ist es für Echtzeitanwendungen wie z. B. nicht besonders geeignet Voice over IP. Für solche Anwendungen mögen Protokolle wie die Echtzeit-Transportprotokoll (RTP) über die operieren User Datagram Protocol (UDP) werden normalerweise stattdessen empfohlen.[6]

TCP ist ein zuverlässiger Stream -Lieferservice, der garantiert, dass alle erhaltenen Bytes identisch und in der gleichen Reihenfolge wie die gesendeten sind. Da die Paketübertragung durch viele Netzwerke nicht zuverlässig ist, erreicht TCP dies mit einer Technik, die als bekannt ist positive Anerkennung mit Re-Übertragung. Dies erfordert, dass der Empfänger mit einer Bestätigungsnachricht antwortet, da er die Daten empfängt. Der Absender behält eine Aufzeichnung jedes Pakets, das er sendet, und verwaltet einen Timer aus dem Senden des Pakets. Der Absender überträgt ein Paket erneut, wenn der Timer vor dem Erhalt der Bestätigung abläuft. Der Timer wird benötigt, falls ein Paket verloren geht oder beschädigt wird.[6]

Während IP die tatsächliche Lieferung der Daten verarbeitet, verfolgt TCP die Segmente - Die einzelnen Einheiten der Datenübertragung, in die eine Nachricht für ein effizientes Routing durch das Netzwerk unterteilt ist. Wenn beispielsweise eine HTML -Datei von einem Webserver gesendet wird, unterteilt die TCP -Softwareschicht dieses Servers die Datei in Segmente und leitet sie einzeln an die Internetschicht in dem Netzwerkstapel. Die Internet -Layer -Software verkauft jedes TCP IP Adresse. Wenn das Client-Programm auf dem Zielcomputer sie empfängt, assiert die TCP-Software in der Transportschicht die Segmente neu und stellt sicher, dass sie korrekt geordnet und fehlerfrei sind, wenn der Dateiinhalt in die Empfangsanwendung gestreamt wird.

TCP -Segmentstruktur

Das Transmission Control Protocol akzeptiert Daten aus einem Datenstrom, unterteilt es in Stücke und fügt einen TCP -Header hinzu, der ein TCP -Segment erstellt. Das TCP -Segment ist dann eingekapselt in ein Internet -Protokoll -Datagramm (IP) und mit Kollegen ausgetauscht.[7]

Der Begriff TCP -Paket erscheint sowohl in informeller als auch in formeller Verwendung, während in genauerer Terminologie Segment bezieht sich auf die TCP Protokolldateneinheit (PDU), Datagramm[8] zur IP -PDU und rahmen zum Datenübertragungsebene PDU:

Prozesse übertragen Daten, indem sie die TCP aufrufen und Datenpuffer als Argumente übergeben. Die TCP packt die Daten aus diesen Puffern in Segmente und ruft im Internetmodul auf [z. IP] jedes Segment an das Ziel TCP übertragen.[9]

Ein TCP -Segment besteht aus einem Segment Header und ein Daten Sektion. Der Segmentkopf enthält 10 obligatorische Felder und ein optionales Erweiterungsfeld (Optionen, rosa Hintergrund in der Tabelle). Der Datenabschnitt folgt dem Header und ist die Nutzlastdaten für die Anwendung. Die Länge des Datenabschnitts ist im Segmentheader nicht angegeben. Es kann berechnet werden, indem die kombinierte Länge des Segmentheaders und der IP -Header von der im IP -Header angegebenen Gesamt -IP -Datagrammlänge subtrahiert werden.

TCP -Segmentheader
Offsets Oktett 0 1 2 3
Oktett Bisschen 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
0 0 Quellport Zielhafen
4 32 Sequenznummer
8 64 Bestätigungsnummer (wenn ACK -Set)
12 96 Datenversatz Reserviert
0 0 0
Ns
CWR
ECE
Urg
Ack
PSH
RST
Syn
FLOSSE
Fenstergröße
16 128 Überprüfung Dringender Zeiger (wenn Urg -Set)
20
160
Optionen (if Datenversatz > 5. am Ende mit "0" -Bits gepolstert, falls erforderlich.)
60 480
Quellport (16 Bit)
Identifiziert den Sendungsport.
Zielport (16 Bit)
Identifiziert den empfangenden Port.
Sequenznummer (32 Bit)
Hat eine doppelte Rolle:
  • Wenn das Syn -Flag (1) eingestellt ist, ist dies die anfängliche Sequenznummer. Die Sequenznummer des tatsächlichen ersten Datenbyte und die bestätigte Zahl in der entsprechenden ACK sind dann diese Sequenznummer plus 1.
  • Wenn das Syn -Flag klar ist (0), ist dies die akkumulierte Sequenznummer des ersten Datenbytes dieses Segments für die aktuelle Sitzung.
Bestätigungsnummer (32 Bit)
Wenn das ACK -Flag eingestellt ist, ist der Wert dieses Feldes die nächste Sequenznummer, die der Absender des ACK erwartet. Dies bestätigt den Erhalt aller vorherigen Bytes (falls vorhanden). Der erste von jedem Ende gesendete ACK erkennt die anfängliche Sequenznummer des anderen Endes selbst an, jedoch keine Daten.
Datenversatz (4 Bit)
Gibt die Größe des TCP-Headers in 32-Bit an Wörter. Der Header der Mindestgröße beträgt 5 Wörter und das Maximum beträgt 15 Wörter, wodurch die minimale Größe von 20 Bytes und maximal 60 Bytes angezeigt wird, was bis zu 40 Bytes Optionen im Kopfzeile ermöglicht. Dieses Feld hat seinen Namen von der Tatsache, dass es auch der Versatz von Beginn des TCP -Segments bis zu den tatsächlichen Daten ist.
Reserviert (3 Bit)
Für zukünftige Verwendung und sollte auf Null gesetzt werden.
Flaggen (9 Bit)
Enthält 9 1-Bit-Flags (Kontrollbits) wie folgt:
  • NS (1 Bit): ECN -Nonce - Verschleierung Schutz[a]
  • CWR (1 Bit): Das Flag (Verstärkungsfenster reduziert) wird vom sendenden Host festgelegt, um anzuzeigen, dass es ein TCP -Segment mit dem ECE -Flag -Set erhalten hat und im Stauungskontrollmechanismus reagiert hatte.[b]
  • ECE (1 Bit): ECN-Echo spielt eine doppelte Rolle, abhängig vom Wert der Syn-Flagge. Es weist darauf hin:
  • Wenn das Syn -Flag eingestellt ist (1), ist der TCP -Peer ECN fähig.
  • Wenn das SYN -Flag klar ist (0), wurde ein Paket mit Überlastung des Flaggensatzes (ECN = 11) im IP -Header beim normalen Getriebe empfangen.[b] Dies dient als Hinweis auf die Netzwerküberlastung (oder eine bevorstehende Überlastung) für den TCP -Absender.
  • URG (1 Bit): Zeigt an, dass das dringende Zeigerfeld signifikant ist
  • ACK (1 Bit): Zeigt an, dass das Bestätigungsfeld von Bedeutung ist. Alle Pakete nach dem ersten vom Client gesendeten Syn -Paket sollten dieses Flag -Set haben.
  • PSH (1 Bit): Push -Funktion. Bitten Sie, die gepufferten Daten in die Empfangsanwendung zu bringen.
  • RST (1 Bit): Setzen Sie die Verbindung zurück
  • Syn (1 Bit): Sequenznummern synchronisieren. Nur das erste von jedem Ende gesendete Paket sollte dieses Flag einstellen. Einige andere Flaggen und Felder ändern die Bedeutung basierend auf dieser Flagge, und andere sind nur dann gültig, wenn sie festgelegt sind, und andere, wenn es klar ist.
  • Fin (1 Bit): Letztes Paket vom Absender
Fenstergröße (16 Bit)
Die grosse von Fenster erhalten, was die Anzahl der Fenstergrößeneinheiten angibt[c] dass der Absender dieses Segments derzeit bereit ist zu erhalten.[d] (Sehen § Ablaufsteuerung und § Fensterskalierung.))
Prüfsumme (16 Bit)
Der 16-Bit Überprüfung Das Feld wird zur Fehlerprüfung des TCP-Headers, der Nutzlast und eines IP-Pseudoaders verwendet. Der Pseudoadler besteht aus dem Ursprungs IP-Addresse, das Ziel-IP-Adresse, das Protokollnummer Für das TCP -Protokoll (6) und die Länge der TCP -Headers und die Nutzlast (in Bytes).
Dringender Zeiger (16 Bit)
Wenn das URG-Flag festgelegt ist, ist dieses 16-Bit-Feld ein Versatz aus der Sequenznummer, die das letzte dringende Datenbyte angibt.
Optionen (Variable 0–320 Bit, in Einheiten von 32 Bit)
Die Länge dieses Feldes wird durch die bestimmt Datenversatz aufstellen. Die Optionen haben bis zu drei Felder: Option-Sink (1 Byte), Optionslänge (1 Byte), Option-Data (Variable). Das Feld "Option-Sach" gibt den Optionstyp an und ist das einzige Feld, das nicht optional ist. Abhängig vom Wert für den Option-Sachgebiet können die nächsten beiden Felder festgelegt werden. Die Optionslänge gibt die Gesamtlänge der Option an, und die Optionsdaten enthält gegebenenfalls Daten, die mit der Option zugeordnet sind. Beispielsweise zeigt ein Option-Sikind-Byte von 1 an, dass dies eine Option "NO-Operation" ist, die nur für die Polsterung verwendet wird und keine Optionslängen- oder Option-Daten-Felder enthält. Ein Option-Byte von 0 markiert das Ende der Optionen und ist auch nur ein Byte. Ein Option-Uktzoten-Byte von 2 wird verwendet, um die Option der maximalen Segmentgröße anzuzeigen, und folgt von einem Byte-Optionslänge, das die Länge des MSS-Feldes angibt. Die Optionslänge ist die Gesamtlänge des Feldes für angegebene Optionen, einschließlich Felder für Optionskind und Optionslänge. Während der MSS-Wert normalerweise in zwei Bytes ausgedrückt wird, beträgt die Optionslänge beispielsweise ein MSS-Optionsfeld mit einem Wert von 0x05b4 als (0x02 0x04 0x05b4) im Abschnitt TCP-Optionen.
Einige Optionen dürfen nur gesendet werden, wenn die Syn eingestellt ist. Sie sind unten als angegeben als [SYN]. Option-Kind- und Standardlängen, die als (Option-Kind, Optionslänge) angegeben sind.
Option-Sach Optionslänge Optionendaten Zweck Anmerkungen
0 - - Ende der Optionsliste
1 - - Keine Operation Dies kann verwendet werden, um Optionsfelder an 32-Bit-Grenzen für eine bessere Leistung auszurichten.
2 4 Ss Maximale Segmentgröße Sehen § Maximale Segmentgröße [SYN]
3 3 S Fensterskala Sehen § Fensterskalierung für Details[10] [SYN]
4 2 - Selektive Bestätigung erlaubt Sehen § Selektive Anerkennung für Details[11][SYN]
5 N (10, 18, 26 oder 34) BBBB, EEEE, ... Selektive Bestätigung (Sack)[12] Auf diese ersten beiden Bytes folgen eine Liste von 1–4 Blöcken, die selektiv anerkannt werden und als 32-Bit-Start-/Endzeiger angegeben sind.
8 10 Tttt, eeee Zeitstempel und Echo des vorherigen Zeitstempels Sehen § TCP -Zeitstempel für Details[13]
Die verbleibenden Optionskindwerte sind historisch, veraltet, experimentell, noch nicht standardisiert oder nicht zugewiesen. Die Optionsnummernzuweisungen werden von der IANA verwaltet.[14]
Polsterung
Die TCP-Headerpolsterung wird verwendet, um sicherzustellen, dass der TCP-Header an einer 32-Bit-Grenze beginnt und die Daten beginnen. Die Polsterung besteht aus Nullen.[15]

Protokollbetrieb

Ein vereinfachtes TCP -Zustandsdiagramm. Sehen TCP EFSM -Diagramm Für ein detaillierteres Zustandsdiagramm einschließlich der Staaten im etablierten Zustand.

TCP -Protokolloperationen können in drei Phasen unterteilt werden. Verbindungseinrichtung ist ein mehrstufiger Handshake-Prozess, der eine Verbindung herstellt Datentransfer Phase. Nach Abschluss der Datenübertragung die Verbindungsabschluss Schließt die Verbindung und veröffentlicht alle zugewiesenen Ressourcen.

Eine TCP-Verbindung wird von einem Betriebssystem über eine Ressource verwaltet, die den lokalen Endpunkt für Kommunikation darstellt, die Internet -Sockel. Während der Lebensdauer einer TCP-Verbindung erfährt der lokale Endpunkt einer Reihe von einer Reihe von Zustand Änderungen:[16]

TCP -Sockelzustände
Bundesland Endpunkt Beschreibung
HÖREN Server Warten auf eine Verbindungsanforderung von einem Remote-TCP-Endpunkt.
Syn-sent Klient Warten auf eine übereinstimmende Verbindungsanforderung nach dem Versenden einer Verbindungsanforderung.
Synchronisation Server Warten auf eine Bestätigung einer Bestätigung der Verbindungsanforderung, nachdem Sie eine Verbindungsanforderung erhalten und gesendet haben.
ETABLIERT Server und Client Eine offene Verbindung, die empfangene Daten an den Benutzer geliefert werden können. Der normale Zustand für die Datenübertragungsphase der Verbindung.
Fin-Wait-1 Server und Client Warten auf eine Anforderung zur Verbindungsbeendigung vom Remote -TCP oder eine Bestätigung des zuvor gesendeten Verbindungsabschlussantrags.
Fin-Wait-2 Server und Client Warten auf eine Verbindungsabschlussprüfung vom Remote -TCP.
Naher Wait Server und Client Warten auf eine Verbindungsabschlussprüfung vom lokalen Benutzer.
SCHLIESSEN Server und Client Warten auf eine Verbindungsbeendigung Anfrage Bestätigung aus dem Remote -TCP.
Last Server und Client Warten auf eine Bestätigung des zuvor an den Remote TCP gesendeten Verbindungsabschlussantrags (der eine Bestätigung der Anforderung des Verbindungsabschlusss enthält).
ZEIT WARTET Server oder Client Warten auf genügend Zeit, um sicherzustellen, dass alle verbleibenden Pakete auf der Verbindung abgelaufen sind.[e]
ABGESCHLOSSEN Server und Client Überhaupt kein Verbindungszustand.

Verbindungseinrichtung

Bevor ein Client versucht, sich mit einem Server zu verbinden, muss der Server zunächst an einen Port binden und an einem Port anhören, um ihn für Verbindungen zu öffnen: Dies wird als passive Open bezeichnet. Sobald der Passive offen ist, kann ein Kunde eine Verbindung herstellen, indem ein aktiver Open mit dem Drei-Wege-Handshake (oder 3-Schritt) eingeleitet wird:

  1. Syn: Das Active Open wird vom Client durchgeführt, der eine Syn an den Server sendet. Der Client legt die Sequenznummer des Segments auf einen zufälligen Wert A fest.
  2. Synchronisation: Als Antwort antwortet der Server mit einem SYN-ACK. Die Bestätigungsnummer wird auf eine mehr als die empfangene Sequenznummer, d. H. A+1, eingestellt, und die Sequenznummer, die der Server für das Paket auswählt, ist eine weitere zufällige Zahl, B.
  3. Ack: Schließlich sendet der Client einen ACK zurück an den Server. Die Sequenznummer wird auf den empfangenen Bestätigungswert eingestellt, d. H. A+1, und die Bestätigungsnummer ist auf eine mehr als die empfangene Sequenznummer, d. H. B+1.

Die Schritte 1 und 2 legen und bestätigen die Sequenznummer für eine Richtung. Die Schritte 2 und 3 legen und bestätigen die Sequenznummer für die andere Richtung. Nach Abschluss dieser Schritte haben sowohl der Client als auch der Server Bestätigungen erhalten und es wird eine Vollduplex-Kommunikation festgelegt.

Verbindungsabschluss

Verbindungsabschluss

In der Verbindungsabschlussphase wird ein Vier-Wege-Handschlag verwendet, wobei jede Seite der Verbindung unabhängig voneinander endet. Wenn ein Endpunkt seine Hälfte der Verbindung stoppen möchte, überträgt er ein Flossenpaket, das das andere Ende mit einem ACK anerkennt. Daher erfordert ein typisches Abtrennen ein Paar Flossen- und ACK-Segmente aus jedem TCP-Endpunkt. Nachdem die Seite, die die erste Flosse gesendet hat, mit dem endgültigen ACK geantwortet hat, wartet sie auf eine Auszeit, bevor sie schließlich die Verbindung schließt. Während dieser Zeit ist der lokale Port für neue Verbindungen nicht verfügbar. Dies verhindert eine mögliche Verwirrung, die auftreten kann, wenn verzögerte Pakete während einer nachfolgenden Verbindung geliefert werden.

Es ist auch möglich, die Verbindung mit einem 3-Wege-Handshake zu beenden, wenn Host A eine Flosse und Host B mit einer Flosse (zwei Schritte in einem kombinieren) sendet und A-Antworten mit einem ACK.[17]

Einige Betriebssysteme, wie z. Linux und HP-UXImplementieren Sie eine halbe Duplex-Abfolge. Wenn der Host eine Verbindung aktiv schließt und dennoch ungelesene eingehende Daten verfügbar ist, sendet der Host das Signal -RST (verliert empfangene Daten) anstelle von FIN. Dies stellt sicher, dass eine TCP -Anwendung bekannt ist, dass ein Datenverlust vorliegt.[18]

Eine Verbindung kann in a sein halb offen Staat, in diesem Fall hat eine Seite die Verbindung beendet, die andere jedoch nicht. Die Seite, die beendet wurde, kann keine Daten mehr in die Verbindung senden, aber die andere Seite kann. Die Kündigungsseite sollte die Daten weiter lesen, bis auch die andere Seiten endet.

Ressourcennutzung

Die meisten Implementierungen weisen einen Eintrag in einer Tabelle zu, die eine Sitzung einem laufenden Betriebssystemprozess ordnet. Da TCP -Pakete keine Sitzungskennung enthalten, identifizieren beide Endpunkte die Sitzung mithilfe der Adresse und Port des Clients. Immer wenn ein Paket empfangen wird, muss die TCP -Implementierung eine Suche in dieser Tabelle durchführen, um den Zielprozess zu finden. Jeder Eintrag in der Tabelle ist als Übertragungsregelblock oder TCB bezeichnet. Es enthält Informationen zu den Endpunkten (IP und Port), dem Status der Verbindung, der Ausführung von Daten zu den Paketen, die ausgetauscht werden, und Puffer zum Senden und Empfangen von Daten.

Die Anzahl der Sitzungen auf der Serverseite ist nur durch den Speicher begrenzt und kann mit neuen Verbindungen wachsen, aber der Client muss eine zuweisen kurzlebiger Hafen Vor dem Senden der ersten Syn an den Server. Dieser Port bleibt während der gesamten Konversation zugewiesen und begrenzt effektiv die Anzahl der ausgehenden Verbindungen aus den IP -Adressen des Kunden. Wenn eine Anwendung unerwünschte Verbindungen nicht ordnungsgemäß schließen kann, kann einem Client die Ressourcen ausgehen und auch nicht in der Lage sein, neue TCP -Verbindungen aus anderen Anwendungen herzustellen.

Beide Endpunkte müssen auch Platz für nicht anerkannte Pakete und empfangene (aber ungelesene) Daten bereitstellen.

Datentransfer

Das Transmissionskontrollprotokoll unterscheidet sich in mehreren Schlüsselmerkmalen im Vergleich zu dem User Datagram Protocol:

  • Bestellte Datenübertragung: Der Zielhost ordnet Segmente gemäß einer Sequenznummer neu[6]
  • Wiedergabe verlorener Pakete: Jeder nicht anerkannte kumulative Strom wird erneut übertragen[6]
  • Fehlerfreie Datenübertragung: beschädigte Pakete werden als verloren behandelt und werden erneut übertragen[19]
  • Durchflussregelung: Begrenzt die Rate, die ein Absender Daten überträgt, um eine zuverlässige Lieferung zu gewährleisten. Der Empfänger weist den Absender ständig darauf hin, wie viele Daten empfangen werden können. Wenn der Puffer des Empfangshosts füllt, setzt die nächste Bestätigung die Übertragung aus und ermöglicht die Verarbeitung der Daten im Puffer.[6]
  • Überlastungskontrolle: Verlorene Pakete (vermutet aufgrund von Überlastung) löst eine Verringerung der Datenablieferungsrate aus[6]

Zuverlässige Übertragung

TCP verwendet a Sequenznummer Um jedes Datenbyte zu identifizieren. Die Sequenznummer identifiziert die Reihenfolge der von jedem Computer gesendeten Bytes, damit die Daten unabhängig von jedem in der Reihenfolge rekonstruiert werden können Aus außerordentlicher Lieferung das kann auftreten. Die Sequenznummer des ersten Byte wird vom Sender für das erste Paket ausgewählt, das syn. Diese Zahl kann willkürlich sein und sollte tatsächlich unvorhersehbar sein, sich gegen zu verteidigen TCP -Sequenzvorhersageangriffe.

Bestätigungen (ACKs) werden vom Datenempfänger mit einer Sequenznummer gesendet, um dem Absender mitzuteilen, dass Daten an das angegebene Byte empfangen wurden. ACKs implizieren nicht, dass die Daten an die Anwendung geliefert wurden, sie bedeuten lediglich, dass es jetzt die Verantwortung des Empfängers ist, die Daten zu liefern.

Die Zuverlässigkeit wird durch den Absender erreicht, der verlorene Daten erkennt und wiederholt. TCP verwendet zwei primäre Techniken, um den Verlust zu identifizieren. Timeout (RTO) und doppelte kumulative Anerkennungen (Dupacks).

Dupack-basierte Wiedergabe

Wenn ein einzelnes Segment (beispielsweise Segmentnummer 100) in einem Stream verloren geht, kann der Empfänger keine Pakete über dieser Segmentnummer (100) bestätigen, da er kumulative ACKs verwendet. Daher bestätigt der Empfänger Paket 99 erneut nach Erhalt eines anderen Datenpakets. Diese doppelte Bestätigung wird als Signal für den Paketverlust verwendet. Das heißt, wenn der Absender drei doppelte Bestätigungen erhält, überträgt er das letzte nicht anerkannte Paket. Ein dreifacher Schwellenwert wird verwendet, da das Netzwerk Segmente neu ordnen kann, was zu doppelten Bestätigungen führt. Es wurde gezeigt, dass diese Schwelle nachgewiesen wurde, um falsche Wiederholungen aufgrund von Neubestehen zu vermeiden.[20] Einige TCP -Implementierungen verwenden Selektive Anerkennung (Säcke), um explizites Feedback zu den empfangenen Segmenten zu geben. Dies verbessert die Fähigkeit von TCP erheblich, die richtigen Segmente zu übernehmen.

Timeout-basierte Wiedergabe

Wenn ein Absender ein Segment überträgt, initialisiert er einen Timer mit einer konservativen Schätzung der Ankunftszeit der Bestätigung. Das Segment wird erneut übertragen, wenn der Timer abgelaufen Exponentielle Backoff Verhalten. Typischerweise ist der anfängliche Timerwert , wo ist die Uhr Granularität.[21] Dieser schützt vor übermäßigen Übertragungsverkehr aufgrund fehlerhafter oder böswilliger Schauspieler, wie z. der Mann in der Mitte Leugnung von Service -Angreifern.

Fehlererkennung

Mit Sequenznummern können Empfänger doppelte Pakete verwerfen und Pakete aus der Reihenfolge ordnungsgemäß sequenzieren. Ermöglichen Sie die Absender können feststellen, wann verlorene Pakete überbieten müssen.

Um die Korrektheit zu gewährleisten, ist ein Prüfsummenfeld enthalten; sehen § Überprüfungssummenberechnung für Details. Die TCP -Prüfsumme ist eine schwache Prüfung nach modernen Maßstäben und wird normalerweise mit a gepaart CRC Integritätsprüfung bei Schicht 2, unterhalb sowohl TCP als auch IP, wie sie in verwendet wird in Ppp oder der Ethernet rahmen. Die Einführung von Fehlern in Paketen zwischen CRC-geschützten Hops ist jedoch üblich, und die 16-Bit-TCP-Prüfsummen fangen die meisten davon auf.[22]

Ablaufsteuerung

TCP verwendet ein End-to-End Ablaufsteuerung Protokoll, um zu vermeiden, dass der Absender Daten zu schnell sendet, damit der TCP -Empfänger ihn zuverlässig empfangen und verarbeitet. Ein Mechanismus für die Durchflussregelung ist in einer Umgebung, in der Maschinen verschiedener Netzwerkgeschwindigkeiten kommunizieren, von wesentlicher Bedeutung. Wenn beispielsweise ein PC Daten an ein Smartphone sendet, das die empfangenen Daten langsam verarbeitet, muss das Smartphone den Datenfluss so regulieren können, dass nicht überwältigt wird.[6]

TCP verwendet a Schiebefenster Durchflussregelungsprotokoll. In jedem TCP -Segment gibt der Empfänger die in der an Fenster erhalten Feld Die Menge an zusätzlich empfangenen Daten (in Bytes), die bereit ist, für die Verbindung zu puffern. Der sendende Host kann nur bis zu dieser Datenmenge senden, bevor er auf eine Bestätigung warten und das Fenster -Update vom empfangenden Host empfangen muss.

TCP -Sequenznummern und Empfangsfenster verhalten sich einer Uhr sehr ähnlich. Das Empfangsfenster verschiebt sich jedes Mal, wenn der Empfänger ein neues Datensegment empfängt und bestätigt. Sobald es aus den Sequenznummern ausgeht, werden die Sequenznummer wieder auf 0.

Wenn ein Empfänger für eine Fenstergröße von 0 wirbt, sendet der Absender keine Daten und startet seine Starts Timer persist. Der persistische Timer wird verwendet, um TCP vor a zu schützen Sackgasse Eine Situation, die auftreten kann, wenn ein nachfolgendes Update der Fenstergröße vom Empfänger verloren geht und der Absender erst mehr Daten senden kann, wenn er eine neue Fenstergröße vom Empfänger empfängt. Wenn der persistische Timer abläuft, versucht der TCP -Absender die Wiederherstellung, indem er ein kleines Paket sendet, damit der Empfänger eine weitere Bestätigung mit der neuen Fenstergröße sendet.

Wenn ein Empfänger eingehende Daten in kleinen Schritten verarbeitet, kann er wiederholt für ein kleines Empfangsfenster bewerben. Dies wird als die bezeichnet Dummes Fenster -SyndromDa es ineffizient ist, nur wenige Daten Bytes in einem TCP -Segment zu senden, angesichts des relativ großen Aufwand des TCP -Headers.

Überlastungskontrolle

Der letzte Hauptaspekt von TCP ist Überlastungskontrolle. TCP verwendet eine Reihe von Mechanismen, um eine hohe Leistung zu erzielen und zu vermeiden Zusammenbruch des Kongestiven, Eine Stillstandssituation, in der die Netzwerkleistung stark verschlechtert ist. Diese Mechanismen steuern die Datenrate, die in das Netzwerk eintreten, und halten den Datenfluss unter eine Rate, die den Zusammenbruch auslösen würde. Sie ergeben auch ungefähr eine max-min fair Zuweisung zwischen Strömungen.

Bestätigungen für Daten gesendet oder das Fehlen von Bestätigungen werden von Absendern verwendet, um die Netzwerkbedingungen zwischen dem TCP -Absender und dem Empfänger zu schließen. In Verbindung mit Timern können TCP -Absender und Empfänger das Verhalten des Datenflusss verändern. Dies wird allgemeiner als Überlastungskontrolle oder Überlastungsvermeidung bezeichnet.

Moderne Implementierungen von TCP enthalten vier miteinander verflochtene Algorithmen: langsamer Start, Überlastungsvermeidung, Schneller Wiederveranstaffen, und schnelle Erholung.[23]

Darüber hinaus beschäftigen Absender a Wiedervermietung von Zeitüberschreitungen (RTO) das basiert auf dem geschätzten Zeit für eine Rundreise (RTT) zwischen Absender und Empfänger sowie die Varianz in dieser Hin- und Rückfahrt. Das Verhalten dieses Timers ist in angegeben RFC 6298. Es gibt Feinheiten bei der Schätzung von RTT. Beispielsweise müssen Absender bei der Berechnung von RTT -Proben für erneut übertragene Pakete vorsichtig sein. Normalerweise verwenden sie Karns Algorithmus oder TCP -Zeitstempel (siehe RFC 1323). Diese einzelnen RTT -Proben werden dann im Laufe der Zeit gemittelt, um einen geglätteten Rund Trip Time (SRTT) mit Jacobsons Algorithmus zu erstellen. Dieser SRTT-Wert wird als Rundweg-Zeitschätzung verwendet.

Verbesserung der TCP, um den Verlust zuverlässig zu bewältigen, Fehler zu minimieren, die Stauung zu verwalten und in sehr hohen Geschwindigkeitsumgebungen schnell zu gehen, sind laufende Bereiche der Forschung und Standardentwicklung. Infolgedessen gibt es eine Reihe von TCP -Überlastungsvermeidungsalgorithmus Variationen.

Maximale Segmentgröße

Das Maximale Segmentgröße (MSS) ist die größte Datenmenge, die in Bytes angegeben ist und die TCP bereit ist, in einem einzigen Segment zu empfangen. Für die beste Leistung sollten die MSS klein genug sein, um zu vermeiden IP -Fragmentierung, was zu Paketverlust und übermäßigen Wiederholungen führen kann. Um dies zu erreichen, wird der MSS normalerweise von jeder Seite unter Verwendung der MSS -Option angekündigt, wenn die TCP -Verbindung hergestellt wird. Der Optionswert wird von der abgeleitet Maximale Übertragungseinheit (MTU) Größe der Datenverbindungsschicht der Netzwerke, an die der Absender und der Empfänger direkt angehängt sind. TCP -Absender können verwenden Path MTU -Entdeckung Um die minimale MTU entlang des Netzwerkpfads zwischen Absender und Empfänger zu schließen, und damit die MSS dynamisch einstellen, um die IP -Fragmentierung innerhalb des Netzwerks zu vermeiden.

MSS -Ankündigung kann auch genannt werden MSS -Verhandlung Aber streng genommen ist das MSS nicht ausgehandelt Da zwei völlig unabhängige Werte von MSS für die beiden Richtungen des Datenflusss in einer TCP -Verbindung zulässig sind[24] Es ist daher nicht erforderlich, eine gemeinsame MSS -Konfiguration für eine bidirektionale Verbindung zuzustimmen.

Selektive Anerkennung

Wenn Sie sich nur auf das von der ursprünglichen TCP verwendete kumulative Anerkennungsschema verlassen, kann dies zu Ineffizienzen führen, wenn Pakete verloren gehen. Angenommen, Bytes mit Sequenzzahl von 1.000 bis 10.999 werden in 10 verschiedenen TCP -Segmenten gleicher Größe gesendet, und das zweite Segment (Sequenznummern 2.000 bis 2.999) gehen während der Übertragung verloren. In einem reinen kumulativen Anerkennungsprotokoll kann der Empfänger nur einen kumulativen ACK -Wert von 2.000 senden (die Sequenznummer unmittelbar nach der letzten Sequenznummer der empfangenen Daten) und kann nicht sagen, dass er erfolgreich Bytes erhalten hat. Daher muss der Absender dann möglicherweise alle Daten wiedergeben, beginnend mit der Sequenznummer 2.000.

Um dieses Problem zu lindern, verwendet TCP die Selektive Bestätigung (Sack) Option, die 1996 in RFC 2018 definiert wurde und es dem Empfänger ermöglicht, diskontinuierliche Blöcke von Paketen zu bestätigen, die ordnungsgemäß empfangen wurden, zusätzlich zur Sequenznummer unmittelbar nach der letzten Sequenznummer des letzten zusammenhängenden Byte, wie er nacheinander empfangen wurde, wie in der grundlegenden TCP -Bestätigung . Die Bestätigung kann eine Reihe von enthalten Sackblöcke, wo jeder Sackblock von der vermittelt wird Linker Rand des Blocks (die erste Sequenznummer des Blocks) und die Richtige Rand des Blocks (die Sequenznummer unmittelbar nach der letzten Sequenznummer des Blocks) mit a Block Ein zusammenhängender Bereich, den der Empfänger korrekt empfangen hat. Im obigen Beispiel würde der Empfänger ein ACK -Segment mit einem kumulativen ACK -Wert von 2.000 und einem Sackoption -Header mit Sequenznummern 3.000 und 11.000 senden. Der Absender würde dementsprechend nur das zweite Segment mit Sequenznummern von 2.000 bis 2.999 übernehmen.

Ein TCP-Absender kann eine Segmentzustellung außerhalb der Reihenfolge als verlorenes Segment interpretieren. Wenn dies der Fall ist, wird der TCP-Absender das Segment vor dem außergewöhnlichen Paket erneut übertragen und seine Datenlieferungsrate für diese Verbindung verlangsamt. Die Option Duplicate-Sack, eine Erweiterung der Sack-Option, die im Mai 2000 in RFC 2883 definiert wurde, löst dieses Problem. Der TCP-Empfänger sendet einen D-ACK, um anzugeben, dass keine Segmente verloren gingen und der TCP-Absender dann die höhere Übertragungsrate wieder einstellen kann.

Die Sackoption ist nicht obligatorisch und kommt nur dann in Betrieb, wenn beide Parteien sie unterstützen. Dies wird ausgehandelt, wenn eine Verbindung hergestellt wird. Sack verwendet eine TCP -Header -Option (siehe § TCP -Segmentstruktur für Details). Die Verwendung von Sack ist weit verbreitet - alle beliebten TCP -Stapel unterstützen es. Selektive Bestätigung wird auch in verwendet Stream Control Transmission Protocol (SCTP).

Fensterskalierung

Für die effizientere Verwendung von Netzwerken mit hohem Bandbreiten kann eine größere TCP-Fenstergröße verwendet werden. Das Feld der TCP -Fenstergröße steuert den Datenfluss und sein Wert ist auf 0 und 65.535 Bytes begrenzt.

Da das Größenfeld nicht erweitert werden kann, wird ein Skalierungsfaktor verwendet. Das Option für TCP -Fensterskala -SkalaWie in RFC 1323 definiert, wird eine Option verwendet, um die maximale Fenstergröße von 65.535 Bytes auf 1 Gigabyte zu erhöhen. Die Skalierung bis zu größeren Fenstergrößen ist ein Teil dessen, was notwendig ist TCP -Tuning.

Die Option für Fensterskala wird nur während des 3-Wege-Händedrucks von TCP verwendet. Der Fensterskala-Wert repräsentiert die Anzahl der Bits zum Linkshob des 16-Bit-Fenstergröße. Der Fensterskala -Wert kann für jede Richtung von 0 (keine Verschiebung) auf 14 eingestellt werden. Beide Seiten müssen die Option in ihren SYN -Segmenten senden, um die Fensterskalierung in beide Richtungen zu aktivieren.

Einige Router und Paket -Firewalls schreiben den Fensterskalierungsfaktor während eines Getriebes neu. Dies führt dazu, dass das Senden und Empfangen von Seiten unterschiedliche TCP -Fenstergrößen angenommen wird. Das Ergebnis ist nicht stabiler Verkehr, der sehr langsam sein kann. Das Problem ist an einigen Standorten hinter einem defekten Router sichtbar.[25]

TCP -Zeitstempel

TCP -Zeitstempel, die 1992 in RFC 1323 definiert sind, können TCP helfen, zu bestimmen, in welcher Bestellpakete gesendet wurden. TCP -Zeitstempel sind normalerweise nicht auf die Systemuhr ausgerichtet und beginnen mit einem zufälligen Wert. Viele Betriebssysteme erhöhen den Zeitstempel für jede verstrichene Millisekunde. Der RFC gibt jedoch nur an, dass die Zecken proportional sein sollten.

Es gibt zwei Zeitstempelfelder:

Ein 4-Byte-Absender-Zeitstempelwert (mein Zeitstempel)
Ein 4-Byte-Echo-Antwort-Zeitstempelwert (der neueste von Ihnen erhaltene Zeitstempel).

TCP -Zeitstempel werden in einem Algorithmus verwendet Schutz gegen verpackte Sequenz Zahlen, oder Pfoten (Siehe RFC 1323 für Einzelheiten). Pfoten werden verwendet, wenn das Empfangsfenster die Randaround -Grenze der Sequenznummer überschreitet. In dem Fall, in dem ein Paket potenziell erneut übertragen wurde, beantwortet es die Frage: "Ist diese Sequenznummer in den ersten 4 GB oder im zweiten?" Und der Zeitstempel wird verwendet, um die Krawatte zu brechen.

Außerdem verwendet der Eifel -Erkennungsalgorithmus (RFC 3522) TCP -Zeitstempel, um festzustellen, ob eine Wiederholung auftritt, da Pakete verloren gehen oder einfach nicht in Ordnung sind.

Jüngste Statistiken zeigen, dass die Einführung von Zeitstempel mit ~ 40%aufgrund der Ablagerung von Windows Server seit Windows Server 2008 mit ~ 40%gestagelt wurde.[26]

TCP -Zeitstempel sind standardmäßig im Linux -Kernel aktiviert.[27] und standardmäßig in Windows Server 2008, 2012 und 2016 deaktiviert.[28]

Daten außerhalb des Bandes

Es ist möglich, den Stream in der Warteschlange zu unterbrechen oder abzubrechen, anstatt darauf zu warten, dass der Stream fertig ist. Dies geschieht durch Angabe der Daten als dringend. Dies teilt dem Empfangsprogramm zusammen mit den übrigen dringenden Daten sofort. Nach Abschluss informiert TCP die Anwendung und setzt sich in die Stream -Warteschlange zurück. Ein Beispiel ist, wenn TCP für eine Remote -Anmeldesitzung verwendet wird, kann der Benutzer eine Tastatursequenz senden, die das Programm am anderen Ende unterbricht oder abbricht. Diese Signale werden am häufigsten benötigt, wenn ein Programm auf der Remote -Maschine nicht korrekt funktioniert. Die Signale müssen gesendet werden, ohne darauf zu warten, dass das Programm seine aktuelle Übertragung beendet.[6]

TCP Daten außerhalb des Bandes wurde nicht für das moderne Internet konzipiert. Das dringend Zeiger verändert die Verarbeitung auf dem Remote -Host nur und beschreibt keine Verarbeitung im Netzwerk selbst. Wenn es um den Remote -Host geht, gibt es zwei leicht unterschiedliche Interpretationen des Protokolls, was bedeutet, dass nur einzelne Bytes von OOB -Daten zuverlässig sind. Dies setzt voraus, dass es überhaupt zuverlässig ist, da es eines der am wenigsten häufig verwendeten Protokollelemente ist und neigt dazu, schlecht umgesetzt zu werden.[29][30]

Erzwingung der Datenbereitstellung

Normalerweise wartet TCP auf 200 ms auf ein vollständiges Datenpaket zum Senden (Nagles Algorithmus versucht, kleine Nachrichten in ein einzelnes Paket zu gruppieren). Diese Wartezeit schafft kleine, aber möglicherweise schwerwiegende Verzögerungen, wenn sie während einer Dateiübertragung ständig wiederholt wird. Beispielsweise wäre ein typischer Send -Block 4 kb, ein typischer MSS beträgt 1460 wartet auf einen vollen Puffer.

Im Fall von Telnet wird jeder Benutzer -Tastenanschlag vom Server wiedergegeben, bevor der Benutzer ihn auf dem Bildschirm sehen kann. Diese Verzögerung würde sehr nervig werden.

Einstellen des Steckdose Möglichkeit Tcp_nodelay Überschreibt die Standardverzögerung von 200 ms. Anwendungsprogramme verwenden diese Socket -Option, um die Ausgabe zu erzwingen, die nach dem Schreiben eines Zeichens oder einer Zeichenzeile gesendet werden soll.

Der RFC definiert die PSH Drücken Sie Bit als "eine Nachricht an den empfangenden TCP -Stack, um diese Daten sofort an die Empfangsanwendung zu senden".[6] Es gibt keine Möglichkeit, es anzuzeigen oder zu kontrollieren Benutzerraum Verwendung Berkeley Sockets und es wird von kontrolliert von Protokollstapel nur.[31]

Schwachstellen

TCP kann auf verschiedene Weise angegriffen werden. Die Ergebnisse einer gründlichen Sicherheitsbewertung von TCP sowie mögliche Minderungen für die identifizierten Themen wurden 2009 veröffentlicht.[32] und ist derzeit[wenn?] innerhalb der verfolgt werden Ietf.[33]

Denial of Service

Durch Verwendung a gefälschte IP Adresse und wiederholt senden absichtlich zusammengebaut Syn -Pakete, gefolgt von vielen ACK -Paketen, können Angreifer dazu veranlassen, dass der Server große Mengen an Ressourcen verbraucht, die die falschen Verbindungen im Auge behalten. Dies ist als a bekannt Syn -Flut Attacke. Vorgeschlagene Lösungen für dieses Problem umfassen Syn Cookies und kryptografische Rätsel, obwohl Syn Cookies mit ihren eigenen Schwachstellen ausgestattet sind.[34] Sockstress ist ein ähnlicher Angriff, der mit dem Systemressourcenmanagement gemindert werden kann.[35] Ein fortgeschrittener DOS -Angriff, der die Ausbeutung des TCP -persistischen Timers beinhaltete, wurde in analysiert Phrack #66.[36] Push- und ACK -Überschwemmungen sind andere Varianten.[37]

Verbindungsentführung

Ein Angreifer, der in der Lage ist, eine TCP -Sitzung zu belauschen und Pakete umzuleiten, kann eine TCP -Verbindung entführen. Zu diesem Zweck lernt der Angreifer die Sequenznummer aus der laufenden Kommunikation und schmiert ein falsches Segment, das wie das nächste Segment im Stream aussieht. Ein solch einfacher Hijack kann dazu führen, dass ein Paket an einem Ende fälschlicherweise akzeptiert wird. Wenn der empfangende Host das zusätzliche Segment auf die andere Seite der Verbindung anerkennt, geht die Synchronisation verloren. Die Entführung kann mit dem Adressauflösungsprotokoll kombiniert werden (ARP) oder Routing -Angriffe, die die Kontrolle über den Paketfluss ermöglichen, um die dauerhafte Kontrolle über die entführte TCP -Verbindung zu erhalten.[38]

Die Identität einer anderen IP -Adresse war vor RFC 1948 nicht schwierig, als die Initiale Sequenznummer war leicht erraten. Dies ermöglichte es einem Angreifer, blind eine Abfolge von Paketen zu senden, von denen der Empfänger von einer anderen IP -Adresse stammen würde, ohne dass ARP oder Routing -Angriffe bereitgestellt werden müssen: Es reicht aus, um sicherzustellen , oder bringen Sie es in diese Bedingung mit Denial-of-Service-Angriffe. Aus diesem Grund wird die anfängliche Sequenznummer nun zufällig ausgewählt.

TCP Veto

Ein Angreifer, der die Größe des zugesandten nächsten Pakets abhören und vorhersagen kann, kann dazu führen, dass der Empfänger eine böswillige Nutzlast akzeptiert, ohne die vorhandene Verbindung zu stören. Der Angreifer injiziert ein böswilliges Paket mit der Sequenznummer und einer Nutzlastgröße des nächsten erwarteten Pakets. Wenn das legitime Paket letztendlich empfangen wird, hat sich festgestellt, dass es die gleiche Sequenznummer und Länge wie ein bereits empfangenes Paket hat und als normales doppeltes Paket lautlos fallen gelassen wird - das legitime Paket wird vom bösartigen Paket "Vetoed" "Vetoed". Im Gegensatz zu Verbindungsentführungen wird die Verbindung nie deynchronisiert und die Kommunikation wird nach der Annahme der böswilligen Nutzlast fortgesetzt. Das TCP -Veto gibt dem Angreifer weniger Kontrolle über die Kommunikation, macht den Angriff jedoch besonders widerstandsfähig gegen die Erkennung. Der große Anstieg des Netzwerkverkehrs aus dem ACK -Sturm wird vermieden. Der einzige Beweis für den Empfänger, dass etwas nicht stimmt, ist ein einzelnes Duplikatpaket, ein normales Auftreten in einem IP -Netzwerk. Der Absender des gewerbierten Pakets sieht nie Beweise für einen Angriff.[39]

Eine andere Verwundbarkeit ist die TCP Reset Attack.

TCP -Ports

TCP- und UDP -Verwendung Portnummern Um das Senden und Empfangen von Bewerbungsendpunkten auf einem Host zu identifizieren, oft genannt Internet -Sockeln. Jede Seite einer TCP-Verbindung verfügt über eine zugeordnete 16-Bit-nicht signierte Portnummer (0-65535), die vom Senden- oder Empfangsantrag reserviert ist. Ankunft TCP -Pakete werden von seinen Sockets als zu einer bestimmten TCP -Verbindung gehörend identifiziert, dh der Kombination aus Quellhostadresse, Quellport, Zielhostadresse und Zielport. Dies bedeutet, dass ein Servercomputer mehrere Clients gleichzeitig mehrere Dienste zur Verfügung stellen kann, solange ein Client gleichzeitig gleichzeitige Verbindungen zu einem Zielport von verschiedenen Quellports initiiert.

Portnummern werden in drei grundlegende Kategorien eingeteilt: bekannt, registriert und dynamisch/privat. Die bekannten Ports werden von der zugewiesen Internet zugewiesene Zahlen Autorität (IANA) und werden typischerweise durch System- oder Wurzelprozesse verwendet. Bekannte Anwendungen, die als Server ausgeführt werden und passiv auf Verbindungen anhören, verwenden diese Ports normalerweise. Einige Beispiele sind: Ftp (20 und 21), Ssh (22), Telnet (23), SMTP (25),, HTTP über SSL/TLS (443) und Http (80). Beachten Sie ab dem neuesten Standard, Http/3, Quic wird als Transport anstelle von TCP verwendet. Registrierte Ports werden normalerweise von Endbenutzeranwendungen als verwendet flüchtig Quellports beim Kontakt mit Servern, aber sie können auch benannte Dienste identifizieren, die von einem Dritten registriert wurden. Dynamische/private Ports können auch von Endbenutzeranwendungen verwendet werden, sind jedoch weniger häufig. Dynamische/private Ports enthalten keine Bedeutung außerhalb einer bestimmten TCP -Verbindung.

Netzwerkadressübersetzung (NAT) verwendet typischerweise dynamische Portnummern auf der öffentlichen Seite ("Internet-Ausrichtung"), um sich steigern Der Verkehrsfluss, der zwischen einem öffentlichen Netzwerk und einem privaten verläuft SubnetzwerkDadurch können viele IP-Adressen (und deren Ports) auf dem Subnetz von einer einzigen öffentlichen Adresse bedient werden.

Entwicklung

TCP ist ein komplexes Protokoll. Obwohl im Laufe der Jahre signifikante Verbesserungen vorgenommen und vorgeschlagen wurden, hat sich der grundlegendste Betrieb seit seiner ersten Spezifikation RFC 675 im Jahr 1974 und der V4 -Spezifikation RFC 793, die im September 1981 veröffentlicht wurde, nicht wesentlich geändert. Hosts haben eine Reihe von TCP -Protokollimplementierungsanforderungen geklärt. Eine Liste der 8 erforderlichen Spezifikationen und über 20 erheblichen Verbesserungen ist in RFC 7414 verfügbar . Im Jahr 2001 wurde RFC 3168 geschrieben, um eine explizite Überlastungsbenachrichtigung zu beschreiben (ECN), ein Signalmechanismus zur Vermeidung von Überlastungen.

Das Original TCP -Überlastungsvermeidungsalgorithmus war als "TCP Tahoe" bekannt, aber seitdem wurden viele alternative Algorithmen vorgeschlagen (einschließlich TCP Reno, TCP Vegas, Schneller TCP, TCP New Reno, und TCP Hybla).

TCP Interactive (ITCP) [40] ist ein Forschungsaufwand in TCP-Erweiterungen, mit denen Anwendungen TCP-Ereignisse abonnieren und Handlerkomponenten registrieren können, die Anwendungen für verschiedene Zwecke starten können, einschließlich anwendungsunterstützter Überlastungskontrolle.

Multipath TCP (MPTCP) [41][42] ist eine fortlaufende Anstrengung innerhalb des IETF, die es einer TCP -Verbindung ermöglichen soll, mehrere Pfade zu verwenden, um die Ressourcenverbrauch zu maximieren und die Redundanz zu erhöhen. Die von Multipath TCP im Kontext von drahtlosen Netzwerken angebotene Redundanz ermöglicht die gleichzeitige Nutzung verschiedener Netzwerke, die einen höheren Durchsatz und besseren Übergabefunktionen mit sich bringt. Multipath TCP bringt auch Leistungsvorteile in Rechenzentrumumgebungen mit.[43] Die Referenzimplementierung[44] von Multipath TCP wird im Linux -Kernel entwickelt.[45] Multipath TCP wird verwendet, um die Siri -Voice -Erkennungsanwendung auf iPhones, iPads und Macs zu unterstützen [46]

tcpcrypt ist eine im Juli 2010 vorgeschlagene Verlängerung, um die Verschlüsselung auf Transportebene direkt in TCP selbst bereitzustellen. Es ist so konzipiert, dass es transparent funktioniert und keine Konfiguration erfordert. nicht wie Tls (SSL) bietet TCPCrypt selbst keine Authentifizierung, sondern liefert die Anwendung, um dies zu tun. Ab 2010Der erste TCPCrypt -IETF -Entwurf wurde veröffentlicht und es gibt Implementierungen für mehrere wichtige Plattformen.

TCP schnell offen ist eine Erweiterung, um die Öffnung von aufeinanderfolgenden TCP -Verbindungen zwischen zwei Endpunkten zu beschleunigen. Es funktioniert, indem es den Drei-Wege-Handschlag mit einem kryptografischen "Cookie" überspringt. Es ähnelt einem früheren Vorschlag namens T/TCP, was aufgrund von Sicherheitsproblemen nicht weit verbreitet war.[47] TCP Fast Open wurde 2014 als RFC 7413 veröffentlicht.[48]

Vorgeschlagen im Mai 2013 ist eine proportionale Ratenreduzierung (PRR) eine TCP -Erweiterung, die von entwickelt wurde, Google Ingenieure. PRR stellt sicher, dass die TCP -Fenstergröße nach der Wiederherstellung so nahe an der ist Langsamer Start Schwelle wie möglich.[49] Der Algorithmus ist entwickelt, um die Wiederherstellungsgeschwindigkeit zu verbessern, und ist der Standard -Stauungssteuerungsalgorithmus in Linux 3,2+ -Kerneln.[50]

Veraltete Vorschläge

TCP -Cookie -Transaktionen (TCPCT) ist eine Erweiterung, die im Dezember 2009 vorgeschlagen wurde, um Server gegen Angriffe von Denial-of-Service zu sichern. Im Gegensatz zu Syn Cookies widerspricht TCPCT nicht mit anderen TCP -Erweiterungen wie z. Fensterskalierung. TCPCT wurde aufgrund der Notwendigkeiten von entworfen DNSSEC, wo Server eine große Anzahl von kurzlebigen TCP-Verbindungen verarbeiten müssen. Im Jahr 2016 wurde TCPCT zugunsten von veraltet TCP schnell offen. Der Status des ursprünglichen RFC wurde in "historisch" geändert.[51]

TCP über drahtlose Netzwerke

TCP war ursprünglich für Kabelnetzwerke konzipiert. Paketverlust wird als Ergebnis von angesehen Netzüberlastung und die Überlastungsfenstergröße wird vorsorglich dramatisch reduziert. Es ist jedoch bekannt Interferenzund andere Funkeffekte, die nicht streng überlastet sind. Nach der (fehlerhaften) Back-Off der Überlastungsfenstergröße aufgrund des drahtlosen Paketverlusts kann eine Überlastungsvermeidungsphase mit einer konservativen Verringerung der Fenstergröße stattfinden. Dies führt dazu, dass die Funkverbindung nicht genutzt wird. Es wurden umfangreiche Untersuchungen zur Bekämpfung dieser schädlichen Effekte durchgeführt. Vorgeschlagene Lösungen können als End-to-End-Lösungen kategorisiert werden, die Änderungen am Client oder Server erfordern.[52] Link -Layer -Lösungen wie Radioverbindungsprotokoll (RLP) in zellulären Netzwerken oder proxybasierten Lösungen, die einige Änderungen im Netzwerk erfordern, ohne Endknoten zu ändern.[52][53]

Eine Reihe alternativer Stauungskontrollalgorithmen, wie z. Vegas, Westwood, Veno und Santa Cruz, wurden vorgeschlagen, um das drahtlose Problem zu lösen.

Hardware -Implementierungen

Eine Möglichkeit, die Verarbeitungsleistunganforderungen von TCP zu überwinden, besteht darin, Hardware -Implementierungen zu erstellen, die allgemein bekannt als TCP -Offload -Motoren (ZEHE). Das Hauptproblem von Zehen besteht darin, dass sie schwer in Computersysteme integrieren sind und umfangreiche Änderungen im Betriebssystem des Computers oder Geräts erfordern. Ein Unternehmen, um ein solches Gerät zu entwickeln, war Alacritech.

Debuggen

A Paketschnusel, das den TCP -Datenverkehr auf einem Netzwerkverbindung abfängt, kann nützlich sein, um Netzwerke, Netzwerkstapel und Anwendungen zu debuggen, die TCP verwenden, indem der Benutzer gezeigt wird, welche Pakete durch einen Link gehen. Einige Netzwerkstapel unterstützen die Option So_debug Socket, die mithilfe von Setsockopt in der Socket aktiviert werden kann. Diese Option bringt alle Pakete, TCP -Zustände und Ereignisse in diesem Socket ab, was beim Debuggen hilfreich ist. Netstat ist ein weiteres Dienstprogramm, das zum Debuggen verwendet werden kann.

Alternativen

Für viele Anwendungen ist TCP nicht angemessen. Ein Problem (zumindest bei normalen Implementierungen) ist, dass die Anwendung nicht auf die Pakete zugreifen kann, die nach einem verlorenen Paket kommen, wenn die erneut übertragene Kopie des verlorenen Pakets empfangen wird. Dies führt zu Problemen für Echtzeitanwendungen wie Streaming von Medien, Echtzeit-Multiplayer-Spiele und Voice over IP (VoIP) wo es im Allgemeinen nützlicher ist, die meisten Daten rechtzeitig zu erhalten, als alle Daten in Ordnung zu bringen.

Aus historischen und leistungsstarken Gründen die meisten Speicherbereichsnetzwerke (Sans) verwenden Faserkanalprotokoll (FCP) über Faserkanal Verbindungen.

Auch für eingebettete Systeme, Netzwerkbootingund Server, die einfache Anfragen von einer großen Anzahl von Kunden stellen (z. DNS Server) Die Komplexität von TCP kann ein Problem sein. Schließlich einige Tricks wie die Übertragung von Daten zwischen zwei Hosts, die beide dahinter sind Nat (Verwendung BETÄUBEN oder ähnliche Systeme) sind ohne ein relativ komplexes Protokoll wie TCP weitaus einfacher.

Im Allgemeinen, wenn TCP ungeeignet ist, die User Datagram Protocol (UDP) wird verwendet. Dies liefert die Anwendung Multiplexing und Überprüfungen, die TCP durchführen, verarbeitet jedoch keine Streams oder eine Übermittlung, wodurch der Anwendungsentwickler die Möglichkeit gibt, sie auf eine Weise zu codieren, die für die Situation geeignet ist, oder sie durch andere Methoden wie ersetzt Vorwärtsfehlerkorrektur oder Interpolation.

Stream Control Transmission Protocol (SCTP) ist ein weiteres Protokoll, das zuverlässige, streamorientierte Dienste ähnelt wie TCP. Es ist neuer und wesentlich komplexer als TCP und hat noch keine weit verbreitete Bereitstellung gesehen. Es ist jedoch insbesondere so konzipiert, dass es in Situationen verwendet werden soll, in denen Zuverlässigkeit und nahezu reale Überlegungen wichtig sind.

Venturi -Transportprotokoll (VTP) ist patentiert Proprietäres Protokoll Dies soll TCP transparent ersetzen, um wahrgenommene Ineffizienzen im Zusammenhang mit dem drahtlosen Datentransport zu überwinden.

TCP hat auch Probleme in Umgebungen mit hoher Bandbreite. Das TCP -Überlastungsvermeidungsalgorithmus Funktioniert sehr gut für Ad-hoc-Umgebungen, in denen der Datenabsender im Voraus nicht bekannt ist. Wenn die Umgebung vorhersehbar ist, ein zeitbasiertes Protokoll wie z. asynchroner Übertragungsmodus (ATM) kann TCP -Rückschläge über Kopf vermeiden.

UDP-basierter Datenübertragungsprotokoll (UDT) hat eine bessere Effizienz und Fairness als TCP in Netzwerken, die hoch haben Bandbreiten-Delay-Produkt.[54]

Mehrzweck -Transaktionsprotokoll (MTP/IP) ist eine patentierte proprietäre Software, mit der die Leistung und Transaktionsleistung in einer Vielzahl von Netzwerkbedingungen adaptiv erreicht werden soll, insbesondere bei solchen, bei denen TCP als ineffizient angesehen wird.

Prüfsummenberechnung

TCP -Prüfsumme für IPv4

Wenn TCP überläuft IPv4Die Methode zur Berechnung der Prüfsumme ist in RFC 793 definiert:

Das Prüfsummenfeld ist das 16-Bit-Ergänzung der Komplementsumme aller 16-Bit-Wörter im Kopf und Text. Wenn ein Segment eine ungerade Anzahl von Header- und Text-Oktetten enthält, die überprüft werden sollen, wird das letzte Oktett rechts mit Nullen gepolstert, um ein 16-Bit-Wort für Prüfsummen zu bilden. Das Pad wird nicht als Teil des Segments übertragen. Während der Berechnung der Prüfsummen wird das Feld Kontrollummen selbst durch Nullen ersetzt.

Mit anderen Worten, nach geeigneten Polsterung werden alle 16-Bit die Komplementarithmetik. Die Summe wird dann bitweise ergänzt und als Prüfsummenfeld eingefügt. Ein Pseudoader, der den IPv4-Paket-Header nachahmt, der in der Prüfsummenberechnung verwendet wird, wird in der folgenden Tabelle angezeigt.

TCP Pseudo-Header für die Prüfsummenberechnung (IPv4)
Bit Offset 0–3 4–7 8–15 16–31
0 Quelladresse
32 Zieladresse
64 Nullen Protokoll TCP -Länge
96 Quellport Zielhafen
128 Sequenznummer
160 Bestätigungsnummer
192 Datenversatz Reserviert Flaggen Fenster
224 Überprüfung Dringender Zeiger
256 Optionen (optional)
256/288+  
Daten
 

Die Quell- und Zieladressen sind die des IPv4 -Headers. Der Protokollwert beträgt 6 für TCP (vgl. Liste der IP -Protokollnummern). Das Feld TCP -Länge ist die Länge des TCP -Headers und der Daten (gemessen in Oktetten).

TCP -Prüfsumme für IPv6

Wenn TCP überläuft IPv6Die Methode zur Berechnung der Prüfsumme wird gemäß RFC 2460 geändert:

Jeder Transport oder ein anderes Protokoll der oberen Schicht, das die Adressen des IP-Headers in der Prüfsummenberechnung enthält, muss für die Verwendung über IPv6 geändert werden, um die 128-Bit-IPv6-Adressen anstelle von 32-Bit-IPv4-Adressen zu enthalten.

Ein Pseudoader, der den IPv6-Header für die Berechnung der Prüfsummen nachahmt, ist unten gezeigt.

TCP Pseudo-Header für die Prüfsummenberechnung (IPv6)
Bit Offset 0–7 8–15 16–23 24–31
0 Quelladresse
32
64
96
128 Zieladresse
160
192
224
256 TCP -Länge
288 Nullen Nächster Header
= Protokoll
320 Quellport Zielhafen
352 Sequenznummer
384 Bestätigungsnummer
416 Datenversatz Reserviert Flaggen Fenster
448 Überprüfung Dringender Zeiger
480 Optionen (optional)
480/512+  
Daten
 
  • Quelladresse: die im IPv6 -Header
  • Zieladresse: Das endgültige Ziel; Wenn das IPv6 -Paket keinen Routing -Header enthält, verwendet TCP die Zieladresse im IPv6 -Header, ansonsten am Ursprungsknoten die Adresse im letzten Element des Routing -Headers und am empfangenden Knoten sie Verwendet die Zieladresse im IPv6 -Header.
  • TCP -Länge: Die Länge des TCP -Headers und der Daten
  • Nächster Header: Der Protokollwert für TCP

Prüfsumme -Ausladung

Viele TCP/IP -Software -Stapel -Implementierungen bieten Optionen für Hardwareunterstützung, um die Prüfsumme automatisch in der zu berechnen Netzwerkadapter Vor der Übertragung auf das Netzwerk oder nach Empfang aus dem Netzwerk zur Validierung. Dies kann das Betriebssystem daran hindern, kostbare CPU -Zyklen zu verwenden, die die Prüfsumme berechnen. Daher wird die gesamte Netzwerkleistung erhöht.

Diese Funktion kann verursachen Paketanalysatoren Dies ist nicht bewusst oder unsicher über die Verwendung von Prüfsummen -Offload, um ungültige Prüfsummen in ausgehenden Paketen zu melden, die den Netzwerkadapter noch nicht erreicht haben.[55] Dies tritt nur für Pakete auf, die vor dem Übertragen vom Netzwerkadapter abgefangen werden. Alle vom Netzwerkadapter auf dem Kabel übertragenen Pakete haben gültige Prüfsummen.[56] Dieses Problem kann auch auftreten, wenn die Überwachung von Paketen zwischen virtuellen Maschinen auf demselben Host übertragen wird, wobei ein virtueller Geräte -Treiber die Prüfsummenberechnung (als Optimierung) weglassen kann, wobei der Beachtungsumsatz später vom VM -Host -Kernel oder dessen physikalisch berechnet wird Hardware.

RFC -Dokumente

  • RFC675 - Spezifikation des Internetübertragungskontrollprogramms, Dezember 1974 Version
  • RFC793 - TCP V4
  • RFC1122 - Enthält einige Fehlerkorrekturen für TCP
  • RFC1323 - TCP -Erweiterungen für hohe Leistung [von RFC 7323 veraltet]
  • RFC1379 - TCP für Transaktionen erweitern - Konzept [überlegt von RFC 6247]
  • RFC1948 - Verteidigung gegen Sequenznummernangriffe
  • RFC2018 - TCP Selektive Bestätigungsoptionen
  • RFC5681 - TCP -Überlastungskontrolle
  • RFC6247 - Bewegen Sie die nicht liegenden TCP -Erweiterungen RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644 und RFC 1693 zum historischen Status
  • RFC6298 - Berechnung des TCP -Retransmission -Timers von TCP
  • RFC6824 - TCP -Erweiterungen für den Multipath -Betrieb mit mehreren Adressen
  • RFC7323 - TCP -Erweiterungen für hohe Leistung
  • RFC7414 - Eine Roadmap für TCP -Spezifikationsdokumente

Siehe auch

Anmerkungen

  1. ^ Experimentell: Siehe RFC 3540
  2. ^ a b Hinzufügen von RFC 3168 zu Header hinzugefügt
  3. ^ Windows -Größeeinheiten sind standardmäßig Bytes.
  4. ^ Die Fenstergröße ist relativ zum Segment, das durch die Sequenznummer im Feld Bestätigungsfeld identifiziert wurde.
  5. ^ Laut RFC 793 kann eine Verbindung maximal vier Minuten lang als zwei in Zeit erwarten Maximale Segmentlebensdauer (MSL).

Verweise

  1. ^ Vinton G. Cerf; Robert E. Kahn (Mai 1974). "Ein Protokoll für die Interkommunikation für Paketnetzwerke" (PDF). IEEE -Transaktionen zur Kommunikation. 22 (5): 637–648. doi:10.1109/tcom.1974.1092259. Archiviert von das Original (PDF) am 4. März 2016.
  2. ^ Bennett, Richard (September 2009). "Für Veränderungen konzipiert: End-to-End-Argumente, Internetinnovation und die Debatte über die Netzneutralität" (PDF). Foundation für Informationstechnologie und Innovation. p. 11. Abgerufen 11. September 2017.
  3. ^ Cerf, Vinton; Dalal, Yogen; Sunshine, Carl (Dezember 1974), RFC 675, Spezifikation des Internetübertragungsregelungsprotokolls
  4. ^ "Robert E Kahn - A. M. Turing Award Laureate". Amturing.acm.org.
  5. ^ "Vinton Cerf - A. M. Turing Award Laureate". Amturing.acm.org.
  6. ^ a b c d e f g h i Comer, Douglas E. (2006). Internetbearbeitung mit TCP/IP: Prinzipien, Protokolle und Architektur. Vol. 1 (5. Aufl.). Prentice Hall. ISBN 978-0-13-187671-2.
  7. ^ "TCP (Transmission Control Protocol)". Abgerufen 2019-06-26.
  8. ^ "RFC 791 - Abschnitt 2.2".
  9. ^ Transmissionskontrollprotokoll. Ietf. September 1981. doi:10.17487/rfc0793. RFC 793.
  10. ^ TCP -Erweiterungen für hohe Leistung. Sek. 2.2. RFC 1323.
  11. ^ "RFC 2018, TCP Selektive Bestätigungsoptionen, Abschnitt 2".
  12. ^ "RFC 2018, TCP Selektive Bestätigungsoptionen, Abschnitt 3".
  13. ^ "RFC 1323, TCP -Erweiterungen für hohe Leistung, Abschnitt 3.2".
  14. ^ "Transmission Control Protocol (TCP) Parameter: TCP -Option Art -Nummern". Iana.
  15. ^ RFC 793 Abschnitt 3.1
  16. ^ RFC 793 Abschnitt 3.2
  17. ^ Tanenbaum, Andrew S. (2003-03-17). Computernetzwerke (Viertes Ausgabe). Prentice Hall. ISBN 978-0-13-066102-9.
  18. ^ RFC 1122, Abschnitt 4.2.2.13
  19. ^ "TCP -Definition". Abgerufen 2011-03-12.
  20. ^ Mathis; Mathew; Semke; Mahdavi; Ott (1997). "Das makroskopische Verhalten des Algorithmus zur Vermeidung von TCP -Überlastungen". ACM Sigcomm Computerkommunikation Review. 27 (3): 67–82. Citeseerx 10.1.1.40.7002. doi:10.1145/263932.264023. S2CID 1894993.
  21. ^ Paxson, V.; Allman, M.; Chu, J.; Sargent, M. (Juni 2011). "Der Grundalgorithmus". Berechnung des TCP -Retransmission -Timers von TCP. Ietf. p. 2 Sek. 2. doi:10.17487/rfc6298. RFC 6298. Abgerufen 24. Oktober, 2015.
  22. ^ Stein; Partridge (2000). "Wenn der CRC- und TCP -Kontrollsumme nicht zustimmt". ACM Sigcomm Computerkommunikation Review: 309–319. Citeseerx 10.1.1.27.7611. doi:10.1145/347059.347561. ISBN 978-1581132236. S2CID 9547018.
  23. ^ RFC 5681
  24. ^ "RFC 879".
  25. ^ "TCP -Fensterskalierung und kaputte Router [lwn.net]".
  26. ^ David Murray; Terry Koziniec; Sebastian Zander; Michael Dixon; Polychronis Koutsakis (2017). "Eine Analyse der sich ändernden Unternehmensnetzwerk -Verkehrsmerkmale" (PDF). Die 23. asiatisch-pazifische Kommunikationskonferenz (APCC 2017). Abgerufen 3. Oktober 2017.
  27. ^ "IP -Sysctl". Linux -Kernel -Dokumentation. Abgerufen 15. Dezember 2018.
  28. ^ Wang, Eva. "TCP -Zeitstempel ist deaktiviert". TECHNET - Windows Server 2012 Essentials. Microsoft. Archiviert von das Original Am 2018-12-15. Abgerufen 2018-12-15.
  29. ^ Gont, Fernando (November 2008). "Zur Implementierung von TCP -Dringdaten". 73. IETF -Meeting. Abgerufen 2009-01-04.
  30. ^ Peterson, Larry (2003). Computernetzwerke. Morgan Kaufmann. p.401. ISBN 978-1-55860-832-0.
  31. ^ Richard W. Stevens (November 2011). TCP/IP illustriert. Vol. 1, die Protokolle. Addison-Wesley. S. Kapitel 20. ISBN 978-0-201-63346-7.
  32. ^ "Sicherheitsbewertung des Transmission Control Protocol (TCP)" (PDF). Archiviert vom Original am 6. März 2009. Abgerufen 2010-12-23.{{}}: CS1 Wartung: Bot: Original -URL -Status unbekannt (Link)
  33. ^ Sicherheitsbewertung des Transmission Control Protocol (TCP)
  34. ^ Jakob Lell. "Schnellblindes TCP -Verbindungs ​​-Spoofing mit Syn Cookies". Abgerufen 2014-02-05.
  35. ^ "Einige Einblicke in die jüngsten TCP DOS (Denial of Service) Schwachstellen" (PDF).
  36. ^ "TCP und den persistischen Timer unendlich ausnutzen".
  37. ^ "Push und ACK Flut". f5.com.
  38. ^ "Laurent Joncheray, Einfacher aktiver Angriff gegen TCP, 1995 ".
  39. ^ John T. Hagen; Barry E. Mullins (2013). TCP Veto: Ein neuartiger Netzwerkangriff und seine Anwendung auf SCADA -Protokolle. Innovative Smart Grid Technologies (ISGT), 2013 IEEE PES. S. 1–6. doi:10.1109/isgt.2013.6497785. ISBN 978-1-4673-4896-6. S2CID 25353177.
  40. ^ "TCP Interactive". www.medianet.kent.edu.
  41. ^ RFC 6182
  42. ^ RFC 6824
  43. ^ Raiciu; Stange; Pluntke; Greenhalgh; Wischik; Handley (2011). "Verbesserung der Leistung und Robustheit mit Multipath TCP" Verbesserung ". ACM Sigcomm Computerkommunikation Review. 41 (4): 266. Citeseerx 10.1.1.306.3863. doi:10.1145/2043164.2018467. Archiviert von das Original am 2020-04-04. Abgerufen 2011-06-29.
  44. ^ "Multipath TCP - Linux -Kernel -Implementierung".
  45. ^ Raiciu; Paasch; Stange; Ford; Honda; Duchene; Bonaventure; Handley (2012). "Wie schwer kann es sein? Entwerfen und Implementieren eines bereitstellbaren Multipath -TCP". Usenix NSDI: 399–412.
  46. ^ Bonaventure; SEO (2016). "Multipath TCP -Bereitstellungen". IETF Journal.
  47. ^ Michael Kerrisk (2012-08-01). "TCP Fast Open: Expediting Web Services". Lwn.net.
  48. ^ Yuchung Cheng; Jerry Chu; Sivasankar Radhakrishnan & Arvind Jain (Dezember 2014). "TCP schnell offen". Ietf. Abgerufen 10. Januar 2015. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  49. ^ Mathis, Matt; Dukkipati, Nandita; Cheng, Yuchung (Mai 2013). "RFC 6937 - Proportionalrate Reduktion für TCP". Abgerufen 6. Juni 2014. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  50. ^ Grigorik, Ilya (2013). Hochleistungs-Browser-Netzwerk (1. ed.). Peking: O'Reilly. ISBN 978-1449344764.
  51. ^ "Umzug zu" historischer "Status". Bewegen veralteter TCP-Erweiterungen und TCP-bezogenen Dokumente in den historischen oder Informationsstatus. Ietf. 2016. p. 4. Sek. 2.1. doi:10.17487/rfc7805. RFC 7805.
  52. ^ a b "TCP -Leistung über CDMA2000 RLP". Archiviert von das Original Am 2011-05-03. Abgerufen 2010-08-30.
  53. ^ Muhammad Adeel & Ahmad Ali Iqbal (2004). TCP -Überlastungsfensteroptimierung für CDMA2000 -Paket -Datennetze. Internationale Konferenz über Informationstechnologie (ITNG'07). S. 31–35. doi:10.1109/itng.2007.190. ISBN 978-0-7695-2776-5. S2CID 8717768.
  54. ^ Yunhong Gu, Xinwei Hong und Robert L. Grossman."Eine Analyse des AIMD -Algorithmus mit abnehmender Zunahme". 2004.
  55. ^ "Wireshark: abladen". Wireshark erfasst Pakete, bevor sie an den Netzwerkadapter gesendet werden. Es wird nicht die richtige Prüfsumme angezeigt, da sie noch nicht berechnet wurde. Noch schlimmer ist, dass die meisten OSS diese Daten nicht initialisieren, sodass Sie wahrscheinlich kleine Speicherbrocken sehen, die Sie nicht sollten. Neue Installationen von Wireshark 1.2 und oben deaktivieren standardmäßig IP-, TCP- und UDP -Prüfsummenvalidierung. Sie können bei Bedarf die Überprüfungssummenvalidierung in jedem dieser Disssektoren von Hand deaktivieren.
  56. ^ "Wireshark: Prüfsummen". Überladungsprüfungsauslagerung führt häufig zu Verwirrung, da die zu übertragenen Netzwerkpakete an Wireshark übergeben werden, bevor die Prüfsummen tatsächlich berechnet werden. Wireshark erhält diese „leeren“ Überprüfungen und zeigt sie als ungültig an, obwohl die Pakete gültige Prüfsummen enthalten, wenn sie die Netzwerkhardware später verlassen.

Weitere Lektüre

Externe Links