操统实验日志 第一章 序章
简述
+操统实验日志 第一章 序章
简述
在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
它是关于什么的
@@ -506,7 +506,7 @@ btf.addGlobalFn('pjaxSend', () => {目前为止，环境已经基本配置完成了
接下来就让我们开始愉快的操作系统实验之旅吧！
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 時痕！
在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
目前为止，环境已经基本配置完成了
接下来就让我们开始愉快的操作系统实验之旅吧！
本章的序将会首先介绍操作系统是如何运行起来的，并在此基础上介绍实现一个完备的操作系统实验需要实现哪些方面，以及这些部分的先后顺序和依赖关系
由于这份文档我并不打算作为一份完备的教程文档来编写，因此语言方面的介绍会相对简略或是跳过，对应的详细介绍可以参考学校的同步教程
在本章的后半部分，将会介绍MBR和中断的相关知识，记录如何编写MBR、测试使用BIOS启动MBR引导程序并通过中断输出字符串进行测试
@@ -953,7 +953,7 @@ BIOS从
0x7C00处开始执行代码，其并不区分内存中存储
下一章中，将会编写bootloader，从mbr中加载bootloader并且启动，最后在bootloader中让CPU进入保护模式在本章的第一部分中，将会介绍读取硬盘的CHS方式、LBA方式以及如何通过in、out指令读写硬盘，之后会将上一章输出Hello World!的代码移植到BootLoader中，并且从MBR中加载并跳转到编写的BootLoader执行
在第二部分中，会回顾保护模式的概念并介绍进入保护模式的四个步骤，并在开启保护模式之后输出第二个Hello World
完成
至此，就完成了本章的全部任务，赶紧使用make clean build run来测试代码的运行情况吧！
在本章节的第一部分中，将会简要介绍在下一章中将要编写的KernelLoader，以及在开始着手进行它的编写之前所需要完成的，包括各种驱动、文件系统接口等在内的诸多准备工作。
在第一部分之后，我决定按照KernelLoader中的函数调用顺序，逐节完成KernelLoader中所需要的所有准备工作，因此在第二部分中，将会首先记录如何在项目中使用C语言和汇编混合编程，包括C语言是如何进行函数调用的，以及内联汇编中NASM向AT&T迁移语法所需要注意的问题。有了这部分基础知识，就可以进行第三部分编写一些常用的驱动，并从我个人的角度讲讲为什么要这么做，它对后续的代码编写能够起到哪些帮助。
在之后的第四部分中，会进行有关文件系统的知识的详述，并且带领大家阅读微软关于FAT文件系统的文档，根据文档完成FAT文件系统接口的设计和实现。
@@ -1845,7 +1845,7 @@ VirtualPageIndex &= VirtualPageAddress >> n \nonumber \\勇者奖章
恭喜你，读完了所有日志中最长最复杂的一篇，后面的实验之路将会因这一章的努力而愈发平坦。
时隔两年，终于借着重新配置家里网络环境的契机，重新搭建了这个博客。
+时隔两年，终于借着重新配置家里网络环境的契机，重新搭建了这个博客。
原先关于操作系统的文章正在慢慢搬迁，应该很快就能恢复了~
再一次启用关于自己的博客，感觉心里良多感慨。还记得上一次搭博客时的自己，刚来到计算机学院，对着网上的保姆教程在腾讯云的小机器上搭了 git 仓库、配置了宝塔面板、DNS 解析。
那时的自己对 TLS、证书、Git、反代、CDN、Docker 这些东西都还是那么陌生，以至于教程之外的东西完全不敢去碰，哪怕是在宝塔面板上配一个 Let’s Encrypt 的证书都要折腾好久，也没有去研究 hexo deploy 到底 deploy 了什么到服务端，只觉得能跑便是好事，这也就导致了后来的删库跑路事件——本地的博客仓库被主动删除，等到发现服务器上是没有 Markdown 源文件的时候已经太迟，由于没有了源文件，写新的博客势必会导致旧的 html 被覆盖，又因为文章实在太长迟迟没有动手迁移，原先的数万字长文就这样被冻在了旧的博客里长达两年。
不夸张地说，看到熟悉的页面再一次出现在浏览器中的时候，内心有许多感慨，大概就像离家的游子多年后重新推开家门时那样吧。拂去把手上的灰尘，推开门回到曾经熟悉的地方，所有的东西都还在原本的地方等着自己，仿佛从来没有离开过那样。博客大概就是我内心无处安放的杂思的归宿吧，我想，如今它们终于又能安家了。
这一次回来，不知道能够持续多久，但我希望，能够长一些、再长一些。至于内容，我也不打算维持早年纯技术的导向了，我更多地想让这个博客成为我存在的痕迹，让多年后的自己看到曾今的文章能够会想起当年的纠结、焦虑、喜悦或是激动，能够从这里，看到我。
总之，欢迎回家。
-简单来说，方案分为了几个主要的部分：
+简单来说，方案分为了几个主要的部分：
在配博客之前，我是先配好了 Nas 上的 Gitea 服务，可以参考 在 NAS 上部署自己的 Gitea 服务，无需公网服务器 这一篇博客来准备基本的网络环境和 Gitea 服务。
(也就是说，我是先搭好了 Gitea，然后实在不知道能拿干点什么，才决定把博客迁移回来的。有点为了醋包饺子的感觉哈哈，不过现在博客全部内容都运行在自己本地感觉还是颇有成就感的)
待后面补充~
-最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
直到今天突然意识到，hexo 渲染 markdown 为 html 文本肯定会分为三个大部分：
然后再把原先的图片复制到现在的 img 目录下，批量改一手路径，Done！
谁能想到这个卡了我两年的问题，竟然能 15 分钟就搞定了！！！
过于激动，遂特写此文记录一下，真是拍大腿啊！！！
-简单来说，方案包含了以下几个主要部分：
+简单来说，方案包含了以下几个主要部分：
不过，由于 Cloudflare 只支持有限的端口转发，并且只支持基于 http/https 协议的流量转发，因此适用面相对不那么广，但是家用部署网站服务还是绰绰有余了。具体允许的端口号见 Cloudflare 文档。
经过测试，中国联通封了 80，443，2096 端口，回源我采用的 2095 端口，这个在 Cloudflare 控制台 - 规则 - Origin Rules 可以创建回源规则针对特定域名指定。
待后续翔实~
-感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
+感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
看到 Hexo - Butterfly 有提供一个 “说说” 的页面可以用 .yml 格式来存一些说说文档，但是仔细一看发现好像不会自动分页，这样一来图片一多感觉加载就会变成彻底的灾难…
不知道为什么在静态编译的时候没有做成本地分页的格式呢… 就像文章那样，其实在编译阶段就可以分散到不同的 index.html 去了，好可惜，也许以后有空会想办法看看能不能改吧…
还有很多云存储的方案，但感觉把自己的内容放在云上，总感觉会比较担心数据安全和以后的迁移成本，纯本地的话哪怕一天发两条十年也不过才不到上万条数据，一个 .yml 就带走了，哎可惜没分页终究还是不打算去用。
想来想去，就把短博客也当作正常的文章一样的显示在主页吧，不过会在标题前面加上 “短文” 的标记和对应的 tag，也方便浏览的时候来做区分好了
今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
+今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
对自己的期望就是，不要忘记做技术的初心，在新的阶段能有所成长，有所收获。
Po 一张在鹅厂的第一个关爱里程碑~
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
对于目标 .jar 或是 .dex 文件，有两种不同的编译方案：
.dex 文件方式：atx/uiautomator2 的实现的时候，先入为主地就认为作者使用了 uiautomator <jar> 这种方式调用，后面注意力都放在了查找作者针对 u2.jar 的打包方式和相关代码上了，以至于在仓库里搜索 u2.jar 的时候竟然没有注意到在搜索结果中 core.py 赫然有着 command = "CLASSPATH=/data/local/tmp/u2.jar app_process / com.wetest.uia2.Main" 这一启动方式，与答案擦肩而过并且进一步在寻找 uiautomator 1.0 的打包方式上浪费了大半天的时间快要到年底绩效考核的时间了，回想过去半年好像一直忙忙碌碌但好像又没有什么很亮眼的成果。期间还有一大部分精力都投在了一个设计难度远大于实现难度的需求。
+快要到年底绩效考核的时间了，回想过去半年好像一直忙忙碌碌但好像又没有什么很亮眼的成果。期间还有一大部分精力都投在了一个设计难度远大于实现难度的需求。
回过头想想，其实在工作上开始做一件长期的事情之前，还是要去评估可行性、投入以及收效，到底这件事情有多大的优先级，是不是就值得现在立马开始投入人力去做这个。到底做些什么可以被业务感知到，从而去判断，到底哪些需求才是重要的，而不是一味的承接需求，最后反倒抓不到重点了。
当然，除此之外，更重要的一点是，在知道了公司存在强制的 Underperform 比例时，不免会想，也许有一天我也要成为背这个绩效的人？在这种场景下，是否不要把鸡蛋放在一个篮子里更为安全？诚然，上班本质还是一种利益交换，我给公司提供我能够产出的内容，帮助公司节省人力开支或是做原本人力做不了的事情，公司给我反馈大厂背景、经验、人脉和钱，当然，这里面必然伴随着剩余价值的剥削云云，但总的来看，也算是目前相对公平且不错的买卖，在这样的背景下，我还是会在工作的时候专注于需求本身，坚守住技术人应有的底线，但在工作时间之外，确实应该更加关注自身的投资，也许是身体的健康，也许是产品思维，也许真的去做一些能代表自己实力的东西吧。
前几天有看到一个帖子，个人认为说的其实很有道理，大致意思就是，人总要有一些能证明自己能力的东西，在校招的时候，学历就是最大的背书；在工作的时候，便是绩效和公司、项目经历。但是，如果能有足够的其他履历，比如大的开源项目、成功的产品，这些就会替代前者变成能力的证明，毕竟，选择前者只是没有后者的无奈之举。所以，我想，做自己感兴趣的事，并且在这方面出彩，大概才是最有价值的投资吧。
-日常工作中，经常会需要临时 Clone 某个仓库并且用 VSCode 打开，在 Windows 上我一般都是：
+日常工作中，经常会需要临时 Clone 某个仓库并且用 VSCode 打开，在 Windows 上我一般都是：
git clone之后，在文件夹中直接输入 clode <repo url> [dest folder] 即可一键 clone
[dest folder] 为选填，不填则是默认取 <repo url> 末尾仓库名称作为目标文件夹，同直接执行 git clone <repo url> 行为保持一致
某天在 Windows 宿主机上执行任务时，发现 wda 指令请求一直失败，查看日志发现唯一有效的错误日志是 Only one usage of each socket address (protocol/network address/port) is normally permitted，回顾宿主机环境在过去一段时间没有进行过变更，并且该问题是第一次出现，此前相同环境并没有出现过这个问题
尝试在其他宿主机以及本地开发机上执行相同命令均不能稳定复现该问题，其中 Linux 开发机无法复现该问题
+
由于报错信息只有一行，也只能从这个信息来入手。搜索引擎检索得到如下内容：
+listen 同一端口引起，阅读提问者提供的代码确实有此问题由于此前宿主机并没有暴露出该问题，优先考虑并不是发起请求及接收请求的 client 及 wda 侧的问题，即第一篇文章中提到的可能，而是从宿主机上的 tcp 连接状况入手来进一步分析这个问题，于是主要的关注点转向如下方面：
+在开始检查 tcp 连接情况前，首先需要确认大致的请求链路，从而确定需要关注的 tcp 连接范围。问题发生在 Windows 上 docker 容器内服务向宿主机发送 wda 请求时，因此从这一条请求链路入手：
+请求的末端是 usbmuxd 服务，该服务负责和连接的 iPhone 进行通信，所有请求最后都会发送到 usbmuxd 来进行多路复用 (multiplexing)，从而达到在一个 usb 链路上同时执行多个请求。
+usbmuxd 服务在 Linux 和 Windows 上的表现并不相同，在 Linux 上，其监听一个 UNIX socket 套接字来提供服务，而在 Windows 上，其监听 127.0.0.1:27015 端口提供服务，这里应该是处于安全考虑，其只监听了 127.0.0.1:27015 而不是 0.0.0.0:27015。
由于 Windows 上的 usbmuxd 服务仅监听 127.0.0.1:27015 端口，对于容器内打出来的请求，考虑到其 ip 可能不是 127.0.0.1，遂在宿主机有起一个反代服务，从 0.0.0.0:23333 端口反向代理到 127.0.0.1:27015，这样不是以 127.0.0.1 发起请求的服务可以通过连接到宿主机的 23333 端口来和 usbmuxd 通信。在 Linux 上，同样有这个反代服务，不过它的作用是将请求代理到对应的 UNIX socket 上。
之后就是 docker 内的服务了，其通过 host.docker.internal 域名向宿主机的 23333 端口建立连接，并和 usbmuxd 通信来发送 wda 的请求。
这样，在宿主机上需要关注的连接就很明了了：
+127.0.0.1:27015 服务发起的通信，包括宿主机对 usbmuxd 服务的请求以及反代服务发起的请求23333 端口发起的通信在 Windows 再次复现问题时，使用 netstat -ano | findstr 27015 以及 netstat -ano | findstr 23333，并辅助 | Mesaure-Object 方法来查看连接情况发现：
上述现象佐证：
+联系 报错分析 中的第二篇参考文章，初步猜测可能由于存在进程大量发起请求，请求结束后 tcp 连接进入 TIME_WAIT 状态，由于没有设置 SO_REUSEADDR 此时端口号仍然处于被占用的状态，如果继续建立连接确实可能会出现端口号用尽导致报错。
+这也就引导关注点到如下问题：
+netstat -ano | findstr 27015 | findstr | findstr TIME_WAIT | Measure-Object 或是 netstat -ano | findstr 23333 | findstr TIME_WAIT | Measure-Object 反映出来的 TIME_WAIT 连接也不到一万，问题是如何触发的？先关注第一个问题，通过检索搜索引擎 windows dynamic port range 可以检索到如下文档：
+The default dynamic port range for TCP/IP has changed since Windows Vista and in Windows Server 2008：*To comply with Internet Assigned Numbers Authority (IANA) recommendations, Microsoft has increased the dynamic client port range for outgoing connections in Windows Vista and Windows Server 2008. The new default start port is 49152, and the new default end port is 65535.*，也即 Windows 上的默认动态端口范围自 Windows Server 2008 开始，默认从 49152 开始到 65535，一共 16384 个，同时使用 netsh int ipv4 show dynamicport tcp 可以查看实际配置的值
Powershell 执行 netsh int ipv4 show dynamicport tcp，确实得到 16384 这个结果：
1 | 协议 tcp 动态端口范围 |
联系 tcp 链接分析 中的数量，如果与 27015 和 23333 端口建立的连接数量均达到 8000，确实会有端口耗尽的可能。所以下一步的关键就是：究竟是哪个进程在建立这些连接？是否是自己工程逻辑有问题？
由于 netstat -ano | findstr 27015 | findstr TIME_WAIT 无法展示实际创建连接的 PID，为此我专门写了一个 python 小脚本，这个脚本不断获取非 TIME_WAIT 状态的连接列表来获取连接的 PID，再获取 TIME_WAIT 连接并找到它们原先对应的 PID 输出：
1 | import subprocess |
脚本写的比较简单，考虑到没有太多干扰连接，直接抓取的所有的 TIME_WAIT 连接的原始 PID，同时过滤了下 443 和 80 这种明显干扰的结果。
同时为了分析 报错分析 中的第二个问题，同样也写了一份针对 Linux 机器的分析脚本：
+1 | import subprocess |
分析脚本的输出，发现：
+127.0.0.1 发起的，与反代监听端口建立的连接，PID 查看发起进程为 com.docker.backend.exe其中第一点符合预期，因为在 Linux 上反代通过 UNIX socket 与 usbmuxd 通信，并不经过 tcp 连接。
+第二点则提示工程确实存在冗余逻辑，1000 请求量在 120s TIMEWAIT 窗口下代表约 8qps 请求负载，这明显存在逻辑错误，自动化再怎么跑也不应该出现如此高的请求负载。
+第三点令人感到疑惑：为什么从 docker 容器内发出的请求实际发起 ip 为 127.0.0.1，并且是由 docker 进程发起的？
由于 Linux 下，请求的发起 ip 均为 docker bridge 网卡下容器的 ip，可以推断 Linux 下容器内发起的请求不会占用宿主机的动态端口。而如果 Windows 会由 docker 代为发起请求，从现象上看起来确实是会占用宿主机的端口范围，这很有可能是 Linux 上无法复现这个问题的，除了 Linux 上与 usbmuxd 通信不使用 tcp 连接之外的另一个关键原因。
+至此，可以产生一些阶段性的结论：
+接下来，更多的是验证上述结论的正确性，目光转向下列方向：
+有了猜想，想要复现问题其实比较容易，Windows 侧动态端口范围分析 中提到，Windows 默认动态端口范围就是 16384 个，为了减少额外操作干扰，就不改动这个范围，直接手动打 16000 个连接看看问题能不能复现即可。
+遂随便手搓了一对 server-client 脚本，server 甚至还有没办法退出的 bug（不过管他呢，反正也是复现问题用的，能跑就行）
+client 可以手动通过 open <number> 或 close <number> 指定打开或关闭多少个连接，从而达到精确控制，免得开得不够多或者开得太多，主打一个灵活。
1 | """server""" |
1 | """client""" |
测试发现，当打开了 16000 个端口左右再全部 close 后，问题确实可以复现。
+为了交叉验证，在等待一段时间 （大概相当于第一个 open 的端口关闭 2 分钟后）问题自行消失并且在不另开新连接时不再复现。
+同时，还通过设置 SO_REUSEADDR 标记进一步验证是因为 TIME_WAIT 端口无法被复用导致的问题，在设置该标记后，TIME_WAIT 阶段的端口可以被新的连接复用，实际测试反复开关连接超过 16000 次仍让不会导致问题复现。
至此，基本可以肯定问题出现的原因就是短连接过多导致 TIME_WAIT 堆积，最后动态端口耗尽无法创建新的连接使得 wda 请求失败。
+由于此处与工程相关逻辑强相关，不详细展开。经过代码 review，发现部分环节存在多次反复获取同一信息的问题，即有一些连续执行的逻辑链路 A-B-C-D-E，其中每一步都会请求 get_necessary_data 方法，由于五个方法分开实现，串联五个方法的代码作者与方法编写人又各不相同，没有注意到这里方法的反复多次冗余调用，最终导致了短时间高频调用的逻辑。暂时通过请求缓存优化后得以解除。
此处也佐证了高频的 wda 请求确实与工程的逻辑相关，进一步排除了底层工具链存在问题的可能性。
+在搜索引擎检索相关内容，发现并没有太多相关的内容，个人也没有找到官方有关上述发现的行为相关的文档。通过将 问题复现 中的 client 代码搬到 docker 容器内执行并请求 host.docker.internal 地址，可以复现这种行为，也即容器内与 docker 网卡网关地址建立连接，宿主机上由 docker 发起另一段连接，并不直通，而在 Linux 上执行则可以看到不会有这样的行为。
在 Windows 上执行 ipconfig 同样也可以看到不会有 Linux 下执行 ip a 所看到的 docker0 或是 vethX 网卡，进一步推测两个平台上 docker 对于 bridge 网络驱动的实现方案不相同。
同时，我也对 gpt 进行了相关问题的询问，下面是 gpt 给出的解答，大家参考着看，不具有权威性：
+1 | [Prompt] |
问题的根因是工程逻辑变更后请求次数异常增加导致，直接原因是由于请求次数大量增加后，Windows 上动态端口耗尽触发了该报错，同时，docker 在 Windows 上的网络行为也进一步加剧了请求数量增长的影响（导致请求数量翻倍）。
+由于 usbmuxd 和 docker 在 Windows 和 Linux 上行为的差异性导致了这个问题在 Linux 机器上无法复现，同时由于同一时间宿主机上任务负载量不同，导致了在同一个宿主机上也不能够稳定复现。通过手动构造极端场景可以做到稳定复现。
+找到了问题的原因，解决方案也就很明了了：
+此处额外解释一下第二点中为什么又可以直接从容器内访问 usbmuxd 了：前面发现容器内请求 host.docker.internal 会让 docker 以 com.docker.backend.exe 的身份使用 127.0.0.1 发起一个代理的请求，这还正好满足了 usbmuxd 只监听 127.0.0.1:27015 的行为了，这样宿主机的反代服务也就不需要了。
对于 Linux 服务，如果需要保持架构上的统一，一个可能的优化方向是将 usbmuxd 监听的 socket 映射到容器内？考虑到 docker daemon 的 socket 可以做到，大概这个方向也可行，但目前还没有做尝试，就留作一些可行的方案放在此处吧~
+