Diskussion:Transmission Control Protocol/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Transmission Control Protocol/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Transmission_Control_Protocol/Archiv#Thema_1

Kommentare zum Artikel

Ich schliesse mich der Meinung an

daß der Artikel gut, aber nicht sehr gut ist.

Anbei einige Kommentare, [K] bedeutet, daß ich das klärenswert halte, [H] sollte man hinzufügen.

• Einführung:

• [K] Das Attribut „zuverlässig“ wird nicht im in der Informationstechnik üblichen Sinne verwendet. Um es zu erklären, kann man den Gegensatz des „unzuverlässigen“ UDP erwähnen (es darf Pakete verlieren).
• [H] Erweiterungen und die Wartung von TCP finden in Charter „TCP Maintenance and Minor Extensions“ der „Transport Area der IETF Working Groups statt (http://www.ietf.org/html.charters/tcpm-charter.html)
• [H] Die erste Unix-Implementierung fand in BSD Unix statt. Diese Software wurde später von Microsoft in Windows übernommen.

• „Verbindungsaufbau und Abbau“, „Allgemeines“:

• [H] Sowohl bei Unix als auch bei Windows finden sich Teile der TCP/IP-Software im Kernel, andere außerhalb des Kernels. Die Socket-Schnittstelle (Standard-Schnittstelle zum Zugriff auf das Internet; eingeführt bei BSD Unix) ist bei Unix ein Teil der libc und bei Windows eine DLL. Praktisch alle Anwendungen, die Zugang zum Internet benötigen, benutzen die Socket-Schnittstelle.
• [K] Es reservierter Port ist nicht gleichbedeutend mit einen well-known Port. Die ersteren sind nach Unix-Tradition für den Administrator reserviert. Die letzteren sind wohlbekannten Diensten zugeordnet. Port 25 ist z.B. dem SMTP-Dienst zugeordnet. Will ein Netzwerkrechner einem anderen eine Mail schicken, kann er immer dessen Port 25 kontaktieren (ohne vorher über irgendeinen nichtlokalen Namensservice den Port herauszufinden).
• [K] „Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte definiert. So ist es beispielsweise möglich, dass ein Webserver auf einem Port mehr als eine Verbindung zu einem anderen Rechner geöffnet haben kann.“ Das Tupel (IP-Adresse(A), Port(A), IP-Adresse(B), Port(B)), wobei A und B die an der Verbindung beteiligten Rechner sind, definieren eine TCP-Verbindung.

• „Literatur“: Der Stevens ist absolut empfehlenswert. Vielleicht sollte man den an die erste Stelle der Literaturliste schieben.

tostro 20:07, 13. Feb 2006 (CET)

Noch eine Ergänzung von einem anonymen Leser :) Unter "Aufbau des TCP-Headers" ist das Feld "Window" extrem schlecht beschrieben. Ein Durch das Ack-Feld indiziertes Byte??? Also das sollte jmd. der sich auskennt dringend neu formulieren. Ansonst gefällt mir der Beitrag sehr gut.

Anonym: "HTTP-Protokoll" ist nicht ganz richtig, da das "P" schon für "Protocol" steht.

Gut, aber (noch) nicht exzellent!

Als Nicht-Experte, der sich derzeit mit TCP beschäftigen muss, habe ich den Artikel soeben sorgfältig gelesen. Auf den ersten Blick ein schöner Atikel -- man kann auch viel lernen. Einige Formulierungen erscheinen jedoch unpräzise, einige überflüssig, einige Begriffe werden nicht oder nicht vollständig erklärt. Exzellent heißt für mich: Viel besser geht es nicht. Diesen Artikel kann man jedoch durchaus noch verbessern, sofern man sich wirklich (mit TCP) auskennt. Gruß Stefan Salewski. 84.143.135.151 15:55, 14. Feb 2006 (CET)

Ich wurde soeben (23:00, 14. Feb 2006 (CET)) gebeten, etwas konkreter zu sein. Gut. Wie gesagt, ich bin kein Experte, aber gerade ich soll ja aus dem Artikel etwas lernen. (Ausserdem habe ich die Wikipedia bisher vorwiegend als passiver Konsument benutzt, daher bitte ich um etwas Milde bei formalen Fehlern.)

Könnte man den Artikel nicht etwas straffen? "Diese Verbindung kann in zwei Halbduplex-Verbindungen eingeteilt werden, wobei die Daten in Gegenrichtung zusätzliche Steuerungsinformationen enthalten." Was lerne ich aus diesem Satz? Die beiden Angaben in Klammern im ersten Abschnitt "(je nach Betriebssystem unterschiedlich)" und "(zum Beispiel Apache)" erscheinen mir überflüssig. Dritter Absatz: "Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte definiert. So ist es beispielsweise möglich, dass ein Webserver auf einem Port mehr als eine Verbindung zu einem anderen Rechner geöffnet haben kann." Der erste Satz ist knapp und präzise, aber der zweite "So..." hat sich mir nicht so recht erschlossen. "Ein Webserver, der seinen Dienst anbietet, generiert einen Endpunkt mit dem Port und seiner Adresse (er kann auch beliebige Adressen zulassen)." Der Inhalt der Klammer erschließt sich mir nicht. Vielleicht besser: Ein Webserver, der einen Dienst anbietet, generiert einen über Portnummer und IP-Adresse definierten Endpunkt. "Beim Aufbau einer TCP-Verbindung kommt der so genannte Drei-Wege-Handshake zum Einsatz. Der Rechner, der die Verbindung initiieren will, sendet dem anderen ein SYN-Paket mit einer Sequenznummer x. Es handelt sich also um ein Paket, dessen SYN-Bit im Paketkopf gesetzt ist (siehe TCP-Header). Die initiale Sequenznummer ist beliebig und wird vom jeweiligen Betriebssystem festgelegt." Der letzte Satz erscheint überflüssig und auch etwas widersprüchlich. Man kann doch auch sagen "Beim Aufbau einer TCP-Verbindung kommt der so genannte Drei-Wege-Handshake zum Einsatz. Der Rechner, der die Verbindung initiieren will, sendet dem anderen ein SYN-Paket mit einer WILLKÜRLICH GEWÄHLTEN Sequenznummer x..."

"Im Buffer ist der Datenblock, dieser wird in 5 Segmente aufgeteilt (siehe Abb. 6)." Der Satz ist nicht gerade schön, wieso gerade 5 Segmente, und sollte man im Deutschen statt Buffer nicht eher Puffer sagen? "Diese sind nicht geordnet, da im Internet jedes TCP-Segment ... " Besser: "Diese treffen in ungeordneter Reihenfolge beim Empfänger ein, da ..." Statt Checksumme sollte man vielleicht auch besser Prüfsumme sagen. "Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer ..." Was variiert wie? Absatz "Flusssteuerung". Habe ich leider nicht ganz verstanden. "Slow-Start. Der Algorithmus startet mit einem kleinen Zeitfenster von zwei MSS..." MSS ist doch keine Zeiteinheit, sondern eine bestimmte Anzahl von Bytes? "Das Wachstum des Fensters ist exponentiell, also erst langsam, dann schnell, daher der Name slow-start." Der Satz ist nicht gerade schön und nicht sehr informativ. Können wir ihn weglassen?

So, das wären meine Anmerkungen. Zu den technischen Einzelheiten kann ich mich mangels Kenntnis leider nicht äußern. Der englisch-sprachige Artikel enthält übrigens weitaus mehr Referenzen -- wenn sie gut sind sollte man sie vielleicht auch hier angeben.

Gruß Stefan Salewski 84.143.135.151 01:52, 15. Feb 2006 (CET)

Zeitfenster ist tatsächlich eine absolut falsche Übersetzung:

Das Wort Zeitfenster deutet an, dass dem Sender eine gewisse Zeit lang erlaubt wird, zu senden, und er danach nicht mehr senden darf (siehe TDMA) - was ganz und gar nicht der Fall ist.

Man könnte es höchstens als Pufferfenster oder so ähnlich bezeichnen (die Größe des Bereiches des Puffers vom ersten noch nicht bestätigten Byte bis zum letzten Byte, das von der Congestion Control her gesendet werden darf - also nichts mit Zeit)

Da mir aber auch kein allgemein üblicher Begriff dafür einfällt, erlaube ich mir mal, "Zeitfenster" durch "Fenster" zu ersetzen. 132.231.54.1 22:39, 13. Apr. 2007 (CEST)

Exzellenter Artikel?

Ich verstehe beim besten Willen nicht, warum dieser Artikel exzellent sein soll. Die Gliederung folgt keiner nachvollziehbaren Logik. So wird beispielsweise der Pseudoheader völlig aus dem Zusammenhang gerissen. Dementsprechend fehlt bei der ersten Erklärung der Checksumme auch der Hinweis darauf, daß diese über den Pseudoheader berechnet wird.

Auch sonst erscheint mir die Gliederung völlig willkürlich.

Paracetamol 18:21, 5. Feb 2006 (CET)

Ich finde man sollte sich auf wichtige Aspekte von TCP konzentrieren - Reno und Tahoe haben praktisch keine Bedeutung. --Str. 13:20, 29. Jul. 2009 (CEST)

Unübersichtlich + TCP-Header in extra Artikel

Die Seite ist sehr unübersichtlich und chaotisch aufgebaut; Es fehlt der Aufbau des Protokoll-Datagramms und die Beschreibung zu den einzelnen Feldern.

Der TCP-Header hat einen eigenen Artikel, wie ich gerade sehe. Das halte ich eigentlich nicht für sinnvoll. Es hätte hier, in einem besser strukturierten TCP-Artikel, seinen Platz, finde ich. --Elwood j blues 17:14, 27. Mär 2005 (CEST)

Ich habe die Übersicht im Abschnitt Datenübertragung leicht verbessert. Ist die Frage, ob man Details in eine extra Seiten auslagert, insbesondere der TCP-Header. Weil wenn ich allgemein wissen will, was TCP/IP ist oder wie es funktioniert, dann muss ich nicht erfahren welche Header-Felder mit wievielen Bits spezifiziert wurden. Andererseits folgt die Spezifikation des Header genau aus dieser Funktionalität. Jetzt ist der Header mal mit drin... --84.56.83.13 23:31, 16. Jan 2006 (CET)

Deutsche Übersetzung der RFC 793

Gibt es irgendwo im Web eine deutschsprachige Übersetzung des RFC-Textes zum TCP? -- WalterSpiegel 21:26, 28. Aug 2005 (CEST)

In einer Vorlesung wurde es an unserer Uni so beschrieben

[Bild:http://img74.imageshack.us/img74/7493/afilestreampv6.jpg] --141.3.146.45 12:44, 29. Jul. 2008 (CEST)

TCP-Header (Grafik)

Hallo! Ich habe mich mal ein bissi hingesetzt, und den Header in eine Grafik überführt. Ich wäre um eure Kritik (Meinung etc.) dankbar. --Wendelin 23:15, 11. Mai 2005 (CEST)

Problematik der Datenwiederholung

Dieser Abschnitt ist ungenau und teilweise falsch. Hier sollte Slow Start, Congestion Avoidance Schwellenwert und Phase erwähnt werden, in der das Staufenster nach einer RTT nicht verdoppelt sondern nur um eine MSS erhöht wird. Nach einem Paketverlust (Timeout) wird der Schwellenwert neu definiert (= 1/2 * letzte Fenstergröße) und der Slow Start beginnt erneut.

Zu nennen wäre zudem Fast Retransmit und Fast Recovery.

Empfangsfenster für Flußkontrolle.

Mir fehlt bei der Diskussion der Datenwiederholung auch die Nennung (Erläuterung und Problematik) des Begriffes "Denial of Service (DoS)"; respektive eine Verlinkung. Meines Wissens ist es definiert, wann der Dienst verweigert werden muß. Bitte hinzufügen. --Wendelin 13:58, 15. Mär 2005 (CET)

Ja, Staukontrolle (Slow Start und seine Freunde) muss auf jeden Fall erwähnt werden. Ich bin gegen einen eigenen "Slow Start" Artikel, den die gegenwärtige Verlinkung vorsieht. --Elwood j blues 16:55, 27. Mär 2005 (CEST)

Ich habe den Slow-Start Artikel wie vorgeschlagen modifiziert und in den TCP-Artikel integriert. --131.188.3.20 19:00, 16. Jan 2006 (CET)

Unter linux 2.6 ist TCP BIC und TCP CUBIC default, beides wird nirgends erwaehnt. Da linux weit verbreitet ist und das Verfahren Senderseitig im einsatz ist (wir ignorieren jetzt mal p2p filesharing) macht das ein wesentlicher Anteil am Datenfluss aus da wir viele Server im Netz haben die mit Linux laufen. Weiter finde ich den Artikel stark einseitig. RFC 2001 ist nicht mehr von Bedeutung und vermittelt im besten Fall noch grob die Konzepte die den modernen TCP implementierungen zugrundeliegen. Im Wesentlichen sollte da aber ein Bild rein wie hier zwei zu finden sind: http://www.hamilton.ie/net/tcp.htm alternativ hats auch gute dazu im CUBIC paper: "CUBIC: A new TCP-Friendly High-Speed TCP Variant" von Dept of Computer Science North Carolina Stat University dort bei 5.2 "Cubic in action" wo man sieht wie zwei TCP-streams die Bandbreite fair aufteilen. (nicht signierter Beitrag von 134.2.186.15 (Diskussion | Beiträge) 15:13, 27. Apr. 2009 (CEST))

paketorientiert

Was bitte hat UDP, was ja nur zu Transportschicht gehört, mit einem paketorientiertem Netzwerkkern zu tun? Das passt mMn nicht zusammen. UDP ist verbindungslos und TCP als Gegenstück dazu verbindungsorientiert, das hat jedoch nichts damit zu tun, ob ein Netzwerkkern leitungsvermittelt oder paketvermittelt ausfgebaut ist. MfG

UDP hat nichts mit paketorientiert zu tun, das ist völlig richtig. Es gibt halt immer wieder sprachliche Ungenauigkeiten bei Leuten, die mit englischer Fachliteratur umgehen. Sie lesen "packet" und übersetzen das einfach als "Paket", weil sie die spezifische deutsche Fachsprache für Kommunikation nicht gut genug kennen. Korrigiere es doch einfach. 213.6.50.126 00:25, 1. Mär 2005 (CET)

Fluss- und Staukontrolle

Dass und wie TCP das Sliding Window-Verfahren einsetzt, fehlt noch. --Elwood j blues 17:14, 27. Mär 2005 (CEST)

Ich habe zu diesem Thema einen "Stub" eingefügt, der natürlich alles andere als aufschlussreich ist. So bekommt man aber ein wenig mehr Struktur in den Artikel. Ggf. nach Belieben ergänzen, bitte. --Elwood j blues 18:24, 27. Mär 2005 (CEST)

Transmission Control Protocol, 17. Mai

• pro: durchaus umfassend. Jedoch könnte die Literatur zum Protokoll und die Erläuterung des Aufbauschemas ausführlicher sein. --Wendelin 21:42, 17. Mai 2005 (CEST)
• contra: der Artikel ist in seiner jetzigen Form zu fachlich. Wer kein Vorwissen mitbringt, der wird gar nichts verstehen. --Herr Schroeder 08:52, 19. Mai 2005 (CEST)
• contra Nur zwei Bücher unter Literatur, da fehlen ein paar Standardwerke (Databecka kann dafür vermutlich eher raus). An der Verständlichkeit des Artikels kann man noch arbeiten - er muss nicht für Oma verständlich sein, aber auch jemand, der sich bemüht, steigt nach kurzem Lesen aus. --Elian Φ 17:20, 19. Mai 2005 (CEST)
• contra Die TCP-Software ist eine Funktionssammlung zum Beispiel in der Winsock.dll oder im Kernel (je nach Betriebssytem unterschiedlich). Die Anwendung ist zum Beispiel ein Webbrowser oder ein Webserver (zum Beispiel Apache). – Ich denke nicht, dass explizit Dateien genannt werden müssen. Und wenn doch, bitte das zugehörige Betriebssystem dazu. Außerdem sollte der Artikel besser formuliert werden (hier: zum Beispiel in zwei Sätzen dreimal).
  

Während der Datenübertragungsphase (active open) sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch. – Die Datenübertragungsphase heißt nicht active open. active open ist, wenn ein Client-Prozess die Verbindung auf eigene Initiative hin öffnet, also ein SYN-Paket schickt.

Drei-Wege-Handshake – sollte man das vielleicht wie im englischen Three-Way-Handshake nennen?

Insgesamt bin ich der Meinung, dass der Artikel in Review sollte, und dann nochmal gründlich überarbeitet werden soll. Im aktuellen Zustand ist der Artikel oft zu unpräzise. --Ww 00:40, 22. Mai 2005 (CEST)

@Ww: Ich bin ganz deiner Meinung. Mir ist sowieso schleierhaft wieso ein halbfertiger Artikel als "Kandidat" gesetzt wurde. Man sollte den Artikel eher ins Review setzen. Ich habe nur 3 Bücher über TCP. Davon kann man getrost "1,5" vergessen. Es wäre schön, wenn mehr Leute an diesem Artikel mitarbeiten würden. - Appaloosa 01:37, 22. Mai 2005 (CEST)

Transmission Control Protocol, 21. Juni

aus dem Review:

• Dafür: Umfangreiche Erläuterung des Protokolls. -- Dishayloo [ +] 01:14, 21. Jun 2005 (CEST)
• contra: der Artikel ist für Laien nicht verständlich, dies sollte bei einem exzellenten Artikel aber der Fall sein. Außerdem enthält der Artikel Abschnitte, die doppelt vorkommen. fehlende Verknüpfung: RFC, Socket, Fullduplex/Halfduplex, Handshake, Paket. --Atamari 17:35, 21. Jun 2005 (CEST)

Für den Artikel TCP sind gute Netzwerkgrundkenntnisse Voraussetzung. Wenn man den Artikel für jeden Laien verständlich machen wollte, wäre der Artikel - übertrieben gesagt - mindestens 100 Seiten lang und 80 Seiten davon würden nicht TCP betreffen.

Dies betrifft auch naturwissenschaftliche Bereiche bei Wikipedia, wie zum Beispiel die Gentechnik oder die höhere Mathematik. Man kann höchstens per Links den Leser etwas helfen.

BtW: Der Artikel Überlagerungsempfänger ist zum Beispiel exzellent. Ich kann ihn ja mal meiner Mutter vorlegen und sie fragen, ob sie ihn verstanden hat. ;)

- MfG Appaloosa 00:33, 22. Jun 2005 (CEST)

Oh schön, eine Grundsatzdiskussion ;)! Nun kenne ich deine Mutter nicht (schönen Gruß unbekannterweise!), aber ich könnte mir vorstellen, dass sie nach Lektüre der Einleitung von Überlagerungsempfänger doch verstanden hat, worum es im Prinzip geht, warum es so etwas gibt, und dass sie sich selbst vermutlich nicht näher damit beschäftigen muss. Die Einleitung zu TCP lässt da zu wünschen übrig, weil sie mit jedem zweiten Wort, auch wenn's verlinkt ist, spezielles Vorwissen voraussetzt. Dazwischen gibt es dann Namen und Jahreszahlen, deren Relevanz für die Sache man an diesem Punkt nicht einordnen kann. Eine für den interessierten Laien verständliche Einleitung kann man über alles schreiben; ich sehe nicht ein, warum Naturwissenschaft und Technik da Sonderrechte haben sollen. Dass sich der Hauptteil dann eher an Eingeweihte richtet, geht in Ordnung. Mir gefällt der Artikel im Ganzen übrigens; daher: abwartend. T.a.k. 01:14, 22. Jun 2005 (CEST) Jetzt pro T.a.k. 00:24, 28. Jun 2005 (CEST)

• Abwartend: Ganz abgesehen von obiger Diskussion, müssten etwas mehr Fachbegriffe verlinkt werden. Es weiß ja z.B. nicht jeder automatisch, was eine DLL ist. Weitere Begriffe, die nicht verlinkt sind: Virtueller Kanal, Fullduplex, Winsock.dll beziehungsweise wsock32.dll,

SYN und ACK, Flags, Buffers. Gruß Boris Fernbacher 17:34, 23. Jun 2005 (CEST)

• pro habe etwas an der Einleitung gefeilt, als Referenz an alle Großmütter. @Ein Artikel kann trotzdem exzellent sein, auch wenn er in weiten Teilen Fachwissen voraussetzt.--Heliozentrik 19:03, 26. Jun 2005 (CEST)

• pro schöner Artikel :) -- da didi | Diskussion 18:18, 30. Jun 2005 (CEST)
• abwartend, mag sich noch jemand die rel. (optisch) unschönen Textblöcke ansehen? (... Wie kann man mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten versenden? Ganz einfach, man teilt die Daten auf (Segmentierung), fügt ...). Darkone (¿!) 1. Jul 2005 10:41 (CEST)
• pro - absolute Laienmeinung, aber wenn ich einen solchen Text schon versteh ... -- Achim Raschka 5. Jul 2005 08:31 (CEST)

• Abwartend - Der Artikel ist gut, aber sicher nicht exzellent.

• So fehlt z.B. in der Einleitung einer kurze Beschreibung der Eigenschaften des Kommunikationskanals (bi-direktional, full-duplex, reihenfolgeerhaltend, byte-orientiert, fehlerkompensierend, etc.)
• Bei der Geschichte fehlt ein Hinweis darauf, daß TCP und IP anfangs ein Protokoll waren
• Es fehlt ein Hinweis darauf, daß die überwältigende Mehrheit der Anwendungsprotokolle im Internet auf TCP aufbaut
• Der "Teardown" (Verbindungsabbau) ist ungenau beschrieben (FINs zählen wie SYNs eine ACK-Nummer)
• Die Beschreibung der TCP-Flags ist unglücklich/missverständlich
• Wenn schon TCP Vegas erwähnt wird, dann sollten auch TCP Reno und TCP Tahoe erwähnt werden
• Wo die "TCP-Software" steckt (DLL, etc.) ist nicht so wichtig, viel wichtiger ist wie man sie anspricht (=die Schnittstelle). Das sich hier die Berkeley Sockets API durchgesetzt hat (mit der man übrigens nicht nur TCP, UDP und IP ansprechen kann, sondern auch alle möglichen anderen Protokolle) ist sicherlich interessant. Es gibt aber auch andere APIs für TCP.
• Ein kurzer Hinweis auf die Sicherheit von TCP (Stichwort "session hijacking") fehlt
• Hinweis über die "Fairness" von TCP fehlt
• Vor- und Nachteile von TCP sollten beleuchtet werden -- beos 7. Jul 2005 12:26 (CEST)

Klammern und Exzellenz

In WP:WSIGA findet sich der Hinweis, dass man Bemerkungen in Klammern vermeiden solle; trotzdem enthält vor allem der Abschnitt Datenübertragung dieses exzellenten Artikels einige. Ist die Regel obsolet oder der Artikel verbesserungswürdig? --Ein anderer 10:52, 22. Jul 2005 (CEST)

Verbindungsaufbau und Abbau

Also die ersten zwei Sätze hier sind Käse: TCP bietet eine Ende-zu-Ende-Verbindung, im Gegensatz zu IP oder PPP, die eine Punkt-zu-Punkt- Verbindung bieten. Zu dem wird die Vollduplex-Verbindung in zwei Simplex-Verbindungen aufgeteilt, und nicht in zwei Halbduplex-Verbindungen. Das geht schließlich gar nicht. jungelbewohner 12. Okt 2005 15:15 (CEST)

Genau so sollte es da stehen, da hast du recht. Alles andere ist Unfug. --Elwood j blues 06:10, 13. Okt 2005 (CEST)

Ich hab mir eben die rfc793 mal angeschaut und dabei entdeckt, dass die Grafik zum Verbindungsabbau nicht ganz ok zu sein scheint: in der Grafik wird zum Einleiten des Abbaus ein einfaches FIN gesendet, in der entsprechenden Abb der RFC (Figure 13) aber ein FIN,ACK. Auch der weitere Verlauf ist etwas anders. Ich bin jetzt kein Experte, aber das ist doch ein Unterschied, der berücksichtigt werden sollte, oder? -- 10:41, 14.02.2006

Standard

Da steht, TCP wäre durch diverse RFCs standardisiert. TCP ist _nie_ standardisiert worden. RFC steht für request for comment. Auch wenn TCP inzwischen Quasistandard ist, sollte man ausdrücklich erwähnen, dass es eben nicht standardisiert ist. Sonst käme noch jemand auf die Idee, die ISO/OSI hätte tatsächlich einmal etwas sinnvolles standardisiert. braeutigam

Zur Definition von Standard siehe Standard, auch De-facto-Standard, Industriestandard. Von Quasistandard kann keine Rede sein. Die RFCs enthalten für TCP/IP Implementierungen gültige erforderlichen ("required") und empfohlenen ("recommended") Protokolleigenschaften und sind der allgemein akzeptierte Standard, auch wenn keine staatliche Standardisierungsinstitution dahintersteht. Die Frage ist, was du unter "standardisiert" verstehst bzw. missverstehst. --Hubi 11:58, 13. Mär 2006 (CET)

Ok, es ist ein De-Facto-Standard. Aber da der Begriff inzwischen sowieso fast immer fälschlicherweise als Synonym für Norm gebraucht wird, sollte man lieber De-Facto-Standard schreiben. Alles andere ist scheiße. --braeutigam

Exzellenter Artikel?

Also ich sehe da eine ganze Menge unverstaendlicher Dinge in dem Artikel. Fuer jemanden, der die Materie nicht versteht, ist das sicher ziemlich unangenehm beim Lesen.

"Ein Webserver, der seinen Dienst anbietet, generiert einen Endpunkt mit dem Port und seiner Adresse (er kann auch beliebige Adressen zulassen)."

Wieso zulassen? Und welche Adressen sind dann nicht zugelassen? Was passiert mit nicht zugelassenen Adressen? Ich verstehe nicht, wie das gemeint ist.

Ist damit vielleicht gemeint, dass man den Socket an ein bestimmtes Interface binden kann (bei Angabe einer IP) oder eben alle Interfaces bedienen moechte (bei INADDR_ANY).

"Die initiale Sequenznummer ist beliebig und wird vom jeweiligen Betriebssystem festgelegt."

Ich dachte, die Socket-Sachen macht auch winsock.dll. Und "fest" ist die ISN auch nicht. Sie wird von der TCP-Implementierung auf einen zufaelligen Wert gesetzt.

Ausserdem wird abwechselnd von TCP-Segment und TCP-Paket geschrieben. Zwischendrin sogar von TCP/IP-Paket.

"Damit die TCP-Software im Empfänger die Segmente wieder ordnen kann, ist jedes Segment "nummeriert" (die Segmente werden sozusagen gezählt). Bei der Zuordnung der Segmente wird die Sequenznummer herangezogen. Der Empfänger muss TCP-Segmente, die einwandfrei (Checksumme ist in Ordnung) angekommen sind, bestätigen."

Es werden nicht Semente nummeriert, sondern Oktetts. Die Squenznummer wird dabei nicht nur "herangezogen", sondern genutzt. (Herangezogen klingt, als wuerde noch irgendwas anderes verwendet werden.) Der Empfaenger darf auch nur die Segmente bestaetigen, die den bisher empfangenen Datenstrom lueckenlos ergaenzen und nicht einfach alle fehlerfreien. (Go-Back-N-Verhalten)

"Da die Anwendung Daten aus dem Buffer liest, ändert sich der Füllstand des Buffers ständig. Deshalb ist es notwendig den Datenfluss entsprechend dem Füllstand zu steuern."

Das ist doch keine Begruendung fuer eine Flusssteuerung! Der Grund fuer Flusssteuerung ist, dass der Empfaenger von Daten nicht unnoetig viel Daten zugeschickt bekommen will, die er dann evtl. verwerfen muss.

Dann wird sofort gleich zu "Congestion-Window" gegangen, ohne zu erklaeren, dass es sich hierbei um einen Mechanismus handelt, der "Verstopfungen im Netz" vermeiden soll.

(Flusssteuerung und Ueberlastkontrolle sind zwei unterschiedliche Aufgaben von TCP!)

"Wird ein Paketverlust festgestellt, so wählt man die Hälfte der noch unbestätigten Daten im Netz als geeignetes Zeitfenster für die Datenübertragung zwischen diesem Sender und diesem Empfänger über den benutzten Kanal."

Wie kann eine Datenmenge als Zeitfenster verwendet werden. Da stimmen doch die Masseinheiten gar nicht. Zeit wird in Sekunden gerechnet, Datenmenge in Bytes/Oktetts!

Der Artikel ist an vielen Stellen chaotisch und schwer zu verstehen. Es ist nicht klar, ob die Erklaerung nun Top-Down oder Bottom-Up erfolgt. Erst ist man allgemein, dann geht man in feine Details und wird dann doch wieder allgemein.

ChrisHuebsch 13:08, 13. Mär 2006 (CET)

Dem muss ich zustimmen, der Artikel ist furchtbar ! Stilistisch und sprachlich ist er IMHO grottenschlecht, und Luecken hat er dass ein ganzer Elefant durchmarschieren koennte.

Da fehlt ja die Haelfte:

* die meisten Sachen sind nicht zu Ende erklaert

* keinerlei Diskussion von Schwachstellen von TCP-Implementationen (z.B. die diversen Angriffsmoeglichkeiten auf schlechte Implementationen mittels SYN flood, X-mas Pakete u.ae.)

* keinerlei Diskussion von Schwachstellen in TCP selbst (z.B. FIN Angriffe auf langlebige Verbindungen, Stealth-Scans moeglich weil 3-Way-Handshake anstatt 4-Way-Handshake)

Von einem exzellenten Artikel erwarte ich deutlich mehr, IMHO verdient er noch nichtmal ein lesenswert.

--DarkDust 14:55, 13. Mär 2006 (CET)

Was auch noch nicht so ganz paßt: "TCP setzt in den meisten Fällen auf das IP (Internet-Protokoll) auf" Wann setzt es nicht auf IP auf? Ich kenne kein solches Beispiel, habe aber auch nur solides Grundwissen. Zumindest geht das aus dem Artikel nicht hervor. --Itangast 17:03, 13. Mär 2006 (CET)

Zustandsgraph

Für das zustandsbasierte Protokoll TCP fehl definitiv ein Zustandsdiagramm! Wie soll man sonst den Ablauf von Handshake und Abbau verstehen? Gimbal 18:28, 13. Mär 2006 (CET)

Bild 2 ist ein Zustandsdiagramm für eine Seite der TCP-Verbindun. Was meinst du?

ChrisHuebsch 09:35, 14. Mär 2006 (CET)

Ups. Alles klar. Das meinte ich. Gimbal 17:51, 18. Mär 2006 (CET)

Exzellente Artikel sehen anders aus

Es gibt sicher viel schlechtere Artikel. Ich schliesse mich aber der Meinung an, daß der Artikel gut, aber nicht sehr gut geschweige denn exzellent ist. Das hängt mit der Strukturierung zusammen; aber auch mit der Auslassung von Interpunktion (ich setze noch ein paar Kommata).

In einer Enzyklopädie sollte, zumindest in einem 'exzellenten' Artikel, all dies gewährleistet sein.

- Es gibt Wiederholungen innerhalb des Artikels (z.B. URG-Flag), die an nur einmal, dort aber konsequent,erklärt werden sollten.

- Für den 'normalen' Leser fehlen noch einige Links auf Fachbegriffe (Beispiel hiernach)

- Eine Checksumme kann man als Prüfsumme bezeichnen; einen Buffer als Puffer.

- "Gehen bei einer bestimmten Fenstergröße Pakete verloren, kann das festgestellt werden, wenn der Sender innerhalb einer bestimmten Zeit (Timeout) keine Bestätigung (ACK) erhält." -> Bin Laie, aber ich vermute, dass ein Timeout das Ereignis der Zeitüberschreitung selbst ist und nicht die dazu definierte Zeitspanne (?). Da ich es nicht genau weiß, unterlasse ich eine Änderung.

-"Ports sind 16-Bit-Zahlen und reichen von 0 bis 65535" -> Sollte es hier nicht besser z.B. heißen "Ports werden durch 16-Bit-Zahlen repräsentiert (oder auch: 'dargestellt'), und auf 16-Bit-Zahlen statt "und reichen von 0 bis 65535" ein Link auf '16 Bit' gesetzt werden?

- "Anwendungen, die diese Software häufig nutzen, sind zum Beispiel Webbrowser wie der Firefox und Webserver wie der Apache HTTP Server." -> Reicht es hier nicht aus, den Firefox und Apache auszusparen und Neutralität zu waren? Jedem seine Liebe zu Programmen mit offenem Quelltext, aber mit Hinblick auf die Marktdurchdringung bei Browsern wäre der MS IE sicher (immer noch) das Referenzprogramm für den Normalverbraucher.

Alles Gute.

Hmm, mir fehlt das wirklich grundlegende Detail, dass alle Client-Verbindungen gewöhnlich mit Port > 1023 ausgehen und dass auf vielen Systemen Services auf den well-known ports administrative Rechte zum Starten voraussetzen. ----Stefan.keller 22:12, 13. Mär 2006 (CET)

Abb. 1

Was soll mir diese Abbildung sagen? Das zwischen der Anwendung und der TCP-Schicht ein Puffer ist?! Betextet ist sie nicht, eine Referenz im Text gibts auch nicht (oder ich habs nicht gefunden) und besonders aussagekräftig find ich sie auch nicht. Schöner fände ich hier das OSI-Modell.. -cljk 22:53, 13. Mär 2006 (CET)

Bilder gelöscht

Maaan, da hat irgendwer Bilder gelöscht http://de.wikipedia.org/w/index.php?title=Transmission_Control_Protocol&diff=14614890&oldid=14614740

Wenn nicht schon 2 Nachbearbeitungen stattgefunden hätten, hätt ich schon nen Revert gemacht... cljk 23:05, 13. Mär 2006 (CET)

Hab sie wieder reingestellt... Was fuer mutige Helden es doch gibt. ChrisHuebsch 09:36, 14. Mär 2006 (CET)

Fenstermechanismus

Der Fenstermechanismus sollte auch rein. Könnte ich machen. Das Prinzip wird in den letzten Zeilen angeschnitten. Sollte für einen exzellenten Artikel rein. -- Arx 10:19, 27. Jun 2006 (CEST)

Abwahl-Diskussion

Diese Kandidatur läuft vom 14. Juni bis zum 4. Juli.

In der Lesenswert-Diskussion zu Simple Network Management Protocol kam die Frage auf, warum der Artikel exzellent ist ... nach Ansicht der Artikel-Diskussion von Transmission Control Protocol, wo bereits diverse andere diese Frage stellten, stelle ich den Artikel also zur Wiederwahl -- Sven-steffen arndt 15:07, 14. Jun 2006 (CEST)

•  Kontra In der Tat ist die Strktur des Artikels (wie hier an mehreren Stellen kritisiert) ziemlich dürftig. Vor allem wird der Laie in der ersten Erklärung gleich auf Voll- und Halfduplex verwiesen, es fehlt eine einfache, für den nicht-fachkundigen verstädnöiche Erklärung. Inhaltlich gibt der Artikel wohl durchaus ein Exzellent her, ist es in dieser Form aber leider nicht. · blane ( ♪♫♪ · ᾣ ) 16:23, 14. Jun 2006 (CEST)
•  Kontra Mit so viel Fachchinesisch auf einmal wurde ich in noch keiner einzigen Informatik-Vorlesung bombadiert. Meiner Meinung nach daher nicht einmal lesenswert. --Novil Ariandis 10:40, 15. Jun 2006 (CEST)
•  Pro - Der Artikel ist ausführlich und vollständig ohne bei den einzelnen Punkten zu sehr ins Detail zu gehen. Möglichkeiten zur Verbesserung der Verständlichkeit sind eher minimal. Man erhält einen guten Überblick darüber, was TCP alles kann und wie die Kommunikation mit diesem Protokoll funktioniert. Das die vielen Funktionen von TCP scheinbar einige hier überfordert, ist kein Grund was an dem Artikel selbst auszusetzen. Dabei werden die einzelnen Techniken jeweils ausführlich erklärt. Unter den Artikeln der Netzwerktechnik gehört dieser mit Sicherheit zu den Besten. --Stefan2 19:14, 15. Jun 2006 (CEST)

So so, indem ich das Fachchinesisch bemängelt habe, habe ich damit also gleichzeitig offenbart, dass ich geistig nicht in der Lage bin, TCP/IP zu verstehen... Wow, dazu fällt mir zwar einiges ein, aber ich sage es besser nicht. --Novil Ariandis 00:48, 16. Jun 2006 (CEST)

An Stefan2. Deine Art mit Kritik am Artikel umzugehen -> "Das die vielen Funktionen von TCP scheinbar einige hier überfordert, ist kein Grund was an dem Artikel selbst auszusetzen." und durch Mutmaßungen über die eventuelle Überforderung einzelner Leser darauf zu reagieren, halte ich nicht für sehr konstruktiv. Nebenbei ist es auch dem "persönlichen Klima" zwischen den einzelnen Autoren nicht gerade bekömmlich. Der Artikel ist ja gut ! Dennoch kann man einiges noch verständlicher und einfacher ausdrücken, ohne das Niveau fachlich zu senken. Ich habe im ersten Drittel des Artikels mal einige Veränderungen vorgenommen. Einen Waitstate kann man auch als Wartezyklus beschreiben. Zu RFC, Voll und Halbduplex habe ich kurze erklärende Nebensätze eingebaut. Ebenso ein kurzen Satz, wozu man überhaupt eine Sequenznummer braucht. Inkrementiert und dekrementiert durch erhöht und erniedrigt ersetzt. Bei der Windows-DLL und dem Kernel ist nun erwähnt, dass es sich um die Konzepte einzubindende Bibliotheksroutine versus Funktion im Systemkern handelt. Die Flags und den Buffer, deren Kenntnis wohl kaum zur Allgemeinbildung gehören, habe ich erklärt (die waren noch nicht mal verlinkt). Der Begriff Router war auch nicht verlinkt. Hoffe, du bist mit den Änderungen einverstanden. In der Weise kann man sicher am Rest des Artikels noch das ein oder andere klarer und nachvollziehbarer ausdrücken, bzw. einfacher ausdrücken. Gruß Boris Fernbacher 10:09, 16. Jun 2006 (CEST)

Sicherlich mag der Artikel durch seine Vielzahl an Informationen, für einige erst mal abschreckend wirken. Aber wenn man ihn sich genau durchließt, dann erkennt man, daß das Protokoll Punkt für Punkt ausführlich und verständlich erklärt wird und daß das ganz doch nicht so schlimm ist. Deshalb war meine Vermutung, daß eher die Fülle an Informationen hier einige zu einem negativem Votum bewegt. Wenn es anders ist, dann könnt ihr es meinetwegen schreiben, aber derartig aggressive und inhaltlose Kritik weise ich entschieden zurück. Ich habe nie jemand geistige Beschränktheit unterstellt und so was rein zu interpretieren gehört sich nicht. Wenn man anderer Meinung ist, dann braucht man nicht gleich unhöflich zu werden. An Boris Fernbacher: Ich habe nicht an dem Artikel mitgearbeitet und habe deshalb auch keine Probleme damit, wenn Sie etwas hinzufügen. Wenn Sie sich unsicher sind, dann empfehle ich es direkt auf der Diskussionsseite von TCP anzusprechen. --Stefan2 13:52, 16. Jun 2006 (CEST)

Ich wollte hier niemand beleidigen, und auch nicht unhöflich sein. Wenn es evtl. so rübergekommen ist, tut es mir leid. Also bleiben wir am besten locker. Gruß Boris Fernbacher 17:13, 16. Jun 2006 (CEST)

Tut mir auch leid. Ich hätte es dabei belassen sollen meinen Standpunkt zu verdeutlichen und nicht versuchen zurück zu schlagen. Ich hoffe das ganz hat sich damit erledigt. --Stefan2 18:56, 17. Jun 2006 (CEST)

*  Kontra geändert in  Neutral Siehe Begründungen von blane und Novil Ariandis. Habe den Artikel noch mal genauer gelesen -> War bei meinem Urteil wohl etwas zu streng. Habe einige Fachbegriffe im Text erklärt, so dass es hoffentlich laienverständlicher geworden ist. Gruß Boris Fernbacher 19:16, 15. Jun 2006 (CEST)

• Insgesamt  Pro. Es spricht deutlich für diesen Artikel, daß ich selbst als Laie diesen fast komplett verstanden habe. An der einen oder anderen Formulierung kann (und sollte!) man in Richtung "Verständnis" sicherlich noch feilen; aber eigentlich möchte ich noch auf ein ganz anderes Problem hinweisen: Wenn dieser Artikel wegen fehlender "Laienverständlichkeit" den Excellent-Status verliert und damit "nur" lesenswert wird, sollte das angesprochene Simple Network Management Protocol auf keinen Fall als "lesenwert" betitelt werden, da es da doch noch Welten zwischen gibt. Wir haben hier nun zwei rein "technische" (und zudem thematisch ähnliche) Artikel vor uns und sollten das auch Nutzen, um das Verhältniss zwischen "Fachgesimpel" und "Verständlichkeit" mal DEUTLICH zu klären. --Kantor.JH 22:26, 15. Jun 2006 (CEST)

hier geht es nur um diesen Artikel - Auswirkungen auf die Wahl anderer Artikel sollten keine Rolle spielen ... Sven-steffen arndt 23:11, 16. Jun 2006 (CEST)

Du hast natürlich recht! Aber dieser Artikel steht hier zur Wiederwahl, weil genau diese Frage/Diskussion/Argument bei den Lesenswerten aufkam. Von daher wollte ich die - ja auch bestehende - Problematik auch hier bei den Excellenten nicht unerwähnt lassen; Ich finde diesen Artikel in Sachen Laienverständlichkeit dennoch für außerordentlich gut. --Kantor.JH 23:22, 16. Jun 2006 (CEST)

Ein Objekt sollte aus seinen eigenen positiven/negativen Kriterien beurteilt werden. Ist TCP verständlich oder nicht ? Meine Meinung: Besser als mancher andere IT-Artikel, der riesige fachliche Lücken mit "dummem Fachgelaber" verbindet. Ich habe einiges im Artikel erklärt: DLL versus Kernel, Duplex und Halbduplex, und so weiter. Müsste reichen. Wenn zuviel Fachgelaber drin ist, dann svhreibt mich an. Ich bin der perfekte Vereinfacher (kann Sachen bis zur Unkenntlichkeit vereinfachen -> Bild-Zeitung) Gruß and good sunday Boris Fernbacher 23:57, 17. Jun 2006 (CEST)

Nachdem wir jetzt alle wissen, wo du arbeitest, nimm dir mal lieber SNMP vor - der hat das deutlich dringender nøtig ;-) --Kantor.JH 00:15, 18. Jun 2006 (CEST)

Meinst du mir macht der IT-Irrsinn noch Spaß ??? Warum schreibe ich über Musik ?? Weil sie immer noch wichtiger und schöner als PC-Probleme ist. Gruß Boris Fernbacher 03:24, 18. Jun 2006 (CEST)

 Kontra Der Schwerpunkt des Artikels liegt in der Beschreibung der Spezifikation des Protokolls. Aufgrund der grossen Bedeutung in einer Reihe unterschiedlicher Anwendungsgebiete (nicht nur Internet!) sollten hier aber einige weitere Aspekte erwähnt werden, u.a.:

• Geschichte: Wie kam es zur Entwicklung von TCP? Rolle der DARPA? Wesentliche Anforderungen an das Protokoll (Fehlertoleranz, ..).
• Schwächen / Nachteile des Protokolls (Overhead, Eignung für Echtzeitanwendungen, ..)? Welche Alternativen gibt es?
• Probleme von TCP bei Einsatz in Funknetzen

Der Artikel ist m.E. nicht ausgewogen.
@Kantor.JH: Der Vergleich mit SNMP hinkt. TCP hat eine ganz andere Bedeutung als SNMP, an einen Artikel über TCP stelle ich daher deutlich höhere Anforderungen.--Belsazar 01:23, 18. Jun 2006 (CEST)

Ich bezog mich auch nur auf die sprachliche Verstaendlichkeit. Die fachliche/inhaltliche Seite ueberlasse ich gerne (und zurecht) den Fachleuten. --Kantor.JH 12:39, 18. Jun 2006 (CEST)

contra Stimme Belsazar zu --Phrood 02:00, 18. Jun 2006 (CEST)

Man muss Belsazar in gewisser Weise recht geben. TCP is a little bit more important then SNMP or other protocols. Da kann man auch mehr erwarten. Trotzdem finde ich den Artikel nachvollziebar und verständlich. Gruß Boris Fernbacher 03:17, 18. Jun 2006 (CEST)

 Pro Als Laie habe ich beim zweimaligen Lesen (fast) alles verstanden. Wenn Fachleute konkrete Defekte sehen, sind Verbesserung immer möglich. Einzige Stellen für mich: was ist ein virtueller Kanal zwischen Endpunkten? und: Das SYN-Paket kommt für mich ein bißchen aus dem heiteren Himmel (ist wohl einfach eine Zeichenfolge, die einem Befehl entspricht, oder?)

PS: In der SNMP-Diskussion habe ich (angeregt von einer Bemerkung) keine für mich (Achtung: Laie) qualitativen Unterschiede zu diesem Artikel hier feststellen können und damit nicht eine neue Debatte dieses Artikels, sondern eine faire Bewertung von SNMP ermöglichen wollen, zumal die contra-Stimmen dort weitgehend keine konkreten Verbesserungsvorschläge einbringen.

@ Kantor: Wo sind die Welten zwischen den Artikeln? Hilf mit, SNMP zu verbessern! --Leumar01 16:01, 18. Jun 2006 (CEST)

 Pro Verständlich, nicht überfrachtet--84.56.8.177 19:38, 19. Jun 2006 (CEST)

 Kontra Bin ich der einzige, den Buffer (engl!) stört?? Nehmt doch Puffer (da geht übrigens auch der Redirect von Buffer hin), dann hat man das auch in deutsch. Auch wenn in der Informatik vieles nur englisch ist, ist Puffer doch verbreitet. Auch für die vielen anderen englischen Begirffe sollte man die entsprechende deutsche Übersetzung auch anbieten. Vor allem, wenn diese wie bei listen in deutschen Publikationen als lauschen durchaus verbreitet ist (für Port dageben gibt es meines Wissens keine verbreitete Übersetztung). Außerdem gebe ich Belsazar in allen Punkten Recht. -- FelixReimann 12:02, 21. Jun 2006 (CEST)

Buffer hab ich jetzt zwar korrigiert, doch dabei ist mir noch etwas aufgefallen: Der Absatz Aufbau und Funktion des TCP Pseudo-Headers sollte entweder weiter oben bei Checksum im Absatz Aufbau des TCP-Headers oder - wenn man bei Checksum darauf verweisst - unter dem sowieso noch weiter auszubauenden Kapitel Datenintegrität und Zuverlässigkeit eingebaut werden. So wie es jetzt ist, ist es für einen Laien denke ich nicht verständlich wo jetzt dieser Header eingesetzt wird. Insgesamt denke ich, der Artikel erklärt schon sehr gut RFC793. --FelixReimann 23:58, 28. Jun 2006 (CEST)

•  Kontra zu technisch, mMn für Laien nicht verständlich --Nrainer 14:14, 25. Jun 2006 (CEST)
•  Pro Sehe keinen Grund zur Abwahl. Knarf-bz 13:14, 3. Jul 2006 (CEST)

Slow Start

Ich glaube, der Abschnitt über Slow Start ist nicht ganz korrekt. Beispielsweise heisst der Algorithmus aus historischen Gründen "slow start" (weil er mit kleiner Fenstergröße anfängt), obwohl er eigentlich ein "quick start" Algo. ist.

In Computernetzwerke von Tanenbaum ISBN 3827370469 ist slowstart nur der Algorithmus der exponentiell schnell steigert, Der Treshold/Schwellwert kommt erst nachträglich dazu und gehört damit nicht zum Algorithmus. --Skurt 11:58, 8. Apr. 2008 (CEST)

Checksummenberechnung und Überprüfung

Habe diesen Abschnitt überarbeitet da er meiner Meinung nach nicht ganz korrekt oder zumindest missverständlich war: "Die Berechnung der Prüfsumme erfolgt durch Addition von 16 Bit-Werten im Einerkomplement." Die Summe wird nur durch Addition nach den Regeln des Einerkomplements (Überträge werden aufaddiert) und es wird nicht - wie man nach diesem Satz meinen könnte - von jedem Wert das Einerkomplement gebildet (vlg. auch RFC 793, Page 15, Checksum: "The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text."). Das Ergebnis ist bei der Überprüfung ist dann 0xFFFF (was beim Rechnen im Einerkomplement Null entsprich). -- Lukas227 23:14, 21. Okt. 2006 (CEST)

Du hast Recht, der Abschnitt war in Teilen schlichtweg falsch. Ich habe mich mal dranbegenben. --Gimbal 20:13, 6. Sep. 2008 (CEST)

Lesenswert-Kandidatur 31. 7. - 7. 8. 2006 (erfolgreich)

Das Transmission Control Protocol (TCP) ist eine Vereinbarung (Protokoll) darüber, auf welche Art und Weise Daten zwischen Computern ausgetauscht werden sollen. Alle Betriebssysteme moderner Computer beherrschen TCP und nutzen es für den Datenaustausch mit anderen Rechnern.

• pro - noch ein ehemaliger Exzellenter, der imho in den lesenswerten gut platziert wäre. -- Achim Raschka 07:33, 31. Jul 2006 (CEST)
•  Pro lesenswert, keine Frage. --Hufi ^Rating 08:19, 31. Jul 2006 (CEST)
•  Pro --62.225.62.65 13:29, 31. Jul 2006 (CEST)
•  Pro, auch für mich Laien ein verständlicher Artikel, der einen lesenswerten Einblick in die black box der Rechnerwelt erlaubt. --Leumar01 14:04, 31. Jul 2006 (CEST)
•  Pro für mich klar lesenswert. -- Uhr 18:18, 31. Jul 2006 (CEST)
•  Pro Hat mir schon einmal sehr genutzt. Eindeutig ausgereift. 84.149.216.191 13:25, 1. Aug 2006 (CEST)
•  Pro ...aber absolut! --Rohieb 会話 00:17, 2. Aug 2006 (CEST)
• pro schön geschrieben, gut illustriert, für mich klar lesenswert. JHeuser 17:23, 2. Aug 2006 (CEST)

Port

Die Behauptung im Abschnitt "Allgemeines", "Durch die Verwendung von Portnummern auf beiden Seiten ... dass ein Webserver auf einem Port gleichzeitig mehrere Verbindungen zu einem anderen Rechner geöffnet haben kann." stimmt so nicht. Der Server öffnet einen "Server-Port", auf dem er Verbindungen annimmt. Die erste Antwort teilt dann dem Client mit, auf welchem höhergelegenen Port seine Verbindung mit dem Server ist. Dass der Client ebenfalls Ports verwendet, liegt vielmehr daran, dass er sonst seine Anfragen nicht auseinander halten könnte. Dbu 10:31, 6. Feb. 2007 (CET)

Mit Verlaub, das stimmt nun gar nicht. Ein HTTP-Request beginnt damit, dass das Betreibssystem nach dem socket()-Aufruf auf dem Client (sagen wir, 10.11.12.13) für den Webbrowser einen Client-Port "aufmacht". (Eigentlich macht es ihn nicht richtig "auf", denn andere Rechner können sich nicht auf den Port verbinden.) Die Portnummer wird hierbei in der Regel vom Betriebssystem vergeben; dem Webbrowser ist dieser Client-Port herzlich egal. Jeder neu aufgemachte Client-Port kriegt eine eigene Portnummer. Mit dieser Client-Portnummer, sagen wir mal 12345, schickt der Client, sobald der Client sockaddr_in() und connect() macht, ein SYN-Paket an den Server, sagen wir 10.0.0.1, auf Port 80. Falls der Clientrechner 10.11.12.13 zufällig zum gleichen Zeitpunkt ebenfalls eine Verbindung zu 10.0.0.1 aufmacht (z.B. anderer Browser oder parallele Verbindung), dann kann man die beiden Verbindungen anhand der Client-Portnummern unterscheiden, weil die zweite Verbindung eine andere Client-Portnummer hat, z.B. 12346. Die Antwort des Servers teilt nun gar nichts bezüglich der Ports mit -- der Server schickt sein SYN-ACK an 10.11.12.13, Port 12345 (erste Verbindung) bzw. an Port 12346 (zweite Verbindung) zurück, weil es von dort kam. Er hat keine andere Wahl; alles andere würde zu einem RST führen (oder von der Firewall ignoriert).

Fassen wir nochmal zusammen: wir haben zwei Verbindungen (10.11.12.13, 12345 ↔ 10.0.0.1, 80) und (10.11.12.13, 12346 ↔ 10.0.0.1, 80). Das einzige, worin sie sich unterscheiden, ist die Nummer des Client-Ports. --Wutzofant (✉✍) 15:33, 6. Feb. 2007 (CET)

Alles leicht vereinfacht und verständlich. Hier könnte man aber auch schon auf (uncompleted und completed) Pufferung und der Weiterleitung eingehen. Das möchte ich aber nun den Fachleuten überlassen.... Dies habe ich in einem englischsprachigen Fachbuch(Titel: ???)mal gelesen. wh..09.11.2007

Korrektur von Slow Start

Ich habe die Beschreibung von Slow Start überarbeitet. Dort wurde beschrieben, dass sich das Congestion Window für jedes ACK verdoppelt. Das ist meines Wissens falsch. Für jedes ACK wird es nur um eine MSS erhöht und verdoppelt sich damit einmal pro Roundtrip Zeit. (Näheres in in RFC 2581)

Antwort--Nickson86 18:02, 18. Jun. 2010 (CEST): Richtig und falsch. Richtig: Congestion Window wird für jedes ACK um eine MSS erhöht. Falsch: Pro RTT verdoppelt sich das Congestion Window trotzdem, denn es kommen ja mehrere ACKs/RTT an und für jedes wird um ein MSS erhöht. (ist an sich im Text mit Beispiel recht gut beschrieben)

Der Drei-Wege-Handshake

Ich persönlich finde "Drei-Wege-Handshake" ein unschönes Wort. Wird das im deutschen offiziell so genannt? In der Mathematik bin ich schon öfters Bezeichnungen begegnet, die im deutschen als "...-fach" übersetzt werden. Demnach wäre mein Vorschlag hierfür: "Der dreifache Handshake" Gruss, --Chiccodoro 15:56, 1. Mai 2007 (CEST)

Ist unschoen, aber ein gebraeuchlicher Fachbegriff. "Dreifacher Handshake" oder "Dreifach-Handshake" hab ich noch nie gehoert und klingt, ehrlich gesagt, fast noch gruseliger. Tut mir leid, das so hart sagen zu muessen... --Wutzofant (✉✍) 16:37, 1. Mai 2007 (CEST)

Beispiel einer TCP-/IP-Datenübertragung

Transmission Control Protocol #Beispiel einer TCP-/IP-Datenübertragung

Im Artikel steht:

"Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen. Fehlt zum Beispiel das TCP-Segment 3, weil es verlorengegangen ist, so kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente."

Ich habe aus anderer Quelle folgende Informationen:

Geht wie im obigen Bsp. das Segment 3 verloren, sendet der Empfänger nur eine Bestätigung für die erhaltenen 2. Daraufhin schickt der Sender das Segment 3 und auch die folgenden (4 und 5 hier im Bsp.) Segmente erneut, weil nur die Segmente 1 und 2 bestätigt wurden. Das erscheint mir logischer, weil es doch eine verbindungsorientierte Übertragung ist und diese von der Reihenfolge, in der die Segmente empfangen werden abhängig ist. Der Timer kommt mMn zum Einsatz, wenn gar keine Bestätigung vom Empfänger erfolgt.

Oder verstehe ich hier etwas falsch? PS: Ich vergas meine Signatur: --84.156.57.211 14:46, 20. Mär. 2008 (CET)

Gute Frage, würde mich auch interessieren. --84.156.53.32 15:41, 25. Mär. 2008 (CET)

Das ist wieder mal ein Implementierungsdetail. Der Sender erhält Bestätigungen für sicher empfangene Daten, die er also nicht mehr vorhalten muß. Wie er genau mit ausbleibenden Bestätigungen umgeht, ist ihm überlassen. Er kann, wie im Artikel geschrieben, nur das erste fehlende Packet neu verschicken, er kann aber auch gleich das gesamte Sliding-Window ab dort neu versenden. Netzlasttechnisch ist in jedem Fall erste Variabte besser:

1. Ging das Packet nur zufällig verloren (Bitübertragungsfehler -> Prüfsumme falsch -> Packet wird gedroppt), dann braucht auch nur das eine neu übertragen zu werden.
2. Ging das Packet wegen der Überlastung eines Routers verloren, dann sollte man möglichst wenig Zusatzlast über diesen Router schicken, um eine weitere Überlastung zu vermeiden.

Insbesondere auch, wenn man geringen Upload hat (ADSL) dürfte es sinnvoller sein, lieber erstmal nur ein Packet neu zu senden, in der Hoffnung, daß dann gleich für den gesamten Rest ein ACK rein kommt. Aber wie gesagt: Das ist ein Implementierungsdetail, das vom RFC nicht exakt vorgeschrieben ist (es spielt für die Funktion von TCP/IP ja auch keine Rolle).

Netzwerk vs. Netz

siehe Diskussion:Internet_Protocol#Netzwerk_vs._Netz (Der vorstehende, nicht signierte Beitrag stammt von Kockster (Diskussion • Beiträge) 19:56, 7. Jul. 2008 (CEST))

1. Ersetzen Sie in dem Artikel Netzerk durch Netz. DIN kennt nur in diesem Zusammenhang Netz. Es wird viel Arbeit und Zeit beim DIN investiert, um eine Arbeitsgruppe mit dem Thema Begriffe der Informationstechnik zu normieren. Die Iustrie, Hochschulen und Verbände sind in diese Arbeit beteiligt. Siehe auch o.a. Artikel.
2. Im ersten Bild im TCP/IP Protokollstapel (siehe Artikel zu IP) gibt es keine Vermittlungsschicht. Hier gibt es nur die Internetschicht. Wer ist der, der meint hier die Rechte zur btimmung er Begriffe zu haben?
3. Anerkannte Kenner der Deutschen Sprache geben uns ihre Hilfe. Warum wird sie bei WIKI nicht angenommen?

Referenz

• [1] Begriff Netz versus Netzwerk

Wolfgang (Der vorstehende, falsch signierte Beitrag stammt von 84.160.251.64 (Diskussion • Beiträge) 20:05, 10. Jul. 2008 (CEST))

Bitte hier weiter diskutieren. Danke --M.L 17:01, 12. Jul. 2008 (CEST)

Acknowledgment Number (Quittierungsnummer)

Sie gibt die Sequenznummer an, die der Empfänger dieses TCP-Segmentes als nächstes erwartet. Sie ist nur gültig, falls das ACK-Flag gesetzt ist.

Meiner Meinung nach müßte es lauten:

Sie gibt die Sequenznummer an, die der Sender dieses TCP-Segmentes als nächstes erwartet. Sie ist nur gültig, falls das ACK-Flag gesetzt ist.

(Also der Sender sagt dem Empfänger was der Sender als Nächstes erwartet. Der Sender sagt dem Empfänger nicht, was der Empfänger erwartet.) (nicht signierter Beitrag von 139.18.13.71 (Diskussion | Beiträge) 17:21, 7. Jul 2009 (CEST))

Keine Datagramme?

Es wird erwähnt, dass TCP keine Datagramme hat sondern nur einen Datenstrom, kennt sich jemand gut genug mit TCP aus um sagen zu können, dass es wirklich KEINE Datagramme sind die versendet werden ?! (nicht signierter Beitrag von 85.183.18.196 (Diskussion | Beiträge) 11:28, 19. Okt. 2009 (CEST))

Überlastabwehr etc.

Man sendet nicht vorsorglich Duplikate, um Paketverluste in drahtlosen Netzen auszugleichen, denn damit werden das Kernnetz belastet und die TCP-Überlaststeuerung ausgehebelt. Kompletter Unsinn, so etwas da reinzusetzen. Da war wohl wieder ein "Fachmann" am Werk.

Ich finde es nicht in Ordnung, in einem fremden Text einzelne Worte zu ändern, die den Sinn des Textes entstellen oder gar verdrehen. Beim Kapitel "Überlastabwehr als Forschungsfeld", das ich vor Jahren zum TCP-Artikel beigetragen habe, sind einige Stellen geändert worden, die den ursprünglichen Text nicht verbessert haben, sondern nur krude oder unausgereifte Ideen hinzugefügt haben. Schlimm!

Da wird mit Begriffen um sich geworfen, z.B. ausgelastet (ist doch gut!!) anstelle von überlastet, Datenstau anstelle von Überlast (das ist etwas ganz anderes!), Senderate (gibt es bei TCP nicht!!!), und dann noch in merkwürdigem Zusammenhang. Grausam.

Ich erkenne meinen alten Text nicht wieder. Und besser ist da gar nichts geworden. (nicht signierter Beitrag von 80.187.103.227 (Diskussion | Beiträge) 23:20, 2. Apr. 2010 (CEST))

Grund für Segmentierung

In dem Artikel geht überhaupt nicht hervor, wieso sich TCP überhaupt um die MTU kümmern sollte. Die MTU ist an die physische Schicht gebunden und wird bereits durch IP komplett abgedeckt. Falls ein Datagram an IP übermittelt wird, fragmentiert es dieses und schickt zwei Fragmente an das Ziel. Nun kommt TCP ins Spiel: da es eine kontrollierte/gesicherte Verbindung darstellt, muss es auch über die Fragmente bescheid wissen, die eventuell verloren gehen können. IP ist nicht in der Lage festzustellen, ob Datagramme verloren gingen oder nicht, dafür ist die Transportschicht zuständig. Daher werden die MSS ausgehandelt, damit immer genau ein TCP-Paket in ein IP-Datagram passt, so dass die Gegenstelle anhand der Segmentierungsnummer erkennt, ob ein Paket fehlt oder nicht. Dieses Verhalten wird auch eindeutig im RFC 879 beschrieben. Dies ist der einzige Grund, wieso eine Art 1:1-Beziehung zwischen TCP-Paket und IP-Datagram besteht. (nicht signierter Beitrag von 195.13.40.237 (Diskussion | Beiträge) 09:48, 19. Apr. 2010 (CEST))

Für IPv4 hast Du recht, aber spätestens mit IPv6 ist das mit der Fragmentierung eh so eine Sache: Ein zu großes v6-Paket wird nämlich einfach weggeschmissen :-) vgl. IPv6 und Path MTU Discovery. --Wutzofant (grunz) 18:10, 19. Apr. 2010 (CEST)

TCP-Pseudo-Header (Text)

Der Teil "...Anteilen eines TCP-Pakets und Teilen des darin eingekapselten IP-Headers..." des ersten Satzes ist inhaltlich falsch. In ein TCP-Packet ist kein IP-Header eingekapselt, sondern das TCP-Packet ist in einem IP-Frame enthalten.

Gruß, Marko 14:00, 13.11.2008 (falsch signierter und nicht mit der WP-gemäßen Zeitangabe versehener Beitrag von 160.45.112.100 (Diskussion | Beiträge) 14:01, 13. Nov. 2008 (CET))

Geschichtliches

Ein bisschen ueber die Geschichte und Entwicklung von TCP fehlt noch. (nicht signierter Beitrag von 217.233.205.88 (Diskussion | Beiträge) 14:48, 16. Dez. 2004 (CET))

Geschichtliches ist tatsächlich etwas mager. Die Recherche zu den Anfängen aber auch nicht einfach. Mehr zu den Ideen und Rahmenbedingungen der Entwicklung würde ich mir wünschen, wobei vielleicht auch ein Hinweis auf http://www.ietf.org/rfc/rfc675.txt helfen würde. (nicht signierter Beitrag von 130.149.147.22 (Diskussion | Beiträge) 13:34, 10. Jul. 2006 (CEST))

Falscher Teilsatz

Der Teilsatz: "... Data Layer (beim Ethernet das statische MAC Protokoll)" ist inhaltlich falsch. Richtig: Nachzulesen unter den Stichworten LLC, MAC und Ethernet. (nicht signierter Beitrag von 217.231.217.230 (Diskussion | Beiträge) 22:47, 18. Mär. 2005 (CET))

2 inhaltliche Fragen zur Datenübertragung

1) im Teil Datenübertragung > Aufteilen der Anwendungsdaten auf TCP/IP-Pakete:

"Wie kann man mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten versenden? Ganz einfach, man teilt die Daten auf mehrere Pakete auf, fügt einen TCP-Header hinzu und versendet die TCP-Segmente, der Vorgang heißt Segmentierung. Im Buffer ist der Datenblock, dieser wird in 5 Segmente aufgeteilt (siehe Abb. 6)."

=> Um 10KByte Daten in einem 1460 Nutzdatenfeld zu versenden braucht man aber doch mind. 7 Segmente, oder? Vorschlag: ändern der 10KByte in 7KByte.

2) ebenfalls im Teil Datenübertragung > Beispiel einer TCP/IP Datenübertragung:

"Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt einen Timer (RTT)."

=> RTT wird auf Round Trip Time verlinkt. Sollte da nicht eher "Retransmission Timer" stehen? Könnte mir zwar vorstellen, dass die RTT zur Berechnung des "Retransmission Timers" herangezogen wird, sie wird jedoch wohl kaum identisch sein, oder?

Gruß, Jonas

ps: das nächste Mal schaue ich in den entsprechenden RFCs nach, versprochen! ;-) (nicht signierter Beitrag von 217.190.63.205 (Diskussion | Beiträge) 09:43, 26. Feb. 2006 (CET))

Ziemlich unverständlich

Also ich finde das ganze viiiiel zu kompliziert. (nicht signierter Beitrag von 212.144.198.111 (Diskussion | Beiträge) 12:27, 7. Mai 2006 (CEST))

Net schlecht

Dieser Artikel enthält so ungefähr das, was man in diversen online tutorials wiederfindet. Gut finde ich das vermittelte Wissen über den Verbindungsaufbau, den Verbindungsabbau sowie der Datenübertragung. Ich wühle jetzt schon ne ganze Weile im Internet und versuche mehr über die Datentypen, die bei den, im RFC793, aufgeführten Funktionen OPEN, SEND, RECEIVE, etc. verwendet werden, herauszufinden. Bisher leider Fehlanzeige. Ich bin auf den etwas älteren RFC675 gestossen, allerdings enthält er zu viele veraltete Informationen, um ihn als Referenz zu nutzen zu können (auch wenn er einige Typen aufzählt und Flow Charts der einzelnen Funktionen darstellt). Solche Dinge fehlen eventuell noch in diesem Artikel. Leider gibt es von meiner Seite aus noch zu viele ungeklärte Fragen um etwas in dieser Richtung zu verfassen.

Gruss,

Markus (nicht signierter Beitrag von 62.145.161.122 (Diskussion | Beiträge) 16:46, 15. Mai 2006 (CEST))

Fehlende CWR und ECE flags

In der deutschen Wikipedia fehlen bei der Beschreibung des TCP-Headers die in RFC 3168 neu dazugekommenen CWR und ECE flags/control bits. In der englischen Wikipedia sind diese aber schon vorhanden: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure (nicht signierter Beitrag von 85.124.188.36 (Diskussion | Beiträge) 09:04, 16. Jan. 2008 (CET))

Abb. 9 (nicht beschriftet) zu "Slow Start und Congestion Avoidance"

In der Abbildung von Thomaas wird der Schwellenwert (Slow-Start-Threshold) bei einem Timeout nicht wie im Text richtig beschrieben um "...die Hälfte des alten Congestion Windows herabgesetzt..." (wäre dann auf ca. 10,5 und nicht auf 8) sondern um die Hälfte des alten Schwellenwertes. Dies führte zumindest bei mir zu einiger Verwirrung, denn so würde der Schwellenwert ja bei jedem Timeout um die Hälfte sinken und gegen Null gehen. --Nickson86 18:02, 18. Jun. 2010 (CEST)

Ist mir eben auch aufgefallen, die berechnung im Bild ist definitiv falsch. Metallicum 13:44, 14. Feb. 2011 (CET)

Auswertung KALP - Kandidatur vom 13. Mai bis 10. Juni 2011

Die Diskussionsseite zeigt viele Fehler auf, aber niemand kümmert sich um die Behebung. 93.196.59.109 10:42, 13. Mai 2011 (CEST)

Hallo IP (bzw. abgemeldeter Benutzer), würdest du bitte die potenziellen Abwahlgründe inhaltlich hier darlegen und konkrete Probleme benennen, danke -- Achim Raschka 10:47, 13. Mai 2011 (CEST)

Auf Diskussion:Transmission Control Protocol#Überarbeiten stehen einige Argumente. Anscheinend ist der Artikel fachlich falsch. -- Prince Kassad 21:02, 13. Mai 2011 (CEST)

Im Archiv sind noch mehr - unter anderem wird bemängelt, dass einige Änderungen den Artikel verschlechtert haben. Aufgrund der praktisch fehlenden Einzelnachweise sind die Bemängelten Angaben auch schwer nachvollziehbar.

Wenn es sich nur um "Verschlimmbesserungen" der letzten Jahre handelt, wäre dann ein Zurücksetzen auf eine ältere Version vielleicht eine Alternative?

Der Artikel wurde wohl 2005 oder früher exzellent gewählt (Diskussion fehlt im Archiv) und dann auf lesenswert runtergestuft, nachdem der Exzellenz-Status mehrere Male in Frage gestellt wurde.

Das bedeutet wohl, dass es keine Version gibt, auf die es sich anbieten würde zurückzugehen.

Hm.. und direkt so fällt mir auf, dass es keinen Geschichtsabschnitt gibt, dafür aber die Geschichte in der Einleitung abgehandelt wird. Iridos 14:53, 15. Mai 2011 (CEST)

2005 lief das alles noch etwas anders mit Review und Abstimmungsdiskussion, anbei der Diff-Link zum Zeitpunkt der Auswertung bzw. Entfernung vom Vorläufer der KALP-Seite [2]. Entsprechende Übertragung auf die Artikel-Disk hier [3]. Die scheinbaren Streichungen dürften ein Tippfehler im End-Tag sein und ursprünglich nur das Wort "abwartend". Die Kritik an der Verständlichkeit war damals schon ausformuliert und wurde zwischenzeitlich mehrfach erwähnt. Die Diskussion ist also im Archiv, nur eben nicht eindeutig als solche gekennzeichnet. Wenn der Artikel inzwischen scheinbar inhaltlich an mehreren Stellen fehlerhaft ist, in weiten Teilen selbst für Experten nur schwer verständlich und sich keiner so richig darum kümmern kann oder mag, was spricht denn dann noch für "lesenswert" als Auszeichnung? Insofern konsequenterweise vorläufig  keine Auszeichnung, nach einer entsprechenden Überarbeitung dann gerne Neubewertung und Wiederwahl. --Vux 21:04, 3. Jun. 2011 (CEST)

Ich würde den Artikel auch nicht als exzellent einstufen. Der sprachliche Stil ist sehr "informatiklastig", für Außenstehende fast nicht zu verstehen. Sogar für mich als Informatiker ist er wahnsinnig schwer zu lesen. --81.189.240.216 22:17, 31. Mai 2011 (CEST)

 keine Auszeichnung Fachsprache ist ja ok aber das ist hier eindeutig zu viel des Guten. Obwohl ich gewisse Informatik-Grundkenntnisse habe, bin ich ziemlich bald nach der Einleitung geistig ausgestiegen und habe den roten Faden auch nicht wiedergefunden. So leid es mir tut, aber in dieser Version noch nicht mal ein lesenswert. Das ist wesentlich mehr als nur "im Detail für Laien unverständlich" auch wenn ich natürlich berücksichtige, dass der Artikel wohl kaum vollständig Oma-tauglich gemacht werden kann. --Tavok 18:52, 6. Jun. 2011 (CEST)

Ein Protokoll der TCP/IP-Architektur lässt sich nur mittels der dazu gehörenden Fachsprache im Detail schildern. Bei diesem Artikel wurde versucht, die Einleitung Oma-tauglich zu machen, und prompt taugt der Einleitungstext nichts mehr. Ich will nur mal zur Einleitung Stellung nehmen: Ein Satz wie „Das Protokoll (gemeint ist TCP) ist ein ... Transportprotokoll...“ ist einfach nur hilflos, er erklärt garnichts. Zumal Transportprotokoll auf Netzwerkprotokoll verlinkt wird, einen Artikel, in dem nicht steht, was mit "Transport" gemeint ist. Dass TCP "paketvermittelnd" sei, ist so formuliert erstmal sogar falsch, weil ein Protokoll nie vermittelt. Ich kann mir vorstellen, was der Autor damit sagen will, aber dieses Adjektiv braucht man in dem Artikel überhaupt nicht, weil es zum IP-Protokoll gehört. "Verbindungsorientiert" ist dann auch eine nicht weiter erläuterte Beschreibung: wozu ist das Feature denn gut, kommunizierende Prozesse auf zwei Endsystemen Verbindungen auf- und abbauen zu lassen? Wieso kann man das brauchen? Wird nicht plausibel gemacht. „Angenehme Eigenschaften: Datenübertragung in beide Richtungen“, aha. Dazu brauche ich kein TCP, das geht doch schon mit IP. Im Grunde zeigt die Einleitung, dass der Autor die Grundidee von TCP nicht verstanden hat. Oder die Einleitung war mal gut, ist aber durch viele wohlmeinende Halbwisser heruntergeschrieben worden. In fast jedem Satz der Einleitung hätte ich was zu verbessern. Die Einleitung sollte aus meiner Sicht ganz einfach nur die Eigenschaften erwähnen, die TCP durch eigene Maßnahmen realisiert, weil sie dem IP fehlen. Genau das sollte in der Einleitung stehen. Das ist auch relativ schnell und kurz gesagt: wenn Prozesse mithilfe von IP miteinander kommunizieren, können bestimmte Fehler in der Datenübertragung nicht erkannt werden, weil IP dafür keine Mechanismen bietet. Mit TCP werden nun bestimmte Mechanismen hinzugefügt: Der Verlust, die Vertauschung und die Verdopplung von IP-Paketen können von IP nicht, aber mit den Mechanismen von TCP erkannt und korrigiert werden. Dazu bietet TCP noch eine Flußkontrolle zwischen kommunizierenden Prozessen. Mit ihr können die kommunizierenden Prozesse regeln, dass der Sender die Daten nicht schneller sendet, als der Empfänger sie empfangen kann. Durch diese Mechanismen von Fehlerkorrektur und Regelung wird die Zuverlässigkeit der Kommunikation erhöht. Das wäre mE eine kurze Funktionsbeschreibung der wesentlichen Eigenschaften von TCP für die Einleitung. Ob der Rest des Artikels im Detail richtig ist, habe ich garnicht mehr gecheckt. Der braucht erstmal eine passable Einleitung.Potamo 00:10, 7. Jun. 2011 (CEST)

Oder kurz und laienverständlich: von zwei herzlich wenig koordinierten Monologen zum tatsächlichen Dialog. —mnh·∇· 02:34, 7. Jun. 2011 (CEST)

Status Lesenswerter Artikel abgewählt - eindeutiger Kandidaturverlauf. Martin Bahmann 21:59, 10. Jun. 2011 (CEST)

Überarbeiten

Der Artikel stimmt vorne und hinten nicht, hab einiges ausgebügelt aber nicht für alles Zeit:

• 10kb mit 1460mtu wären 7 Pakete, nicht 5 wie im Artikel erwähnt. Es werden auch alle Pakete verschickt und nicht nur 3.
• Abb 1 war falsch, hab sie entfernt und den Autor kontaktiert. (Gibt es eigentlich eine gute Lösung Abbildungen zu Nummerieren?)
• Umgangssprache rausgemacht, feste Leerzeichen rein
• Abschnitt "Problematik der Datenwiederholung" hochgesetzt, passt besser als Einführung als nach der detaillierten Erklärung davor.

• Auch der Slow Start wird falsch beschrieben. Denn der Slow Start ist ja einer, der exponenziell ansteigt. Somit ist er eigentlich garnicht langsmal. Slow Start heißt das ganze nur, da es historisch bedingt noch aggresivere Startmethoden gab. Der Additive Increse ist der eigentlich "slow"e. --88.68.0.157 21:18, 20. Jul. 2011 (CEST)

Todo:

• mehr Quellen
• Abb 8a und 8b fehlen, werden im Artikel aber erwähnt
• Die Portnummern-Vergabe von der IANA ist falsch beschrieben, richtig dort: http://www.iana.org/assignments/port-numbers
• die Abschnitte "Fast-Retransmit und Fast-Recovery", "TCP-Tahoe und TCP-Reno", und "Überlaststeuerung als Forschungsfeld" überschneiden sich inhaltlich und enthalten jede Menge Geschwurbel ohne Quellen. (nicht signierter Beitrag von Gnom451 (Diskussion | Beiträge) 18:34, 10. Feb. 2011 (CET))
• "Da das Options-Feld in der Regel nicht genutzt wird, hat ein typischer Header eine Größe von 20 Byte". Der Satz ist komplett falsch. Das Option-Feld wird *immer* genutzt (SACK, Timestamps, Window Scaling,...) (nicht signierter Beitrag von 77.109.98.112 (Diskussion) 10:32, 13. Mai 2011 (CEST))

Zur Qualität des TCP-Artikels

Ein prinzipieller Einwand: Protokolle wie TCP sind kompliziert. Geht man ins Detail, werden vermutlich 99,9 % aller Informatiker, selbst die, die etwas im Studium über Rechnernetze gehört haben, abgehängt. Natürlich kann TCP Fehler korrigieren, jedoch nicht alle (Arten). Insofern sind einleitende Worte mit gewissen Eigenschaften von TCP sofort wieder angreifbar, da sie zu vereinfachend sind. Und es stimmt: Halbwissende haben den Artikel gewaltig verschlechtert. Dazu trägt auch bei, dass viele Fachbücher über TCP die Dinge vereinfacht oder schlichtweg falsch darstellen. Man muss schon die RFCs lesen, auf dem aktuellen Stand der Forschung sein, um halbwegs mitschreiben zu können. Bei bestimmten Themen kommt ein Lexikon an seine Grenzen. Wikipedia geht es nicht anders!

M. Savoric (nicht signierter Beitrag von 80.187.96.223 (Diskussion) 21:00, 13. Aug. 2011 (CEST))

Autoren die für ihre "Fachbücher" Wikipedia zitieren würde ich aber meiden. Wer sich auf bewährte Quellen wie Tanenbaum bezieht, ist auf der relativ sicheren Seite. Du hast aber im Kern recht, das hier bei Wikipedia soll nur ein Einstieg in die Lektüre sein. Die Kunst ist die, diesen Einstieg korrekt zu formulieren. (nicht signierter Beitrag von Webskipper (Diskussion | Beiträge) 15:36, 11. Jun. 2013 (CEST))

Unvollständiger TCP-Header

Unter Transmission_Control_Protocol#Erläuterung wird ein TCP-Header dargestellt und erläutert, welcher die Flags NS, ECE und CWR nicht deklariert bzw. als reserviert markiert. Diese drei Flags werden benutzt um Verstopfungen im Datentransfer zu vermeiden oder zu beenden. Ich markiere den Abschnitt als zu Überarbeiten. 84.226.26.210 20:25, 19. Aug. 2013 (CEST)

Ich habe mal einen Anfang dazu gemacht. Da ich die Header-Abbildung nicht editieren kann, muss da aber immer noch etwas getan werden. --Itsecstudi (Diskussion) 02:36, 31. Aug. 2013 (CEST)

Kritik an TCP

Ist Kritik wie diese relevant? --Hamburger 17:05, 28. Jan. 2012 (CET)

Ich würde das nicht Kritik an TCP als Protokoll, sondern Kritik an seinen Teilen bezeichnen. Also Kritik am MSL-Wert, Kritik an der Windowscale-Option und Kritik an einzelnen Elementen der Staukontrolle. Man darf sich TCP nicht als einen monolithischen Standard vorstellen, der irgendwann mal hingesetzt wurde, sondern eher als ein dynamisches System vieler Einzelsysteme die sehr vorsichtig und in einem langen Prozess (>30 Jahre) aufeinander abgestimmt wurden und noch werden. Insofern ist die Meldung von Heise irreführend. Google beteiligt sich einfach an der Forschung zu TCP, ist aber auch nur ein Akteur unter vielen. --Artistoex (Diskussion) 14:53, 26. Okt. 2013 (CEST)

Inkorrekt

Folgende Aussage ist nich korrekt:

"Ein Server wartet beispielsweise auf Port 80 auf eingehende Verbindungen (listen) und setzt bei einem Verbindungsaufbau durch einen Client (accept) die Verbindung auf einem anderen Socket fort. Dadurch ist es möglich, dass ein Webserver gleichzeitig mehrere Verbindungen zu verschiedenen Rechnern geöffnet hat. Mehrfaches listen auf demselben Port ist nicht möglich."

Siehe:

• http://news.ycombinator.com/item?id=3028849
• http://en.wikipedia.org/wiki/Network_socket
• http://stackoverflow.com/questions/3329641/how-do-multiple-clients-connect-simultaneously-to-one-port-say-80-on-a-server (nicht signierter Beitrag von 78.43.84.210 (Diskussion) 09:03, 3. Mär. 2013 (CET))

 Absatz ersatzlos gestrichen, da falsch.
 --And1mu (Diskussion) 20:10, 7. Mär. 2013 (CET)

Ist das wirklich falsch? Mein Wissensstand ist folgender: Ein HTTP-Server lauscht auf Port 80. Kommt eine Verbindungsanfrage, öffnet der Server einen neuen Socket (nicht Port!) für die Verbindung mit dem Client. Fortan kommen Pakete dieser Verbindung (festgelegt durch Quell- und Ziel-IP, sowie Quell- und Zielport) am neuen Socket an und nicht mehr am allgemeinen Lausch-Socket für Port 80 (ich nenn den jetzt mal so). Nach Abbau der Verbindung wird der Socket wieder gelöscht. Somit können so viele Verbindungen über einen Port laufen wie der Rechner Sockets verwalten kann, aber an einem Port auf neue Verbindungen lauschen kann nur ein Server, denn der belegt ja den Lausch-Socket. Versucht man einen zweiten Webserver auf einem Rechner zu starten scheitert der, weil er den Socket für Port 80 nicht belegen kann, denn der ist ja schon besetzt. --Saibot2 (Diskussion) 22:50, 14. Mär. 2013 (CET)

Von http://de.wikipedia.org/wiki/Socket_%28Software%29 :

Das heißt, dass ein mit einem Client-Socket verbundener („connected“) Server-Socket genau die gleiche IP-Adresse und Port-Nummer trägt wie der lauschende („listen“) Server-Socket. Die Unterscheidung von gleichzeitigen Client-Verbindungen zum selben Server erfolgt daher durch das Paar von Server-Socket und Client-Socket. Dieses Paar muss zu jedem Zeitpunkt eindeutig auf jedem der beteiligten Kommunikationspartner sein. Als Beispiel sei ein HTTP-Server gegeben der auf Port 80 lauscht. Die Verbindungen des Servers zu verschiedenen Clients führt zu folgenden eindeutigen „Connected“-Socket-Paaren auf dem Server-Rechner: (<Server-IP>:80;<Client_A-IP>:<Client_A_Port_1>), (<Server-IP>:80;<Client_A-IP>:<Client_A_Port_2>), (<Server-IP>:80;<Client_B IP>:<Client_B_Port_1>) usw.

Empfehlenswert sind auch die jeweiligen englischen Seiten.

--And1mu (Diskussion) 19:16, 15. Mär. 2013 (CET)

Genau. Das ist ja genau das, was ich geschrieben habe und das ist auch das, was in dem strittigen Absatz steht. Zumindest seh ich das so. Wenn du anderer Meinung bist fände ich es gut wenn du mir erklären könntest wo du da noch Fehler siehst. --Saibot2 (Diskussion) 21:34, 15. Mär. 2013 (CET)

OK, mir ist jetzt klar wie man den Abschnitt auch verstehen kann. In der Tat ist er dann genaugenommen nicht "falsch". Allerdings besteht meiner Ansicht nach eine sehr große Gefahr den Abschnitt falsch zu verstehen: Nachdem man liest "... auf Port 80 ..." geht es weiter mit "...auf einem anderen Socket fort" - der unbedarfte Leser (oder zumindest ich) assoziiere hier Port und Socket miteinander (wie es im Zustand "listen" gerechtfertigt ist) und verstehe den Satz, wenn ich ihn nicht ganz genau zerpflücke so, dass die Verbindung auf einem anderen Port fortgesetzt wird. Verstärkt wird dies durch den folgenden Satz: "Dadurch ist es möglich, dass ein Webserver gleichzeitig mehrere Verbindungen zu verschiedenen Rechnern geöffnet hat." - eine einzige Verbindung wäre also auch ohne Wechsel des Sockets möglich? Es geht weiter mit: "Mehrfaches listen auf demselben Port ist nicht möglich." was in der Tat richtig ist, aber nichts mit den vorherigen Aussagen zu tun hat, denn sobald eine Verbindung aufgebaut wird ist der alte 'listen' Socket schon ein neuer Socket und damit nicht mehr bzw. der Port schon wieder im "listen" Zustand. Also für mich mag jeder Satz für sich genommen nicht falsch sein, trotzdem ist die Aussage des Absatzes, wenn nicht falsch, dann doch sehr missverständlich. Vielleicht sollte man so schreiben: "Ein Server öffnet beispielsweise auf Port 80 einen Socket ('listen'), der auf eingehende Verbindungen wartet. Ein Clients baut von einem beliebigen Port ab 1024 eine Verbindung zum Server auf. Diese Verbindung läuft anschließend wiederum über einen Socket ('established', ebenfall auf Port 80 des Servers). Dadurch ist es möglich, dass ein Webserver gleichzeitig mehrere Verbindungen zu verschiedenen Rechnern geöffnet hat. Mehrfaches listen auf demselben Port ist nicht möglich. Auf der Client-Seite wird eine beliebige Portnummer ab 1024 zugewiesen. Der gestrichene Teil trägt glaube ich nichts zum Verständnis bei. --And1mu (Diskussion) 15:14, 20. Mär. 2013 (CET)

Damit dürftest du recht haben. Die Missverständlichkeit war mir jetzt vermutlich nicht mehr aufgefallen, weil ich den Abschnitt bestimmt fünf mal gelesen hab um einen Fehler zu finden. --Saibot2 (Diskussion) 18:31, 24. Mär. 2013 (CET)

Habe den Abschnitt nun so umformuliert, dass er für die überwiegende Mehrheit der vorkommenden TCP-Verbindungen zutrifft. --Artistoex (Diskussion) 15:15, 26. Okt. 2013 (CEST)