Golang Go语言中明明关闭了 udp 连接,但 netstat 显示连接越来越多,偶尔会减一个,但减小的速度远远慢于增加的速度

发布于 1周前 作者 sinazl 来自 Go语言

Golang Go语言中明明关闭了 udp 连接,但 netstat 显示连接越来越多,偶尔会减一个,但减小的速度远远慢于增加的速度

两个 golang 程序,一个实现通用的功能,接口是 udp server ;

另一个根据业务处理数据,并提供 http 接口;

另外一个 shell 脚本,用 curl 定时调用 http 接口,间接调用了 udp 接口。

结果 netstat 发现与 udp 的连接越来越多,偶尔会减一个,总体一直在增长;

netstat 发现进程 id 是提供 http 接口的那个程序,我使用的是短连接,net.Dial 后,就 defer conn.Close(),按理说肯定能关闭,事实也是并非连接数量不减小,但减小速度太慢了。


更多关于Golang Go语言中明明关闭了 udp 连接,但 netstat 显示连接越来越多,偶尔会减一个,但减小的速度远远慢于增加的速度的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

27 回复

你 defer 是不是在循环中 或者异步的,贴代码吧

更多关于Golang Go语言中明明关闭了 udp 连接,但 netstat 显示连接越来越多,偶尔会减一个,但减小的速度远远慢于增加的速度的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


udp 哪儿来的连接!

你看了 netstat 后面的连接状态了么?

linux 内核有个连接回收间隔时间的设置 调整下试试

http 是基于 tcp 的,你最后一段话是说的与 http 程序的连接不断? tcp 连接即使由一端关闭也不会马上释放,udp 貌似一样的

状态是 established

连接 udp 专门写了个函数,这个函数在 http.HandleFunc("/api/xxx", func (w http.ResponseWriter, r *http.Request){
调用了连接 udp 的函数
})

#3 udp 没有状态的

你还能看到状态,你确定你的情况是 udp 链接越来越多?

udp 服务那边没关闭,可能就是这个原因,我怀疑过,但加了关闭连接以后,好像是关得太快,客户端那边收不到回复了

udp 连接和 tcp 粘包更配哦

我刚才又试了一下 go 一个线程 sleep 一下再关掉连接,发现直接客户端收不到数据了,仔细一看代码,udp 服务端只有一个句柄,调的 Readfrom 函数,所以不能关

我加了图,netstat 命令输出有 udp

你说的具体怎么调整

udp 从协议设计上就只有超时没有关闭

我看了 golang UDPConn.Close 方法的源码,是 close 了一个文件描述符,对比 BSD socket 的 UDP 客户端,也有一个 fd 需要关闭

你贴一下代码吧,怎么建立连接,怎么关闭的

没有回包的接口,Send 完就 close,兜底 Settimeout 就好了
有回包的,收到就 close,然后记得发的时候加 cookie

提供 http 服务的那个程序,是不是从 udp 读取数据啊?如果没有设置超时时间,而服务端又没有返回,或者数据丢了,都会导致客户端一直等待的哦。最好把你连接 udp 的函数贴一下

解决了,是 Read 前没有调 SetReadDeadline

我比较好奇你这是什么神仙 netstat 能给一个本机 udp 出 established 的状态

业务程序也用 ListenUDP 就行了,用 DialUDP 确实会有连接

Dial 之后的连接不是 UDP 协议概念上的连接,而是代码实现上的,connected UDP socket

在 Go 语言中使用 UDP 时,遇到即使关闭了连接但 netstat 显示连接数仍在增加的问题,通常不是由于 UDP 连接的“关闭”机制导致的,因为 UDP 本身是一个无连接的协议,它不维护像 TCP 那样的持久连接状态。

UDP 的“连接”在 Go 中通常表现为一个绑定了本地和远程地址的 socket,当你调用如 net.DialUDPnet.ListenUDP 后,会创建一个这样的 socket。即使你调用了 Close 方法,也只是关闭了该 socket 的文件描述符,释放了系统资源,但网络层面上的 UDP 数据包仍然可以发送到之前使用的端口(除非端口被操作系统回收)。

netstat 显示的“连接”增加,可能实际上是正在接收或等待接收的 UDP 数据包的数量在增加,这可能是因为:

  1. 你的应用可能没有足够快地读取 UDP 数据包,导致数据包在接收缓冲区中积压。
  2. 网络上有大量 UDP 数据包发送到你的应用。
  3. 防火墙或网络设备的配置可能导致数据包被错误地计数或处理。

为了解决这个问题,你可以:

  • 确保应用足够快地读取和处理 UDP 数据包。
  • 使用更高效的并发模型来处理 UDP 数据包。
  • 检查网络设备或防火墙的配置,确保它们不会干扰 UDP 数据包的正常处理。

希望这些建议能帮助你解决问题。

回到顶部