TCP连接状态详解
2014-12-26 15:23:49 
阿炯
TCP状态LISTEN：侦听来自远方的TCP端口的连接请求
SYN-SENT：再发送连接请求后等待匹配的连接请求
SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认
ESTABLISHED：代表一个打开的连接
FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认
FIN-WAIT-2：从远程TCP等待连接中断请求
CLOSE-WAIT：等待从本地用户发来的连接中断请求
CLOSING：等待远程TCP对连接中断的确认
LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认
TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认
CLOSED：没有任何连接状态
TCP 连接状态
下面是此握手的简短说明。 在此上下文中"客户端"等请求连接并且"服务器"对等机器接受连接。 请注意这种表示法作为体系结构的主体不反映客户端/服务器的关系。
1. 建立连接
* 客户端将 SYN 消息，其中包含服务器的端口和客户端的初始序列号 (ISN)发送到服务器 (活动打开)。
* 服务器将发送回，其自己的 SYN 和 ACK 由客户端的 ISN + 1 组成)。
* 客户端发送一个 ACK 包含服务器的 ISN + 1)。
2. 连接操作下(已修改的三种方式握手)。
* 客户端发送 FIN (活动关闭)。 这是一个现在半关闭连接。 客户端不能再发送数据，但仍可从服务器接收数据。 在收到此 FIN，时服务器都会进入被动的关闭状态。
* 服务器发送一个 ACK (这是客户端 FIN 序列 + 1)
* 服务器发送它自己的 FIN。
* 客户端发送一个 ACK (这是服务器的 FIN 序列 + 1)。 在收到此 ACK，时服务器关闭连接。
半关闭连接可终止窗台接收数据时发送的数据。 套接字应用程序可以调用带有进入此状态设置为 1，第二个参数的关闭。
Netstat 输出
上面的 TCP 连接状态，请监视在 TCP 标记下的网络跟踪。也是可以通过运行 Netstat 实用工具，并查看状态列中确定连接的状态。
状态说明，netstat 中所示：
状态说明
------------ --------------------------------------------------------
SYN_SEND 指示活动的打开。
SYN_RECEIVED 服务器接收就到 SYN 从客户端。
已建立的客户端接收到服务器的 SYN 和会话已建立。
侦听服务器已准备好接受连接。
注意： 请参阅 listen() 套接字调用的文档。TCP 套接字侦听的状态中不显示-这是 NETSTAT 的限制。有关其他信息，请参见该的以下文章的 Microsoft 知识库文章：
134404 (http://support.microsoft.com/kb/134404/EN-US/ ) NETSTAT.EXE 不显示 TCP 侦听的套接字
FIN _ WAIT _ 1 关闭指示活动。
TIMED_WAIT 活动关闭后，客户端进入此状态。
CLOSE_WAIT 指示被动关闭。 服务器只接收到来自客户端的第一个 FIN。
FIN_WAIT_2 其第一个 FIN 从服务器的客户端只接收确认。
LAST_ACK 服务器处于此状态发送它自己的 FIN 时。
CLOSED 的服务器从客户端收到 ACK，并关闭连接。
例如，请考虑如下情形：
已终止一个套接字应用程序，但 netstat 报告套接字在 CLOSE_WAIT 状态。 这可能表示客户端正常关闭 (已发送 FIN) 连接，但服务器仍有打开的套接字。 这可能是未关闭套接字的所有线程或进程) 之间的一个实例的结果。
注意： 它是正常套接字在 TIME _ WAIT 状态的长时间。RFC793 中为两倍，最大片段生命周期 (MSL) 指定时间。 MSL 指定为 2 分钟。 因此，套接字可能处于 TIME _ WAIT 状态只要 4 分钟。 某些系统为该 MSL 实现不同的值 (少于 2 分钟)。
其他参考：
* 通过 Douglas Comer 的"internetworking TCP/IP，卷 1"
* "TCP/IP 说明，卷 1"的 Richard Stevens。
* "计算机网络"的 Andrew Tanenbaum
TCP数据报头和TCP连接建立过程
一个TCP数据报包含一个固定的20字节的头、一个可选部分以及0或多字节的数据。
对数据报的大小有两个限制条件：
首先，每个数据报(包括TCP头在内)必须适合IP的载荷能力，不能超过65535字节；其次，每个网络都存在最大传输单元MTU(maximum transfer unit)，要求每个数据报必须适合MTU。如果一个数据报进入了一个MTU小于该数据报长度的网络，那么处于网络边界上的路由器会把该数据报分解为多个小的数据报。
TCP数据报头
源端口、目的端口：16位长。标识出远端和本地的端口号。
顺序号：32位长。表明了发送的数据报的顺序。32 位的序列号由接收端计算机使用，重新分段的报文成最初形式。当SYN 出现，序列码实际上是初始序列码(ISN)，而第一个数据字节是ISN+1。这个序列号(序列码)是可以补偿传输中的不一致。
确认号：32位长。希望收到的下一个数据报的序列号。32 位的序列号由接收端计算机使用，重组分段的报文成最初形式，如果设置了ACK 控制位，这个值表示一个准备接收的包的序列码。
TCP头长：4位长。表明TCP头中包含多少个32位字。4 位包括TCP 头大小，指示何处数据开始。
接下来的6位未用。
连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。ACK：ACK位置1表明确认号是合法的。如果ACK为0，那么数据报不包含确认信息，确认字段被省略。TCP 报头内的确认编号栏内包含的确认编号(w+1，Figure：1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。
PSH：表示是带有PUSH标志的数据。接收方因此请求数据报一到便可送往应用程序而不必等到缓冲区装满时才传送。该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理telnet 或rlogin 等交互模式的连接时，该标志总是置位的。
RST：用于复位由于主机崩溃或其它原因而出现的错误的连接。还可以用于拒绝非法的数据报或拒绝连接请求。
SYN：用于建立连接。该标志仅在三次握手建立。
FIN：用于释放连接。
窗口(Window)：16 位，用来表示想收到的每个TCP 数据段的大小。窗口大小字段表示在确认了字节之后还可以发送多少个字节。
校验位(Checksum)：16 位TCP 头。源机器基于数据内容计算一个数值，收信息机要与源机器数值结果完全一样，从而证明数据的有效性。是为了确保高可靠性而设置的。它校验头部、数据和伪TCP头部之和。
优先指针(紧急,Urgent Pointer)：16 位，指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG 标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。
选项(Option)：长度不定，但长度必须以字节。如果没有选项就表示这个一字节的域等于0。
填充：不定长，填充的内容必须为0，它是为了数学目的而存在。目的是确保空
间的可预测性。保证包头的结合和数据的开始处偏移量能够被32 整除，一般额外的零以保
证TCP 头是32 位的整数倍。
可选项：0个或多个32位字。包括最大TCP载荷，窗口比例、选择重发数据报等选项。
1. 最大TCP载荷：允许每台主机设定其能够接受的最大的TCP载荷能力。在建立连接期间，双方均声明其最大载荷能力，并选取其中较小的作为标准。如果一台主机未使用该选项，那么其载荷能力缺省设置为536字节。
2. 窗口比例：允许发送方和接收方商定一个合适的窗口比例因子。这一因子使滑动窗口最大能够达到232字节。
3. 选择重发数据报：这个选项允许接收方请求发送指定的一个或多个数据报。
连接管理
在TCP中建立连接采用三次握手的方法。
为了建立连接，其中一方，如服务器，通过执行LISTEN和ACCEPT原语被动地等待一个到达的连接请求。
另一方，如客户方，执行CONNECT原语，同时要指明它想连接到的IP地址和端口号，设置它能够接受的TCP数据报的最大值，以及一些可选的用户数据。CONNECT原语发送一个SYN=1，ACK=0的数据报到目的端，并等待对方响应。
该数据报到达目的端后，那里的TCP实体将察看是否有进程在侦听目的端口字段指定的端口。如果没有，它将发送一个RST=1的应答，拒绝建立该连接。
如果某个进程正在对该端口进行侦听，于是便将到达的TCP数据报交给该进程，它可以接受或拒绝建立连接。如果接受，便发回一个确认数据报。
为了释放连接，每方均可发送一个FIN=1的TCP数据报，表明本方已无数据发送。当FIN数据报被确认后，那个方向的连接即告关闭。当两个方向上 的连接均关闭后，该连接就被完全释放了。一般情况下，释放一个连接需要4个TCP数据报：每个方向均有一个FIN数据报和一个ACK数据报。
经典案例，这是后来被称为MITNICK 攻击中KEVIN 开创了两种攻击技术： TCP 会话劫持和 SYN FLOOD(同步洪流)。
在这里我们讨论的是TCP 会话劫持的问题。先让我们明白TCP 建立连接的基本简单的过程。为了建设一个小型的模仿环境我们假设有3 台接入互联网的机器。A 为攻击者操纵的攻击机。B 为中介跳板机器(受信任的服务器)。C 为受害者使用的机器(多是服务器)，这里把C 机器锁定为目标机器。A 机器向B机器发送SYN 包，请求建立连接，这时已经响应请求的B 机器会向A 机器回应SYN/ACK表明同意建立连接，当A 机器接受到B 机器发送的SYN/ACK 回应时，发送应答ACK 建立，A 机器与B 机器的网络连接。这样一个两台机器之间的TCP 通话信道就建立成功了。
B 终端受信任的服务器向C 机器发起TCP 连接，A 机器对服务器发起SYN 信息，使C 机器不能响应B 机器。在同时A 机器也向B 机器发送虚假的C 机器回应的SYN 数据包，接收到SYN 数据包的B 机器(被C 机器信任)开始发送应答连接建立的SYN/ACK 数据包，这时C 机器正在忙于响应以前发送的SYN 数据而无暇回应B 机器，而A 机器的攻击者预测出B 机器包的序列号(现在的TCP 序列号预测难度有所加大)假冒C 机器向B 机器发送应答ACK 这时攻击者骗取B 机器的信任，假冒C 机器与B 机器建立起TCP 协议的对话连接。这个时候的C 机器还是在响应攻击者A 机器发送的SYN 数据。
TCP 协议栈的弱点：TCP 连接的资源消耗，其中包括：数据包信息、条件状态、序列号等。通过故意不完成建立连接所需要的三次握手过程，造成连接一方的资源耗尽，通过攻击者有意的不完成建立连接所需要的三次握手的全过程，从而造成了C 机器的资源耗尽。序列号的可预测性，目标主机应答连接请求时返回的SYN/ACK 的序列号时可预测的(早期TCP 协议栈，具体的可以参见1981年出的关于TCP雏形的RFC793文档)。
理解TCP/IP三次握手与四次挥手
TCP建立连接为什么是三次握手，而不是两次或四次？
TCP，名为传输控制协议，是一种可靠的传输层协议，IP协议号为6。另外说一句，原则上任何数据传输都无法确保绝对可靠，三次握手只是确保可靠的基本需要。客户端与服务器之间的通信：
关于四次挥手
先由客户端向服务器端发送一个FIN，请求关闭数据传输。
当服务器接收到客户端的FIN时，向客户端发送一个ACK，其中ack的值等于FIN+SEQ
然后服务器向客户端发送一个FIN，告诉客户端应用程序关闭。
当客户端收到服务器端的FIN是，回复一个ACK给服务器端。其中ack的值等于FIN+SEQ
为什么要4次挥手？
确保数据能够完整传输。
当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。
但未必被动方所有的数据都完整的发送给了主动方，所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，再发送FIN报文给主动方，告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文多数情况下都是分开发送的。
一、TCP报文格式
TCP报文格式图：
上图中有几个字段需要重点介绍下：
(1)序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
(2)确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
(3)标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
(A)URG：紧急指针(urgent pointer)有效。
(B)ACK：确认序号有效。
(C)PSH：接收方应该尽快将这个报文交给应用层。
(D)RST：重置连接。
(E)SYN：发起一个新连接。
(F)FIN：释放一个连接。
需要注意的是：
(A)不要将确认序号Ack与标志位中的ACK搞混了。
(B)确认方Ack=发起方Req+1，两端配对。
二、三次握手
TCP(Transmission Control Protocol)传输控制协议
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接
位码即Tcp标志位，有6种标示：
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
establish 建立，创建
所谓三次握手(Three-Way Handshake)即建立TCP连接，是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：
(1)第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
(2)第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack (number )=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
(3)第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
SYN攻击：
在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接(half-open connect)，此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：
#netstat -nap | grep SYN_RECV
三、四次挥手
三次握手耳熟能详，四次挥手估计就..所谓四次挥手(Four-Way Wavehand)即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：
由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
(1)第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
(2)第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号)，Server进入CLOSE_WAIT状态。
(3)第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
(4)第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图：
流程和状态在上图中已经很明了了，在此不再赘述，可以参考前面的四次挥手解析步骤。
四、附注
关于三次握手与四次挥手通常都会有典型的面试题，在此提出供有需求的人们参考：
(1)三次握手是什么或者流程？四次握手呢？答案前面分析就是。
(2)为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。
五、TCP网络传输数据包1460MSS和1448负载
1448字节是实际场景下，单个TCP包的实际运载能力。也就是说，实际场景下，上层调用send(1000KB)，下层会把这1000KB封装成多个TCP包进行发送。单个TCP包每次打包1448字节的数据进行发送。
每个TCP包在理论上应该能打包更多数据才对，但是实际场景下 TCP传输为什么会以这个1448作为打包单位呢？
这个实际TCP单包传输1448字节数据的根源在于 “ 以太网 Ethernet 最大的数据帧是 1518字节”。
1500字节的MTU
以太网Ethernet最大的数据帧是1518字节。 以太网帧的帧头 14字节和帧尾CRC校验4字节 (共占 18字节 )，剩下承载上层协议的地方也就是Data域最大就只剩1500字节。这个值就把它称之为MTU。
来看看linux上MTU默认值，查证一下：cat /sys/class/net/eth0/mtu
这个MTU值可以修改，但是现在大部分计算机网络都被以太网承载，所以修改这个值没有什么实际意义。
MSS决定TCP的单包传输量
MSS就是TCP数据包每次能够传输的最大量。为了达到最佳的传输效能，TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替(需要减去IP数据包包头的大小20Bytes和TCP数据段的 包头 20Bytes )所以往往 MSS 为 1460( 常见的SYN包中的MSS值)。通讯双方会根据双方提供的 MSS 值得最小值确定为这次连接的最大 MSS 值。
MSS为1460是由1500-20(IP头)-20(TCP头)计算出的。实际场景下，TCP包头中会带有12字节的选项--时间戳。这样，单个TCP包实际传输的最大量就缩减为1448字节。1448=1500-20(IP头)-32(20字节TCP头和12字节TCP选项时间戳)。
每个TCP包在理论上应该能打包更多数据才对，但是实际场景下TCP传输为什么会以这个1448作为打包单位呢？
理论上，单个TCP包能打包的数据量远远多于1448字节，现在为了适应MTU，只要在以太网上跑TCP，系统就默认最大以1448字节打包TCP。
假如我们用更大的数据量来打包会有什么结果呢？
答案是降低了传输效率。
超过MTU的大包反而降低效率的原因如下：IP层非常关心MTU，因为IP层会根据MTU来决定是否把上层传下来的数据进行分片。就像一条运输线路的承载能力是有限的，遇到大东西要运输，只能把大东西拆开成为散件，分开运输，到达目的地之后还必须能再次组装起来。当两台远程PC互联的时候，它们的数据需要穿过很多的路由器和各种各样的网络媒介才能到达对端，网络中不同媒介的MTU各不相同，就好比一长段的水管，由不同粗细的水管组成(MTU值不同)通过这段水管最大水量就要由中间最细的水管决定。
对于网络层的上层协议而言(我们以TCP/IP协议族为例)它们对水管粗细并不在意，它们认为这个是网络层的事情。网络层IP协议会检查每个从上层协议下来的数据包的大小，并根据本机MTU的大小决定是否作“分片”处理。分片最大的坏处就是降低了传输性能：本来一次可以搞定的事情，分成多次搞定，所以在网络层更高一层(就是传输层)的实现中往往会对此加以注意！
这个就是在以太网上，TCP不发大包，反而发送1448小包的原因。只要这个值TCP才能对链路进行效能最高的利用。
MSS 为什么是1460
21:01:42.648017 IP freeoa.4503 > node2.discard: Flags [S], seq 1415506235, win 14600, options [mss 1460,sackOK,TS val 106943306 ecr 0,nop,wscale 6], length 0
21:01:42.648017 IP freeoa.4503 > node2.discard: Flags [S], seq 1415506235, win 14600, options [mss 1460,sackOK,TS val 106943306 ecr 0,nop,wscale 6], length 0
Maximum Segment Size，TCP提交给IP层最大分段大小，不包含TCP Header和 TCP Option，只包含TCP Payload。
MSS是TCP用来限制Application层最大的发送字节数，是Tcp能发送的分组的最大长度。
MSS是系统默认的，就是系统TCP/IP栈所能允许的最大包。在建立连接时，这个值已经被确定了，这个值并不是客观的值，而是由tcp/ip的实现确定的。
如果底层物理接口MTU=1500 byte，则 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte，如果application 有2000 byte发送，就需要两个segment才可以完成发送，第一个TCP segment = 1460，第二个TCP segment = 540。
LINUX查看MTU值：
cat /sys/class/net/eth0/mtu
freeoa:/root#cat /sys/class/net/eth0/mtu
1500
MSS就是1460
六、TCP Connection States(连接状态)
SYN_SENT Indicates that the sender has initiated the active open process with the receiver.
SYN_RECEIVED Indicates that the receiver has received a SYN segment from the sender.
ESTABLISHED Indicates that the receiver has received a SYN segment from the sender, the sequence numbers are synchronized, and a connection is established.
LISTEN Indicates a state of readiness to accept connection requests.
FIN_WAIT_1 Indicates that an active close process has been initiated. This state forms the first state in the three-step connection termination process.
TIMED_WAIT Indicates that this side is waiting for acknowledgement from another side after it has initiated an active close process. The wait period is timed by a timer mechanism on the sender’s machine.
CLOSE_WAIT Indicates that a FIN segment has arrived from another side to begin the process of terminating the connection.
FIN_WAIT_2 Indicates that the acknowledgement for the FIN segment sent to another side has arrived. This state forms the second state in the three-step connection termination process.
LAST_ACK Indicates that user input for terminating a connection is obtained and that a FIN segment can now be sent to complete the connection termination process. This state is the last state in the three-step connection termination process.
CLOSED Indicates that the acknowledgement for the last FIN segment has arrived and that the connection is terminated.
七、TCP Flags
TCP flags are used to indicate a particular state during a TCP conversation. TCP flags can be used for troubleshooting purposes or to control how a particular connection is handled.
TCP flags are various types of flag bits present in the TCP header. Each of them has its own significance. They initiate connections, carry data, and tear down connections. The commonly used TCP flags are syn, ack, rst, fin, urg, psh. We will discuss the details later.
TCP Flags List
SYN (synchronize): Packets that are used to initiate a connection.
ACK (acknowledgment): Packets that are used to confirm that the data packets have been received, also used to confirm the initiation request and tear down requests
RST (reset): Signify the connection is down or maybe the service is not accepting the requests
FIN (finish): Indicate that the connection is being torn down. Both the sender and receiver send the FIN packets to gracefully terminate the connection
PSH (push): Indicate that the incoming data should be passed on directly to the application instead of getting buffered
URG (urgent): Indicate that the data that the packet is carrying should be processed immediately by the TCP stack
TCP: ..0….. = No urgent data
TCP: …0…. = Acknowledgement field not significant
TCP: ….0… = No Push function
TCP: …..0.. = No Reset
TCP: ……1. = Synchronize sequence numbers
TCP: …….0 = No Fin
Here are the numbers which match with the corresponding TCP flags.
URG ACK PSH RST SYN FIN
32 16 8 4 2 1
TCP flags can be combined together to make TCP data transfer efficiently like ack-psh in one TCP segment. We can use tcpdump to filter packets with TCP flags.
TCP Flags For 3 Way Handshake
SYN and ACK TCP flags are used for TCP 3 way handshake to establish connections.
1.SYN (Synchronize sequence number). This indicates that the segment contains an ISN. During the TCP connection establishment process, TCP sends a TCP segment with the SYN flag set. Each TCP peer acknowledges the receipt of the SYN flag by treating the SYN flag as if it were a single byte of data. The Acknowledgment Number field for the acknowledgment of the SYN segment is set to ISN + 1.
2.ACK (Acknowledgment field is significant). This indicates that the Acknowledgment field contains the next byte expected on the connection. The ACK flag is always set, except for the first segment of a TCP connection establishment.
TCP uses a three-way handshake to establish a reliable connection. The connection is full-duplex, and both sides synchronize (SYN) and acknowledge (ACK) each other. The exchange of these flags is performed in three steps: SYN, SYN-ACK, ACK.
TCP Flags For Normal Data Transfer Connection
URG and PSH are used during data transfer.
1.URG (Urgent Pointer field is significant). Indicates that the segment portion of the TCP segment contains urgent data and the Urgent Pointer field should be used to determine the location of the urgent data in the segment.
2.PSH (the Push function). Indicates that the contents of the TCP receive buffer should be passed to the Application Layer protocol. The data in the receive buffer must consist of a contiguous block of data from the left edge of the buffer.
More info about PSH tcp flag
In other words, there cannot be any missing segments of the byte stream up to the segment containing the PSH flag; the data cannot be passed to the Application Layer protocol until missing segments arrive.
Normally, the TCP receive buffer is flushed (the contents are passed to the Application Layer protocol) when the receive buffer fills with contiguous data or during normal TCP connection maintenance processes. The PSH flag overrides this default behavior and immediately flushes the TCP receive buffer.
The PSH flag is used also for interactive Application Layer protocols such as Telnet, in which each keystroke in the virtual terminal session is sent with the PSH flag set. Another example is the setting of the PSH flag on the last segment of a file transferred with FTP. Data sent with the PSH flag does not have to be immediately acknowledged.
TCP Flags For Aborting Connections
RST is used to abort connections. It is very useful to troubleshoot a network connection problem.
1.RST (Reset the connection). Indicates that the connection is being aborted. For active connections, a node sends a TCP segment with the RST flag in response to a TCP segment received on the connection that is incorrect, causing the connection to fail.
2.The sending of an RST segment for an active connection forcibly terminates the connection, causing data stored in send and receive buffers or in transit to be lost. For TCP connections being established, a node sends an RST segment in response to a connection establishment request to deny the connection attempt.
TCP Flags For Terminating Connection
FIN TCP flag is used to terminate TCP connection.
1.FIN (Finish sending data). Indicates that the TCP segment sender is finished sending data on the connection. When a TCP connection is gracefully terminated, each TCP peer sends a TCP segment with the FIN flag set.
2.A TCP peer does not send a TCP segment with the FIN flag set until all outstanding data to the other TCP peer has been sent and acknowledged. Each peer acknowledges receipt of the FIN flag by treating it as if it were a single byte of data. When both TCP peers have sent segments with the FIN flag set and received acknowledgment of their receipt, the TCP connection is terminated.
Additional TCP Flags
These CWR ECE NS TCP flags are not commonly used.
1.CWR (congestion window has been reduced). Indicates that the sending host has received a TCP segment with the ECE flag set. The congestion window is an internal variable maintained by TCP to manage the size of the send window.
2.ECE (TCP peer is ECN-capable).
3.Indicates that a TCP peer is ECN-capable during the TCP 3-way handshake and to indicate that a TCP segment was received on the connection with the ECN field in the IP header set to 11.
4.NS (1 bit): ECN-nonce – concealment protection