美文网首页思科DevNetJava 程序员Java
拒绝八股文,透过实战理解TCP连接过程

拒绝八股文,透过实战理解TCP连接过程

作者: 马小莫QAQ | 来源:发表于2021-10-26 14:12 被阅读0次

    一、准备工作

    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网卡

    原文链接:https://juejin.cn/post/7022262487839932423

    相关文章

      网友评论

        本文标题:拒绝八股文,透过实战理解TCP连接过程

        本文链接:https://www.haomeiwen.com/subject/nbzealtx.html