1.概述

做后台工程化的同学，经常会遇到一些tcp协议上的报错，但却无法快速定位问题原因，其实很多tcp协议上的报错都是有很明确的原因，只要我们知道了报错的根因，就能做到快速排错。

2.实验环境和工具linux系统：Debian GNU/Linux 8.11 (jessie)；telnet：用于快速发起连接，并可以观察报错；tcpdump：tcp抓包工具，用于查看tcp协议层tcp报文段交互细节。3.TCP协议常见错误3.1 Address already in use

这个是大家在自测中最经常遇到的一个错误，导致这个错误的原因是服务启动时要监听的端口已经有另外一个服务在监听。此时可以使用netstat -lnpt | grep port来查看端口被哪个服务占用，再使用killall -9或者kill -9（江湖俗称“酒杀”，一招必杀）命令强杀服务，最后再启动自己的服务。

3.2 Connection refused

这个错误经常出现在和下游业务联调的时候出现，导致这个错误的原因是对端没有在对应的端口上开启监听（下游服务崩溃或者服务没有启动），我们来分析一下整个tcp报文段的交互过程：

客户端为了建立连接，向对端发送了tcp syn报文段；对端收到tcp syn的建立连接报文，发现对应的端口没有服务在监听，就返回一个rst（重置）报文段；客户端收到rst报文段之后，返回ECONNREFUSED的错误码。3.2.1 举个栗子确保系统没有在6666端口监听；使用终端工具，打开两个命令行终端；在一个终端执行命令（要先切换到root用户）：tcpdump -i lo port 6666 进行抓包；在另一个终端中执行命令：telnet 127.0.0.1 6666。3.2.2 结果分析tcpdump抓包的输出如下：

root@mylinux:~# tcpdump -i lo port 6666

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes

17:16:45.536614 IP localhost.25822 > localhost.6666: Flags [S], seq 2996337797, win 43690, options [mss 65495,sackOK,TS val 999915811 ecr 0,nop,wscale 10], length 0

17:16:45.536633 IP localhost.6666 > localhost.25822: Flags [R.], seq 0, ack 2996337798, win 0, length 0

从上面的抓包结果，我们看到对端在收到syn的tcp报文段之后，马上回复了rst的tcp报文段。

3.3 Broken pipe这个错误是在tcp连接对端已经关闭连接的情况下触发的，对端关闭连接之后tcp进入半关闭的状态，当你向这个半关闭的tcp连接继续写入数据时，就会报这个错误，此时进程会收到SIGPIPE信号，而SIGPIPE信号的默认处理动作是退出进程，所以当你发现开发的网络服务莫名其妙的自己退出时，可以考虑是否由这个错误码导致。处理Broken pipe错误其实也很简单，修改SIGPIPE信号的默认处理逻辑，比如可以忽略这个信号，也可以简单的打印一条日志即可。3.4 Connection timeout

这个错误也非常常见，在网络出现抖动（rtt比较大）或者tcp建连的syn报文段被防火墙丢弃时经常出现，如果使用操作系统的默认超时策略，connect会被阻塞很久，具体多久由系统的参数net.ipv4.tcp_syn_retries所决定，因为connect长时间被阻塞导致服务worker进程或者线程被耗尽，进而导致服务雪崩，最终不可用的case在生产环境中也屡见不鲜。

3.4.1 举个栗子使用终端工具，打开两个命令行终端；在一个终端执行命令（要先切换到root用户）：tcpdump host 8.8.8.8 进行抓包；在另一个终端中执行命令：date && telnet 8.8.8.8 || date。3.4.2 结果分析tcpdump抓包的输出如下：

root@mylinux:~# tcpdump host 8.8.8.8

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

19:27:06.327655 IP n226-201-007.byted.org.29808 > dns.google.telnet: Flags [S], seq 2312335739, win 29200, options [mss 1460,sackOK,TS val 1001871009 ecr 0,nop,wscale 10], length 0

19:27:07.325126 IP n226-201-007.byted.org.29808 > dns.google.telnet: Flags [S], seq 2312335739, win 29200, options [mss 1460,sackOK,TS val 1001871259 ecr 0,nop,wscale 10], length 0

19:27:09.329116 IP n226-201-007.byted.org.29808 > dns.google.telnet: Flags [S], seq 2312335739, win 29200, options [mss 1460,sackOK,TS val 1001871760 ecr 0,nop,wscale 10], length 0

19:27:13.337100 IP n226-201-007.byted.org.29808 > dns.google.telnet: Flags [S], seq 2312335739, win 29200, options [mss 1460,sackOK,TS val 1001872762 ecr 0,nop,wscale 10], length 0

telnet命令的输出如下：

root@mylinux:~$ date && telnet 8.8.8.8 || date

Sun Oct 18 19:29:28 CST 2020

Trying 8.8.8.8...

telnet: Unable to connect to remote host: Connection timed out

Sun Oct 18 19:29:43 CST 2020

我们从telnet命令执行前后打印的时间信息，可以看出telnet在connect上阻塞了15秒之后才超时，你多试几次发现都是15秒，为什么都是15秒？其实在上面已经说过了connect默认超时时间是由系统参数net.ipv4.tcp_syn_retries所决定，执行命令cat /proc/sys/net/ipv4/tcp_syn_retries可以看到当前系统配置值为3，也就是说syn最多重试3次，重试3次之后还没收到ack，则认为connect超时。

再回到tcpdump抓包的输出，我们逐条分析：

19:27:06 telnet客户端发出第一个syn包；19:27:07 1秒超时之后发出第二个syn包（第一次重试）；19:27:09 2秒超时之后发出第三个syn包（第二次重试）；19:27:13 4秒超时之后发出第四个syn包（第三次重试）；过了8秒之后第三次重试超时了，connect调用返回连接超时的错误码ETIMEDOUT。

1 + 2 + 4 + 8 = 15，所以每次connet操作都是15秒之后超时。

写在最后

我是字节跳动后端研发工程师，将持续分享后端研发相关的技术干货、架构设计、应聘和职业规划等方面的内容，希望得到你的关注。