Learning Question
How does HTTP define messages over a lower byte stream?
TCP gives HTTP an ordered byte stream. HTTP must define where a request or response begins, which metadata belongs to it, where the body begins, and how the body length or end is known.
TCP does not know these boundaries. HTTP defines them.
One Logical Message, Many Transport Pieces
A large HTTP upload is commonly one request:
POST /upload HTTP/1.1
Content-Type: multipart/form-data
Content-Length: 1000000000
<file bytes...>The request body may be carried by many TCP segments and IP packets. Those pieces are not separate HTTP requests.
The distinction is:
HTTP perspective:
one request with a large body
TCP/IP perspective:
many byte ranges, segments, and packetsProgressive Sending and Receiving
The sender does not need to build the whole HTTP message in memory before anything can be transmitted.
A browser or client can write:
request line
headers
empty line
body bytes
more body bytes
more body bytesThe receiver can parse the request line and headers before the whole body has arrived. After the header section, HTTP rules tell the receiver how to interpret the body.
Length and Framing
HTTP needs a way to know how much body data belongs to a message.
Depending on the version and mode, that may come from:
Content-Length- chunked transfer encoding
- HTTP/2 or HTTP/3 frames
- stream-ending signals
- connection close in older patterns
TCP sequence numbers do a different job. They place bytes in order inside a connection. They do not say where an HTTP body ends.
Core Mental Model
TCP carries ordered bytes. HTTP gives those bytes message boundaries and meaning.
When reasoning about HTTP over connections, ask:
What is the HTTP message?
Where do its headers end?
How is its body length or end known?
Which lower transport pieces merely carried parts of that message?