Download An Introduction to TCP/IP - Oakton Community College

Transport Control Protocol (TCP)/IP
The Internet Protocol (IP) is responsible for ensuring that data is transferred between two addresses without
being corrupted. For manageability, the data is usually split into multiple pieces or packets each with its own
error detection bytes in the control section or header of the packet. The remote computer then receives the
packets and reassembles the data and checks for errors. It then passes the data to the program that expects to
receive it.
The two most popular transportation mechanisms used on the Internet are Transmission Control Protocol (TCP)
and User Datagram Protocol (UDP).
TCP provides a communication service at an intermediate level between an application program and the
Internet Protocol (IP). That is, when an application program desires to send of data across the Internet using IP,
instead of breaking the data into IP-sized pieces and issuing a series of IP requests, the software can issue a
single request to TCP and let TCP handle the IP details.
When the type of transport protocol has been determined, the TCP/UDP header is then inspected for the "port"
value, which is used to determine which network application on the computer should process the data.
Certain programs are assigned specific ports that are internationally recognized. For example, port 80 is
reserved for HTTP Web traffic, and port 25 is reserved for SMTP e-mail. Ports below 1024 are reserved for
privileged system functions, and those above 1024 are generally reserved for non-system third-party
applications.
UDP “Connectionless" Protocol
UDP is a connectionless protocol. Data is sent on a "best effort" basis with the machine that sends the data
having no means of verifying whether the data was correctly received by the remote machine. UDP is usually
used for applications in which the data sent is not mission-critical. It is also used when data needs to be
broadcast to all available servers on a locally attached network where the creation of dozens of TCP
connections for a short burst of data is considered resource-hungry.
TCP a Connection-Oriented Protocol
TCP opens up a virtual connection between the client and server programs running on separate computers so
that multiple and/or sporadic streams of data can be sent over an indefinite period of time between them. TCP
keeps track of the packets sent by giving each one a sequence number with the remote server sending back
acknowledgment packets confirming correct delivery. Programs that use TCP therefore have a means of
detecting connection failures and requesting the retransmission of missing packets. TCP is a good example of a
connection-oriented protocol.
TCP is a reliable stream delivery service that guarantees delivery of a data stream sent from one host to another
without duplication or losing data. Since packet transfer is not reliable, a technique known as positive
acknowledgment with retransmission is used to guarantee reliability of packet transfers. This fundamental
technique requires the receiver to respond with an acknowledgment message as it receives the data. The sender
keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet. The
sender also keeps a timer from when the packet was sent, and retransmits a packet if the timer expires. The
timer is needed in case a packet gets lost or corrupted.
TCP Connection Establishment
To establish a connection, TCP uses a three-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, a client may initiate an active open. The hostr initiating the connection sends a segment
with the SYN bit set in TCP header. The target replies with a segment with the SYN and ACK bits set, to which
the originating server replies with a segment with the ACK bit set. This SYN, SYN-ACK, ACK mechanism is
often called the "three-way handshake".
To establish a connection, the three-way (or 3-step) handshake occurs:
1. The active open is performed by the client 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 acknowledgment of the connection. Usually when a
connection is made from a client computer requesting data to the server that contains the data:



The client selects a random previously unused "source" port greater than 1024 and queries the server on
the "destination" port specific to the application. If it is an HTTP request, the client will use a source
port of, say, 2049 and query the server on port 80 (HTTP) .
The server recognizes the port 80 request as an HTTP request and passes on the data to be handled by
the Web server software. When the Web server software replies to the client, it tells the TCP application
to respond back to port 2049 of the client using a source port of port 80.
The client keeps track of all its requests to the server's IP address and will recognize that the reply on
port 2049 isn't a request initiation for "NFS", but a response to the initial port 80 HTTP query.
TCP Connection Example:
Here is a modified packet trace obtained from an ethereal program:
hostA -> hostB TCP 1443 > http [SYN] Seq=9766 Ack=0 Win=5840 Len=0
hostB -> hostA TCP http > 1443 [SYN, ACK] Seq=8404 Ack=9767 Win=5792 Len=0
hostA -> hostB TCP 1443 > http [ACK] Seq=9767 Ack=8405 Win=5840 Len=0
hostA -> hostB HTTP HEAD/HTTP/1.1
hostB -> hostA TCP http > 1443 [ACK] Seq=8405 Ack=9985 Win=54 Len=0
hostB -> hostA HTTP HTTP/1.1 200 OK
hostA -> hostB TCP 1443 > http [ACK] Seq=9985 Ack=8672 Win=6432 Len=0
hostB -> hostA TCP http > 1443 [FIN, ACK] Seq=8672 Ack=9985 Win=54 Len=0
hostA -> hostB TCP 1443 > http [FIN, ACK] Seq=9985 Ack=8673 Win=6432 Len=0
hostB -> hostA TCP http > 1443 [ACK] Seq=8673 Ack=9986 Win=54
In this trace, the sequence number represents the serial number of the first byte of data in the segment. So in the
first line, a random value of 9766 was assigned to the first byte and all subsequent bytes for the connection from
this host will be sequentially tracked. This makes the second byte in the segment number 9767, the third number
9768 etc. The acknowledgment number or Ack, not to be confused with the ACK bit, is the byte serial number
of the next segment it expects to receive from the other end, and the total number of bytes cannot exceed the
Win or window value that follows it. If data isn't received correctly, the receiver will re-send the requesting
segment asking for the information to be sent again. The TCP code keeps track of all this along with the source
and destination ports and IP addresses to ensure that each unique connection is serviced correctly.
Data Transfer
The data portion of the IP packet contains a TCP or UDP segment sandwiched inside. Only the TCP segment
header contains sequence information, but both the UDP and the TCP segment headers track the port being
used. The source/destination port and the source/destination IP addresses of the client & server computers are
then combined to uniquely identify each data flow.
During data transfer, TCP enforces:






Ordered data transfer - the destination host rearranges according to sequence numbe
Retransmission of lost packets - any cumulative stream not acknowledged will be retransmitted
Discarding duplicate packets
Error-free data transfer
Flow control - limits the rate a sender transfers data to guarantee reliable delivery. When the receiving
host's buffer fills, then next acknowledgement contains a 0 in the window size, to stop transfer and allow
the data in the buffer to be processed
Congestion control – using TCP sliding window
The communication then continues with a series of segment exchanges, each with the ACK bit set. When one of
the servers needs to end the communication, it sends a segment to the other with the FIN and ACK bits set, to
which the other server also replies with a FIN-ACK segment also. The communication terminates with a final
ACK from the server that wanted to end the session.
Connection Termination
The connection termination phase uses, at most, a four-way handshake, with each side of the connection
terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN
packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN
and ACK segments from each TCP endpoint.
A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side
that has terminated can no longer send any data into or receive any data from the connection, but the other side
can (but generally if it tries, this should result in no acknowledgment and therefore a timeout, or else result in a
positive RST, and either way thereby the destruction of the half-open socket).
It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B
replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.
This is perhaps the most common method. It is possible for both hosts to send FINs simultaneously then both
just have to ACK. This could possibly be considered a 2-way handshake since the FIN/ACK sequence is done
in parallel for both directions.
Some host TCP stacks may implement a "half-duplex" close sequence, as Linux or HP-UX do. If such a host
actively closes a connection but still has not read all the incoming data the stack already received from the link,
this host will send a RST instead of a FIN. This allows a TCP application to be sure that the remote application
has read all the data the former sent - waiting the FIN from the remote side when it will actively close the
connection. Unfortunately, the remote TCP stack cannot distinguish between a Connection Aborting RST and
this Data Loss RST - both will cause the remote stack to throw away all the data it received, but the application
still didn't read. Some application protocols may violate the OSI model layers, using the TCP open/close
handshaking for the application protocol open/close handshaking - these may find the RST problem on active
close.
TCP Session States
TCP session have various states as displayed by the netstat –an command:
netstat -an
Active Connections
Proto Local Address
Foreign Address
State
TCP 0.0.0.0:135
0.0.0.0:0
LISTENING
TCP 0.0.0.0:445
0.0.0.0:0
LISTENING
TCP 10.218.186.109:139 0.0.0.0:0
LISTENING
TCP 10.218.186.109:1072 172.24.17.70:1533 ESTABLISHED
TCP 10.218.186.109:1343 172.24.17.63:1352 CLOSE_WAIT
TCP 10.218.186.109:1345 172.24.8.58:30999 ESTABLISHED
TCP 192.168.201.26:139 0.0.0.0:0
LISTENING
TCP 192.168.201.26:2116 192.234.16.5:443
TIME_WAIT
TCP 192.168.201.26:2126 192.234.16.5:443
ESTABLISHED
UDP 0.0.0.0:427
*:*
UDP 0.0.0.0:445
*:*
UDP 0.0.0.0:1045
*:*
Session States:
1. LISTEN
2. SYN-SENT
3. SYN-RECEIVED
4. ESTABLISHED
5. FIN-WAIT-1
6. FIN-WAIT-2
7. CLOSE-WAIT
8. CLOSING
9. LAST-ACK
10. TIME-WAIT
11. CLOSED
LISTEN
represents waiting for a connection request from any remote TCP and port. (usually set by TCP servers)
SYN-SENT
represents waiting for the remote TCP to send back a TCP packet with the SYN and ACK flags set.
(usually set by TCP clients)
SYN-RECEIVED
represents waiting for the remote TCP to send back an acknowledgment after having sent back a
connection acknowledgment to the remote TCP. (usually set by TCP servers)
ESTABLISHED
represents that the port is ready to receive/send data from/to the remote TCP. (set by TCP clients and
servers)
TIME-WAIT
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.
FIN-WAIT, FIN-WAIT-2, CLOSE-WAIT, CLOSING , LAST-ACK, TIME-WAIT, CLOSED all relate to
various states of TCP session termination depending on the method used (described above)
TCP/IP Session State Diagram (From Wikipedia)
The TCP/IP "Time To Live" Feature
Each IP packet has a Time to Live (TTL) section that keeps track of the number of network devices the packet
has passed through to reach its destination. The server sending the packet sets the initial TTL value, and each
network device that the packet passes through then reduces this value by 1. If the TTL value reaches 0, the
network device will discard the packet.
This mechanism helps to ensure that bad routing on the Internet won't cause packets to aimlessly loop around
the network without being removed. TTLs therefore help to reduce the clogging of data circuits with
unnecessary traffic.
The ICMP Protocol and Its Relationship to TCP/IP
ICMP provides a suite of error, control, and informational messages for use by the operating system. For
example, IP packets will occasionally arrive at a server with corrupted data due to any number of reasons
including a bad connection; electrical interference, or even misconfiguration. The server will usually detect this
by examining the packet and correlating the contents to what it finds in the IP header's error control section. It
will then issue an ICMP reject message to the original sending machine saying that the data should be re-sent
because the original transmission was corrupted.
ICMP also includes echo and echo reply messages used by the Linux ping command to confirm network
connectivity. ICMP TTL expired messages are also sent by network devices back to the originating server
whenever the TTL in a packet is decremented to zero. Note there is a UDP echo command that performs thae
same function as ICMP PING. ON some systems the PING command can be used for either protocol.
Address Resolution Protocol
ARP is a Link Layer protocol that resolves IP addresses to local MAC addresses that operates on the local area
network or point-to-point link that a host is connected to. On Ethernet networks, these packets use an
EtherType of 0x0806, and are sent to the broadcast MAC address of FF:FF:FF:FF:FF:FF.
On a local network the target IP address will “hear” the broadcast ARP request and respond with an ARP
response reversing MAC and IP source and destination IP address, substituting it’s own MAC address for the
broadcast address on the response packet.
TCP/IP Network Model
The TCP/IP network model has only 4 layers and does not exactly map to the OSI 7-layer model.
First - IP does not define the bottom two OSI Layers (Data and Physical). It only provides an interface to it –
ARP.
Second – the application layer defines the top three layers of the OS model – application, presentation and
session. All specifications for the application layer are in the RFC document defining the TCP/IP application.
Most of the logic for TCP/IP protocol itself lies in OSI layer 3 (network) and 4 (transport).
TCP/IP Stack
The TCP/IP stack is a program(s) that implements the TCP/IP protocol within an OS. Each OS has it’s own
stack and it’s own assumptions on ho w it operates. For example, in most workstation OSes, port 3’s below
1024 are restricted. On some server OSes; the “reserved” port #’s can be higher -2048, 4096, 8192.
TCP/IP Stack datasets
/etc/services
On UNIX, /etc/services maps port numbers to named services to be provided by the server. Its purpose is so
that programs can do a getportbyname() sockets call in order to get what port they should use – e.g. a POP3
email daemon would do a getportbyname ("pop3") in order to retrieve the number 110. /etc/services contains
mostly IANA reserved ports under 1024 (RFC 1700) and proprietary registered ports thru 49151. Private prts
are 49152 thru 65535. Each line in /etc/services list: service name, protocol/port #, aliases.
/etc/networks
On UNIX, /etc/networks maps network numbers to network names as seen by the server.
Its purpose is so that programs can do a getnetbyname() sockets call in order to get what subnet is assigned to it.
A typical default /etc/networks will look like this:
Default 0.0.0.0
Loopback 127.0.0.0
Link-local 169.254.0.0
/etc/protcols
On UNIX, /etc/networks maps IP protocol names to IP protocol as seen by the server.
Its purpose is so that programs can do a getprotbyname() sockets call in order to get what protocol # is assigned
to a specific namet.
/etc/nsswitch.conf
On UNIX, /etc/nsswitch.conf maps name lookup procedures for all services that references names. See DNS for
more info.
/etc/host.conf
On UNIX, /etc/host.conf maps TCP/IP name lookup procedures for all services that references TCP/IP names.
See DNS for more info.
/etc/hosts
In most Oses. contains local, static host to IP mame-address mappings.
/etc/resolv.conf
In most Oses. contains information for locating TCP/IP name/address mappings from a separate (DNS) server.
/etc/named.conf
In most Oses. contains information for the DNS Server configuration. The actual DNS information is stored in
separate ZONE files located in a separate directory - /var/named under LINUX.
TCP/IP Stack Commands
Used to configure and display the TCP/IP suite are as follows:
-
PING - used to determine the ability to contact a specific IP address.
-
TRACEROUTE – used to display gateway address(es) when passing thru multiple networks to get to a
specific IP address (PING)
-
ARP – used to determine which IP addresses map to whicm MAC address on the LAN (local IP network
only)
-
NETSTAT - is used to display network statistics (-s), Ethernet Statistics (-e), TCP/UDP connections (-a)
and routing information (-r).
-
NSLOOKUP/DIG - return an IP address for a domain name
-
FINGER – obtain local/remore user information
-
HOSTNAME – local hostname
-
IPCONFIG/IFCONFIG – local IP configuration information
-
ROUTE - for displays, same as NETSTAT –r; otherwise updates local route table
-
ETHTOOL – display/set Ethernet card settings. LINUX specific; other systems use different
commands or ifconfig for this purpose.