Hi，欢迎来到 卡瓦邦噶！我是 laixintao，现在生活在新加坡。我的工作是 SRE，喜欢在终端完成大部分工作，对各种技术都感兴趣。我从 2013 年开始写这个博客，写的内容很广泛，运维的方法论，编程的思考，工作的感悟，除了技术内容之外，还会分享一些读书感想，旅行游记，电影和音乐等。欢迎留下你的评论。
声明：本博客内容仅代表本人观点，和我的雇主无关。本博客承诺不含有 AI 生成的内容，所有内容未加说明均为博主原创，一经发布自动进入公有领域，本人放弃所有权利。转载无需本人同意。但是依然建议在转载的时候留下本博客的链接，因为这里的很多内容在发布之后会还会不断地继续更新和追加内容。
这是 网络断断续续 一文的答案。
对于这种时而正常时而异常的「幽灵问题」，在没有思路的时候，可以通过对比的方法来寻找线索。
有的时候 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 国际 协议。
我们遇到的 Harbor 的另外一个问题是 image 的下载瓶颈。在容灾的时候，我们需要在短时间内启动几万个容器。Harbor 这里就成了瓶颈，抛开所有的数据库和文件系统的瓶颈不说，网络这里就需要 Tib 级别的带宽。这是不现实的。
用户构建的 image 质量参差不齐，大于 10GiB 的 image 比比皆是，尽管这些 image 都有很大的优化空间，但是期望所有的用户都按照构建 image 的最佳实践1进行优化，也是不现实的。
于是问题就成了：如何才能够大量的 worker 节点迅速扩容上万的容器？
此外，在平时，遇到工作日多个系统发布的时候，或者整点的时候运行定时任务（定时任务每次都会下载 image），harbor 的压力也非常大，经常满载运行。如果能解决这个问题，平时的负载问题也可以缓解。
之前介绍过 Spegel 的下载方案2，Spegel 的想法很好，基本思想是，先去其他已经存在这个 image 的机器上去下载，如果找不到，再 fallback 到 Harbor 下载。可惜的是，Spegel 把 P2P 下载和 P2P 服务发现混为一谈了，导致服务发现的性能极低。
什么意思呢？去其他的机器上下载 image，需要的一个信息是：哪一个机器有这个 image？这就是下载源的服务发现。这个服务发现和 P2P 本质上没有什么关系，用什么都可以。P2P 技术解决的是下载上的瓶颈，只有能有一个方法记录每一个机器上现在都有什么 image 就可以，用 Etcd 也可以，不一定也得用 P2P 形式的。
但是 Spegel 这里是用 P2P （libp2p）做的服务发现。在我看来这是完全没有必要的。我们在实际的部署中遇到的问题有：
在实际的部署中，Spegel 的缓存命中率在 25% 左右。
当然，使用 P2P 做服务发现也是有好处的，好处就是部署简单，不需要额外的存储依赖。只不过这个好处和它带来的问题相比就微不足道了。
我觉得如果解决服务发现的问题，使用 P2P 下载的方法，是可以解决资源的瓶颈问题的。
所以设计的方案是：使用中心化的，高性能的服务发现，去中心化的 P2P image 下载。
原本 Spegel 的代码，服务发现层是独立的模块，所以我从 fork 它的代码来添加一个新的服务发现方式开始。但是随着修改，发现问题越来越多，比如 subscribe containerd events 的时候没有正确 defer 关闭，没处理好 containerd 重启的情况，等等，最后开始了一个独立的仓库，叫 Piccolo。代码4依然是开源的，但是还没时间写文档和注释，这篇博客先写一下原理。
项目主要分两部分：
Pi – 安装在每台机器上的 daemonset，负责：
Piccolo Server 是服务发现的源，全局只有一组（几个实例就够用了），提供 3 个接口：
部署之后，97% 的下载请求可以在 Pi 完成而不必请求 Harbor。
从这个监控可以看出，随着 Piccolo 的发布，Harbor 的流量骤降。而且每个小时的峰值流量也几乎没有了。
Pi 部署在每一个机器上，使用的资源也非常少，平均 CPU 用了一个 core 的不到 1%，可以忽略不计。平均内存用了 22M 左右，也可以忽略不计。
Piccolo 为集群提供了大约 8Tib 的下载带宽，没有消耗额外的资源，几乎是免费的 8Tib 带宽。
Piccolo server 方面，性能也很高，一台 8C8G 的 instance 足以支撑 5 万个 Pi （实际的物理机 worker 节点）。秘诀就是注重细节的性能优化。
比如全量同步的资源消耗较大，一起部署的机器会定时发送 keeplive，通过对这些定时执行的 API 加随机偏移，可以保持这些 API 的频率几乎是均匀的，解决了资源的峰值问题。
服务发现的核心，是用一张 MySQL 表，存储了 blob 和 IP 的对应关系。服务发现请求主要是通过这张表的查询完成的。Piccolo 支持把不同的 group（同一个 group 的 Pi 可以互相发现，不同的 group 的 Pi 不可以互相发现。其实这个功能也可以通过部署多个 Piccolo Server 来实现）放到不同的数据库中，加上索引优化（极致的索引优化，所有的查询都是 index-only 的），每一个库 2千万的数据，请求在 200 QPS，耗时在 10ms 以内，已经足够使用了。
Piccolo server 在服务发现接口返回的时候，会根据请求者的 IP 地址，把所有的资源拥有者的 IP，根据和请求者的 IP 相似度（距离）排序，返回。这样 Pi 在下载的时候，会从距离和它最近的邻居开始尝试，这样可以最大程度减少跨网络设备的带宽流量。
所有的 API 接口都有重试和指数时间退让，这样在大规模部署的时候，可以分散一些请求，不至于大家一起失败。
在高可用方面，由于 Piccolo server 是无状态的，所以部署多个实例即可。在预防未知的 bug 上，系统的每一个阶段都是可以降级的：
我和欣都很喜欢看电影，我们一起看了很多电影。我最喜欢的导演是韦斯·安得森，现在最喜欢的电影是《布达佩斯大饭店》，看了很多遍。欣最喜欢的电影是《沙丘》，也看了很多遍。科幻电影是我们共同喜欢的类型。
《布达佩斯大饭店》每一帧都很美，故事性也很强，台词简洁但是话又很多。和其他的电影很不一样，后来我才知道，这属于「艺术电影」的范畴。导演的个人特色太鲜明，有一次我在看《腓尼基计划》，欣看了一眼，就问，「这又是那个怪导演拍的？」
《沙丘》作为老牌科幻，背景世界构建的宏大而又符合逻辑，导演 Denis Villeneuve 实力很强，把这么难拍的电影也拍的像艺术一样。每一帧也都很美。
我们在一起看了很多电影。用过各种各样的设备和方法一起看。
高铁从上海到山东需要 5 个小时，看电影是最好的消磨时间的方法了。问题是，一直没有找到比较好的可以两个人一起看电影的方案。即两个人一起看，但是各自用自己的降噪耳机。
在网上找到了一个 Mac 可以使用的方法1，原理是用 Audio MIDI 创建一个新的输出设备，实际输出的物理设备是 2 个耳机，步骤如下：
- First, on your Mac, go to System Preferences > Bluetooth. Turn it on and pair the two pair of AirPods with your Mac. Now only one pair of AirPods can be connected.
Now open Finder and click on Applications > Utilities > Audio MIDI Setup.- Look for the plus sign and click on it to create multi-output device.
- Check the box next to the two pairs of AirPods and check the Drift Correction box next to the second pair of AirPods.
- Click on System Preference > Sound, followed by Multi-Output Device.
- Once done, the audio of your Mac will be sent to both pairs of AirPods. So this how to connect multiple AirPods to Mac.
有的时候不想拿出来 Mac，或者有时候没有带，就用下面这个万能的办法，不过仅适用于提前下载好的电影：
这样也算一起看了。
近几年大部分时间都是在家里一起看，买过 HBO，Amazon Prime，Disney+，Netflix 等等，在电视上看了不少电视和剧，简单也方便，体验很不错。《克拉克森的农场》，《Severance》，《浴血黑帮》，《大西洋帝国》，《For All Mankind》，等等。
去年买了一个新的电视，型号是三星的 S95F，可能是最近几年买过的最满意的电子产品了，OLED 屏幕非常惊艳，这一款还有一个不反光的特性，白天看也不用拉窗帘。最近又发现一个惊艳的功能。
有天家里有人睡觉了，我戴着耳机在客厅里看电视，欣过来问我，你看电视怎么没有声音？我说用的耳机。欣惊讶到，这电视居然能连接蓝牙耳机。我觉得这是很正常的功能。
于是她拿出来自己的耳机要和我一起看，我说不能连接两个耳机。她说可以，这是正常的功能。
我觉得肯定不行，因为之前用的所有的设备在不 hack 的情况下都不支持同时输出到 2 个蓝牙设备（实际上，iOS 在 2019 年好像就支持 audio share 了）。但是决定还是用事实证明。于是我打开蓝牙，连接上她的耳机。预期是之前连接的我的耳机会断开。结果两个耳机都连接成功。
然后打开声音输出，预期是只能选择一个耳机。结果电视自动弹出来对话框，问是否要切换到 multiconnect 功能？选择「是」之后，两个耳机都完美地有了声音。
后来一想，这个功能确实挺符合直觉并且实用的。现在的问题是，为什么之前那么多设备反而不支持？
最近读了《征服C指针》，是一本好书。日本人写的计算机技术书籍像娓娓道来的技术博客那样，假设读者没有（或者有很少）相关的背景知识，围绕一个主题，除了介绍干巴巴的知识，还会谈自己的经验和理解，对其他的书和论点做点评，指出一些常见的谬误，这样读者可以更容易理解书里讲的东西。如果只有干巴巴的知识，那么去读维基百科就好了。但是维基百科（无论中文还是英文）的说明一般晦涩难懂，因为百科的首要目标是准确，消除歧义，而不是易于理解。而好的技术书里面会旁征博引，运用举例和比喻，用多的篇幅详细说明难懂的部分，加上作者的经验让读者知道哪些内容是经常使用的，哪些是晦涩又不常用的，哪些是可以辅以技巧理解的。这是我理解的优秀的技术书籍。比如，《流畅的 Python》就是这样一本好书，这本书不光介绍 Python 的编程知识，还有对 Python 语言设计的点评，和其他编程语言的对比，作者自己的理解和评价，读完之后对于整个编程概念的理解都会有提升。
这本书其实就不只是 C 语言的指针，还设计内存分配，C 的语法和编译器，CPU 等知识。从初学者到老手都可以从中有所收获。
另外书中对于有些概念可以给出确定的定义，而不是给出模棱两可的答案。如果永远模棱两可，那么永远都不会错，但是这种内容读起来也是浪费时间。一位得高望重的星际2游戏解说曾经说过：「专业解说要敢于下判断。」
以下是一些笔记。每一段引用都是书中的原文，引用如果不是连续的，就来自于不同的段落。非引用的格式是我的评论。
在C语言中，记录指针指向何种类型是只到编译器为止的，到了运行的时候就已经没有相关信息了。在运行时，指针的值就只是单纯的地址而已。“要从这个地址里取出哪种类型的值”这一信息只残留在编译器生成的机器码中。无论是在指针的值中，还是在指针指向的变量的内存空间中，都没有类型的信息。因此，如果把指向int的指针转换成了void*，就不可能再知道它原来是指向 int 的了。
指针的类型，主要是为了告诉编译器信息。
|
1 2 3 4 5 |
int hoge = 5; void *hoge_p; hoge_p = &hoge; <-- 不会报错 printf("%d\n", *hoge_p); /* 输出hoge_p所指向的内容 */ |
会报错如下：
|
1 2 |
warning: dereferencing `void *' pointer error: invalid use of void expression |
只告知了内存上的地址，却没有告知那里保存的是什么类型的数据，当然无法读取。
改成下面这样可以运行：
|
1 |
5: printf("%d\n", *(int*)hoge_p); /* 将hoge_p转换成int */ |
这正是指针运算的特征。在 C 语言中，对指针加1 后，其地址就增加该指针所指向的类型的长度。示例程序中的 hoge_p 是指向 int 的指针，而在我的环境中 int 的长度是 4，所以对地址来说，加 1 就是前进 4 字节，加 3 就是前进 12 字节。
对指针+1，地址移动的单位是「指针所指向的类型的长度」，这个也是编译器计算的，这是指针需要类型的主要原因。
由于空指针可以确保与任何非空指针进行比较都不相等，所以经常作为返回指针的函数发生异常时的返回值使用。
例如我工作的地方位于日本名古屋市某栋大楼的 5 楼，某人爬一层楼需要 10秒，那么从地面上到 5 楼需要花费多少秒？50 秒？很遗憾，正确答案是 40秒。想必大家在中学都学过等差数列，等差数列的第 n 项等于“首项 + 公差× (n –1)”。每个都要减 1，真麻烦……此外，“1900 年代”并不是 19 世纪，它的一大半属于 20 世纪。更加复杂的情况是，2000 年不属于 21 世纪，而属于 20 世纪。这些问题分别可通过以下方式回避。把大楼里与地面等高的那层计作第 0 层把数列的首项计作第 0 项把最初的世纪计作 0 世纪，把公历最初的年份计作 0 年这种“差 1 错误”的问题在编程中经常发生。因此，普遍认为在一般情况下如果以 0 为基准编号，那么通常（并不是所有）能回避这类问题。
延伸阅读：为什么要“包含头不包含尾”？
要点
p[i] 是 *(p + i) 的简便写法。
下标运算符 [] 只有它原本的意义，与数组毫无关系。
要点
【比上面的要点更重要的要点】
但是，千万别写成那样。
在 get_word() 中使用下标运算符访问 buf 的内容，会让人觉得从 main() 传递过来的就是buf 数组。然而，这是个错觉，从 main() 传递过来的说到底只是指向 buf 的初始元素的指针。
函数传递只能传递指针而不能传递数组。即使数组和指针不同，但是在函数传递的时候，数组也会转换为指针，指向数组开头的元素。
在 C 语言中，参数全部都是通过值传递的。
即便是像全局变量那样在函数外部定义的变量，一旦加上 static，其作用域就只限定在当前源文件内。指定为 static 的变量（函数）对于其他源文件是不可见的（函数也是一样的）。
另外，对于函数（非 static 限定）和全局变量，只要名称相同，即便位于不同的源文件中，也会被当作相同的对象处理。
因此，根据操作系统及CPU的不同，需要规定不同的调用方法，这就叫作调用约定（calling convention）。本书中说明的调用方法是在x86系列处理器中被称为cdecl的调用约定。该方法中所有的参数都通过压栈的方式进行传递。
malloc() 会遍历链表，搜寻空块，若该块大小足够，就将其分割出来，做成使用中的块，并向应用程序返回紧邻管理区域的下一个地址。free() 会改写管理区域的标志，将该块置为空块，如果上下有空块，就顺便将它们合并成一个块。这是为了防止块碎片化。 这种操作称为 coalescing。当没有足够大的空块满足 malloc() 的要求时，就向操作系统请求（在 UNIX 中需要通过 brk()系统调用）扩充内存空间。
补充
Valgrind正如前面多次提到的那样，与动态内存分配相关的Bug往往出现在距离它被发现的位置很远的地方，因此调试非常困难。在Linux上可以使用Valgrind工具追踪这类Bug。Valgrind工具用于检测对malloc()分配的内存空间越界读写、忘记free()（内存泄漏）或者对同一块内存空间多次free()这类问题。
如果运气好，标准库 glibc 也可以为我们检测出这个问题。
调用 malloc() 之后必定写上相应的free() 是一种谨慎的编程风格。程序员就应该小心翼翼地将 malloc()和 free() 对应起来。“因为调用了 exit()，所以就没必要free() 了”的想法是不负责任的偷工减料行为，是不良的编程风格。不管怎么说，程序员也是人，人就是这么一种在可能犯错的地方必定会犯错的生物。可是，“必须 free() 派”却偏要大肆宣扬无论如何都要“谨慎地”编码，这种论调其实是于事无补的。
我认为，“谨慎地”编码并没有什么了不起的，那些能够尽可能地回避“麻烦事”的人才是优秀的程序员。在我心中，理想的程序员是下面这样的：在能够安全地偷懒的地方尽可能地偷懒，并且尽可能地依靠工具而不是肉眼来进行检查，但在无论如何都需要人工处理麻烦的事情时，会在心中坚定地起誓“总有一天要将它自动化”。
这是我最喜欢的一段话。Python 的初学者写的代码，会在所有的函数入口都写上 try-catch，称之为防御性编程。我觉得这么做的人肯定会有这样的疑惑：「怎么这么麻烦？」对于这个疑惑，有两类人，一类是认为「这么做一定有道理，作为程序员我们要不辞劳苦地做好工作。」另一类人认为「一定有更方便的方式」。
正如图 2-17 所示，填充有时会被放到结构体的末尾。因为在创建结构体数组时，填充是必要的。在将 sizeof 运算符应用到这样的结构体上时，返回的是包含末尾填充部分大小的长度。将结果和元素个数相乘，就可以获取数组整体的长度。
——有关结构体的对齐
小端与大端到底哪一种更好呢？这个话题经常引起人们的争论，此处就不再深入讨论了。它们各有各的优点。人类在用纸和笔做加法时也会从低位开始相加，所以对 CPU 来说，或许采用小端的方式更轻松一些，而在人类看来，大端的方式或许更容易理解。
C 语言的声明要用英语阅读
我们可以遵循以下步骤解释 C 语言声明。
先看标识符（变量名或函数名）。
从贴近标识符的地方开始，按照如下优先级解释派生类型（指针、数组、函数）：
①用于整合声明的括号；
②表示数组的 []、表示函数的 ()；
③表示指针的 *。
完成对派生类型的解释之后，通过 of、to 或returning 连接句子。添加类型修饰符（位于左侧，比如 int、double）。如果不擅长英语，可以用中文解释。
能正确地阅读 C 指针的声明，函数参数中有关指针的声明，已经 sizeof 中的声明，是读此书最大的收获了。
像这样可以确定长度的类型，在标准中被称为对象类型（object type）。然而，函数类型不是对象类型。C 语言中不存在函数类型的变量，因而我们无法（也没必要）确定其长度。我们说过，数组类型是由若干个派生源类型排列而成的类型。因此，数组类型的总长度为：
派生源类型的长度×数组的元素个数
但是，由于函数类型的长度无法确定，所以也就无法从函数类型派生出数组类型。也就是说，无法创造出“函数的数组”这种类型。但是，可以生成“指向函数的指针”这一类型。只是指向函数类型的指针是不能进行指针运算的，因为我们无法确定指针指向的类型的长度。
当表达式代表的是某处的存储空间时，该表达式就称为左值。与此相对，当表达式仅代表值时，该表达式称为右值。表达式中有时存在左值，有时不存在左值。例如，变量名是左值，而 5 这样的常量、1 +hoge 这样使用运算符的表达式就不是左值。
当作为 sizeof 运算符的操作数时
在以“sizeof 表达式”的形式使用 sizeof 运算符时，由于这里的操作数是表达式，所以即使是对数组使用 sizeof，数组也会被解读为指针，从而只能获取指针的长度——或许有人是这样认为的，但其实在数组作为 sizeof 运算符的操作数的情况下，将数组解读为指针这一规则是无效的，在这种情况下返回的是数组整体的长度。
总之，关于指向函数的指针的 C 语言的语法是比较混乱的。造成这种混乱的罪魁祸首就是“函数在表达式中会被解读为指向函数的指针”这一意图不明（难不成是为了与数组保持一致？）的规则。
在表达式中，数组会被解读为指向该数组初始元素的指针，因此代码可以写成下面这样。
|
1 2 3 |
int *p; int array[10]; p = array; <-- 将指向array[0]的指针赋给p |
但是，反过来写成下面这样就不行。array = p;
数组和指针截然不同。
“不要误会我对 goto 语句持有任何教条主义的执念。我只是担忧，很多人把这件事给神化了，甚至认为仅凭某个编程技巧或某个简单的编程原则，就能解决编程语言的概念问题！”