Build it

We will run a tiny NestJS API, read its raw HTTP, then measure each step of a real request.

1. A minimal NestJS controller that returns JSON

   Add this to a new Nest project (npx @nestjs/cli new stock-api) and register the controller in AppModule. It uses a fake array, so you need no database yet. In Mangrove's data a site is a store or a DC, and an article is a product, so this endpoint returns the stock of one product at one store.

   TypeScriptCopy

   // src/stock.controller.ts
   import { Controller, Get, NotFoundException, Param, ParseIntPipe } from '@nestjs/common';
   
   type StockDto = { siteId: number; articleId: number; qty: number; updatedAt: string };
   
   const fakeStock: StockDto[] = [
     { siteId: 12, articleId: 4711, qty: 42, updatedAt: '2026-10-06T09:15:02.118Z' },
   ];
   
   @Controller('sites/:siteId/stock')
   export class StockController {
     // GET /sites/12/stock/4711
     @Get(':articleId')
     findOne(
       @Param('siteId', ParseIntPipe) siteId: number,       // "12" becomes 12, "abc" gives 400
       @Param('articleId', ParseIntPipe) articleId: number,
     ): StockDto {
       const row = fakeStock.find((s) => s.siteId === siteId && s.articleId === articleId);
       if (!row) throw new NotFoundException(`No stock row for article ${articleId} at site ${siteId}`);
       return row; // Nest turns the object into JSON and sets status 200
     }
   }
   

   TerminalCopy

   npm run start:dev    # listens on http://localhost:3000
   

2. See the request and response with curl -v

   The -v flag prints what curl sends (lines starting with >) and what it receives (<).

   TerminalCopy

   curl -v http://localhost:3000/sites/12/stock/4711
   

   OutputCopy

   *   Trying 127.0.0.1:3000...
   * Connected to localhost (127.0.0.1) port 3000        <- TCP done
   > GET /sites/12/stock/4711 HTTP/1.1                    <- request line
   > Host: localhost:3000                                 <- headers
   > User-Agent: curl/8.5.0
   > Accept: */*
   >                                                      <- blank line
   < HTTP/1.1 200 OK                                      <- status line
   < Content-Type: application/json; charset=utf-8
   < Content-Length: 78
   < Connection: keep-alive
   < Keep-Alive: timeout=5                                <- idle connection kept 5 s
   <
   {"siteId":12,"articleId":4711,"qty":42,"updatedAt":"2026-10-06T09:15:02.118Z"}
   

   Output trimmed a little; you will also see X-Powered-By, ETag and Date headers. Try /sites/12/stock/999 to get a 404 with a JSON error body, and /sites/abc/stock/1 to get a 400 from ParseIntPipe.

3. Send HTTP by hand

   To prove HTTP/1.1 is only text, type the request yourself with nc (netcat). The \r\n pairs are the line endings HTTP requires, and the final empty line ends the headers.

   TerminalCopy

   printf 'GET /sites/12/stock/4711 HTTP/1.1\r\nHost: localhost:3000\r\nConnection: close\r\n\r\n' \
     | nc localhost 3000
   

   You get back the same status line, headers and JSON body. A phone, a browser and curl all send text like this. With HTTPS, the same text travels inside the TLS encryption.

4. Look up a name with dig

   Replace api.example.com with your own API's domain. +noall +answer shows only the answer. The second column is the TTL in seconds.

   TerminalCopy

   dig +noall +answer api.example.com
   dig +trace api.example.com    # walk the chain yourself: root, .com, name server
   

   OutputCopy

   api.example.com.     300     IN      A       203.0.113.10
   

   Run the first command again a minute later. If your resolver cached the answer, the TTL counts down (for example to 241), because the resolver is telling you how long its copy stays valid. dig comes in the dnsutils or bind-utils package on Linux.

5. Time every step with curl -w

   Save this format file. Each variable is a time in seconds, counted from the start of the request, not from the previous step.

   OutputCopy

      dns lookup:  %{time_namelookup}s\n
     tcp connect:  %{time_connect}s\n
   tls handshake:  %{time_appconnect}s\n
      first byte:  %{time_starttransfer}s\n
           total:  %{time_total}s\n
          status:  %{http_code}\n
   

   TerminalCopy

   # save the lines above as curl-timing.txt, then:
   curl -s -o /dev/null -w "@curl-timing.txt" https://api.example.com/health
   

   OutputCopy

      dns lookup:  0.152s
     tcp connect:  0.311s
   tls handshake:  0.498s
      first byte:  0.874s
           total:  0.951s
          status:  200
   

   Read it by subtracting each line from the next (these numbers are an example from a slow link):

   • DNS: 152 ms.
   • TCP: 311 − 152 = 159 ms, which is about one round trip.
   • TLS: 498 − 311 = 187 ms, about one more round trip (TLS 1.3).
   • Waiting for the first byte: 874 − 498 = 376 ms. This is one round trip plus server work, so the server took roughly 376 − 160 ≈ 216 ms.
   • Download: 951 − 874 = 77 ms.

6. Watch connection reuse

   Give curl the same URL twice in one command. It reuses the open connection for the second request.

   TerminalCopy

   curl -s -o /dev/null -o /dev/null -w "@curl-timing.txt" \
     https://api.example.com/health https://api.example.com/health
   

   For the second request, tcp connect and tls handshake show 0.000000s, and the total drops to about one round trip plus server time. That difference is what keep-alive saves on every request after the first.

   Steps 1 to 6 need a terminal on your own machine. The subtraction from step 5, which is where most people slip, is also in the Practice section as a JavaScript exercise you can run in your browser.