容器云平台和容器网络紧密结合，共同构建了容器化应用程序的网络基础设施，实现了容器之间的通信、隔离和安全性。文中容器云平台采用的容器网络组件是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有多次的断链，按以往经验来看，之前没有发生过断链，都是长链接。项目上关于多次断链有点担心，怕存在隐患。
相关日志
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版本开始，都是这样子的。后经与研发一起讨论，认为这个断链是正常的，不会有实质性的影响。
【要点】
从抓包中确认有websocket 断链发生，且是服务端发起的抓取足够量的建链、断链，发现规律每(30分钟、60分钟）发生一次断链通过以上2点确认排查方向是从k8s master服务端做起结合TLS解包，确认这个断链是TLS 21 消息，属于正常的断链包，排除了网络层面的影响结合k8s master的启动项及源码发现高版本的源码中就是这样的设计逻辑源代码层面，通过比对低版本与高版本的websocket处的实现，发现从1.15.0-alpha1版本开始，代码实现上加入了超时断开的功能经过反复测试，断链的问题清楚，不用担心，可以忽略，属于正常机制