Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

TCP Protocol

News	See Also	Recommended Links	IP troubleshooting	TCP Headers	TCP flow control
TCP handshake	Sequence numbers	NAT	Quiz	Humor	Socks5

Introduction

Reliability

TCP Headers

TCP Flow Control

Introduction

TCP protocol is defined in RFC 793. The objective of TCP is to provide a reliable, connection-oriented delivery service. TCP views data as a stream of bytes, not frames. The unit of transfer is refered to as a segment. To provide the connection-oriented service, TCP takes care to ensure reliability, flow control, and connection maintainence.

TCP is suited to the situation when large volume of data are transmitted between systems possibly across multiple routers. TCP has four main features:

Virtual circuit connection
Full-duplex connection
Unstructured stream orientation
Buffered transfer

Here are those four features in detail:

Virtual Circuit Connection. TCP, on both the sending and receiving systems, must establish a connection before the transmission can start. This is similar to making a phone call; the line must be established before you can begin to talk.

Full-Duplex Connection. TCP connections provide concurrent transfer in both directions. According to the application, a full-duplex connection consists of two independent streams that flow in opposite directions. Each segment of data receives is acknowledges with special ACK packet. The TCP protocol software sends control information for one stream back to the source in the segments that carry data in the opposite direction. This process is called piggybacking, and it reduces network traffic.

Unstructured Stream Orientation. Data originating from the Application layer flows to TCP as a stream of bytes. This stream of bytes is divided into packets called segments. TCP segments have a leading header section that contains control information including so called sequence number, source and destination port numbers, and a data section. The content in the data section is not read or translated by TCP. TCP then sends the segments to the Internet layer for encapsulation and delivery.
Buffered Transfer. Data that comes from the application is a flowing stream. Data can flow fast or slow. To ensure the efficient flow of data to and from the application, TCP provides both input and output buffers to regulate the flow of data. The input and output buffers also allow the application to see TCP as a full-duplex connection.

Reliability

To ensure reliability, TCP is able to recover from data that is damaged, lost, duplicated, or delivered out of sequence. In order to do this, TCP assigns a sequence number to each byte transmitted. The receiving host's TCP must return an ACK for bytes received within a specified period. If this is not done, the data is retransmitted. Damaged data is handled by adding a checksum to each segment. If a segment is detected as damaged by the receiving host's TCP, it will discard the segment. The sender will resend the segment since the ACK was never sent.

TCP Headers

All IP packets have at least one header, which is known as the IP header; sometimes this header is also called a Layer 3 or network header. The IP header is simply a series of bits which have been grouped into fields of a set size. All IP headers have the same structure; the only difference will be which bits have been set to "1" to either turn on a field's value or to represent a binary number within a field. Let's take a closer look at the fields in an IP header:

4	8	16	32 bits
Ver.	IHL	Type of service	Total length
Identification			Flags	Fragment offset
Time to live		Protocol	Header checksum
Source address
Destination address
Option + Padding
Data

An IP packet has 14 fields and occupy six 32-bit words; let's go through these fields one at a time.

Version This is a 4-bit field that indicates the IP version, written in binary. For example if you are using IPv4, the bits will be set to 0100; if you are using IPv6, the bits will be set to 0110.
IHL or header length This 4-bit field indicates how long the IP packet header is; this value is used to distinguish which part of the IP packet is the header, and which part is the actual data. If you take a look at the picture of the IP packet, you'll notice that it is 32 bits wide. Now take a look at the length of the packet: the data is not part of the header, the options are optional, but all other fields are required. This means that the minimum header length is five 32-bit words, or binary 0101. You'll sometimes see these words translated into bytes; that is, five words multiplied by 4 bytes (32 bits divided by 8 bits to make a byte) equals a header length of 20 bytes. If the options are used, the header length will be at least six 32-bit words. Since this is a 4-bit field, the maximum length will be 2 to the power of 4 minus 1, or 15. This effectively limits the size of an IP header to 60 bytes (15 words multiplied by 4 bytes).
Type of Service (sometimes called TOS) flags This field is 8 bits long; the first 3 bits are called precedence bits and the last 5 bits represent the type of service flags. These flags were originally created to prioritize which packets should be delivered and which packets could be dropped if a router became congested. Since then, other protocols have been invented to prioritize traffic and most routers ignore these flags even if they have been set.
Total length; also called packet length or datagram length
This 16-bit field represents the total length of the IP packet, meaning both the data and the header. The minimum size is 21 bytes (default header size plus one byte of data). Since this field is 16 bits long, the maximum packet size is 2 to the power of 16 minus one, or 65,535 bytes. (The minus one represents the illegal length value of 0.)
Identification. Every IP packet is given an identification number when it is created; that number is contained within this 16-bit field. It is possible for an IP packet to be separated into smaller "fragments" before it reaches its final destination; each fragment still belongs to the original IP packet, so each fragment will have the same identification number.
Flags This field contains three flags as follows:
- reserved flag: must always be 0
- don't fragment flag: if set to 0, this flag is off, meaning you can fragment the IP packet; if set to 1, this flag is on, meaning you don't fragment this IP packet
- more fragments flag: if set to 0, there are no more fragments; if set to 1, there are more fragments of this IP packet yet to arrive
Fragment offset. If an IP packet has been fragmented, each fragment will have a value in this 13-bit field indicating where this fragment's data fits into the original IP packet. For example, let's pretend an IP packet containing 128 bytes of data was fragmented into two fragments each containing 64 bytes of data. The fragment containing the first 64 bytes of data would have a fragment offset of 0 as its data belongs at the very beginning of the original IP packet. The fragment containing the last 64 bytes of data needs to indicate that its data starts after the first 64 bytes. Since the number in this field represents an 8-byte multiple, its fragment offset will be 8 (8 multiplied by 8 = 64 bytes).
Time to Live (often called TTL) Whenever an IP packet passes through a router, the router will decrease the TTL by one; if the TTL ever reaches 0, the packet will be thrown away under the assumption that it must be undeliverable as it hasn't been delivered by now. The original TTL value depends upon the operating system; your FreeBSD system uses a default TTL of 64. Since this is an 8-bit field, the maximum allowable TTL is 255 (2 to the power of 8 minus 1; the minus 1 is for the non-allowable TTL of 0).
Protocol. This 8-bit value specifies which protocol's data is contained within the IP packet and gives a good indication of what type of information will be contained within the data portion of the packet. The protocol numbers that appear in this field are found in the "/etc/protocols" file on your FreeBSD system.
- For example, the protocol number 1 represents the ICMP protocol. This means that this IP packet does not contain any data from an application; instead, it contains a small amount of ICMP data. We'll be taking an in-depth look at ICMP and how it affects your firewall in a separate article.
- A protocol number of 6 indicates the TCP protocol. You may remember from earlier articles that TCP is a connection-oriented transport. This IP packet will have an additional header known as a TCP header that will be located just after the IP header and before the beginning of the actual data that is being delivered.
- A protocol number of 17 indicates the UDP protocol, which is the connectionless transport. This IP packet will have a UDP header located just after the IP header and before the beginning of the data that is being delivered.
Header Checksum. Whenever an IP header is created or modified, a CRC (cyclic redundancy check) is run on the bits contained within the IP header. Basically, some math (the CRC algorithm) is done which results in an answer known as the checksum. When the IP packet is received, the same CRC is repeated on the header; if this results in the same answer (checksum), all of the bits of the IP header must have arrived in the correct order. If the CRC results in a different checksum, some of the bits in the header didn't arrive, meaning the IP packet was somehow damaged during transit.
Source Address. This will be the IP address of the host that sent the IP packet.
Destination Address. This will be the IP address of the host that is to receive the data contained within the IP packet.
Options and Padding. This is the only field in an IP packet which is optional, as all other fields are mandatory. This field is used to provide special delivery instructions not covered by the other fields in an IP header. It can allow for up to 40 bytes worth of extra instructions; these instructions must be in 32-bit words. If an instruction doesn't quite fill up a 32-bit word, the missing bits will be filled in with "padding" bits.
Data. The last field in an IP packet is called the data field. This will be the actual data that is being sent from one host to another. The data field may start with a Layer 4 header, which will give additional instructions to the application that will be receiving the data; alternately, it may be an ICMP header and not contain any user data at all. Now that we've examined what is contained in a Layer 3 (IP) header, let's move on to the Layer 4 header. A Layer 4 header occurs at the very beginning of the IP data field and can be either a TCP header or a UDP header. Let's start with the fields that will be found in a Layer 4 TCP header:

16								32 bits
Source port								Destination port
Sequence number
Acknowledgement number
Offset	Reserved	U	A	P	R	S	F	Window
Checksum								Urgent pointer
Option + Padding
Data

Note that a TCP header is also composed of 32-bit words; like an IP header, the default size is 20 bytes if the option field is not used. Let's summarize the fields that are available in a TCP header:

Source Port This 16-bit number represents the name of the application that sent the data in the IP packet. On your FreeBSD system, the file /etc/services lists which applications use which port numbers. There are 65,535 possible port numbers (2 to the power of 16 minus 1).
Destination Port. This 16-bit number represents the name of the application that is to receive the data contained within the IP packet. This is one of the major differences between a Layer 3 and a Layer 4 header: the Layer 3 header contains the IP address of the computer that is to receive the IP packet; once that packet has been received, the port address in the Layer 4 header ensures that the data contained within that IP packet is passed to the correct application on that computer.
Sequence Number. TCP is responsible for ensuring that all IP packets sent are actually received. When an application's data is packaged into IP packets, TCP will give each IP packet a sequence number. Once all the packets have arrived at the receiving computer, TCP uses the number in this 32-bit field to ensure that all of the packets actually arrived and are in the correct sequence.
Acknowledgement Number. This number is used by the receiving computer to acknowledge which packets have successfully arrived. This number will be the sequence number of the next packet the receiver is ready to receive.
Header Length or Offset. This is identical in concept to the header length in an IP packet, except this time it indicates the length of the TCP header.
Reserved. These 6 bits are unused and are always set to 0.
Control Flags. TCP uses six control flags with each flag being a unique bit. If the bit is set to 1, the flag is on; if the bit is set to 0, the flag is off. The order of the flags is:
- URGent
- ACKnowledgement
- PuSH
- ReSeT
- SYNchronize
- FINish

We'll be seeing these flags again when we run "tcpdump" and when we take a look at creating packet filter rules.

Window Size. Every TCP packet contains this 16-bit value that indicates how many octets it can receive at once. When IP packets are received, they are placed in a temporary area of RAM known as a buffer until the receiving computer has a chance to process them; this value represents how big a buffer the receiving host has made available for this temporary storage of IP packets.
Checksum. Unlike IP, TCP is responsible for ensuring that the entire IP packet arrived intact. TCP will run a CRC on the entire IP packet (not just the header) and place the resulting checksum in this field. When the IP packet is received, TCP re-runs the CRC on the entire packet to ensure the checksum is the same.
Urgent Pointer. If the Urgent flag was set to on, this value will indicate where the urgent data is located.
Options and Padding. Like IP options, this field is optional and represents additional instructions not covered in the other TCP fields. Again, if an option does not fill up a 32-bit word, it will be filled in with padding bits.
Data. This will be the actual data being sent and will not include any additional headers.

TCP Flow Control

Introduction

TCP is more than a basic send-receive-acknowledge-send progression. TCP has sophisticated algorithms to optimize flow control on both the sender side and the receiver side. The algorithm that implements flow
control on both the sender side and the receiver side follows what is known as the sliding window principle.

Receiver-Side Window Advertisements

A TCP window advertisement determines the maximum amount of data that can be sent before the sender must wait for an acknowledgement from the receiver. By advertising its window size, the receiver side manages flow control. With window advertisements, the receiving host continually informs the sending host of how much data it is prepared to receive.

Each TCP segment from the receiver carries an acknowledgement and a window advertisement. Each acknowledgement specifies how many bytes have been received, and each window advertisement specifies how many additional bytes the receiver is prepared to accept. The size contained in the window advertisements varies over time; therefore, it is considered a sliding window.

Sender-Side Congestion Window

To avoid network congestion, TCP on the sender side maintains a congestion window. The congestion window adjusts the amount of data that can be sent according to the number of segments that were recently lost or acknowledged in transit. Lost segments are detected if a transmission timeout occurs before an acknowledgement is received.

As acknowledgements begin to be received, TCP doubles the size of the congestion window. If congestion is detected, the congestion window halves in size. If congestion continues, the congestion window can be halved multiple times.

Depending upon the severity of the congestion, TCP can use either a slow-start or congestion-avoidance algorithm to begin to increase the size of the congestion window. The slow-start algorithm quickly increases window size by doubling it for each successful transmission. The congestion-avoidance algorithm slowly increases the window�s size by increasing it only one segment at a time for each successful transmission.

TCP Large Window

The Solaris implements RFC 1323, which allows larger TCP window advertisement sizes to enhance performance over high-delay, high-bandwidth networks, such as satellite networks.

A standard TCP header uses a 16-bit field to report the receiver window size to the sender. Therefore, the largest window that can be used is 216 or 64 Kbytes. RFC 1323 introduces a mechanism to increase the window size to 230 or 1 Gbyte.

Sequence Numbers

A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received. This mechanism allows for straight-forward duplicate detection in the presence of retransmission. Numbering of octets within a segment is that the first data octet immediately following the header is the lowest numbered, and the following octets are numbered consecutively.

Quiz

Q1. TCP stands for _____________________ ?

A: Transmission Control Protocol

Q2. TCP is ________ and ____________ ?

a. connectionless, stateless

b. connection-orineted, stateless

c. connection-oriented, stateful

d. connectionless, stateful

A: C

Q3. Full Duplex Connection consists of ___ independent streams of data.

Ans: 2

Q4. Receiving host informs header of how much it is ready to receive. This is called ________________ ?

A: Window Advertisement

Q5. T/F: There is no way to inform TCP of congestion along the path

A: True

Q6. What is spoofing?

a. Where a packets claims its source to be other that what its source really is.

b. Same as "denial of service" attacks

c. Where a machine continually pings another machine

d. Where certain broadcasts are passed through a router

A: A

NOTE: There is protection built-in in IPv6 to against spoofing

Q6. Sequence Number in a TCP header is used for (list all that apply)

a. acknowledgements

b. upper layer information

c. reordering of the octets received

d. protocol dependent information

e. rejecting the duplicate octets

A: A,C,E

Q7. What is "keepalive�?

a. A keepalive is a small, layer-1 bit message that is transmitted by a

     network device to let directly-connected network devices know of its presence.

b. A keepalive is a small, layer-2 message that is transmitted by a

     network device to let directly-connected network devices know of its presence.

c. A keepalive is a small, layer-2 message that is transmitted by a

     network device to let it neighbors know of congestion

d. A keepalive is a small, layer-3 message that is transmitted by a

     network device to let directly-connected network devices know of its presence.

e. A keepalive is a small, layer-3 message that is transmitted by a

     network device to let it neighbors know of congestion

A: B

Q8. What is flow control ?

a. To keep the transmitting device from transmitting no faster than the receiving device can receive.

b. To find the best route to a destination

c. To determine which machine transmits packets on the wire on a given instance.

d. To be able to send a beacon message when congestion occurs.

A: A

Q9. Which of the following methods are used as flow control ?

Choose 3

a. Acknowledgements

b. Windowing

c. Traceroute

d. TTL

e. Sliding windows

A: A,B,E

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright � 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last Modified: March 12, 2019