几个容器网络问题实战解析

容器云平台和容器网络紧密结合，共同构建了容器化应用程序的网络基础设施，实现了容器之间的通信、隔离和安全性。文中容器云平台采用的容器网络组件是calico，这个是业界普遍采用的一种方案，性能及安全性在同类产品中都是比较好的。本篇就笔者在近期项目上所涉及的几个容器网络问题，依据真实案例，分享如何通过网络抓包进行问题的解析与处理。

实战一、因基础网络层MTU不一致引发的应用访问偶发性超时

MTU，即Maximum Transmission Unit（最大传输单元），此值设定TCP/IP协议传输数据报时的最大传输单元，单位字节。传统的网络模式下，如果此值设置得太小，网络性能会受影响；如果设置得太大可能触发“部分网站打不开”等问题。

在容器环境下，容器网络借助于IAAS层网络传输来达到分布式服务间的网络通讯。容器环境下的典型特征是：服务都是多实例的、分布式的、跨网段的、跨多网络区域、甚至跨VPC的。再加上容器网络本身也是一层虚拟化，特别是在overlay模式下，会额外嵌入一层协议，更增加了容器网络问题分析的复杂性。特别是当IAAS较复杂的组网模式时，如果MTU不合理，可能导致以下问题：

大包阻塞（Jumbo Frames）：如果不同网段的设备或路由器的MTU设置不一致，可能会导致大于某个网络段MTU的数据包无法通过。这可能导致大包阻塞，因为在路径上的某个点上，数据包将被分片或被丢弃。
丢包：当数据包在跨越网络段时被分片，而某个网络段无法容纳整个分片时，会导致分片的丢失。这可能会引起通信中的丢包情况，降低网络性能。
性能下降：分片和重组数据包会增加网络设备的负担，可能导致性能下降。特别是在高负载情况下，这可能会对容器间的通信产生显著的影响。

问题背景

某项目前端页面上出现个别菜单偶发性超时，但是如果重新点击又正常了。这种现象出现多次，且近期出现的次数更加明显。

应用的通讯架构可以抽象为如下：

问题表现

前端页面上出现个别菜单偶发性超时

在前端浏览器上F12调试-504

从调用链测发现调用有失败

平台的调用链引擎是pinpoint，业界很多厂商也是基于此技术栈实现分布式应用的调用拓扑、调用性能的分析。我们从调用链上可以看到前端与后端的请求中，有少数请求是超时的，可以明确看到Socket("message:"Read timeout..")的网络接收数据超时。从这里可以初步感受到问题是出在网络通讯上。

调用与被调用的容器间的ping包都是正常的；做一些简单的curl也是正常的。

由于从调用链上能够得到的信息是出在网络上，而在容器环境下业务间的通讯是容器网络，于是首先从最基本的检查做起，理清前端、后端间的相关容器的节点分布情况，写脚本探测容器之间的网络稳定性，看看是不是会出现网络抖动或ping丢包。

最基本检查可以通过ping脚本来评估网络的稳定性，选取不同的节点上调度的容器，分别在前、后端容器内执行长时间的ping探测，并收集ping结果进行分析，脚本如下：

#长ping脚本，带时间戳,可以直接塞入相关被探测的容器中 #!/bin/bash for i in 100.80.95.XX 100.80.174.YY 100.80.90.ZZ 100.80.76.MM ... ;do ping $i | awk '{ print $0"\t" strftime("%Y-%m-%d %H:%M:%S",systime()); fflush()}' >> ./PingpodTopod.log & done

经过几个小时的探测（确保这个期间业务有偶发性超时问题发生），从ping的结果上来分析，所有ping的req包都有回包，没有丢包，且延时都非常低，从这里至少可以说明网络链路层是没有问题的。

那进一步做tcp层通讯的基本检查，从业务侧获取一些涉及tcp通讯且不会对生产环境产生任何影响的接口调用，在前端容器内对后端容器实行实施多次curl调用检查，从多对容器以及多次的抓取中可以看到所有的curl都是能够快速应答，且没有超时发生。

从最基本的链路层检测及tcp通讯的检测上来看，容器网络没有明显的问题。那么问题会出现在哪里？接下来对相关容器实施网络抓包，从网络包上看看能不能发现端倪。

容器网络抓包分析

限于篇幅，长言短叙，随便挑一对发生问题的异常容器，然后实施抓包分析。服务端抓包可以采取最常见的基于ip与port的过滤器来抓网络包。特别注意要分别在服务端与客户端进行抓包，好处是可以基于时间点及sequence来相互印证，找出有问题的包，然后对比分析，重点查看发出去的包有没有到达对端，对端的回包自己有没有收到、有没有重传等等，从异常中找出问题的线索。

在下图中：服务端容器100.80.95.126 、客户端容器100.80.174.53，可以很明显地看到在问题发生的时间点有多次重传(TCP Retransmission), 进一步分析发现属于典型的丢包现象。具体分析细节见图注说明。

客户端抓包分析：

从客户端与服务端抓包的多个包的对比中，得出以下结论

客户端、服务端正常建链，客户端正常发送请求
服务端收到客户端请求后，客户端未收到服务端的回包
未收到的回包属于大包，大包（长度 >=6000 或者7000的包，服务端发了，但是客户端收不到）
再加上客户端容器、服务端容器主要在跨宿主机网段的的机器上，这些特点符合MTU的问题，因此，下一步调整MTU。一般来说，应该要检查一下IAAS层的网络设备的MTU的配置，但是IAAS资源都是局方的，而且也分属于不同部门，协调起来比较困难。因此，考虑在容器侧调整MTU，在经过客户的允许后，在夜晚调小了线上环境的容器网络的MTU，问题解决。

再次抓包，可以看到大的数据包也都可以正常传输了，见下图：

从调用链上反馈也是正常的啦。

结论

通过分析收发包的特点，找出异常数据包的发送情况，主要特征是：多发生在跨网段间的主机上，核心是小包能正常通讯，大包通讯上有问题，大包无法到达对端，典型的MTU配置不当的表现。

知道问题的原因了，那么解决问题的办法就很简单了，可以直接调小一点容器层面的MTU，从而可以规避此问题。

实战二、基于协议回包特点反推服务端的逻辑问题

在容器场景下，不仅要在容器平面进行MESH方式的通讯，常常容器还需要与外部通讯，甚至与第3方的厂家进行业务交互，困难点在于你无法清晰知道第3方服务的逻辑、也无法登录第3方环境，无法知道网络架构、网络安全配置等。这样的背景下，当业务出现异常且排除自己业务代码的问题层面之后，那么可借助网络抓包来进行分析，通过解析数据的的交互同时比对正常情况下的TCP流与异常情况下的TCP流的差异、同时基于业务采用具体业务协议下本来应该是个什么样的，从而来发现问题。

这种问题本质上不是网络问题，网络层面的通讯都是正常的，是业务逻辑上有潜在的问题，比如业务代码条件判断不够精确，误判走了不同的流程，回传了不需要的数据包。

问题背景

某项目上线期间发现API发起VC充值业务( CGMMLClient调用第三方的的MML接口 QUERY VC INFO)偶发性异常。相关业务日志

APPLICATION|ERROR|192.168.12.243|20|2022-12-15 
12:39:38:971||70802003|ConnectorCacheHandler.java:86|postHandle|7083012|245|||Message is timeout, and handled. message [beginTime=2022-12-15 
12:39:23.969,timeout=15000,interval=15002 : server channel=[1], channel=[/192.168.12.243:58034], channel=[/10.16.76.5:8124] adapter=[SocketClient-MML],sequence=[SocketClient-00018915], status=[REMOTING_TIMEOUT], lastHandlingObject=[com.ztesoft.zsmart.cg.service.binder.ServiceBindingRuleIntrp@2c881e0], command=[QUERY VC INFO] field list: {"OPTYPE":"1","transId":"000024f3","totalLen":{"_endPos_":8,"_value_":"0068","_startPos_":4},"sessionId":"00000000","terminal":"CCB00000","serviceName":"PPSPHS","version":"1.00","msgBeginFlag":"`SC`","transRemain":"FFFF","checkSum":"AA8A9495","COMMAND":"QUERY VC INFO","transControl":"TXBEG ","Body":
{"_endPos_":112,"_startPos_":8},"sessionControl":"DLGCON","CARDNO":"516683732197360540","sessionRemain":"FFFF"} variable list: {"protocol":"MML","reomoteHost":"10.16.76.5","cg":"SocketClient-MML","resultCode":"REMOTING_TIMEOUT","__cost__":0,"command":"QUERY VC INFO","status":"REMOTING_TIMEOUT"} param list: {"arg0":{"opType":1,"class":"com.ztesoft.zsmart.bss.payment.orange.smartfren.bc.service.mml.QueryVcCardRequest","cardNumber":"516683732197360540"}} buffer=[。。。。。。] ]

抓包分析-通过对比正常号码充值与异常号码充值的网络包

既然是偶发性异常，那么一定是存在正常的业务流程与异常的业务流程；接下来大的思路就是对比正常业务流程下的业务收/发包与异常流程下收/发包，然后比较差异。

首先重点从业务日志中找出关键的数据包中必传输的关键字信息，比如本例中充值号码："cardNumber":"516683732197360540"。

容器内抓包

容器内基于IP与port端口进行抓包，首先针对异常号码充值包分析，在业务容器内进行抓包，同时从业务侧获取问题发生期间的充值异常的号码，例如：CARDNO":"516683732197360540 ，基于此号码分析网络包。

现在的wireshark功能比较强大，可以通过match添加过滤条件，从TCP包中找出异常号码"cardNumber":"516683732197360540"对应的通讯链路，然后再逐一分析这个TCP流。

另外，取正常号码充值包分析，比如正常的号码 CRD 160588272651221

从比对中发现问题-第3方的服务端

从包中比对

包的主要特点:

1）长链接；

2）整个网络流比较正常，第一次抓取的包，是在一个容器内做的；10万个包中真正发生重传的次数也就10来次，比率相当低的；且重传后都能得到及时响应，不存在网络丢包；

3）问题触发时，并不发生在包的重传上；

4）整个单纯的TCP层面的通讯上没有明显问题；

5）根据apig发包以及服务端的回应来看，收到的不是预想的包-这是重点。

从比对中发现，每次发生异常时，apig 正常发送了vc query请求包，没有收到vc qeury的应答包；而正常的充值的号码都是收到了应答包。因此服务端存在偶发性的回包问题，而服务端是局方管理的第3方公司提供的；之后经由与局方面对面沟通，同时比照务端业务日志的查看，问题确实在第3方公司的服务端。后经第3方公司核查完自己的服务端代码，发现一处条件的判断逻辑有问题，后经处理完服务端，该问题得到解决。

[要点] 分别找出正常充值时的TCP数据流与异常充值时的数据流，通过对比正常充值与异常充值的数据包，从而发现差异、介定异常。

实战三、websocket协议断链-大量断链包中发现规律+源码求证

WebSocket是一种在单个TCP连接上提供全双工通信的协议，它允许在客户端和服务器之间进行实时、双向的数据传输。WebSocket通讯的优点很多，以下重点提2个：

全双工通信：WebSocket允许双向通信，客户端和服务器可以同时发送和接收数据。这使得实时性应用程序的开发更为简便，例如在线聊天、实时协作和实时更新的Web应用程序。
持久连接：WebSocket连接是持久的，一旦建立连接，它可以保持打开状态，允许任何时候双方都能发送数据。这降低了频繁建立和断开连接相关的开销。

简单地说，基于websocket协议通讯的业务，都倾向于长时通讯，一般情况下不会去主动断开；如果项目上碰到websocket通讯有频发断链的情况，要引起注意，请明确这属于逻辑上设置的主动断链，还是异常断链；特别是在不了解背后实现逻辑的情况下，可以通过抓包，重点抓取3次握手与4次握手，来发现断链的规律、由谁发起的、属于主动断链、还是丢包导致的锻炼，有条件的要将抓包与源码进行比对分析，从而解决问题。

问题背景

业务网关与k8s APIServer之间websocket有多次的断链，按以往经验来看，之前没有发生过断链，都是长链接。项目上关于多次断链有点担心，怕存在隐患。

问题表现

抓包分析

由于是线上环境，首先要考虑的是对线上业务的影响。从日志中评估出每小时发生的概率不高，因此，可以实施抓包。

- 初步抓握手包-观察断链及规律

特别强调一下，为了最大程度地不影响线上环境，只抓少量的包，且只抓建链、断链的包，即3次握手、4次握手。此次抓包不同于前面的直接基于IP与端口抓包，会加一些稍显复杂的过滤条件，尽可能减少线上环境的影响，只抓1000个包，只在网关节点上抓包

sudo nohuptcpdump -i eth0 host XXX and port 6443 and \('tcp[tcpflags] == tcp-rst' 
or'tcp[tcpflags] == tcp-syn' or 'tcp[tcpflags] == tcp-fin' or 'tcp[13] & 1 != 0'\)-
c 1000 -nn -vv -w ./host195-2-socket-esta-or-close-01.pcap &

基于抓包文件分析-取片段：

在实际的分析中是取了多个片段进行分析的，总体发现一个规律

1）服务端发起的断链

2）每个链接保持时长都在 (30分钟 60分钟）这个区间内，这一点很重要，这为我们后面在规定时间内抓取数据包提供很大的价值。

- 进一步抓数据包

为了不影响生产环境，在同版本的测试环境上进行同样方式抓包，同样具有此特点，后续就直接转到测试环境上进行分析...

按前面的规律，半小时至1小时内必然发生断链，因此，考虑抓取数据包。由于websocket是基于TLS的通讯，为了探索出到底是什么数据带来的影响，更进一步的措施做TLS数据包的解析。方便解包，仿照网关逻辑，写了一个golang的websocket测试程序，在测试环境上进行多轮测试。从抓包及websocket TLS解包中来看，是服务端正常的断开，服务发送了一个TLS Aller_message 21，解包中得出是 Close_notify，由此可以明确知道问题该从服务端查起。