Hi!
Wie das im TCP-Layer implementiert ist weiß ich auch nicht.
Aber, gerade bei Telnet, wo du nur sehr selten was tippst, ist
es gut, wenn das ACK sofort zurückgeschickt wird. Das
Verzögern von ACK macht ja nur bei großen Datenströmen Sinn,
wenn man einige Packerl abwarten kann und dann ein Sammel-ACK
schickt.
ja, nur mir magelt es an einer guten - belegbaren - begründung
Begründung wofür?
Außerdem: bei Telnet bekommst du ja das Echo von remote, und
daher ist die Anzeige des getippten Buchstaben sowieso ein
Packerl aus der Gegenrichtung, das dann praktischerweise
gleich das ACK mitführt.
das is allerdings gut zu wissen. hast du vielleicht ne idee wo
ich ne detailierte übersicht über ne telnet-session finde? gut
wäre es wenn net nur das procedre angesprochen wird (kenn ich
ja), sondern genau auf einzelne commandos/datenpakete
eingegangen wird…
Telnet-Session ist eine ganz einfache TCP Verbindung, _ohne_ zusätzliches Protokoll (wie das z.b. bei FTP, HTTP, … noch zusätzlich notwendig ist). D.h., wenn du
machst, macht der die TCP-Verbindung auf (3-way-handshake) und wartet erst mal. Sobald du eine Taste tippst (manchmal wartet er auch bis du Return drückst, das kann man einstellen) schickt er ein TCP-Packerl mit genau 1 Byte Inhalt, nämlich deiner Taste in ASCII-Code weg. Die kriegt die Gegenstelle, leitet sie an den Telnet-Server weiter (der hat irgendwelche Verbindungen, z.b. zu einem TTY vom Betriebssystem), dieses Echoed das Zeichen zurück, das geht in den TCP/IP-Stack des Servers, der packt dieses eine Zeichen (das jetzt zur Anzeige am Telnet-Client vorgesehen ist) in ein TCP-Packerl ein, tut gleich die richtige ACK-Nummer rein und schickts los.
Dein Client kriegt das Packerl mit dem Zeichen und schickt wieder eine ACK zurück. So ist das bei „remote echo“. Bei „local echo“ gibts nur je Taste 2 Packerl, wobei das ACK-Packet gar keine Daten enthält.
Woher weiß aber der TCP/IP-Stack, ob er _sofort_ ein ACK-Packerl generieren soll, ob er sowieso Nutzdaten zum Zurückschicken hat oder ob er das Window noch ausnutzen kann?
TCP/IP hat da keine expliziten Regeln. Ich denke, dass er es aber erstens aus dem TOS (Type of Service) Feld (bulk transfer, low-latency, …) und aus der Window-Size bestimmt.
@Flow Control: Die wird mit der Änderung der Window-Size gesteuert. Wenn ein Host mal ein ACK unterdrückt, dann ist es ihm schon _viel_ zu heiß um die Ohren, das wird vermieden so lange es geht. Um das zu vermeiden gibt es ECN (Explicit Congestion Negotiation), ein Mechanismus der von Routern „unterwegs“ verwendet werden kann, um explizit auf eine notwendige Verringerung der Bandbreite hinzuweisen. Ohne ECN müsste er ein Packet wegwerfen, was eine brutale Methode ist.
Leider gibts aber noch einige alte Router, die ECN nicht verstehen, darum kann man es nicht immer verwenden. 
Bye
Hansi
