„Diskussion:Transmission Control Protocol“ – Versionsunterschied

Versionsgeschichte interaktiv durchsuchen

Inhalt gelöscht Inhalt hinzugefügt

Inline

Aktuelle Version vom 3. Dezember 2021, 13:54 Uhr



Zum Archiv

Timestamps

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Im Artikel werden die Timestamp-Optionen nicht erwähnt.--2001:4CA0:309:0:2105:C6D6:91E2:B7FE 11:07, 3. Mai 2019 (CEST)Beantworten

Fujitsu

Letzter Kommentar: vor 12 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

... will eine leistungsfähigere Alternative zu TCP erfunden haben. Noch namenlos (und unverstanden). --Itu (Diskussion) 08:28, 4. Feb. 2013 (CET)Beantworten

PSH-Flag

Letzter Kommentar: vor 12 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Der Abschnitt ueber das PSH-Flag ist etwas weitschweifig und unklar formuliert. Der erste PSH enthaltende Satz im ersten verlinkten RFC hat's dagegen gleich geklaert. Folgende zwei Punkte sollten mMn den vielen Text ersetzen:

PSH bedeutet push.
Bei _nicht_ gesetztem Flag _koennen_ Applikationsdaten vom TCP gepuffert werden, und zwar in beiden Senderichtungen. Wenn das Flag dagegen gesetzt ist, werden die Daten sofort durchgereicht (gepusht).

--217.111.33.4 15:04, 4. Mär. 2013 (CET)Beantworten

Syn-Flags, Ack-Flags bei bestehender Verbindung

Letzter Kommentar: vor 12 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Bei Transmission Control Protocol#Verbindungsaufbau und -abbau steht nicht, wie Pakete während der Verbindung aussehen... Da steht nur, wie Pakete beim Verbindungsaufbau(Syn-Flag, Ack-Flag) und beim Verbindungsabbau(Fin-Flag, Ack-Flag) aussehen... Wie Pakete während der Verbindung aussehen, steht nicht in dem Artikel... Das sollte vielleicht noch erklärt werden... Welche Flags sind während der Verbindung gesetzt?

- Es beginnt mit dem Verbindungsaufbau... dies ist im Artikel erklärt

- Dann ist die Verbindung aufgebaut und es werden Daten übertragen... dies ist im Artikel nicht erklärt

- Es endet mit dem Verbindungsabbau... dies ist im Arikel erklärt

(nicht signierter Beitrag von 88.70.127.22 (Diskussion) 13:30, 7. Mär. 2013 (CET))Beantworten

Urgent Pointer

Letzter Kommentar: vor 10 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Laut RFC 6093 zeigt der Urgent Pointer nicht auf das erste Byte nach den Urgent-Daten, sondern auf das letzte Byte der Urgent-Daten. Viele Stacks behandeln den Urgent Pointer jedoch immer noch so, dass er auf das erste Byte nach den Urgent-Daten zeigt (kommt von der Zweideutigkeit in RFC 793). Auf diese Zweideutigkeit sollte hingewiesen werden, oder? (nicht signierter Beitrag von 149.172.65.125 (Diskussion) 21:05, 19. Feb. 2015 (CET))Beantworten

@@ Zeile 1: / Zeile 1: @@
+{{War AdT|1=13. März 2006}}
-== Exzellenter Artikel? ==
+{{Archiv-Tabelle|Hilfe=0}}
-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.
+{{Autoarchiv
+|Alter             =365
+|Ziel              ='((Lemma))/Archiv'
+|Klein             =Nein
+|Mindestbeiträge   =2
+|Mindestabschnitte =3
+|Frequenz          =monatlich
+}}
+== Timestamps ==
-Auch sonst erscheint mir die Gliederung völlig willkürlich.
+Im Artikel werden die Timestamp-Optionen nicht erwähnt.--[[Spezial:Beiträge/2001:4CA0:309:0:2105:C6D6:91E2:B7FE|2001:4CA0:309:0:2105:C6D6:91E2:B7FE]] 11:07, 3. Mai 2019 (CEST)
-[[Benutzer:Paracetamol|Paracetamol]] 18:21, 5. Feb 2006 (CET)
+== Fujitsu ==
-== 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.
+... will eine [http://www.golem.de/news/fujitsu-tcp-alternative-macht-datenuebertragung-30-mal-schneller-1301-97246.html leistungsfähigere Alternative] zu TCP erfunden haben. Noch namenlos (und unverstanden). --[[Benutzer:Itu|Itu]] ([[Benutzer Diskussion:Itu|Diskussion]]) 08:28, 4. Feb. 2013 (CET)
-: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. --[[Benutzer:Elwood j blues|Elwood j blues]] 17:14, 27. Mär 2005 (CEST)
+== PSH-Flag ==
-::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... --[[Benutzer:84.56.83.13|84.56.83.13]] 23:31, 16. Jan 2006 (CET)
+Der Abschnitt ueber das PSH-Flag ist etwas weitschweifig und unklar formuliert. Der erste PSH enthaltende Satz im ersten verlinkten RFC hat's dagegen gleich geklaert. Folgende zwei Punkte sollten mMn den vielen Text ersetzen:
-== Deutsche Übersetzung der RFC 793 ==
+* PSH bedeutet push.
+* Bei _nicht_ gesetztem Flag _koennen_ Applikationsdaten vom TCP gepuffert werden, und zwar in beiden Senderichtungen. Wenn das Flag dagegen gesetzt ist, werden die Daten sofort durchgereicht (gepusht).
+--[[Spezial:Beiträge/217.111.33.4|217.111.33.4]] 15:04, 4. Mär. 2013 (CET)
-Gibt es irgendwo im Web eine deutschsprachige Übersetzung des RFC-Textes zum TCP? -- [[Benutzer:WalterSpiegel|WalterSpiegel]] 21:26, 28. Aug 2005 (CEST)
+== Syn-Flags, Ack-Flags bei bestehender Verbindung ==
-== TCP-Header (Grafik) ==
+Bei [[Transmission Control Protocol#Verbindungsaufbau und -abbau]] steht nicht, wie Pakete während der Verbindung aussehen... Da steht nur, wie Pakete beim Verbindungsaufbau(Syn-Flag, Ack-Flag) und beim Verbindungsabbau(Fin-Flag, Ack-Flag) aussehen... Wie Pakete während der Verbindung aussehen, steht nicht in dem Artikel... Das sollte vielleicht noch erklärt werden... Welche Flags sind während der Verbindung gesetzt?
-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. --[[Benutzer:Wendelin|Wendelin]] 23:15, 11. Mai 2005 (CEST)
+:- Es beginnt mit dem [[Transmission Control Protocol#Verbindungsaufbau|Verbindungsaufbau]]... dies ist im Artikel erklärt
-== Geschichtliches ==
+:- Dann ist die Verbindung aufgebaut und es werden Daten übertragen... dies ist im Artikel nicht erklärt
-Ein bisschen ueber die Geschichte und Entwicklung von TCP fehlt noch.
+:- Es endet mit dem [[Transmission Control Protocol#Verbindungsabbau|Verbindungsabbau]]... dies ist im Arikel erklärt
+<small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von ''[[Spezial:Beiträge/88.70.127.22|88.70.127.22]] ([[Benutzer Diskussion:88.70.127.22|Diskussion]])<nowiki/> 13:30, 7. Mär. 2013 (CET))</small>
+== Urgent Pointer ==
-Der Teilsatz: "... Data Layer (beim Ethernet das statische MAC Protokoll)" ist inhaltlich falsch. Richtig: Nachzulesen unter den Stichworten LLC, MAC und Ethernet.
+Laut RFC 6093 zeigt der Urgent Pointer nicht auf das erste Byte nach den Urgent-Daten, sondern auf das ''letzte'' Byte der Urgent-Daten. Viele Stacks behandeln den Urgent Pointer jedoch immer noch so, dass er auf das erste Byte ''nach'' den Urgent-Daten zeigt (kommt von der Zweideutigkeit in RFC 793). Auf diese Zweideutigkeit sollte hingewiesen werden, oder? <small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Spezial:Beiträge/149.172.65.125|149.172.65.125]] ([[Benutzer Diskussion:149.172.65.125|Diskussion]])<nowiki/> 21:05, 19. Feb. 2015 (CET))</small>
-== 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 "'''D'''enial '''o'''f '''S'''ervice (DoS)"; respektive eine Verlinkung. Meines Wissens ist es definiert, wann der Dienst verweigert werden ''muß''. Bitte hinzufügen. --[[Benutzer:Wendelin|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. --[[Benutzer:Elwood j blues|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. --[[Benutzer:131.188.3.20|131.188.3.20]] 19:00, 16. Jan 2006 (CET)
-== 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. [[Benutzer:213.6.50.126|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. --[[Benutzer:Elwood j blues|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. --[[Benutzer:Elwood j blues|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. --[[Benutzer:Wendelin|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. --[[Benutzer:Herr Schroeder|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. --[[Benutzer:Elian|Elian]] [[Benutzer Diskussion:Elian|&Phi;]] 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).<br>
-:''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.<br>
-:''Drei-Wege-Handshake'' – sollte man das vielleicht wie im englischen Three-Way-Handshake nennen?<br>
-: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. --[[Benutzer:Ww|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. - [[Benutzer:Appaloosa|Appaloosa]] 01:37, 22. Mai 2005 (CEST)
-=== [[Transmission Control Protocol]], 21. Juni ===
-aus dem [[Wikipedia:Review|Review]]:
-* '''Dafür''': Umfangreiche Erläuterung des Protokolls. -- [[Benutzer:Dishayloo|Dishayloo]] [ [http://de.wikipedia.org/w/wiki.phtml?title=Benutzer_Diskussion:Dishayloo&action=edit&section=new +]] 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. --[[Benutzer:Atamari|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 [[Benutzer:Appaloosa|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: <s>'''abwartend'''<s>. [[Benutzer:T.a.k.|T.a.k.]] 01:14, 22. Jun 2005 (CEST) Jetzt '''pro''' [[Benutzer:T.a.k.|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ß [[Benutzer:Boris Fernbacher|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.--[[Benutzer:Heliozentrik|Heliozentrik]] 19:03, 26. Jun 2005 (CEST)
-*'''pro''' schöner Artikel :) -- [[Benutzer:MichaelDiederich|da didi]] | [[Benutzer Diskussion:MichaelDiederich|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 ...''). [[Benutzer:Darkone|<font color=black>'''Dark'''one</font>]][[User Talk:Darkone| ''('''¿!''')'']] 1. Jul 2005 10:41 (CEST)
-*'''pro''' - absolute Laienmeinung, aber wenn ich einen solchen Text schon versteh ... -- [[Benutzer:Achim Raschka|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 -- [[Benutzer:beos|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 [[Transmission_Control_Protocol#Daten.C3.BCbertragung|Datenübertragung]] dieses exzellenten Artikels einige. Ist die Regel obsolet oder der Artikel verbesserungswürdig? --[[Benutzer:Ein anderer|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.
-[[Benutzer:jungelbewohner|jungelbewohner]] 12. Okt 2005 15:15 (CEST)
-:Genau so sollte es da stehen, da hast du recht. Alles andere ist Unfug. --[[Benutzer:Elwood j blues|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?