引言：tcp是传输层的一个协议，关于使用，已经被http封装的很完善，也有很多人使用，今天就结合基础知识重新通过抓包认识一下三次握手、四次挥手等基本过程以及一些知识点。
一、抓包工具（通过对易问抓包分析）
wireshark
二、三次握手基本概念及注意点
2.1、三次握手
打开易问界面时，发起的第一次连接，第一次的请求中，http请求头connection: keep-alive长连接
其中54687是本地端口，即客户端发起方；9060是服务ng端口，即服务端接受方。
客户端发起syn信号，序列seq为0
服务端收到syn信号以后，返回服务端的同步信号和确认信号ack，序列为服务端序列新值，初始为0，确认信号为客户端发来的syn时seq值+1，此处为0+1=1
客户端收到ack信号后，表示客户端到服务端的连接已经建立；收到服务端的syn信号后，客户端发起ack信号，同理seq=0+1=1，ack=0+1=1，服务端收到ack以后表示服务端到客户端的连接已建立。三次握手以后，双向的连接已经建立，都变成ESTABLISH状态
（连接状态后截图故端口不一致）
2.2、注意点
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
为什么不能用两次握手进行连接？
为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。
三、四次挥手及注意点
3.1、四次挥手
此处http请求头connection：close连接断开发生了这个过程，有两点疑问：
a、ack值并未发生+1的现象
b、FIN和ACK的发送顺序不太一样
c、第一个FIN发送方是客户端，但是服务端连接状态是TIME_WAIT
将客户端连接拉出来：
两边都是TIME_WAIT进行了双向的主动关闭。为了验证这是否是正常得，进行了易信的连接监控和主动postman调用监控：
都是正常的流程，第二张的乱序和重复包发送的原因还未了解。用以上正常流程也还是验证了四次挥手过程
3.2、注意点
为什么需要等待 2 倍最大报文段生存时间之后再关闭链接？
1、 保证 TCP 协议的全双工连接能够可靠关闭；
2、保证这次连接的重复数据段从网络中消失，防止端口被重用时可能产生数据混淆。
