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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
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.
Received on 2022-01-23
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
- application/pgp-signature attachment: OpenPGP digital signature