A byte-stream service
Applications hand bytes to TCP, which carries them in segments over IP. The receiver obtains an ordered byte stream rather than a guarantee that each send call corresponds to one receive call. Applications needing separate messages must define framing through lengths, delimiters, or another explicit representation.
References: [1]
Sequence numbers and acknowledgments
Sequence numbers locate bytes in the stream, and acknowledgments communicate reception progress. Retransmission can recover missing data, while duplicates and out-of-order arrival must also be handled. Reliability describes the transport service, not an infallible network: connections can fail, and applications must deal with operations that cannot complete.
References: [1]
Receiver capacity and network congestion
The advertised receive window limits data according to receiver capacity, while congestion control regulates the load placed on the network. Both can constrain a connection, but they address different problems. RFC 5681 specifies slow start, congestion avoidance, and related recovery mechanisms; implementations can also use other suitable congestion-control algorithms.
Transport completion and application work
Ports distinguish communication endpoints, and connection state coordinates setup and closure. Transport acknowledgment does not prove that a server has completed a payment, committed a record, or performed another business operation. Application success, encryption, authentication, and message meaning require protocols beyond TCP’s basic ordered byte-stream service.
References: [1]