回顾 2023 年，许多在 2022 年设定的目标都未能实现，包括深入学习 Kubernetes 和掌握 Rust 等。在五月、六月以及秋招后至实习入职期间，感觉自己有些散漫，代码能力也没有显著提升。

幸运的是，我在三月份成功找到了实习机会，度过了五个月的杭漂生活。尽管在后续的秋招中遇到了一些波折，但也有不少收获。整个一年中，我经历了许多事情，走过了许多未曾到过的地方，还有幸与许多素未谋面但一直保持联系的网友线下见面。总体来说，过得还算不错。

我在去年十一月初踏上了求职的征程，第一场面试虽以失败告终，但至少迈出了第一步。到了十二月份，陆续参加了几轮其他小公司的面试，然而最终都未能通过终面。反思的过程中，我逐渐找出了问题所在。在面试中，我发现之前自己琢磨的源码设计难以清晰地表达出来，这引起了我对自身一贯弱点的认识：输出能力较差。在去年的年度总结中，我也提到总结是我的短板。曾经，我未养成在学习时同时输出的习惯，导致很多知识在仔细学过后就随着时间而逐渐遗忘。今年我也在努力改进这方面，但实际上成效并不显著，因为反馈不够明显。直到提前实习期间，在组内做了一次技术分享，并与导师进行了一对一的交流后才恍然大悟。原来技术分享并不一定要非常高深，关键是能够清晰地讲解一个概念，让没有接触过这部分知识的听众也能理解你所分享的内容。在 2023 年的最后一周，我进行了一次新人业务串讲，因为领悟了分享的核心，也提前做足了准备，这次的分享异常顺利，尽管听众都是组里的熟人，但至少没有再磕磕绊绊，没有不知道怎么去表达。

实习&杭漂：走走停停

二月末，我侥幸地收到了杭州城西一家小公司的 offer。当时想着实习六个月到秋招正好是九月份，现在才开始实习好像已经有点赶了，因此就接了去了，也没有再参与接下来的春招实习。回想起来，深感后悔，若当初不那么着急做决定，也许未来的可能性更为广阔。

来之前在脉脉上看到对这家公司的差评很多，但想到脉脉上即便是狗路过也难免被骂两句，于是借此安慰自己。实习的这段日子总的来说并不好受，一方面是资金有限的压力，租房 1450 只能合租到 7 平左右的单间，外卖一顿基本要二三十元，再加上中后期要来回学校参加考试，而作为实习生一个月的工资只有这么微薄，压力显得相当巨大。幸好有豪哥和超哥的支持和鼓励，我才得以挺过来。另一方面，我对实习的内容不太满意，公司整体氛围也不尽如人意。由于公司产品力不足，盈利状况不佳，同事们都承受着巨大的压力。前几天得知我所在的部门已经被遣散，希望曾经的同事们都能够找到更好的去处。

刚入职的那段时间感觉还是比较轻松，但是对实习生的培养几乎没有，我完全找不到自己的主线，也不清楚具体的工作内容。在入职的第一周，我产出了两个 CRUD 的接口，很多代码基本上是照搬的，缺乏实质性的技术力。随后，导师安排了一个接入多云服务商短信的重构需求，我很快就完成了代码编写，也进行了多次自我审查。然而，当请导师进行 code review 时，却硬生生地拖延了一两周，导致我只能在这段时间里自己查看文档和代码进行自学。那时我一直在思考公司为何招聘我这个实习生，既不培养我作为校招苗子，也不是脉脉上所说的招来当短期工抗压 007，这种困惑一直延续到大概六月份。现在回想起来，当时确实有些内耗。

大约在六月初，负责带我的导师和 leader 被调到 AIGC 的部门，由隔壁的 leader 接替带领我所在的部门，而我则被完全放养。正值那段时间接到一个重大需求，同时又到了期末考试月，需要频繁硬卧绿皮往返学校，压力随之而来。当时由于导师被调走导致再也没有人给我派活，于是我尝试向隔壁 leader 要一些活。可能是因为组里人都很忙，也可能是因为隔壁 leader 对我比较信任，于是这个风险较大的大需求就交给了我。我还记得当时隔壁的 leader 问我：“你能当 POC 吗？”，我愣住了，当时我还不知道 POC 是个什么概念，差点答应下来。后来才得知，让一个实习生来担任这种重大需求的 POC，这个风险极大的决定，或许表明当时隔壁 leader 在管理上存在一些问题。

随着大需求的顺利上线，那段充满压力的时光也随之过去，我又回到了放养内耗的时期。在杭州时虽然资金有限，但我还是穷游了一些地方：关于我的三个月杭漂。紧接着陆陆续续有一些应届校招生入职，更没有新的需求分配到我的工作中。直到离职前与隔壁 leader 聊天，我才了解到应届校招生需要更多需求来确保绩效能够挺过试用期。怀揣着实习时的遗憾和不甘，我决定辞去工作，回家准备秋招。

秋招：沉下心，沉住气

辞职回家后，待了将近两周时间，边投简历边笔试，努力调整了自己的状态，恢复了一些元气。九月初回到学校后，我再次开始了面试准备。那段时间其实挺爽的，杭漂五个月后，我愈发珍惜与舍友相处的时光，享受低消费的校园生活，那时候也接触了开源，我也有更充足的时间去追求自己感兴趣的方向。

整个秋招持续了大概三个月，从七月末到十月末，从既期盼又害怕面试的到来，到死猪不怕开水烫狠狠海面。整个人感觉成熟了不少，对自身技术栈、实习产出和项目细节的掌握都更进了一步，更重要的是面试官会充当我的听众，以此来锻炼我的沟通能力。那时候正当牛客小论文流行，感觉非常有意思，就偷了不少发在朋友圈，和认识的一群水友评论区互动，太有意思了。

实际上，很多人的秋招最终都能够取得不差的结果。前期的抱怨很可能只是因为投递较少、面试机会有限所致。当然，如果面试机会明显不足，可能需要反思自身竞争力是否有待提升，或者所在技术方向的竞争程度较高。此外，努力仍然是至关重要的，整个秋招的关键在于保持沉着冷静的心态，走得慢并不要紧，重要的是要坚持奋斗，每个人的求职进程都有快有慢，找到适合自己的节奏才是最终取得成功的关键。

北漂：进京见世面

北漂了一个月，游览了圆明园、天安门广场、北京动物园和颐和园，还亲眼目睹了北京的初雪，体验到了人生第一场大雪。来北京之前，我无论如何都难以想象“道路结冰”是怎样的场景，也无法体会零下十六度是怎样的寒冷。幸好在北京有暖气，在屋里待着甚至只需穿短袖，在暖气的加持下，室内的温暖相比南方大冬天的时候更为宜人。

在这段时间里，我领略了初雪的美丽，也感受到了北方寒冷的严寒。尽管天气寒冷，但身处温暖的室内，感觉舒适宜人。我还有许多未探索的地方，计划明年再次踏上探险之旅，继续发现这座城市的魅力。

由于在技术方向上，以往一直专注于基础架构开发，除了实验室项目外，对业务接触相对较少。而我秋招加入的部门正好是业务方向，因此体验了一波技术到业务的转型。入职一个月以来，小组的氛围非常好，同事们都很实在，组里专门为校招生制定了培养计划，组长和导师也会定期进行一对一的指导，矫正方向并解答疑惑。上手业务开发是一个循序渐进的过程。在入职至今，我已经做了一次技术分享和一次业务串讲，对我个人的正向反馈也很大。总体来说，我的实习生活过得非常舒适。

技术

github 来看中后段（秋招开始后）基本摆了，然后前面也很多是私人 repo，包括学习 Rust 和几个 demo，参与的一些活动的代码等等。

要是拼上 leetcode 的话就差不多了，虽然我刷题也不多。我的 leetcode 从去年十月刷起，全勤大概六个月，然后入职实习后就基本没有再坚持了，直到八月离职参与秋招，又恢复训练了两个月，后面也没再坚持。其实我认为刷题的 ROI 并不高，只要够用就可以了。刷题太多容易产生逃避心理，但在面试中展示代码能力和思维能力还是相当重要的。对于明年，我计划会随缘地继续刷刷，保持一定的状态。

2024 年，我希望延续今年年初立下的 flag，深入学习 Kubernetes 和 Rust，并探索更多业务设计的实践，争取将脑中诸多的想法落地，争取多做技术分享，争取多为开源做贡献。

输出

今年写了包括杂谈的十四篇文章，时间上主要集中在年初和七八月份，内容上主要包括 Golang 常用标准包的解析、一致性知识、容器和网络协议。基本上都是“一文了解”系列，起这个系列的初衷是希望写一些不像网络上同标题大部分文章这么水的技术文章，所以内容上多少会有一些深入，希望不了解/听说过的人在阅读完后能到稍微深入了解这样的程度。emmm 事实上可能也没达到我想要的效果，但也希望读者能多少有些收获。

第一篇是《一文了解事务》，可以说是《DDIA》第七章的阅读笔记，也在学校团队里给师弟分享了一下，但是一讲就讲了很久，以至于讲着讲着都不知道讲到哪里了，反正效果很差。那之后就想着需要更精炼的语言，更简洁的方式去表达我想要表达的东西，于是后续的文章都会有一部分的总结部分，而且文章的模块划分会比较明显。

除了写了几篇技术文章，今年还对去年写过的一些文章进行了重构，包括修复 typo、润色文段、矫正过去的一些错误和加入自己学习过程中的感悟。明年的话，希望能写更多技术文章，兼顾数量和质量，希望能多点画图，减少笔记形式的记录，多转换为技术分享形式。今年后半段属实有点摆了 haha，第一段小厂实习有一段时间干着还挺累人的，那之后也懈怠了不少。

接触开源

契机是学校团队内部使用的就是 Gitea，遇到了一些较于其他代码库稍有不足的地方，刚好和师兄一拍即合，找了一个 issue 就开干，也成就了第一次给 Gitea 贡献代码的经历。非常感谢师兄的鼓励，感谢 lunny 和其他社区伙伴对我拙劣代码能力的包容~ New webhook trigger for receiving Pull Request review requests by Makonike · Pull Request #24481

其后也给 Gitea 提了几个关于 Webhook 的 PR，希望明年也能继续为 Gitea 贡献更多的代码。

下一个接触开源的机会是中科院开源之夏 OSPP，实际上，我个人对这个活动并不太感兴趣。去年我也投递了几个项目，但邮件发出去之后就再也没有收到回应。即使我尝试补发了几封邮件，也没有得到任何回应。更糟糕的是，某些社区以贡献 PR 的数量为 rank score，建立了一个排行榜赛马。基本上，该社区的项目都被排行榜上前列的人包揽了。如果你在排行榜上稍后一些，甚至都没有机会被选中参与这个项目。

尽管对这个活动有所失望，但今年还是借接触开源的机会投了两个项目，一个是傲空间社区的 Golang SDK 开发，另一个是 MOSN 社区基于 MoE 框架为 Envoy 集成 LDAP 认证。刚好那时候五六月份，我在实习时接触了 LDAP 相关的需求，也去了解了一波 LDAP 协议，也很幸运地中选了这个项目，感谢豆浆老师对我的指导和帮助。在我发出邮件后的几天后，两者都发来了邮件回复，我也为傲空间的项目写了一个小的 demo，以及一份相对简单的项目申请书，可惜后来没有中选这个项目。豆浆老师发来的邮件就有些特别，我选择的这个项目因为名额的问题不算入 OSPP 活动中，这意味着即使完成了这个项目，也没法得到 OSPP 的证书和奖金。当时来看，这份奖金额度对我来说还是相当可观的。

我个人对开源还是保持积极的态度，特别是看了豆浆老师的博文（我与开源的缘分），更是深感认同。他提到的“人人为我，我为人人”，以及分享精神，我认为正是开源精神的核心所在。参与开源项目的人，应该怀揣着助人为乐的精神，而非只追求个人狭利。这是一种开放的协作方式，参与者通常是自愿加入，怀着分享互助的心态共同参与项目的建设。

这种协作方式不仅能够对抗内卷，还能显著提高整个社会的生产效率。至今，我仍然坚守这一观点。尽管我知晓，开源稀缺性的技术会让自己失去核心竞争力，甚至失去赖以生存的基石，那又怎样呢？开源某种程度上确实促进了技术的增长，也为许多人提供了帮助，而我个人，正是乐于分享、乐于助人的信仰者。

阅读

今年对于文学和技术的输入都比去年要少，技术上主要补了年初买的幼麟实验室的《深度探索 Go 语言》和周志明老师的《凤凰架构》。这两本都是很好的书籍，弥补了我对 Go runtime 和技术架构设计的认知缺陷。希望明年能更多输入一些技术书籍。

文学方面最喜欢的还是最近看的《大明王朝 1566》，这是一本非常好看的历史小说，通俗易懂，即使对历史认知不多也能看进去，整本书读下来畅意淋漓，人物形象设计非常经典，看的时候可以让人完全沉浸在故事中。

《生死疲劳》书里除了垃圾话比较多以外，六世轮回的故事还是挺有趣的。但我还是觉得太累了，人活一世足矣。

《道诡异仙》是近两年看过最好看的一本网络小说，脑洞很大，估计很难再看到如此天马行空的小说了。

近来，读书无用论者的言论屡见不鲜，这让我深感反思自己读书的目的。一方面，我进行的是应试教育式的读书，简言之，是为了追求升学的目标，为未来争取更多选择。这看似合理，但未来的走向谁又能确切预测呢？就像那些宣扬“量产大学生进厂打螺丝”的读书无用论者所言，学历的价值一直在贬值。然而，他们却忽略了那些未受过教育或学历较低者的实际情况，忽视了“28 定律”无处不在。对于大多数人来说，学历只是你曾学过的证明，究竟学了什么其实并不那么重要。

另一方面，我也沉浸在兴趣驱使的读书中。前几年，我每年能读二三十本书，然而如今许多书的内容早已消逝于记忆之中，留下的只是当初写下的几句批注和几篇读后感。我清楚地认识到，阅读闲书只是我打发时间的一种方式。即便看了一些书，获取了一些知识，拓展了一些见识，也并没有让我突然醒悟，人生变得一片坦途。如果阅读真的能如此简单地让人迅速觉悟，那么为什么我还在原地徘徊呢？如果这种路径如此轻松，早就被前人走烂了才对。

音乐

用的听歌软件依旧是网易云音乐，他家的年度总结挺有意思的。今年也是喜欢凯瑟喵的一年，我在第一段实习离职前抓住机会去了线下 Live，第一次线下见她，感觉真的好可爱啊，她是我不能忘怀的青春里不可或缺的存在，明年和明年的明年也会一直喜欢她。

今年尤其钟意粤语歌和说唱，冯泳是今年发现的宝藏歌手，【风中余烬】、【海风】的词和 hook 都很戳我。

设备

今年忙于实习和秋招，资金链也异常紧张，所以设备上没啥变动。七月份我为心爱的键盘换上了一套可爱的玉桂狗键帽，秋招后朋友送了一个 XBOX 手柄和 XSS 主机，感谢朋友的慷慨。

动画片与电影

动画片今年基本没看了吧，我没啥印象。电影倒是看了几部。

《铃芽之旅》感觉不好看，女主也太恋爱脑了= =，而且剧情挺迷的，也可能是这部电影的内蕴比较深，我在观看的过程中产生了很多疑惑，而这些疑惑直到观影完都没有解开。

《封神第一部》特效做的确实可以，感觉剧情不是很完整，有点像预告片的样子 hh，姬昌声音听起来太🍬了。

《巨齿鲨 2：深渊》好看，很震撼，很刺激。

总结

虽然今年未能完成去年设定的目标，但在沟通能力方面取得了超出预期的提升。与此同时，我敢于勇往直前，涉足了许多之前未曾涉足的领域，拓展了自己的视野，也结识了许多新朋友。展望明年，我期待能够持续自我发展，将更多精力投入到我所钟情的领域，深耕并不断积累经验。希望未来的努力能够为我带来更为丰硕的成果。

本文复习自用，因为近期的几次面试都考察了比较基础的排序算法，所以记录一下。内容均来自Hello 算法 - 排序，这本书中详细描述了算法基础、各种数据结构以及各种算法类型，对我的帮助很大。再次感谢作者和各位贡献者的分享。

冒泡排序

通过连续比较与交换相邻元素实现排序。即使是经过优化，最差和最优的平均复杂度也为O(n^2)，但是在输入数组完全有序的情况下，可以达到最佳的时间复杂度 O(n)，属于稳定排序，在冒泡中遇到的相等元素不交换。

数组从最左端向右遍历，依次比较相邻元素大小，如果左元素>右元素就交换它俩，遍历完成后，最大的元素会被移到数组最右端。比较次数：n-1, n-2, …, 2, 1 总和为 (n - 1)n/2

1
2
3
4
5
6
7

nums = [5, 3, 1, 2, 4]
n = len(nums)
for i in range(n - 1, 0, -1): # 外循环，未排序区间[0, i]
    for j in range(i): # 内层循环将[0, i]的最大元素交换至区间最右端
        if nums[j] > nums[j + 1]:
            nums[j + 1], nums[j] = nums[j], nums[j + 1]
print(nums)

优化：标志位记录，如果没有交换，提前结束

1
2
3
4
5
6
7
8
9
10
11

nums = [5, 3, 1, 2, 4]
n = len(nums)
for i in range(n - 1, 0, -1): # 外循环，未排序区间[0, i]
    flag = False # 标志位记录是否完成排序
    for j in range(i): # 内层循环将[0, i]的最大元素交换至区间最右端
        if nums[j] > nums[j + 1]:
            flag = True
            nums[j + 1], nums[j] = nums[j], nums[j + 1]
    if not flag:
        break
print(nums)

归并排序

基于分治策略的排序算法，通过划分和合并组成。时间复杂度O(nlogn)，空间复杂度 O(n)，属于稳定排序，合并过程中，相等元素的次序保持不变。

划分：通过递归将数组从中点处分开，将长数组的排序转换为短数组的排序问题

合并：当子数组长度为 1 时，开始合并，持续将左右两个较短的有序数组组合为一个较长的有序数组，直到结束。

可以看到每一层都是 n，合并排序每一层的时间复杂度是 o(n)（可以参考合并两个有序数组），有 logn 层，因此时间复杂度是 O(nlogn)。

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

nums = [5, 3, 1, 2, 4]
n = len(nums)
def merge_sort(nums, left, right):
    if left >= right:
        return
    mid = (left + right) >> 1
    merge_sort(nums, left, mid)
    merge_sort(nums, mid + 1, right)
    merge(nums, left, mid, right)

def merge(nums, left, mid, right):
    tmp = list(nums[left:right + 1]) # 辅助数组，记录原先的值
    left_start = 0 # 左子数组的起始索引和结束索引
    left_end = mid - left
    right_start = mid + 1 - left # 右子数组的起始索引和结束索引
    right_end = right - left
    i = left_start # 左右子数组首元素索引
    j = right_start
    for k in range(left, right + 1):
        if i > left_end: # 只剩右子数组
            nums[k] = tmp[j]
            j += 1
        elif j > right_end or tmp[i] <= tmp[j]: # 只剩左子数组，或者左子数组的值更小
            nums[k] = tmp[i]
            i += 1
        else:
            nums[k] = tmp[j]
            j += 1
merge_sort(nums, 0, n - 1)
print(nums)

选择排序

开启一个循环，每轮从未排序区间选择最小的数，放到已排序区间的末尾。时间复杂度O(n^2)，比较次数包括 n, n-1, n-2, …, 3, 2 总共 (n - 1)(n + 2) / 2。非稳定排序，在经过选择后，相对顺序会更改。

流程如下

1. 初始状态所有元素未排序，未排序区间[0,n-1]
2. 从[0,n-1]找到最小的数的下标，与 0 交换
3. 从[1,n-1]找到最小的数的下标，与 1 交换
4. …直到 n-1 轮

1
2
3
4
5
6
7
8
9
10

nums = [5, 3, 1, 2, 4]
n = len(nums)

for i in range(n):
    minn = i
    for j in range(i, n):
        if nums[j] <= nums[minn]:
            minn = j
    nums[minn], nums[i] = nums[i], nums[minn]
print(nums)

插入排序

在未排序区间选择一个基准元素，将其与其左侧已排序区间的元素逐一比较大小，并将该元素插入到正确位置。基于元素赋值实现

时间复杂度O(n^2)，最差情况下分别需要比较 n-1, n-2, …, 2, 1 次，总和为 n(n-1)/2。实际遇到有序后会提前终止，当数组完全有序，复杂度为 O(n)。属于稳定排序，插入时会将元素插入到同等元素的右边，不会更改顺序。

流程如下

1. 初始时第一个元素已完成排序
2. 选择第二个元素作为 base，将其插入已排序的里面的正确位置
3. 选择第三个元素作为 base，将其插入已排序区间的正确位置
4. 直到最后一轮

1
2
3
4
5
6
7
8
9
10
11

nums = [5, 3, 1, 2, 4]
n = len(nums)

for i in range(1, n): # 遍历未排序区间[1, n - 1]
    base = nums[i]
    j = i - 1
    while j >= 0 and base < nums[j]: # 将base插到已排序区间[0, i]的某个正确位置
        nums[j + 1] = nums[j] # 将nums[j]后移一位，为base腾出空间
        j -= 1
    nums[j + 1] = base
print(nums)

虽然比快排的复杂度高，但插入排序的优势在于小数据量下通常会更快。

快速排序

基于分治策略的排，核心操作是哨兵划分，选择数组中某个元素作为基准数，将所有小于基准数的元素移到其左侧，将所有大于基准数的元素移到其右侧。时间复杂度为O(nlogn)，平均情况下哨兵划分递归层数为 log n，每层总循环 n 次，共 O(nlogn) 时间。最差情况下，每次划分为 0 和 n-1 长度的数组，递归层数为 n，每层循环数为 n，总体就是 O(n^2)。属于非稳定排序，在哨兵划分的最后一步，基准数可能会被交换到相等元素的右侧。

流程如下

1. 选择数组最左侧元素作为基准数，初始化 i 和 j 指向数组左右两端
2. 设置一个循环，每轮用 i、j 分别寻找到第一个比基准数大、小的元素，然后交换这俩元素
3. 重复直到 i 和 j 相遇，交换基准数至俩子数组的分界线。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

nums = [5, 3, 1, 2, 4]
n = len(nums)

def partition(nums, left, right):
    i, j = left, right # 以nums[left]作为基准数
    while i < j:
        while i < j and nums[j] >= nums[left]: # 找到右区间第一个比基准数小的
            j -= 1
        while i < j and nums[i] <= nums[left]: # 找到左区间第一个比基准数大的
            i += 1
        nums[i], nums[j] = nums[j], nums[i] # 交换这俩，保证左边都比基准数小，右边都比基准数大
    nums[i], nums[left] = nums[left], nums[i] # 将基准数放中间
    return i # 哨兵位置

def quick_sort(nums, left, right):
    if left >= right:
        return
    pivot = partition(nums, left, right) # 哨兵划分
    quick_sort(nums, left, pivot) # 递归左、右区间
    quick_sort(nums, pivot + 1, right)

quick_sort(nums, 0, n - 1)
print(nums)

快排优点：

大多数情况下都是以 O(nlogn) 复杂度运行，在执行哨兵划分时能用到系统缓存（将整个子数组加载到系统缓存，因为是连续的），快排的比较、赋值、交换次数更少（如果插入排序比冒泡排序快一样）

优化：

如果数组完全倒序，那么每次选择最左元素为基准数都会交换到最右端，导致 O(n^2)，退化为冒泡排序。可以优化基准数的选择策略，随机选择一个元素为基准数，或者说从前中后三个数中选择中位数作为基准数。

尾递归优化，某些输入下快排占用空间会很多，比如完全倒序，会占 O(n) 的栈空间。可以在每轮哨兵完成排序后，比较左右俩子数组的长度，仅对长度较小的子数组进行递归。

1
2
3
4
5
6
7
8
9

def quick_sort2(nums, left, right):
    while left < right:
        pivot = partition(nums, left, right)
        if pivot - left < right - pivot:
            quick_sort2(nums, left, pivot - 1) # 对左子区间递归
            left = pivot + 1 # 剩余未排序区间为[pivot + 1, right]
        else:
            quick_sort2(nums, pivot + 1, right) # 对右子区间递归
            right = pivot - 1

堆排序

基于堆的排序。时间复杂度O(nlogn)，其中建堆用 O(n)，取最大元素时间复杂度 O(logn)，共循环 n-1 轮。非稳定排序，在交换堆顶元素和堆底元素时，相等元素的位置可能会发生变化。

流程如下：

1. 输入数组并建立大顶
2. 将堆顶元素与堆底元素（最后一个）交换，完成交换后，堆长度 -1，已排序元素数量 +1
3. 从堆顶开始，从顶到底执行堆化（sift down），调整堆
4. 循环执行 2、3 步，直到 n-1 轮完成

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

nums = [5, 3, 1, 2, 4]
n = len(nums)

def sift_down(nums, root, k):
    t = nums[root] # 父节点
    while root << 1 < k: # k指堆大小
        child = root << 1 # 左子节点
        if child | 1 < k and nums[child | 1] > nums[child]: # 检查右子节点是否有机会
            child |= 1
        if nums[child] > t: # 如果当前元素更小，则递归向下，使得堆顶元素更大
            nums[root] = nums[child]
            root = child
        else: # 如果到了合适的位置，则赋值
            break
    nums[root] = t

nums = [0] + nums # 哨兵，基于此可以通过位运算快速定位子节点以及父节点
k = len(nums)

for i in range((k - 1) >> 1, 0, -1): # 建堆
    sift_down(nums, i, k)
for i in range(k - 1, 0, -1): # 取最大元素与堆底元素交换，并从顶到底调整堆
    nums[1], nums[i] = nums[i], nums[1]
    sift_down(nums, 1, i)

print(nums[1:])

桶排序

基于分治，非比较的排序算法，通过设置一些具有大小的桶，每个桶对应一个数据范围，将数据平均分散到桶中，然后对桶内执行排序（往往不需要，因为多数只有一个数），最终按照桶范围合并。时间复杂度一般是线性的，n 个数 k 个桶，O(n + k)，假设分布均匀，每个桶内元素 O(n/k)，排序耗时 O((n/k)log(n/k))，所有桶排序则 O(nlog(n/k))。当桶足够大，分散足够均匀，每个桶一个数，则趋向于O(n)。是否稳定基于桶内排序是否稳定。

流程如下

1. 初始化 k 个桶，将 n 个数分到 k 个桶
2. k 个桶分别执行排序
3. 从小到大合并 k 个桶

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

nums = [56, 32, 13, 26, 43]
n = len(nums)

k = 6
bucket = [[] for _ in range(k)] # 分k个桶
for x in nums:
    i = x // 10
    bucket[i].append(x)
for b in bucket:
    b.sort()
i = 0
for x in bucket:
    for xx in x:
        nums[i] = xx
        i += 1
print(nums)

主要是如何去将原始数据平均分散到多个 bucket 中。可以创建递归树来做，对数量多的 bucket 进行再分桶，或者通过概率统计来分桶。

计数排序

通过统计数量来对元素实现排序，适用于较为密集的数组。时间复杂度O(n + m)，包括遍历数组以及计数器。一般 n >> m，趋近于 O(n)。通过倒序遍历可以避免修改元素之间的相对位置，正序则非稳定。

流程如下

1. 遍历数组找到最大数 m，创建一个 m+1 辅助数组
2. 遍历数组计数
3. 编辑计数器统计出现次数，填充即可

1
2
3
4
5
6
7
8
9
10
11
12
13
14

nums = [5, 3, 1, 2, 4, 3, 2, 1]
n = len(nums)

maxx = max(nums)
c = [0] * (maxx + 1)
for x in nums:
    c[x] += 1
idx = 0
for i, x in enumerate(c): # 遍历计数器
    while x > 0: # 递减计数器
        nums[idx] = i # 填充nums
        x -= 1
        idx += 1
print(nums) # [1, 1, 2, 2, 3, 3, 4, 5]

基数排序

通过统计个数实现排序，但是主要利用数字各个位之间的递进关系，依次对每一位排序，适用于数值范围较大的，较分散的数组。时间复杂度 O(nk)，n 为数据量，d 为进制，k 为最大位数。对一位执行计数排序是 O(n + d)，排序 k 位就是 O(k(n + d))，通常趋向于 O(n)。通过倒序遍历可以避免修改元素之间的相对位置，正序则非稳定。

流程如下

1. 初始化位数 k=1
2. 针对第 k 位进行计数排序，整个数进行变动
3. 将 k+1，返回第二步，直到结束

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

nums = [10546151, 35663510, 21233312, 97422133, 22188831]
n = len(nums)

def digit(x, exp): # 取x的第k位返回，对10 100 1000...整除后取模
    return (x // exp) % 10

def counting_sort_digit(nums, exp):
    counter = [0] * 10 # 对每一位计数 0~9
    n = len(nums)
    for i in range(n): # 统计0~9出现次数
        d = digit(nums[i], exp)
        counter[d] += 1
    for i in range(1, 10): # 前缀和, 将个数转换为索引，比如 0 1 1 2 0 1 -> 0 1 2 4 4 5
        counter[i] += counter[i - 1]
    print(counter)
    res = [0] * n # 倒序遍历存入结果数组
    for i in range(n - 1, -1, -1):
        d = digit(nums[i], exp) # d为nums[i]的第k位值
        j = counter[d] - 1 # 获取d所在索引
        res[j] = nums[i] # 填入
        counter[d] -= 1 # 索引-1，因为可能有重复的 0 1 2 4 4 5 -> 0 1 2 3 4 5
    for i in range(n):
        nums[i] = res[i] # 覆盖

def radix_sort(nums):
    m = max(nums)
    exp = 1
    while exp <= m:
        counting_sort_digit(nums, exp)
        exp *= 10
radix_sort(nums)
print(nums)

总结

排序算法各有特点，在选择使用时需要跟据适用的场景来选择，而不是盲目选择快排等更知名的排序。

context 意为上下文，用于管理子 goroutine 的生命周期，或维护一条调用链路中的上下文，广泛用于微服务、以及各类标准包如 http、sql 中。context 的源代码非常的少且简洁，接下来笔者直接对 context 的源代码进行分析，并对 context 的应用场景做简单的介绍。

一个接口、四种实现、六个函数

Context 定义是一个接口，具体的实现有四种：emptyCtx、cancelCtx、timerCtx 以及 valueCtx。context 包对外暴露的方法主要有六个（实际上更多一点）：Background()、TODO()、WithValue()、WithCancel()、WithDeadline() 与 WithTimeout()。

可以简单看出，Context 四个方法决定了 Context 的几个用途：设置 deadline、设置取消信号，以及携带一些值。

1
2
3
4
5
6
7
8
9
10

// A Context carries a deadline, a cancellation signal, and other values across
// API boundaries.
//
// Context's methods may be called by multiple goroutines simultaneously.
type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key any) any
}

从 emptyCtx 起

其中*emptyCtx 只是对这四个方法进行了简单地实现：返回默认值、nil 或者 false。你可能感到很疑惑，*emptyCtx 看起来像是什么也没做，恰如其名，事实上确实是这样。emptyCtx 是以 int 为基础定义的自定义类型，不过即使是其他的类型，我们也能够接受。

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

// An emptyCtx is never canceled, has no values, and has no deadline. It is not
// struct{}, since vars of this type must have distinct addresses.
type emptyCtx int

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
    return
}

func (*emptyCtx) Done() <-chan struct{} {
    return nil
}

func (*emptyCtx) Err() error {
    return nil
}

func (*emptyCtx) Value(key any) any {
    return nil
}

func (e *emptyCtx) String() string {
    switch e {
    case background:
       return "context.Background"
    case todo:
       return "context.TODO"
    }
    return "unknown empty Context"
}

而 Background() 与 TODO() 这两个方法返回了构造好的*emptyCtx。

对于 Background，我们很快就通过它的命名能猜测到它的作用：作为上下文中最初的状态存在，像是一幅画最初的状态——一块白板，即是 Background。Background 是直接 new 的 emptyCtx，它本身不带有 deadline 或者其他一些奇怪的值，很符合作为白板。所以可以经常见到在异步处理请求的时候，为了不让带有 deadline 的 context 传入导致异步的 goroutine 被 cancel，就将为其新获取一个 Background 的 context 继续向下展开上下文。你可能不太了解为什么它适合作为白板来使用，我们先放一放，后续才是展现 context 魅力的时刻。

对于 TODO，经常用在还未决定使用哪种 context 或还无法接纳从外部传入的 context 的时候，例如一个函数的调用本应该接纳从外部传入的 context，而外部却没有传递 context 进来，所以暂时使用 TODO()，就像它的命名一样，留下一个 TODO。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var (
    background = new(emptyCtx)
    todo       = new(emptyCtx)
)

func Background() Context {
    return background
}

func TODO() Context {
    return todo
}
func main() {
    ctx := context.Background()
    ...
}

在普通的程序中，我们通过 context.Background() 获取一个初始 context，结合 iface 相关的知识，我们可以知道它的结构如下。通过结构图，我们可以更清晰地理解 context 调用链相关的知识，以及为何它被称为上下文。

再来看看 cancelCtx

我们再来看看 cancelCtx，它是一种可以被取消的 context，当它被取消时，它所有可取消的子 context 也会被取消。其中 done 用于获取 context 的取消通知，children 用于存储以它为根节点的所有可取消的子 context，以便于在根节点 context 取消时可以将它们一并取消，err 用于存储 context 被取消时存储的错误信息，mu 是用于保证这几个字段的锁，以保证 cancelCtx 是线程安全的，cause 则与 err 一样但又有点不同，它是专门用于存储解释 cancel 的 error，当 context 没被取消，则 cause 会是 nil，而 err 却不一定是 nil。

1
2
3
4
5
6
7
8
9
10
11

// A cancelCtx can be canceled. When canceled, it also cancels any children
// that implement canceler.
type cancelCtx struct {
    Context                        // 父级context

    mu       sync.Mutex            // 保护下述字段
    done     atomic.Value          // 用于获取context的取消通知
    children map[canceler]struct{} // 用于存储以它为根节点的所有可取消的子context
    err      error                 // 用于存储context被取消时存储的错误信息
    cause    error                 // 用于存储解释context被取消的信息
}

WithCancel() 函数可以将一个 context 包装为 cancelCtx，并返回一个取消函数，用于取消对应的 context。来看看它的底层，其实是通过 withCancel 进行包装，而 withCancel 则是通过 newCancelCtx 创建了一个 cancelCtx，将之前的 context 设置为了父 context。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
    c := withCancel(parent)
    // 返回的是一个匿名函数，用于将所有子的context一并取消
    return c, func() { c.cancel(true, Canceled, nil) }
}

func withCancel(parent Context) *cancelCtx {
    if parent == nil {
       panic("cannot create context from nil parent")
    }
    c := newCancelCtx(parent)
    propagateCancel(parent, c)
    return c
}

// newCancelCtx returns an initialized cancelCtx.
func newCancelCtx(parent Context) *cancelCtx {
    // 可以看到，只是简单包装了一层
    return &cancelCtx{Context: parent}
}

在解读 propagateCancel 之前，我们先来看看 cancelCtx 对 Done() 的实现。d.done 是一个 chan struct{}，懒加载并通过 mu 来保证并发安全。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

func (c *cancelCtx) Done() <-chan struct{} {
    d := c.done.Load()
    if d != nil {
       return d.(chan struct{})
    }
    c.mu.Lock()
    defer c.mu.Unlock()
    d = c.done.Load()
    if d == nil {
       d = make(chan struct{})
       c.done.Store(d)
    }
    return d.(chan struct{})
}

我们之前提到 children 中存储了所有以它为根节点的所有可取消的 context，propagateCancel 正是用于此处，它根据父级 context 的状态来关联 cancelCtx 的 cancel 行为，在父节点被取消时，会一同取消所有可取消的子 context。

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

// goroutines counts the number of goroutines ever created; for testing.
var goroutines atomic.Int32

// propagateCancel arranges for child to be canceled when parent is.
func propagateCancel(parent Context, child canceler) {
    done := parent.Done() // 一次检查：继承父级的done方法，如果父级是*emptyCtx就直接返回
    if done == nil {
       return 
    }

    select {
    case <-done:
       // 检查父级是否已经cancel了
       child.cancel(false, parent.Err(), Cause(parent))
       return
    default:
    }

    // 找到自己第一个父级的cancelCtx
    if p, ok := parentCancelCtx(parent); ok {
       p.mu.Lock()
       if p.err != nil {
          // 父级已经cancel了，那么也调用子context的cancel
          child.cancel(false, p.err, p.cause)
       } else {
          // 如果这个父级没有children，则给它分配一个，然后把自己存进去
          // 添加关联
          if p.children == nil {
             p.children = make(map[canceler]struct{})
          }
          p.children[child] = struct{}{}
       }
       p.mu.Unlock()
    } else {
       // 开启一个goroutine去监听parent是否Done了，相当于监控线程
       // 这里应该是测试使用，单独一个协程生命周期运行完会被gc回收，不会泄漏
       goroutines.Add(1)
       go func() {
          // 阻塞式select
          select {
          // 如果child已经cancel了，parent再cancel会导致child被cancel两次，不过问题不大
          case <-parent.Done():
             child.cancel(false, parent.Err(), Cause(parent))
          case <-child.Done():
          }
       }()
    }
}

// &cancelCtxKey is the key that a cancelCtx returns itself for.
var cancelCtxKey int

func parentCancelCtx(parent Context) (*cancelCtx, bool) {
    // 二次检查（removeChild需要）
    done := parent.Done()
    if done == closedchan || done == nil {
       return nil, false
    }
    // 通过cancelCtxKey获取父级第一个cancelCtx
    // 这里我们可以先看看cancelCtx的Value()方法，它通过一个特定的key（cancelCtxKey）来返回自身，否则走value()向上递归查询
    // valueCtx的Value()也一样，而valueCtx并不会影响到cancelCtxKey的使用，这是因为cancelCtxKey是一个新的类型，后续讲解valueCtx会涉及到
    // 这里如果false，就是获取到了emptyCtx，到达了根节点也没有cancelCtx，直接返回即可
    p, ok := parent.Value(&cancelCtxKey).(*cancelCtx)
    if !ok {
       return nil, false
    }
    // 看看父级第一个cancelCtx的done是否与当前传入的parent context的done匹配
    // 如果不是，则说明可能在context传播过程中进行了包装，不可直接绕过当前上下文进行取消操作
    // 我们返回false即可
    pdone, _ := p.done.Load().(chan struct{})
    if pdone != done {
       return nil, false
    }
    return p, true
}

func (c *cancelCtx) Value(key any) any {
    if key == &cancelCtxKey {
       return c
    }
    return value(c.Context, key)
}

func (c *valueCtx) Value(key any) any {
    if c.key == key {
       return c.val
    }
    return value(c.Context, key)
}

等了这么久，我们终于可以看看 cancel 了。它在上述我们使用 WithCancel 时包装成一个匿名函数返回，通过调用这个函数，我们可以取消当前的 context，关闭当前 context 的 done，并取消其所有子 context。在取消时，会设置 cause。

前文中 WithCancel 在执行 cancel 时传的参数是 Canceled，Canceled 就是我们熟知的 context canceled 错误。

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
43
44
45
46
47
48
49
50
51
52
53

// Canceled is the error returned by Context.Err when the context is canceled.
var Canceled = errors.New("context canceled")

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
    c := withCancel(parent)
    return c, func() { c.cancel(true, Canceled, nil) }
}
// closedchan is a reusable closed channel.
var closedchan = make(chan struct{})

func init() {
    close(closedchan)
}

func (c *cancelCtx) cancel(removeFromParent bool, err, cause error) {
    if err == nil {
       panic("context: internal error: missing cancel error")
    }
    // cancel原因
    if cause == nil {
       cause = err
    }
    c.mu.Lock()
    // 已经被cancel了
    if c.err != nil {
       c.mu.Unlock()
       return // already canceled
    }
    c.err = err
    c.cause = cause
    // 获取done
    d, _ := c.done.Load().(chan struct{})
    if d == nil {
       // 如果done不存在，说明Done还没调用过，懒加载没执行，直接设一个默认关闭的chan即可，读出来的都会是零值
       c.done.Store(closedchan)
    } else {
       // 否则将done关掉，这样被done阻塞的goroutine就会收到零值通知，执行后续代码
       close(d)
    }
    // 对所有子cancel进行cancel
    for child := range c.children {
       // NOTE: acquiring the child's lock while holding parent's lock.
       // 由于后续c.children置为nil了，而且这些context只会注册到离他最近的父cancelCtx中，就不需要removeFromParent了
       child.cancel(false, err, cause)
    }
    c.children = nil
    c.mu.Unlock()
    
    // 查看是否需要从parent处remove
    if removeFromParent {
       removeChild(c.Context, c)
    }
}

而使用 WithCancelCause 相较于 WithCancel 类似，区别是它会传入造成此次 cancel 的自定义 error，这个你可以自己去定义，关键时候使用能更快地排查出相关问题。

1
2
3
4

func WithCancelCause(parent Context) (ctx Context, cancel CancelCauseFunc) {
    c := withCancel(parent)
    return c, func(cause error) { c.cancel(true, Canceled, cause) }
}

Cause 用于返回 cancel 的 error。

1
2
3
4
5
6
7
8

func Cause(c Context) error {
    if cc, ok := c.Value(&cancelCtxKey).(*cancelCtx); ok {
       cc.mu.Lock()
       defer cc.mu.Unlock()
       return cc.cause
    }
    return nil
}

cancelCtx 的解读到此处就快结束了，我们来收尾看看 removeChild 的逻辑：很简单，它找到第一个父 cancelCtx，将自己从它的 p.children 中移除。

1
2
3
4
5
6
7
8
9
10
11
12

// removeChild removes a context from its parent.
func removeChild(parent Context, child canceler) {
    p, ok := parentCancelCtx(parent)
    if !ok {
       return
    }
    p.mu.Lock()
    if p.children != nil {
       delete(p.children, child)
    }
    p.mu.Unlock()
}

如果上述的解读不够直观，我们可以再来看看调用 WithCancel 后包装一层的结构，以此来加深对 context 上下文调用链的理解：

1
2
3
4
5
6

func main() {
    ctx := context.Background()
    ctx1, cancel := context.WithCancel(ctx)
    defer cancel()
    //...
}

timerCtx

timerCtx 基于 cancelCtx，封装了一个定时器和一个截止时间。这样既可以通过 cancelCtx 主动取消，又可以通过到达 deadline 时，通过 timer 来调用取消动作，timer 也由 cancelCtx 的 mu 字段互斥锁来保护，保证了 timerCtx 也是线程安全的。

1
2
3
4
5
6

type timerCtx struct {
    *cancelCtx
    timer *time.Timer // Under cancelCtx.mu.

    deadline time.Time
}

先来看看它的 cancel，非常简洁，只是调用了一下 cancelCtx 的 cancel，并将 timer 暂停。

1
2
3
4
5
6
7
8
9
10
11
12
13

func (c *timerCtx) cancel(removeFromParent bool, err, cause error) {
    c.cancelCtx.cancel(false, err, cause)
    if removeFromParent {
       // Remove this timerCtx from its parent cancelCtx's children.
       removeChild(c.cancelCtx.Context, c)
    }
    c.mu.Lock()
    if c.timer != nil {
       c.timer.Stop()
       c.timer = nil
    }
    c.mu.Unlock()
}

通过 WithDeadline 和 WithTimeout 都可以创建 timeCtx，区别是 withDeadline 需要指定一个时间点，而 WithTimeout 需要指定一个时间段。WithDeadline 中，先判断之前是否有 timerCtx，如果有，就看看时间是否在自己之前，是的话就不用设置了，包装个 cancelCtx 直接返回，因为父级 context 设置了更早的时间，更早的 cancel，当前 context 肯定会被影响，一并 cancel。然后根据当前给定的 context 又创建了一个新的 cancelCtx 包装 parent context，进行关联关系，并获取当前时间的差值，赋值一个 timer。

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
43
44
45
46
47

// DeadlineExceeded is the error returned by Context.Err when the context's
// deadline passes.
var DeadlineExceeded error = deadlineExceededError{}

type deadlineExceededError struct{}

func (deadlineExceededError) Error() string   { return "context deadline exceeded" }
func (deadlineExceededError) Timeout() bool   { return true }
func (deadlineExceededError) Temporary() bool { return true }

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
    if parent == nil {
       panic("cannot create context from nil parent")
    }
    // 如果之前设置的deadline在如今设置的deadline之前，直接返回cancel包装
    // 这样遵循了之前的截止日期，因为父级context的deadline取消操作会影响到当前context，所以不用设置了
    // 如果这里是false说明是emptyCtx，没有设置deadline，不用管
    if cur, ok := parent.Deadline(); ok && cur.Before(d) {
       return WithCancel(parent)
    }
    c := &timerCtx{
       cancelCtx: newCancelCtx(parent),
       deadline:  d,
    }
    // 设置一些关联
    propagateCancel(parent, c)
    dur := time.Until(d)
    // 如果已经超时了，就直接cancel
    // 此处的DeadlineExceeded是"context deadline exceeded"错误
    if dur <= 0 {
       c.cancel(true, DeadlineExceeded, nil) // deadline has already passed
       return c, func() { c.cancel(false, Canceled, nil) }
    }
    c.mu.Lock()
    defer c.mu.Unlock()
    if c.err == nil {
       // 设置timer，超时则调用cancel
       c.timer = time.AfterFunc(dur, func() {
          c.cancel(true, DeadlineExceeded, nil)
       })
    }
    return c, func() { c.cancel(true, Canceled, nil) }
}

func (c *timerCtx) Deadline() (deadline time.Time, ok bool) {
    return c.deadline, true
}

而 WithTimeout 就是简单调用了 WithDeadline：

1
2
3

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
    return WithDeadline(parent, time.Now().Add(timeout))
} 

使用示例如下：

1
2
3
4
5
6
7
8

func main() {
    ctx := context.Background()
    ctx1, cancel := context.WithCancel(ctx)
    defer cancel()
    ctx2, cancel2 := context.WithDeadline(ctx1, time.Now().Add(1*time.Second))
    defer cancel2()
    //...
}

可以看到 ctx2 基于 ctx1，而 ctx1 基于 ctx，而每个 context 都可以延伸出多个子 context，进行不断的扩展和包装，于是就构成了一颗 context 树。

基于这颗 context 树，我们的 cancel 就派上用场了，一个上下文 context 可以取消其与其所有可取消的子 context：

valueCtx

最后来看看 valueCtx，它附加了一个键值对，通过 WithValue() 可以给 context 附加一个键值对的打包。

1
2
3
4

type valueCtx struct {
    Context
    key, val any
}

WithValue() 简单的将 context 包装了一层，返回 valueCtx。注意此处的 key 和 context 都不能为 nil，且 key 必须是可比较类型。

1
2
3
4
5
6
7
8
9
10
11
12

func WithValue(parent Context, key, val any) Context {
    if parent == nil {
       panic("cannot create context from nil parent")
    }
    if key == nil {
       panic("nil key")
    }
    if !reflectlite.TypeOf(key).Comparable() {
       panic("key is not comparable")
    }
    return &valueCtx{parent, key, val}
}

valueCtx 的核心函数当然是 Value()，它对比当前 context 的 key 与给定的 key 是否一致，如果一致就返回值，否则继续向上递归调用。

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

func (c *valueCtx) Value(key any) any {
    if c.key == key {
       return c.val
    }
    return value(c.Context, key)
}

func value(c Context, key any) any {
    for {
       switch ctx := c.(type) {
       case *valueCtx:
          if key == ctx.key {
             return ctx.val
          }
          c = ctx.Context
       case *cancelCtx:
          if key == &cancelCtxKey {
             return c
          }
          c = ctx.Context
       case *timerCtx:
          if key == &cancelCtxKey {
             return ctx.cancelCtx
          }
          c = ctx.Context
       case *emptyCtx:
          return nil
       default:
          // 向上递归调用
          return c.Value(key)
       }
    }
}

很显然，当 key 值是一样时，最接近当前 context 的 context 的值就会被获取到，而更高层 context 的值就会被掩盖。因此，最好将 key 自定义类型，而不是直接使用基础类型，这样容易导致 key 被覆盖。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

func main() {
    ctx := context.Background()
    ctx1 := context.WithValue(ctx, "key", "value111")
    ctx2 := context.WithValue(ctx1, "key", "value222")
    ctx3, cancel := context.WithCancel(ctx2)
    defer cancel()
    println(ctx1.Value("key").(string)) // value111
    println(ctx2.Value("key").(string)) // value222
    println(ctx3.Value("key").(string)) // value222
}
type key string
type keyy string

func main() {
    ctx := context.Background()
    var key1 keyy = "key"
    var key2 key = "key"
    ctx1 := context.WithValue(ctx, key1, "value111")
    ctx2 := context.WithValue(ctx1, key2, "value222")
    ctx3, cancel := context.WithCancel(ctx2)
    defer cancel()
    println(ctx3.Value(key1).(string)) // value111
    println(ctx3.Value(key2).(string)) // value222
}

至此，context 包中大部分源码已经解读完毕，我们可以聊一聊应用了。

应用

上下文数据传递

在 Java 中有 Threadlocal，而 Go 中则有 Context。在一个请求链路中，常常有一定的标识，比如这个请求是用户 A 发起的，那么整条链路中会有很多地方需要去获取用户 A 的一些信息，此时就可以通过 context 去存储相关的信息，然后借助 context 进行传递。当然，这也仅限于当个服务内，我们以 grpc 沟通时，在调用链路中，一个服务中的 context 携带的信息不可能直接在下游服务的 context 就有，通常是在两个服务间通过 grpc metadata 进行传递，通过 client 和 server 注册的 Interceptor 对 context 和 metadata 进行转换。http 的话就可以根据请求头携带相关的值。

超时控制

context 广泛用于微服务、http 以及 sql 包等的超时控制。调用 cancel 能释放与该 context 关联的资源，所以在这个 context 完成它的使命时，应该尽快调用 cancel，通常我们会在调用完成后使用 defer cancel()。在以下 http 请求示例中，为什么defer cancel()不放在resp, err := client.Do(req)下面一行呢，其实这是一个常见的误区，因为这样会导致 cancel 函数的调用在超时情况下失去作用。在网络请求超时的情况下，client.Do 可能会阻塞，而 cancel 函数将无法被调用，无法取消上下文，从而可能导致资源泄漏或意外的等待。

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

package main

import (
    "context"
    "fmt"
    "net/http"
    "time"
)

func main() {
    // 创建一个具有 5 秒超时的 context
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    req, err := http.NewRequest("GET", "https://anyview.fun", nil)
    if err != nil {
       fmt.Println("Error creating request:", err)
       return
    }

    // 将 context 与请求关联
    req = req.WithContext(ctx)

    client := http.DefaultClient
    resp, err := client.Do(req)
    if err != nil {
       fmt.Println("Error sending request:", err)
       return
    }
    defer resp.Body.Close()

    fmt.Println("Response status:", resp.Status)
}

在net包中/src/net/http/transport.go:512可以看到通过对ctx.Done的监听来控制context的超时。很常见的一种用法，也说明了一点：context的超时控制不是通过直接中断 Goroutine 来实现的，而是通过在 Goroutine 中检查 context 的状态来实现的。在请求中，当使用一个派生自当前 context 的子 context 时，如果主 context 被取消，context 中的取消信号将传递给请求操作，通知它们停止等待和执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// roundTrip implements a RoundTripper over HTTP.
func (t *Transport) roundTrip(req *Request) (*Response, error) {
    ...
    for {
        select {
        case <-ctx.Done():
            req.closeBody()
            return nil, ctx.Err()
        default:
        }
        ...
    }
...
}

sql 也类似，在多个地方监听和检查 context 的信号状态，以此来控制自己 goroutine 的生命周期。

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

package main

import (
    "context"
    "database/sql"
    "fmt"
    "time"

    _ "github.com/go-sql-driver/mysql"
)

func main() {
    db, err := sql.Open("mysql", "user:password@tcp(127.0.0.1:3306)/database")
    if err != nil {
       fmt.Println("Error connecting to database:", err)
       return
    }
    defer db.Close()

    // 创建一个具有 2 秒超时的 context
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()

    // 将 context 与查询关联
    rows, err := db.QueryContext(ctx, "SELECT * FROM users")
    if err != nil {
       fmt.Println("Error executing query:", err)
       return
    }
    defer rows.Close()

    for rows.Next() {
       var id int
       var username string
       err := rows.Scan(&id, &username)
       if err != nil {
          fmt.Println("Error scanning row:", err)
          return
       }
       fmt.Printf("User: ID=%d, Username=%s\n", id, username)
    }
}

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

// /src/database/sql/sql.go:1281
// conn returns a newly-opened or cached *driverConn.
func (db *DB) conn(ctx context.Context, strategy connReuseStrategy) (*driverConn, error) {
    ...
    // Check if the context is expired.
    select {
    default:
    case <-ctx.Done():
       db.mu.Unlock()
       return nil, ctx.Err()
    }
    ...
}

// /src/database/sql/ctxutil.go:46
func ctxDriverQuery(ctx context.Context, queryerCtx driver.QueryerContext, queryer driver.Queryer, query string, nvdargs []driver.NamedValue) (driver.Rows, error) {
    ...

    select {
    default:
    case <-ctx.Done():
       return nil, ctx.Err()
    }
    ...
}

而在异步场景下，context 就不能这样依靠父 context 直接构造子 context 继续传递上下文。最好的方法当然是通过 context.Background() 为其重新开启一段上下文。但当我们有一些特定的场景需要异步且还是需要上下文的时候怎么办呢？最好使用其余的东西去存储你需要的相关上下文信息，而不是想着拷贝 context 继续向下执行，否则代码会变得难以维护。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

package main

import (
    "context"
    "fmt"
    "sync"
)

func main() {
    ctx := context.Background()
    add(ctx, 1, 2)
    wg := &sync.WaitGroup{}
    wg.Add(1)
    go func() {
       add(context.Background(), 2, 3)
       wg.Done()
    }()
    wg.Wait()
}

func add(ctx context.Context, x, y int) {
    fmt.Println(x + y)
}

链路追踪

链路追踪的本质也是通过维护一条链路上同一个 trace-id，在 client 和 server 的 Interceptor、或者一些 log sdk、db 集成的 sdk 进行上报，通过 jaeger 等收集相关的数据进行展示。

笔者写了个基于 Opentelemetry 集成了 Jaeger 的 grpc 中间件作为学习 demo。主要也是处理上下文数据传递中的细节，来达到一条链路上一致的 trace-id 和 span。

在为 dtm 贡献时，笔者发现，基于分布式事务的 dtm 事务管理器在处理请求时以异步的形式来进行更好，能够减少分布式事务中产生的数据不一致的情况，提高分布式事务的效率。这会导致 context 无法作为上下文继续向下传递。而一些数据已经在 Interceptor 处理过放到 context 里了，比如 opentelemetry 中 trace 的 span、trace 啥的，这里真正好的方法是在新的 background 拷贝一些需要继续向下传递的值，然后再将新的 context 继续向下传递。

此外，笔者也借此机会写了完整拷贝 context 值的方法，但是不推荐使用，仅供参考。以下的代码由于在 Go1.19.3-1.20.5 之间某个版本迭代中，timerCtx 的结构从 cancelCtx 更改为了*cancelCtx，所以只适用于后者的版本，相应的改动是将以下 timerCtx 的结构也更改为对应的结构。

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

type iface struct {
    itab, data uintptr
}

type valueCtx struct {
    context.Context
    key, value any
}

type cancelCtx struct {
    context.Context
}

type timerCtx struct {
    cancelCtx *cancelCtx
}

func (*timerCtx) Deadline() (deadline time.Time, ok bool) {
    return
}

func (*timerCtx) Done() <-chan struct{} {
    return nil
}

func (*timerCtx) Err() error {
    return nil
}

func (*timerCtx) Value(key any) any {
    return nil
}

func (e *timerCtx) String() string {
    return ""
}

// CopyContext copy context with value and grpc metadata
// if raw context is nil, return nil
func CopyContext(ctx context.Context) context.Context {
    if ctx == nil {
       return ctx
    }
    newCtx := context.Background()
    kv := make(map[interface{}]interface{})
    getKeyValues(ctx, kv)
    for k, v := range kv {
       newCtx = context.WithValue(newCtx, k, v)
    }
    return newCtx
}

func getKeyValues(ctx context.Context, kv map[interface{}]interface{}) {
    rtType := reflect.TypeOf(ctx).String()
    if rtType == "*context.emptyCtx" {
       return
    }
    ictx := *(*iface)(unsafe.Pointer(&ctx))
    if ictx.data == 0 {
       return
    }
    valCtx := (*valueCtx)(unsafe.Pointer(ictx.data))
    if valCtx.key != nil && valCtx.value != nil && rtType == "*context.valueCtx" {
       kv[valCtx.key] = valCtx.value
    }
    if rtType == "*context.timerCtx" {
       tCtx := (*timerCtx)(unsafe.Pointer(ictx.data))
       getKeyValues(tCtx.cancelCtx, kv)
       return
    }
    getKeyValues(valCtx.Context, kv)
}

由于反射的做法不兼容不同的 Go 版本，所以也可以尝试自定义一个 context 去阻断父节点的 cancel，具体代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

type asyncCtx struct {
context.Context
}

func (a *asyncCtx) Deadline() (deadline time.Time, ok bool) {
return
}

func (a *asyncCtx) Done() <-chan struct{} {
return nil
}

// NewAsyncContext create a new async context
// the context will not be canceled when the parent context is canceled
func NewAsyncContext(ctx context.Context) context.Context {
if ctx == nil {
return nil
}
return &asyncCtx{Context: ctx}
}

总结

本文从源码入手解析了精致的 context 包，感叹作者设计优秀的同时，也介绍了相关的应用场景。

ACL

访问控制列表（ACL，即 Access-control list），将一系列的权限与一个系统资源相关联。ACL 专注于个别许可的列表，想象一下你家门口的门禁系统，门禁系统上有一个名单，上面列出了允许进入你家的人的姓名。这个名单就像是一个 ACL，里面记录了具体的人名和他们被授予的进入权限，比如进入、离开、访问特定房间等。只有名单上的人才能够进入你家，其他人则不能。

一般的表结构设计如：ACL 表（对象标识，主体标识，权限标识），对象指需要访问的对象，比如门禁系统中特定的门口，主体代表进入你家的人，权限则标识进入、离开等。

一些变种包括：

• ACL with superuser

普通用户的权限管理与之前一致，但引入了一个超级用户，不受权限管理控制，拥有所有权限。有了超级用户，排查些问题会比较方便。

• ACL without users

适用于没有身份验证或用户登录的系统，比如文件共享系统，希望进行访问控制，但又不想为每个用户分配权限，就可以通过定义文件属性（如文件类型、标签、内容等）来管理文件的访问权限，从而更灵活地控制访问。

• ACL without resources

与 ACL 不同，它不再关心特定的资源，而是专注于对一类资源或者一种操作的权限控制。比如你可以定义一个权限叫写文章，而不用关心具体的哪篇文章。这意味着你可以将 “写文章” 权限授予多个用户，让他们可以写任何文章，而不用每次新建一篇文章都重新设置权限。

RBAC

基于角色的访问控制（RBAC，Role-based access control），主要专注于角色和权限的管理和分配。想象你是一家公司的主管，有员工、经理和管理员等角色。在 RBAC 中，你为每个角色指定了特定的权限集合。例如，员工可以访问公司资源，经理可以管理项目并授予权限，管理员可以管理整个系统。当某人被分配了某个角色，他们就会自动获得与该角色相关的权限，而不需要单独指定。

RBAC 相对于其他访问控制模型，优势在于它的批量操作非常便捷，只需要为这些用户都分配这个角色即可，它们就会获取到该角色拥有的大量权限。而且更改该角色的权限时，无需为这些用户改动。

一般的表结构是一个角色表，一个权限表，一个用户表，一个角色和权限的关联表，一个用户和角色的关联表。当获取一个用户的权限时，根据角色与权限的关联取到权限交集。

变种有：

1. RBAC with resource roles

通过为资源分配角色，访问控制变得更加细粒度。与其仅仅确定用户是否能够访问资源不同，这种方法允许定义特定操作或操作，特定角色的用户可以对特定资源执行这些操作。

比如一个开放的在线文档平台，有作者、审阅者、访客等角色。对于一篇文档的不同状态，有不同的权限控制：

• 正在编辑的文档：只有作者可见，只有作者允许编辑。
• 正在审阅的文档：只有作者和审阅者可见，审阅者无法编辑但可以反馈，作者无法编辑（如果需要编辑，需要等待审阅打回）。
• 已发布的文档：所有角色都可见，只有作者允许编辑。

这个例子中，不同的用户和文档角色组合导致了不同级别的权限，同时也考虑了文档的不同状态和用途。这种方法有助于确保适当的权限和访问控制，使用户可以在协作环境中高效地工作。

2. RBAC with domains/tenants

适用于多租户系统，比如在线网课平台，每个学校都是一个租户，每个用户在不同租户中的角色权限都不一样，可以更细粒度的进行管理。这使得平台能够根据不同的领域或租户需求，提供个性化和定制化的权限控制，确保用户可以在不同环境中执行适当的操作。

ABAC

ABAC 是基于属性的访问控制，通过角色属性和资源属性根据策略来控制访问权限。

访问策略通常指：如果你的某个属性为特定属性时，或者达到了某个条件，那么这个资源你就可以进行对应权限的访问。

一般表结构如下：一个实体表，一个资源表，一个实体属性表，一个策略表，一个策略规则表。其中策略表关联了资源表，相当于为该资源设定了访问策略，策略规则表存储了条件、动作等。

假设你在一个虚拟的游戏世界中。在 ABAC 中，访问权限取决于你的属性。每个玩家都有一些属性，比如级别、任务完成情况、特殊技能等。为了获得访问权限，系统会根据你的属性动态地决定是否允许你进入某个区域或执行某项任务。例如，如果你的级别达到了某个要求，你就可以访问一个高级区域。

Deny-override

Deny-override 支持同时使用允许（allow）和拒绝（deny）授权，其中拒绝授权会覆盖允许授权。这种机制用于确定用户是否有权访问资源，即当允许和拒绝授权同时存在时，拒绝授权将优先于允许授权生效。

关键特点在于

• 允许授权（Allow Authorization）：允许授权确定哪些用户或角色可以访问特定资源。这些授权可能基于角色、属性、上下文等条件。
• 拒绝授权（Deny Authorization）：拒绝授权确定哪些用户或角色不允许访问特定资源，即拒绝访问权限。
• Deny-override 规则：在 Deny-override 机制下，如果一个用户或角色同时有允许和拒绝授权，那么拒绝授权会覆盖允许授权，即拒绝授权优先于允许授权。

这种访问权限控制模型笔者没有用过，适用于一些机密文件，可以确保该资源不被不应该访问的用户访问。

Priority

类似防火墙规则，访问策略规可以根据其优先级进行排序，以决定当多个规则适用于同一资源时，哪个规则将被优先应用。这种机制允许管理员灵活地控制访问权限，确保特定规则在发生冲突时能够正确执行。

像 iptables 就是，从上到下多条规则进匹配，然后决定该数据包是 ACCEPT 还是转发等。

RESTful

以 URI 来唯一标识某个资源，然后根据请求方法 GET、PUT、POST 等对资源进行操作。

比较简单的是用户能访问自己的资源，管理员能访问所有的资源。

1
2
3
4

http://localhost:8080/{user_id}/paper

其中{user_id}是用户的唯一标识
根据请求GET，表示获取用户的paper列表，POST表示添加paper，DELETE表示删除paper等。

实践

笔者所在的部门主要维护一个服务于所有业务线的基座平台，该平台上承载着多个 appfy，每个 appfy 都相当于一个业务的闭环，类似于手机上的 app。在 SaaS 业务中，一个 appfy 可能会有一些高级功能或者定制功能，这些功能只提供给付费用户使用。由于业务方向是 B 端的，一个公司在使用过程中需要进行权限管理。

在公司组织架构管理中，常用的访问控制模型是 RBAC，根据用户的角色来分配权限。针对 RBAC 模型，我们将权限维度抽象为权限点，权限点用于控制某个 appfy 的某个功能。通过用户 - 角色 - 权限点的方式来管理公司内的权限分配。

然而，在过去的版本迭代中存在一些问题：

1. 纯 RBAC 模型无法兼顾高级功能或定制功能的权限分配。权限点没有公司维度，且独属于一个 appfy。如果添加一个权限点用于控制高级功能或定制功能，所有公司在自己的组织架构中都能看到这个权限点。虽然有禁用权限点的功能，但权限点默认都是不禁用的。

2. 新建立的公司所拥有的 appfy 是通过模板来分配的，但模板分配的维度仅限于 appfy，而非更细分的权限点。

为了解决这些问题，笔者的设计是将权限点进行分类处理，并通过扩展 RBAC 模型来管理公司所拥有的高级、定制权限点。

角色和资源：

• 角色：公司
• 资源：带有高级 tag 的权限点

策略规则：

• 如果用户属于某一个公司，并且公司付费功能包含该功能权限点，则进而根据 RBAC 模型判断用户是否拥有该权限点。

另一方面，为了简化 CSM 对客户公司的权限管理：

• 如果权限点关联的 appfy 没有为该公司开启，则该权限点将不会允许该公司用户访问。
• 将部分有关联的高级权限点打包，CSM 进行分配时可以批量分配。

总结

本文介绍了几种权限访问控制模型：ACL、RBAC、ABAC、Deny-override、Priority 和 RESTful，并通过实际案例展示了它们的应用。ACL 强调对象权限关联，RBAC 基于角色分配权限，ABAC 根据属性动态控制，Deny-override 优先拒绝，Priority 排序规则，RESTful 基于 HTTP 方法。通过灵活选择和组合这些模型，可以实现有效的权限管理系统。

容器网络的初期阶段，容器是一种封装技术，将应用和其依赖的环境打包在一起，方便快速部署和运行。对外暴露的方式相对简单：每个容器通过对应的端口暴露，外部程序可以通过不同的端口来区分不同的容器实例和应用实例。这种方案比较直接，没有引入任何网络堆栈，因此被广大开发者采纳。但是管理起来存在一些问题，因为每个容器都至少占用宿主机的一个端口。

为了解决容器规模化部署管理方面的问题，引入了 Overlay 网络方案。在这种方案下，两台主机之间构建一个默认私有的虚拟网络，支持容器与容器之间的通信，每个容器在虚拟网络中都有一个独立的 IP 地址。当容器需要对外暴露时，通过虚拟网络连接主机端口，主机端口对外暴露，外部数据包可以通过主机端口进入虚拟网络，然后路由转发给特定的容器。这也就是 Overlay 网络方案的工作原理。显而易见，Overlay 的优势在于允许无限制地部署容器，并提供虚拟网络中的独立 IP 地址，但通信数据仍然需要通过真实物理网络基础设施传输。然而，企业较少使用 Overlay，因为一些传统的应用程序可能依赖于特定网络拓扑配置和直接的主机间通信方式，而 Overlay 网络方案可能需要对这些应用程序进行适配或修改，以适应虚拟网络的架构。

大约在 17 年左右，基于 Overlay 的 Underlay 网络方案在业界流行起来。在这种网络方案下，虚拟网络与底层网络相连，能够满足虚拟网络中容器与虚拟机、物理机以及数据库等之间互通互连的需求，成为企业级网络方案的主流。与 Overlay 网络方案相比，Underlay 本质上没有变化，只是网络连接方式上有些许不同。然而，Underlay 网络方案有着明显的缺陷，当虚拟网络与真实物理网络打通后，容器每一个 IP 地址的管理都受到物理条件制约。由于底层网络有着多种类型，比如 vlan，IPv6，SDN，VPC 等，Underlay 需要对它们都进行适配，而这种适配可能具有一定的特殊性，比如华为的 SDN 可能无法以适配物理二层的方式进行适配，可能需要调用 SDN 的一个接口去获取可路由的 IP，然后在 SDN 网络控制器中配置转发规则。

网络方案的第三个阶段是多网络框架，它支持底层多变多样的基础网络结构，同时支持应用层面的联通性和管理的便捷性。这也是适配底层网络多样性的通用性解决方案，在容器内实现 Underlay 和 Overlay 网络的互通互联，在负载均衡层实现对外端口暴露，并将数据包转发到 Overlay 和 Underlay。

Overview

容器是独立的，没有存储任何网络相关信息。沿用 Docker 官网的一句话：

A container only sees a network interface with an IP address, a gateway, a routing table, DNS services, and other networking details.

开放端口

默认不开放端口，创建或运行容器时通过指定参数来暴露端口。其实就是在宿主机创建一个防火墙规则，将容器的端口路由到容器宿主机。

1
2
3
4
5

docker create -p 192.168.1.100:8080:80

docker run -p 8080:80

docker run -p 8080:80/udp -p 8080:80/tcp

如果参数重包括 localhost ip，那么只有 Docker 宿主机可以访问到：

1

docker run -p 127.0.0.1:8080:80 nginx

容器互通可以不用开放端口，使用 bridge network 即可。

IP address

容器会从每一个连接到的 Docker 网络中获取一个 ip，Docker 守护进程为容器执行动态子网划分和 ip 地址分配，每个网络都有一个默认的子网掩码和网关。

启动的时候只能指定连接到一个网络，但可以通过命令使得运行中的容器连接到多个网络。

1

docker network connect

DNS

默认继承宿主机的 DNS 配置，定义在/etc/resolv.conf中。容器连接默认网桥的时候会拷一份这个文件。连接自定义网络的时候会使用 Docker 内置的 DNS 服务器，它将外部 DNS 查询转发给宿主机上配置的 DNS 服务器。

同理，在开启和创建的时候能通过参数配置 DNS 解析。

有时候需要在容器中访问宿主机，那么需要将宿主机的地址通过域名映射的方式传给容器。而在宿主机上/etc/hosts中的文件不会被容器继承，可以在启动时这样达到同样的效果。

1

docker run --add-host=docker:93.184.216.34 --rm -it alpine

Network drivers

Docker 的网络子系统是可插拔的，使用默认的驱动程序来提供核心的网络功能。

bridge

默认的网络驱动，如果没有特殊指定一个驱动，就会创建这种网络类型，它常用于应用程序跑在容器中，需要与其他在同一宿主机上的容器进行交流。

在网络方面，网桥是在网段（network segments）之间转发流量的链路层设备，可以是硬件设备，也可以是运行在主机内核的软件设备。就 Docker 而言，网桥使用软件网桥，允许连接到同一个网桥的容器进行通信，同时提供与未连接到该网桥的容器的隔离。Docker 桥接驱动程序会自动在宿主机中安装规则，使得不同网桥上的容器之间不能直接通信。

当然，它只适用于运行在同一个 Docker 守护进程宿主机上的容器，对于不同 Docker 守护进程宿主机上的容器之间的通信，可以在 OS 级别管理路由，或者用覆盖网络（overlay network）。

启动 Docker 时会自动创建一个默认的网桥，名字也叫 bridge，新启动的容器除非特殊指定，否则也会连接到它。也可以创建自定义的网桥，

自定义网桥与默认网桥

• 自定义网桥提供容器间的自动 DNS 解析。默认网桥的容器只能通过 ip 互相访问，而自定义的可以通过别名来互相解析，灵活度更高且更易迁移。

• 自定义网桥能做到更好的隔离。所有没指定–network 的容器都会连到默认网桥，不相干的容器间也能进行访问，可能造成不好的影响。

• 容器能随时与自定义网桥连接或分离。在容器的生命周期内可以随时连接或断开与自定义网桥的连接，但是要从默认网桥中移除容器，得停止容器并用不同的网络选项重新创建容器。

• 自定义网桥可单独进行配置 比如 MTU 和 iptables 规则，默认网桥的所欲容器都用相同的设置，配置网桥后得重启 Docker。

• 默认网桥上的容器共享环境变量

通过如下命令来创建或移除自定义网桥、亦或是将容器连接或断开与某个网桥的连接时，实际上发生的是 Docker 守护进程使用操作系统特定的工具去管理底层网络基础设施（如在 Linux 上添加或移除网桥设备或配置 iptables 规则）。

1
2

docker network create my-network
docker network rm my-network

默认网桥是 Docker 的历史遗留，不推荐在生产环境使用，而且配置它还需要额外的步骤，且存在技术缺陷（如上与自定义网络的差异）。

配置默认网桥

更改/etc/docker/daemon.json，更改后需要重启 docker 才会生效。

1
2
3
4
5
6
7
8
9

{
  "bip": "192.168.1.1/24",
  "fixed-cidr": "192.168.1.0/25",
  "fixed-cidr-v6": "2001:db8::/64",
  "mtu": 1500,
  "default-gateway": "192.168.1.254",
  "default-gateway-v6": "2001:db8:abcd::89",
  "dns": ["10.20.1.2","10.20.1.3"]
}

看官网说的：Docker network failures with more than 1002 containers · Issue #44973 · moby/moby · GitHub 由于 Linux 内核限制，当一个网桥连了一千多个容器时，会变得不稳定，容器的通讯可能会断开。

Overlay

Overlay 在多个 Docker 守护进程主机之间创建一个分布式的虚拟网络，使得连到该网络的容器能经过加密后相互通讯，Docker 透明处理每个数据包到目标主机以及目标容器的路由。

前文提到过，在 Overlay 网络方案下，容器网络自建虚拟子网且自置一个 IPAM，可以有无限的虚拟 ip 地址分配，每一个在虚拟子网内的容器都具备一个独立可访问的 ip，通过对外暴露端口（即 Kubernetes 的 nodeport），可以访问到任意一个容器。但是虚拟机需要与容器通讯时，当虚拟机需要访问容器时，需要一层 NAT 网络转换，且无法指定某个容器实例，相当于随机网络访问。

Host

移除容器与宿主机的网络隔离，直接使用宿主机的网络。使用这种模式，容器会共享宿主机的网络命名空间（network namespace），这意味着 Docker 守护进程不会为该容器分配 ip，而该容器也不需要手动去暴露端口，在容器中跑了 80 端口的应用，宿主机就能直接通过自己的 80 端口访问到。

主机网络模式（host）主要用来优化性能，能减少大量端口映射导致的网络地址转换（NAT）损耗，而且不需要为每个端口创建代理。

Linux 内核网络

iptables 在 SLB、Container、Istio 以及 Kubernetes 等服务中应用非常广泛，比如容器和宿主机端口映射、Istio 中的透明流量劫持、Kubernetes 核心组件 kube-proxy 的 IPVS 模式等等都是通过 iptables 实现的。此处简要介绍 iptables 以及 Netfilter。

Netfilter

iptables 的底层实现是 Netfilter，它提供一整套 hook 函数管理机制，使得数据包过滤、包处理（设置标志位、修改 TTL）、地址伪装、网络地址转化、访问控制、协议连接追踪等成为可能。五个主要的 hook 链包括：PRE_ROUTING、LOCAL_IN、IP_FORWARD、LOCAL_OUT、POST_ROUTING。主要原理如下：

当网卡接收到一个包送达协议栈时，会在这几个关键 hook 处判断是否有对应的钩子函数，然后进行处理。

在 Linux 接收网络数据包的过程中，IP 层接受数据包的入口处理便是经过了 NF_HOOK 的过滤，如果有复杂的 filter 规则，会在此处加大网络延迟。

1
2
3
4
5
6
7
8

// file: net/ipv4/ip_input.c
int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt, struct net_device *orig_dev)
{
    ...
    return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING, skb, dev, NULL,
           ip_rcv_finish);
    ...
}

iptables

iptables 是 netfilter 的操作接口，在用户空间管理应用于数据包的自定义规则，netfilter 则根据规则对应的策略处理数据包。实际上，iptables 的规则就是挂在 netfilter 钩子上的函数，用来修改数据包内容或过滤数据包，iptables 的表就是所有规则的逻辑集合。

对 Linux 稍有了解的都知道：iptables 就像繁忙城市交通中的交警，负责管理和控制网络数据包的流动。iptables 分为用户空间和内核空间两部分。用户空间的 iptables 命令向用户提供访问内核 iptables 模块的管理界面，而内核空间的 iptables 模块在内存中维护规则表，实现表的创建以及注册。

在 iptables 中，有四表五链的概念，每个表包含多个数据链，防火墙规则需要写入到具体的数据链中。

四表包括：

• raw 表：负责控制 nat 表中连接追踪机制的启用状况。

• managle 表：负责数据包的拆解、修改和再封装。

• nat 表：负责数据包的网络地址转换。包括 SNAT 和 DNAT，SNAT 解决内网地址访问外部网络的问题，通过在 POSTROUTING 修改源 IP 实现，DNAT 解决内网服务要能被外部访问到的问题，通过 PREPROUTING 修改目标 IP 实现。

• filter 表：负责数据包过滤功能，包括 drop、reject 等。

一个 IP 包经过 iptables 的处理流程如下，能直观看到各个表影响着不同的链：

通常情况下，一条 iptables 规则包含匹配条件和动作两部分，匹配条件如协议类型、四元组元素等，匹配条件可以组合，动作主要包括：

• DROP：直接丢弃数据包

• REJECT：返回 connection refused 或 destination unreachable 报文

• QUEUE：将数据包放入用户空间队列，供用户空间程序使用

• RETURN：跳出当前链，不再匹配后续规则

• ACCEPT：允许数据包通过

• JUMP：跳转到其他自定义链继续执行

以下是 iptables 防火墙的规则链，Chain INPUT 表示处理进入计算机到数据包，Chain FORWARD 用于处理通过计算机转发到数据包，Chain OUTPUT 处理离开计算机的数据包，Chain DOCKER 用于处理与 Docker 容器相关的数据包，其中 ACCEPT 表示允许任何源的目标端口为 ssh 的 TCP 包通过目标为 172.17.0.3 的主机（容器），即允许 SSH 连接到 Docker 容器。

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
43
44
45
46
47
48
49
50
51
52
53

[root@harbor ~]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
INPUT_direct  all  --  anywhere             anywhere            
INPUT_ZONES_SOURCE  all  --  anywhere             anywhere            
INPUT_ZONES  all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere             ctstate INVALID
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
FORWARD_direct  all  --  anywhere             anywhere            
FORWARD_IN_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_IN_ZONES  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES  all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere             ctstate INVALID
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
OUTPUT_direct  all  --  anywhere             anywhere            

Chain DOCKER (5 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.17.0.3           tcp dpt:ssh

网络虚拟化

主要技术是 Network namespace，以及各类虚拟设备如 Veth、Linux Bridge 等，它们彼此协作，将独立的 namespace 连接形成一个虚拟网络。

Network namespace

namespace用于 Linux 内核隔离内核资源，其中 network namespace 则用于隔离网络资源。它能创建多个隔离的网络空间，通过man ip-netns可以知道：该网络空间内的防火墙、网卡、路由表、邻居表、协议栈与外部都是独立的（逻辑上），不管是虚拟机还是容器，当运行在独立的命名空间时，就像是一台单独的主机一样。

“network namespace is logically another copy of the network stack, with its own routes, firewall rules, and network devices.”

创建网络命名空间可以用 ip，此处创建了 ns1 和 ns2 两个命名空间，可以看到只有一个 loopback 的网络设备：

1
2
3
4
5
6
7
8
9
10
11

[root@harbor ~]# ip netns add ns1
[root@harbor ~]# ip netns add ns2
[root@harbor ~]# ip netns
ns2
ns1
root@harbor ~]# ip netns exec ns1 ip link list
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
[root@harbor ~]# ip netns exec ns2 ip link list
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

或者使用 nsenter 进入对应的 netns 查看（不要忘记 exit）：

1
2

sudo nsenter --net=/var/run/netns/ns1 bash
sudo nsenter --net=/var/run/netns/ns2 bash

创建一对虚拟网卡，将 veth pair 一端放入 ns1，另一端放入 ns2：

1
2
3
4
5
6
7
8
9
10
11
12
13

[root@harbor ~]# ip link add veth1 type veth peer name veth1-peer
[root@harbor ~]# ip link set veth1 netns ns1
[root@harbor ~]# ip link set veth1-peer netns ns2
[root@harbor ~]# ip netns exec ns1 ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2739: veth1@if2738: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a2:48:9b:37:b0:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
[root@harbor ~]# ip netns exec ns2 ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2738: veth1-peer@if2739: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 16:94:b7:58:e9:3e brd ff:ff:ff:ff:ff:ff link-netnsid 0

由于初始时网卡状态为 DOWN，需要启用网卡并配置 ip 地址：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

[root@harbor ~]# ip netns exec ns1 ip addr add 172.16.0.1/24 dev veth1
[root@harbor ~]# ip netns exec ns1 ip link set dev veth1 up
[root@harbor ~]# ip netns exec ns2 ip addr add 172.16.0.2/24 dev veth1-peer
[root@harbor ~]# ip netns exec ns2 ip link set dev veth1-peer up
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2739: veth1@if2738: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a2:48:9b:37:b0:37 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet 172.16.0.1/24 scope global veth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a048:9bff:fe37:b037/64 scope link 
       valid_lft forever preferred_lft forever
[root@harbor ~]# ip netns exec ns2 ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2738: veth1-peer@if2739: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 16:94:b7:58:e9:3e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.16.0.2/24 scope global veth1-peer
       valid_lft forever preferred_lft forever
    inet6 fe80::1494:b7ff:fe58:e93e/64 scope link 
       valid_lft forever preferred_lft forever

测试两个 namespace 是否互通：

1
2
3
4
5

[root@harbor ~]# ip netns exec ns1 ping 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=0.072 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=0.051 ms

Veth Pair

“veth devices are virtual Ethernet devices. They can act as tunnels between network namespaces to create a bridge to a physical network device in another namespace, but can also be used as standalone network devices.”

Veth（Virtual Ethernet devices）是 Linux 中通过软件模拟的硬件网卡设备，由于成对出现，也称为 Veth Pair。其实就像一根网线，假设 veth0 和 veth1 是一对 veth 设备，从 veth0 发送数据，那么 veth1 就会收到数据。它常常充当一个桥梁连接着各种网络设备，典型的有：两个 namespace 的连接、Docker 容器之间的连接等，以此构造出各种复杂的虚拟网络。实际上，本机网络 IO 中的 lo 回环设备也是用软件虚拟出来的设备，区别在于 veth 是成对出现的。

root 与 container 交互：

Linux Bridge

由于简单 veth 互联方案难以做到多个容器的互联，因此采用的是 veth pair + bridge，这也是容器互联经典操作。bridge 是软件模拟硬件交换机，它拥有多个虚拟端口，能将多个虚拟网卡连接在一起，通过自己的转发功能让这些虚拟网卡之间进行通信。bridge 与物理虚拟机类似，有自学习功能，在内存中维护了一张转发表，通过目标 MAC 地址来转发数据包。

需要注意的是 veth 在 bridge 端是不需要分配地址的，因为 bridge 是工作在二层上，只会处理以太包，包括 ARP 解析，以太数据包的转发和泛洪，而不会进行三层（IP）的处理，因此不需要三层的 IP 地址。

路由

如果两个 namespace 处于不同的子网中，就无法通过作用于二层的 bridge 进行连接，只能通过路由器进行三层转发。所谓路由其实很简单，就是选择哪张网卡将数据写进去，至于选择哪张网卡呢，规则在路由表中指定。Linux 拥有多张路由表，最常用的是 local 和 main。

local 路由表统一记录本网络命名空间的网卡设备 IP 的路由规则。

1
2
3

[root@harbor ~]# ip route list table local
local 61.174.x.y dev eth0 proto kernel scope host src 61.174.x.y
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1

其余基本存在 main 表中，可以用ip route list table local或者route -n看。

除本机外，转发也涉及路由过程，在上文 iptables 中提到，当 Linux 收到数据包发现不是本机的包可以通过查找路由表找到合适的设备将其转发出去。在 ip_rcv 中将包送到 ip_forward 函数中处理，最后在 ip_ouput 函数将包转发出去，整个过程经过了 PREROUTING、FORWARD 和 POSTROUTINE 三个规则。

单主机容器网络问题

有了以上基础，我们可以尝试回答几个问题：

如何虚拟化网络资源，使得容器认为它们每个都拥有专用的网络堆栈？

在 Linux 中，要虚拟化网络资源以使容器认为每个都拥有专用的网络栈，可以通过使用网络命名空间（netns）和虚拟以太网设备（veth）实现。网络命名空间创建了独立的网络栈，每个容器可以与一个网络命名空间关联，从而实现网络隔离。veth 设备成对出现，连接主机的根网络命名空间（root netns）与容器的网络命名空间，使容器在通信时表现得好像拥有独立的网络栈，有效地利用网络资源，确保各个容器之间的网络环境隔离。

如何在容器之间实现隔离与通信，确保良好的容器互操作性？

为了在容器之间实现隔离与通信，我们可以利用 Linux 的网络命名空间（netns）和虚拟以太网设备（veth）。通过网络命名空间，每个容器都可以拥有独立的网络栈，从而实现隔离。然后，使用虚拟以太网设备将这些容器连接到一个虚拟网络交换机（bridge），使它们处于同一以太网段内，实现容器之间的通信。虚拟交换机会转发容器之间的数据包，保证良好的容器互操作性。通过这种方法，我们可以在同一主机上运行多个容器，实现资源共享，并确保它们在隔离的同时能够相互通信。

容器如何与外部网络连接？

为了使容器与外部网络连接，我们需要创建一个虚拟交换机（bridge），并将容器的虚拟以太网设备（veth）连接到该交换机。这样，容器之间可以相互通信，同时也可以通过交换机连接到主机和外部网络。为了实现这一连接，我们需要为交换机分配 IP 地址，并将其设置为容器的默认网关。同时，启用网络地址转换（NAT）功能，以便在容器发送到外部网络的数据包上替换源 IP 地址为主机的外部接口地址，从而使外部网络可以回复数据包给容器。最后，如果需要将容器的某个端口发布到主机的接口上，可以使用 iptables 进行端口转发，将到达主机特定端口的数据包重定向到容器的对应端口。通过这些步骤，我们可以实现容器与外部网络之间的连接，使容器能够与外部服务通信，并让外部网络能够访问容器的特定端口。

总结

本篇文章主要介绍容器网络，从容器网络的演变历史到 Docker 官网的一些描述，再到 Linux 内核网络、网络虚拟化来探究容器的大致底层实现原理，最后回答了单主机容器网络的几个问题。笔者在前一段时间深入学习过 Linux 网络相关知识，本以为容器网络无非是使用到几条命令，官网以及书上的几个简短说明这么简单，在翻阅参考资料与深入学习的过程中，笔者才发现容器网络有着非常庞大且复杂的体系，由于阅历与经验有限，文中多数部分都只是简单介绍就略过了。当然，此篇也只是初探开篇，后续会更深入理解容器网络相关的知识。

参考

• DaoCloud-容器网络的发展与演进

• Container Networking Is Simple!

• Networking overview

• Overlay 与 Underlay

• Computer Networking Basics For Developers

• 深入架构原理与实践 | 深入架构原理与落地实践

为什么选择 LDAP

众所周知，数据存储有诸多类型，包括但不限于 NoSQL 类如 Redis、MongoDB 等，RDBMS 类如 MySQL、PostgreSQL 等，那么为什么要选择 LDAP 呢？

如果选择 NoSQL，基本上就将自己限定在了某种类型的数据库中，因为每种 NoSQL 数据库都有自己的协议。在 NoSQL 数据库中，包括多个种类，例如键值存储、文档数据库、列存储和图形数据库等。而每种类型的数据库都有自己独特的工作方式和协议。选择其中一种数据库意味着你将与这种数据库的特定协议绑定在一起，不同类型的 NoSQL 数据库之间的协议可能不兼容。

以 Redis 和 MongoDB 为例，Redis 使用一种简单而高效的文本协议与客户端进行通信，这个协议被称为 Redis 协议或 RESP（Redis Serialization Protocol）协议，MongoDB 则使用一种称为 MongoDB 协议的二进制协议与客户端进行通信。假设你的应用程序现在使用 Redis 作为数据存储，客户端与 Redis 之间的通信依赖于 Redis 的协议。如果你要将 Redis 服务器替换为 MongoDB 服务器，你需要确保所有的客户端应用程序都能够适应 MongoDB 的协议，否则它们没办法和 MongoDB 服务器进行通信。

为了解决这个问题，可以通过写一层 API 兼容层来兼容客户端应用程序与多种 NoSQL 服务器的通信，但不同的 NoSQL 存储的应用场景不同，写个兼容层还不如直接选择一个满足需求的存储来使用。

如果选择关系型数据库，虽然使用了 SQL，更加标准化，但仍然需要更新客户端应用程序来确保与新的数据库进行通信。此外，不同的关系型数据库的数据类型、特定函数、事务处理可能不同，而且大部分都对 SQL 有独特的解释和实现方式，所以在迁移数据库时可能还需要进行调整和优化。

RFC 4511 明确定义了 LDAP 协议，其中包括客户端如何编码请求、服务端如何编码响应等，其中提供了很多种客户端和服务端的 API，所以不会绑死在一种客户端或服务端的 API 上。

LDAP 的特性

LDAP 经过多年的迭代，已经非常成熟，但它还在不断发展。最近的一个版本 LDAP v3 官方发行于 1997 年的十二月。

轻量

LDAP 是一个 X.500 的轻量级版本，使用 ASN.1BER 编码（一种用于高效编码和解码的紧凑的二进制格式），比起 HTTP 用的 JSON 或 XML 等还要更精简。

LDAP 使用持久连接与 directory server 通信，而许多现代基于 HTTP 的协议只是使用相对短暂的连接，LDAP 的连接却可以存活数小时或数天更长时间。基于 xxx，我们可以认为 LDAP 的连接更轻量级。

安全

LDAP Directory Server 通常被用作为认证库，和存储敏感信息，比如密码和账号信息等。LDAP 中包含了大量密码策略功能，如 strong envoding mechanisms 和 contraints，能够防止用户选择弱类型密码，也包括通过 SASL 对各种认证类型的支持，还包括通过 one-time passwords 等实现 two-factor 选项等。

此外，LDAP 还提供细粒度的访问控制支持，限制任何个人用户能够以哪些方式访问哪些 entries、attributes 和 values。基于 SQL 和 NoSQL 的应用通常用单个账户直接对数据存储操作，而 LDAP 应用程序通常作为终端用户来操作，能更加方便地限制访问和审计追踪。

基础概念

Directory Servers

一种网络数据库，以条目树形式存储数据。关系型数据库用的是由行列组成的表格，所以 Directory Servers 可以认为是一种 NoSQL 数据库。

虽然所有 Directory Servers 都支持 LDAP，但由于 LDAP 是一个开放的标准协议，所以有些服务器提供了对其他附加协议的支持，能够用于与数据进行交互，包括 X.500、命名服务协议如 DNS 和 NIS、基于 HTTP 的协议如 DSML 和 SCIM 以及其他专有的协议如 Novell 的 DNS。

Directory Servers - ldap.com

Entries

一个 LDAP 条目（entry）是关于一个实体信息的集合，每个条目由三个主要部分组成：一个分区名（distinguished name），一个属性集合（attributes）和一个对象类的集合（object classes）。

DNs 和 RDNs

一个条目的专有名称被称为DN，唯一表示该条目以及该条目在目录信息树（DIT，directory information tree）中的位置，有点像文件系统中的文件路径。

一个 LDAP DN 由零个或多个元素组成，称为相对专有名称（RDN）。每个 RDN 由一个或多个属性 - 值对组成，如uid=john.doe表示一个 RDN 由一个叫 uid 的属性组成，它的值为 john.doe，如果有多个键值对组成，则用加号分开，如uid=john.doe+sn=Doe。

不包含键值对的 DN 被称为 null DN，它引用了一种特殊类型的条目，称为根 DSE，提供关于 Directory Servers 的内容和能力的信息。

如果一个专有名称由多个相对专有名称组成，那么这些 RDN 的顺序决定了它们在目录信息树中的位置。RDN 之间用逗号分隔，每个 RDN 代表层次结构中的一个级别，按照从上到下的顺序（也就是离树根更近的位置）。如果从一个 DN 中移除一个 RDN，就相当于得到了该 DN 的父级 DN。举个🌰，DN“uid=john.doe,ou=People,dc=example,dc=com”包含了四个 RDN，其中父级 DN 是“ou=People,dc=example,dc=com”。

LDAP DNs and RDNs

Attributes

属性（Attributes）保存了一个条目的数据。每个属性都有一个属性类型（attribute type），零个或多个属性选项（attribute options），以及一组值（values）组成的实际数据。

属性类型是规定 LDAP 客户端和服务器如何处理属性的规则。属性类型必须有一个唯一的标识符（OID）和一个或多个名称来引用该属性。属性类型还定义了属性的数据类型和比较规则。它还可以指定属性是否可以有多个值，以及属性是用于保存用户数据还是服务器操作。

属性选项用于提供一些关于属性的额外信息，但并不经常使用。例如，属性选项可以用于在不同语言中提供属性值的不同版本。

Object Classes

对象类（Object classes）是一种模式元素，用来定义一组可能与特定类型的对象、过程或其他实体相关联的属性类型集合。每个条目都有一个主要对象类，它表示该条目所代表的对象类型（例如，人员信息、群组、设备、服务等），还可以有零个或多个附加对象类，用于提供该条目的其他特征。

就像属性类型一样，对象类也需要一个唯一的标识符，还可以有一个或多个名称。对象类还可以定义一组必需的属性类型（表示具有该对象类的条目必须包含这些属性）和/或一组可选的属性类型（表示具有该对象类的条目可以选择性地包含这些属性）。

想象一下，对象类就像一个描述对象类型及其属性的模板。每个对象都可以根据所属的对象类来确定应该具备哪些属性。

Object Identifiers (OIDs)

对象的唯一标识，是一个字符串。OID 由一系列用句点分隔的数字组成（例如，“1.2.840.113556.1.4.473”是表示服务器端排序请求控件的 OID）。在 LDAP 中，OID 用于标识模式元素（如属性类型、对象类、语法、匹配规则等）、控件以及扩展请求和响应。对于模式元素，还可以使用用户友好的名称来代替 OID。

简而言之，OID 是用于在 LDAP 协议和相关系统中唯一标识和区分不同组件和功能的特定标签。

Search Filters

搜索过滤器（Search Filters）用于定义标识包含特定信息的条目的条件。有很多种：

• Presence filters，标识指定属性至少有一个值的条目
• Equality filters，标识指定属性有特定值的条目
• Substring filters，标识指定属性至少有一个值与被给定子字符串相匹配的条目
• Greater-or-equal filters，标识指定属性至少有一个值被视为大于或等于给定值的条目
• Less-or-equal filters，标识指定属性至少有一个值被视为小于或等于给定值的条目
• Approximate match filters，标识指定属性的值与给定值近似相等的条目。近似相等的判断取决于服务器，可能是发音相等或其它的
• Extensible match filters，用于提供更高级的匹配类型，包括使用自定义匹配规则和/或匹配条目 DN 中的匹配属性
• AND filters，标识与 AND 内部封装的所有过滤器都匹配的条目
• OR filters，标识与 OR 内部封装的至少一个过滤器匹配的条目
• NOT filters，对封装的过滤器结果进行否定，相当于取反

匹配规则是用于执行匹配操作的逻辑，在属性类型定义中进行指定。不同的匹配规则可能使用不同的逻辑来进行确定。匹配规则定义了如何根据特定的逻辑规则进行匹配，以便在搜索和过滤操作中进行正确的比较和匹配。

Search Base DNs and Scopes

所有搜索请求都包括一个基本的 DN 元素，用于指定在哪个 DIT 部分查找匹配的条目，以及一个范围（scope），用于指定应考虑该子树的程度，不同的范围决定了搜索操作的深度和范围。定义的搜索范围包括：

• baseObject 范围（base）表示只应考虑搜索基本 DN 指定的条目
• singleLevel 范围（one/onelevel）表示只应考虑搜索基本 DN 的直接下级条目（但不包括基本条目本身）
• wholeSubtree 范围（sub）表示应考虑搜索基本 DN 指定的条目以及所有在其下方的条目（到任意深度）
• subordinateSubtree 范围表示应考虑搜索基本 DN 下方的所有条目（到任意深度），但不包括搜索基本条目本身

Modifications and Modification Types

修改请求用于向条目中添加、删除或替换属性值。每个修改都有一个类型，用于指定进行何种操作，例如添加、删除、替换或增量。通过修改请求，可以对 LDAP 服务器中的数据进行更新和修改。

• 添加（add）修改类型表示应将一个或多个属性值添加到条目中。这可以用于添加全新的属性，或向现有属性添加新值。对于添加修改类型，必须至少指定一个属性值。
• 删除（delete）修改类型表示应从条目中删除一个或多个属性值，或者整个属性。如果删除修改包括一个或多个属性值，那么只会删除这些值。如果删除修改不包括任何值，则会删除整个属性。
• 替换（replace）修改类型表示应使用新集合（可能包含条目中已有的值）替换指定属性的值集合。如果替换修改有一个或多个属性值，则这些值将用于相关的属性。如果替换修改没有任何值，且如果存在该属性，它将从条目中移除。
• 增量（increment）修改类型表示应将指定属性的整数值增加指定的数量（如果增量值为负，则减少）。

LDAP URLs

LDAP URL 是一种用于定位目录服务器和条目以及搜索条件的标识符，在 LDAP 协议中被广泛用于引用和链接到目录服务器中的数据。它封装了信息，可以用于引用目录服务器、特定条目和搜索标准，以便在目录服务器中识别匹配的条目。

Controls

控制项是 LDAP 请求或响应中的一段额外信息，用来提供更多关于请求或响应的信息，或者改变服务器（对于请求）或客户端（对于响应）对其的处理方式。就像我们可以在请求中附带一张“便条”，告诉服务器我们需要对数据进行特殊处理，或者在响应中附带一些额外的指示。比如，服务器端排序请求控制项可以告诉服务器在将搜索结果返回给我们之前，先按照特定的方式对结果进行排序。

控制项有三个元素：

• 唯一标识符（OID），用于标识控制项类型
• 关键性，用于指示控制项是否是请求的关键部分。关键性为“true”表示控制项是请求的关键部分，如果服务器无法支持控制项，应拒绝请求。关键性为“false”表示控制项更像是请求的“额外要求”部分，如果服务器无法支持控制项，则应继续处理操作，就好像没有包含该控制项一样。如果服务器确实支持请求范围内的控制，那么关键性就不会起作用
• 可选值，用于提供控制项处理所需的附加信息。例如，对于服务器端排序请求控制项，控制值应指定期望的排序顺序。控制项的具体编码方式会根据控制项的类型而有所不同

Referrals

简单来说，引荐（referral）是一种 LDAP 响应，表示服务器无法处理所请求的操作，但建议在其他地方尝试（例如在不同的服务器或 DIT 中的不同位置），可能会成功。引荐可能出现的原因包括：

• 客户端请求的操作针对的条目在连接的服务器中不存在，但服务器能够建议该条目可能存在的位置
• 客户端请求的操作针对的条目在服务器中确实存在，但由于某种原因，服务器目前无法处理该请求。例如，客户端向只读副本发送写入请求，副本可以将请求重定向到可写服务器
• 数据中包含一种特殊类型的引荐条目（有时称为“智能引荐”），每当客户端请求该条目或其下属内容时，服务器根据该条目的内容生成引荐

Alias Entries

简单来说，别名条目是一种特殊类型的条目，类似于符号链接在文件系统中指向另一个文件。

别名条目主要用于搜索操作，它可以使位于 DIT 中的一个位置的条目在另一个位置上出现。在某些情况下很有用，例如，当一个条目在特定子树中的存在用于确定群组成员身份或表示某种授权目的时。搜索请求包括一个元素，指示如何处理搜索过程中遇到的任何别名。

针对别名条目的非搜索操作不会跟随别名进行操作。别名不能作为绑定操作的目标标识。别名必须是叶子条目，因为无法在别名条目下添加条目。

需要注意的是，并非所有目录服务器都支持别名。如果应用程序打算与广泛范围的目录服务器兼容，应避免使用别名。

LDAP 模式

在关系型数据库中，模式包含了数据库结构的信息，包括表结构的信息、关于每个表的列的信息以及每个列的数据类型和约束。在 LDAP 中，模式提供了很多类似的信息，但是由于信息的排列方式关系型数据库不同，表达方式也不同。

一个 LDAP 模式包含多个类型的元素，每个模式都必须包含以下几个：

• Attribute Syntaxes 定义了能在目录服务器中表示的数据类型
• Matching Rules 定义了能对 LDAP 数据进行比较的种类
• Attribute Types 定义了可存储在条目中的命名信息单位
• Object Classes 定义了可以在包含该对象类的条目中使用的属性类型的命名集合，以及这些属性类型哪些是可选的，哪些是必选的

一些额外的元素：

• Name Forms，可用于限制可作为特定类型条目的命名属性的属性种类
• DIT Content Rules，可用于增强对象类的定义，进一步指出必须、可选和不能出现在特定类型的条目中的属性种类
• DIT Structure Rules，可用于定义服务器中允许存在的层次关系的信息
• Matching Rule Uses，可用于对可使用特定匹配规则的属性种类加限制

操作类型

Bind

绑定操作（Bind）是用于让客户端在目录服务器上进行身份认证的方式。它确保客户端能够证明自己的身份，并建立一个用于后续操作的授权身份，并指定客户端将使用的 LDAP 协议版本。

认证通常包括两个部分：确定是谁进行认证以及提供一些证据来证明身份（通常是只有用户自己知道的密码、证书、硬件或软件令牌或生物特征信息等）。在进行绑定操作时，服务器可能还会执行其他步骤，如检查密码策略和满足其他限制条件，以确保绑定成功。

LDAP 绑定请求提供了两种认证方式：简单认证和SASL 认证。简单认证是通过使用帐户的唯一标识（DN）和密码来进行身份验证。密码以明文形式传输，因此强烈建议只在加密连接下使用简单认证。匿名简单绑定（anonymous simple bind）是通过提供空的 DN 和密码来进行的。

SASL 认证使用了一种名为简单认证和安全层（SASL）的标准。它是一个可扩展的框架，可以将各种认证机制集成到 LDAP 中。SASL 认证通过使用一种特定的机制和编码的凭据来完成。某些机制可能需要多次请求和响应来完成完整的认证过程。

LDAP 绑定请求包含三个要素：

• 客户端希望使用的 LDAP 协议版本。目前大部分新的应用都是使用 v3，少部分非常老旧的客户端使用 v2。
• 认证用户的 DN。对于匿名简单认证，这应该为空；对于 SASL 认证，由于大多数 SASL 机制在编码的凭据中标识目标帐户，因此通常为空。对于非匿名简单认证，它必须为非空值。
• 认证用户的凭据（一般是密码）。对于简单认证，这是指定绑定 DN 的用户的密码（或匿名简单认证的空字符串）。对于 SASL 认证，这是一个编码值，其中包含SASL 机制名称和可选的编码 SASL 凭据集。

如果 LDAP 客户端在没有进行绑定的情况下发出其他类型的请求，则客户端将被视为未经身份验证。这与匿名简单绑定（使用空绑定 DN 和空密码）导致的身份验证状态相同，也是绑定操作失败导致的身份验证状态。

当简单绑定操作完成时，服务器将返回一个基本响应，其中包括结果代码、可选的匹配 DN、诊断消息、引荐和/或响应控制。SASL 绑定响应还可以包括编码的服务器 SASL 凭据，用于后续处理。对于需要多个请求/响应周期的 SASL 机制，除了最后一个响应之外，所有响应都将包含一个“SASL 绑定正在进行中”的结果代码，以指示身份验证过程尚未完成。

Search

LDAP Search 操作能检索匹配给定条件的条目的数据。请求参数包括：

• base DN：检索的起始点，必须提供，但可能是 null DN。操作将会在该指定子树检索。
• search scope：目标子树的检索范围，支持以下几个选项
  • baseObject（base）：搜索操作只会在指定的条目上进行，不会扩展到它的子条目。
  • singleLevel（one）：搜索操作仅限于基础条目的直接子级，不包括它的其余子级和它自己。
  • wholeSubtree（sub）：整个子树搜索将包括搜索基础条目以及其下的所有子孙级条目，但不包括根 DSE（如果搜索基础 DN 为空）。
  • subordinateSubtree（subordinates）：从搜索基础的下一级开始，包括其所有子级和子孙级条目，但不包括搜索基础条目本身。
• DerefAliases：别名解引用行为，指明了服务器在检索过程中应该如何处理遇到的别名。以下是支持的解引用行为：
  • neverDerefAliases：表示服务器在处理搜索时应解引用遇到的任何别名。
  • dereflnSearching：表示服务器不应尝试解引用搜索基础条目，但应解引用范围内遇到的任何别名。
  • derefFindingBaseObj：表示如果作为搜索基础的条目是一个别名，则服务器应解引用该别名，但不应解引用范围内遇到的任何别名。
  • derefAlways：表示如果作为搜索基础的条目是一个别名，则服务器应解引用该别名，并且应解引用范围内遇到的任何别名。
• Size limit：限制检索结果中返回条目的最大数量。如果为 0 则说明不限制。服务端可能也会对检索结果进行限制，此时取二者较小的那个。
• Time limit：检索过程的时间限制，相当于请求超时，单位为秒。服务端可能也对检索时间进行限制，此时同上取二者较小的那个。
• typesOnly：一个 flag，如果设置为 true，则表示匹配搜索条件的条目应只返回包含属性描述的条目，而不包含这些属性的值。如果将其设置为 false，则表示返回的条目应包含属性值。
• search filter：过滤器，用于检索匹配条件，上文有提到过。
• attributes：一个属性集合，返回的条目只包含这些属性。然后还有些特定值：

当目录服务器接收到一个有效且经过授权的搜索请求时，它将识别出在指定范围内与给定过滤器匹配的任何条目。所有这些条目（或者至少是请求者有权限检索的条目）将以搜索结果条目消息的形式返回给客户端。每个搜索结果条目消息将包含匹配条目的 DN，以及该条目中包含的零个或多个属性，这取决于搜索请求中请求的属性集合以及请求者有权限检索的属性集合。如果搜索请求的 typesOnly 值为 true，则这些属性将返回而不包含其值；否则，属性将返回与请求者有权限检索的所有值。

比较有意思的是如果服务器在搜索过程中确定可能有其他服务器中与搜索条件匹配的条目，那么服务器还可以返回一个或多个搜索结果引用消息，其中包含引荐 URI，客户端可以选择是否跟随。

一旦服务器返回了所有适当的搜索结果条目和搜索结果引用消息，它将返回一个搜索结果完成消息，表示该搜索操作的所有处理已完成。这个搜索结果完成消息是一个基本的 LDAP 响应，包括一个结果代码，以及可选的匹配 DN、诊断消息、引荐和/或响应控制。

实践

envoy-go-ldap-auth

GitHub - mosn/envoy-go-ldap-auth: Envoy golang filters that will be provided in golang hub

笔者近期在研究MOSN时，为MOSN社区贡献了一个基于MoE框架的LDAP过滤器，旨在为Envoy集成LDAP认证功能，感兴趣可以看一下。基于MoE框架的Go Filter有着以下几点好处：

• 动态加载Go Filter，无需重新编译Envoy，节省开发与部署时间。
• 可以使用Go的全部特性，享受Go生态带来的便利。
• 保证了内存安全、兵法安全以及沙箱安全。

总结

本文介绍了 LDAP 协议，为什么选择 LDAP，以及 LDAP 的特性、基础概念、模式和操作类型等。LDAP 在各行各业中得到广泛应用，包括企业组织、教育机构、政府部门等。它被用于集中管理用户身份和权限，实现单点登录、身份验证和访问控制等功能，加上跨平台的特性使得 LDAP 成为跨多个系统和应用集成的标准选择。关于 LDAP 的内容还有很多本文没有介绍，详情可以见参考。

参考

• ldap.com

对杭州的第一印象

记得刚来杭州的时候很冷，刚下绿皮就哆嗦着穿多一件卫衣，现在杭州却热得有点受不了了，感觉和广州不分高下。杭州给笔者的第一印象是干净，到杭州那一天的下午，笔者去办杭州银行的银行卡，一路上发现和广州的最大区别是杭州非常干净，没有看到广州街道上随处可见的垃圾，但是沿路上都没见到垃圾桶（

打破第一次

打破了很多人生第一次

• 第一次一个人来到完全陌生的城市

• 第一次独立生活

• 第一次参与全职工作

• 第一次正式参与开源

• 。。。

工作方面，笔者是第一次实习。虽然是几百人的小公司，但是实习体验还是 OK 的。脱离学校后，真正地接触到生产环境，对各种利弊权衡有了更深的把握，对互联网公司的工作流程也有了真实的体验。

社交方面

虽说职场上不得与同事交心，但是组里的人都挺好的，一起工作也很快乐，至少在前两个月没什么压力。只可惜五月初 Leader 和导师都调去带新组了，其实还是挺想念他们的。

笔者早在一个玩具开源项目 GoFound 的微信交流群中认识了一个在杭州工作的群友，在来到杭州后也成功线下面基了，一起搓了好几顿。此外，笔者也有个高中同学在杭电就读，期间也约出来到处逛了几次。在实习期间也认识了几个同实习的朋友，一起交流学习、娱乐吹水和吃饭。在五月中旬，也有两个认识的同校好友来杭州实习，六月时更是有一个师弟也来杭州实习了，因此总体来看其实也没那么孤单。

穷游

其实实习的薪资并不高，在高物价的杭州自然也攒不下什么钱，索性来杭州旅游了。现在回想起来，其实开销大处都在于约饭，由于有地铁直达，想要穷游杭州各个景点其实花费不过几块钱地铁交通费而已。

西湖

印象中是到了杭州的第二天就去看了，第一次去坐地铁 + 公交，可惜路线和时间规划有点问题，到了西湖比较偏的地方，虽然人比较少，但是太阳已经要下山了，手机也因为奔波快没电了，所以错过了西湖日落= =，匆匆观望一下就走了。

第二次去看西湖也是晚上，本想着是去湖滨步行街那边散散步的，发现西湖在附近，走着走着就到了。湖滨步行街的人太多了==，特别是龙翔站那里，不想再去体验第二次。走在西湖边，走了一路吃了一路狗粮。

良渚

由于笔者对古历史的认知匮乏，笔者对良渚的感觉是“啥也没有”。很多东西虽然有介绍，但经过太长时间的迭代后，最终也只是以土坡的形式呈现。历史的奥妙也在于此，让人只觉时光流逝。

里面的小鹿真可爱，鸽舍的鸽子走起路来脑袋一晃一晃的，感觉太傻了。

大明山

没想到五一假期这里的人还挺少的，唯一的遗憾是同行伙伴的钱包身份证全在路上掉了。由于出行的计划没安排好，大巴站点的时间有点对不上，所以只能坐大巴到一半后只能打车去，回杭州也是直接打车的，在打车上就花了好几百米。

山上挺多矿洞的，里面很冷，吹的风很凉快。大明湖看起来真不错，可惜貌似没有路能走下去。

开源与学习

这段时间主要学了一下 Rust 和一些关于权限控制方面的知识，也正式踏出了开源贡献的第一步。其实在接触 Github 至今我已经为多个 repo 贡献了文档或 typo 修复，尽管看的代码也很多，但是却很少去贡献代码。

五月份的时候为学校团队使用已久的 Gitea 提出了第一个 PR，被合并的时候是真的开心，也希望后面能继续为 Gitea 以及其它开源项目贡献代码。

New webhook trigger for receiving Pull Request review requests by Makonike · Pull Request #24481

短轮训->长轮训->基于流->WebSocket

TCP 长连接就是 WebSocket 的基础，但是如果是 HTTP 的长连接，本质上还是 Request/Response 消息对，仍然会造成资源的浪费、实时性不强等问题

特点

• 建立在 TCP 之上

• 与 HTTP 有良好兼容性

• 没有同源限制，客户端可以与任意服务器通信

• 标识符是ws/wss，服务器地址是URL

• 可以发送文本和二进制数据

• 数据格式轻量，性能开销小，通信高效。连接创建后，ws 客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的情况下，服务端到客户端的包头只有 2~10 字节（取决于数据包长度），客户端到服务端的的话，需要加上额外的 4 字节的掩码。而 HTTP 协议每次通信都需要携带完整的头部；

建立连接

WebSocket 的目的是取代 HTTP 在双向通信的场景下使用，所以有些实现方式也是基于 HTTP 的（比如默认端口为 80/443），有向下兼容的意思。

客户端发起协议升级

1
2
3
4
5
6
7
8
9

GET / HTTP/1.1
Host: localhost:8080 // 前两行都和HTTP的Request起始行一样
Origin:http://127.0.0.1:3000   // 标明原始域，防止跨站攻击
Connection: Upgrade // 表示升级协议。
Upgrade: websocket    // 表示升级到websocket。upgrade是HTTP1.1用来定义转换协议的header域
Sec-WebSocket-Version: 13 // 表示websocket的版本
// 如果服务端不支持该版本，则返回一个Sec-WebSocket-Versionheader，包含服务端支持的版本号
Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw== 
// 与后文服务端响应首部的Sec-WebSocket-Accept配套，提供基本的防护。如恶意连接或无意义连接

服务端响应协议升级

101 表示服务器收到了客户端切换协议的请求，并且同意切换到此协议。

1
2
3
4

HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

服务端回应的 HTTP 状态码只能在握手阶段使用。过了握手阶段后，就只能采用特定的错误码。

Sec-WebSocket-Accept 计算

根据客户端请求首部的 Sec-WebSocket-Key 进行计算。

• 将 Sec-WebSocket-Key 跟 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接

• 通过 SHA1 计算出摘要，并转成 base64 字符串

toBase64( sha1( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 ) )

Sec-WebSocket-Key/Accept 作用

主要用于提供基础防护，减少恶意连接和意外连接

• 为了避免服务端收到非法 websocket 连接（如 http 客户端不小心请求 websocket 服务）。

• 确保服务端能理解 websocket 连接，客户端能通过 Sec-WebSocket-Key 来确保认识 ws 协议（服务端不仅需要处理 Sec-WebSocket-Key，还需要实现 ws 协议，否则没有意义）。

• 在浏览器中发起 ajax 请求，设置 Header 时，Sec-WebSocket-Key 以及其他相关 header 是被禁止的，防止 ajax 请求意外请求升级升级。

  • 以“Sec-”开头的 Header 可以避免被浏览器脚本读取到，这样攻击者就不能利用 XMLHttpRequest 伪造 WebSocket 请求来执行跨协议攻击，因为 XMLHttpRequest 接口不允许设置 Sec-开头的 Header。

• 可以防止反向代理返回错误的数据。

• Sec-WebSocket-Key 主要目的不是为了确保数据安全性，因为转换公式时公开的，主要预防一些常见的非故意意外情况。

只能带来基本保证，无法确保连接安全、数据安全、客户端/服务端是否合法。

Sec-WebSocket-Protocol 子协议

详情见：WebSocket API: Sec-WebSocket-Protocol (Subprotocol) header support

在笔者初识子协议时，曾用其作为 Token 的存放位置 qwq，因为 WebSocket 无法自定义请求头。实际生产场景中，可以通过 SubProtocol 区分不同的应用场景。比如笔者的应用场景有推送、协同两种，就能自定义 SubProtocol 去区分。

数据帧格式

通信的最小单位是帧 frame，由一个或多个帧组合为一条完整的消息 message

• 发送：将消息切割为多个帧，并发送给服务端

• 接收：组成一个完整消息

详细定义：RFC ft-ietf-hybi-thewebsocketprotocol: The WebSocket Protocol

数据帧统一格式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

• FIN 1bit

如果为 1，表示这是该消息的最后一个分片。否则为 0

• RSV1, RSV2, RSV3 3bit

一般情况下为全 0，用于客户端与服务端协商采用 WebSocket 扩展，值由扩展进行定义，如果出现非 0 值且没有使用扩展，则连接出错

• Opcode 4bit

操作代码，决定该如何解析后续 payload。如果操作代码未知，则接收端应断开连接。可选如下

1
2
3
4
5
6
7
8

%x0：表示一个延续帧。当Opcode为0时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片。
%x1：表示这是一个文本帧（frame）
%x2：表示这是一个二进制帧（frame）
%x3-7：保留的操作代码，用于后续定义的非控制帧。
%x8：表示连接断开。
%x9：表示这是一个ping操作。
%xA：表示这是一个pong操作。
%xB-F：保留的操作代码，用于后续定义的控制帧。

• Mask 1bit

表示是否要对 data payload 进行掩码操作。从客户端发向服务端要，从服务端发向客户端不用。当服务端接收到未进行掩码操作的数据，服务端应该断开连接

Mask 为 1，Masking-key 中应该定义一个掩码键 masking key，并用其对 data payload 进行反掩码。所有客户端发到服务端的帧，mask 都为 1

• Payload length 7bit

data payload 的长度，单位为字节。如果 patload length == x

1
2
3

x为0~126：数据的长度为x字节。
x为126：后续2个字节代表一个16位的无符号整数，该无符号整数的值为数据的长度。
x为127：后续8个字节代表一个64位的无符号整数（最高位为0），该无符号整数的值为数据的长度。

payload length 下面有扩展的长度。如果他超过 1 个字节，payload length 的二进制表达采用网络序（big endian，重要的位在前）

• Masking-key 32bit

Data playload length 不包含 masking-key

• Playload data x+y bytes

包含扩展数据和应用数据，其中扩展数据 x 字节，应用数据 y 字节

扩展数据：不协商使用就为 0。所有扩展数据都要声明扩展数据的长度，或者声明如何能计算出扩展数据长度。都在握手阶段协商好，如果扩展数据存在，那么 data payload length 就包含扩展数据长度

应用数据：任意的应用数据，在扩展数据之后。data payload length - 扩展数据长度即为应用数据长度

掩码算法

Masking-key 是客户端挑出的 32bit 随机数。

掩码和反掩码操作都用如下算法

定义：

1
2
3
4

original-octet-i：为原始数据的第i字节；
transformed-octet-i：为转换后的数据的第i字节；
j：为i mod 4的结果；
masking-key-octet-j：为mask key第j字节。

original-octet-i与masking-key-octet-j异或后得到transformed-octet-i

1
2

j = i mod 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j

掩码操作不会影响数据载荷的长度。

数据掩码作用

主要作用是增强协议安全性，但不是为了保护数据本身，因为算法本身就是公开的，且不复杂。实际作用是为了防止早期版本的协议中存在的代理缓存污染攻击（proxy cache poisoning attacks）等问题。

详细如下：Talking to Yourself for Fun and Profit

整个攻击过程分为两步：

攻击步骤一：

1. 攻击者浏览器 向 邪恶服务器 发起 WebSocket 连接。根据前文，首先是一个协议升级请求。

2. 协议升级请求 实际到达 代理服务器。

3. 代理服务器 将协议升级请求转发到 邪恶服务器。

4. 邪恶服务器 同意连接，代理服务器 将响应转发给 攻击者。

由于 upgrade 的实现上有缺陷，代理服务器 以为之前转发的是普通的 HTTP 消息。因此，当 邪恶服务器 同意连接，代理服务器 以为本次会话已经结束。

攻击步骤二：

1. 攻击者 在之前建立的连接上，通过 WebSocket 的接口向 邪恶服务器 发送数据，且数据是精心构造的 HTTP 格式的文本。其中包含了 正义资源 的地址，以及一个伪造的 Host（指向 正义服务器）。

2. 请求到达 代理服务器。虽然复用了之前的 TCP 连接，但 代理服务器 以为是新的 HTTP 请求。

3. 代理服务器 向 邪恶服务器 请求 邪恶资源（script.js）。

4. 邪恶服务器 返回 邪恶资源。代理服务器 缓存住 邪恶资源（url 是对的，且 Host 是 正义服务器 的地址）。

到这里，受害者可以登场了：

1. 受害者 通过 代理服务器 访问 正义服务器 的 正义资源。

2. 代理服务器 检查该资源的 url、host，发现本地有一份缓存（伪造的）。

3. 代理服务器 将 邪恶资源 返回给 受害者。

4. 受害者 卒。

整个过程最大的 Bug 点是“在 upgrade 协议实现上有缺陷的代理服务器（错把 Websocket 当做是普通的 HTTP 消息）”，而数据掩码也就是为了针对这类“愚蠢”的代理服务器。因为数据掩码在每次消息传输中都由客户端随机生成，经过掩码算法后，明文消息变成了不被识别的字节，代理服务器发现每次传来的消息都不同，那它只好选择通过，而不是做缓存处理。

如果没有这个掩码限制，攻击者只需要在网上放个钓鱼网站骗人去访问，就可以在短时间内展开大范围攻击。安全的范围很大，防止代理缓存污染攻击也算在安全范畴内，所以不要局限于一点，这样容易进死胡同。

数据传输

连接建立后，后续操作都是基于数据帧传递，根据 opcode 来区分操作类型

数据分片

WebSocket 接收方每收到一个数据帧都会根据 FIN 来判断是否已经收到消息的最后一个数据帧。此时 opcode 在数据交换的场景下表示数据类型，如 0x01 位文本，0x02 为二进制。0x00 表示延续帧 continuation frame，表示完整消息对应的数据帧还没接收完。

🌰：Writing_WebSocket_server

第一条消息表示发送的是文本类型，第二、三条消息表示完整消息未被接收完，第四条消息表示文本类型。

1
2
3
4
5
6
7
8

Client: FIN=1, opcode=0x1, msg="hello"
Server: (process complete message immediately) Hi.
Client: FIN=0, opcode=0x1, msg="and a"
Server: (listening, new message containing text started)
Client: FIN=0, opcode=0x0, msg="happy new"
Server: (listening, payload concatenated to previous message)
Client: FIN=1, opcode=0x0, msg="year!"
Server: (process complete message) Happy new year to you too!

心跳

引入TCP/IP的心跳、KeepAlive问题

对应 WebSocket 操作中的 ping 和 pong，opcode 分别为 0x9、0xA。

一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等

在绝大部分场景中，由客户端来发送心跳是最佳实践。考虑到 Session 残留的情况：TCP 的保活机制非常不灵敏，完全不适用于正常业务场景，所以使用底层代码库实现的 max_idle_time 来限制。

心跳保活与 idle_time

通过心跳保活与 WebSocket 底层实现库设置 idle_time 来使残余 Session 关闭。在笔者的设计中，在 WS 握手成功后的连接回调函数中，会为该连接对应的 Session 设置一个 max_idle_time，后续过程中，由客户端来发送心跳保活。

笔者业务中使用的是原生的 websocket 包，可以看到核心代码如下：

在建立连接后，如果当前 endpoint 对应的 SessionMap 没有 Session（意味着当前连接是第一个连接），会创建一个后台线程，然后注册当前 Session 到内存中的 sessions 中，这是一个 map，key 和 value 存放的都是 WsSession 实例。

其实上图走的是BackgroundProcessManager.getInstance().register(this);

在调用BackgroundProcessManager.getInstance().register(this)时，会开一个 WsBackgroundThread 线程，它的主要任务是每秒跑一次manager.process()，它会获取所有 process，并一一执行process.backgroundProcess()

对应到 WsWebSocketContainer 的实现，即获取每个 Session 的实例，调用 checkExpiration，下面代码贴在一起：

核心判断语句是：(timeout > 0 && (currentTime - lastActiveRead) > timeout && (currentTime - lastActiveWrite) > timeout)，它检查上次读/写活跃时间是否已经超过了设定的最长空闲时间 maxIdleTimeout，如果超过，则调用 doClose 回调函数，主动关闭 Session。

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

@Override
public void backgroundProcess() {
    // This method gets called once a second.
    backgroundProcessCount ++;
    if (backgroundProcessCount >= processPeriod) {
        backgroundProcessCount = 0;

        for (WsSession wsSession : sessions.keySet()) {
            wsSession.checkExpiration();
        }
    }
}

protected void checkExpiration() {
    // Local copies to ensure consistent behaviour during method execution
    long timeout = maxIdleTimeout;
    long timeoutRead = getMaxIdleTimeoutRead();
    long timeoutWrite = getMaxIdleTimeoutWrite();

    long currentTime = System.currentTimeMillis();
    String key = null;

    if (timeoutRead > 0 && (currentTime - lastActiveRead) > timeoutRead) {
        key = "wsSession.timeoutRead";
    } else if (timeoutWrite > 0 && (currentTime - lastActiveWrite) > timeoutRead) {
        key = "wsSession.timeoutWrite";
    } else if (timeout > 0 && (currentTime - lastActiveRead) > timeout &&
            (currentTime - lastActiveWrite) > timeout) {
        key = "wsSession.timeout";
    }

    if (key != null) {
        String msg = sm.getString(key, getId());
        if (log.isDebugEnabled()) {
            log.debug(msg);
        }
        doClose(new CloseReason(CloseCodes.GOING_AWAY, msg), new CloseReason(CloseCodes.CLOSED_ABNORMALLY, msg));
    }
}

至于更新 lastActiveRead 与 lastActiveWrite，自然会在读写时做更新。

1
2
3
4
5
6
7
8

protected void updateLastActiveRead() {
    lastActiveRead = System.currentTimeMillis();
}


protected void updateLastActiveWrite() {
    lastActiveWrite = System.currentTimeMillis();
}

以上就是 WebSocket 代码库 idle_time 实现清除参与 Session 的原理。

一句话来说：就是底层代码库会为 endpoint 创建 background 线程，每秒一次去 checkExpiration，主要检查 lastActiveRead 与 lastActiveWrite 是否距离当前时间已经超过了 maxIdleTimeout。

长连接实时推送网关

解决痛点

1. 技术栈不统一，开发和维护困难

2. WebSocket 实现分散在各个工程，与业务系统强耦合，其余业务需要集成时，会有重复开发、浪费成本的情况，效率低下

3. WebSocket 是有状态协议，集群需要解决共享会话功能，如果单节点部署无法水平扩展支撑更高负载，有单点风险

4. 缺乏监控和报警。虽然可以通过 LinuxSocket 连接数大致估计，但是不准确，且没有业务指标数据，无法与现有微服务框架整合

技术目标和价值

1. 封装 WebSocket 通信细节，与业务系统节藕，双方可以独立迭代，避免重复开发，便于开发和维护

2. 提供了 HTTP 接口，便于各个其他开发语言接入，便于系统集成和使用

3. 采用分布式架构，实现服务水平扩展、负载均衡和高可用

4. 网关集成监控和报警，便于及时排查和解决问题

技术选型

选用：Netty：高性能，易扩展，社区活跃

WebSocket 是有状态的，无法像直接 HTTP 以集群方式实现负载均衡，长连接建立后即与服务端某个节点保持着会话，因此集群下想要得知会话属于哪个节点有点困难。

一般有如下两种解决方案：

• 使用类似微服务的注册中心维护全局的会话映射问题

• 使用事件广播由各节点自行判断是否持有会话

广播实现方案，其实就是选 mq：

在笔者所参与的项目中，由于业务场景中消息无需保证可靠，因此选用：Redis 的 Pub/Sub，少一个依赖的 mq，维护方便，实现简单。如果需要保证消息可靠，还是推荐 RocketMQ 或者 Kafka。

实现思路

架构图：

网关整体流程：

1. 客户端与网关任意一个 node 握手建立长连接，节点将其加入到内存维护的长连接队列（集合）中。客户端定时向服务端发送心跳，如果超过设定时间仍没有收到心跳，则认为客户端与服务端的长连接已断开，服务端回关闭连接，清理内存中会话。详见心跳

2. 当业务系统需要给客户端推送数据时，通过网关提供的 HTTP 接口向网关发送请求

3. 将数据信息写到 mq 里

4. 网关作为消费者，以广播模式消费消息，所有节点都会接收到消息。

5. 节点接收到消息后判断消息目标是否在自己内存中维护的长连接队列里，如果存在则通过长连接推送数据，否则忽略

当面对海量连接时，可以通过网管多节点，增加节点的方式分摊压力，实现水平扩展。如果节点宕机，客户端会尝试和其他节点握手建立长连接，保证服务整体可用。

会话管理：

每个 node 内存中维护一个哈希表，哈希表维护了 UID 和 UserSession 的关系。

UID 即用户 ID，UserSession 表示用户纬度的会话，一个用户困难会同时建立多个长连接，因此 UserSession 内部同样适用了一个哈希表维护一个 Channel 与 ChannelSession 的关系。

为了避免无止尽创建长连接，当内部 ChannelSession 数量超过一定限制后，会将最早建立的 ChannelSession 关闭，减少资源占用。

通过心跳保活与 WebSocket 底层实现库设置 idle_time 来使残余 Session 关闭。详见心跳

监控和报警：

网关接入micrometer，将连接数和用户数作为指标暴露，供prometheus收集，使用Grafana来展示和报警

负载均衡策略

负载均衡策略五花八门，需要选择合适自己的业务场景来设定。简单的做法是直接 ip hash 分到不同 node 上。也可以为 WebSocket node 设一个接口获取负载情况，再做相应的决定。

笔者尝试了一种比较有意思的方案：一文了解一致性哈希，仅供参考。

压测

由于笔者设备能力有限，此处借用原文爱奇艺的测试数据，从下文数据可以看到，该长连接网关的性能非常优秀，足以支撑笔者业务中大部分场景，而且易横向扩展。

压测选择两台配置为 4 核 16G 的虚拟机，分别作为服务器和客户端。压测时选择为网关开放了 20 个端口，同时建立 20 个客户端，每个客户端使用一个服务端端口建立起 5 万连接，可以同时创建百万个连接。连接数与内存使用情况如图 3 所示。

给百万个长连接同时发送一条消息，采用单线程发送，服务器发送完成的平均耗时在 10s 左右。

一般同一用户同时建立的长连接都在个位数。以 10 个长连接为例，在并发数 600、持续时间 120s 条件下压测，推送接口的 TPS 大约在 1600+。

参考与推荐阅读

• https://mp.weixin.qq.com/s/x8tjsZRuLlNYHg04aW7KFw
• http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf
• https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_server
• RFC ft-ietf-hybi-thewebsocketprotocol: The WebSocket Protocol
• https://blog.moontalk.top/post/why-websocket-masked/
• https://datatracker.ietf.org/doc/html/rfc6455#section-10.3
• 构建通用 WebSocket 推送网关的设计与实践
• http://www.52im.net/thread-2697-1-1.html
• https://medium.com/@lancers/websocket-api-sec-websocket-protocol-subprotocol-header-support-277e34164537

链表

相比普遍的链表实现方式，Linux 内核的实现比较独树一帜。普通的实现是数据通过在内部添加一个指向数据的 next 或 prev 节点指针，才能串联在链表中，存储这个结构到链表里的通常方法是在数据结构中嵌入一个链表指针，如 next 或 prev。而 Linux 内核中，是将链表节点塞入数据结构。

1
2
3
4
5
6
7
8
9
10
11

struct list_head{
    struct list_head *next;
    struct list_head *prev;
};

struct fox {
    unsigned long tail_length;
    unsigned long weight;
    bool is_fantastic;
    struct list_head list; // 所有fox结构体形成链表
}

内核还提供了一组链表操作接口，比如 list_add() 加入一个新节点到链表中，他们都有一个统一的特点，就是只接受 list_head 结构作为参数。通过使用宏 container_of()我们可以很方便地从链表指针找到父结构包含的任何变量，因为在 c 语言中，一个给定的结构中的变量偏移在编译时地址就被 ABI 固定下来了。

通过宏 container_of()，定义一个简单的函数就可以返回包含 list_head 的父类型结构体。

1
2

#define list_entry(ptr, type, member) \
    container_of(ptr, type, member)

节约两次纲领（dereference）

如果已经获得了 next 和 prev 指针，就可以直接调用内部链表函数，省下提领指针的时间。前面的所有函数仅仅是找到 next 和 prev 指针，再去调用内部函数而已。内部函数和它们的外部包装函数（上面提到的，比如 list_del(list)）同名，只是前面多加了两条下划线。比如用__list_del(prev, next) 替代 list_del(list)。

队列

Linux 中通用队列实现是 kfifo，和多数的其他队列实现类似，主要提供两个操作：enqueue（入队）和 dequeue（出队）。kfifo 对象维护了两个偏移量：入口偏移和出口偏移。入口偏移是指下一次入队时的位置，出口偏移是指下一次出队列时的位置。出口偏移总是小于入口偏移。

enqueue 操作拷贝数据到队列入口偏移位置，拷贝完后，入口偏移会加上推入的元素数目。dequeue 操作类似。当出口偏移等于入口偏移时，说明队列为空，在新数据被推入前，不可以摘取任何数据了。当入口偏移等于队列长度时，说明在队列重置前，不可再有新数据推入队列。

创建和初始化 kfifo 对象时，它将使用由 buffer 指向的 size 字节大小的内存，size 必须是 2 次幂。

映射

映射是由唯一键组成的集合，每个键必然关联一个特定的值。主要支持三个操作：Add、Remove、Lookup。

映射不仅可以由散列表组成，还可以通过自平衡二叉搜索树来存储数据，散列表可以提供更好的平均的渐进复杂度，但是二叉搜索树在最坏情况能有更好的表现（对数复杂性相比线性复杂性），且二叉搜索树同时满足顺序保证，给用户的按序遍历带来很好的性能，二叉搜索树还不需要散列函数，需要的键类型可以通过定义<=操作算子就能满足条件。

Linux 内核用的不是通用的映射，它的目标是：映射一个唯一的标识数（UID）到一个指针。除了提供三个标准的映射操作外，还在 add 基础上实现了allocate操作，这个操作不但向 map 中加入了键值对，而且还可以产生 UID。

idr 数据结构用于映射用户空间的 UID，如将 inodify watch 的描述符或 POSIX 的定时器 ID 映射到内核中相关联的数据结构上，如 inotify_watch 或 k_itimer 结构体。

二叉树

• 二叉搜索树

• 自平衡二叉搜索树

一个节点的深度是从根节点算起，到达它一共需经过的父节点数目。处于树底层的节点称为叶子结点。一个树的高度是指书中的处于最底层节点的深度。而一个平衡的二叉搜索树是一个所有叶子结点深度差不超过 1的二叉搜索树。一个自平衡二叉搜索树指在操作中都维持半平衡状态的二叉搜索树。

• 红黑树

红黑树是典型的自平衡二叉搜索树，也是 Linux 中主要的平衡二叉树数据结构。红黑树具有特殊的着色属性，遵循着六个特性，维持着半平衡结构。

1. 所有的节点要么着红色，要么着黑色。
2. 叶子节点都是黑色。
3. 叶子节点不包含数据。
4. 所有非叶子节点都有两个子节点。
5. 如果一个节点是红色，则它的子节点都是黑色。
6. 在一个节点到其叶子节点的路径中，如果总是包含同样数目的黑色节点，则该路径相比其他路径是最短的。

这意味着树中最长的路径是红黑交替节点路径，从根节点到叶子节点的最长路径不会超过最短路径的两倍。

Linux 实现的红黑树称为 rbtree，除了一定的优化外，rbtree 类似于前面描述的经典红黑树，即保持了平衡性，所以插入效率和树中节点数目呈对数关系（ O(logN) ）。rbtree 的根节点为 rb_root，其他节点由 rb_node 描述，给定一个 rb_node，可以跟踪同名节点指针来找到它的左右子节点。

数据结构的选择

• 如果对数据集合的主要操作是遍历数据，就用链表。
• 当性能非首要考虑因素，或者只需要存储相对较少的数据项，或者当你要和内核中其他使用链表的代码交互时，优先选择链表。
• 如果需要存储一个大小不明的数据集合，选择链表更合适。
• 如果需要存储大量数据，但没有执行太多次时间紧迫的查询操作，最好使用链表
• 如果代码符合生产者/消费者模式，则使用队列，特别是如果你想要一个定长缓冲。
• 如果需要映射一个UID到一个对象，就使用映射。
• 如果需要存储大量数据，并且检索迅速，最好使用红黑树。

内存管理

页

内核把物理页作为内存管理的基本单位。MMU 通常以页为单位来管理系统中的页表，从虚拟内存角度看，页就是最小单位。大多数 32 位体系结构支持 4KB 的页，64 位体系结构一般支持 8KB 的页。

内核用 struct page 结构表示系统中的每个物理页。

1
2
3
4
5
6
7
8
9
10

struct page {
    unsigned long flags; 
    atomic_t _count;
    atomic_t _mapcount;
    unsigned long private;
    struct address_space *mapping;
    pgoff_t index;
    struct list_head lru;
    void *virtual;
}

flags 用于存放页的状态，比如这个页是不是脏的，是不是被锁定在内存中等，flags 的每一位都单独表示一个状态，至少可以同时表示 32 种不同状态。

_count 存放页的引用计数，为 -1 时标识没有被当前内核引用，那么在新的分配中就可以使用它。一般不会直接访问这个字段，而是调用 page_count() 来检查。对 page_count() 来说，当_count 为负数时，返回 0，表示页空闲，如果返回一个正整数表示页在使用。这个页可以被页缓存使用（mapping 字段指向这个页关联的 address_space 对象），或者作为私有数据（由 private 指向），或者作为进程页表中的映射。

virtual 字段存放了页的虚拟地址。有些内存不永久映射到内核地址空间上，这种情况下这个字段为 NULL，在需要的时候才动态映射这些页。

这个结构只是描述了物理页的信息，而不是描述包含在其中的数据。内核用这个结构来管理系统中的所有页，因为内核需要知道一个页是否空闲，如果页已经被分配，还需要知道谁拥有这个页。拥有者可能是用户空间进程，也可能是动态分配的内核数据，还可能是静态内核代码或页高速缓存等。

区

区的出现是为了处理一些特定的限制：由于硬件限制，内核不能对所有页一视同仁，有些页位于内存中特定物理地址上，所以不能将其用于一些特定任务。此外，Linux 将系统的页划分为区后，形成不同的内存池，就可以根据用途来进行分配了。区的划分并没有任何物理意义，只是内核为了管理页面而采取的一种逻辑上的分组。

• 一些硬件只能用特定内存地址来访问 DMA。
• 一些体系结构的内存的物理寻址范围比虚拟寻址范围大得多，这样就有一些内存不能永久映射到内核空间上。

Linux 主要使用四种区：

• ZONE_DMA 这个区包含的页能用来执行 DMA 操作。在 x86 体系结构上，由于某些 PCI 设备只能在 24 位地址空间内执行 DMA 操作，所以 ISA 设备不能在整个 32 位的地址空间中执行 DMA，因为 ISA 设备只能访问物理内存的前 16MB。因此 ZONE_DMA 在 x86 上包含的所有页都在 0~16MB 的内存访问内。
• ZONE_DMA32 和 ZONE_DMA 类似，但是只能被 32 位设备访问
• ZONE_NORMAL 包含的都是能正常映射的页
• ZONE_HIGHEM 包含高端内存，其中的页并不能永久映射到内核地址空间。能否直接映射取决于体系结构，在 32 位 x86 系统上，ZONE_HIGHMEM 为高于 896M 的所有物理内存，其所在内存也被称为高端内存，而其余内存就是低端内存。在其他体系结构上，由于所有内存都被直接映射，所以 ZONE_HIGHMEM 为空。

当可供分配的资源不够时，内核会去占用其他可用区的内存。在 x86-64 体系结构下，由于它可以寻址和处理的 64 位内存空间较大，所以没有 ZONE_HIGHMEM 区，所有的物理内存都处于 ZONE_DMA 和 ZONE_NORMAL 中。

页的分配和释放接口

底层页分配的核心函数是 alloc_pages，它分配 1<<order 个连续的物理页，并返回指向第一个页的 page 结构体的指针。

1

struct page *alloc_pages(gfp_t gfp_mask, unsigned int order)

可以通过 page_address 获取它的逻辑地址，这个函数返回一个指向给定页当前所在的逻辑地址的指针。

1

void * page_address(struct page *page)

__get_free_pages 的作用类似，但是它是直接返回请求的第一个页的逻辑地址。

1

unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)

获取全是填充零的页，可以调用 get_zeroed_page，它的实现与__get_free_pages 类似，但是在返回前，会将所有数据填充为 0，保障系统安全。

1

unsigned long get_zeroed_page(unsigned int gfp_mask)

释放页可以使用以下函数。如果传递了错误的 struct page 或地址，用了错误的 order 值，这些都可能导致系统崩溃。

1
2
3

void __free_pages(struct page *page, unsigned int order)
void free_pages(unsigned long addr, unsigned int order)
void free_page(unsigned long addr)

kmalloc()

kmalloc() 常用于以字节为单位分配内核内存，它与用户空间的 malloc() 一族函数非常类似，但是多了个 flags 参数。函数返回一个指向内存块的指针，至少有 size 大小，而且所分配的内存在物理上是连续的。

1

void * kmalloc(size_t size, gfp_t flags)

gfp_mask 标志常见于低级页分配函数和 kmalloc() ，可以分为三类：行为修饰符、区修饰符以及类型。

• 行为修饰符表示内核应该如何去分配所需的内存，在某些特定场景下只能使用特定方式分配内存。如中断处理程序要求内核在分配内存的时候不能睡眠。
• 区修饰符表示从哪分配内存。由于内核将物理内存分成了若干个区，每个区用于不同的目的，区修饰符指明了要从哪个区中分配。
• 类型标志组合了行为修饰符和区修饰符，将各种可能用到的组合归纳为不同类型，相当于已经加工好了，简化了修饰符的使用。

因为一般只使用类型修饰符就够了，所以只展示常见的类型标志：

内核中最常见的标志是 GFP_KERNEL，是普通优先级，由于调度可能阻塞，所以只能用在可以重新安全调度的进程上下文中，这个标志没有对请求的内存进行约束，所以内存分配成功的可能性比较高。

另一个极端的标志是 GFP_ATOMIC，表示不能睡眠的内存分配，它的调用需要满足很严格的限制。即使没有足够的内存块可以获取，内核也不能让调用者睡眠，因此它分配成功的机会较小。即使如此，在当前代码不能睡眠时（如中断处理程序，软中断和 tasklet），也只能选择 GFP_ATOMIC。

夹在俩中间的是 GFP_NOIO 和 GFP_NOFS，以这两个标志进行的分配可能会阻塞，但是他们会避免某些其他操作的执行。它们分别用于某些低级块 I/O 或文件系统的代码中，设想，如果文件系统的代码中需要分配内存，没有使用 GFP_NOFS，这种分配可能会引起你更多文件系统的操作，又导致了更多的分配，引发不期望发生的递归，最终导致死锁。总的来说，这两个标志用的还是极少的。

GFP_DMA 标志表示分配器必须满足 ZONE_DMA 进行分配的请求，这个标志用于需要 DMA 的内存的设备驱动中，一般和 GFP_ATOMIC 或 GFP_KERNEL 结合使用。

kfree() 用于释放 kamlloc() 分配的内存块，但是不可用于释放其余分配函数分配的内存，或者已经释放过的内存，否则会造成严重后果。

1

void kfree(const void *ptr)