connection reset by peer

1、connection reset by peer?

单纯从应用层日志来看的话，几乎难以确定 connection reset by peer 的底层原因。所以，我们就展开了抓包工作。具体做法是：

• 我们需要选择一端做抓包，这次是客户端；
• 检查应用日志，发现没几分钟就出现了 connection reset by peer 的报错；
• 对照报错日志和抓包文件，寻找线索。

我们先看一下，这些报错日志长什么样子：

2015/12/01 15:49:48 [info] 20521#0: *55077498 recv() failed (104: Connection reset by peer) while sending to client, client: 10.255.252.31, server: manager.example.com, request: "POST /WebPageAlipay/weixin/notify_url.htm HTTP/1.1", upstream: "http:/10.4.36.207:8080/WebPageAlipay/weixin/notify_url.htm", host: "manager.example.com"
2015/12/01 15:49:54 [info] 20523#0: *55077722 recv() failed (104: Connection reset by peer) while sending to client, client: 10.255.252.31, server: manager.example.com, request: "POST /WebPageAlipay/app/notify_url.htm HTTP/1.1", upstream: "http:/10.4.36.207:8080/WebPageAlipay/app/notify_url.htm", host: "manager.example.com"
2015/12/01 15:49:54 [info] 20523#0: *55077710 recv() failed (104: Connection reset by peer) while sending to client, client: 10.255.252.31, server: manager.example.com, request: "POST /WebPageAlipay/app/notify_url.htm HTTP/1.1", upstream: "http:/10.4.36.207:8080/WebPageAlipay/app/notify_url.htm", host: "manager.example.com"
2015/12/01 15:49:58 [info] 20522#0: *55077946 recv() failed (104: Connection reset by peer) while sending to client, client: 10.255.252.31, server: manager.example.com, request: "POST /WebPageAlipay/app/notify_url.htm HTTP/1.1", upstream: "http:/10.4.36.207:8080/WebPageAlipay/app/notify_url.htm", host: "manager.example.com"
2015/12/01 15:49:58 [info] 20522#0: *55077965 recv() failed (104: Connection reset by peer) while sending to client, client: 10.255.252.31, server: manager.example.com, request: "POST /WebPageAlipay/app/notify_url.htm HTTP/1.1", upstream: "http:/10.4.36.207:8080/WebPageAlipay/app/notify_url.htm", host: "manager.example.com"

日志分析

• recv() failed：这里的 recv() 是一个系统调用，也就是 Linux 网络编程接口。它的作用呢，看字面就很容易理解，就是用来接收数据的。我们可以直接 man recv，看到这个系统调用的详细信息，也包括它的各种异常状态码。
• 104：这个数字也是跟系统调用有关的，它就是 recv() 调用出现异常时的一个状态码，这是操作系统给出的。在 Linux 系统里，104 对应的是 ECONNRESET，也正是一个 TCP 连接被 RST 报文异常关闭的情况。
• upstream：在 Nginx 等反向代理软件的术语里，upstream 是指后端的服务器。也就是说，客户端把请求发到 Nginx，Nginx 会把请求转发到 upstream，等后者回复 HTTP 响应后，Nginx 把这个响应回复给客户端。注意，这里的“客户端 <->Nginx”和“Nginx<->upstream”是两条独立的 TCP 连接，也就是下图这样：

2、wireshark常用过滤器

ip.addr eq my_ip：过滤出源IP或者目的IP为my_ip的报文
ip.src eq my_ip：过滤出源IP为my_ip的报文
ip.dst eq my_ip：过滤出目的IP为my_ip的报文
tcp.seq eq 1 and tcp.ack eq 1 RST 的序列号是 1，确认号也是 1
frame.time >="dec 01, 2015 15:49:48" and frame.time <="dec 01, 2015 15:49:49" #frame.time 过滤器
frame.time >="dec 01, 2015 15:49:48" and frame.time <="dec 01, 2015 15:49:49" and ip.addr eq 10.255.252.31 and tcp.flags.reset eq 1 and !(tcp.seq eq 1 or tcp.ack eq 1)

找到 TCP RST 报文。这就要用到另外一类过滤器了，也就是 tcp.flags，而这里的 flags，就是 SYN、ACK、FIN、PSH、RST 等 TCP 标志位。

对于 RST 报文，过滤条件就是：

tcp.flags.reset eq 1
ip.addr eq 10.255.252.31 and tcp.flags.reset eq 1

3、客户端握手的内核调用

客户端发起连接，依次调用的是这几个系统调用：

• socket()
• connect()

而服务端监听端口并提供服务，那么要依次调用的就是以下几个系统调用：

• socket()
• bind()
• listen()
• accept()

服务端的用户空间程序要使用 TCP 连接，首先要获得上面最后一个接口，也就是 accept() 调用的返回。而 accept() 调用能成功返回的前提呢，是正常完成三次握手。