k8s pod 抓包 tcpdump结果详解

 

首先安装tcpdump： yum install tcpdump

kubectl get pod -o wide查看pod在哪个节点上

docker ps 查看container的id

查看pid： docker inspect -f {{.State.Pid}} $containerid

pod是宿主机上不同namespace中运行的进程，因此进入network namespace ： nsenter --target $pid -n

用ip a查看网卡信息，例如查看为

 

则网卡为eth0

 

使用tcpdump在8080端口抓包，tcpdump -i eth0 tcp and port 8080 -vvv    |tcpdump -i eth0 tcp and port 8080 -vnn  -XX

 

2. 理解 tcpdump 的输出

2.1 输出内容结构

tcpdump 输出的内容虽然多，却很规律。

这里以我随便抓取的一个 tcp 包为例来看一下

21:26:49.013621 IP 172.20.20.1.15605 > 172.20.20.2.5920: Flags [P.], seq 49:97, ack 106048, win 4723, length 48

从上面的输出来看，可以总结出：

1. 第一列：时分秒毫秒 21:26:49.013621
2. 第二列：网络协议 IP
3. 第三列：发送方的ip地址+端口号，其中172.20.20.1是 ip，而15605 是端口号
4. 第四列：箭头 >， 表示数据流向
5. 第五列：接收方的ip地址+端口号，其中 172.20.20.2 是 ip，而5920 是端口号
6. 第六列：冒号
7. 第七列：数据包内容，包括Flags 标识符，seq 号，ack 号，win 窗口，数据长度 length，其中 [P.] 表示 PUSH 标志位为 1，更多标识符见下面

ack序列号为随机生成，在请求发送时，client的请求会有一个ack序列号，server端响应时，会在seq中以 ack序列号:随机生成的seq序列号来响应 

2.2 Flags 标识符

使用 tcpdump 抓包后，会遇到的 TCP 报文 Flags，有以下几种：

• [S] : SYN（开始连接）
• [P] : PSH（推送数据）
• [F] : FIN （结束连接）
• [R] : RST（重置连接）
• [.] : 没有 Flag （意思是除上面四种类型外的其他情况，有可能是 ACK 也有可能是 URG）

 

三次握手与四次挥手：

 

 

1）-3）是3次握手，8）-10）是4次挥手，但是这里只有三段报文段。原因是，延迟确认，即服务器不会马上确认收到的数据，而是在一段延迟时间后查看本端是否有数据要发送 ，如果有，则和确认信息一起发出。延迟确认可以减少发送tcp报文段的数量。这里的四次挥手中服务器的确认报文和结束报文一次性发送给客户端了。（书上是在局域网内进行的，没有延迟确认）

 比如这样一段在172.44.154.59的80端口抓包的结果：

 可以看到发包时，用的端口并不是80，而是41030，因为发包时会从没有占用的端口中默认找一个端口。而接收包的一方，则需要固定用一个端口接收。我们可以用ss -o命令查看目前存在系统中的连接的源地址和目的地址。一般连接都是长时间建立的，凭借keep-alive时间长时间保持连接的建立。

我们可以通过这个41030来追踪这一次长连接进行的所有报文传输。

图片中，前两个Flags [S]以及第三个 Flags [.]就是三次握手，后两个的Flags [F.]和最后一个Flags [.]就是四次挥手，因为延迟确认，所以四次挥手只有三段报文

 

参考：https://blog.csdn.net/zorsea/article/details/126760314

https://blog.csdn.net/Howl_1/article/details/119046215

https://blog.csdn.net/m0_56649557/article/details/119492899