Netty 出现 Connection reset by peer 异常的几个原因

最近使用 netty 过程中发现了几个比较细节的 Connection reset by peer 异常,做个笔记。

1. 服务端

a. 客户端设置 SO_LINGER=0

这个场景出现在用 Jedis ping 检测的场景,用完直接 close,服务端稳定出现 Connection reset by peer。

tcpdump 一下就很容易定位到问题所在,客户端收到 PONG 响应后直接发了一个 RST 包给服务端:

13:23:20.371000 IP client > server: Flags [S], seq 1642204245, win 29200, options [mss 1460,sackOK,TS val 3295733375 ecr 0,nop,wscale 9], length 0
    0x0000:  4500 003c ea2a 4000 3706 0fd4 0a74 f82b  E..<.*@.7....t.+
    0x0010:  0a1e 3d00 bb7c 0f7c 61e2 0c55 0000 0000  ..=..|.|a..U....
    0x0020:  a002 7210 a80f 0000 0204 05b4 0402 080a  ..r.............
    0x0030:  c470 e67f 0000 0000 0103 0309            .p..........
13:23:20.371024 IP server > client: Flags [S.], seq 1241908279, ack 1642204246, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
    0x0000:  4500 0034 0000 4000 ff06 3206 0a1e 3d00  E..4..@...2...=.
    0x0010:  0a74 f82b 0f7c bb7c 4a06 0437 61e2 0c56  .t.+.|.|J..7a..V
    0x0020:  8012 3908 64cb 0000 0204 05b4 0101 0402  ..9.d...........
    0x0030:  0103 0309                                ....
13:23:20.373036 IP client > server: Flags [.], ack 1, win 58, length 0
    0x0000:  4500 0028 ea2b 4000 3706 0fe7 0a74 f82b  E..(.+@.7....t.+
    0x0010:  0a1e 3d00 bb7c 0f7c 61e2 0c56 4a06 0438  ..=..|.|a..VJ..8
    0x0020:  5010 003a de6d 0000                      P..:.m..
13:23:20.373063 IP client > server: Flags [P.], seq 1:15, ack 1, win 58, length 14
    0x0000:  4500 0036 ea2c 4000 3706 0fd8 0a74 f82b  E..6.,@.7....t.+
    0x0010:  0a1e 3d00 bb7c 0f7c 61e2 0c56 4a06 0438  ..=..|.|a..VJ..8
    0x0020:  5018 003a ca43 0000 2a31 0d0a 2434 0d0a  P..:.C..*1..$4..
    0x0030:  5049 4e47 0d0a                           PING..
13:23:20.373068 IP server > client: Flags [.], ack 15, win 29, length 0
    0x0000:  4500 0028 43e4 4000 ff06 ee2d 0a1e 3d00  E..(C.@....-..=.
    0x0010:  0a74 f82b 0f7c bb7c 4a06 0438 61e2 0c64  .t.+.|.|J..8a..d
    0x0020:  5010 001d de7c 0000                      P....|..
13:23:20.373411 IP server > client: Flags [P.], seq 1:8, ack 15, win 29, length 7
    0x0000:  4500 002f 43e5 4000 ff06 ee25 0a1e 3d00  E../C.@....%..=.
    0x0010:  0a74 f82b 0f7c bb7c 4a06 0438 61e2 0c64  .t.+.|.|J..8a..d
    0x0020:  5018 001d 49df 0000 2b50 4f4e 470d 0a    P...I...+PONG..
13:23:20.375397 IP client > server: Flags [.], ack 8, win 58, length 0
    0x0000:  4500 0028 ea2d 4000 3706 0fe5 0a74 f82b  E..(.-@.7....t.+
    0x0010:  0a1e 3d00 bb7c 0f7c 61e2 0c64 4a06 043f  ..=..|.|a..dJ..?
    0x0020:  5010 003a de58 0000                      P..:.X..
13:23:20.375408 IP client > server: Flags [R.], seq 15, ack 8, win 58, length 0
    0x0000:  4500 0028 ea2e 4000 3706 0fe4 0a74 f82b  E..(..@.7....t.+
    0x0010:  0a1e 3d00 bb7c 0f7c 61e2 0c64 4a06 043f  ..=..|.|a..dJ..?
    0x0020:  5014 003a de54 0000                      P..:.T..

查看 Jedis 的源码发现 socket 有个比较特殊的配置 socket.setSoLinger(true, 0)

先看一下 man7/socket.7 的解释:

**SO_LINGER**
              Sets or gets the **SO_LINGER** option.  The argument is a
              *linger* structure.

                  struct linger {
                      int l_onoff;    /* linger active */
                      int l_linger;   /* how many seconds to linger for */
                  };

              When enabled, a close(2) or shutdown(2) will not return
              until all queued messages for the socket have been
              successfully sent or the linger timeout has been reached.
              Otherwise, the call returns immediately and the closing is
              done in the background.  When the socket is closed as part
              of exit(2), it always lingers in the background.

坦白说不是很明白啥意思。。。

最终在 stackoverflow 上找到一个比较容易理解的解释:

The typical reason to set a SO_LINGER timeout of zero is to avoid large numbers of connections sitting in the TIME_WAIT state, tying up all the available resources on a server.

When a TCP connection is closed cleanly, the end that initiated the close ("active close") ends up with the connection sitting in TIME_WAIT for several minutes. So if your protocol is one where the server initiates the connection close, and involves very large numbers of short-lived connections, then it might be susceptible to this problem.

This isn't a good idea, though - TIME_WAIT exists for a reason (to ensure that stray packets from old connections don't interfere with new connections). It's a better idea to redesign your protocol to one where the client initiates the connection close, if possible.

简而言之,设置 SO_LINGER(0) 可以不进行四次挥手直接关闭 TCP 连接,在协议交互上就是直接发 RST 包,这样的好处是可以避免长时间处于 TIME_WAIT 状态,当然 TIME_WAIT 存在也是有原因的,大部分评论都不建议这样配置。

2. 客户端

a. 服务端 accept 队列满

这个场景有点儿微妙,首先得理解一下 tcp 的两个队列。

这篇文章讲得比较清楚:SYN packet handling in the wild

accept 队列满通常是由于 netty boss 线程处理慢,特别是在容器化之后,服务刚启动的时候很容易出现 CPU 受限。

为了模拟这个现象,我写了个示例程序 shichaoyuan/netty-backlog-test,设置 SO_BACKLOG 为 1,并且在 accept 第一个连接后设置 autoRead 为 false,也就是让 boss 线程不再继续 accept 连接。

启动第一个 Client,可以正常连接,发送 PING,接收 PONG。

启动第二个 Client,也可以正常连接,但是没有收到 PONG:

[yuan@server ~]$ ss -nlt | grep 18088
LISTEN     1      1            *:18088                    *:*
[yuan@server ~]$ netstat -nap | grep 18088
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        1      0 0.0.0.0:18088           0.0.0.0:*               LISTEN      11155/java
tcp        0      0 server:18088      client:47496      ESTABLISHED 11155/java
tcp        5      0 server:18088      client:47568      ESTABLISHED -

可见这个连接创建成功了,已经在 Accept Queue 里了,但是进程没有 accept,所以没有与进程绑定。

启动第三个 Client,也可以正常连接,也没有收到 PONG:

[yuan@server ~]$ ss -nlt | grep 18088
LISTEN     2      1            *:18088                    *:*
[yuan@server ~]$ netstat -nap | grep 18088
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        2      0 0.0.0.0:18088           0.0.0.0:*               LISTEN      11155/java
tcp        0      0 server:18088      client:47496      ESTABLISHED 11155/java
tcp        5      0 server:18088      client:47568      ESTABLISHED -
tcp        5      0 server:18088      client:47826      ESTABLISHED -

与第二个连接一样。

启动第四个 Client,也可以正常连接,但是在发送 PING 后出现 Connection reset by peer:

[yuan@server ~]$ ss -nlt | grep 18088
LISTEN     2      1            *:18088                    *:*
[yuan@server ~]$ netstat -nap | grep 18088
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        2      0 0.0.0.0:18088           0.0.0.0:*               LISTEN      11155/java
tcp        0      0 server:18088      client:47496      ESTABLISHED 11155/java
tcp        5      0 server:18088      client:47568      ESTABLISHED -
tcp        5      0 server:18088      client:47826      ESTABLISHED -
tcp        0      0 server:18088      client:47876      SYN_RECV    -

这个连接在服务端并没有进入 accept queue,处于 SYN_RECV 状态,并且很快就消失了(因为 accept queue 已经满了,无法转入 ESTABLISHED 状态)。

抓包看一下:

17:43:47.437096 IP client.47876 > server.18088: Flags [S], seq 4054390029, win 29200, options [mss 1460,sackOK,TS val 1453776664 ecr 0,nop,wscale 9], length 0
    0x0000:  4500 003c ca15 4000 4006 f825 ac10 1031  E..<..@.@..%...1
    0x0010:  ac10 102f bb04 46a8 f1a9 150d 0000 0000  .../..F.........
    0x0020:  a002 7210 1f4a 0000 0204 05b4 0402 080a  ..r..J..........
    0x0030:  56a6 df18 0000 0000 0103 0309            V...........
17:43:47.437150 IP server.18088 > client.47876: Flags [S.], seq 2975142789, ack 4054390030, win 28960, options [mss 1460,sackOK,TS val 3821588077 ecr 1453776664,nop,wscale 9], length 0
    0x0000:  4500 003c 0000 4000 4006 c23b ac10 102f  E..<..@.@..;.../
    0x0010:  ac10 1031 46a8 bb04 b155 1385 f1a9 150e  ...1F....U......
    0x0020:  a012 7120 78af 0000 0204 05b4 0402 080a  ..q.x...........
    0x0030:  e3c8 ce6d 56a6 df18 0103 0309            ...mV.......
17:43:47.437239 IP client.47876 > server.18088: Flags [.], ack 1, win 58, options [nop,nop,TS val 1453776664 ecr 3821588077], length 0
    0x0000:  4500 0034 ca16 4000 4006 f82c ac10 1031  E..4..@.@..,...1
    0x0010:  ac10 102f bb04 46a8 f1a9 150e b155 1386  .../..F......U..
    0x0020:  8010 003a 48cc 0000 0101 080a 56a6 df18  ...:H.......V...
    0x0030:  e3c8 ce6d                                ...m
17:43:48.439207 IP server.18088 > client.47876: Flags [S.], seq 2975142789, ack 4054390030, win 28960, options [mss 1460,sackOK,TS val 3821589080 ecr 1453776664,nop,wscale 9], length 0
    0x0000:  4500 003c 0000 4000 4006 c23b ac10 102f  E..<..@.@..;.../
    0x0010:  ac10 1031 46a8 bb04 b155 1385 f1a9 150e  ...1F....U......
    0x0020:  a012 7120 78af 0000 0204 05b4 0402 080a  ..q.x...........
    0x0030:  e3c8 d258 56a6 df18 0103 0309            ...XV.......
17:43:48.439302 IP client.47876 > server.18088: Flags [.], ack 1, win 58, options [nop,nop,TS val 1453777666 ecr 3821588077], length 0
    0x0000:  4500 0034 ca17 4000 4006 f82b ac10 1031  E..4..@.@..+...1
    0x0010:  ac10 102f bb04 46a8 f1a9 150e b155 1386  .../..F......U..
    0x0020:  8010 003a 44e2 0000 0101 080a 56a6 e302  ...:D.......V...
    0x0030:  e3c8 ce6d                                ...m
17:43:52.522571 IP client.47876 > server.18088: Flags [P.], seq 1:6, ack 1, win 58, options [nop,nop,TS val 1453781750 ecr 3821588077], length 5
    0x0000:  4500 0039 ca18 4000 4006 f825 ac10 1031  E..9..@.@..%...1
    0x0010:  ac10 102f bb04 46a8 f1a9 150e b155 1386  .../..F......U..
    0x0020:  8018 003a a042 0000 0101 080a 56a6 f2f6  ...:.B......V...
    0x0030:  e3c8 ce6d 0450 494e 47                   ...m.PING
17:43:52.522605 IP server.18088 > client.47876: Flags [R], seq 2975142790, win 0, length 0
    0x0000:  4500 0028 249a 4000 4006 9db5 ac10 102f  E..($.@.@....../
    0x0010:  ac10 1031 46a8 bb04 b155 1386 0000 0000  ...1F....U......
    0x0020:  5004 0000 70d7 0000                      P...p...

从客户端视角来看连接确实是建成功了,有一个比较特殊的地方在三次握手之后,服务端又向客户端发送了一个 [S.],客户端回复了一个 [.],这个交互看起来不影响连接。

服务端后来销毁了连接,而客户端还认为连接是 ESTABLISHED 的,发送 PING 消息,服务端自然得回复一个 RST。

PS:我在 Windows 10 的 WSL2 中实验这种场景是建连接超时,可能不同的操作系统或 linux 版本对这个交互的过程处理不同,在此不进行进一步测试了。

以上,这个故事告诉我们判断连接是否可用,建成功之后应该发个心跳包测试一下。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容