the byte-stream service
When you pour water from one cup into another, you don't pour it as little numbered droplets — it just flows as one continuous stream. TCP offers its data the same way: to the application, a TCP connection looks like a continuous stream of bytes flowing reliably from sender to receiver, not a sequence of separate messages. You write bytes in at one end; they come out, in the same order, at the other.
What this means in practice is that TCP does not preserve message boundaries. If your program calls 'send' three times with 100 bytes each, the receiver might read all 300 bytes in one chunk, or in two reads of 150, or byte by byte — TCP only promises the bytes arrive correctly and in order, not in the same groupings you sent them. Underneath, TCP packages the stream into segments for transmission and numbers every byte, but the application never sees those segment edges; it just sees an ordered flow.
Why it matters: the byte stream is wonderfully simple to program against, but it pushes one responsibility onto the application — message framing. If your protocol sends discrete messages, you must mark where each one ends (for example, with a length prefix or a delimiter like a newline), because TCP won't do it for you. This is the opposite of UDP, which is message-oriented: each UDP datagram is one self-contained message with a preserved boundary. Confusing TCP's stream for messages is a classic beginner bug — reading once and assuming you got a whole message.
A chat app sends 'Hello' then 'World' over one TCP connection. The receiver might read 'HelloWorld' in a single read, or 'Hel' then 'loWorld'. To recover the two messages, the app must frame them — e.g. send a length first, or terminate each with a newline.
TCP delivers bytes in order but doesn't keep your message edges.
The most common beginner mistake: treating one TCP read as one message. The stream has no built-in boundaries — framing is the application's job. UDP, by contrast, preserves each datagram as a discrete message.