HTTP-Response extrem fragmentiert

[Murray]

Hi,

ich sehe hier ein seltsames Phänomen, welches ich mir nicht erklären; leider soll muss ich es trotzdem abstellen.

Ich habe einen einfachen Web-Server, der bestimmte HTTP-Requests versteht und dann einfach über den OutputStream des Sockets die passenden Responses schreibt. Das funktioniert auch alles soweit: man kann (z.B.) mit einem Browser Requests an den Server schicken und sieht dann vernünftige Resultate (z.B. HTML-Seiten). Analysiert man den Traffic auf der Ebene des HTTP-Protokolls, sieht man keine Besonderheiten (ist ja auch nicht zu erwarten, denn es funktioniert ja). Wenn ich aber den Traffic "weiter unten" analysiere, dann sehe ich, dass der Response-Header auf sehr viele Frames verteilt wird; diese Frames enthalten nur wenige Bytes.

Das wäre ja jetzt eigentlich kein Problem (normalerweise hätte ich das nicht einmal bemerkt); allerdings gibt es jetzt Schwierigkeiten mit einem Traffic-Management-Gerät, welches offenbar (nix genaues weiß man nicht; alles ganz geheim) eine Stateful-Inspection betreibt und IP-Pakete abhängig von der Art des Traffic quasi sortiert: die von meinem Server gelieferten Responses fallen da jetzt irgendwie durch das Raster und werden nicht richtig als das erkannt, was sie sind (nämlich HTTP-Verkehr mit einem bestimmten content-type).

Zuerst dachte ich, da wäre vielleicht aus Versehen irgendwo die TCP_NODELAY-Option gesetzt; Socket.getTcpNoDelay liefert aber false.

Ist zufällig schon mal jemand über so ein Problem gestolpert?

 

[tuxedo]

Naja, da die Pakete vom Webserver kommen würde ich drauf tippen dass der Webserver an der Misere schuld ist. Oder hat du den Webserver auch selbst geschrieben? Du könntest auch mal nach dem Puffer auf dem Socket schauen. Der ist aber glaub ich per default 8k groß. Bin mir aber nicht sicher.

- Alex

 

[Murray]

Naja, da die Pakete vom Webserver kommen würde ich drauf tippen dass der Webserver an der Misere schuld ist. Oder hat du den Webserver auch selbst geschrieben?

Ja, genau. Ich bin mir da allerdings keiner Schuld bewusst ;-)

Du könntest auch mal nach dem Puffer auf dem Socket schauen. Der ist aber glaub ich per default 8k groß. Bin mir aber nicht sicher.

Stimmt, der Send-Buffer ist 8K groß; das habe ich schon geprüft. Insofern dürfte eine Vergrößerung wohl nichts bringen.

Es wird beim Schreiben des Headers auch nicht etwa mal der OutputStream geflushed (zumindest nicht explizit).

 

[Murray]

Falls jemand mal ein ähnliches Problem hat: ich umgehe das jetzt, indem ich den Header erstmal in einen Puffer (einen ByteArrayOutputStream) schreibe und erst am Ende den komplett fertigen Puffer in den SocketOutputStream schreibe. Das ist zwar a) nicht so schön, weil man Speicher verschwendet und b) immer noch keine Garantie dafür, dass der SocketOutputStream die Daten nicht trotzdem auf mehrere Frames verteilt, aber so funktioniert es wenigstens.

 

[kaesebrot]

Hi,

du könntest alternativ auch den SocketOutputStream in einen BufferedOutputStream verpacken.


viele Grüße,
Käse