2011/4/5 Willy Tarreau <[email protected]> > On Tue, Apr 05, 2011 at 04:31:38AM +0200, Cyril Bonté wrote: > > Hi Marcin, > > > > Le lundi 4 avril 2011 23:39:22, Marcin Gozdalik a écrit : > > > Hi > > > > > > I'm trying to put RTMPT ( > > > http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) traffic > through > > > HAProxy. It seems to work well for a while but after that HAProxy > replies > > > with 400 Bad request. I though it might be a problem with HTTP header > > > length (RTMPT sends on idle connections dummy headers thus inflating > HTTP > > > header length), but I am not sure as there are several big headers > which > > > HAProxy accepts and replies 200 OK. I would appreciate any help with > > > debugging or reconfiguring HAProxy to handle RTMPT. > > > > > > The client here is Flash Player, so I can't really control what it > sends. > > > Proxying the same traffic via Apache mod_proxy works OK but I'd like to > > > separate my reverse proxy from backend Web servers. > > > > > > The capture is here: http://gozdal.com/rtmpt-400.pcap > > > > As you can see in the capture, idle requests duplicayes headers. Each > request > > sends a longer list of headers. After some times, the request becomes > longer > > than the haproxy buffer, which results in a 400 Bad Request. If it works > with > > mod_proxy, it's more by chance. > > > > The bug comes from the flash player plugin : > > https://bugs.adobe.com/jira/browse/FP-4797 >
Thanks for the link. It is indeed what I am experiencing. I though that the duplicated headers are sent as method to "fill up" idle connection, and are not sent in bulk (many headers in one packet) but every interval, 3 headers at a atime. > > It's not clear if it has been fixed in the last version. > > > > Do you need Layer 7 enabled in your configuration or "mode tcp" would be > an > > acceptable workaround ? > > Alternatively you can force haproxy to use larger buffers, but this will > eat > more RAM. You can do that like this : > > global > tune.bufsize 65536 > tune.maxrewrite 1024 > > The defaults are 16k and 8k, meaning that "only" 16-8 = 8kB are used as the > max request size. With the setting above, you'll have 64k for each request, > which will consume 128kB of RAM per connection. > > Anyway, this Flash bug will cause a big performance issue at some point, > because the clients really have to upload that many data, and this can > take a lot of time, especially in mobile environments, where uploading > 64kB can take up to about 30 seconds in some cases. > It did not help unfortunately. It seems Adobe shoot itself in the foot as RTMPT was working and was quite a reliable alternative to transport any stream over HTTP. I was mistaken referring to "Apache works" as a I tested it on previous version of Flash Player long time ago. Regards -- Marcin Gozdalik
