Caches

libcurl caches different information in order to help subsequent transfers toperform faster. There are four key caches: DNS, connections, TLS sessions andCA certs.

When the multi interface is used, these caches are by default shared among allthe easy handles that are added to that single multi handle, and when the easyinterface is used they are kept within that handle.

You can instruct libcurl to share some of the caches with theshare interface.

DNS cache

When libcurl resolves a hostname to one or more IP addresses, that is storedin the DNS cache so that subsequent transfers in the near term do not have toredo the same resolve again. A name resolve can easily take several hundredmilliseconds and sometimes even much longer.

By default, each such hostname is stored in the cache for 60 seconds(changeable withCURLOPT_DNS_CACHE_TIMEOUT).

libcurl does in fact not usually know what the TTL (Time To Live) value is forDNS entries, as that is generally not exposed in the system function calls ituses for this purpose, so increasing this value come with a risk that libcurlkeeps using stale addresses longer periods than necessary.

Connection cache

Also sometimes referred to as the connection pool. This is a collection ofpreviously used connections that instead of being closed after use, are keptaround alive so that subsequent transfers that are targeting the same hostname and have several other checks also matching, can use them instead ofcreating a new connection.

A reused connection usually saves having to a DNS lookup, setting up a TCPconnection, do a TLS handshake and more.

Connections are only reused if the name is identical. Even if two differenthostnames resolve to the same IP addresses, they still always use two separateconnections with libcurl.

Since the connection reuse is based on the hostname and the DNS resolve phaseis entirely skipped when a connection is reused for a transfer, libcurl doesnot know the current state of the hostname in DNS as it can in fact change IPover time while the connection might survive and continue to get reused overthe original IP address.

The size of the connection cache - the number of live connections to keepthere - can be set withCURLOPT_MAXCONNECTS (default is 5) for easy handlesandCURLMOPT_MAXCONNECTS for multi handles. The default size for multihandles is 4 times the number of easy handles added.

TLS session cache

TLS session IDs and tickets are special TLS mechanisms that a client can passto a server to shortcut subsequent TLS handshakes to a server it previouslyestablished a connection to.

libcurl caches session IDs and tickets associated with hostnames and portnumbers, so if a subsequent connection attempt is made to a host for whichlibcurl has a cached ID or ticket, using that can greatly decrease the TLShandshake process and therefore the time needed until completion.

CA cert cache

With some of the TLS backends curl supports, it builds a CA cert store cachein memory and keeps it there for subsequent transfers to use. This letstransfers skip unnecessary loading and parsing time that comes from loadingand handling the sometimes rather big CA cert bundles.

Since the CA cert bundle might be updated, the life-time of the cache is bydefault set to 24 hours so that long-running applications will flush the cacheand reload the file at least once every day - to be able to load and use a newversion of the store.

Applications can change the CA cert cache timeout with theCURLOPT_CA_CACHE_TIMEOUT option in case this default is not good enough.