删除不精确的表达

ch5-web/ch5-06-ratelimit.md

@@ -4,11 +4,9 @@
 
 web 系统打交道最多的是网络，无论是接受，解析用户请求，访问存储，还是把响应数据返回给用户，都是要走网络的。在没有 epoll/kqueue 之类的系统提供的 IO 多路复用接口之前，多个核心的现代计算机最头痛的是 C10k 问题，C10k 问题会导致计算机没有办法充分利用 CPU 来处理更多的用户连接，进而没有办法通过优化程序提升 CPU 利用率来处理更多的请求。
 
-从 linux 引入了 epoll 的 API 之后，这个问题基本解决了，我们可以借助其轻松解决当年的 C10k 问题，也就是说如今如果你的程序主要是和网络打交道，那么瓶颈一定在用户程序而不在操作系统内核。
+从 linux 实现了 epoll，freebsd 实现了 kqueue，这个问题基本解决了，我们可以借助内核提供的 API 轻松解决当年的 C10k 问题，也就是说如今如果你的程序主要是和网络打交道，那么瓶颈一定在用户程序而不在操作系统内核。
 
-随着时代的发展，编程语言对这些系统调用又进一步进行了封装，如今做应用层开发，几乎不会在程序中看到 epoll 之类的字眼，大多数时候我们就只要聚焦在业务逻辑上就好，不用管底层是用的 epoll 还是 kqueue。C10k 已经很少被人所提起，摩尔定律让这个 10k 这个数字失去了意义。
-
-我们先来写一个简单的 `hello world` web 服务：
+随着时代的发展，编程语言对这些系统调用又进一步进行了封装，如今做应用层开发，几乎不会在程序中看到 epoll 之类的字眼，大多数时候我们就只要聚焦在业务逻辑上就好。Golang 的网络库针对不同平台封装了不同的 syscall API，http 库又是构建在 net 库之上，所以在 Go 我们可以借助标准库，很轻松地写出高性能的 http 服务，下面是一个简单的 `hello world` 服务的代码：
 
 ```go
 package main
@@ -33,7 +31,7 @@ func main() {
 }
 ```
 
-衡量一个 web 服务最重要的是其吞吐量，再具体一些，就是接口的 QPS。我们借助 wrk，在家用电脑 Macbook Pro 上对这个 `hello world` 服务进行基准测试，Mac 的硬件情况如下：
+我们需要衡量一下这个 web 服务的吞吐量，再具体一些，实际上就是接口的 QPS。借助 wrk，在家用电脑 Macbook Pro 上对这个 `hello world` 服务进行基准测试，Mac 的硬件情况如下：
 
 ```shell
 CPU: Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
@@ -89,7 +87,7 @@ Requests/sec:  45118.57
 Transfer/sec:      5.51MB
 ```
 
-多次测试的结果在 4w 左右的 QPS浮动，响应时间最多也就是 40ms 左右，对于一个 web 程序来说，这已经是很不错的成绩了，我们只是照抄了别人的示例代码，在五行以内解决了 C10k 问题，是不是很有成就感？
+多次测试的结果在 4w 左右的 QPS浮动，响应时间最多也就是 40ms 左右，对于一个 web 程序来说，这已经是很不错的成绩了，我们只是照抄了别人的示例代码，就完成了一个高性能的 `hello world` 服务器，是不是很有成就感？
 
 这还只是家用 PC，线上服务器大多都是 24 核心起，32G 内存+，CPU 基本都是 Intel i7。所以同样的程序在服务器上运行会得到更好的结果。