2011/4/5 Willy Tarreau <w#1wt.eu>
> 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 GozdalikReceived on 2011/04/05 18:28
This archive was generated by hypermail 2.2.0 : 2011/04/05 18:30 CEST