全球滚动:抓包分析RST报文

大家好，我是蓝胖子，今天我们来分析下网络连接中经常出现的RST信号，连接中出现RST信号意味着这条链接将会断开，来看下什么时候会触发RST信号，这在分析连接断开的原因时十分有帮助。

本文的讲解视频已经上传 抓包分析RST报文

在开始分析触发RST的场景之前，我们先来准备下需要的客户端和服务端代码，以方便我们进行测试。

(资料图片)

服务端代码目前先是在8080端口监听，然后将接收到的消息打印出来。

func main() {     listen, err := net.Listen("tcp", ":8080")     if err != nil {        log.Fatal(err)     }     go func() {        for {           conn, err := listen.Accept()           if err != nil {              log.Fatal(err)           }           buf := make([]byte, 1024)           n, err := conn.Read(buf)           if err != nil {              log.Fatal(err)           }           fmt.Println(string(buf[:n]))            }()     ch := make(chan int)     <-ch  }

客户端代码，连接8080端口然后打印hello world

func main() {     conn, err := net.Dial("tcp", "192.168.2.3:8080")     if err != nil {        log.Fatal(err)     }     _, err = conn.Write([]byte("hello world"))     if err != nil {        log.Fatal(err)     }  }

现在，来让我们测试下触发RST的各种场景。

这个场景比较容器，不启动服务端，然后对8080端口进行抓包，接着直接运行客户端程序，看看此时客户端收到的数据包是怎样的。

(base) ➜  ~ sudo tcpdump -i lo0 port 8080tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes18:58:14.745651 IP xiongchongdembp.63558 > xiongchongdembp.http-alt: Flags [S], seq 1854765658, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 98239951 ecr 0,sackOK,eol], length 018:58:14.745699 IP xiongchongdembp.http-alt > xiongchongdembp.63558: Flags [R.], seq 0, ack 1854765659, win 0, length 0

从tcpdump的抓包结果可以看出，客户端程序发出了握手信号[S]，直接被回复了[R.]RST信号，可见，服务端没有监听端口时，系统内核会对想要连接该端口的客户端回复RST信号。

再来看看客户端关闭后，对端继续发送消息的场景，这样的场景分为两种情况，一种事服务端发送keepalive消息，一种是服务端发送业务字节数据。

先来看看发送keepalive消息的场景，这次同样用tcpdump监听8080端口，不过为了更清晰的分析这次抓包文件，我将tcpdump的抓包文件存到了本地，之后wireshark再去打开，tcpdump抓包命名如下:

sudo tcpdump -i lo0 port 8080 -w lo.pcap

接着，用文章开头准备的代码段启动服务端，客户端，注意，此时服务端仅仅是打印了收到的消息，并没有对客户端进行回应，而客户端进程也是在发送消息后就被销毁了。来看看此时的抓包文件

当客户端进程关闭时，即使没有显示的调用close方法，内核也会帮助我们关闭连接，发送fin信号，此时客户端连接会进入fin wait1状态，在这个状态下，客户端还是可以正常回应keep alive消息，不过超过fin wait1状态的超时时间时，则会被系统内核自动回收掉，此时再发送keepalive消息就会回复RST 这个超时时间在linux内核上可以通过下面这个文件进行修改,默认是1min。

root@ecs-295280:~# cat /proc/sys/net/ipv4/tcp_fin_timeout60

接着来看下，服务端在客户端关闭(无论是主动调用close方法还是进程结束连接被内核关闭都一样)的场景下主动发送消息触发RST的场景。

此时需要修改下目前服务端的代码了。

func main() {     listen, err := net.Listen("tcp", ":8080")     if err != nil {        log.Fatal(err)     }     go func() {        for {           conn, err := listen.Accept()           if err != nil {              log.Fatal(err)           }           buf := make([]byte, 1024)           n, err := conn.Read(buf)           if err != nil {              log.Fatal(err)           }           fmt.Println(string(buf[:n]))  time.Sleep(time.Second)         _, err = conn.Write([]byte("receive msg"))           if err != nil {              fmt.Println(err)           }       }()     ch := make(chan int)     <-ch  }

这次的服务端不仅打印了收到的消息，还将消息发送给了客户端,为了确保服务端发送消息时，客户端已经关闭了，我还在服务端收到消息时故意停留了1s再发送消息。

此时用tcpdump抓包如下:

可以看到在连接关闭后，还往连接发送消息是会触发RST信号的。

接着来看下服务端读缓冲区有数据的情况下，服务端关闭连接的场景，这个场景服务端会直接发送RST信号，我们对客户端代码进行修改，让它发送完消息进程等待状态，防止进程结束。

func main() {     conn, err := net.Dial("tcp", "192.168.2.3:8080")     if err != nil {        log.Fatal(err)     }     _, err = conn.Write([]byte("hello world"))     if err != nil {        log.Fatal(err)     }     time.Sleep(time.Hour)  }

然后对服务端代码进行修改，握手成功后等待2s来确保客户端发送的消息到达，然后关闭连接。

func main() {     listen, err := net.Listen("tcp", ":8080")     if err != nil {        log.Fatal(err)     }     go func() {        for {           conn, err := listen.Accept()           if err != nil {              log.Fatal(err)           }           time.Sleep(2 * time.Second)           conn.Close()        }       }()     ch := make(chan int)     <-ch  }

对这个场景的抓包如下:

可见，服务端在关闭连接时直接发送了RST信号。

再来看下最后一个RST信号触发的场景，默认情况下，当写缓冲区还有数据时，如果调用close方法，会将写缓冲区的发送到对端然后再发送fin信号，但是如果设置了linger属性，那么情况会变得不同。

// SetLinger sets the behavior of Close on a connection which still// has data waiting to be sent or to be acknowledged.  //  // If sec < 0 (the default), the operating system finishes sending the  // data in the background.  //  // If sec == 0, the operating system discards any unsent or  // unacknowledged data.  //  // If sec > 0, the data is sent in the background as with sec < 0. On  // some operating systems after sec seconds have elapsed any remaining  // unsent data may be discarded.func (c *TCPConn) SetLinger(sec int) error 

如果写缓冲区还有数据或者发送了数据但是没有被ack，当设置linger为0时，进行close，会直接将写缓冲区数据丢弃并且往对端发送RST信号。

为了验证这种场景，我们将服务端的代码再改动下，将连接linger属性设置为0，并且在写入一段数据后马上关闭。

func main() {     listen, err := net.Listen("tcp", ":8080")     if err != nil {        log.Fatal(err)     }     go func() {        for {           conn, err := listen.Accept()           if err != nil {              log.Fatal(err)           }           buf := make([]byte, 1024)           n, err := conn.Read(buf)           if err != nil {              log.Fatal(err)           }           conn.(*net.TCPConn).SetLinger(0)           fmt.Println(string(buf[:n]))           _, err = conn.Write([]byte("receive msg"))           if err != nil {              fmt.Println(err)           }           conn.Close()       }()     ch := make(chan int)     <-ch  }

客户端程序仍然保持在发送消息后，睡眠1小时的状态，防止进程结束

func main() {     conn, err := net.Dial("tcp", "192.168.2.3:8080")     if err != nil {        log.Fatal(err)     }     _, err = conn.Write([]byte("hello world"))     if err != nil {        log.Fatal(err)     }     time.Sleep(time.Hour)  }

对这种场景的抓包如下: