libcurl和DNS ttl中的内部连接管理 [英] Internal connection management in libcurl and DNS ttl

问题描述

libcurl缓存连接，并将其重用于连续的请求. 假设我有4个连接到example.com，并且需要建立第5个连接. Libcurl将尝试建立与example.com的新的第5个连接. 如果在为example.com DNS结果创建第5个连接的TTL时过期，该怎么办?我想libcurl不会缓存DNS结果，而只是查询OS解析器(我不使用ares)，并且如果example.com在缓存中过期，则会发出新的DNS请求. 现在，让我们假设对example.com的原始4个请求被解析为对1.1.1.1的请求，而第5个请求被解析为5.5.5.5.

libcurl caches connections and reuses them for consecutive requests. Suppose I have 4 connections in progress to example.com and I need to make 5th connection. Libcurl will try to establish new 5th connection to example.com. What will happen if at the time the 5th connection is created TTL for example.com DNS result expired? I suppose libcurl doesn't cache DNS results and simply queries OS resolver (I don't use ares), and if example.com expired in the cache a new DNS request will be made. Now, let's suppose original 4 requests to example.com were resolved as requests to 1.1.1.1 and 5th request was resolved as 5.5.5.5.

• libcurl中的内部连接缓存会发生什么?
• 这四个请求完成后，libcurl是否会丢弃"并关闭与1.1.1.1的连接?
• 如果我也有对something.com的请求，但该请求也解析为1.1.1.1 ip，怎么办?

• What will happen to internal connection cache in libcurl?
• Does libcurl "throw away" and close connections to 1.1.1.1 when these 4 requests complete?
• What if I also had requests to something.com that also resolved to 1.1.1.1 ip?

如果有问题，我可以使用curl mutli接口.

If it matters I use curl mutli interface.

推荐答案

curl有自己的内部DNS缓存，默认情况下它将在其中缓存解析的地址60秒(您可以更改).因此，具有相同名称的后续解析将在该时间范围内使用缓存的结果.

curl has its own internal DNS cache, where it will cache resolved addresses for 60 seconds by default (you can change that). Subsequent resolves of the same name will thus use the cached results within that time frame.

curl的连接缓存完全基于URL中使用的主机名，因此，如果缓存中已有与"example.com"的可用连接，则该连接将用于对同一主机名的后续请求. curl既不知道也不关心该名称的IP地址是什么，或者从连接开始以来它是否已更改.重用连接时，它将跳过整个名称解析阶段.

curl's connection cache is entirely based on the host name used in the URL so if you have an existing available connection to "example.com" sitting in the cache, that will be used for a subsequent request to that same host name. curl doesn't know nor care what the IP address for that name is or if it changed since the connection was started. It skips the entire name resolving phase when reuses a connection.

当传输完成并且连接仍处于活动状态时，该连接将放回到连接缓存中(如果由于达到限制而被视为满"缓存，则将其关闭).

When a transfer is done and the connection is still alive, the connection is put back into the connection cache (or closed if the cache is deemed "full" due to having reached a limit).

由于连接重用是基于名称完成的，因此拥有另一个名称来解析现有连接的相同IP的名称将不会使curl重复使用该连接.它将解析名称并为此创建一个新的连接.

Since the connection reuse is done based on names, having another name that resolves to the same IP of an existing connection won't make curl reuse that connection. It will resolve the name and create a new connection for that.

除非连接被杀死以腾出空间或被重用，否则连接可以在连接缓存中保留无限的时间.如果它死了"(由于它从另一端关闭了)，那么当它被注意到时，它将最终从缓存中删除.

A connection can be kept in the connection cache for an unlimited period of time unless it gets killed to make room or gets reused. If it "dies" (due to it getting closed from the other end) it will eventually be removed from the cache when that gets noticed.

PING帧等不会(atm)用于连接缓存中的连接，这将导致它们很快被服务器杀死. (libcurl 7.62.0添加了新的API，以允许应用程序也保持此类连接保持活动状态，请参见 curl_easy_upkeep )

PING frames etc that can be sent over HTTP/2 will not (atm) be handled for connections in the connection cache, which will lead to them getting killed by the server within soon. (libcurl 7.62.0 adds a new API to allow applications to keep such connections alive as well, see curl_easy_upkeep)

curl 7.62.0中引入了DoH(DNS-over-HTTPS)支持后，DNS缓存将缓存TTL秒数的名称，而不仅仅是使用默认的60秒.

With the introduction of DoH (DNS-over-HTTPS) support coming in curl 7.62.0, the DNS cache will cache the names for TTL number of seconds and not just the default 60 when that is used.

有一些局限性，条件和极端情况破坏了这里所解释的内容，但这是基础.

There are some limitations, conditions and edge cases that break what's explained here, but this is the basics.

这篇关于libcurl和DNS ttl中的内部连接管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！