拒绝八股文，透过实战理解TCP连接过程
一、准备工作
1.1 Wireshark
下载安装（MAC版）
Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是截取网络封包，并尽可能显示出最为详细的网络封包资料。Wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换。 -- 摘自百度百科
配置启动
第一次下载完之后，打开可能会碰到如下提示: you don't have permission to capture on that device
解决方式：
whoami
cd /dev
sudo chown ${whoami}:admin bp*
执行完上述命令重新启动工具即可。
1.2 netstat
Netstat是控制台命令,是一个监控TCP/IP网络的非常有用的工具，它可以显示路由表、实际的网络连接以及每一个网络接口设备的状态信息。Netstat用于显示与IP、TCP、UDP和ICMP协议相关的统计数据，一般用于检验本机各端口的网络连接情况。 -- 摘自百度百科
这个简单掌握一些命令参数就好
1.3 Java&IDE
这个玩意相信不用多说，这里只需要copy一些后面会用到的代码即可
这个程序大概就是监听指定端口，当有新的连接到来分配一个线程处理该socket的其他事件
public class BIOServer {
private final static ExecutorService EXECUTOR_SERVICE = Executors.newCachedThreadPool();
private static void handleSocket(Socket socket) throws IOException {
byte[] socketContent = new byte[1024];
int len;
while ((len = socket.getInputStream().read(socketContent)) != -1) {
System.out.println(
"Thread:" + Thread.currentThread().getName() + " receive message:" + new String(socketContent, 0, len));
}
}
public static void main(String[] args) throws IOException {
ServerSocket serverSocket = new ServerSocket(8888);
while (true) {
Socket socket = serverSocket.accept(); // 此处将阻塞直到连接建立
EXECUTOR_SERVICE.submit(() -> {
System.out.println("New connection!,Submit it to thread:" + Thread.currentThread().getName());
try {
handleSocket(socket);
} catch (IOException e) {
e.printStackTrace();
}
});
}
}
}
二、前景知识准备
在查看TCP连接报文时，主要看的就是TCP头部信息，所以这里先贴一下TCP头部结构，有个感觉：
2.2 TCP连接状态一览
整个TCP的连接和断开其实也是TCP状态的变化，所以提前了解下TCP状态都有哪些，更加有助于后面的分析。
三、实战TCP连接的三次握手
客户端--> telnet
服务端--> java程序
首先直接来看三次握手的整个流程：
接下来自上往下分析整个连接建立的过程。
3.1 服务端创建并监听socket
首先启动1.3节的java程序，通过netstat查看服务端socket状态：
netstat -a -n | grep 8888
可以看到服务端程序启动之后，这里socket状态为LISTEN，正在等待新连接与其建立连接。
3.2 客户端连接服务端socket
执行命令
telnet 127.0.0.1 8888
然后观察Wireshark得到如下报文：
上面圈出来的三条报文就是TCP三次握手的过程了，接下来分别看一下这三条报文，每一条报文都代表着一次握手，首先第一条：
通过这里src port和dst port可以得知，这是客户端发向服务端的一条报文，这条报文带有SYN（即SYN=1）标志位，表示请求建立连接，那么此时客户端的状态应该变为了SYN_SEND；不过由于服务端马上进行ACK，这个状态捕捉不到，然后查看第二条报文：
相同，通过这里src port和dst port可以得知，这是服务端发向客户端的一条报文，这条报文中带有SYN和ACK标志位，代表了服务端向客户端同时发出SYN建立连接以及服务端对客户端SYN请求的ACK确认，再来看第三条报文：
同理得知这条报文是客户端发给服务端的报文，携带标志位ACK，并且回复ack=y+1,这里的y就是第二条报文中服务端发向客户端报文携带的seq序列。到这里TCP三次握手完毕了，接下来通过netstat查看socket状态：
netstat -a -n | grep 8888
可以看到此时客户端的socket和服务端socket状态都变为了ESTABLISHED，此时我们通过客户端和服务端就建立成功可以开始进行通信了。
我们通过客户端发送一条消息看看：
可以看到我们发出一条消息后，服务端收到之后也立马进行ACK确认。
四、实战TCP连接的四次挥手
客户端--> telnet 服务端--> java程序
4.1 关闭客户端
当关闭客户端时，则客户端会向服务端发起断开请求，服务端收到断开请求，回应客户端：
此时查看客户端和服务端socket状态：
可以看到客户端socket此时因为已经收到了服务端的ack，所以此时状态为FIN_WAIT_2，并且服务端socket状态变为CLOSE_WAIT
4.2 关闭服务端
关闭了客户端之后，再来关闭服务端进行观察
目前只剩下客户端一个socket了，说明服务端socket已经完成了关闭，此时客户端处于TIME_WAIT阶段，需要等待2MSL之后才可以完成关闭。
到这里差不多结束了，可能你会问，在第二节中列了那么多状态，怎么没看到其他状态呢？这是因为有些状态存在时间过短导致无法捕捉到，比如为什么没看到SYN_SEND，那是因为当客户端发送SYN报文后，服务端马上就进行了确认，并且客户端也马上对服务端的确认进行了确认，所以这些中间状态很难捕捉。
五、TCP连接过程中的一些注意点
5.1 三次握手时
5.1.1 注意点一
为什么连接时只需要三次就够了，两次可以吗？四次可以吗？
- 假如握手两次
这种情况下，就相当于客户端发送syn连接请求，服务端进行确认，然后连接建立成功，总共两次。这样有没有问题呢？我们假如在客户端第一次发送syn连接请求时，由于网络拥塞等原因，服务端迟迟没有做出ACK应答，那么此时客户端就认为第一次发送的syn请求失效，然后重发一个新的syn连接请求，然后建立成功，紧接着啪啪啪通讯完毕，然后啪啪啪连接断开，看似没有什么问题了，但是假如最早发送的syn请求并非失效，只是网络等原因导致该请求滞留，正好此时该请求报文到达服务端，服务端收到连接请求建立连接成功（因为就两次，所以此时连接已经建立了），然后等待客户端发送数据，但是其实客户端早啪啪啪结束回家了，此时服务端就只能干等着白白消耗资源！
- 假如握手四次
四次无非就是和四次挥手一样，那么多的一步多到哪里了？从三次挥手过程可以看到，在客户端发送syn请求之后，客户端同时发给客户端syn连接请求，以及对客户端syn的ack确认，这两步能分开不？分开倒也是可以，但是能一步解决为啥要分两步？吃饱了撑的吗不是！
5.2 四次挥手时
5.2.1 注意点一
为什么当服务端发送FIN确认断开后，客户端不立马close，而是进入TIME_WAIT状态，等待2MSL之后才断开？
MSL（Max Segment Lifetime，最大分段生存期，指一个TCP报文在Internet上的最长生存时间）
回顾一下TCP连接断开的过程：
1）客户端发送FIN
2）服务端收到FIN发送ACK
3）服务端发送FIN
4）客户端收到FIN发送ACK
假设有这种场景：假如第4步客户端返回的ACK号丢失了，结果会如何呢？这时，服务器没有接收到ACK号，可能会重发一次FIN。如果这时客户端的套接字已经关闭删除了，会发生什么事呢？套接字被删除，那么套接字中保存的控制信息也就跟着消失了，套接字对应的端口号就会被释放出来。这时，如果别的应用程序要创建套接字，新套接字碰巧又被分配了同一个端口号，而服务器重发的FIN正好到达，会怎么样呢？本来这个FIN是要发给刚刚删除的那个套接字的，但新套接字具有相同的端口号，于是这个FIN就会错误地跑到新套接字里面，新套接字就开始执行断开操作了，这不乱了套了？
因为只要客户端socket不删除，就不会有新的socket绑定此端口，那应该等待多久呢？
这里就是上面所说的2MSL了，根据MSL定义：一个TCP报文在Internet上的最长生存时间，上面说的情况顶多就是客户端socket断开删除之后，第4步发送的ACK报文依然有效情况才会导致，那我们就一直等到这个报文失效了不就行了？那这样看到貌似只要等待1MSL就够了，那为啥还是2MSL呢？试想如果正好就在MSL临界值，服务端以为收不到了重发了FIN报文，那这种情况不是依然存在问题吗？所以保守起见再多等一下等到有可能重发的FIN报文也失效，这样就不会有问题啦！
5.3 关于Wireshark
5.3.1 注意点一
tcp请求多了去了，怎么才能准确找到我想要的报文？
这里设置过滤就好了，简单的方式就是根据端口过滤
5.3.2 注意点二
为什么过滤了之后，什么也没抓到？
这个要设置好抓包的网卡，因为我们都是本地启动的程序建立TCP，所以这里要设置抓包lo0网卡
