Hi，欢迎来到 卡瓦邦噶！这里是一个 SRE 的博客，讨论的内容有：Linux, Vim, Tmux, NixOS, Python, Java, TCP/IP, Container, Docker, Ansible, Git, Graphviz, Redis, Prometheus, SSH, Shell, Bash, GNU, Github, C, C++, Unix, Nginx, Lua, Django, React 以及运维的方法论，编程的思考，工作的感悟。除了技术上的内容之外，这个博客还会分享一些读书感悟，电影和音乐等。欢迎留下你的评论。
声明：本博客内容仅代表本人观点，和我的雇主无关。本博客承诺不含有 AI 生成的内容，所有内容未加说明均为博主原创，一经发布自动进入公有领域，本人放弃所有权利。转载无需本人同意。但是依然建议在转载的时候留下本博客的链接，因为这里的很多内容在发布之后会还会不断地继续更新和追加内容。
之前写过一个服务发现系统，叫做 prometheus-http-sd，给 Prometheus 查找监控的目标使用。它的原理很简单，每当 Prometheus 请求 prometheus-http-sd 服务的时候，这个服务就执行用户的脚本，拿到 targets，然后返回。定位是作为一个中间系统，对接 Prometheus 和其他的 CMDB。用户通过写一个简单的脚本，可以将任何系统返回的结果，转换成 Prometheus 的 API 格式返回给 Prometheus.
于是就会有一个自然而然的需求：缓存。
如果部署了 100 个 Prometheus 采集端，那么每一个都需要来做服务发现，如果每 60s 请求一次，那么每分钟就有 100 次请求。监控目标的变更没有那么频繁，而且分钟级的不一致是可以接受的（Prometheus 原生的这个 HTTP 做服务发现的模式已经是分钟级不一致了）。所以我们可以把用户脚本的执行结果缓存起来，至少缓存1分钟，拿一次运行结果直接返回给这分钟内的其他请求。（考虑到内部系统一半写的比较差，这样可以节省巨大资源，笑）
以上是背景。这个缓存功能上线以后，我见到了10万行的一个错误 stack traceback:
这是异常日志的一部分，不知道读者是否能发现什么端倪。这个服务是开源的，存在 bug 的版本是这个。
首先第一个比较明显的 bug 是，在用户脚本正常执行的时候才设置了缓存过期的时间，在发生异常的时候没有设置 expire 时间。这就导致了，一旦用户的脚本出发了 Exception，这个 Exception 就会进入到缓存中，并且不会过期，导致以后这个脚本永远会命中缓存返回 Exception。
但是为什么我会看到这么奇怪的 stack 呢？
看到这个 Exception，我的第一个想法是有什么地方拿到这个 Exception 之后，又作了修改，然后 set 回去，修改的时候又包上了当前的 stack，所以越包越长。但是在代码中看了好几遍，这个缓存都没有重新设置的地方。然后又用 PDB 去debug，跟着走了一遍代码，一切都是正常的。最后又用 watchpoint 这个库跟踪了一下，结果也是一样，cache 没有被重新修改过，只有第一次触发有 set。
那好吧，然后我又想到，会不会在 raise Exception 的时候，这个 stack 其实就是这样的了呢？又用 pdb 去跑了几遍代码，发现不存在这么深的 stack。（后来想了一下，Python 默认的 frame 最大好像是 1000，如果真是这样的 stack 的话肯定已经 stack overflow 了！）
想到这里已经没了思路，决定回家睡一觉。
第二天一醒，问题就解决了。
现在抛去一些无关的逻辑，最小化一个复现的 Case 是这样：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
import traceback d = {"e": Exception("foobar")} def raise1(): raise d['e'] def raise2(): raise1() if __name__ == "__main__": for _ in range(3): try: raise2() except Exception as e: traceback.print_exception(type(e), e, e.__traceback__) |
其中 d 是我们的缓存，上来就已经有了，然后，我们在代码中会 raise 这个 Exception 3 次。和 prometheus-http-sd 中是一样的逻辑。
看似无害，其实是有 bug 的。
它的输出如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
Traceback (most recent call last): File "/private/tmp/1.py", line 17, in <module> raise2() File "/private/tmp/1.py", line 11, in raise2 raise1() File "/private/tmp/1.py", line 7, in raise1 raise d['e'] Exception: foobar Traceback (most recent call last): File "/private/tmp/1.py", line 17, in <module> raise2() File "/private/tmp/1.py", line 11, in raise2 raise1() File "/private/tmp/1.py", line 7, in raise1 raise d['e'] File "/private/tmp/1.py", line 17, in <module> raise2() File "/private/tmp/1.py", line 11, in raise2 raise1() File "/private/tmp/1.py", line 7, in raise1 raise d['e'] Exception: foobar Traceback (most recent call last): File "/private/tmp/1.py", line 17, in <module> raise2() File "/private/tmp/1.py", line 11, in raise2 raise1() File "/private/tmp/1.py", line 7, in raise1 raise d['e'] File "/private/tmp/1.py", line 17, in <module> raise2() File "/private/tmp/1.py", line 11, in raise2 raise1() File "/private/tmp/1.py", line 7, in raise1 raise d['e'] File "/private/tmp/1.py", line 17, in <module> raise2() File "/private/tmp/1.py", line 11, in raise2 raise1() File "/private/tmp/1.py", line 7, in raise1 raise d['e'] Exception: foobar |
可以看到，每一次这个 Exception 被 raise，它的 stack 都加深了。
到这里问题就明了了：raise Exception 这个操作本身就会修改这个 Exception。
从 PEP 3134 中发现，Python3 已经把和一个 Exception 有关的 traceback，局部变量等放到 Exception 对象中了。这里也说，你不能明确地指定一个 Python Exception 的 traceback。按照我们上面中代码的行为看，就是，Python 在 raise Exception 的时候，会把当前的 stack 写到 traceback 中，但是如果当前已经有 __traceback__ 了的话，就会把之前的 traceback 保留住。（但是没有找到相关资料和代码，欢迎读者补充）
所以，这里每次 raise 一次被缓存下来的 Exception，这个 stacktrace 就会加深一次。
那么问题如何解决呢？我觉得 Exception 不应该被缓存下来，从 Python 的机制可以看出，Exception 被 raise 的时候，应该是 Exception 真正发生的时候。而在我们的这个场景中，Exception 并没有发生，而只是我们返回了之前的一个缓存。缓存 Exception 对用户也有困扰，这个 Exception 看起来就像是：“我运行了你的代码，你的代码出错了”，而实际上用户的代码并没有执行过。所以我觉得这里应该缓存下来一个错误信息，string 就可以了。而不应该缓存 Exception 实例。
小插曲
在做以上实验的时候，我发现用这个代码，就会触发一个奇怪的错误：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
import traceback e = Exception("foobar") def raise1(): raise e def raise2(): raise1() if __name__ == '__main__': for _ in range(3): try: raise2() except Exception as e: traceback.print_exception(type(e), e, e.__traceback__) |
错误如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
Traceback (most recent call last): File "/Users/xintao.lai/Downloads/ex.py", line 15, in <module> raise2() File "/Users/xintao.lai/Downloads/ex.py", line 10, in raise2 raise1() File "/Users/xintao.lai/Downloads/ex.py", line 6, in raise1 raise e Exception: foobar Traceback (most recent call last): File "/Users/xintao.lai/Downloads/ex.py", line 15, in <module> raise2() File "/Users/xintao.lai/Downloads/ex.py", line 10, in raise2 raise1() File "/Users/xintao.lai/Downloads/ex.py", line 6, in raise1 raise e ^ NameError: name 'e' is not defined Traceback (most recent call last): File "/Users/xintao.lai/Downloads/ex.py", line 15, in <module> raise2() File "/Users/xintao.lai/Downloads/ex.py", line 10, in raise2 raise1() File "/Users/xintao.lai/Downloads/ex.py", line 6, in raise1 raise e ^ NameError: name 'e' is not defined |
说这个 e 没有定义，好奇怪。
然后在文档中找到了答案。
原来 except 之后是有一个 clear 动作的。
想了一下，这应该是用来解决 GC 问题的。因为 Python3 把 trackback 放到 Exception 上，实际上是创建了一个环形的引用： err -> traceback -> stack frame -> err，引用计数无法清除，必须要等垃圾回收。而这部分环形的设计的对象又比较多，比如局部变量里面有已经关闭的文件的话，在 gc 之前，可能 file handle 会耗尽。所以这里解释器相当于做引用减 1 ，破掉 stack frame -> err 这个环。（不过感觉应该有办法区分开，当前的 e 不是 local，不要 del 吧？）
今天听闻陈皓去世了，心情久久不能平静。周末的时候我还在看他在 Twitter 分享的一个观点，居然这一条就成了他最后发送的推文。
陈皓对我的帮助非常大，我的书签，博客引用，和笔记里面，都有很多对 coolshell.cn 的链接。可以说，他是我在很多领域的启蒙老师。
一些教程只是教会你用某一个工具，但是陈皓写的文章，是想教会你这个东西设计的逻辑，使用的核心思想是什么，举一反三，和其他优秀的设计有什么相通之处。
由于国内特殊的工作环境，在技术方面做到他这个级别的前辈很少了，又几十年如一日在网络上耐心地分享自己的知识的人就更少了。陈皓就像一盏明灯，不知道照亮了多少人的路。
像陈皓这样光在网络上就有十几万的粉丝的“网红”，却很少见到有负面评价，今天在网络上大家都是清一色的表达自己的悲痛和思念，是因为他帮助过的人实在太多了，即使网络上跟别人有争论，也都是有理有据，讲逻辑，很有耐心。
我和他有过短暂的交流，沟通的过程非常舒服，他是一个很谦逊的人，即使对于我这样的后辈，也称可以“学到东西”。
由衷地感谢这位素未谋面的老师，愿在天堂安息。
让我们永远记住这位伟大的人。
旅行的轨迹一直在往南走，不断突破“去过的最南边”，从上海，到杭州，厦门，广州，新加坡，最近去了巴厘岛，第一次约过了赤道。
我们从新加坡出发，先去雅加达转机，然后再去巴厘岛。
巴厘岛的时间让我怀疑人生：我们的轨迹一直向东飞，到雅加达，时间变了 -1，然后从雅加达到了巴厘岛，时间竟然又 +1，明明一直是向东飞，为啥会先减后加呢？
最后发现奇怪的并不是印度尼西亚，原来是新加坡，这个地方本来是 UTC+7, 现实却是 UTC+8, 导致我们只要出了新加坡就会先变成正常的 UTC +7, 然后向东，再经历一次正常的时区变更，堪变成 UTC +8.
巴厘岛所在的城市叫登巴萨，所以机票上是登巴萨而不是巴厘岛。因为巴厘岛的建筑限高，所以机场建在哪里都无所谓……于是就建在了市区，这是我去过的唯一一个在市区的机场。机场是填海造的，所以下降的时候有一种要掉进大海的感觉。
来之前还担心天气，天气预报说将来一周几乎天天有雨。来了之后发现这种担心几乎是多余的，雨很少下，即使下，也不会连续下一整天，太阳很快就出来了，不像新加坡一样，经常淅淅沥沥下好几天。也可能是刚过了雨季有关，巴厘岛的雨季是10月份到3月份。
第一天到了酒店，然后在顶楼酒吧喝了一杯 welcome drink. 酒保很热情，跟我们介绍了很多印尼的文化。
酒店顶楼酒吧的景色很不错
welcome drink
之后去了一个比较近的海滩，有一些失望，沙滩上的垃圾也太多了…… 然后去了一家酒吧吃饭，吃的……汉堡。
最近刚去了普吉岛（咦？游记呢？），来巴厘岛之前以为海岛会大同小异，来了之后发现很不一样。普吉岛的海滩很干净，傍晚就看到很多工人在清理海滩。巴厘岛的公共海滩堆满了垃圾，大部分的度假村酒店都有自己的私有海滩。（感觉是不是政府不太行）
食物上也是，普吉岛到处都是泰国菜，我们旅行的几天，每天都随机走进一家泰国餐厅，完全没有翻车，怎么点都好吃。巴厘岛就不一样了，居然是西餐披萨汉堡居多。（后面就知道为什么了……）
第二天直接报了个团出海了。上午去浮潜，下午去几个景点打卡。行程主要是在佩尼达岛附近。
发生了一个很有意思的事情，我这天穿着一双亚瑟士的鞋，居然有个英国小哥过来搭讪问我鞋子从哪里买的，我就告诉了他型号。原以为是开场白有其他话题，没想到他接着跟他爸爸在网上查了一下，还跟我对了一下英镑新币价格。第一次感受到一种“小红书集美要链接”的感觉。
上船，天气很好
海水是绿色的
打卡景点1，打卡就真的是卡个卡，来了，拍张照片，然后就走了……
著名景点1 所谓的精灵沙滩
第二个地方，其实挺危险的，拍照的地方向前一步的话就掉下去了，非常非常高。
景点2 好像是叫恶魔眼泪
第三个景点相比之下就有些垃跨了，我拍出来是这样的：
小红书用户拍出来是这样的：
晚上又坐船回到了巴厘岛，从 Trip Advisor 上找了一家评分最高的印尼菜餐厅。
印尼人民无比热情和友好，遇到一些服务行业的人员，比如酒店服务员，司机，餐厅的服务员，他们都会友好的打招呼，即使我打着另一家酒店的雨伞，明显不是同一家酒店的，在路上他们也会友好地问候你。
到了这家餐厅，发现这家餐厅是在一家酒店里，点菜的时候，服务员问我们房间号码，我们说我们不是住在这里的，单纯来这里吃饭。服务员听到之后感觉都两眼放光了，说谢谢我们，然后，我就体验到了几乎是这辈子吃过的服务最好的一顿饭！
这几乎是五星级酒店的服务，人均才150人民币左右。但是相对当地物价来说，可能是非常贵的水平了。服务员每次上菜都给我们介绍每一道菜的原料，制作方法，在印尼传统里面的历史。有一个菜有 10 种酱，她耐心地给我们花了有 10 几分钟给我们介绍每一种酱是什么。而且一共问了不下10遍“食物怎么样”，出于礼貌我们每次都说很好。很多手法也很专业，比如盘子都是温的，面包用篮子盛着。环境也很棒，酒店很漂亮。只有一点不好：就是不好吃。
餐厅环境
第一个菜，有10种酱和薯片，加开胃菜，和两个饮料
本地食物
可惜我的胃实在欣赏不了印尼食物，也没吃下多少。最后也掩盖不住了，只好说 “it’s good but not our taste”, 热情的服务员漏出了无法掩饰的失望，笑容逐渐消失…… 我拿了账单给了小费就赶紧溜了…… 并且决定接下里的行程就以西餐为主好了。
他们还让我填了 Feedback 卡片，后来发现很多餐厅吃完了都让我写这个，酒店也让我写。看来这里的人民很注重服务质量啊。
包了个车，继续去各种景点打卡。
第一个景点：海神庙。
然后去了一个瀑布，说实话，感觉一般，和杭州九溪差不多……
我拍的跟小红书差距很大
最后是一个梯田，像是一个游乐园的综合体，有网红秋千（很高的那种），有梯田，有泳池 party。
门口放着咖啡豆，现做现卖
非常高的秋千
飞起来是这样子
还有一些雕像，比如这种：
这种：
还有这种：
我叫它“祖马”
晚上回酒店叫了个必胜客外卖，就结束了。
换了一家酒店（其实是同一家，都是 IHG 开的），是一个度假村，在酒店躺了一天。
躺平的一天
然后下午去了牛角，吃了顿自助。只要 40 新币就可以随便吃，还可以看日落（记住这个日落，它还会出现，以不一样的形式）。新加坡的牛角要 90 新币。
牛角的环境
本来这天没什么计划，后来又包了车去南边玩。（我很后悔）
清澈的海水
第一站是乌鲁瓦图，悬崖，大海，挺好看的。
高高的悬崖
下面这图叫情人崖：
进来之前，司机提醒我们注意眼镜，里面有猴子。庙里也有各种语言的牌子提醒游客看好自己的财物，注意猴子。我觉得挺搞笑的，太夸张了。
……下图是我的眼镜，和抢走它的猴子：
不知道为什么猴子想吃了我的眼镜。后来来了一个女人，给猴子几包豆子把我的眼镜拿回来了（虽然完全不能用了），然后伸手跟我们要钱……
现在感觉新加坡不让喂猴子（喂猴子违法）很有道理，喂多了它们就会抢你的东西，徒步的时候看到的猴子都比较老实。
最后一站去金巴兰海滩看日落，海滩日落……是不是很美？
到了之后发现是这样的：
堆满垃圾的海滩
如果不拍到垃圾的话还可以。
远处海天相接的地方正好有一只小船
第二天又在酒店泡了一下就回去工作了。
最近因为遇到了一个和 MSS 有关的问题，所以花了很多时间学习相关的东西。过程中又发现网上有很多相关的内容是错误的，或者介绍的东西其实现实世界已经不用了。（感觉网络相关的知识经常有这种情况，介绍一种完全过时，现实世界已经不再是用的东西。比如我很久都搞不清 IP 分 Class 有什么意义，后来看到 RIP 才明白原来这古老的路由协议假设全世界的网络号都是 classful 的，让路由结构简单了很多。）我看到这些资料的时候有了无数的疑问，然后又花了很长时间，这些疑问现在基本上都有了一个合理的解释。这篇博客就来总结一下和 MTU, MSS 有关的内容。有可能也写不完“一切”，但是预料到会写的很长。所以你现在去冲一杯咖啡，我们从最简单的地方开始。
MTU 指的是二层协议里面的最大传输单元。
这是一个很简单的概念。但这是我最初的问题来源，不知道你看到这个之后是否也会有相同的疑惑：
我们从最简单的说起……
MTU 的存在很合理，Frame 不可能无限大，发送小的数据是可以的。所以就设定了一个最大值。我们在网卡上看到的 MTU 一般都是 1500bytes，要注意这个值指的是 Frame 内容的最大值，并不包括 Ethernet Frame 的 header 和 FCS。一个 Ether Frame 最大是 MTU + Header 14bytes + FCS 4 bytes = 1518 bytes.
那么为什么 MTU 都设置成 1500 呢？
MTU usually is 1500
可以说是历史原因。维基百科有这么一句话：
Larger MTU is associated with reduced overhead. Smaller MTU values can reduce network delay.
第一句话很好理解，更大的包，header 占据整个包的比例就更小，那么链路上更多的资源就花在了数据的传输上，协议消耗的 overhead 就会很小。
第二句话呢？
我觉得 Ethernet 最精髓的地方就在于，它和我们说话一样。如果两个人在交谈，突然同时说话了，会发生什么？两个人都是停下来，等一段时间，然后一个人又开始说了，那么另一个人要等他说完再说。
那么就意味着，更大的包就会让一个人占据链路的时间更长，所以总体上延迟就会变大。此外：
综上，1500 其实是一个 Trade Off。
其实，不同的 2 层协议有不同的 MTU：
不同传输媒介的 MTU
这就是为什么一般 MTU 都是 1500.
这里要提一下 Jumbo Frame，可以最大支持 9000 bytes，提高传输的速率。不过现实中基本上见不到，Internet 上更见不到。因为 Ethernet 是 2 层协议，负责点对点的传输，如果因特网上如果一个 Jombo Frame 要能从用户传到另一个用户或服务，这需要所有点对点设备都要支持才行。而现实的世界里，基本上网络上所有的路由，交换设备，端设备，路由器，设置的 MTU 都是 1500.
这就有了下一个问题：那如果超过了这个大小呢？
Drop. 这是最简单的处理方法。也是现实世界很多软件，硬件的处理方式。
但是显然这取决于软硬件的实现方式，比如 Cisco 的交换机就可以支持一个 Baby Giant feature（好可爱的名字）: 交换机可以转发超过 1500 bytes ，但又不超过很多的 MTU。有些软件和设备支持类似 feature，有些不支持，大部分都会直接 Drop。
既然上文说到基本上所有的设备设置的 MTU 都是 1500，那么为什么还会出现超过 1500 的 MTU 呢？
最常见的是 VPN 和 overlay 网络。这种网络本质上就是将二层包再包一层，在底层互联网上建一个虚拟的二层网络。比如说 VXLan，它会在原来的 Ethernet Frame 基础上加一个 VXLan header，然后变成 UDP 包发出去。
VXLan 包结构，图片来源
这样，假设我们原来的 Ethernet Frame 里面的数据是 1500 bytes，经过 VXLan 包装之后，就变成了：1500 + 14(原来的 Ethernet Frame header) + 8(VXLan header) + 8(UDP Header) + 20 (IP Header) = 1550 bytes, 超过了 50 bytes. （原来的 Frame 里的 FCS 不在里面，因为网络处理过了。）
如果抓包，就像下面这样：
它是原来的 Ether II frame 变成了 UDP 的数据，被包起来了，又封装成 IP，Ether 发出去。
超过 MTU 的包大部分网络设备都会直接丢掉，所以我们就需要保证发送的数据不超过 MTU （上图是一个反例）。
很显然，我们需要分成多份发送。如果我们要让 2 层网络发送（意思就是包括 IP header 在内一共） 4000 bytes 的数据，那么就要分成 3 个 Etherframe 来发送：第一次发送 1500 bytes，第二次 1500 bytes，第三次 1000 bytes.
要让最终传给 2 层协议的 Frame 数据大小不超过 1500 bytes，就要保证上层协议每一层都没有超过这个大小。
拿最常用的 4 层协议 TCP 来说，如果 MTU 是 1500，那么 IP 层就要保证 IP 层的 Packet 数据不超过 1480 bytes (1500 bytes – 20 bytes IP header), 对于 TCP 来说，它要保证每一个 Segment 数据大小不超过 1460 bytes (1460 bytes – 20 TCP header).
那么 TCP 层要怎么知道 2 层的 MTU 是多少呢？
TCP 层的最大传输数据大小，就叫做 MSS (Maximum segment size).
对于 TCP 来说，我知道了自己这边的 MSS，但是其实并没有什么用，因为我作为接受端，收到的包大小取决于发送端，得让发送端知道自己的 MSS 才行。
所以 TCP 在握手的时候，会把自己的 MSS 宣告给对方。
在 TCP 的握手阶段， SYN 包里面的 TCP option 字段中，会带有 MSS，如果不带的话，default 是 536. 对方也会把 MSS 发送过来，这时候两端会比较 MSS 值，都是选择一个最小的值作为传输的 MSS.
（博客显示的图片如果太小，可以点击图片放大查看）
实际应用场景是什么？拿上文我们提到的 VXLan 封装举例，VXLan 封装的这一端知道自己需要 50bytes 的 overhead 来封装 VXLan，那么它就可以告诉对方，自己能接受的最大的 MSS 是 1410bytes (1500bytes MTU – 20 IP headers – 20 UDP headers – 50 bytes VLan)，对方发过来的 MSS 是 1460 bytes(1500 bytes – 20 bytes – 20 bytes). 然后两端都会用 1410 bytes 作为 TCP MSS 值，即保证发送的 4层 segment 都不会超过 1410 bytes.
这里就有一个疑问：为什么 MSS 两端都使用一个共同的值，而不是 A -> B 1410 bytes; B -> A 1460 bytes, 这样不是可以更高效吗？
这个问题的答案我找了好久，感觉很多地方说法不一，比如这里就说:
TCP MSS is an option in the TCP header that is used by the two ends of the connection independently to determine the maximum segment size that can be accepted by each host on this connection.
但是很多地方也说两边的 MSS 会一样。
这个我自己测试了一下，手动调整一端的 MTU，另一段不调整，发现两端发送数据都会比较小的值。
MTU 一段设置为了 800，另一段是 1500，在 TCP 握手阶段可以看到。
从 10.130.0.6 发送给 10.130.0.5 最大的包是 800.
从 10.130.0.5 到 10.130.0.6 也是 800.
为啥双方用一个共同的最小值，这个我没找到确凿的原因，我觉得理论上两端分别用 MSS 是可以的，就像 TCP 的 rwnd 一样。但是，在现实的网络上，A 发送 B 有限制，那么 B 发送到 A 很大可能也有一样的限制。所以两边会把这个 MSS 作为链路上某一个点的瓶颈。毕竟，每一端都只知道自己这部分网络的情况，最好是基于自己和对方综合的信息来做决策。
如果已知有明确的网络情况，可以调小自己的 MSS，设置的方法有 3 种：
iptables -I OUTPUT -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 48ip route change 192.168.11.0/24 dev ens33 proto kernel scope link src 192.168.11.111 metric 100 advmss 48|
1 2 3 |
from scapy.all import * ip = IP(dst="192.168.11.112") tcp = TCP(dport=80, flags="S",options=[('MSS',48),('SAckOK', '')]) |
当然了，也可以直接调整网卡上的 MTU：ifconfig eth0 mtu 800 up. 这样 Kernel 的 TCP 栈在建立连接的时候会自动计算 MSS。（上文写过的这个过程）
我们这里说的都是 TCP 两端的设备如果清楚自己的网络情况的话，可以进行的一些设置。还有一些情况，比如说一些 VPN 和 overlay，端对此并不知晓，完全是中间的路由设备做的。中间设备需要预留 50bytes，有什么方法可以让两边都知道，发送的数据包要预留 50bytes 呢？
我们在一个 VPN 环境中测试一下，网络结构可以简单地理解为 [Client -> VPN] -> Server.
Client 端对 TCP SYN 抓包
Server 端对 TCP SYN 抓包
仔细观察 TCP 建立连接的过程，可以发现 Server 端抓包，发现 Server 发送给 Client 的 MSS 值是 1460 bytes，但是 Client 收到的时候变成了 1190 bytes.
这意味着，除了 TCP 的两端，中间的路由设备也可以做 MSS Clamping，影响两端选择 MSS 的过程，以确保网络中为其他协议的 overhead 预留出来了足够的空间。
以上说的都是，协议的每一层，都确保了自己递交给下一层协议的数据单元都没有超过下一层协议的最大长度。但是我们并不在一个完美的世界中，假设协议收到了超过最大数据单元的数据，会怎么做呢？
其实，每一层协议自己都会有机制，让自己发送的内容不超过下层协议能承载的最大内容(最大 PDU)。
我们从下往上讲起。
二层协议一般都很简答，如果收到了超过 MTU 的包，一般会简单地 drop 掉，要依靠上层协议来保证发送的数据不超过 MTU。
但是也有协议可以支持拆分(Fragment)，比如二层的 MLPPP。
IP 层的处理就比较经典了，自己收到的是上层协议发给它的内容，然后要负责通过 2 层来发送出去，上层的内容是无法控制的，但是要控制自己发送到下层的内容。
所以 IP 支持一个 feature 叫做 IP Fragmentation.
如果 IP Packet 超过了 1500bytes，IP 协议会将这个 packet 的 data 段拆分成多个，每一个分别上 IP header，以及 fragment header 标志这是拆分成的第几段。 接受端等收到所有的 IP 分片之后，再组装成完整的数据。
我们可以通过 ping 来发送一个超过 MTU 1500 bytes 的数据。ping -s 2000 -I 172.16.42.21 172.16.42.22
抓包如下：
读者可以从这个链接下载抓包文件自行浏览
可以看到一个 ping 一共有 4 个 IP 包，2个完成 Echo 2 个完成 Reply. 其中 Echo request，第一个 IP 包总大小是 1500 bytes，除了 IP 包的 20bytes header，还剩下 1480 bytes 是 ICMP 的数据，第二个 IP 包里面有 528bytes 是 ICMP 数据，两个 IP 包带的数据一共 2008 bytes，是符合我们的预期的，8bytes 是 ICMP 的 header。
由此，可以发现 IP Fragmentation 其实是把上层的数据拆分到多个 IP 包里面，不管上层的数据是什么。说白了，第一个 frame 有 ICMP 的 header，第二个 ICMP 包没有。如果把承载 ICMP 协议换成 TCP 协议，我们就可以发现问题了：收到了 IP framented frame，是无法处理的，因为这个 IP 包的数据对于上层协议来说是不完整的，假设一个 IP 包被 fragment 成了 3 个 IP 包，我们就必须等到 3 个 IP 包全部到齐才可以处理。
所以说：IP Fragmentation is generally a BAD thing.
可能导致的问题有：
所以，在现实的世界中，我们几乎看不到 IP Fragmentation 的，要依靠上层协议保证传给 IP 层的数据大小不需要 fragment.
上文已经提到了 MSS。但是我们平时写应用程序的时候，从没有自己分过 Segment，这是因为 TCP 是面向数据流的，你有一个 socket 之后，尽管向里面写就可以了，Kernel 的协议栈会负责给你将数据拆成正好能放到 IP 包里的大小发出去。注意这里是拆成多个 TCP segment 发送，在 IP 层并没有拆开，每一个 IP 包里面都有 TCP 的 header。
Layer 3 的 IP Fragment 会导致这么多问题，我们宁愿这个包被丢弃，也不要分成多个包发送。
IP 协议的 header 中有一位 bit 叫做 DF，如果这个 bit 设置了，就是告诉中间的路由设备不要分片发送这个包，如果大于最大传输单元的大小，直接丢弃即可。丢弃这个包的设备会发回一个 ICMP 包，其中，type=3 Destination Unreachable, Code=4 Fragmentation required, and DF flag set. RFC 1191
用 tcpdump 我们可以这么抓 ICMP 包：tcpdump -s0 -p -ni eth0 'icmp and icmp[0] == 3 and icmp[1] == 4'
发送端收到这个错误，就需要降低自己的 MSS 重新发送，重复这个过程，直到 MSS 满足条件为止。这个过程就做 PMTUD, 中间路径上的 MTU 探测 RFC 4821.
在 IPv6 中，行为基本上是一样的，但是 IPv6 没有这个 DF flag，所有的 IPv6 包都禁止中间的路由设备进行分片，也就是说等同于 IPv6 包永远是 DF=1，遇到 MTU 太大丢包发回来的是 ICMPv6(Of course!)
这里有一个问题，就是如果一些中间设备，因为安全原因（下文会解释）禁用了 ICMP(ping), 这样可能导致的问题是，TCP 连接能建立成功，但是数据一直发不出去，造成黑洞连接 RFC 2923。解决这个问题的核心，是要区分丢包到底是中间链路造成的，还是 MTU 太大造成的。TCP over IPv4 感觉没有特别好的办法，最好是允许 type 3 的 ICMP 包。RFC 4821 提出了一种不依赖 ICMP 的 PMTUD 方法，本质是使用小包开始，逐渐增大大小直到达到 MTU 上线，和 TCP 拥塞控制有异曲同工之妙。
至于这个“安全原因”，就比较有意思了。举一个例子：如果攻击者知道服务端的地址，即使攻击者不在 Client – Server 的路由链路上，它也可以发送一个 ICMP 包告诉 Clinet MTU too large, 让这个连接的双方降低 MSS 从而降低性能。
还可能有另一个问题，有些 DC 可能用了 ECMP 技术，简单来说，一个 IP 后面有多个服务器，ECMP 会根据 TCP 端口，和 IP 来做 hash，这样可以根据 IP + Port 来保证路由到正确的 Server 上，即使 IP 一样。但是对于 ICMP 包来说就有问题了，ICMP error 包可能被路由到了错误的服务器上，导致 PMTUD 失败。Cloudflare 就遇到过这个问题。
说到这里，基本上就讲完了最近看的资料和自己的实验的内容，因为是一边学习一边记录的笔记，所以可能有不正确的地方，还望指正。
下面说两个有意思的问题。
如果你通过抓包去看一下 MSS 是否是有效的，里面每一个包的大小是否最大是 1500 bytes，你会怀疑人生。
明明协商的 MSS 1460，但是后面的数据居然有 1万多bytes的？？在接收端抓包也一样。
这个叫 TSO，TCP Segment Offload.
上面我们讲为了不发生 IP Fragment, Kernel 协议栈要负责把 TCP 分成一个个不超过 MSS 的小包发送，这部分工作是简单重复并且计算量比较大的，很显然，适合网卡来做这个工作。
所以 TSO，就是网卡 Driver 告诉 Kernel，这个工作可以交给我，做拆包我一直可以的，我可以一直拆包的，于是，Kernel 就发大包到网卡，网卡完成大包拆小包。
但是对于抓包来说，我们看到的就是 Kernel 发送了大包，因为抓包过程是看不到后面网卡具体做了什么的。
图片来源
如果我们关闭 TSO 功能: ethtool -K eth0 tx off。然后再抓包，你就会发现抓到的每一个发送的包都是 1500 bytes 了。
但是即使你按照 1500bytes 发送，然后这时候去接收端抓包，会发现还是有大包。发送端发送的都是小包，为啥到接收端就成了大包呢？显然网卡可以对发送做 offload，也可以对接收做 offload，网卡会攒一些 TCP 包，然后合起来发送给 Kernel 的协议栈。
这减轻了 Kernel 的不少 CPU 负担，转移到了硬件上完成。但是……分析 Sequence number 就是一个 pain in the ass 了。
第二个是工作中遇到的问题，也是我看这些东西的起因。
我们的 SDN 网络有一种这样的路由：
一种奇怪的“三角路由”，其中 Router 会添加 50bytes 的额外 header，然后发现 Router 这里发生了丢包。
最后发现，原因是我们对 eth0 设置了 MTU = 1450，但是忘记设置 ip route，导致握手阶段的包从 eth1 出去了，eth1 的默认 MTU 是 1500，PC 发送的 MTU(MSS actually) 也是 1500，就导致双方一致认为 MTU=1500，MSS=1460. 但是实际上到 Rrouter 这里加了 50bytes 的 overhead，就造成了丢包。
参考资料，文中潜入的链接就不再单独列在这里了：
今天线上发现了一个机器的子网掩码配置错了，其实问题比较简单，一开始没有想到会是这个问题，想了好久才想到这里。
我觉得网络有意思的地方就是在于这些网络协议要考虑的不仅仅是正常的情况，处理正常的情况很简单，而主要的设计其实都是针对不正常的情况如何处理的，比如处理网络中的错误、环路，错误的路由等等。但现实就是，各种各样奇怪的事情会发生，协议必须能处理好各种异常。
不妨拿这个问题来复习一下网络协议：如果子网掩码配置错了，那么两台机器能 ping 通吗？
这个问题看似比较简单，但是答案并不是一个简单的“是”或者“不是”，因为这分成好几种情况。
首先，我们明确这个子网掩码的作用，简单来说，就是判断目标地址和自己是否在同一个网络内：
即，这个判断是发生在本地的，是一台机器判断应该将数据包的目标地址设置成网关的 MAC（不在同一个子网），还是目的 IP 的 MAC（在同一个子网下）。
对于其他的计算机来说，他们不知道你设置的子网是什么，对于他们发送给你的数据包来说，无论你的子网设置成什么，只要 IP 设置对了，都可以收到。子网的设置只对 egress 流量有影响，对 ingress 流量没有影响（不考虑 ingress 依赖 ARP 这些的话）。下文中会用 “我” 来表示本地的机器。
首先看子网配置的范围比正确范围大的情况，比如我的 IP 本来应该是 1.1.3.2/24, 但是错误的配置成了 1.1.3.2/16.
可以从不同的目标地址来分析影响：
1.1.3.0/24 本来，这个范围和我是在同一个地址下面，现在由于我的子网配置的过大，那么现在，这个段还是跟我在同一个子网下面，所以我和它们之间的通讯丝毫不会收到影响；1.1.0.0/16 下面，不包含 1.1.3.0/24 的部分：本来，这部分不是跟我在同一个子网下面，现在由于我的子网配置过大，导致我认为它们跟我在一个子网下。那么，本来数据应该发往 router，现在由于我错误地认为这些目标和我在同一个子网，所以我现在会直接查询 ARP 表，通过 ARP 查到目的地址然后发出去。这显然是查询不到的，发出去的 ARP 也不会有响应的，故，这些 IP 是一定不可达。比如我的 IP 本来应该是 1.1.3.2/16, 但是错误的配置成了 1.1.3.2/24。
如上，首先，1.1.3.0/24 这个网段，在错误之前和之后都是和我在同一个网段，所以不会收到影响，能够正确路由。
然后下面就是有意思的部分了。
假设现在要发送到的一个目的地址是 1.1.4.3, 正确的话，这应该是和我在同一个子网，但是现在我的子网变小了，我会认为它不和我在同一个网络内，需要经过路由器转发，所以我会将要发给 1.1.4.3 的数据包的目标 MAC 地址设置成路由器，并且发给路由器。
现在又出现了两种情况，第一种比较简单，是路由器的 IP 地址和我也因为错误变成了不同的网段，比如 1.1.2.1, 那么我会直接认为是 Unreachable，ping 失败。
第二种情况比较有意思：如果我因为阴差阳错，即使子网掩码配置小了，但是依然幸运地和路由器处在同一个网络内呢？
上面已经分析过，这个时候我是可以 ping 通路由器的：
那么我能 ping 通 1.1.4.3 这个地址吗？
让我们一步一步分析一下。
按照上面的逻辑，我会把去往 1.1.4.3 的包丢给路由器，对于路由器来说，它遇到了一个奇怪的事情：这个家伙来自 1.1.3.2/16(路由器视角，路由器的子网配置是正确的)，然后要把这个包发送给 1.1.4.3/16, 这不是都在同一个网络 1.1.0.0/16 内吗？发给我干嘛，直接发给它呀！
这时候路由器会怎么做呢？
对于 ICMP 包来说，路由器还是会帮我把这个包转发到目的地址，即路由器通过这个 interface 收到我的包，一看，发现是目的同一个 network，它再从同一个 interface 发出去。
The gateway sends a redirect message to a host in the following situation.
A gateway, G1, receives an internet datagram from a host on a network
to which the gateway is attached. The gateway, G1, checks its routing
table and obtains the address of the next gateway, G2, on the route to
the datagram’s internet destination network, X. If G2 and the host
identified by the internet source address of the datagram are on the same
network, a redirect message is sent to the host. The redirect message
advises the host to send its traffic for network X directly to gateway
G2 as this is a shorter path to the destination. The gateway forwards
the original datagram’s data to its internet destination.
在路由器上抓包，也可以看到它产生的 Redirect message，里面有说，你应该直接去找 1.1.4.3 , 不要再来找我啦！
所以说，ping request 的包是可以发给目的地址的，只不过会多回复给发送这一个错误消息而已。
现在请求到了 ping reply 这边，reply 能成功发回去吗？
按理说前面提到过，对于其他人来说，正常发给我消息是没有问题的。但是这个回复有一个依赖，就是它要知道我的 MAC 地址，要知道我的 MAC 地址，就需要我来告诉它。
那么第二个有意思的问题就来了：如果我收到了一个 ARP 请求，和我不在同一个网段，但是询问的确实是我的 MAC 地址，我会回复吗？
这个是 Linux 配置参数，位置在 /proc/sys/net/ipv4/conf/eth0/arp_ignore 含义如下：
arp_ignore – INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 – (default): reply for any local target IP address, configured
on any interface
1 – reply only if the target IP address is local address
configured on the incoming interface
2 – reply only if the target IP address is local address
configured on the incoming interface and both with the
sender’s IP address are part from same subnet on this interface
3 – do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 – reserved
8 – do not reply for all local addressesThe max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}
因为默认值是 0, 所以是会回复的。通过 tcpdump 在 linux1 上抓包可以确认：
这时候 1.1.4.3 拿到了我的 MAC，就直接在二层把 ping 的 reply 发给我了。
如果在 Linux2 这台机器上，即 1.1.4.3 上，抓包，会发现一个有意思的现象：它从路由器 MAC 收到的 ping 包，回复给了另一个 MAC 地址。
这个奇怪的 ping 链路整体的数据流向如下：
所以说，这种情况下是可以 ping 通的。