[Problem] VDSL - neue TCP-Verbindungen hängen

MPW

Neuer User
Mitglied seit
16 Jul 2007
Beiträge
151
Punkte für Reaktionen
1
Punkte
0
Hallo Forengemeinde,

ich habe seit 4-5 Tagen ein immer schlimmer werdendes Problem mit meinem VDSL-Anschluss bei 1&1. Ich habe heute schon 4h in die Hotline investiert, leider mit mäßigem Erfolg.

Fehlerbeschreibung: Wenn eine neue TCP-Verbindung aufgebaut werden soll, z.B. um eine Website zu laden, bleibt diese hängen, läuft ins Timeout und erst beim zweiten oder dritten Versuch ist der Verbindungsaufbau erfolgreich. Parallel kann ich haber Downloads und Speedtests mit maximaler Bandbreite (25,1 down/5,1 up) laufen lassen.

Um das Problem mal zu verdeutlichen, hier ein Beispiel. Ich lade die Startsteite von Golem (stellvertretend für jegliche andere Seite, das Problem besteht zu jeder andere Seite genauso). Während ich gewartet habe, drückte ich pro Sekunde einmal #. Somit kann man die Wartezeit ablesen:

Code:
$ wget golem.de
--2014-06-20 20:52:11--  http://golem.de/
Auflösen des Hostnamen »golem.de (golem.de)«... 176.74.59.148
Verbindungsaufbau zu golem.de (golem.de)|176.74.59.148|:80... #############################verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... #302 Moved Temporarily
Platz: http://www.golem.de/ [folge]
--2014-06-20 20:52:43--  http://www.golem.de/
Auflösen des Hostnamen »www.golem.de (www.golem.de)«... 176.74.59.148
Wiederverwendung der bestehenden Verbindung zu golem.de:80.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: nicht spezifiziert [text/html]
In »»index.html«« speichern.

    [     <=>                               ] 104.568     60,8K/s   in 1,7s    

2014-06-20 20:52:46 (60,8 KB/s) - »index.html« gespeichert [104568]

Wie man sieht kam die DNS-Auflösung sofort, aber der eigentliche Download der html-Datei kam erst 30 Sekunden verzögert. Wenn man sich überlegt, dass bei einer modernen Website nicht nur ein Download erforderlich ist, kann man sich schnell ausrechnen, dass das Laden einer einzigen Seite derzeit mehrere Minuten bei uns dauert. Teilweise laufen die Verbindungen auch ins Timeout und erst der zweite oder dritte Versuch ist erfolgreich.

Das Problem tritt mit jedem Gerät im lokalen Netzwerk auf: Laptops über WLAN, PC über Gigabit, Android- und iPhone-Smartphones. Auch der Port ist nicht entscheidend, alle getesteten Ports (http,https, ssh, imap, smtp) zeigen dasselbe Verhalten.

Was ich schon selbst oder auf Vorschlag von 1&1 getestet habe:

- Router resettet, löst das Problem circa 5 Minuten lang, d.h. 5 min kann ich normal Surfen und dann kommen wieder die Verzögerungen. Das gilt für jeglichen Lösungsansatz, der eine neue DSL Synchronisation beinhaltet.
- Firmware der FritzBox auf den Auslieferungszustand zurück gesetzt, keine Wirkung außer die 5 min, da die DSL-Verbindung neu aufgebaut wird.
- DNS Server in der FritzBox auf 8.8.8.8 (Google) gesetzt, keine Wirkung, DNS klappt ja auch.

1&1 meint, es käme zu Mikroaussetzern in der Leitung. Das glaube ich aber nicht, denn: Wenn eine Verbindung einmal besteht, kann ich ohne Probleme mit voller Bandbreite laden. Z.B. kann ich einen 10 GB großen Testcontainer mit vollen 2,7 MB/s übertragen, während eine neue, parallel aufzubauende Verbindung erst nach 30-40 Sekunden durchkommt. Auch VoIP ist davon überhaupt nicht betroffen, die Qualität ist genauso gut wie immer. Daher kann ich mir nicht vorstellen, dass Mikroaussetzer das Problem sind. Ich kann auch stundenlang über Skype telefonieren oder im Internet Egoshooter spielen, wenn ich denn erstmal auf den Server gekommen bin.

Um es nochmal deutlich zu sagen: Während die Leitung voll da ist und ich mit maximaler Geschwindigkeit etwas herunterlade, kann eine simple Website nicht geladen werden. Es ist aber kein QoS Problem, da das Verhalten auch auftritt, wenn keine Last an der Leitung anliegt.

Die Logs sowohl in der FB als auch bei 1&1 zeigen keine Synchronisationsprobleme oder sonstige Fehler.

Die Leitung an sich scheint nicht gestört zu sein, sondern eine Abstraktionsebene höher, auf TCP-Ebene scheint es ein Problem zu geben. Ich habe schon probiert das Problem zu googeln, aber habe leider nichts gefunden. Hat jemand eine Idee, was da los sein könnte?

Meine Idee wäre 50/50 ein defektes VDSL-Modem in der FB oder ein defekter DSLAM. Leider habe ich keinen anderen VDSL-fähigen Router hier um dies zu testen. Würde denn diese Fehlerbeschreibung dazu passen?

In den Anhang stelle ich die Messwerte der FritzBox als Screenshots.

Ich würde mich über Meinungen oder Hinweise zu meinem Problem freuen.

Grüße
MPW

PS.: Falls jemand in der Nähe von Münster wohnt und mir mal für 2-3 h einen VDSL-Router leihen könnte, wäre das natürlich klasse.
 

Anhänge

  • Bildschirmfoto vom 2014-06-20 20:57:31.jpg
    Bildschirmfoto vom 2014-06-20 20:57:31.jpg
    55.3 KB · Aufrufe: 41
  • Bildschirmfoto vom 2014-06-20 20:56:39.jpg
    Bildschirmfoto vom 2014-06-20 20:56:39.jpg
    58.1 KB · Aufrufe: 35
  • Bildschirmfoto vom 2014-06-20 20:56:19.jpg
    Bildschirmfoto vom 2014-06-20 20:56:19.jpg
    63.1 KB · Aufrufe: 37
Zuletzt bearbeitet:
Ich hab gerade noch einen trivialen Test gemacht, dumm eigentlich, dass ich nicht früher drauf gekommen bin.

Da bestehende Verbindungen keine Probleme haben, leite ich jetzt einfach alles durch ein VPN. Und das klappt, keine Latenzprobleme mehr.

Aber VPN ist ja keine Dauerlösung.

1&1 hat für Dienstag keinen Techniker angekündigt, ich hab ein wenig Angst vor einer weiteren Drosselung. Aber ich hoffe Mal, dass der Techniker mehr Ahnung hat als das CC.

Ich wüsste zu gerne auf welcher Ebene TCP-Verbindungen aufgebaut werden. Die reine Hardwareebene scheint es nicht zu sein; aber ich habe leider von den verschiedenen Netzwerklayern keine Ahnung.
 
Hast du mal (bspw. mit tcpdump) gesnifft, was beim Verbindungsaufbau passiert?
 
Hallo,

hatte ich noch nicht, aber hab's mal eben gemacht. Ich werde leider nicht schlau aus der Anzeige:

Code:
$ sudo tcpdump -vvv -i eth1 host ebay.de
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:00:24.835282 IP (tos 0x0, ttl 64, id 29344, offset 0, flags [DF], proto TCP (6), length 60)
    Server0.fritz.box.49555 > pages.intl.ebay.com.http: Flags [S], cksum 0x88f8 (incorrect -> 0xe2fc), seq 890650823, win 29200, options [mss 1460,sackOK,TS val 78439 ecr 0,nop,wscale 7], length 0
17:00:25.006658 IP (tos 0x0, ttl 245, id 27099, offset 0, flags [none], proto TCP (6), length 44)
    pages.intl.ebay.com.http > Server0.fritz.box.49555: Flags [S.], cksum 0x91ec (correct), seq 2428278007, ack 890650824, win 8190, options [mss 1440], length 0
17:00:25.006702 IP (tos 0x0, ttl 64, id 29345, offset 0, flags [DF], proto TCP (6), length 40)
    Server0.fritz.box.49555 > pages.intl.ebay.com.http: Flags [.], cksum 0x88e4 (incorrect -> 0x5783), seq 1, ack 1, win 29200, length 0
17:00:25.006797 IP (tos 0x0, ttl 64, id 29346, offset 0, flags [DF], proto TCP (6), length 147)
    Server0.fritz.box.49555 > pages.intl.ebay.com.http: Flags [P.], cksum 0x894f (incorrect -> 0x0e80), seq 1:108, ack 1, win 29200, length 107
17:00:25.176698 IP (tos 0x0, ttl 242, id 60028, offset 0, flags [DF], proto TCP (6), length 40)
    pages.intl.ebay.com.http > Server0.fritz.box.49555: Flags [.], cksum 0xc928 (correct), seq 1, ack 108, win 65535, length 0
17:00:25.186626 IP (tos 0x0, ttl 242, id 60637, offset 0, flags [DF], proto TCP (6), length 296)
    pages.intl.ebay.com.http > Server0.fritz.box.49555: Flags [P.], cksum 0x81ce (correct), seq 1:257, ack 108, win 65535, length 256
17:00:25.186656 IP (tos 0x0, ttl 64, id 29347, offset 0, flags [DF], proto TCP (6), length 40)
    Server0.fritz.box.49555 > pages.intl.ebay.com.http: Flags [.], cksum 0x88e4 (incorrect -> 0x52e8), seq 108, ack 257, win 30016, length 0
###### [hier hängt er, während wget auch hängt] ######
17:00:40.746838 IP (tos 0x0, ttl 64, id 29348, offset 0, flags [DF], proto TCP (6), length 40)
    Server0.fritz.box.49555 > pages.intl.ebay.com.http: Flags [F.], cksum 0x88e4 (incorrect -> 0x52e7), seq 108, ack 257, win 30016, length 0
17:00:40.916420 IP (tos 0x0, ttl 245, id 20794, offset 0, flags [none], proto TCP (6), length 40)
    pages.intl.ebay.com.http > Server0.fritz.box.49555: Flags [F.], cksum 0xa828 (correct), seq 257, ack 109, win 8190, length 0
17:00:40.916459 IP (tos 0x0, ttl 64, id 29349, offset 0, flags [DF], proto TCP (6), length 40)
    Server0.fritz.box.49555 > pages.intl.ebay.com.http: Flags [.], cksum 0x88e4 (incorrect -> 0x52e6), seq 109, ack 258, win 30016, length 0

Kannst du daraus was lesen? Am Zeitindex sieht man ja auch, wieder 15 Sek. Wartezeit.

Grüße
MPW
 
Hm, da hätte ich eher erwartet, dass es in den 15 Sekunden auch kaputte Pakete gibt. Aber so garkein Traffic? :confused:
 
Es ist mir auch ein Rätsel :(

Ich verstehe halt auch nicht, wo ich anfangen könnte zu suchen.

Es kann eigentlich nur ein Hardwaredefekt sein oder hat so ein DSLAM auch Software und muss evtl. mal resettet werden? Das hätten die ja vermutlich schon gemacht.

Aber wie kann ein Hardwaredefekt einzelne TCP-Verbindungen beeinflussen und andere nicht.
 
Hi,

setz mal die auf der DSL-Seite MTU auf 1452 und MSS (clamping) auf 1412; und berichte.

Gruß,

DK
 
Zuletzt bearbeitet:
Hallo,

ich hab nicht richtig rausfinden können, wo man das einstellt.

Also unter Internet -> Verbindungsdaten -> IPv6 kann ich die MTU einstellen, aber nur wenn ich IPv6 aktiviere. Ich weiß nicht, ob es am IPv6 liegt, aber dann kommt irgendwie gar keine Übertragung mehr zustande.

Zu MSS lese ich immer nur, dass das automatisch ginge, nicht, dass man da irgendwo die Paketgröße einstellen könnte. Weißt du, wie das in der FritzBox geht? Bei Google und in der AVM Hilfe habe ich es nicht gefunden.

Mich würde auch dein Hintergedanke interessieren. Also mir ist nur das Phänomen bekannt, dass wenn die MTU zwischen Router und 1&1 kleiner ist, als die innerhalb des Netzwerkes, dass dann alle Pakete gesplittet werden müssen. Aber dann verstehe ich nicht, warum ich gleichzeitig andere Verbindungen mit maximaler Geschwindigkeit habe und warum VPN ohne Probleme funktioniert. Die MTU müsste doch meiner amateurhaften Überlegung alle Verbindungen beeinflussen. Aber vielleicht ist das auch nur gefährliches Halbwissen?

Grüße
MPW
 
Hi,

ich habe keine FritzBox und weiss daher auch nicht, wie man das bei der FritzBox konfiguriert; bei den Routen, die ich verwende (pfSense) kann man solche Details vollständig steuern. Ich vermute mal, dass es bei Dir ein Problem mit falschen MTU-Grössen gibt und dass es kein Problem mit der Hardware gibt. Der Hintergrund ist folgender. Im lokalen Ethernet gibt es üblicherweise eine MTU von 1500, abzüglich der Ethernet-Header bleiben da noch 1492 Bytes für IP übrig. Bei DSL gibt es auch nur eine MTU von 1500, allerdings braucht DSL weitere header, kann also weniger Payload als 1492 Bytes übertragen. Es gibt jetzt zwei Möglichkeiten:

* MTU im Lokalen Netz verkleinern (ca. 40 Bytes oder so, müsste ich mal nachschauen), allerdings ist das sehr umständlich und fehlerträchtig, da man sicherstellen muss, dass jedes Gerät im Netz wirklich mit einer MTU von 1460 oder so arbeitet
* MTU auf DSL erhöhen, allerdings geht das nicht, da hier 1500 Maximum ist
* MSS Camping verwenden

Wenn das nicht richtig konfiguriert ist, dann gibt es genau den von Dir beschriebenen Effekt:

* Kleine IP-Pakete (z.B. Ping) gehen problemlos durch, auch DNS-Anfragen
* Grössere IP-Pakete (HTML-Seiten, Bilder) "hängen"

Verifzier mal meine Annahmen mit Ping

Kann sein, dass die Fritzbox das automatisch macht, aber das scheint bei Dir nicht zu laufen. Evtl. findet man diese Einstellungen nicht direkt in der Web UI, sondern muss Konfigurationsdateien manuell anpassen.

Gruß,

DK
 
Hallo,

Danke für die Erklärung. Dass mit der Paketgröße bzgl. DNS hatte ich gar nicht auf dem Schirm.

Also normale (kleine) Pings gehen bei mir immer ohne Probleme durch.

Wenn ich die Paketgröße künstlich erhöhe geht 1464 noch ohne Fragmentierung ab 1465 steht dann, dass er fragmentieren würde.

Aber wie passt das jetzt dazu, dass bestehende Verbindungen immer durchgehen? Also bei Downloads mit maximaler Geschwindigkeit sind die Pakete doch auch groß und bei VPN auch usw.

Es ist ja nicht langsam oder so, sondern es geht ja einfach gar nicht.

Grüße
MPW
 
Zuletzt bearbeitet:
Was für ein Protokoll sind diese bestehenden Verbindungen?
 
Verschiedenes: HTTP-Download als Speedtest, Skype-Telefonate, Sip-Telefonate und eben VPN. Wir surfen hier nur noch über VPN derzeit, das klappt.

Jegliche Verbindung die einmal da ist, läuft perfekt.
 
SIP und Skype arbeiten mit kleinen IP-Paketen. VPN fragmentiert wahrscheinlich von sich.

Stell doch mal ein, was ich gesagt habe, dann überlegen wir uns, warum es manchmal ging.
 
Ich nehme an, du beziehst dich hierauf?

setz mal die auf der DSL-Seite MTU auf 1452 und MSS (clamping) auf 1412; und berichte.

Ich weiß leider nicht, wie ich das an meiner FritzBox 7360 SL mit FRITZ!OS 06.03 mache. Laut Google und AVM geht das gar nicht mehr von Hand.
 
Sorry, dann weiß ich auch nicht weiter.
 
Ist denn die von mir oben gemessene MTU von 1464 pro Paket normal?

Hier übrigens nochmal die Info bzgl. FritzBox und MTU. Also laut der Beschreibung müsste die das automatisch anpassen.

Dazu müsste ich halt wissen, ob denn 1464 normal ist.
 
Zuletzt bearbeitet:
Ich kann Dir bestätigen, dass 1452 garantiert geht. 1464 müsste ich mal selbst testen, bin aber unterwegs.
 
Ich werde leider nicht schlau aus der Anzeige:
Was mir am SYN in den ersten beiden Paketen auffällt ist, daß Dein Computer eine typische MSS für IPv4 signalisiert (1500 - 20 Byte IP-Header - 20 Byte (kürzester) TCP-Header = 1460 Byte MSS), während der Server mit einer IPv6-typischen MSS (1500 - 40 Byte IP-Header - 20 Byte TCP-Header = 1440 Byte MSS) antwortet.

Wenn da die PMTU-Discovery funktioniert hat, müßten aber zwischen dem ACK in Paket 7 und dessen Resend in Paket 8 (weil 15 Sekunden keine Daten kamen) eigentlich jede Menge Pakete vom Server eingehen. Da die ausbleiben, würde ich erwarten, daß der Server seinerseits zu große Pakete mit DF-Flag sendet und diese dann eben irgendwo auf dem Weg, wo sie fragmentiert werden müßten, verworfen werden. Die kleinen Pakete mit dem HTTP-Request (Paket 4) und den Response-Headern (Paket 6) gehen ja noch durch. Dein Computer quittiert dann im 7. Paket den Empfang der Header und nun sollten eigentlich die "HTTP-Nutzdaten" in mehreren Paketen eintreffen. Im Prinzip macht also Dein Computer alles richtig ... es bleiben bloß die Nutzdaten des Servers aus, die in größeren Paketen (und mit einer großen Window Size) gesendet werden müßten.

Kannst Du nicht mal erst einmal den Weg zu ebay.de generell mit traceroute prüfen ? Laß ruhig mal die Namensauflösung weg, damit man sehen kann, wo es wirklich lang geht.

Ich habe zwar IPv4-Adressen irgendwo in Deiner Frage gesehen, aber bei DS-Lite übernimmt die Kapselung ja auch erst der Router und intern siehst Du dabei die IPv4-Adresse des Ziels.
Kannst Du nicht noch etwas zur DSL-Anbindung und den Angaben auf der Seite "Online-Monitor" des Routers sagen ? Ist das ein ganz normaler IPv4-Anschluß mit öffentlicher IP, wie ihn die meisten mit dem Provider 1&1 verbinden ?
Bei PPPoE müßten ja irgendwo die 8 Byte PPPoE-Header berücksichtigt sein, da wäre dann aber eigentlich eine MSS von 1452 zu erwarten.

Was wirklich richtig hilfreich wäre, ist der Netzwerk-Mitschnitt auf der Seite eines von Dir aufgerufenen Servers ... dort müßten ja per ICMP die verworfenen Pakete dann gemeldet werden und man sollte sehen können, wo die Pakete zurückgewiesen werden. Du hast nicht zufällig einen eigenen Server irgendwo im Internet und kannst auf diesem mal ein tcpdump machen ? Schreib es dann am besten in eine Datei (-w-Option und -s-Option benutzen), damit man auch mal die zu erwartenden Daten (Content-Length-Header im HTTP-Response) ansehen kann bei Bedarf.
 
Zuletzt bearbeitet:
Hallo PeterPawn,

vielen Dank für deinen ausführlichen Beitrag. Nach ein wenig googlen und mit Hilfe der Wikipedia hoffe ich den größten Teil deiner Infos verstanden zu haben :).

Also mein Anschluss hat meines Wissens nach eine öffentliche IPv4-Adresse. Diese nutze ich auch für eingehende Portweiterleitungen via Dyndns (SSH/FTP/HTTP), das hat bisher immer geklappt. Von einer IPv6-Adresse steht dort nichts. IPv6 ist auch in den Verbindungseinstellungen bei mir deaktiviert. Wenn ich das aktiviere hab ich noch mehr Probleme. Auf der FritzBox-Übersichtsseite steht auch nur eine IPv4, keine IPv6.

Hier ein paar traceroutes:

Code:
$ traceroute -n golem.de
traceroute to golem.de (176.74.59.148), 30 hops max, 60 byte packets
 1  192.168.178.1  0.353 ms  0.428 ms  0.681 ms
 2  217.0.116.166  20.143 ms  21.633 ms  23.114 ms
 3  217.0.65.194  26.603 ms  26.829 ms  26.817 ms
 4  62.154.46.182  37.716 ms  45.818 ms  45.805 ms
 5  194.25.211.58  39.905 ms  41.365 ms  42.763 ms
 6  77.247.83.196  42.977 ms  45.466 ms  45.435 ms
 7  37.49.152.1  49.322 ms  32.165 ms  32.134 ms
 8  176.74.59.148  34.252 ms  33.866 ms  35.103 ms
$ traceroute -n heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 60 byte packets
 1  192.168.178.1  0.403 ms  0.476 ms  0.547 ms
 2  217.0.116.166  20.539 ms  22.125 ms  22.125 ms
 3  217.0.65.194  25.732 ms  29.437 ms  29.431 ms
 4  62.154.14.246  33.425 ms  33.609 ms  33.607 ms
 5  217.243.218.222  37.251 ms  37.250 ms  37.305 ms
 6  82.98.102.17  40.666 ms  40.512 ms  40.543 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * 212.19.61.13  26.809 ms !X *
$ traceroute -n ebay.de
traceroute to ebay.de (66.135.215.61), 30 hops max, 60 byte packets
 1  192.168.178.1  0.316 ms  0.386 ms  0.643 ms
 2  217.0.116.166  20.938 ms  21.226 ms  23.391 ms
 3  217.0.65.198  24.933 ms  28.643 ms  28.642 ms
 4  62.154.5.186  125.189 ms  125.189 ms  125.169 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Einen Server im Netz habe ich leider gerade nicht. Hoste zwar ein paar Websiten, aber tcpdump kann man nur als root ausführen. Aber spricht was gegen einen Webserver per UMTS? Das hab ich mal gerade zweimal getestet.

Laut tcpdump bekommt der Webserver auf meinem Netbook, dass per UMTS (Telekom) verbunden ist, die ersten Pakete erst, wenn die Dateiübertragung startet. Während der Verbindungsaufbau mal wieder hängt, steht bei den empfangenen Paketen immer 0.

Zur Vergleichbarkeit: Natürlich hat UMTS eine deutlich höhere Latenz, allerdings geht es über VPN fast in Echtzeit, während eine direkte Verbindung mal wieder 15-20 Sekunden hängt.

DSL -> Uni VPN -> UMTS Webserver < 1 Sekunde abgeschlossen
DSL -> UMTS Webserver > 20 Sekunden Wartezeit

Als Testdatei habe ich einfach per wget die Startseite von golem.de gezogen und diese dann per pyhton SimpleHTTPServer gehostet. So ganz kurz nur... psst :)

Grüße
MPW

/edit: Welchen Wert brauchst du bei "-s"? Dann würde ich das nochmal wiederholen.
 

Anhänge

  • http-test-via-umts.txt
    106.7 KB · Aufrufe: 1
Zuletzt bearbeitet:
Also mein Anschluss hat meines Wissens nach eine öffentliche IPv4-Adresse.
Das sehe ich jetzt auch so. Die 217.0.116.166 auf dem Weg ist ziemlich sicher ein Telekom-Router und kein CGN-Gateway.

Laut tcpdump bekommt der Webserver auf meinem Netbook, dass per UMTS (Telekom) verbunden ist, die ersten Pakete erst, wenn die Dateiübertragung startet.
Das verstehe ich jetzt nicht.

Bei einem HTTP-Request ist der Ablauf folgender:

1. Der Client sendet SYN-Request zum Verbindungsaufbau.
2. Der Server antwortet mit SYN-ACK.
3. Der Client sendet "finales" ACK für den Verbindungsaufbau (legt auch einige Optionen dabei fest). Jetzt steht die TCP-Verbindung und beide Seiten könnten (theoretisch) senden und empfangen. Da der Server keine Ahnung hat, was der Client von ihm will, nimmt er eine "passive Rolle" ein und wartet auf den HTTP-Request vom Client.
4. Der Client sendet seine Anfrage (der Einfachheit halber nehmen wir an - ein GET, was komplett in ein einzelnes Paket paßt).
5. Der Server quittiert mit einem ACK den Empfang des Requests.
6. Der Server sendet die "Header" der Antwort in einer HTTP-Response, auch diese paßt normalerweise in ein einzelnes Paket und enthält (im Content-Length-Header) die Länge der zu erwartenden "Antwort-Daten".
7. Jetzt quittiert der Client seinerseits dem Server den Erhalt der HTTP-Response mit einem ACK. Anschließend wartet er auf die "versprochenen" Datenpakete. Er selbst sendet nichts weiter, solange nicht so viele Daten bei ihm eingegangen sind, daß die "Receive Window Size" (RWIN) überschritten wurde (dann würde er - quasi als Lebenszeichen - zwischendrin ein weiteres ACK senden um anzuzeigen, daß er bis hier alles empfangen hat). Der einzige andere Grund, der ihn zu einem ACK veranlassen würde, ist der Abschluß des Empfangs der angekündigten Daten (die Länge kennt er aus dem erwähnten Header).
----
Hier tritt jetzt (im tcpdump aus dem vorherigen Posting) die 15-Sekunden-Pause ein.
----
8. Da der Client nach dem ACK aus Schritt 7 keine Reaktion des Servers erhalten hat, nimmt er nun an, das letzte ACK-Paket ist unterwegs verloren gegangen und sendet es erneut; immer in der Hoffnung, den Server nun doch noch zum Senden der versprochenen Daten zu überreden.

Da endete dann der letzte tcpdump wohl auch schon und man konnte nichts mehr von der folgenden Konversation sehen, insbesondere nicht, ob die Daten dann doch noch in derselben Verbindung übertragen wurden (oder sie mit einem FIN-Paket abgebaut wurde) oder ob eine neue TCP-Verbindung aufgemacht wurde, die dann endlich funktionierte.

Der Server auf dem Notebook müßte also - vor der Pause - bereits 4 Pakete (1, 3, 4, 7) vom Client erhalten haben und seinerseits mindestens 3 Pakete (2, 5, 6) gesendet haben. Wenn er das ACK im Schritt 7 empfängt, müßte er hintereinander genug Pakete senden, daß die "Window Size" erreicht wird. Erst dann sollte er auf ein erneutes ACK vom Client warten.

Die Frage ist also jetzt eigentlich, fehlt das ACK aus Schritt 7 (dann sendet der Server wirklich nichts) oder kommen die Pakete vom Server nicht zum Client durch. Wenn der Server sendet und irgendjemand unterwegs die Pakete wegen der Forderung "nicht fragmentieren" (DF-Flag gesetzt) ablehnt, weil er sie ohne Fragmentierung nicht übertragen kann, muß der ablehnende Router den Absender (also den Server) darüber mit einer ICMP-Nachricht informieren.

Während der Verbindungsaufbau mal wieder hängt, steht bei den empfangenen Paketen immer 0.
Worauf basiert dieser Zähler denn ? Auf HTTP-Paketen oder auf IP-Paketen ?

PS: Ich habe jetzt erst mitbekommen, daß die angehangene txt-Datei wohl ein tcpdump-Capture ist ... ich schaue mal rein. Den Text lasse ich aber trotzdem stehen, wer weiß wozu es noch gut ist ...
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.