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

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

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

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

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

调用与被调用的容器间的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), 进一步分析发现属于典型的丢包现象。具体分析细节见图注说明。

客户端抓包分析：

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

再加上客户端容器、服务端容器主要在跨宿主机网段的的机器上，这些特点符合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是一种在单个TCP连接上提供全双工通信的协议，它允许在客户端和服务器之间进行实时、双向的数据传输。WebSocket通讯的优点很多，以下重点提2个：

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

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

相关日志

00:54:34:463|||WatcherWebSocketListener.java:66|onClose||43||||WebSocket close received. code: 1000, reason: k8s.log:APPLICATION|DEBUG|||2023-05-19 00:54:35:468|||WatchConnectionManager.java:60|closeWebSocket||475||||Closingwebsocket io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl@46de5f80 k8s.log:APPLICATION|DEBUG|||2023-05-19 00:54:35:468|||WatchConnectionManager.java:63|closeWebSocket||475||||Websocket already closed io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl@46de5f80 k8s.log:APPLICATION|DEBUG|||2023-05-19 01:52:47:876|||WatcherWebSocketListener.java:66|onClose||43||||WebSocket close received. code: 1000, reason: k8s.log:APPLICATION|DEBUG|||2023-05-19 01:52:48:880|||WatchConnectionManager.java:60|closeWebSocket||487||||Closingwebsocket io.fabric8.kubernetes.client.okhttp.OkHttpWebSocketImpl@7de2a21a k8s.log:APPLICATION|DEBUG|||2023-05-19 01:52:48:880|||WatchConnectionManager.java:63|closeWebSocket||487||||Websocket already closed ...(略） ...

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

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

特别强调一下，为了最大程度地不影响线上环境，只抓少量的包，且只抓建链、断链的包，即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，由此可以明确知道问题该从服务端查起。

如果不解析包，会是什么情况？可以看到全部是加密的数据，不是太好分析，举例

- 从k8s master源码分析

从k8s master源码分析，发现k8s master有个配置项，RequestTimeout，基本上从来没有用。限于篇幅，略去中间的摸索过程，见代码如下

- 定位原因-版本差异

通过辛苦的版本比对及调试验证，最后找到是k8s高版本做了超时的修复，具体来说是k8s 1.15.0-alpha1，直接上个图：

由此可以看出，从1.15.0-alpha1版本开始，都是这样子的。后经与研发一起讨论，认为这个断链是正常的，不会有实质性的影响。

【要点】