|
-----Original Message-----
发件人: Peter Kese <peter.kese@xxxxxx>
收件人: linux-virtualserver@xxxxxxxxxxxx <linux-virtualserver@xxxxxxxxxxxx>
日期: 1999年2月3日 22:56
主题: Tunneling & Timeouts
>
>For the past few days, I have been exploring the VS-Tunneling
>functionality and I came up with a question I can't answer myself...
>
>Let's suppose I set up a tunneling VS configuration for a web or proxy
>server. Clients send the requests (through the VS router) and the
>servers reply directly to clients. When the transfer is finished, the
>server closes the TCP socket. That means it sends an IP packet to the
>client to notify it that the socket had been closed. But this IP packet
>does not get intercepted by the VS and the masquerading entry remains in
>the hash table and stays there for the next 15 minutes until the
>TCP/masq timeout mechanism decides the connection is dead.
>
>Am I right?
Yes, you are right. I found the same problem after implementing the
virtual server via IP tunneling codes, but I didn't think it is
serious and didn't spend time fixing it. :-(
>
>If I am, than we might be in trouble. In a web proxy configuration, the
>amount of hourly requests easily exceeds 100000 requests per hour. That
>means that in each moment there would be 25000 'zombie' masquerading
>entries messing up the hash table.
>
>Any ideas?
To release a TCP connection, each party can send a TCP segment
with the FIN bit set. When the FIN is acknowledged, the direction
is shutdown. When both directions have been shut down, the connection
is released. Normally, four TCP segments are needed to release
a connection, one FIN and one ACK for each direction. However, it
is possible for the first ACK and the second FIN to be contained
in the same segment, reducing the total count to three. The secenario
of releasing a connection in virtual server via IP tunneling is
illustrated as follows:
<--------------FIN--------------
Client <--------------ACK-------------- Server
----------FIN----------| |----->
----------ACK----------| |----->
VS-Router
So, the VS-router can only get one FIN and one ACK. In the original
masquerading expiring code, when two FINs (IP_MASQ_F_SAW_F_IN and
IP_MASQ_F_SAW_F_OUT) are detected, the masquerading entry is set to
be expired in the MASQUERADE_EXPIRE_TCP_FIN (2 minutes).
When the local node feature is enabled in virtual server via NAT, the
connection to the local server also have the same problem, because
the local server sends the FIN segment to the client directly.
I changed the masquerading code today that when the IP_MASQ_F_SAW_F_IN
is received to set the masquerading entry to be expired in the
MASQUERADE_EXPIRE_TCP_FIN (2 minutes). In the most applications, two
FINs are not sent very far. Even when the IP_MASQ_F_SAW_F_IN is received
and the entry is expired in 2 minutes, the server can still send
a large volume of data to the client if the first ACK of receiving data
return in 2 minutes. Therefore, I think the change can fix the long
timeout problem and won't get problems in most cases.
I also set up an option to set the IP masquerading table size while
configuring the kernel. It is more flexible than users modify the
source code manually.
Both changes are in the attached patch, which can be applied to a
fresh copy of Linux kernel 2.0.36.
I would like to include it into the version 0.7 patch (maybe the
version 1.0pre1). Before I do, I would like to hear your answers.
Thank you,
Wensong
>
>Cheers,
> Peter
>
patch-vs-2.0.36-v0.7.gz
Description: Binary data
|
