Gateways

HTTP Gateway Time To First Byte

This graphs shows daily aggregates of the Time to First Byte (TTFB) latency for all probed HTTP gateways. We collect the data with our Tiros measurement suite. The tooltip shows the number of samples that went into the calculation of each data point.

Tiros makes requests for the /ipfs/{cid} path endpoint as opposed to the corresponding subdomain (https://{cid}.{gateway_domain}). This means that the retrieval performance for some gateways includes round-trips to resolve redirects. Subdomain gateways are generally more secure because of improved origin isolation at the expense of additional round-trips to resolve to the subdomain.

The data is segmented along the dimensions: region, cache status, and CID source.

Region

We have deployed our Tiros measurement suite in different AWS regions around the world. They correspond to the following region identifiers:

• eu-central-1: Europe (Frankfurt)
• us-east-2: US East (Ohio)
• us-west-1: US West (N. California)
• ap-southeast-2: Asia Pacific (Sydney)

Cache Status

Each time Tiros probes an HTTP gateway, it sends two requests for the same CID one after another. With the first request we attempt to trigger an uncached response and with the second request we attempt to trigger a cached response. We determine whether a request was cached or not by parsing the response headers and evaluating the headers: cf-cache-status, x-filebase-edge-cache, and x-cache.

CID Source

We have two types of sources for CIDs that we request from the gateways: controlled and organic. The controlled CIDs correspond to random 1kB data blobs that we host on a controlled Kubo node in us-east-1. The idea is to use these blobs to measure a baseline performance of the gateways under controlled conditions.

The organic CIDs come from our Bitswap Sniffer tool that has picked them up by observing bitswap traffic. Measuring the retrieval performance for these CIDs can be used as a proxy to what users on average would perceive when interacting with IPFS gateways. It is useful to track long term trends.

Service Worker Gateway Time To First Byte

This graph shows daily aggregates of the Time to First Byte (TTFB) latency of the inbrowser.link Service Worker Gateway. We collect the data with our Tiros measurement suite. The tooltip shows the number of samples that went into the calculation of each data point as well as the fainted bars in the background.

Tiros makes requests for the https://inbrowser.link/ipfs/{cid} path endpoint in a headless Chromium instance and then measures the time until the first byte of the actual content was seen by the browser. This means that the TTFB performance includes the download and initialization of the service worker code and various redirects to configure the browser. The performance will likely be worse than the plain HTTP Gateways but you need to consider three things:

1. The service worker gateway verifies the downloaded bytes
2. The service worker gateway ensures proper subdomain origin isolation
3. Subsequent requests won't need to download the service worker code again and thus resolve much faster

In short, service worker gateways are generally more secure and once initialized subsequent retrievals don't exhibit the startup performance penalty.

The data is segmented along the dimensions: region, cache status, and CID source.

Region

We have deployed our Tiros measurement suite in different AWS regions around the world. They correspond to the following region identifiers:

• eu-central-1: Europe (Frankfurt)
• us-east-2: US East (Ohio)
• us-west-1: US West (N. California)
• ap-southeast-2: Asia Pacific (Sydney)

Cache Status

When the content for a CID is requested via a service worker gateway, it races two resolution paths:

1. a regular request to a trustless HTTP gateway (trustless-gateway.link in the case of inbrowser.link)
2. a delegated routing request plus direct retrieval from the actual peer

If the request was served internally served via a trustless gateway, we determine whether a request was cached or not by parsing the response headers and evaluating the headers: cf-cache-status, x-filebase-edge-cache, and x-cache.

The result can be a cache hit or miss. Thirdly, if the request was served directly by a peer, we mark that data as "direct".

CID Source

We have two types of sources for CIDs that we request from the gateways: controlled and organic. The controlled CIDs correspond to random 1kB data blobs that we host on a controlled Kubo node in us-east-1. The idea is to use these blobs to measure a baseline performance of the gateways under controlled conditions.

The organic CIDs come from our Bitswap Sniffer tool that has picked them up by observing bitswap traffic. Measuring the retrieval performance for these CIDs can be used as a proxy to what users on average would perceive when interacting with IPFS gateways. It is useful to track long term trends.