php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #17044 TIME_WAIT status
Submitted: 2002-05-06 11:48 UTC Modified: 2002-07-01 16:29 UTC
Votes:5
Avg. Score:4.8 ± 0.4
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: gberger at apaara dot com Assigned:
Status: Not a bug Package: Sockets related
PHP Version: 4.2.1 OS: Linux Red Hat 7.0
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: gberger at apaara dot com
New email:
PHP Version: OS:

 

 [2002-05-06 11:48 UTC] gberger at apaara dot com 
this is my setup:
php 4.2.0 with the socket extension, as a dynamically loaded module in apache 1.3.23. it is running on is a red hat 7.0 box with kernel 2.2.19.

this is was i am trying to do: 
i am using the socket functions to connect to a server which is running a ticketing software using a specifically designed protocol; the details do not matter here. i'll call my webserver "webserv.com", the client calling the script "client.com" and the ticketsystem "tixserv.com".

i think i am doing everything by the book - just a simple one-shot tcp-client; writing some request to tixserv.com, reading the response and closing the connection. i am using socket_create(), socket_connect(), socket_write(), socket_read(), and finally socket_close(), pretty much the same way as the example 2 ("Simple TCP/IP client") in the php manual. this seems to work well (no errors or warnings).

this is my problem:
if i monitor the connection attempts with netstat, i am seeing the following behaviour:

firstly, connections are established: from webserv.com to client.com and from webserv.com to tixserv.com:

tcp    webserv.com:1558     tixserv.com:45007    SYN_SENT    1126/httpd          
tcp    webserv.com:www      client.com:1894      ESTABLISHED 1126/httpd          

then, the connection from webserv.com to tixserv.com is closed (using socket_close() in the script), so the connection status goes to TIME_WAIT:

tcp    webserv.com:1558     tixserv.com:45007    TIME_WAIT   -                   
tcp    webserv.com:www      client.com:1894      ESTABLISHED 1126/httpd          

i see that to go to TIME_WAIT status is the correct way to behave for a socket. but the problem is that httpd somehow seems to wait for the TIME_WAIT status to go away and keeps the connection open during this time (ESTABLISHED). this takes a really long time (at least 30 seconds or more). at some time, the TIME_WAIT of the connection to tixserv.com finally goes away, and the connection to the client falls into that state:

tcp    webserv.com:www      client.com:1894      TIME_WAIT   -                   

strange - my browser and php seem to ignore this: the script execution, measured with microtime(), is around 800 miliseconds, of which at least 90% is response time by tixserv.com which is fine. also, my browser does not need more than a second to display the script results. nonetheless, the httpd connection on the server stays ESTABLISHED for at least 30 seconds.

the scary thing about this is that it gets worse if i start to stress the server. i used jakarta-jmeter to simulate simultaneous requests. jmeter did not behave the same as my browser: it actually waited until the httpd connection status was really closed. this totally stressed webserv.com: i had response times around 600 seconds and more, with only 5 threads doing 2 requests for the script. the load on webserv.com was huge during that time, sometimes i even had to stop apache to end the test.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-05-13 05:16 UTC] gberger at apaara dot com 
i have also tried this in a slightly different setting:
red hat 7.2, kernel-2.4.7 and php 4.1.2.

in this environment, both tcp-connections go right to the TIME_WAIT status and stay there for 1 minute (which seems to be 2MSL); the tcp connection owned by httpd is not waiting in ESTABLISHED mode as it does under kernel 2.2.
this seems to be a kernel-related issue, then? has anyone else experienced this problem?
 [2002-06-17 07:16 UTC] rick at simpleftp dot co dot uk 
Are you sure this isn't the keep-alive part of the HTTP protocol? AFAIK, most browsers will use a keep-alive header to keep the connection to the HTTP server open, even after it has received the entire document. That lets it speed things up as it doesn't have to reconnect to load another page, images or whatever.

There's details on the settings for it under Apache 1.3 at http://httpd.apache.org/docs/keepalive.html
 [2002-06-18 02:40 UTC] gberger at apaara dot com 
i partially agree - have not thought about this yet. well, so i went and turned KeepAlice Off in the apache conf. and yes, the described behaviour went away. so far, so good.

but there are still some points that make no sense to me:

- the TIME_WAIT status of these tcp connections stays there until timeout (after 2MSL has passed). that should not be the case if i am doing an active close, right?

- even with KeepAlive On: in my apache conf, the KeepAliveTimeout Directive is set to 15 seconds. but the tcp connection of httpd stays in ESTABLISHED state for much longer than 15 seconds. this should not happen, right?

probably, this is not a php issue anymore. i would be grateful for any pointers, though.

btw. i have upgraded to php 4.2.1 in the meantime.
 [2002-06-19 10:46 UTC] filippo at zirak dot it 
> probably, this is not a php issue anymore.

I think it still is a php bug (4.2.1)... even using it as command line script, it seems from netstat that the connection is not well closed... :-(

binding, accepting, (shutdowning,) closing a socket on 19731 leave anyway the connection open in TIME_WAIT

tcp 0 0 localhost:19731   localhost:32861  TIME_WAIT
 [2002-06-19 11:13 UTC] gberger at apaara dot com 
as i have discussed with others in the meantime, i think the TIME_WAIT status is not the problem:

the process that is opening a tcp-connection from webserv to tixserv needs to stay in TIME_WAIT, in case its last ACK is lost and tixserv sends its FIN again. webserv is acting as client here and has to stay in TIME_WAIT for 2MSL. 

the thing i do not understad is that in the praticular case described, the tcp connection opened to the browser stays in TIME_WAIT as well; this should not be, since webserv is the server in this case. probably, this is an apache issue.

just because i'm curious, fillipo: what kernel and what apache do you use?
 [2002-06-24 09:07 UTC] filippo at zirak dot it 
the thing i do not understad is that in the praticular case described,
   the tcp connection opened to the browser stays in TIME_WAIT as well;
   this should not be, since webserv is the server in this case. probably,
   this is an apache issue.

   just because i'm curious, fillipo: what kernel and what apache do you
   use?
 [2002-06-24 09:12 UTC] filippo at zirak dot it 
> probably, this is an apache issue.
> just because i'm curious, fillipo: what kernel and what apache do you use?

kernel 2.4.4
no Apache!

I'm finding the same TIME_WAIT bug also with client/server (both written in php) architecture, not found with other php4 < 4.2.1...

for that I think it may be a kernel or php problem (I've to check kernel), but not Apache, at least in my case.

phy
 [2002-06-24 10:20 UTC] filippo at zirak dot it 
Resume:
server socket (accepted) will cause a 60secs TIME_WAIT even after a  socket_shutdown+socket_close ...
(it's difficult it a kernel problem, as I've checked with other tcp-servers, and they behave normally...)

... hope it helps...
phy
 [2002-06-24 10:52 UTC] prakash at libero dot it 
same problem on kernel 2.2.16 and php 4.2.1
and kernel 2.2.16 and php 4.1.2...
 connections are accepted but cannot be closed properly.
prakash
 [2002-06-25 05:41 UTC] filippo at zirak dot it 
trying to temporarily use a "daemontools" way... found a CLOSE_WAIT problem...

http://bugs.php.net/bug.php?id=17964

are php-sockets well tested ?!?   ;-P
	Filippo
 [2002-07-01 16:29 UTC] jason@php.net 
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php

Thank you for your interest in PHP.

I read this thoroughly, and it looks like Keep-Alive was the actual problem here.

I can't see anything here that would relate to a php bug.
TCP connections have a 2MSL TIME_WAIT status, and this is just an aspect of TCP.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Jan 15 13:01:29 2025 UTC