auto commit

notes/Socket.md

@@ -5,7 +5,6 @@
     * [I/O 复用](#io-复用)
     * [信号驱动 I/O](#信号驱动-io)
     * [异步 I/O](#异步-io)
-    * [同步 I/O 与异步 I/O](#同步-io-与异步-io)
     * [五大 I/O 模型比较](#五大-io-模型比较)
 * [二、I/O 复用](#二io-复用)
     * [select](#select)
@@ -83,16 +82,14 @@ ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *
 
 <div align="center"> <img src="../pics//1492930243286_8.png"/> </div><br>
 
-## 同步 I/O 与异步 I/O
-
-- 同步 I/O：应用进程在调用 recvfrom 操作时会阻塞。
-- 异步 I/O：不会阻塞。
-
-阻塞式 I/O、非阻塞式 I/O、I/O 复用和信号驱动 I/O 都是同步 I/O，虽然非阻塞式 I/O 和信号驱动 I/O 在等待数据阶段不会阻塞，但是在之后的将数据从内核复制到应用进程这个操作会阻塞。
-
 ## 五大 I/O 模型比较
 
-前四种 I/O 模型的主要区别在于第一个阶段，而第二个阶段是一样的：将数据从内核复制到应用进程过程中，应用进程会被阻塞。
+- 同步 I/O：将数据从内核缓冲区复制到应用进程缓冲区的阶段，应用进程会阻塞。
+- 异步 I/O：不会阻塞。
+
+阻塞式 I/O、非阻塞式 I/O、I/O 复用和信号驱动 I/O 都是同步 I/O，它们的主要区别在第一个阶段。
+
+非阻塞式 I/O 、信号驱动 I/O 和异步 I/O 在第一阶段不会阻塞。
 
 <div align="center"> <img src="../pics//1492928105791_3.png"/> </div><br>
 
@@ -299,7 +296,7 @@ epoll 的描述符事件有两种触发模式：LT（level trigger）和 ET（ed
 
 ### 1. select 应用场景
 
-select 的 timeout 参数精度为 1ns，而 poll 和 epoll 为 1ms，因此 select 更加适用于实时要求更高的场景，比如核反应堆的控制。
+select 的 timeout 参数精度为 1ns，而 poll 和 epoll 为 1ms，因此 select 更加适用于实时性要求比较高的场景，比如核反应堆的控制。
 
 select 可移植性更好，几乎被所有主流平台所支持。
 
@@ -309,11 +306,11 @@ poll 没有最大描述符数量的限制，如果平台支持并且对实时性
 
 ### 3. epoll 应用场景
 
-只需要运行在 Linux 平台上，并且有非常大量的描述符需要同时轮询，而且这些连接最好是长连接。
+只需要运行在 Linux 平台上，有大量的描述符需要同时轮询，并且这些连接最好是长连接。
 
 需要同时监控小于 1000 个描述符，就没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势。
 
-需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且epoll 的描述符存储在内核，不容易调试。
+需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且 epoll 的描述符存储在内核，不容易调试。
 
 # 参考资料