Description
curl 7.65.3 with woflSSL v4.1.0, cares 1_15_0, test base on this code example: https://curl.haxx.se/libcurl/c/multi-uv.html
test from os: macOS, linux, android. all has same issue.
CURLINFO_PRIMARY_IP
, CURLINFO_PRIMARY_PORT
return null and 0 at CURLMSG_DONE
callback function. (test before curl_multi_assign(null)
, curl_multi_remove_handle
)
CURL_POLL_REMOVE
is called before CURLMSG_DONE
, I guess this could be the problem.
I use getpeername to get the socket peer IP, on step CURL_POLL_REMOVE
I can get the correct peer IP.
On step CURL_POLL_IN
, if socketp
is null, peer IP also is null. (Even I remove uv_close
from CURL_POLL_REMOVE
, so socket get reused without call uv_close)
I also try delay curl_multi_remove_handle
until before curl_easy_cleanup
get called, this will allow CURLINFO_ACTIVESOCKET
return a valid socket fd (without delay curl_multi_remove_handle
, CURLINFO_ACTIVESOCKET
return -1
when easy finished ).
According to https://ec.haxx.se/libcurl-connectionreuse.html:
When you are using the multi API, the connection pool is instead kept associated with the multi handle. This allows you to cleanup and re-create easy handles freely without risking losing the connection pool, and it allows the connection used by one easy handle to get reused by a separate one in a later transfer.
In the test code, connection not reused all the time.
The TLS session cache also get destroyed when multi handle perform a new host request.
For TLS version < 1.3, If the socket peer IP remain same, and domain remain same, TLS session cache still not work. I guess because TLSv1.2 no 0-rtt handshake, and connection is not reused(the TLSv1.2 session cache should speed up the connection time cost, but the test code show the same time cost ).
Activity
bagder commentedon Sep 5, 2019
Can you provide a small stand-alone example showing the problem?
patrickkh7788 commentedon Sep 5, 2019
Here is the test example, to build:
gcc tests.c -luv -lcurl -lssl -lng2 -lcares -lz
output:
It show socket closed at every call, and ssl session not working for domain:
https:/www.baidu.com
If I remove
CURLOPT_TCP_FASTOPEN
, then the TLSv1.2 session cache is not get destroyed. but still close the socket every time.the demo test on macOSX, linux, andoird. same results.
bagder commentedon Sep 5, 2019
If it closes the connection or not is not relevant. Does it return the info if you remove
CURLOPT_TCP_FASTOPEN
? Because that's an old unresolved bug, see #1332patrickkh7788 commentedon Sep 5, 2019
Yes, I can get info without TFO.
The much important problem is with TFO tls session cache not working.
And the connection is not get reused like document said.
[-]CURLINFO_PRIMARY_IP, CURLINFO_PRIMARY_PORT empty for multi handle [/-][+]CURLINFO_PRIMARY_IP, CURLINFO_PRIMARY_PORT empty with CURLOPT_TCP_FASTOPEN[/+]bagder commentedon Sep 5, 2019
... which then sounds like a separate issue, right?
patrickkh7788 commentedon Sep 5, 2019
The connection not get reused is a separate issue.
I am not sure the TLS cache is a separate issue, since it work as expect without TFO.
When do api call from China to EU or USA, the RTT is like 200ms to 2000ms, and tcp package get lost frequently. with TFO and 0-rtt TLSv1.3. the speed is get huge improve.
Without FASTOPEN, and a working TLS session cache, the ssl handshake time increased 2 ~ 3 times.
bagder commentedon Sep 5, 2019
The way I read it, issue #4296 says that CURLINFO_PRIMARY_IP and CURLINFO_PRIMARY_PORT don't work with TFO enabled. Which unfortunately already was known since #1332, making this basically a duplicate.
Now you're talking about "TFO tls session cache not working" which is not mentioned at all in the previous paragraph, thus separate (but possibly related).
patrickkh7788 commentedon Sep 5, 2019
Sorry for my poor English.
Correct me if I am wrong, I expect the curl work this way(by my understand from the document):
connection get reused for easy handle with multi api. (in this test socket get closed for every call, before easy handle destroyed)
TLS session cached when call same domain again (in this test, with TFO not working some times)
CURLINFO_PRIMARY_IP and CURLINFO_PRIMARY_PORT should show correct information. (in this test with TFO show NULL)
bagder commentedon Sep 5, 2019
All I'm asking is that we discuss one problem per issue. If you have more issues, then we discuss them in separate issues. Discussing numerous problems and theories in a single issue makes it hard to follow and understand what's going on.
patrickkh7788 commentedon Sep 5, 2019
Sorry for misunderstanding.
In here we can focus on
CURLINFO_PRIMARY_IP and CURLINFO_PRIMARY_PORT
with TFO return null problem.