Intercept fetches to R2 and use direct CARPARK pull

[hannahhoward]

Goals

When we fetch blocks from an R2 CARPark URL, we appear to get TTFB around 400ms. Interestingly, if we instead use Cloudflare Worker's direct R2 access, our TTFB drops to around 200ms. Bandwidth doesn't seem to change much, but this is still an important win.

Implementation

• Using a seperate change in blob-fetcher to allow passing a custom fetch implementation, we now write a version of fetch that checks URLs to see if they are CAR Park URLs. if they are, instead of using the fetch API, we use our direct connection to CARPark in the worker to perform the fetch request.
• Pass this custom fetch to the batching fetch used by content claims dagula
• Also, to assemble a browser like Response object use the existing code in withCarBlockHandler, factored out to utility file
• In the process of doing this, I discovered a bug in that code where it was treating the last byte in the range as exclusive to the returned content rather inclusive, and this was undetected as the test was expecting the wrong result.

For Discussion

Comparison traces, note the average TTFB of 200 vs 400 on requests to R2

Regular fetch:

With intercepted direct gets to R2:

[hannahhoward]

blocked by storacha/blob-fetcher#30

[fforbeck]

LGTM!

[alanshaw]

Code change looks good to me but does require non-multipart byte range requests from the fetcher.

Do you see the 200ms perf issue when hitting the public URL directly...or just from the worker? I'm just wondering if it's the public bucket code that needs optimizing? https://github.com/storacha/public-bucket - looks like it does a bucket.head then bucket.get for all requests - perhaps that's the difference?

[alanshaw]

Suggested change

	} catch (err) {
	} catch (err) {
	console.warn('parsing range header', err)

[hannahhoward]

@alanshaw now uses the public public handler directly. perf looks really good: