一、引言
接上篇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的时候最后一个\r\n有可能不会读取 这样下一次复用连接的时候会发现有脏数据\r\n关闭连接，并且进行新建tcp链接。
修改为使用FAIL_ON_TRAILING_TOKENS就可以减少上面这种情况的新建tcp，对于jackson自身的影响是如果是"{json}xxxxx" 这样的字符串 之前是可以反序列的 加了以后会失败，但是在正常的业务场景不会出现这种异常json。
当然，这种改动并不是直接针对丢包的，主要是想复用tcp，所以效果是有概率的，新建链接是不可避免的，链接不会一直被复用，就看因为网络原因会丢包的时候，是正好复用链接还是新建链接。
五、总结
最终定位到了tcp握手丢包是阿里云内核容易取到重复端口建立tcp链接，linux自检确认发现重复使用就会丢弃握手数据包。
解决方案是操作相通升级内核（随机获取替代顺序获取、端口重复丢包的时候会立刻通知tcp重传）、服务使用json配置FAIL_ON_TRAILING_TOKENS（减少新建tcp链接）