Transmission Control Protocol: Difference between revisions
imported>Howard C. Berkowitz mNo edit summary |
imported>Howard C. Berkowitz m (made 1st sentence a definition) |
||
| Line 1: | Line 1: | ||
{{subpages}} | {{subpages}} | ||
The fundamental Internet protocol for implementing reliable delivery is the '''transmission control protocol''' (TCP).<ref name=RFC0793>{{citation | |||
The fundamental protocol for implementing reliable delivery is the '''transmission control protocol''' (TCP).<ref name=RFC0793>{{citation | |||
| title = Transmission Control Protocol | | title = Transmission Control Protocol | ||
| first = J. | last = Postel | | first = J. | last = Postel | ||
| Line 9: | Line 7: | ||
| publisher = Internet Engineering Task Force | | publisher = Internet Engineering Task Force | ||
}}</ref> Yes, it is the "TCP" in "TCP/IP"; its role is that fundamental. | }}</ref> Yes, it is the "TCP" in "TCP/IP"; its role is that fundamental. | ||
When the Internet was first designed, one of its basic axioms was the [[end-to-end assumption]]. Under this assumption, the transfer of information between Internet endpoints is the responsibility of the endpoints. As opposed to other network architectures such as [[X.25]], the Internet did not guarantee reliable delivery. Not all Internet applications need guaranteed delivery. | |||
At a general level, assume that TCP guarantees a stream of error-free bytes. If TCP is unable to correct errors by repeated retransmission, it shuts down the connection. TCP does not guarantee the rate, or the variability of rate, of delivery; see [[differentiated services]]. | At a general level, assume that TCP guarantees a stream of error-free bytes. If TCP is unable to correct errors by repeated retransmission, it shuts down the connection. TCP does not guarantee the rate, or the variability of rate, of delivery; see [[differentiated services]]. | ||
Revision as of 12:11, 9 May 2008
The fundamental Internet protocol for implementing reliable delivery is the transmission control protocol (TCP).[1] Yes, it is the "TCP" in "TCP/IP"; its role is that fundamental.
When the Internet was first designed, one of its basic axioms was the end-to-end assumption. Under this assumption, the transfer of information between Internet endpoints is the responsibility of the endpoints. As opposed to other network architectures such as X.25, the Internet did not guarantee reliable delivery. Not all Internet applications need guaranteed delivery.
At a general level, assume that TCP guarantees a stream of error-free bytes. If TCP is unable to correct errors by repeated retransmission, it shuts down the connection. TCP does not guarantee the rate, or the variability of rate, of delivery; see differentiated services.
TCP assumes that any loss is due to congestion, so it strives not to transmit more data than the network and destination can accept. This is done with flow control mechanisms, which also control retransmission of data lost in transmission.
Windowing
There are both implicit and explicit flow control mechanisms. In the conventional "slow start" mode, TCP starts with a window size of one byte. As long as the transmission stays up, and delay does not exceed certain parameters, TCP keeps doubling the window size until either reaches the 64K limit imposed by its 16-bit window size field, or a transmission is not acknowledged.
If there is no acknowledgement, TCP assumes that is due to congestion, although TCP really does not know if the problem is congestion or a transmission error. In either case, TCP sets the window back to 1 and starts increasing the window until it hits a limit.
References
- ↑ Postel, J. (September 1981), Transmission Control Protocol, Internet Engineering Task Force