一、准备工作

1.1 Wireshark

下载安装（MAC版）

Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是截取网络封包，并尽可能显示出最为详细的网络封包资料。Wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换。 -- 摘自百度百科

官网地址：https://www.wireshark.org/
mac版本下载地址：https://2.na.dl.wireshark.org/osx/Wireshark%203.4.9%20Intel%2064.dmg

配置启动

第一次下载完之后，打开可能会碰到如下提示:
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头部结构，有个感觉：

image.png

2.2 TCP连接状态一览

整个TCP的连接和断开其实也是TCP状态的变化，所以提前了解下TCP状态都有哪些，更加有助于后面的分析。

图源：https://www.cnblogs.com/qingergege/p/6603488.html

三、实战TCP连接的三次握手

客户端--> telnet
服务端--> java程序

首先直接来看三次握手的整个流程：

TCP连接三次握手

接下来自上往下分析整个连接建立的过程。

3.1 服务端创建并监听socket

首先启动1.3节的java程序，通过netstat查看服务端socket状态：

netstat -a -n | grep 8888

image.png

3.2 客户端连接服务端socket

执行命令

telnet 127.0.0.1 8888

然后观察Wireshark得到如下报文：

image.png

上面圈出来的三条报文就是TCP三次握手的过程了，接下来分别看一下这三条报文，首先第一条

image.png

通过这里src port和dst port可以得知，这是客户端发向服务端的一条报文，这条报文带有SYN（即SYN=1）标志位，表示请求建立连接，那么此时客户端的状态应该变为了SYN_SEND；不过由于服务端马上进行ACK，这个状态捕捉不到，然后查看第二条报文：

image.png

image.png

netstat -a -n | grep 8888

image.png

可以看到此时客户端的socket和服务端socket状态都变为了ESTABLISHED，此时我们通过客户端和服务端进行通信

image.png

image.png

四、实战TCP连接的四次挥手

客户端--> telnet
服务端--> java程序

image.png

4.1 关闭客户端

当关闭客户端时，则客户端会向服务端发起断开请求，服务端收到断开请求，回应客户端：

image.png

此时查看客户端和服务端socket状态：

image.png

4.2 关闭服务端

关闭了客户端之后，再来关闭服务端进行观察

image.png

到这里差不多结束了，可能你会问，在第二节中列了那么多状态，怎么没看到其他状态呢？这是因为有些状态存在时间过短导致无法捕捉到，比如为什么没看到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请求多了去了，怎么才能准确找到我想要的报文？

这里设置过滤就好了，简单的方式就是根据端口过滤

image.png

5.3.2 注意点二

为什么过滤了之后，什么也没抓到？

这个要设置好抓包的网卡，因为我们都是本地启动的程序建立TCP，所以这里要设置抓包lo0网卡

image.png

参考

TCP的11种状态