Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime
From: Keith W. McCammon (km@km.com)
Date: 03/20/03
- Next message: Dave: "Xcopy data from NT40 server to Server2000"
- Previous message: Jack: "Prevent game play on company workstations"
- In reply to: Ray: "Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime"
- Next in thread: Ray: "Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime"
- Reply: Ray: "Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Keith W. McCammon" <km@km.com> Date: Thu, 20 Mar 2003 11:24:06 -0500
> This brings up a couple more questions. I've configured the Web
server
> as follows: ISM | WWW Service | Edit | Web site tab | Connection Timeout =
> 300 seconds| & Home Directory tab | Configuration | App Options Tab |
> Session timeout = 5 minutes. I was under the impression these settings
were
> all different.
They are.
> For instance the TCP resources would be held (by default)
> for 2 hours while the http connection resources (10 kb per connection)
would
> be for 5 minutes (15 by default but I reduced it).
TCP resources are not held for two hours. A single HTTP 1.0 GET opens a TCP
connection, makes the request, receives the reply, and then closes the TCP
connection. HTTP 1.1, on the other hand, uses HTTP keep-alives by default.
When HTTP keep-alives are used, multiple GET requests could be sent via the
same TCP connection, reducing the overhead of opening multiple TCP
connections between the same hosts.
In either case, an HTTP connection that is not used for 900 seconds (600 in
your case) would be actively closed by IIS, thus closing the TPC connection
as well.
> In addition, the App
> Session State was something else too.
App session state controls application-side sessions created using ASP, PHP,
etc. These are entirely different that both TCP and HTTP sessions.
Application sessions are used within the web-based application to track
users and store information associated with a user's visit. These can be
created by using the ASP session object, cookies, etc.
> Maybe if you had an example of an
> application that did not close the connection after the transaction was
> complete.
Can't think of one off the top of my head, because most day-to-days apps
would close a session once a given transaction was complete. Maybe someone
else will chime in on this...
> I think what adds to my confusion is that http is stateless.
It is.
> From that, I assume that the http (layer 7) session will be closed while
the
> tcp (layer 4) will still allocate the resources until 2 hours has expired
In theory, this could happen. However, client/server implementations
provide for interaction with the TCP that let it know when a session is no
longer needed. If the two were entirely separate, and every TCP-based app
just allowed every connection to linger for the maximum segment lifetime,
memory use would be out of hand. Part of implementing these types of
applications involves issuing timely calls to the TCP.
-- Keith W. McCammon
- Next message: Dave: "Xcopy data from NT40 server to Server2000"
- Previous message: Jack: "Prevent game play on company workstations"
- In reply to: Ray: "Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime"
- Next in thread: Ray: "Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime"
- Reply: Ray: "Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
