那时刻
2022-01-21要定位两侧的同个报文，还可以依据消息内容，frame contains进行过滤作者回复: 很棒！ 这个方式也很好，通过搜索特定消息内容（比如某个http事务的唯一uuid）的方式，找到两边抓包文件里同一个报文。这个消息越确定越唯一，匹配的范围就越小越精确。 在二层就是用frame contains 在三层就是用ip contains 在四层就是tcp contains 在七层就可能是http contains
共 3 条评论21
江山如画2022-01-21首先根据时间戳大致确认报文范围，再从不同层入手。 数据链路层，使用 mac 地址区分。 网络层，使用源IP，目的IP，IPv4/IPv6版本。 传输层，使用源端口，目的端口，协议类型，裸序列号，裸确认号，校验和。 会话层和表示层，比如 TLS，可以先用 Content Type 字段区分报文类型，比如是握手报文还是数据传输的报文。如果是握手阶段的报文，可以用 sessionID 区分，如果是正式的数据传输报文，可以用 Encrypted Application Data 区分。 应用层，使用 URL 区分，数据没有加密使用内容区分。作者回复: 差不多，很全面了，给你点赞！ 你也可以参考另外一个同学的回答，就是在数据链路层，用frame contains "xxx"这个wireshark过滤器，在两个文件中找到同样的报文。当然前提是这个"xxx"应该足够唯一，否则是多个的话，得结合其他信息（比如ip，端口号，序列号等等）来综合判断。 一般来说，我个人用的比较多的就是两种： 1. 用裸序列号（也叫原始序列号） 2. 用应用载荷数据，比如frame contains, ip contains, tcp contains, http contains都可以
共 3 条评论14
志强2022-01-21但从经验上看，乱序几率大概在百分之一以下到千分之一左右都属正常 ----请问老师 问题中的乱序是多少呢？ 这个百分比是谁除以谁得到的呢？作者回复: 就是指乱序报文的数量。比如有一个抓包文件里有1万个报文，其中10个是乱序报文（wireshark会提示的，在专家信息里可以看到），那么就是千分之一，是支持范围内，或者说不会明显影响到传输。 你可以这样得到百分比： 1. 计算全部报文数量：capinfos file.pcap | grep packets 2. 计算乱序报文数量：tshark -n -q -r file.pcap -z "io,stat,0,tcp.analysis.out_of_order" 3. 两者相除，或者肉眼也能看出来比例大概在什么数量级了
共 2 条评论5
怀朔2022-01-25如果可以 希望老板把cap包发一下 大家一起分析看看作者回复: 嗯这个在计划中的，后续陆续对抓包文件做数据脱敏，然后整理出来，放到gitee上方便大家的学习
共 2 条评论3
includestdio.h2022-01-21老师留的思考题没啥头绪，我就大概按照我的理解总结下本篇的知识点吧 - - 排查原则： “两端抓包”，听完“A”的抱怨，也该问问“B”的解释，这样才公平 注意事项： 1.各端的抓包过滤条件一般以对端 IP 作为条件 2.两端的抓包应该差不多在同时开始和结束 3.边重现，边抓包（确保问题出现，再停止抓包） 排查步骤： 1.查看 expert information； 2.重点关注可疑报文（比如 Warining 级别），追踪其整个 TCP 流【TCP流追踪方法：Follow -> TCP Stream】； 3.深入分析这个可疑 TCP 流的第二到四层的报文，再结合应用层表象，综合分析其根因； 4.结合两侧的抓包文件，找到属于同一个 TCP 流的数据包，对比分析，得出结论【通过TCP裸序号，找到对端同个TCP流】； 另外有个小建议，老师后续能不能在下篇专栏内容开头公布下思考题答案作者回复: 你的总结太好了，学习委员就是你了：） 这个排查分析的思路虽然不包含具体的操作，但对我的排查工作的开展非常有指导意义，希望对你也有帮助
2
我为什么这么菜2022-05-09老师，根据上面的乱序报文，它对应的 ACK 是否是这样的： 1. 客户端收到 [包4]，回复 ACK5 2. 客户端收到 [包1]，回复 ACK2 3. 客户端收到 [包2]，回复 ACK3 4. 客户端收到 [包3]，回复 ACK4 因为这几次 ACK 的值都不一样，所以不会引起快速重传。 但如果是下面这种乱序，应该就会引发快速重传吧？ 1. 客户端收到 [包1]，回复 ACK2 2. 客户端收到 [包3]，回复 ACK2 3. 客户端收到 [包4]，回复 ACK2 这时候服务端连续收到 3 个 ACK2，就会引发快速重传吧？作者回复: 一方收到3个DupAck会启动快速重传，注意是3个DupAck，而加上原始Ack就是4个同确认号的Ack了，比你这里说的多一个：）
1
星星云2022-05-07服务端经过了haproxy和nginx，还能这样抓包吗作者回复: 经过了LB（包括这里的haproxy和nginx），那么LB前后的TCP连接是没有关系的，在TCP层面的信息毫无联系，所以就不能按这节课里的方法（对比两侧的抓包文件）来对比客户端抓包和服务端（在LB后面）抓包。不过我们还是可以在以下两种抓包场景里做比较： 1. 比较客户端抓包和LB抓包（LB的客户侧） 2. 比较LB抓包（LB的服务侧）和服务端抓包 但是因为1和2是不同的TCP连接，无法从TCP元数据（IP，port，序列号等等）上找到关联关系。不过，可以在应用层数据上找到这种关系。比如客户侧的某个请求有个特定的uuid，那么LB转发到服务侧后，这个uuid还是保留的，就可以通过它来找到两侧TCP的关系。 这个话题很大，在后续课程里会陆续提到的~
共 2 条评论1
bingo2022-03-05请问老师，客户端和服务端同一个包显示的时间不一样，这是什么原因呢？作者回复: 你好，你具体指的是客户端或者服务端的哪个报文，或者是对哪个图有困惑呢？
共 2 条评论
晴天了2022-02-25在 客户端a 和 服务器端b分别用tcpdump抓包. 然后用wireshark 展开分析 . 发现a 第一次握手发送的序号是 3758130604 , 而在b抓到包内容展示的第一次握手的序号是1594004265, 问下老师是什么问题?作者回复: 比较奇怪，一般发生序列号改变的话，是经过了LB的，你是这种场景吗
共 3 条评论
追风筝的人2022-02-21在两个不同的抓包文件中如何定位到同个报文的方法，也就是使用裸序列号SN。作者回复: 恩，如果我们在通信两端都做了抓包，那么同一个报文就会在两个文件中都出现（假设没有丢包），通过这种方法，找到同一个tcp流