我是靠谱客的博主 安详百合,最近开发中收集的这篇文章主要介绍TCP丢包解决一、引言二、丢包原因-操作系统层面三、丢包解决-操作系统层面四、丢包解决-服务层面五、总结,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

一、引言

        接上篇TCP丢包排查_tingmailang的博客-CSDN博客,丢包的排查确认在环境、网络链路层,对于后续的排查以及解决方案博主全程跟踪,这里再分享下。

二、丢包原因-操作系统层面

        上篇文章定位到tcp握手偶发丢包,运维联系了阿里云人员排查丢包是否和云平台有关,阿里云进行了系统监控,发现的确是有不少丢包现象。

                                              

        阿里云说明在kernel-4.19.91-25.1.al7及之前的内核版本上,当应用程序同时发起多条TCP连接请求时,大量TCP报文经过NAT表并有概率获取到重复的端口。Conntrack模块在确认阶段发现端口存在重复的情况,丢弃了相关的TCP报文。

        iptables防火墙可以用于创建过滤(filter)与NAT规则,所有Linux发行版都能使用iptables。所以获取到NAT的重复端口的linux的机制决定的。

        有的同学可能有疑问,k8s不是隔离的吗,怎么会出现端口重复使用?实际上如果一个物理机一个k8s容器,那的确是隔离的,但这样也失去了k8s的意义:隔离内存磁盘等物理机上容易相互干扰的资源,干脆一个物理机一个服务算了。

        生产环境基本上一个物理机会有十几个服务,而内核cpu、网络端口这些实际上是被k8s容器中的服务共用的。

 

总结一下当前微服务环境下的请求发送过程:

        ①x服务发出请求,通过iptables的NAT表对(数据包的)网络地址(IP + Port)进行转换,获取端口

        ②端口发送tcp握手包,Linux的Conntrack模块自检确认(包会经过 nf_conntrack_in() 、 nf_conntrack_confirm() 进行创建(new)和确认(confirm)两个阶段 

        ③请求到达服务网格1

        ④服务网格通过iptables的NAT表对(数据包的)网络地址(IP + Port)进行转换,获取端口,建立tcp链接

        ⑤网格发送tcp握手包,Linux的Conntrack模块自检确认(包会经过 nf_conntrack_in() 、 nf_conntrack_confirm() 进行创建(new)和确认(confirm)两个阶段 

        ⑥服务端操作系统收到握手请求包,通过iptables的NAT表获取端口,使用该端口与客户端网格建立tcp链接

        ⑦网格1转发数据给网格2

        ⑧服务网格2接收请求数据,转发给y服务处理

 这里可以看出这一次的问题就在第二、五,获取端口重复,linux自检确认的时候就会直接丢弃这个数据包,握手超时,tcp再次发起握手。

三、丢包解决-操作系统层面

         根据阿里云的描述4.19的时候是顺序获取,所以比较频繁,使用yum升级到5.x以上,5.X的内核是随机获取,出现端口重复的频率比较低。

        这种解决方式是概率性的,重复端口丢包的风险依然存在,只是频率会下降,不过阿里云做了其他优化,在端口重复丢包的时候会立刻通知tcp重传,这样延时就降低到了ms级别。

四、丢包解决-服务层面

        虽然说丢包是操作系统与网络层面的问题,但是服务层面也不是没有优化解决的办法,或许不能称之为解决,和操作系统的升级一样,只是尽量降低丢包频率。

        根据上一篇文章定位到的,丢包基本是第一次握手发生,那么是否可以尽量避免tcp新建链接,多多复用呢?

        还是有这种办法的,服务使用的json序列化是fasterxml.jackson默认的EAGER_DESERIALIZER_FETCH,这种序列化读取响应json的时候最后一个rn有可能不会读取 这样下一次复用连接的时候会发现有脏数据rn关闭连接,并且进行新建tcp链接。

        修改为使用FAIL_ON_TRAILING_TOKENS就可以减少上面这种情况的新建tcp,对于jackson自身的影响是如果是"{json}xxxxx" 这样的字符串 之前是可以反序列的 加了以后会失败,但是在正常的业务场景不会出现这种异常json。

        当然,这种改动并不是直接针对丢包的,主要是想复用tcp,所以效果是有概率的,新建链接是不可避免的,链接不会一直被复用,就看因为网络原因会丢包的时候,是正好复用链接还是新建链接。

五、总结

        最终定位到了tcp握手丢包是阿里云内核容易取到重复端口建立tcp链接,linux自检确认发现重复使用就会丢弃握手数据包。

        解决方案是操作相通升级内核(随机获取替代顺序获取、端口重复丢包的时候会立刻通知tcp重传)、服务使用json配置FAIL_ON_TRAILING_TOKENS(减少新建tcp链接)

最后

以上就是安详百合为你收集整理的TCP丢包解决一、引言二、丢包原因-操作系统层面三、丢包解决-操作系统层面四、丢包解决-服务层面五、总结的全部内容,希望文章能够帮你解决TCP丢包解决一、引言二、丢包原因-操作系统层面三、丢包解决-操作系统层面四、丢包解决-服务层面五、总结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(57)

评论列表共有 0 条评论

立即
投稿
返回
顶部