IIS / TCP RST instead of FIN
ambrishverma
Christof Wegmann wrote:
IIS / TCP RST instead of FIN
20-Feb-09
We have a similar problem with the behavior of the IIS. I found a paper that shades some light on this issue:
http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf
An extract ... "The results in Table 3 illustrate two main points. First, among the four di erent Web servers tested, three
used the proper FIN handshake to terminate an idle persistent connection, while one (Microsoft IIS) used a TCP
RST. This type of server behaviour is likely responsible for many of the responder RSTs (RSTR) observed in the
campus TCP traffic. This feature of IIS is used to reduce the number of connections that enter the TIME WAIT
state on the server [6]."
So it looks like the RST behavior is expected and again MS implements something different than all the other web servers *sigh*.
Chris
Previous Posts In This Thread:
On Thursday, September 18, 2008 9:20 AM
ThomasOlsso wrote:
Weird tcp/ip session problem using IIS 7
We have a web site running on Windows Server 2008 (x86). It uses ASP.NET.
Sometimes the web browser does not get any response and there is a timeout
after a while. The pattern is that we go to one page, wait a couple of
minutes and then press Refresh (F5). Once in a while, we do not get any web
page and there is a timeout. If we do not wait long enough it will work. If
we press F5 once a minute, it will work every time.
We have investigated this further. No requests came to our ASP code. First
of all, we looked for errors in the Event Log or IIS logs. Nothing.
We then enabled logging for http.sys. First of all we could not see any
requests at the time when we refreshed the client and it resulted in a
timeout.
However we could see that 3-4 minutes after the previously successful event,
http.sys wrote that there was an idle timeout and that the session was closed.
It is only after such events that we run into problems. But not always.
By using Network Monitor we looked at the tcp/ip traffic between the client
and the server. We could then see that most of the time there was a session
"reset" packet sent at the same time as the "idle timeout" message in the
http.sys log. Sometimes the session was closed by the client instead, but in
those cases there was a different message in the log. However, in those cases
were we got a timeout on the client side, we could see that http.sys had
logged "idle timeout", but we could not see a corresponding "reset" packet in
the network log. When the client tried to send data on the same port, the
server simply did not respond. It seemed to think that the tcp/ip session was
closed, but no tcp/ip packet had been sent from the server to notify the
client.
We have upgraded to the last version of the NIC driver, but still see the
same thing.
We have not been able to see at pattern in when this happens. It seems like
http.sys has some timer that looks for idle sessions once a minute or so. We
often see in the log that it closes several idle sessions at the same time.
In the network log we also see that several sessions are closed. Sometime we
see like five messages together in the http.sys log about closed sessions,
but we see only four tcp/ip reset packages in the network log.
Any ideas any?
--
Thomas Olsson
On Thursday, September 18, 2008 4:16 PM
ThomasOlsso wrote:
I have Network Monitor installed on the web server and thus see the traffic
I have Network Monitor installed on the web server and thus see the traffic
directly on the server. No firewalls or NAT involved there.
One idea we had when we first saw that we did not get a response on the
client was that our ASP application was hung or had crashed in some way. We
looked for application restarts or some error on that level. That is why I
mentioned that there is nothing in the event log. Further investigation has
shown that our app is doing fine. IIS is also fine. No errors are indicated
in the http.sys log either.
The problem is clearly that http.sys regards the tcp/ip session as closed,
but the client does not.
As I said, when we see in the http.sys log that it closes the connection
because it has been idle for some time, we normally see this in the Network
Monitor data, but every now and then there is no packet going out when
http.sys says that it has closed the session and it is when this happens that
we run into problem when the client tries to use that session.
I thing that struck me when I looked at the Network Monitor logs is that
even when the sessions are closed, they are closed by a Reset package. Why is
the server sending a tcp/ip reset and not closing the session in the well
behaved way using a packet with the "Fin" flag set?
--
Thomas Olsson
"David Wang" wrote:
On Friday, September 19, 2008 5:26 AM
David Wang wrote:
Re: Weird tcp/ip session problem using IIS 7
On Sep 18, 6:20=A0am, Thomas Olsson
<ThomasOls...@discussions.microsoft.com> wrote:
t
eb
If
t
nt,
osed.
nt
on
in
ases
t in
was
ke
We
e.
we
,
It sounds like your webserver is behind some other NAT/networking
device which is causing problems by pooling connections made by the
browser. If so, you need to fix that networking device.
The Event Log can *never* contain any request-associated failures. If
it did, then an anonymous attacker can easily spam the Event Log.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Friday, September 19, 2008 5:26 AM
David Wang wrote:
Well, if you think it's a bug in HTTP.
Well, if you think it's a bug in HTTP.SYS, then you should contact
Microsoft PSS and open a support case, especially if it is easily
reproducible for you.
Of course, if you do that and then it is discovered to be a problem
elsewhere outside of Windows and Microsoft products, then the support
case is going to cost you money. Hence, I first look at any possible
interaction BETWEEN the server and client.
If you are confident that there is no intervening network device and
that the problem is in the way HTTP.SYS is responding, then you should
contact PSS directly. No other channel will be able to do anything for
you other than listen to you.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Sep 18, 1:16=A0pm, Thomas Olsson
<ThomasOls...@discussions.microsoft.com> wrote:
ic
We
I
as
ed
,
rk
that
y is
NET.
meout
f
ny web
rk. If
First
ny
a
event,
s closed.
s.
client
ession
the
but in
se cases
had
acket in
the
sion was
the
the
s like
so. We
time.
time we
ions,
On Friday, September 19, 2008 7:56 AM
ThomasOlsso wrote:
I am perfectly sure that it is the lack of proper tcp/ip session termination
I am perfectly sure that it is the lack of proper tcp/ip session termination
that is causing this problem. However, I am not sure if the problem is in the
OS, http.sys, NIC drivers or perhaps even in our ASP.NET code.
My biggest concern is that it is something that we have done wrong that
causes this, but I really cannot figure out how we could possibly cause such
a problem from ASP.NET.
We have now tried with a completely different NIC with Broadcom chips
instead of the Intel card we had before. The problem is still there. I guess
that this rules out the NIC or NIC drivers.
I guess it is time for PSS then.
--
Thomas Olsson
"David Wang" wrote:
On Friday, February 20, 2009 3:14 AM
Christof Wegmann wrote:
IIS / TCP RST instead of FIN
We have a similar problem with the behavior of the IIS. I found a paper that shades some light on this issue:
http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf
An extract ... "The results in Table 3 illustrate two main points. First, among the four di erent Web servers tested, three
used the proper FIN handshake to terminate an idle persistent connection, while one (Microsoft IIS) used a TCP
RST. This type of server behaviour is likely responsible for many of the responder RSTs (RSTR) observed in the
campus TCP traffic. This feature of IIS is used to reduce the number of connections that enter the TIME WAIT
state on the server [6]."
So it looks like the RST behavior is expected and again MS implements something different than all the other web servers *sigh*.
Chris
Submitted via EggHeadCafe - Software Developer Portal of Choice
Task Parallelism in C# 4.0 with System.Threading.Tasks
http://www.eggheadcafe.com/tutorials/aspnet/21013a52-fe11-4af8-bf8b-50cfd1a51577/task-parallelism-in-c-40-with-systemthreadingtasks.aspx
Ken Schaefer
Cheers
Ken
"Ambrish Verma" wrote in message news:201061822...@microsoft.com...