写点什么

TCP 连接的 99 号和 110 号错误

  • 2019-11-25
  • 本文字数:2566 字

    阅读完需:约 8 分钟

TCP连接的99号和110号错误

当客户端频繁的采用短链接时候,经常会遇到[110][connection time out]和[99][could not assigned requested address]的错误。以下是对两种错误的分析以及优化建议,希望对大家有所帮助。

短链接常见的两种错误

当客户端频繁的采用短链接时候,经常会遇到[110][connection time out]和[99][could not assigned requested address]的错误。前段时间我们的存储服务就遇到了这样的一拨报警,经过调研分析,基本确定以上这两个错误与客户端端口的 TIME-WAIT 状态以及服务端的 listen 队列有关(当然也有其它可能的原因,这里只分析这两种)。


从客户端来看,在我们的应用场景中,因为频繁的使用端连接,而且在同一台机上的客户端的数量比较多,造成了大量的 TIME-WAIT 状态的端口,当 TIME-WAIT 状态端口的数量铺满了整个 port_range(由 ip_local_port_range 内核参数指定)范围后,就会产生 99 号错误;从服务端来看,因为频繁大量的 accept 短链接,到达一定量后,服务端口的 listen 队列会出现溢出,这个时候,新的连接请求会被丢弃,连接建立失败,客户端也就产生了 110 号错误。

两种错误产生的原因

[99][could not assigned requested address]

TIME-WAIT 状态是连接一端主动关闭并发送完最后一个 ACK 之后所处的状态,这个状态一般会存在 2MSL(Max Segment Lifttime,即一个包在传输过程中的最大生存时间)时间(所以又叫 2MSL 状态),之所以要有这个状态,是为了让前一个连接的包不影响后面的链接,并且可以被有效的应答,以保证 TCP 连接的可靠性。


为了避免混淆在 TIME-WAIT 状态连接上的处理的包是前一个连接迟到的包还是新连接的包,TCP 协议规定在整个 TIME-WAIT 状态下,不能再建立同样的连接(即四元组一样的连接,但是可以利用处于 TIME-WAIT 的端口建立四元组不一样的连接)Linux 的 TCP/IP 协议栈在判断一个处于 TIME-WAIT 状态的本地端口是否可以作为一个新连接的本地绑定端口时,需要对这个端口做一个是否可用的的判断(在四员组符合之后)。


下面是 linux.2.6.32.70 内核中这一部分逻辑的代码片段



在上面的逻辑中返回 1 表示可以用,返回 0 表示不可用,不可用后报的错是"EADDRNOTAVAIL", 也就是“[99][could not assigned requested address]”。从上面的代码逻辑中可以看出,当 tcp_tw_resuse 对能否重用处于 TIME-WAIT 状态的端口至关重要


1.若 tcp_tw_resuse 未打开,且没有空闲的窗口使用时,则会报“[99][could not assigned requested address]”的错误


2.若 tcp_tw_reuse 打开了,且处于 TIME_WAIT 状态端口的连续两次连接使用间隔要小于等于 1 秒,也会报“[99][could not assigned requested address]”的错误


验证:1 的情况好理解,现在验证 2 的情况,这也是我们线上的客户端的情况,设定系统的 port_range 只有一个元素


$cat "net.ipv4.ip_local_port_range = 1024 1024" >> /etc/sysctl.conf && sysctl -p
复制代码


然后客户端果然返回"[99][could not assigned requested address]"错误,验证成功。

[110][connection time out]

Linux 的服务端从 listen 的端口建立的连接要经过两个队列的过渡,分别是 SYN 队列和 ACCEPT 队列。服务端接受到 SYN 请求后,会发送 SYNACK,并把这个 request sock 存在 SYN 队列内;等到三次握手完成后,再存放到 ACCEPT 队列内;然后再由 accept 系统调用,从 ACCEPT 队列内拿出,交给用户使用。


SYN 队列和 ACCEPT 队列都是有长度限制的,这个长度限制与以下三个参数有关:


a. 调用 listen 接口,传递给 back_log 参数;


b. 内核参数 somaxconn; //与 ACCEPT 队列相关


c.内核参数 tcp_max_syn_backlog; //与 SYN 队列相关


我们线上的问题主要是 ACCEPT 队列出现溢出造成的,所以这里主要分析 ACCEPT 队列长度限制的情况 。


在调用 listen 接口的时候,内核会用系统的 somaxconn 参数去截断传递给 listen 的 back_log 参数。下面是 linux2.6.32-70 的相关代码片段



上面的 sk_max_ack_backlog 就是 listen 端口的 ACCEPT 队列的最大长度


当短链接的量太大,accept 系统调用接口处理来不及时,ACCEPT 队列就可能会阻塞溢出,这个时候,Linux 的 TCP/IP 协议栈的做法是把新来的 SYN 请求丢弃掉( Accept backlog is full. If we have already queued enough of warm entries in syn queue, drop request. It is better than clogging syn queue with openreqs with exponentially increasing timeout.),这样当客户端设定的连接超时不够发送第二次 SYN 请求时,就会收不到服务端 ack,连接建立失败,这个时候报的错误是 ETIMEDOUT,也就是“[110][connection time out]“。


下面是 linux.2.6.32-70 的相关代码片段



在上面的代码段中,sk_acceptq_is_full(sk)是判断 ACCEPT 队列是否满了(队列长度限制已经在 listen 系统调用中被截断了,这也是为什么我们修改内核 somaxconn 内核参数,对当前应用程序的已经 listen 的端口的 ACCEPT 队列长度限制不产生影响的原因,需要重起,才能够使用新的内核参数),如果满了,而且 SYN 队列中又有新的没有完成握手的连接请求,则丢弃当前这个链接请求,这个时候的如果客户端设置的链接超时只够它发送一次 SYN 请求,则链接失败,发生“[110][connection time out]“报错。


验证:


1.按照线上情况,设置 somaxconn 为 128,listen 接口的 back_log 为 8192 运行一定数量的客户端,频繁的向服务端建立 TCP 链接,然后释放,观察情况 。


2.设置 somaxconn 为 8192, 同时设置 listen 的接口的 back_log 参数也为 8192,重复 1 的步骤。



上面是单个客户端的代码逻辑,很简单。

somaxconn 为 128

客户端大量报错



服务端



从上面的结果可以看出,被丢弃的 SYNs 在不断的增加

somaxconn 为 8192

客户端没有报错


服务端



可以看出,这段时间内没有被丢弃的 SYNs

总结

验证的结果和内核代码以及我们的预想是吻合的

解决办法

1.提高客户端的链接超时限制。当前是 300ms,比如可以提升到 3s 等;


2.提高服务端的 somaxconn 限制,这是个指标不治本的方法,只能是一定程度的缓解。(修改内核的其他的网络参数也是一样,只能是缓解,并不能解决根本问题)。


3.在客户端使用连接缓冲池,将短链接转换成长链接来使用(个人认为这个才是更好的办法,一劳永逸)。


本文转载自公众号 360 云计算(ID:hulktalk)。


原文链接:


https://mp.weixin.qq.com/s/umQTPgYC7UVtOGCbVjRnyA


2019-11-25 10:451427

评论

发布
暂无评论
发现更多内容

架构师训练营第 1 期 - 第九周作业

Todd-Lee

极客大学架构师训练营

接口测试之json中的key获取

测试人生路

接口测试

算法讲解|贪心算法的理解与分析

Java架构师迁哥

2021年Java程序员请先把这几项硬技能熟悉掌握,再想着跳槽拿高薪

Java架构之路

Java 编程 程序员 架构 面试

MySQL 连接为什么挂死了?

Java架构师迁哥

LeetCode 热题 - 递归

helbing

LeetCode

第五周 - 作业

leo

极客大学架构师训练营

网络冲浪信任危机频发,区块链能否破局?

CECBC

区块链 征信透明

阿里内部“新鲜出炉”手慢无!首发面试终极指南V3.0,符合一线大厂面试知识点+面试题

Java架构追梦

Java 阿里巴巴 架构 面试 分布式

Spring Cloud Config 实现分布式配置中心

AI乔治

Java 架构 微服务 Spring Cloud

《ZooKeeper分布式过程协同技术详解》.pdf

田维常

电子书

接口的幂等性的多重考虑,你会了吗?

moon聊技术

Java 接口

4年Java开发经验,从传统公司裸辞之后足足准备了3个月,终于拿到美团、京东、字节跳动等大厂offer

Java架构之路

Java 程序员 架构 面试 编程语言

并发编程Bug的源头-原子性

996小迁

Java 程序员 架构 面试 并发编程

消灭微服务的坏味道 之 循环依赖

码猿外

微服务 循环依赖 坏味道

架构师系列之6: python实现一致性hash

桃花原记

架构师训练营第 1 期 - 第九周总结

Todd-Lee

极客大学架构师训练营

MyBatis 面试题(附答案解析)

比伯

Java 大数据 编程 架构 面试

区块链的新信任模式将重塑传统金融业

CECBC

区块链 资产流动性

奉劝各位准备面试的Java程序员耗子尾汁,赶紧扔掉网上那些千篇一律的面试题

Java架构之路

Java 程序员 架构 面试 编程语言

五、一致性哈希算法

Geek_28b526

给,你们想要的内存溢出MAT排查工具

田维常

内存溢出

看“区块链”如何为外贸企业融资

CECBC

区块链 银行

架构师训练营第 1 期第 9 周作业

好吃不贵

极客大学架构师训练营

一张图片一份文档,我想redis就到这里吧,剩下的只有实践了

小Q

Java redis 学习 编程 面试

用 Python 实现定时自动化收取蚂蚁森林能量

Python小二

Python

第五周-笔记

leo

极客大学架构师训练营

React 灵魂 23 问

局外人

Java 大前端 React

Redis 分布式锁原理看这篇就够了, 循循渐进

马丁玩编程

redis 架构 分布式 分布式锁

Nacos实战及其源码分析

Fox666

Spring Cloud nacos spring cloud alibaba

《使用C ++的数据结构和程序设计》限时免费下载

计算机与AI

c++

TCP连接的99号和110号错误_文化 & 方法_吴晓飞_InfoQ精选文章