一、 udp问题抓包分析

公司内部的一个 中间件报 UDP 连接异常的日志，问题很明显，对端的服务挂了，自然重启下就可以了。

让人疑惑的问题是 udp 是如何检测对端挂了？

err:  write udp 172.16.44.62:62651->172.16.0.46:29999: write: connection refused

err:  write udp 172.16.44.62:62651->172.16.0.46:29999: write: connection refused

err:  write udp 172.16.44.62:62651->172.16.0.46:29999: write: connection refused

UDP 协议既没有三次握手，又没有 TCP 那样的状态控制报文，那么如何判定对端的 UDP 端口是否已打开？

通过抓包可以发现，当服务端的端口没有打开时，服务端的系统向客户端返回 icmp ECONNREFUSED 报文，表明该连接异常。

通过抓包可以发现返回的协议为 ICMP，但含有源端口和目的端口，客户端系统解析该报文时，通过五元组找到对应的 socket，并 errno 返回异常错误，如果客户端陷入等待，则唤醒起来，设置错误状态。

(上面是 udp 异常情况下的 icmp，下面是udp 正常 情况下的icmp)

image.png image.png

写UDP socket程序的时候，在调用sendto或者recvfrom的时候，会发现有Connection refused错误返回，错误码是ECONNREFUSED。

对于懂得socket接口但是不很很懂网络的人，可能这根本就不是个问题，他会根据错误码知道远端没有这个服务端口，正如socket api的man手册中描述的那样：

ECONNREFUSED
A remote host refused to allow the network connection (typically because it is not running the requested service).

如果你十分精通TCP/IP栈，那么就想不通了，UDP既然无连接，怎么知道远端的情况呢？
UDP不正如协议标准描述的那样，发出去就不管了吗？
对于接收，没有数据就一直等，如果设置了NOWAIT，则直接返回EAGAIN，表示稍后再试。不管怎么说，也不会有ECONNREFUSED这么详细的信息返回才对啊。

既然UDP不会从对端返回任何错误信息，那么一定有别的什么返回了，这就涉及到了网络协议设计中的数据平面和控制平面了，对于控制平面的消息，可以是带内传输，也可以是带外传输。

数据分为两种，一种是带内数据，一种是带外数据。
带内数据就是我们平常传输或者说是口头叫的数据，带外数据就是我们接下来讲的内容。

许多的传输层都具有带外数据（也称为 经加速数据 ）的概念，想法就是连接的某段发生了重要的事情，希望迅速的通知给对端。这里的迅速是指这种通知应该在已经排队了的带内数据之前发送，也就是说，带外数据拥有更高的优先级。带外数据可以使用一条独立的传输层连接，也可以映射到传输普通数据的连接中。其中，UDP没有实现带外数据。

TCP中telnet、rlogin和ftp等，除了这样的远程非活跃应用之外，几乎很少有使用到带外数据的地方。

TCP利用其头部中的紧急指针标志以及紧急指针字段，给应用程序提供里一种紧急方式，所以TCP是利用传输普通数据的连接来传输带外数据。

对于TCP而言，无疑是带内传输的，因为它本身就是有连接的协议，协议本身会处理任何的错误和异常，然而对于UDP而言，因为其设计目的就是保持简单性，故不再附带有任何带内的控制消息逻辑，互联网上为了弥补这一类协议的控制逻辑的缺失，ICMP协议才显得尤为重要！

实际上，ICMP，根据名称就可以看出它是一种专门的控制协议，控制和指示IP层发生的事件。

ECONNREFUSED正是ICMP返回的，然而并不是所有的UDP socket都可以享用ICMP带来的错误提示，毕竟带外控制消息和协议本身的关联太松散了。
UDP socket必须显式的connect对端才可以。

现在问题又来了，既然UDP根本就是一个无连接的协议，connect的意义何在呢？
这其实是socket接口设计的范畴，和协议本身没有任何关系，当一个UDP socket去 connect一个远端时，并没有发送任何的数据包，其效果仅仅是在本地建立了一个五元组映射，对应到一个对端，该映射的作用正是为了和UDP带外的ICMP控制通道捆绑在一起，使得UDP socket的接口含义更加丰满。

image.png

我们知道，ICMP错误信息返回时，ICMP的包内容就是出错的那个原始数据包，根据这个原始数据包可以找出一个五元组，根据该五元组就可以对应到一个本地的connect过的UDP socket，进而把错误消息传输给该socket，应用程序在调用socket接口函数的时候，就可以得到该错误消息。
如果一个UDP socket没有调用过connect，那么即使有ICMP数据包返回，由于socket保持了UDP的完整语义，协议栈也就不保存关于该socket和对端关联的任何信息，因此也就无法找到一个特定的五元组将错误码传给它。

你不能太指望这个Connection refused以及一切带外返回的错误信息，因为你不能保证一定能收到远端发送的ICMP包，如果中间的某个节点或者本机禁掉了ICMP，socket api调用就无法捕获这些错误了。

当 UDP 连接异常时，可以通过 tcpdmp 工具指定 ICMP 协议来抓取该异常报文，毕竟对方是通过 icmp 返回的 ECONNREFUSED。

我们使用 tcpdump 抓包，先找到一个可以 ping 通的目标主机, 然后用 nc 模拟 udp 客户端去请求不存在的端口，出现 Connection refused.

# yum  -y install  nc 

# nc -vzu 172.16.0.46 8888
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 172.16.0.46:8888.
Ncat: Connection refused.

# tcpdump   -i   any   icmp   -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
17:01:14.075617 IP 172.16.0.46 > 172.16.0.62: ICMP 172.16.0.46 udp port 8888 unreachable, length 37
17:01:17.326145 IP 172.16.0.46 > 172.16.0.62: ICMP 172.16.0.46 udp port 8888 unreachable, length 37
17:01:17.927480 IP 172.16.0.46 > 172.16.0.62: ICMP 172.16.0.46 udp port 8888 unreachable, length 37
17:01:18.489560 IP 172.16.0.46 > 172.16.0.62: ICMP 172.16.0.46 udp port 8888 unreachable, length 37

注意： telnet 不支持 udp,，只支持 tcp，建议使用 nc 来探测 udp。

二、各种case的测试

case小结：

1. 当 ip 无法连通时, udp 客户端连接时，通常会显示成功
2. 当 udp 服务端程序关闭, 但系统还存在时, 对方系统会 icmp ECONNREFUSE 错误
3. 当对方有操作 iptables udp port drop 时，通常客户端也会显示成功.

# ping 172.16.0.65

PING 172.16.0.65 (172.16.0.65) 56(84) bytes of data.
From 172.16.0.46 icmp_seq=1 Destination Host Unreachable
From 172.16.0.46 icmp_seq=2 Destination Host Unreachable
From 172.16.0.46 icmp_seq=3 Destination Host Unreachable
From 172.16.0.46 icmp_seq=4 Destination Host Unreachable
From 172.16.0.46 icmp_seq=5 Destination Host Unreachable
From 172.16.0.46 icmp_seq=6 Destination Host Unreachable
^C
--- 172.16.0.65 ping statistics ---
6 packets transmitted, 0 received, +6 errors, 100% packet loss, time 4999ms
pipe 4

# nc   -zuv 172.16.0.65 8888
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 172.16.0.65:8888.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.02 seconds.

再次明确一点 udp 没有类似 tcp 那样的状态报文, 所以单纯对 UDP 抓包是看不到啥异常信息.
那么当 IP 不通时, 为啥nc udp 命令显示成功 ?

netcat nc udp 的逻辑

为什么当 ip 不连通或者报文被 drop 时，返回连接成功 ?

因为 nc 默认的探测逻辑很简单，只要在 2 秒钟内没有收到 icmp ECONNREFUSED 异常报文, 那么就认为 UDP 连接成功。

所以， UDP 客户端，给无法连通的地址发 UDP 报文时，其实也不会报错, 这时候通常会认为发送成功。

还是那句话 UDP 没有 TCP 那样的握手步骤，像 TCP 发送 syn 总得不到回报时, 协议栈会在时间退避下尝试 6 次，当 6 次还得不到回应，内核会给与错误的 errno 值。

UDP 连接信息

在客户端的主机上, 通过 ss lsof netstat 可以看到 UDP 五元组连接信息。

$ netstat  -tunalp | grep 29999

udp   0   0 172.16.0.46:44136  172.16.0.46:29999   ESTABLISHED 1285966/client

通常在服务端上看不到 UDP 连接信息, 只可以看到 udp listen 信息 ！

# netstat -tunalp|grep 29999

udp    0      0 :::29999     :::*     4038720/server

客户端重新实例化问题 ?
当 client 跟 server 已连接，server 端手动重启后，客户端无需再次重新实例化连接，可以继续发送数据。当服务端再次启动后，照样可以收到客户端发来的报文。

udp 本就无握手的过程，他的 udp connect() 也只是在本地创建 socket 信息. 在服务端使用 netstat 是看不到 udp 五元组的 socket。

image.png image.png

总结

当 udp 服务端的机器可以连通且无异常时，客户端通常会显示成功。
但当有异常时，会有以下的情况：

1. 当 ip 地址无法连通时, udp 客户端连接时，通常会显示成功

2. 当 udp 服务端程序关闭, 但系统还存在时, 对方系统通过 icmp ECONNREFUSE 返回错误，客户端会报错

3. 当对方有操作 iptables udp port drop 时，客户端也会显示成功

4 客户端和服务端互通数据，当服务进程挂了时，UDP 客户端不能立马感知关闭状态，只有当再次发数据时才会被对方系统回应 icmp ECONNREFUSE 异常报文， 客户端才能感知对方挂了。

三、参考

让人迷糊的 socket udp 连接问题
https://xiaorui.cc/archives/7255

TCP/IP 某些最常见的错误原因码 (errno)列表
https://www.cnblogs.com/jiu0821/p/5895723.html

技术分享之网络编程的那些事儿
https://xiaorui.cc/archives/7271

TCP 带外数据（即紧急模式的发送和接受）
https://blog.csdn.net/liushengxi_root/article/details/82563181

TCP带外数据
https://www.cnblogs.com/c-slmax/p/5553857.html

TCP-带外数据（紧急数据）
https://www.jianshu.com/p/65a4b8c059d4

什么是带外管理和带内管理？
https://zhuanlan.zhihu.com/p/341264872

FAQ-什么是带外管理和带内管理?它们的区别是什么？
https://support.huawei.com/enterprise/zh/knowledge/EKB1000055297