TCP是什么？
TCP(Transmission Control Protocol 传输控制协议)是一种面向连接(连接导向)的，可靠的，基于IP的传输层协议。


TCP的头部格式


TCP源端口（SourcePort）：16位的源端口其中包含发送方应用程序对应的端口。源端口和源IP地址标示报文发送端的地址。
TCP目的端口(Destination port)：16位的目的端口域定义传输的目的。这个端口指明报文接收计算机上的应用程序地址接口。
TCP序列号（序列码SN,Sequence　Number）: 表示我这个报文是第几个
TCP应答号(Acknowledgment   Number简称ACK Number或简称为ACK Field)：表示我期望收到另一端的下一包数据的编号
头长(Header Length)：TCP的头部大小，只是TCP头的长度
保留(Reserved)：4位值域，这些位必须是0。为了将来定义新的用途所保留
标志(Code Bits)：比较长在下面介绍
窗口大小(Window Size)：表示TCP接收或发送窗口的剩余空间用于TCP流量控制
校验位(Checksum)：发送一个基于内容计算的数值以确保发送的数据和接收端的数据一致
优先指针（紧急,Urgent  Pointer）：16位，指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。
选项(Option)：长度不定，但长度必须以是32bits的整数倍。常见的选项包括MSS、SACK、Timestamp等等，后续的内容会分别介绍相关选项。

标志位介绍

CWR(Congestion Window Reduce)：拥塞窗口减少标志被发送主机设置，用来表明它接收到了设置ECE标志的TCP包，发送端通过降低发送窗口的大小来降低发送速率
ECE(ECN Echo)：ECN响应标志被用来在TCP3次握手时表明一个TCP端是具备ECN功能的，并且表明接收到的TCP包的IP头部的ECN被设置为11。更多信息请参考RFC793。
URG(Urgent)：该标志位置位表示紧急(The urgent pointer) 标志有效。该标志位目前已经很少使用参考后面流量控制和窗口管理部分的介绍。
ACK(Acknowledgment)：取值1代表Acknowledgment Number字段有效，这是一个确认的TCP包。

PSH(Push)：该标志置位时，一般是表示发送端缓存中已经没有待发送的数据，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。
RST(Reset)：用于复位相应的TCP连接。通常在发生异常或者错误的时候会触发复位TCP连接。
SYN(Synchronize)：同步序列编号(Synchronize Sequence Numbers)有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。类似的后续文章介绍中当这个SYN标志位有效的时候我们称呼这个包为SYN包。
FIN(Finish)：带有该标志置位的数据包用来结束一个TCP会话，但对应端口仍处于开放状态，准备接收后续数据。当FIN标志有效的时候我们称呼这个包为FIN包。
TCP的三次握手是什么
TCP是面向连接的，在发送数据时无论哪一方发起通信首先必须先建立一条通信的链路，这个建立连接的过程叫做三次握手，三次握手的目的是同步连接双方的初始序列号和确认号，并且协商TCP窗口大小信息，用来进行流量控制。
第一次握手
建立连接。客户端发送请求保温段，将SYN位置为1，Seq为起始编号此时为x，之后客户端状态从CLOSED状态变为SYN_SENT状态
第二次握手
服务器收到SYN报文段，服务器收到科幻的SYN报文段，需要对SYN进行确认设置ACK为X+1（表示我需要的下一包数据为X+1的数据），同时自己还要发送SYN请求，将SYN表示位置1，之后设置自己的Seq为y，之后将这个报文发送给客户端，此时服务端进入SYN_RCVD状态
第三次握手
客户端收到服务器的SYN+ACK报文段，需要对这个报文进行确认，设置ACK 为Y+1（表示我收到了服务端的y号数据包，下一包数据需要的包为Y+1），这个报文完毕之后客户端与服务端都进入ESTABLISHED状态完成TCP三次握手
为什么要三次握手而不是两次或者一次
谢希仁的《计算机网络》中说道:“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
通俗解释一下就是为了避免因为网络拥堵造成早已发出的TCP连接在延迟一段时间后到达了服务端此时在服务端是不知道这个连接是什么时候来的，所以会发出回复的信息，若这个时候客户端没有再次发送确认的请求的话，server端会认为连接已经建立并且等待数据，这个状态下持续等待一个无效的连接会白白浪费很多资源。用生活来举例子就像是两个人在对话,A对B说我想和你视频，然后B在听到这句话后对A说“嗯，现在可以”，在A收到这句话后会再次对B确认，会对B说：“那我给你发请求了”，假如A没有对B说这句话，B一直在傻等这样岂不是会浪费B很多的时间？如果中间有这句A的回答存在我的B人在一段时间内没收到A的回复就可以认为A不想给B在发送请求了B就可以忙其他事情去了而不用一直在这里傻等。
TCP的四次挥手又是什么
四次挥手是在TCP通讯结束时发送的报文

Client端发起终端连接请求,也就是发送FIN报文，Server端接收到FIN报文意思是对server端说"我这边的报文发送完毕"，此时若是还有数据没有发送完成，则不必着急关闭Socket可以继续发送数据，但是在此时我需要回复给客户端"我知道你想要关闭连接了，但我这边还没有准备好，稍微等下我，我搞定了之后会通知你"这个时候client会进入到FIN_WAIT状态继续等待Server端的FIN报文，等到Server端确定数据已经收发完成会对Client再次发送FIN报文告诉Client说“好了，我这边数据发送完成，可以关闭连接了”Client在接收到报文后确认了可以关闭连接，但是因为网络传输的不可靠性所以这个时候client端会再次给server端发送回复消息，当server端确认到了client收到了他之前发送的那条指令后就可以放心的关闭连接了，client端等到2MSL后依然没有收到回复则说明了Server已经正常关闭，这个时候client端也会关闭连接
TCP的十一种状态

CLOSED状态：初始状态，表示TCP连接是“关闭的”或者“未打开的”。
LISTEN状态：表示服务端的某个端口正处于监听状态，正在等待客户端连接的到来。
SYN_SENT状态：当客户端发送SYN请求建立连接之后，客户端处于SYN_SENT状态，等待服务器发送SYN+ACK。
SYN_RCVD状态：当服务器收到来自客户端的连接请求SYN之后，服务器处于SYN_RCVD状态，在接收到SYN请求之后会向客户端回复一个SYN+ACK的确认报文。
ESTABLISED状态：当客户端回复服务器一个ACK和服务器收到该ACK（TCP最后一次握手）之后，服务器和客户端都处于该状态，表示TCP连接已经成功建立。
FIN_WAIT_1状态：当数据传输期间当客户端想断开连接，向服务器发送了一个FIN之后，客户端处于该状态。
FIN_WAIT_2状态：当客户端收到服务器发送的连接断开确认ACK之后，客户端处于该状态。
CLOSE_WAIT状态：当服务器发送连接断开确认ACK之后但是还没有发送自己的FIN之前的这段时间，服务器处于该状态。
TIME_WAIT状态：当客户端收到了服务器发送的FIN并且发送了自己的ACK之后，客户端处于该状态。
LAST_ACK状态：表示被动关闭的一方（比如服务器）在发送FIN之后，等待对方的ACK报文时，就处于该状态。
CLOSING状态：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。

TCP连接过程中Client端所经历的状态

TCP连接过程中Server端所经历的状态

我们知道。TCP是全双工的。建立连接与关闭连接，都是需要操作双向通道的。按理说。建立连接，也需要四次握手。但是因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时就不能合并了，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步挥手。
END

Table of Contents
TCP协议中的三次握手
直接上图
解释
来个更清晰的图
为什么要三次握手
SYN攻击
TCP协议中的四次挥手
直接上图
解释（以客户端发起断开为例子）
来个更清晰的图
为什么要四次分手
来个完整的图
问题
为什么连接的时候是三次握手，关闭的时候却是四次握手？
为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？



TCP协议中的三次握手

直接上图



解释
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认;
第二次握手：服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态;
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

来个更清晰的图

为什么要三次握手
谢希仁的《计算机网络》中是这样说的：

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误


说白了就是：防止了服务器端的一直等待而浪费资源

SYN攻击

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态.

Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击
netstat -n -p TCP | grep SYN_RECV

一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.

但是不能完全防范syn攻击。

TCP协议中的四次挥手

直接上图



注意：中断连接端可以是Client端，也可以是Server端，那么就是图上的流程反过来操作

解释（以客户端发起断开为例子）
假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说”我Client端没有数据要发给你了“
但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，”告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息“。– 这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，”告诉Client端，好了，我这边数据发完了，准备好关闭连接了“。
Client端收到FIN报文后，”就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“
Server端收到ACK后，”就知道可以断开连接了“。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

来个更清晰的图



为什么要四次分手

那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

来个完整的图



问题

为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

参考：
http://blog.csdn.net/whuslei/article/details/6667471/
http://www.jellythink.com/archives/705
http://www.jianshu.com/p/9968b16b607e
http://www.cnblogs.com/zmlctt/p/3690998.html





Table of Contents
TCP协议中的三次握手
直接上图
解释
来个更清晰的图
为什么要三次握手
SYN攻击
TCP协议中的四次挥手
直接上图
解释（以客户端发起断开为例子）
来个更清晰的图
为什么要四次分手
来个完整的图
问题
为什么连接的时候是三次握手，关闭的时候却是四次握手？
为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？



TCP协议中的三次握手

直接上图



解释
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认;
第二次握手：服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态;
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

来个更清晰的图

为什么要三次握手
谢希仁的《计算机网络》中是这样说的：

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误


说白了就是：防止了服务器端的一直等待而浪费资源

SYN攻击

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态.

Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击
netstat -n -p TCP | grep SYN_RECV

一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.

但是不能完全防范syn攻击。

TCP协议中的四次挥手

直接上图



注意：中断连接端可以是Client端，也可以是Server端，那么就是图上的流程反过来操作

解释（以客户端发起断开为例子）
假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说”我Client端没有数据要发给你了“
但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，”告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息“。– 这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，”告诉Client端，好了，我这边数据发完了，准备好关闭连接了“。
Client端收到FIN报文后，”就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“
Server端收到ACK后，”就知道可以断开连接了“。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

来个更清晰的图



为什么要四次分手

那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

来个完整的图



问题

为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

参考：
http://blog.csdn.net/whuslei/article/details/6667471/
http://www.jellythink.com/archives/705
http://www.jianshu.com/p/9968b16b607e
http://www.cnblogs.com/zmlctt/p/3690998.html

简明理解三次握手和四次挥手

注：三次握手和四次挥手本身并不复杂，但却可以从很多角度理解这两个过程，本文仅取一个视点解读，如有其它看法欢迎留言交流。

三次握手与四次挥手分别对应TCP连接建立过程与断开过程，先上TCP报文格式：

三次握手过程：

问题1： 为什么要三次握手？
答：三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收机能正常。
        第一次握手：Client什么都不能确认；Server确认了对方发送正常
        第二次握手：Client确认了：自己发送、接收正常，对方发送、接收正常；Server确认了：自己接收正常，对方发送正常
        第三次握手：Client确认了：自己发送、接收正常，对方发送、接收正常；Server确认了：自己发送、接收正常，对方发送接收正常
所以三次握手就能确认双发收发功能都正常，缺一不可。

问题2：为什么要发送特定的数据包，随便发不行吗？
答：三次握手的另外一个目的就是确认双方都支持TCP，告知对方用TCP传输。
        第一次握手：Server 猜测Client可能要建立TCP请求，但不确定，因为也可能是Client乱发了一个数据包给自己
        第二次握手：通过ack=J+1，Client知道Server是支持TCP的，且理解了自己要建立TCP连接的意图
        第三次握手：通过ack=K+1，Server知道Client是支持TCP的，且确实是要建立TCP连接

问题3：上图中的SYN和ACK是什么？
答：SYN是标志位，SYN=1表示请求连接；
        ACK其实就是ack后面加上的那个数，真正发送的时候不单独发ACK，只发ack，下面四次挥手的图同理


四次挥手：

问题1： 为什么要四次挥手？
答：根本原因是，一方发送FIN只表示自己发完了所有要发的数据，但还允许对方继续把没发完的数据发过来。
        举个例子：A和B打电话，通话即将结束后，A说“我没啥要说的了”，B回答“我知道了”，但是B可能还会有要说的话，A不能要求B跟着自己的节奏结束通话，于是B可能又巴拉巴拉说了一通，最后B说“我说完了”，A回答“知道了”，这样通话才算结束。

问题2：为什么双方要发送这样的数据包？
答：和握手的情况类似，只是为了让对方知晓自己理解了对方的意图。


参考文章：
1.http://blog.csdn.net/renzhenhuai/article/details/12105457
2.http://blog.chinaunix.net/uid-20726927-id-2455485.html
转载自：简明理解三次握手和四次挥手
一，三次握手
TCP使用三次握手建立一个连接：
第一次握手：客户端发送SYN包至服务器，并进入SYN_SENT状态，等待服务器确认
第二次握手：服务器收到客户端的SYN包，发送一个ACK，同时发送自己的SYN，此时服务器进入SYN_RCVD状态
第三次握手：客户端接收到服务器发送的SYN+ACK后，进入ESTABLISHED状态，并发送服务器SYN包的确认ACK，服务器接收到客户端ACK后，进入ESTABLISHED状态
当客户端和服务器都进入ESTABLISHED状态后，客户端和服务器之间就可以开始双向传递数据了
二，四次挥手
TCP使用四次挥手关闭一个连接：
第一次挥手：主动关闭方发送一个FIN并进入FIN_WAIT1状态
第二次挥手：被动关闭方接收到主动关闭方发送的FIN并发送ACK，此时被动关闭方进入CLOSE_WAIT状态；主动关闭方收到被动关闭方的ACK后，进入FIN_WAIT2状态
第三次挥手：被动关闭方发送一个FIN并进入LAST_ACK状态
第四次挥手：主动关闭方收到被动关闭方发送的FIN并发送ACK，此时主动关闭方进入TIME_WAIT状态，经过2MSL时间后关闭连接；被动关闭方收到主动关闭方的ACK后，关闭连接


tcp四次挥手，由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）
TCP采用四次挥手关闭连接如图所示为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。