Diskussion:Transmission Control Protocol/Archiv

message: 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)
thread_title:  Kommentare zum Artikel 

message: 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)
thread_title:  Gut, aber (noch) nicht exzellent! 

message: 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)
thread_title:  Exzellenter Artikel? 

message: 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)
replies: text: 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)
thread_title:  Unübersichtlich + TCP-Header in extra Artikel 

message: Gibt es irgendwo im Web eine deutschsprachige Übersetzung des RFC-Textes zum TCP? -- WalterSpiegel 21:26, 28. Aug 2005 (CEST)
replies: text: 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)
thread_title:  Deutsche Übersetzung der RFC 793 

message: 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)
thread_title:  TCP-Header (Grafik) 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Problematik der Datenwiederholung 

message: 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)
thread_title:  paketorientiert 

message: Dass und wie TCP das Sliding Window-Verfahren einsetzt, fehlt noch. --Elwood j blues 17:14, 27. Mär 2005 (CEST)
replies: text: 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)
thread_title:  Fluss- und Staukontrolle 

message: 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)
thread_title:  Klammern und Exzellenz 

message: 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)
thread_title:  Verbindungsaufbau und Abbau 

message: 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)
thread_title:  Exzellente Artikel sehen anders aus 

message: 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)
thread_title:  Abb. 1 

message: 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)
replies: text: Hab sie wieder reingestellt... Was fuer mutige Helden es doch gibt. ChrisHuebsch 09:36, 14. Mär 2006 (CET)
thread_title:  Bilder gelöscht 

message: 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)
thread_title:  Fenstermechanismus 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text:  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)
replies: text: 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)

text: 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)
replies: text:  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)
replies: text:  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)
replies: text:  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)
replies: text:  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)

text: 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)

text: 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)
thread_title:  Abwahl-Diskussion 

message: 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)
thread_title:  Slow Start 

message: 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)
replies: text: Du hast Recht, der Abschnitt war in Teilen schlichtweg falsch. Ich habe mich mal dranbegenben. --Gimbal 20:13, 6. Sep. 2008 (CEST)
thread_title:  Checksummenberechnung und Überprüfung 

message: 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)
thread_title:  Lesenswert-Kandidatur 31. 7. - 7. 8. 2006 (erfolgreich) 

message: 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)
thread_title:  Korrektur von Slow Start 

message: 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)
replies: text: 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)
thread_title:  Der Drei-Wege-Handshake 

message: siehe Diskussion:Internet_Protocol#Netzwerk_vs._Netz (Der vorstehende, nicht signierte Beitrag stammt von Kockster (Diskussion • Beiträge) 19:56, 7. Jul. 2008 (CEST)
replies: text: Bitte hier weiter diskutieren. Danke --M.L 17:01, 12. Jul. 2008 (CEST)
thread_title:  Netzwerk vs. Netz 

message: 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)
thread_title:  Acknowledgment Number (Quittierungsnummer) 

message: 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)
thread_title:  Keine Datagramme? 

message: 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)
thread_title:  Überlastabwehr etc. 

message: 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)
replies: text: 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)
thread_title:  Grund für Segmentierung 

message: 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)
thread_title:  TCP-Pseudo-Header (Text) 

message: 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)
replies: text: 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)
thread_title:  Geschichtliches 

message: 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)
thread_title:  Falscher Teilsatz 

message: 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)
thread_title:  2 inhaltliche Fragen zur Datenübertragung 

message: 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)
thread_title:  Ziemlich unverständlich 

message: 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)
thread_title:  Net schlecht 

message: 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)
thread_title:  Fehlende CWR und ECE flags 

message: 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)
replies: text: Ist mir eben auch aufgefallen, die berechnung im Bild ist definitiv falsch. Metallicum 13:44, 14. Feb. 2011 (CET)
thread_title:  Abb. 9 (nicht beschriftet) zu "Slow Start und Congestion Avoidance" 

message: 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)
thread_title:  Überarbeiten 

message: 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)
replies: text:  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)
thread_title:  Zur Qualität des TCP-Artikels 

message: 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)
replies: text: 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)
thread_title:  Unvollständiger TCP-Header 

message: Ist Kritik wie diese relevant? --Hamburger 17:05, 28. Jan. 2012 (CET)
replies: text: 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)
thread_title:  Kritik an TCP