https://www.thebyte.com.cn/kubernetes/CNI.html

下文中，如图2-2 应为2-3

2.3.1 域名解析的工作原理
域名解析靠的是 DNS，我们在浏览器输入一个域名时，DNS 负责将该域名解析为相应的 IP 地址，以便后续与目标服务器建立 TCP/IP 连接。探寻 DNS 工作原理之前，我们先了解域名的结构。如图2-2所示，域名是一种树状结构，最顶层的域名是根域名（注意是一个点“.”，它是 .root的含义），然后是顶级域名（top-level domain，简写 TLD），再是一级域名、二级域名、三级域名。

如同瀑布流水一般，因为被称为瀑布模型->如同瀑布流水一般，因而被称为瀑布模型

具体位置链接

但其新产品推出收到芯片开发周期的限制

“收到” -> “受到”

如题

安全性 Safety：
一个变量只会被确定一个值（只能一个人当村长），一个变量只有在值被确定之后，才能被学习。
活性 Liveness：
提案最终会被接受（一定能选出个村长）；一个提案被接受之后，最终会被学习到。

学习是什么意思。。。

com后为啥有个.
原文：获取 com.域的 TLD 域名服务器后， 向该地址请求 example.com. 的 权威解析服务器（Authoritative nameserver）。

https://github.com/isno/theByteBook/blob/main/architecture/arc-guide.md#141-%E8%87%AA%E5%AE%9A%E5%90%91%E4%B8%8B%E7%9A%84%E6%8E%A8%E8%BF%9B

【自顶向下】或【自上向下】

https://www.thebyte.com.cn/distributed-system/raft.html#leader-%E9%80%89%E4%B8%BE

在2.7节开头

这个是想描述什么方面的内容？

这个TIME_WAIT吧

为 Network namespace 配置 IP 信息，位于同一个子网 172.16.1.0/24 中。

根据实际执行命令及效果，子网应为172.16.0.0/24

有的只有缩写没有全称
有的有全称没有中文释义
有的二者都有
有的是缩写（全称）
有的是全称（缩写）
有的用的是中文扩号，有的是英文括号。。
有的缩写用的大写，全称首字母用小写
有的全小写

希望能全局统一一下（作者别打我）

https-summary.md 中 SSL 和 TLS 的 full name 及其中文释义有误

• 原文

SSL（Transport Layer Security，传输层安全性协议）
TLS（Transport Layer Security，安全套接字层协议）

• 修改为

SSL（Secure Sockets Layer 安全套接字层协议）
TLS（Transport Layer Security，传输层安全性协议）

既然提到了quic，建议同步增加HTTP 1.1 / HTTP 2.0的章节。

目前在各类企业实际生产环境中，1.1/2.0都有在使用，2.0相比于1.1也有比较好的性能提升，对于1.1升级到quic或许是比较激进的，但是1.1到2.0基本可以无感过渡。建议增加这部份的小章节。

整体写的很棒
有一处手误

在 分布式理论及实践/幂等性设计 这一章节中，此处标红的“实践”是否为“时间”？

标题3出现了两次。

好像和实际左侧导航栏不符

云原生架构的定义

另一方面，云原生架构可以用过与基础设施的深度整合和优化，将存储、计算、网络等资源管理以及相应的自动化能力交由基础设置执行，应用自身变的更为灵活，从而大幅降低管理成本。

这里的 云原生架构可以用过与基础设施的深度整合和优化 是不是少了个词呢？

#3

应该是 ip link set veth2-peer up?

感谢作者的原创开源书籍，阅读到容器编排系统 Kubernetes章节的时候发现弹性伸缩和Kubernetes进阶的内容一直，两者使用的同一个链接。

可以将参考文献或者引用放上吗

这一段话中：
其次，企业逐渐重视上云，云计算服务商也把建设关注点从基础设施的建设向应用的云架构转变。这个阶段，我们谈充分利用云的特性，解放生产力，助力企业商业价值增长，对于技术人员而言，就是理解云技术、拥抱云原生的最强的驱动力。

最后一句话中存在语病，根据我的理解，作者想表达的意思应该是 “企业的重视”是“技术人员的驱动力”，或者”这个转变过程“是”驱动力“。

而最后一句话中的主语是”这个阶段“。

用户态返回TCP Option 中的cip。

文章标题：网络虚拟化的基础：network namespace
章节：配置 network namespace
下面的命令创建一对虚拟以太网卡，然后把 veth pair的一端放入 netns1 中, 另外一端放入 netns1中。
我理解第二个 netns1 应该改为 netns2。

-->
| CE | Chaos Engineering | 混沌工程： 用于故障演练及解决。研究大规模分布式系统瓶颈、缺陷，提升整体服务稳定的方法学|

原文:
在这期间，出现了云计算领域多个重要里程碑：

IaaS的出现：通过按时计费的方式租借服务器，将资本支出（Capex）转变为运营支出（Opex），这使得云计算得以大规模兴起和普及。
PaaS的出现。
开源IaaS的出现：云计算开始进入开源时代。
开源PaaS的出现。
FaaS的出现。

PaaS和FaaS这里是不是可以简单介绍下？像IaaS的出现一样？

如题

如题

Linux Kernel在5.6版本加入time namespace.
https://www.thebyte.com.cn/content/chapter1/SDN.html

https://isno.github.io/chapter1/latency.html
从 SSD 顺序读取 1 MB 49,000 ns ≈ 4.9 μs 换算错误，应该是49μs

另外 https://isno.github.io/chapter1/bgp.html 最后一段 在使用多线机房重复了两次 ，
另外同篇文中首次出现VIP时，建议加注释(Virtual IP ?)，毕竟VIP的常见释义是高级会员

老哥写的很棒，很涨姿势！

2006年，Google 推出 Process Container（进程容器） 用来对一组进程进行限制、记账、隔离资源
这里的 “记账” 应该是 审计 吧

这块之前我也比较感兴趣。在前期搜集信息的时候已经看到国内杭州(也许是宁波?)已经有创业公司在做相关的事情，也有中大厂在做这些事(https://www.bilibili.com/read/cv22150189/)，但主要有两个疑惑：

1. 由于某些"安全"上的要求，已经有很多企业在执行"服务下云"了，对于FinOps在国内的应用及前景是不是不太明朗？
2. FinOps比较依赖云厂商给提供的能力，如果某天云厂商觉得被薅疼了，会不会直接关闭或者修改账单功能，这对于FinOps而言是不是也是一种致命威胁？

在这个commit里的路径是对的：6a59cbf#diff-d922ba5eb323770279ac8c0f81af0d64178cee0268702f003879abc3e5260ffdR91
这个commit误删了：049ed6c#diff-d922ba5eb323770279ac8c0f81af0d64178cee0268702f003879abc3e5260ffdR108

1. dperf https://github.com/baidu/dperf 测试 4 层网络性能，性能最高，dpvs项目在用此工具，国内大厂都在用
2. t-rex https://github.com/cisco-system-traffic-generator/trex-core 测试 3 层、4 层、7 层
3. pktgen https://github.com/pktgen/Pktgen-DPDK 测试 3 层

位置：
如图 2-2 所示，一个 HTTPS 请求共需要 5 个 RTT = 1 RTT（域名解析） + 1 RTT（TCP 握手）+ 2 RTT（SSL 握手）+ 1 RTT（HTTP 内容请求传输）

https://isno.github.io/ 404

在2.2章中网络请求耗时计算中，有一些的参数解释似乎有点问题呢，像time_connect 就是指的tcp握手时间，而不是time_connect - tcp_namelookup；类似time_appconnect就是SSL握手耗时，而不是time_appconnect - time_connect。我也是参考着https://curl.se/docs/manpage.html 和 https://speedtestdemon.com/a-guide-to-curls-performance-metrics-how-to-analyze-a-speed-test-result/ 这两篇文章看的哈

| NIC | Network interface card | 网卡 | -->

| NIC | Network Interface Card | 网卡 |