Socket Verdammt langsame übertragung bei tcp

[pcProfie]

hallo!
anlehnend zu http://www.java-forum.org/netzwerkeprogrammierung/158013-server-uebertragung-immer-langsamer.html hab ich n neues problem: ich habe alles mal ein wenig geändert, für jeden clienten einen neuen thread beim server usw. ich komme aber immernoch auf eine durchschnittsgeschwindigkeit von 1,7 sekunden pro sendevorgang. es wird immernoch per printwriter geschrieben und per buffered reader gelesen. ich hab das ganze mal in udp gemacht und da 13 ms pro vorgang gehabt. ping über die cmd ist auch bei ca 20ms. ich habe das ganze auch so umgeschrieben dass ich immer nur einen clienten gleichzeitig verbunden habe. da vergleichbare werte ~1-2 sekunden.

woran liegt das oder ist tcp wirklich so langsam?

 

[Sen-Mithrarin]

nun ... grundsätzlich bauen UDP und TCP ja auf IP auf ... und wenn UDP/IP im MS bereich ist ... kann es wohl nicht an IP liegen ... ergo : es bleibt als ursache nur TCP selbst ...

jetzt muss man noch wissen was bei TCP sonst noch so passiert im gegensatz außer irgendeinen kram in ein IP-paket zu packen ...

unteranderem spielt das hier ne rolle : Nagle-Algorithmus ? Wikipedia
und auch das hier : Transmission Control Protocol ? Wikipedia

sorgt alles dafür das bei TCP mehr overhead entsteht und daurch das ganze einfach länger dauert

 

[pcProfie]

ja das kann ja sein aber wirklich 100 mal langsamer? (wlan, langsamste komponente 150mbit/s). das selbe programm hat bei win xp pcs über n lan switch 120 ms gebraucht. wieso braucht es bei mir zuhause 1700 ms? lan ist bei den pcs 100 oder 1000 mbits gewesen und das ist nicht 100 mal schneller als wlan. (außerdem läuft doch das halbe inet über tcp und da können 512 kb nicht 1,7 sekunden brauchen!)

 

[Sen-Mithrarin]

na .. da haste aber was nich verstanden

bei UDP werden die daten einfach in ein paket gesteckt und los gefeuert ... den rest macht das netzwerk und kümmert das system nicht weiter

bei TCP werden zu den nutz-daten noch steuerdaten übertragen, teilweise mit den nutz-daten, teilweise als eigene pakete > overhead
weiter kontrolliert TCP den daten-verkehr durch rückmeldung oder neu-anforderungen > noch mehr overhead
und wenn dann noch PPPoE und WPA2 und WLAN und so alles zusammen trifft ... joar ... das summiert sich schon mal auf und kann zu deutlichen einbrüchen im datendurchsatz führen


noch ne anmerkung zu 802.11 (wlan) : die angegebene link-geschwindigkeit gibt in der regel nur über die verfügbare bandbreite auskunft, hat aber mit dem eigentlichen datendurchsatz wenig zu tun
in der regel sagt man grob : datendurchsatz ca. 50% des link-speed
wenn du also n link mit um die 150MBit/s brutto hast wirst du netto kaum mehr als 50MBit/s - 70MBit/s an nutz-daten übertragen können
und wenn man noch weitere störquellen mit einbezieht kann eine TCP-verbindung schon mal deutlich länger und damit langsamer sein als wenn man mit UDP einfach wahllos die pakete durchs netz feuert



wenn man gewisse faktoren ausschließen kann kanns am ende immer noch an schlechtem code liegen

aber als kleines beispiel : simples schiffe versenken über ein 1GBit/s LAN mit TCP > ca. 2sek verzögerung (teilweise auch etwas mehr)
Nagle-Algo abgeschaltet mit Socket.setTcpNoDelay(true) : schon mal runter auf ein paar hundert millis (um die 200ms-500ms)
das ganze mal eben mit udp : verzögerung praktisch nicht mehr messbar

es hat also sehr viel weniger mit den genannten umständen als mit TCP vs UDP selbst zu tun