原文地址：https://blog.csdn.net/libaineu2004/article/details/79020403
TCP(Transmission Control Protocol) 传输控制协议
三次握手
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)
Sequence number(顺序号码) Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
在TCP/IP协议中，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状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据.
实例:
IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;
第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;
第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。
图解：
一个三次握手的过程（图1，图2）
（图1）
（图2）
第一次握手的标志位（图3）
我们可以看到标志位里面只有个同步位，也就是在做请求(SYN)
（图3）
第二次握手的标志位（图4）
我们可以看到标志位里面有个确认位和同步位，也就是在做应答(SYN + ACK)
（图4）
第三次握手的标志位（图5）
我们可以看到标志位里面只有个确认位，也就是再做再次确认(ACK)
（图5）
一个完整的三次握手也就是 请求---应答---再次确认
四次分手：
由于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）。
状态详解:
CLOSED： 这个没什么好说的了，表示初始状态。
LISTEN： 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
SYN_RCVD： 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本 上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态 时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT： 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED：这个容易理解了，表示连接已经建立了。
FIN_WAIT_1： 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别 是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即 进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马 上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
TIME_WAIT： 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING： 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什 么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报 文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT： 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对 方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK： 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
总结：
1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的.
2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
-------------------
说到tcp协议，凡是稍微看过的人都能顺口说出三次握手和四次断连，再牛逼的一点的就能够把每个状态（SYNC_SENT、CLOSE_WAIT。。。。。。等）都能背出来，
而说道socket编程，基本上写过网络编程的人都会熟悉那几个标准的API：socket、connect、listen、accept。。。。。。等
但是，我敢打赌很少有人明白tcp状态和socket编程API之间的关系。不信？ 看看如下几个问题你是否知道吧：
1）什么时候客户端才能够连接上server端， 是server端调用bind后还是listen后还是accept后 ？
2）什么情况下会出现FIN_WAIT_2状态
。。。。。。。。。。。。。。。。。。。。。
本周打破砂锅问到底的精神以及实事求是的精神，我用python脚本写了一些脚本测试这些情况，看完后你一定会大呼过瘾，对tcp的协议和socket编程的理解又更上层楼。
注：以下测试是在Linux（2.6.18）平台上用python（2.7）脚本测试，其它平台没有测试，有兴趣可以自己测试一下。
【连接过程测试和验证】
第1种情况：client调用connect，server只是调用了socket + bind，没有调用listen
tcpdump抓包如下：
抓包结果显示：server端直接回复了RST包
此时使用netstat或者ss命令去查看，无论是client还是server，都查不到连接
第2种情况：client调用connect，server调用了socket + bind + listen
tcpdump抓包如下：
抓包结果显示：三次握手完成
使用ss工具去查看，client和server都显示ESTAB
[html] view plain copy
- [liyh@localhost ~]$ ss -t -n | grep 50000
- ESTAB 0 0 10.1.73.45:55354 10.1.73.76:50000
第3种情况：client调用connect + send，server调用了socket + bind + listen + accept + recv + send
tcpdump抓包如下：
抓包结果显示：三次握手完成，并且双方都可以发送和接受数据了
使用ss工具去查看，client和server都显示ESTAB
[html] view plain copy
- [liyh@localhost ~]$ ss -t -n | grep 50000
- ESTAB 0 0 10.1.73.45:41363 10.1.73.76:50000
【连接过程总结】
1）可以看到，只有当server端listen之后，client端调用connect才能成功，否则就会返回RST响应拒绝连接
2）只有当accept后，client和server才能调用recv和send等io操作
3）socket API调用错误不会导致client出现SYN_SENT状态，那么只能是网络设备丢包（路由器、防火墙）才会导致SYNC_SENT状态
【断连过程测试和总结】
第1种情况：client调用close，但server没有调用close
tcpdump抓包如下：
抓包结果显示：client发送了fin包，server端应答了ack包
使用ss工具去查看，client显示FIN_WAIT_2状态：
[html] view plain copy
- [liyh@localhost ~]$ ss -t -n | grep "10.1.73.76:50000"
- FIN-WAIT-2 0 0 10.1.73.45:47630 10.1.73.76:50000
server显示CLOSE-WAIT状态
[html] view plain copy
- [jws@jae_test ~]$ ss -t -n | grep 50000
- CLOSE-WAIT 1 0 10.1.73.76:50000 10.1.73.45:47630
而且有一个值得注意的现象是：client的连接过一段时间就没有了，而server的连接一直处于CLOSE_WAIT状态
原因在于Linux系统内核中有一个参数可以控制FIN_WAIT_2的时间：tcp_fin_timeout
第2种情况：client调用close，server调用close
tcpdump抓包如下：
抓包结果显示：熟悉的四次断连来啦
使用ss工具去查看，client显示TIME-WAIT状态
[html] view plain copy
- [liyh@localhost ipv4]$ ss -a -n | grep 50000
- TIME-WAIT 0 0 10.1.73.45:39751 10.1.73.76:50000
server端使用ss工具去看已经看不到连接了
第3种情况：server端被kill了
tcpdump抓包如下：
抓包结果显示：熟悉的四次断连来啦
咦，怎么会和正常的server close一样呢？答案就在于操作系统的实现：
close函数其实本身不会导致tcp协议栈立刻发送fin包，而只是将socket文件的引用计数减1，当socket文件的引用计数变为0的时候，操作系统会自动关闭tcp连接，此时才会发送fin包。
这也是多进程编程需要特别注意的一点，父进程中一定要将socket文件描述符close，否则运行一段时间后就可能会出现操作系统提示too many open files
第4种情况：client端调用shutdown操作
shutdown操作有三种关闭方式：SHUT_RD、SHUT_WR、SHUT_RDWR，分别测试后发现有趣的现象。
1）如果是SHUT_RD，则tcpdump抓包发现没有发送任何包；
2）如果是SHUT_WR或者SHUT_RDWR，则client会发送FIN包给server，
若server收到后执行close操作，则server发送FIN给client，最终连接被关闭。
SHUT_WR或者SHUT_RDWR抓包显示如下：
使用ss命令查看，client显示如下：
[html] view plain copy
- [liyh@localhost ~]$ ss -a | grep 50000
- TIME-WAIT 0 0 10.1.73.45:45641 10.1.73.76:50000
server显示连接已经被关闭了。
关于shutdown的详细解释可以参考：http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html
归纳一下SHUT_RD的处理：
1）client端不再接收数据，如果有新的数据到来，直接丢弃(reject)
2）没有发送任何tcp包，所以server端并不知道这个状态，server端可以继续发送数据，但由于1）的原因，发了也白发
归纳一下SHUT_WR或者SHUT_RDWR的处理：
1）停止传送数据（不能再调用write操作），丢弃缓冲区中未发送的数据（已调用write但底层tcp协议栈还没发送的）
2）停止等待已发送数据的确认消息，已发送未确认的数据不再重发
【断连过程总结】
1）close只是减少socket文件的引用计数，当计数减为0后，操作系统执行tcp的断连操作
2）client端close后server端不close，会导致client端连接状态为FIN_WAIT_2，server端连接状态为CLOSE_WAIT
正常编程肯定不会这样处理，一般都是在异常处理跳转（C++/JAVA等）导致没有close，或者整个系统异常导致没有close（例 如JVM内存出现out of memory错误）
3）shutdown的处理逻辑比较复杂，非特殊情况不要乱用，很容易出问题
4）进程退出后操作系统会自动回收socket，发起tcp关闭流程操作