Bug #80830 [Opn->Fbk]: Running out of local ports when using curl
| From: | cmb@php.net | Date: | Mon, 06 Dec 2021 12:47:15 +0000 |
| Subject: | Bug #80830 [Opn->Fbk]: Running out of local ports when using curl | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-238213@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=80830&edit=1
ID: 80830
Updated by: cmb@php.net
Reported by: external dot maik dot dieterich at bosch dot com
Summary: Running out of local ports when using curl
-Status: Open
+Status: Feedback
Type: Bug
Package: Network related
Operating System: Windows Server 2019
PHP Version: 7.4.15
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
PHP 7.4 is out of active support; is this still an issue for you
with PHP 8.0 or 8.1?
Previous Comments:
------------------------------------------------------------------------
[2021-03-12 08:39:03] external dot maik dot dieterich at bosch dot com
Hello,
yes we are using apache2handler SAPI and each request initializes a curl handle.
But also if I'm initialize a curl handle in a cli application and close it the connection I
openend is closed but the corresponding local to local port connection, which i have not explicit
opened, stays in TIME_WAIT.
When I'm opening and close the same connection with curl from command line without PHP i can
not see such a local to local port connection.
Thanks for the support.
------------------------------------------------------------------------
[2021-03-09 11:54:57] cmb@php.net
To clarify: you are not initializing multiple curl handles in a
single request, but rather for different requests, and you are
using the apache2handler SAPI?
In this case there may indeed be a problem, since the SAPI
intializes libcurl (curl_global_init()) at its startup and shuts
it down (curl_global_cleanup()) at its shutdown, so libcurl might
keep connections open, but may not reuse them.
> It's causing localhost to localhost TIME_WAITs.
Frankly, I have no idea why that happens. The curl extension is
relatively thin wrapper around libcurl, so I wonder whether we set
up or use libcurl inappropriately, or whether Apache or the SAPI
interferes.
------------------------------------------------------------------------
[2021-03-09 08:23:25] michael dot mckeever at bosch dot com
Thank you @danack and @cmb for the quick response.
Your suggestions with reusing the the curl handle is correct if you're using a cli application
and you're in control of the environment.
The problem described by Maik is that if you're using apache you can't reuse curl handles.
@rtrtrtrtrt, your comment is unfortunately not helping in this topic ;-)
The key question is, why is the mass usage of curl.exe not causing TIME_WAITs and the php libcurl
functions causing TIME_WAITs. Furthermore the php functinos are not causing TIME_WAITs to the called
server as one would expect, but it's causing TIME_WAITs for some kind of local redirects.
It's causing localhost to localhost TIME_WAITs.
------------------------------------------------------------------------
[2021-03-04 20:07:01] rtrtrtrtrt at dfdfdfdf dot dfd
it's just how TCP works
https://superuser.com/questions/173535/what-are-close-wait-and-time-wait-states
------------------------------------------------------------------------
[2021-03-04 18:32:27] external dot maik dot dieterich at bosch dot com
First thanks for the quick response.
What is not clear for me, is why the connection I open to the external server can be closed
immediately and why this local local port connections, which i do not have if i use curl from
command line, are still open even if the external connection I open is closed.
Because each connection is opened in a different thread i think I can not reuse them.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80830
--
Edit this bug report at https://bugs.php.net/bug.php?id=80830&edit=1