What fetch() really sends

Chrome can record everything its network stack does into a NetLog: each event, its timestamp in milliseconds, and its parameters. Below is our request, replayed from that log. Times are measured from the moment the network service created the request. It all happened on one machine, so the network itself is nearly free; on the real internet, each arrow that crosses to the server costs a round trip.

Calling fetch() runs Blink's C++ implementation on CrRendererMain, our page's main thread. It returns a pending promise at once. Before that, it copies our URL, method, headers, mode and credentials setting into a ResourceRequest and starts a ThreadableLoader.

The renderer is sandboxed and cannot open sockets. The loader sends the request over a Mojo pipe to the network service, which on desktop Chrome runs in its own utility process. The comment on the first line says where CORS lives: not here, but on the other side of that pipe.

In the network service, a URLLoader wraps the request in net/'s URLRequest, asks the resource scheduler whether it may start, and calls Start(). Before that, the CORS layer asks one question: does this request need a preflight? Only if the method is not GET, HEAD or POST, or a header is not on the safelist. Our first fetch is a plain GET, so the NetLog says preflight_required: false.

On Linux, this Chrome resolved the name with the operating system's resolver: the NetLog shows HOST_RESOLVER_SYSTEM_TASK. Chrome calls getaddrinfo() on a worker thread because it blocks. glibc reads /etc/resolv.conf, sends a UDP query to port 53, and waits. (Chrome also has a built-in DNS client, used for DNS-over-HTTPS and on some platforms; the log shows which one ran.)

The packets are tiny. Click any field or byte below: the query is 34 bytes and the answer is 50. The name travels as length-prefixed labels, 3 api 7 example 4 test 0, and the answer points back at it with a 2-byte compression pointer instead of repeating it. Our server also saw an AAAA (IPv6) query for the same name.

With an address, Chrome opens a non-blocking socket and calls connect(). The call returns EINPROGRESS immediately; Chrome watches the socket and is told when it becomes writable. Inside the kernel, tcp_connect() builds a segment with only the SYN flag set, transmits it, and arms a retransmit timer in case no SYN-ACK arrives.

That exchange, SYN → SYN-ACK → ACK, is one full round trip before any data can flow. In our capture it took 1 ms because the server was on the same machine. Across the world it costs whatever the round-trip time is, typically 20 to 200 ms.

Chrome now runs a TLS handshake through BoringSSL. Before the first byte, it sets the hostname (SNI) and the protocols it can speak (ALPN), then calls SSL_do_handshake(), which writes the ClientHello. TLS 1.3 finishes in one round trip because the ClientHello already carries public keys: the client guesses which key-exchange groups the server will accept.

Chrome's guess is two keys: classic x25519 (32 bytes) and the hybrid X25519MLKEM768, which adds a 1,184-byte ML-KEM post-quantum key. That is why this ClientHello is 1,822 bytes instead of a few hundred. Our server, Node 22 with OpenSSL, chose the hybrid group, and the NetLog confirms it: key_exchange_group: 4588 is 0x11EC.

Look for the GREASE values like 0x9a9a: deliberately meaningless entries that keep servers from breaking when real new values appear. Look also for the hostname, which is still in plaintext.

ALPN offered h2 and http/1.1; our server picked HTTP/1.1, so what Chrome writes is readable text. GenerateRequestLine builds GET /api/users HTTP/1.1\r\n, the headers follow one per line, and a blank line ends them. HttpStreamParser::SendRequest logs those headers to the NetLog (that is the event we replayed), and DoSendHeaders writes the bytes. BoringSSL encrypts them into a TLS record on the way out.

All three requests used the same connection. The first fetch paid for DNS, TCP and TLS. The preflight and the POST found an idle socket in the pool and went straight to HTTP. That is Connection: keep-alive at work.

Our page is http://app.example.test:8080; the API is https://api.example.test. Different origins. The browser will send the request, but it lets our script read the response only if the server opts in with Access-Control-Allow-Origin. That is the core of CORS: it protects the user's data on other sites from our script, not the server from requests.

For anything beyond a "simple" request, the browser first asks permission with an OPTIONS preflight. Our second fetch was a POST with Content-Type: application/json, which is not on the safelist, so the NetLog says preflight_required_reason: disallowed_header. The OPTIONS and its 204 reply are in the HTTP viewer above.

The lab below implements the rules. It agrees with real Chrome 141 on all 2,880 combinations we ran (every method, header set and credentials mode against every server policy), including one place where Chrome is more lenient than the spec: Access-Control-Allow-Headers: * still lets Authorization through.

When the headers arrive, the network service sends them to the renderer with OnReceiveResponse, along with the read end of a Mojo data pipe for the body. In the renderer, that message arrives on the IO thread and becomes a task on CrRendererMain: the same wake chain the event-loop page traced. In that task, Blink builds a Response and calls Resolve, which queues our .then or await continuation as a microtask.

Our promise resolves as soon as the headers are in, before the body. res.json() starts a second wait: it reads the data pipe to the end, then parses the text with V8's JSON parser and resolves its own promise. That is why fetch needs two awaits.

The page can see this timeline too. The Resource Timing API exposes a timestamp at each boundary (the API sent Timing-Allow-Origin: *, which cross-origin pages need before they can read them). These are the real values our page read for its two fetches:

Five questions in the style of a computer networks or web systems exam. Write our answer on paper first, then open the model answer and mark ourselves honestly. The marks follow the usual pattern of university theory exams; they are not copied from any real paper.