bind(0)导致的临时端口用尽引发的思考(IP_BIND_ADDRESS_NO_PORT)

tips:本文使用的Linux源码版本为3.10.20,最新的版本已经对本文描述的问题做了优化。

tips:本文不讨论扩大Linux可用端口范围、SO_REUSEADDR、SO_REUSEPORT等优化方法,仅讨论patch:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90c337da1524863838658078ec34241f45d8394d引入的IP_BIND_ADDRESS_NO_PORT选项。

1、临时端口用尽表现出的问题

高并发的情形下,经常出现端口被用尽的情况:bind()返回EADDRNOTAVAIL错误;nginx无法建立新的socket访问上游服务器;本机上运行的其他所有服务不能提供访问等等。

然而理论上来说,虽然Linux最大提供65K个端口,但是一个四元组确定一个唯一的tcp连接,四个元素的组合方式远远大于65K种,不应该如此频繁地出现端口用尽的情况。

2、临时端口用尽的表面原因

一般来说,用户并不关心bind()时选择哪个端口,而更愿意把这项工作交给kernel来完成,即设置为bind(...,...,0)。kernel查找到一个空闲的端口后会进行冲突检查,此时kernel只知道四元组中的src_ip,src_port,只能用这两个元素作为依据去检测冲突。如果没有冲突发生,就把这个socket加入到inet_bind_hashbucket这个哈希表中。一旦代表[本机ip:0~本机ip:65535]的所有socket都通过bind函数插入到了哈希表之后,再有新的bind(0)调用就会失败,无法获取可用的端口。

也就是说,bind()并不是通过五元组区分不同的连接的,所以端口很快就用尽了。

3、bind()和connect()对于连接冲突检测的区别

bind()只使用src_ip和src_port来区分冲突,而connect()用了四元组来区分冲突,所以不会频繁地发生端口耗尽问题。

4、bind(0)和connect()的函数调用链分析

inet_bind()
  L sk_sk_prot->get_port(即inet_csk_get_port)
      L inet_csk(sk)->icsk_of_ops->bind_conflict(即inet_csk_bind_conflict)
          L 作sk_rcv_saddr检查和一些reuse检查,通过后调用inet_bind_hash把sock加入哈希表
tcp_v4_connect()
  L inet_hash_connect()
      L __inet_hash_connect(传入函数指针__inet_check_established)
          L 选中port后调用check_established检查冲突
              L 检查分两步,先查time_wait的连接,再查established的连接,
                检查四元组的宏为INET_TW_MATCH,通过后调用inet_bind_hash把sock加入哈希表

5、Linux维护的网络哈希表

0~65535个端口通过hash算法均匀地分布到一定数量的bucket中,每个端口有一个链表,存储使用这个端口的sock结构体,冲突检查的时候遍历的链表就是这个链表。具体分析见这篇博文:https://blog.csdn.net/dog250/article/details/5303572

发布了166 篇原创文章 · 获赞 8 · 访问量 7万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览