On Wed, 28 Apr 2004, Lizzy Dizzy wrote:
> 15:02:40.327058 spoffs96-166.abc.net.sg.3709 > test9.abc.net.squid: F
> 2014:2014(0) ack 9761 win 63715 (DF)
> **15:02:40.327073 test9.abc.net.squid > spoffs96-166.abc.net.sg.3709: . ack
> 2015 win 10217 (DF)
This looks like a minor kernel bug where the final ACK when tearing down
the connection has lost its TOS.
> 15:02:40.357688 spoffs96-166.abc.net.sg.3713 > test9.abc.net.squid: S
> 3763417607:3763417607(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> **15:02:40.357710 test9.abc.net.squid > spoffs96-166.abc.net.sg.3713: S
> 3042739657:3042739657(0) ack 3763417608 win 5840 <mss 1460,nop,nop,sackOK>
> (DF)
This is normal as this is the traffic long before the first HTTP request
have been sent or even before the connection has been accepted by Squid.
Where you added the TOS code it will only get set once Squid starts
sending a reply to the client. All traffic before that will use the
system default TOS (usually 0).
The earliest you can set the TOS in Squid is just after the connection
have been established. The difference is pretty minimal however as we at
best are talking about the TOS of one or two bare ACK packets ACK:ing the
client request data, and even then there is no guarantee on these as the
client request may well have been sent before Squid gets a chance to
accept the connection, especially if the client is on a LAN connection.
Regards
Henrik
Received on Wed Apr 28 2004 - 01:43:08 MDT
This archive was generated by hypermail pre-2.1.9 : Thu Apr 29 2004 - 12:00:03 MDT