curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: [EXTERNAL] Re:Re: [HELP] What's the underlying connection reusing policy, can it be RR

From: Timothe Litt <litt_at_acm.org>
Date: Sun, 23 Jan 2022 06:24:21 -0500


On 23-Jan-22 05:46, Daniel Stenberg via curl-library wrote:
> On Sun, 23 Jan 2022, 白水月 wrote:
>
>> What I was doing is to send keepalive requests to the server. I'm
>> just wondering if there is a more graceful solution.
>
> TCP keepalive is rarely enough to maintain a connection. It usually
> also requires actual TCP traffic to go over it, which in the HTTP/2
> case could be PING frames like with curl_easy_upkeep(). Sometimes it
> will also require HTTP requests to prevent the server from killing
> connections for being idle.
>
> If you're using HTTP/1 you instead can do "no-op" HTTP requests, such
> as HEAD or OPTIONS.
>
>
HEAD can be expensive for a server - at a minimum it has to do a stat on
a file, but if the target is a program, it may require a lot more work
just to create the headers.  Even for the simple case where the resource
is a plain file, locks and/or IO may be required (think content-type,
content-length).  In any case, absent knowledge of the server, HEAD
should be assumed to cost the server as much as a GET, less the network
cost of sending the body.  It's an optimization primarily for the
client, not necessarily for the server.

OPTIONS is a much better choice for keep-alive.

If you don't own or have an arrangement with the server's operator,
keep-alive in any form may be considered abuse.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.


-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2022-01-23