网络排查案例课
杨胜辉
eBay 资深运维专家,流量系统负责人
22781 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
实战三:不用抓包就能做的网络排查篇 (2讲)
网络排查案例课
15
15
1.0x
00:00/00:00
登录|注册

答疑(二)| 第6~10讲思考题答案

“用空间换时间”的缓冲区设计
缓冲区的动态调整原理
应用程序未及时读取数据
接收端只确认部分数据
协议规范问题
使用tc工具进行流量控制
多客户端连接同一服务端的带宽占用问题
DF位设置与MTU值超标的问题
虚拟网卡与物理网卡的MTU配置
长期方案选择
运维和可用性角度
Chrome的TCP Keep-alive策略
NAT与TCP Keep-alive的关系
实际工作中的应用场景
应用层到数据链路层的contains过滤器
精确匹配与模糊匹配
IP ID方法的局限性
Linux系统SYN+ACK的IP ID为0的特殊情况
利用IP ID不连续性识别防火墙
IP ID字段的作用与特性
数据滞留现象的原因
TCP序列号和确认号的最大值
第9到13讲内容的结合学习
实际工作中的TCP传输速度问题
MTU问题的实际案例
修改MSS的劣势与不足
TCP Keep-alive问题
过滤器的使用
防火墙完善TTL特性后的识别方法
利用TTL不一致识别防火墙
继续留言区交流,共同进步
应用知识点解决实际问题的能力提升
对答疑内容的深入理解
对知识点的复习与补充
第10讲:TCP序列号、确认号与数据滞留
第9讲:TCP传输速度问题
第8讲:修改MSS与MTU问题
第7讲:Wireshark过滤器与TCP Keep-alive
第6讲:识别防火墙
总结与思考
答疑(二):第6~10讲思考题答案

该思维导图由 AI 生成,仅供参考

你好,我是胜辉。
在上一节答疑课里,我们回顾了第 1 到第 5 讲的思考题,分析了每道题目的解题思路,当然更重要的是对这五节课的知识点做了一次复习和补充。你看完了这些解答后的感觉如何呢?跟之前你自己的思考过程和结论相比,又有哪些相同和不同之处呢?相信通过再一次的思考,你对知识的掌握将会更加深刻。
那么这节课,我们就继续讲解这些课后的思考题。先从第 6 讲开始。

06 讲的答疑

思考题

这节课,我给你介绍了利用防火墙的 TTL 跟原先的正常报文的 TTL 不一致的特点,从而识别出防火墙的方法。那么,假设有一天,防火墙公司把这个特性也完善了,我们再也不能仅凭 TTL 的突变而发现防火墙了,你觉得还有什么办法可以识别出防火墙吗?

答案

这是一个开放式的问题,其实并没有标准答案。不过,通过对这个问题的思考,我们可以对网络的理解更进一步。我们先参考下面这张图,复习一下用 TTL 判断防火墙的原理:
补充:上图是一个例子,假设防火墙是路径上的第 5 跳,那么防火墙自己发出的报文的 TTL 就比真正的发送端的 TTL 多了 5。
然后想一想,我们之所以能通过 TTL 定位防火墙,本质原因是什么呢?实际上,本质原因就是这个 IP 报文是防火墙自己构造的,而在构造时 TTL 被设置为了初始值
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了网络安全和网络通信中的技术细节,涉及利用防火墙的TTL、TCP Keep-alive、LB或网关上修改MSS以及MTU引发的问题。作者通过回答每个问题,探讨了网络安全、网络通信和网络运维等多个方面的技术细节。其中,重点讨论了在LB或网关上修改MSS的临时和长期影响,以及通过调整MTU来解决问题的长期方案。此外,还分享了一个案例,通过调整虚拟网卡的MTU解决报文丢失问题。文章还提出了思考题,引导读者思考在工作中遇到的TCP传输速度相关问题,并分享了解决方案。另外,还涉及了TCP的序列号和确认号的长度,以及接收端确认部分数据导致的“数据滞留”现象。总体而言,本文对网络安全和通信技术问题进行了深入探讨,对从事网络技术工作的读者具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《网络排查案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(3)

  • 最新
  • 精选
  • 小白debug
    看了“数据滞留”现象的那部分,有些疑惑,表述看起来像是在说,应用层收了300b之后,才会ack300。但实际上ack的行为跟应用层是否收这个数据无关才对。我理解 应该是t3时B发 ack=1000 + 1,win=0,window full,此时A会发现对方接收窗口满了,过一阵A再发一次窗口探测,此时B的缓冲区被应用层收走了300b,所以此时B回复给A的是ack=1000 + 1, win=300. 求老师帮助解惑。

    作者回复: “ack的行为跟应用层是否收这个数据无关”--这是正确的,也就是TCP不需要等应用层取走数据后再给发送端给与TCP确认。不过,应用层收取数据太慢的话,事实上会导致接收缓冲区变大,容易触及分配给这个socket的缓冲区上限。到达上限的时候,就是发送windows=0的时候了~ 另外,我在t3这里标记了“window full”,这是wireshark的解读,并不是tcp报文本身携带的信息。接收方接收窗口是1000,收到了1000,那么此时窗口用完了,这是一种判断。它跟zero window是不同的。 window full:在途数据=接收窗口,是wireshark的解读 zero window: 明确的在报文里window字段是0,不需要wireshark也可以直接看出来,比如在tcpdump的输出里

    2022-07-23
    2
    3
  • 那时刻
    请问老师例子中在途字节数是 700 字节,是因服务器window full直接丢弃?还是有可能服务器把缓冲区数据被应用程序处理后再次接收呢?

    作者回复: 在途字节数700字节,是发送端自己判断出来的,是根据“已发送数据 - 被确认数据”得出的。 而Window Full是Wireshark根据报文情况作出的解读,这个信息表示:在被标记的时间点,(服务端的)接收窗口已经被用完。这里不会有丢弃的行为。 在服务端确认了300字节的数据后,发送端就知道,虽然另外700字节还未被确认(因此仍属于在途数据),但是窗口已经空出了300字节了,于是可以继续发送300字节。 在服务端应用程序从缓冲区取走更多数据后,发送端就可以发送更多字节。 概括来说,在TCP里,发送端是不会发出超过对方缓冲区大小的数据的(恶意的除外)。

    2022-03-17
    2
  • loris
    老师,最近排查一个数据库查询结果返回的问题,根据ID查询返回一个大文本字段,整体结果20分钟才返回,如果立即中断查询,查询结果立即返回 抓包分析发现有很多Tcp zero window 报文 ,老师能不能对Tcp zero window补充讲解一下

    作者回复: 正好有个学员也问到了zero window的问题,我把问题和回复都在这里发一下,供你参考: 问:老师,我们工作中有同事遇到了tcp window zero,我当时没参与这个任务,没去看具体的抓包数据,但好像也是接收端窗口满了的原因。请问window zero 和window full的区别是什么呢?是视角不同吗?zero是接收端视角,full是发送端视角? 作者回复: 你好,这两个信息都是关于window的,确实很容易搞混,我这里解释一下。其实跟视角没关系。 tcp window zero是指,这个tcp报文的window字段明确就是0,也就意味着这个报文的发送方的接收缓冲区已经变成0了,另一方就会停止发送数据。当然,为了避免无限等待,另一方会有探测机制,定制发送一个零载荷的报文,让window zero这一端回复报文,从这个回复报文里读取到最新的window值。 tcp window full是指,这个报文发送后,另一端的接收窗口就满了。我举个例子,现在A和B在通信,A的一个报文被wireshark标记为tcp window full,指的是A的未被确认的数据量(也就是在途字节数)跟B的接收窗口相等。这意味着A不会发送更多报文(即使B没有发送window zero的报文),因为A知道发送出去的数据量已经“填满”了B的接收缓冲区~

    2022-11-09归属地:上海
收起评论
大纲
固定大纲
06 讲的答疑
思考题
答案
显示
设置
留言
3
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部