Hi，欢迎来到 卡瓦邦噶！我是 laixintao，现在生活在新加坡。我的工作是 SRE，喜欢在终端完成大部分工作，对各种技术都感兴趣。我从 2013 年开始写这个博客，写的内容很广泛，运维的方法论，编程的思考，工作的感悟，除了技术内容之外，还会分享一些读书感想，旅行游记，电影和音乐等。欢迎留下你的评论。
声明：本博客内容仅代表本人观点，和我的雇主无关。本博客承诺不含有 AI 生成的内容，所有内容未加说明均为博主原创，一经发布自动进入公有领域，本人放弃所有权利。转载无需本人同意。但是依然建议在转载的时候留下本博客的链接，因为这里的很多内容在发布之后会还会不断地继续更新和追加内容。
答案是 MTU 设置错误1，链路可以发送的最大 MTU 小于 1500 bytes，但是客户端侧配置的 MTU 却是 1500 bytes。所以 TCP 连接建立之后的包，无法到达另一端。在等待 3.5s 左右，发送端觉得链路存在问题，尝试降低发出的包的大小，这时候就可以发过去了，链路上才开始数据传输。
要定位这个问题，我们现在抓包文件中，找到传输数据最多的那个 TCP flow，就是传输数据最多的那个。这个连接是我们重点研究的对象。右键选择 Follow > TCP Stream，来只展示这一个会话。（如何追踪某一个 TCP 流，在前面 重新认识 TCP 的握手和挥手2 中也介绍过）。
TCP connection 建立之后，客户端一下发了 10 个包，大小都为 1500 bytes。但是服务端一个都没有 ACK。
然后客户端开始重传。
前 3 次重传分别发生在 0.3s, 0.8s, 1.7s，也都没有收到 ACK。
第 4 次重传发生在 3.5s 这个包不再以 1500 bytes 发送了，而是 1076 bytes (TCP 层是 1024 bytes) 发送。这个包得到了服务端的 ACK。
于是客户端知道，1076 bytes 的包可以被服务端收到，所以后续都用 1076 bytes 作为 MTU 发送。过一段时间之后尝试更大的包，1288 bytes，1394 bytes，发现也没有被 drop，就继续 probe 并且增大 MTU，最后用 1399 bytes，接近链路的真实 MTU （实际链路 MTU 是 1400 bytes）。
这就是每一个连接都会卡 3.5s 的原因。
为什么要重传 3 次才开始降低 MTU 呢？
这是通过 tcp_retries1 设置的。man 是这么说的：
The number of times TCP will attempt to retransmit a packet on an established connection normally, without the extra effort of getting the network layers involved. Once we exceed this number of retransmits, we first have the network layer update the route if possible before each new retransmit. The default is the RFC specified minimum of 3.
即 TCP 会尝试 tcp_retries1 次数的重传，而不涉及 IP (network) layer.
如果超过了 tcp_retries1 还没有重传成功的话，（默认第 4 次）就会认为链路存在异常了，需要 IP 层接入，比如开始 mtu probe 尝试解决问题。
如果设置为 1，那么在卡的时间就会降低到 1s 左右。（当然，最好的解决方式还是设置正确的 MTU）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
# sysctl -w net.ipv4.tcp_retries1=1 net.ipv4.tcp_retries1 = 1 # iperf3 -c 10.0.2.2 -b 10M Connecting to host 10.0.2.2, port 5201 [ 5] local 10.0.1.2 port 54580 connected to 10.0.2.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes [ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 22 15.7 KBytes [ 5] 2.00-3.00 sec 3.50 MBytes 29.4 Mbits/sec 2 150 KBytes [ 5] 3.00-4.00 sec 1.25 MBytes 10.5 Mbits/sec 0 200 KBytes [ 5] 4.00-5.00 sec 1.12 MBytes 9.44 Mbits/sec 0 200 KBytes [ 5] 5.00-6.00 sec 1.25 MBytes 10.5 Mbits/sec 0 200 KBytes [ 5] 6.00-7.00 sec 1.12 MBytes 9.44 Mbits/sec 0 200 KBytes [ 5] 7.00-8.00 sec 1.25 MBytes 10.5 Mbits/sec 0 200 KBytes [ 5] 8.00-9.00 sec 1.12 MBytes 9.44 Mbits/sec 0 200 KBytes [ 5] 9.00-10.00 sec 1.25 MBytes 10.5 Mbits/sec 0 200 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 12.0 MBytes 10.1 Mbits/sec 26 sender [ 5] 0.00-10.02 sec 12.0 MBytes 10.0 Mbits/sec receiver iperf Done. |
而根据 TCP 的重传时间，大概就是在 3.5s 左右了。
前面说，第 4 次重传的包是从 1076 bytes 开始发送，为什么是这个数字呢？
这个是 sysctl 参数 net.ipv4.tcp_base_mss = 1024 控制的。TCP payload 是 1024 bytes，加上 TCP 的 header，就是 1076 bytes 了。
如果读者尝试复现这个例子，会发现在 MTU 设置错误的情况下，会一直卡住。这是因为 MTU 出现问题的时候，默认的工作机制是靠 ICMP 消息 “Fragmentation Needed” (Type 3, Code 4 in IPv4) 来提示需要降低 MTU 的。但是现实情况中，这个 ICMP 一般是收不到的（因为各种设备为了所谓的「安全问题」丢弃了 ICMP），这样就会出现 blackhole，一直重试缺卡在这里。默认情况下，MTU 错误的设置地大了，是会一直卡住的。
但是可以通过 sysctl 参数设置 net.ipv4.tcp_mtu_probing，默认是 0，即不用 probe。
如果是 1 的话，在出现 blackhole 的时候就会尝试降低 segment 的大小看能不能通。即本文中的情况。
如果是 2，是一直启用，即 TCP 不管对方说的 MSS，发送的时候总是从一个小的 MSS 开始发，如果没有问题，再逐渐加大。
MTU 常见的原因，以及一些其他的相关讨论，可以参考下面列出来的 有关 MTU 和 MSS 的一切 一文。
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
一天工作日，你拿着刚买的咖啡来到了办公室，准备开始做计划好的工作，度过本该是平平无奇的一天，直到——一位用户发过来消息说他们有新的机器上线之后，所有的 TCP 连接都自带3.5s左右的延迟！他们的服务在使用新的服务器之后，延迟都上升了 3.5s！
经过他们自己的 debug，他们发现，延迟增加之后，在 TCP 连接建立之后，有3.5s 的时间没有发送数据，之后，网络就正常了！然后我们知道，不光服务器是新的，机架，网络设备，都是新的。这批服务器本不该你来负责，但是这个现象也太怪了！所有人都知道你是公司里的网络专家，如果有有解决不了的网络问题，就会来找你。
你让用户用 iperf 测试一下带宽1，用户测试了一下，结果如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ iperf3 -c 10.0.2.2 -b 10M Connecting to host 10.0.2.2, port 5201 [ 5] local 10.0.1.2 port 45026 connected to 10.0.2.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 5] 3.00-4.00 sec 384 KBytes 3.15 Mbits/sec 24 22.4 KBytes [ 5] 4.00-5.00 sec 5.12 MBytes 43.0 Mbits/sec 0 221 KBytes [ 5] 5.00-6.00 sec 1.75 MBytes 14.7 Mbits/sec 0 328 KBytes [ 5] 6.00-7.00 sec 1.12 MBytes 9.44 Mbits/sec 0 328 KBytes [ 5] 7.00-8.00 sec 1.25 MBytes 10.5 Mbits/sec 0 328 KBytes [ 5] 8.00-9.00 sec 1.12 MBytes 9.44 Mbits/sec 0 328 KBytes [ 5] 9.00-10.00 sec 1.25 MBytes 10.5 Mbits/sec 0 328 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 12.0 MBytes 10.1 Mbits/sec 27 sender [ 5] 0.00-10.02 sec 12.0 MBytes 10.0 Mbits/sec receiver iperf Done. |
还真是和用户说的一样！
这必须要抓包一下才知道原因了！用户又做了一次 iperf，并且同时执行 tcpdump 进行抓包，过一会儿，就发来了抓包文件。
你看了一会，然后马上就发现了不对劲的地方……
请分析这个抓包文件，找出固定3.5s延迟的问题在哪里。
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
在网络抓包系列的最后，再来说一下网络学习的一些经验。毕竟，能通过抓包来解决问题的前提是具备网络协议的知识，不然的话 Wireshark 和 tcpdump 用得再熟练也看不懂抓到的包。
以下是我觉得一些比较好的学习方法，我从中获益良多。
学到了一个新的知识点或者新的协议，可以尝试解释给朋友或者同事听。比如在吃饭的时候，「嘿，你知道吗？TCP 三次握手的第三个包实际上是可以携带数据的！」然后他们会想这个问题，问你「要是有些 Server 不能处理带数据的第三个包怎么办？」这样，你就要重新思考你学的知识，看它是否考虑周全。教是最好的学习方法。如果没有朋友的话，可以考虑写一个博客（像我一样？呵呵）。
认识实际的网络，也可以从公司的网络结构开始。平时总结一下自己的问题，多阅读一些内部的文档。在内部 traceroute 跑一下，看看每一个 hop 都是什么。找时间请网络团队的同事吃饭，然后问他们你的问题。
要学会提问。网络协议的目的一部分是传输数据，更重要的，它需要处理各种异常情况，保证即使出现各种意外，也能尽最大努力工作。所以，我们在学习的时候可以经常问题自己：如果这时候出现 xx 会怎么样呢？
问自己问题，然后思考，尝试给自己解答。在思考的过程中，会产生很多解决方案，大部分可能都是有问题的，然后找到其中的问题，推翻自己的方案。比如，网络为什么要分开三层和二层？这个世界上只有 IP 层，没有链路层行不行？或者只有链路层，不要 IP 层了行不行，整个世界都是一个「大二层」，会有什么问题？
网络相关的知识常常是零碎散乱。我的经验是，不要一开始就跳到兔子洞里面去。面对一个新的概念的时候，可以这样来入门。举个例子说，比如 SOCKS5 协议：
其实我觉得，网络协议的设计在最开始的时候考虑并没有很周全，比如 TCP 的一些问题，HOL Blocking；比如 OSPF 协议的奇怪名字 NSSA 之类的。感觉是设计出来之后，然后发现在现实中会有问题，就会在给原来的东西打上补丁。
很多网络协议设计的是很美的，我喜欢那些简单又能解决问题的协议。比如 VRRP，只有一种数据格式包。像 TCP，DHCP 这种就复杂许多，它们的魅力在于解决了复杂的问题，适应各种复杂的环境。
了解网络协议除了按照上面的方法自己来挑战设计，还可以格物致知，看协议的每一个字段，搞清楚这些字段都在解决什么问题。一般每一个字段都是为了解决某种问题或需求而存在的。
面对复杂的协议的时候，把它拆成一个一个小的部分，单独攻破。比如 BGP，状态，选路之类的太复杂了。方法就是 break down，一个一个来。
光学习 Wireshark 这种工具是不行的，工具是围绕网络协议设计出来的，网络协议设计出来是为了解决真实的问题的。所以学习网络协议，它们解决问题的方法，才是主要的。另外，只有懂网络协议才能用好工具。比如，精通 ICMP 和 IP 的 TTL 设计，才能精通 traceroute 的使用。
像 TCP 的书从协议设计到实现，有数不清的书来介绍。读一本是不够的，因为对于网络协议，不同的作者有不同的理解，有不同的比喻。读书就像和作者聊天一样，和不同的人探讨自己对一个东西的认识，有助于加深理解。
上面通过自己设计协议来理解协议的方式，就是 Computer Networking: A Top-Down Approach2 这本书作者用的，作者用从零开始设计 TCP 的方式来教授为什么 TCP 是今天这个样子的。
同一本书也可以读第二遍，所谓书读百遍，其义自见。
如果一个视频明显是那种中国大学的讲课录屏，基本就没有必要看了。这些视频通常知识和现实脱节，讲的内容很多也在现实中见不到，照本宣科，避重就轻。除了磨灭读者的兴趣，把有趣变成枯燥，就没什么价值了。没有兴趣和热情，就学不好。
说到最后，兴趣是最好的老师，对我来说，根据自己的知识和工具拨开迷雾，解决一个一个的问题，是再有意思不过的了。每个人会在人生的一个时间，发现这个世界不是公平的。但是在计算机的世界里，是很公平的，多花一点时间，多思考一些，就会多一分收获，它与天分无关。技术会过时，自己辛苦习得的技能也可能被 AI 轻而易举取代，但是曾经在学习和进步中体会到的乐趣是真实存在的，那些经验运用到新的技术中也多少是有所帮助的。祝愿读者在自己的领域体会到平静和乐趣。
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
这是 网络断断续续 一文的答案。
答案是，在同一个子网内，同一个 IP 地址分配到了 2 个不同的设备上。
对于这种时而正常时而异常的「幽灵问题」，在没有思路的时候，可以通过对比的方法来寻找线索。
有的时候 TCP 能够连通，有的时候无法连通。那么正常的 TCP SYN 包和异常的 TCP 包之间肯定是有什么字段是不一样的。当然，也有可能 SYN 包一模一样，问题出在了其他的网络设备上或者 TCP 的另一端。但是既然题目出给读者了，那么问题的根源肯定是隐藏在抓包文件里面。
正常的 TCP 连接可以完成 TCP 的握手和挥手。
异常的 TCP 连接，发出去的 SYN 直接收到了 RST。
通过对比可以发现，两个 SYN 包的 Dst MAC 是不一样的。
如果不通过对比的方法，顺藤摸瓜，可以用下面的思路。
首先，Src IP 和 Dst IP 分别是 10.210.151.187 和 10.210.151.90，很大概率是属于同一个 /24 子网的 IP，不过要想确认的话需要看下服务器的 IP 地址是如何配置的，子网掩码是不是 /24，这点我们从给出的信息无从得知。
假设确实是属于同一个子网，那么 TCP SYN 包不经过网关，直接发给目的地址，二层的 Dst MAC 地址应该是目的 IP 的 MAC 地址。
假设不属于同一个子网，那么 TCP SYN 包经过网关，TCP SYN 包的目的地址应该是路由器的 MAC 地址。
无论是那种情况，正常情况下发送给同一个 Dst IP 的目的 MAC 应该是唯一且稳定的。通过 Conversation 统计可以看出，通讯的 IP 对只有一对，但是 MAC 的确有 2 对，这是不对的。
造成这种现象的原因是，IP 分配重复了，在同一个子网内，同一个 IP 地址 10.210.151.90 被分配给了多个机器。
发送 TCP 包之前，需要知道对应的 Dst IP 地址的 Dst MAC 地址，怎么知道呢？Src 机器会在整个子网内广播 ARP 询问，持有这个 IP 的机器会回复 ARP。现在子网内有两个相同的机器是相同的 IP 地址。这两台机器的 IP 地址一样，MAC 地址不一样。如果我们现在 arping 10.210.151.90 ，会得到如下的回复：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ arping -c 3 10.210.151.90 ARPING 10.210.151.90 42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=0 time=944.055 usec 42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=1 time=997.915 usec 42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=2 time=13.799 usec 42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=3 time=109.388 usec 42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=4 time=6.670 usec 42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=5 time=48.983 usec --- 10.210.151.90 statistics --- 3 packets transmitted, 6 packets received, 0% unanswered (3 extra) rtt min/avg/max/std-dev = 0.007/0.353/0.998/0.438 ms |
可以看到，我们发出去 3 个询问，却收到 6 个回复。说明每一个询问得到了 2 个答案。（其实，在诊断和验证这个问题的过程中，最快的方式就是用 arping 来测试一下，而不是抓包来分析。但是这里我们主要讨论抓包技术，所以拿来当作一个分析的案例。）
那么 Src 收到两个 ARP 应答，会以哪一个为准呢？答案是以先收到的为准。
|
1 2 |
$ ip nei show 10.210.151.90 dev h2-eth0 lladdr 5a:65:98:0c:82:02 REACHABLE |
但是 ARP 请求广播出去，这两个 ARP 应答哪一个先到是无法确定的，有的时候 5a:65:98:0c:82:02 先到，有的时候 c2:10:70:f2:ae:ab 先到，所以发送给 10.210.151.90 的包，有的时候发给了 MAC 地址为 5a:65:98:0c:82:02 的机器，有的时候发送给了 MAC 地址为 c2:10:70:f2:ae:ab 的机器。
补充一点，在实际的问题排查过程中，我们的 TCP 连接测试失败，最好的排查方法就是去对端进行抓包，看一下对端的机器是否收到了 SYN 包。以及在实际的现象中，客户端收到了 Connection refused ，通常意味着收到了 RST 报文（可能来自真实对端，也可能来自其他设备）。我们在对端抓包的过程中会发现即没有收到 SYN，也没有发出 RST，这说明包到别的地方去了。进而，我们可以发现字网内还有一个「李鬼」的问题。
那么，为什么 ping 的测试完全正常呢？
因为 ICMP 是无连接协议，，ping 的 ICMP 协议回复，是由 Kernel 负责的，所以无论 ICMP 包发送到哪一个机器上，由于它们都设置了这个 IP 地址，所以都可以做出回复。其实抓包中的回复是来自不同的机器，只不过 ping 不知道，只要是收到了回复，就认为一切正常。
最后一个问题，为什么会有 IP 重复的问题呢？
DHCP 可以用来动态分配 IP 地址给设备，但是一般只用于客户端，比如办公网、家用网络中的终端设备，这些设备一般作为连接的发起方，不需要 listen 一个固定的 IP 地址，IP 地址的动态变化对它们影响不大。但是在 IDC 的网络中，每一个服务器的软件都需要固定的 IP 地址，一般不用 DHCP 来动态分配，而是用中心化的 IPAM 系统1追踪 IP 地址的分配情况。如果里面记录的地址不正确，比如，一个地址已经在使用中了，但是并没有在 IPAM 记录，就造成 IP 地址重复的问题。
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
各位读者新年好呀～ 最近比较忙，博客快要长草了。今天我们再来看一个实际的网络问题。
症状如下：
在一次服务扩容的时候，新扩容的虚拟机网络断断续续，它的 TCP 服务时而能连上，时而连不上。新扩容出来的虚拟机的 IP 地址是：10.210.151.90。
|
1 2 3 4 5 6 |
$ nc -vz 10.210.151.90 9999 nc: connect to 10.210.151.90 port 9999 (tcp) failed: Connection refused $ nc -vz 10.210.151.90 9999 nc: connect to 10.210.151.90 port 9999 (tcp) failed: Connection refused $ nc -vz 10.210.151.90 9999 Connection to 10.210.151.90 9999 port [tcp/*] succeeded! |
于是我们联系了虚拟机团队的负责人小马，小马一听说虚拟机的网络有问题，上来就是一顿 ping，结果呢，一个包都没丢。「网络肯定没问题，一定是你们自己服务的问题啦。」小马说。
「可是我们用这台虚拟机部署的服务确实不能用啊！」业务的同事可怜巴巴地说。却也没办法说服小马继续排查网络问题了。小马说：
When a problem is yours, own it. When a problem isn’t yours, prove it.
这时，业务团队里面正好有一个精通网络分析的同事（就是你！），这位网络大神随便找了一台机器，一边去用 ping 和 nc 做 TCP 连接测试，一边 tcpdump，得到下面的抓包文件。
网络大神把这个抓包文件下载到本地，分析起来，不一会儿，就得出了结论……
请分析这个抓包文件，回答：为什么 TCP 连接时而成功时而失败？
这篇文章是抓包破案录系列文章（之前叫做《计算机网络实用技术》，后来改名了）中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网络抓包与分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
如果您正在阅读的是题目类的文章，这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停，进行思考，继续向下滑动，可能会被其他的读者剧透答案。
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。