Industrial Training

Internet Protocol Suite

Layer Protocols
Application DNS, TLS/SSL, TFTP, FTP, HTTP, IMAP, IRC, NNTP, POP3, SIP, SMTP, SNMP, SSH, TELNET, BitTorrent, RTP, rlogin, ENRP, …
Transport TCP, UDP, DCCP, SCTP, IL, RUDP, …
Network IP (IPv4, IPv6), ICMP, IGMP, ARP, RARP, …
Link Ethernet, Wi-Fi, Token ring, PPP, SLIP, FDDI, ATM, Frame Relay, SMDS, …

The Transmission Control Protocol (TCP) is one of the core protocols of the Internet protocol suite. Using TCP, applications on networked hosts can create connections to one another, over which they can exchange data or packets. The protocol guarantees reliable and in-order delivery of sender to receiver data. TCP also distinguishes data for multiple, concurrent applications (e.g. Web server and email server) running on the same host.

TCP supports many of the Internet's most popular application protocols and resulting applications, including the World Wide Web, email and Secure Shell.

In the Internet protocol suite, TCP is the intermediate layer between the Internet Protocol below it, and an application above it. Applications often need reliable pipe-like connections to each other, whereas the Internet Protocol does not provide such streams, but rather only unreliable packets. TCP does the task of the transport layer in the simplified OSI model of computer networks.

Applications send streams of 8-bit bytes to TCP for delivery through the network, and TCP divides the byte stream into appropriately sized segments (usually delineated by the maximum transmission unit (MTU) size of the data link layer of the network the computer is attached to). TCP then passes the resulting packets to the Internet Protocol, for delivery through an internet to the TCP module of the entity at the other end. TCP checks to make sure that no packets are lost by giving each packet a sequence number, which is also used to make sure that the data are delivered to the entity at the other end in the correct order. The TCP module at the far end sends back an acknowledgement for packets which have been successfully received; a timer at the sending TCP will cause a timeout if an acknowledgement is not received within a reasonable round-trip time (or RTT), and the (presumably lost) data will then be re-transmitted. The TCP checks that no bytes are damaged by using a checksum; one is computed at the sender for each block of data before it is sent, and checked at the receiver.

Protocol operation


An abridged version of the TCP state diagram Unlike TCP's traditional counterpart — User Datagram Protocol — that can immediately start sending packets, TCP requires a connection establishment before sending data and a connection termination on completion of sending data. More succinctly, TCP connections have three phases:

1. connection establishment
2. data transfer
3. connection termination

Before describing these three phases, a note about the various states of a socket:


LISTEN represents waiting for a connection request from any remote TCP and port. (usually set by TCP servers)

represents waiting for the remote TCP to send back a TCP packet with the SYN and ACK flags set. (usually set by TCP clients)

represents waiting for the remote TCP to send back an acknowledgment after have sent back a connection acknowledgment to the remote TCP. (usually set by TCP servers)

represents that the port is ready to receive/send data from/to the remote TCP. (set by TCP clients and servers)

represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request. According to RFC 793 a connection can stay in TIME-WAIT for a maximum of four minutes.

Connection establishment
To establish a connection, TCP uses a 3-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established then a client may initiate an active open. To establish a connection, the 3-way (or 3-step) handshake occurs:

1. The active open is performed by sending a SYN to the server.
2. In response, the server replies with a SYN-ACK.
3. Finally the client sends an ACK back to the server.
At this point, both the client and server have received an acknowledgement of the connection.

Data transfer

There are a few key features that set TCP apart from UDP:

1. Error-free data transfer
2. Ordered-data transfer
2. Retransmission of lost packets
3. Discarding duplicate packets
4. Congestion throttling

In the first two steps of the 3-way handshaking, both computers exchange an initial sequence number (ISN). This number can be arbitrary. This sequence number identifies the order of the bytes sent from each computer so that the data transferred is order regardless of any fragmentation or misordering that occurs during transmission. For every byte transmitted the sequence number must be incremented. Conceptually, each byte sent is assigned a sequence number and the receiver then sends an acknowledgement back to the sender that effectively states that they received it. What is done in practice is only the first data byte is assigned a sequence number which is inserted in the sequence number field and the receiver sends an acknowledgement value of the next byte they expect to receive. For example, if computer A sends 4 bytes with a sequence number of 100 (conceptually, the four bytes would have a sequence number of 100, 101, 102, & 103 assigned) then the receiver would send back an acknowledgement of 104 since that is the next byte it expects to receive in the next packet. By sending an acknowledgement of 104, the receiver is signaling that it received bytes 100, 101, 102, & 103 correctly. If, by some chance, the last two bytes were corrupted then an acknowledgement value of 102 would be sent since 100 & 101 were received successfully.

This would not happen for a packet of 4 bytes but it can happen if, for example, 10,000 bytes are sent in 10 different TCP packets and a packet is lost during transmission. If the first packet is lost then the sender would have to resend all 10,000 bytes since the acknowledgement cannot say that it received bytes 1,000 to 10,000 but only that it expects byte 0 because 0 through 9,999 were lost. (This issue is address in SCTP by adding a selective acknowledgement.)

Sequence numbers and acknowledgments cover discarding duplicate packets, retransmission of lost packets, and ordered-data transfer. To assure correctness a checksum field is included (see #Packet structure for details on checksumming).

Hi I am Pluto.