Update ch08.md

ch08.md

@@ -141,11 +141,11 @@
 
 > 一些对延迟敏感的场景，如视频会议和 IP 语音，常使用 UDP。由于 UDP 不需要提供额外保证，因此不需要做超时重传和流量控制，因此可以避免 TCP 很多排队造成的延迟。
 
-> 当然，如果用户仍然需要某种程度的可靠性，可以基于 UDP 在应用层有针对性的做一些优化，比如在视频会议中，如果网络不好，可以主动问下：能再说一遍嘛？这是一种常用的思想，通用场景，可以使用屏蔽底层复杂度的协议；特化场景，可以使用相对底层、粗糙的协议，自己在应用层做有针对性的封装。是一个实现复杂度和效率的 tradeoff。
+> 当然，如果用户仍然需要某种程度的可靠性，可以基于 UDP 在应用层有针对性地做一些优化，比如在视频会议中，如果网络不好，可以主动问下：能再说一遍嘛？这是一种常用的思想，通用场景，可以使用屏蔽底层复杂度的协议；特化场景，可以使用相对底层、粗糙的协议，自己在应用层做有针对性地封装。是一个实现复杂度和效率的 tradeoff。
 
 所有上述因素，都能造成网络延迟变化，且一个基本现象是：**网络流量越满，单个请求延迟抖动越大**。
 
-在公有云或者多租户系统中（比如几个人公用一个物理开发机），由于通信链路上的很多物理资源（交换机、网卡、CPU）都是共享的（虽然会做一定的**资源隔离**），如果其他用户突然运行某种巨占资源的任务（比如跑 MapReduce），则你的网络请求延迟就会变的非常不稳定。
+在公有云或者多租户系统中（比如几个人共用一个物理开发机），由于通信链路上的很多物理资源（交换机、网卡、CPU）都是共享的（虽然会做一定的**资源隔离**），如果其他用户突然运行某种巨占资源的任务（比如跑 MapReduce），则你的网络请求延迟就会变的非常不稳定。
 
 **静态设置**。在这种环境中，如果你要为远端故障检测设置超时时间，就只能使用做实验的方式，经过足够长的时间，统计请求延迟分布。进而结合应用需求，在**检测过久**（设置长超时间隔）和**故障误报**（设置过短超时间隔）做一个权衡。
 
@@ -188,7 +188,7 @@
 >
 > 与之对应，互联网中的通信会**动态的**（dynamically）共享网络资源。每个发送者都会将数据包尽可能快的推送到数据线路上，但在任意时刻，哪个数据包被真正发送（即资源分配给谁），则由交换机来动态决定。这种做法的劣势在于排队，但优势在于能够最大化线路资源利用。一条线路的造价是固定的，如果对其利用率越高，则单位数据发送成本越低。
 >
-> 类似的情形还发生在 CPU 的分时复用里。如果再多个线程间动态的共享每个 CPU，则一个线程使用 CPU 时，其他线程必须排队等待，且排队时间不确定。这种使用 CPU 的方式，比分配给每个线程固定的时间片要高效。类似的，使用虚拟化的方式共享同一台物理机，也会有更好的硬件利用率。
+> 类似的情形还发生在 CPU 的分时复用里。如果在多个线程间动态的共享每个 CPU，则一个线程使用 CPU 时，其他线程必须排队等待，且排队时间不确定。这种使用 CPU 的方式，比分配给每个线程固定的时间片要高效。类似的，使用虚拟化的方式共享同一台物理机，也会有更好的硬件利用率。
 >
 > 在资源静态分配的环境中，如专用的硬件、互斥的带宽分配，有界延迟能够被保证。但是，这种方式是以降低资源利用率为代价的，换句话说，更贵。反之，通过多租户方式动态的共享资源，更便宜，但代价是**不稳定的延迟**（_variable delays_）。**不稳定的延迟并非什么不可变的自然法则，而仅是一种代价和收益权衡的结果罢了**。