• 那时刻
    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.h
    2022-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
  • bingo
    2022-03-05
    请问老师,客户端和服务端同一个包显示的时间不一样,这是什么原因呢?

    作者回复: 你好,你具体指的是客户端或者服务端的哪个报文,或者是对哪个图有困惑呢?

    共 2 条评论
    
  • 晴天了
    2022-02-25
    在 客户端a 和 服务器端b分别用tcpdump抓包. 然后用wireshark 展开分析 . 发现a 第一次握手发送的序号是 3758130604 , 而在b抓到包内容展示的第一次握手的序号是1594004265, 问下老师是什么问题?

    作者回复: 比较奇怪,一般发生序列号改变的话,是经过了LB的,你是这种场景吗

    共 3 条评论
    
  • 追风筝的人
    2022-02-21
    在两个不同的抓包文件中如何定位到同个报文的方法,也就是使用裸序列号SN。

    作者回复: 恩,如果我们在通信两端都做了抓包,那么同一个报文就会在两个文件中都出现(假设没有丢包),通过这种方法,找到同一个tcp流

    
    