fix typo

application-centric/application-centric.md

@@ -1,15 +1,13 @@
 # 10.1 “以应用为中心”的设计思想
 
-回顾过去十几年的技术架构演进，精彩纷呈！
+回顾过去十几年间的技术演进历程，精彩纷呈！
 
-从单体应用到分布式架构，能力大幅提升，但也引入了更多的不确定性，比如节点可能随时宕机、网络有不等的延迟、消息可能丢失。为了解决这些不确定性，业界提出了诸多的分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统稳定运行。
+从单体应用到分布式架构，系统能力大幅提升，但也引入了更多的不确定性，比如节点可能随时宕机、网络有不等的延迟、消息可能丢失。为了解决这些不确定性，业界提出了诸多的分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统稳定运行。
 
-进入微服务时代，这些理论推动基础设施能力开始演进，这些能力（服务发现、负载均衡、故障转移、动态扩容）从业务逻辑中抽象出来，以 SDK（中间件）方式提供给应用开发者。中间件的出现其实体现了一种朴素的“关注点分离”的思想，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力！
+进入微服务时代，这些理论推动基础设施能力演进，这些能力（服务发现、负载均衡、故障转移、动态扩容）从业务逻辑中抽象出来，以 SDK（中间件）形式提供给应用开发者。中间件的出现其实体现了一种朴素的“关注点分离”的思想，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力！
 
-不过，基础设施能力的演进，也伴随着云计算和开源社区的发展，带来了全新的升级。这个变化，正是从云原生技术改变中间件格局开始。更确切地说，原先通过中间件提供和封装的各种基础设施能力，现在全部被 kubernetes 从应用层拽到基础设施层。比如，Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实把构建分布式应用最迫切的需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中，也就是 kubernetes 中。
+不过，基础设施能力的演进，也伴随着云计算和开源社区的发展，带来了全新的升级。这个变化，正是从云原生技术改变中间件格局开始。更确切地说，原先通过中间件提供和封装的能力，现在全部被 kubernetes 从应用层拽到基础设施层。比如，Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实把构建分布式应用最迫切的需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中，也就是 kubernetes 中。
 
-值得注意的是，kubernetes 不直接提供这些能力，它的角色定位是通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。从这一点讲，Kubernetes 从来就不是一个简单的容器平台或者资源管理项目，它是一个分量十足的“接入层”，是云原生时代真正意义上的“操作系统”！
-
-所以说，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，而无需关注底层基础设施的配置和实现细节。
+值得注意的是，kubernetes 不直接提供这些能力，它的角色定位是通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。所以说，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，而无需关注底层基础设施的配置和实现细节。
 
 这种设计理念，以一言蔽之，就是以应用中心。正是因为以应用为中心，整个云原生技术体系无限强调基础设施更好地服务于应用，以更高效的方式为应用提供基础设施能力，而不是反其道行之。而相应的，Kubernetes 也好、Docker 也好、Istio 也好，这些在云原生生态中起到了关键作用的开源项目，就是让这种思想落地的技术手段。

http/conclusion.md

@@ -2,4 +2,4 @@
 
 本章，我们详细分析了 HTTPS 的请求过程，讲解了其中域名解析、内容压缩、SSL 层加密、网络拥塞控制等主要的环节的原理和优化操作。相信你对于构建足够快的网络服务，有了足够的认识。
 
-总体而言，要构建“足够快”的网络服务，首先是保证域名解析不能失败，然后请求要足够快（使用 QUIC、Brotli 压缩）、足够安全（使用 TLS1.3 协议 + ECC 证书，即快又安全）、还要充分利用带宽（使用 BBR 提高网络吞吐率）。最后，技术无法解决的（长链路、弱网、海外网络），那就得花钱（CDN、边缘节点加速、建当地数据中心）。
+总体而言，要构建“足够快”的网络服务，首先是保证域名解析不能失败，然后请求要足够快（使用 QUIC、Brotli 压缩）、足够安全（使用 TLS1.3 协议 + ECC 证书，即快又安全）、还要充分利用带宽（使用 BBR 提高网络吞吐率）。最后，技术无法解决的（长链路、弱网、海外网络），那就得花钱（CDN、边缘节点加速、建立当地数据中心）。