Re: HTTP slower than SSH on client behind iptables

[Boryan Yotov <yotov@prosyst.com>]

Adam Rosi-Kessel wrote:
> On Thu, Feb 02, 2006 at 09:56:13AM -0500, Adam Rosi-Kessel wrote:
> 
>>On Tue, Jan 31, 2006 at 10:10:53AM +0100, Boryan Yotov wrote:
>>
>>>>On clients behind the NAT box, however, HTTP connections seem to top out
>>>>around 70 kilobytes per second. ssh connections (e.g., rsync) get the
>>>>full throughput of the Internet connection.
>>>>As far as NAT goes, I don't hvae any special settings.
>>>>Can anyone think of an explanation for this behavior? It doesn't make any
>>>>sense to me.
>>>
>>>Are you sure, you don't have some kind of a traffic shaping
>>>active on the NAT gateway's internal interface?
>>>For example: If tc is used, you could check that using:
>>>tc class show dev <nat_box_internal_interface>
>>>and
>>>tc filter show dev <nat_box_internal_interface>
>>
>>I figured it out. Apparently I was missing some kernel modules that were
>>causing wondershaper to behave oddly. I rebuilt the kernel with all QOS
>>and netfilter configuration options enabled (or built as modules) and now
>>internal clients can download HTTP at full speed. I suspect there was
>>some option that was causing tc to not distinguish between interfaces
>>despite the fact that wondershaper instructed it to only throttle the
>>external interface. I'm not sure exactly which kernel setting fixed it,
>>but it is now fixed.
> 
> 
> Actually, I didn't figure it out! Apparently, just rebooting the NAT
> system returns everything to full speed. Something happens, either over
> time, or as the result of some occasional event, that causes internal
> connections to be throttled. Any ideas what this could be?
> 

A good starting point is to retrieve the "tc" status, first
when the NAT gateway is restarted and performs correctly, and
once more when you notice that your client are receiving their
HTTP responses throthled.

To get a complete picture of the "tc" status, first retrieve
the qdisc assigned to each interface:

   # tc qdisc  show

And then retrieve the classes and assigned filters for each
of the interfaces shown in "tc qdisc show":

   # tc class  show dev <NEXT_DEVICE>
   # tc filter show dev <NEXT_DEVICE>

Once you have both states, then check if there is a differense
between them.

The idea here is to make sure your "tc" setup is not becoming
corrupted, when your external link need to be renegotiated (in
case of dynamic IP address assignment found with DSL and Cable
modems).




Another thing worth to try is to check if you use the CBQ based
version of the wondershaper script. If true, then switch to the
HTB version and see if it performs better.