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

·  阅读 534
拒绝八股文,透过实战理解TCP连接过程!

小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。

一、准备工作

1.1 Wireshark

下载安装(MAC版)

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

官网地址:www.wireshark.org/
mac版本下载地址:2.na.dl.wireshark.org/osx/Wiresha…

配置启动

第一次下载完之后,打开可能会碰到如下提示: 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状态都有哪些,更加有助于后面的分析。

状态描述
LISTEN表示服务器端的某个SOCKET处于监听状态,等待客户端的连接
SYN-SENT客户端发送syn请求连接服务器端时的状态
SYN-RECEIVED服务器端收到客户端的请求连接syn报文时处于的状态
ESTABLISHEDTCP连接建立成功时的状态
FIN-WAIT-1当客户端向服务端发起断开连接FIN报文后,进入此状态,等待服务端ACK确认
FIN-WAIT-2当客户端收到服务端对FIN报文的ACK后,进入此状态。此时该连接为半连接,如果被动关闭方一直不进行关闭,那么该客户端socket将一直保持该状态
CLOSE-WAIT当服务端确认了客户端的FIN关闭报文之后进入此状态;此时服务端 可能有一些数据需要处理
LAST-ACK当被动关闭方发送FIN关闭报文之后,就进入该状态等待最终客户端的ACK确认
TIME-WAIT当主动关闭方收到被动关闭方的FIN关闭报文并进行ACK确认之后,主动方会进入此状态,并且等待2MSL
CLOSED关闭状态

image.png

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

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

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

image.png

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

3.1 服务端创建并监听socket

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

netstat -a -n | grep 8888
复制代码

image.png

可以看到服务端程序启动之后,这里socket状态为LISTEN,正在等待新连接与其建立连接。

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

相同,通过这里src port和dst port可以得知,这是服务端发向客户端的一条报文,这条报文中带有SYN和ACK标志位,代表了服务端向客户端同时发出SYN建立连接以及服务端对客户端SYN请求的ACK确认,再来看第三条报文:

image.png

同理得知这条报文是客户端发给服务端的报文,携带标志位ACK,并且回复ack=y+1,这里的y就是第二条报文中服务端发向客户端报文携带的seq序列。到这里TCP三次握手完毕了,接下来通过netstat查看socket状态:

netstat -a -n | grep 8888
复制代码

image.png

可以看到此时客户端的socket和服务端socket状态都变为了ESTABLISHED,此时我们通过客户端和服务端就建立成功可以开始进行通信了。

我们通过客户端发送一条消息看看:

image.png

image.png

可以看到我们发出一条消息后,服务端收到之后也立马进行ACK确认。

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

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

image.png

4.1 关闭客户端

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

image.png

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

image.png

可以看到客户端socket此时因为已经收到了服务端的ack,所以此时状态为FIN_WAIT_2,并且服务端socket状态变为CLOSE_WAIT

4.2 关闭服务端

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

image.png 目前只剩下客户端一个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请求多了去了,怎么才能准确找到我想要的报文?

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

image.png

5.3.2 注意点二

为什么过滤了之后,什么也没抓到?

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

image.png

参考

《网络是怎样连接的》
TCP的11种状态

分类:
后端
标签:
分类:
后端
标签: