TCP stream vs UDP message

The interface/API presented to you the user(programmer) of these protocols are:

UDP

Message oriented, you have an API (send/recv and similar) that provide you with the ability to send one datagram, and receive one datagram. 1 send() call results in 1 datagram sent, and 1 recv() call will recieve exactly 1 datagram.

TCP

Stream oriented, you have an API (send/recv and similar) that gives you the ability to send or receive a byte stream. There is no preservation of message boundaries, TCP can bundle up data from many send() calls into one segment, or it could break down data from one send() call into many segments - but that's transparent to applications sitting on top of TCP, and recv() just gives you back data, with no relation to how many send() calls produced the data you get back.

TCP is stream oriented because it is able to assemble data in contiguous format. E.g. you had data from number 1 to 4000 bytes. Now it will be divided into tcp segments where each segment would have a sequence number say first is 1-1200 byte, second is 1201 - 2400 and so on.

It might be delivered out of order while being sent through ip datagrams but is assembled into contiguous data latter, thereby appearing as a stream. The sequence number helps to reorder packets.

A little deeper explanation is:

A byte stream consist of one big chunk of data with no segments or other irregularities. With datagrams (smaller) data chunks are send and received at once as a whole. In practice it means that with datagrams each send/write call sends one packet, and each read/recv call receives one packet, while with stream protocol the data can be send and received in any way. E.g. A sender can call send() ten times, while the receiver receives all that data with one recv call. With datagrams ten send calls means ten packets and ten receive calls

Datagrams and streams

Byte streams