转自：https://murphypei.github.io/blog/2019/08/socket-ready

1.准备好读

引用《Unix网络编程》中的解释：

当满足下列条件之一时，一个套接字准备好读：

• 该套接字接收缓冲区中的数据字节数大于等于套接字接收缓冲区低水位标记的当前大小。对这样的套接字执行读操作不会阻塞并将返回一个大于 0 的值（也就是返回准备好读入的数据）。我们可以使用 SO_RCVLOWAT 套接字选项设置该套接字的低水位标记。对于 TCP 和 UDP 套接字而言，其默认值为 1。
• 该连接的读半部关闭（也就是接收了 FIN 的 TCP 连接）。对这样的套接字的读操作将不阻塞并返回 0 （也就是返回 EOF）。
• 该套接字是一个监听套接字且已完成的连接数不为 0。对这样的套接字的 accept 通常不会阻塞。
• 其上有一个套接字错误待处理。对这样的套接字的读操作将不阻塞并返回 -1（也就是返回一个错误），同时把 errno 设置成确切的错误条件。这些待处理错误也可以通过指定 SO_ERROR 套接字选项调用 getsockopt 获取并清除。

2.准备好写

当满足下列条件之一时，一个套接字准备好写：

• 该套接字发送缓冲区中的可用空间字节数大于等于套接字发送缓冲区低水位标记的当前大小，并且要求该套接字已连接（TCP）或者不需要连接（UDP）。这意味着如果我们把这样的套接字设置为非阻塞，写操作将不阻塞并返回一个正值（例如由传输层接收的字节数）。我们可以使用 SO_SNDLOWAT 套接字选项来设置该套接字的低水位标记。对于 TCP 和 UDP 套接字而言，其默认值通常为 2048。【为什么不会阻塞？写操作调用send从用户缓冲区发送到内核缓冲区，这个复制的过程不会阻塞吗？难道不是小于等于的时候直接写入用户缓冲区，这个过程不会阻塞吗？】
• 该连接的写半部关闭，对这样的套接字的写操作将产生 SIGPIPE 信号。
• 使用非阻塞式 connect 的套接字已建立连接，或者已经以失败告终。
• 其上有一个套接字错误待处理。对这样的套接字的写操作将不阻塞并返回 -1（也就是返回一个错误），同时把 errno 设置成确切的错误条件。这些待处理的错误也可以通过指定 SO_ERROR 套接字选项调用 getsockopt 获取并清除。

//针对第一条有疑问，发送缓冲区是将数据send到内核缓冲区，那么这个过程为什么不会阻塞呢？有系统调用的吧？需要具体理解send socket的过程，

【目前的理解是，写操作不会阻塞，只是说明发送区有数据发送，而无需等待数据。】

【居然看错了，第一条说的是发送缓冲区中可用空间字节数，而不是已存字节数。这是为了保证应用程序输出的数据能写到发送缓冲区，然后send返回，之后再系统调用写到内核缓冲区吧，只要发送有空间，内核那边应该没问题，或者是有回调告诉内核还剩多少空间。】

3.理解

https://blog.csdn.net/majianfei1023/article/details/45788591

通俗的解释一下，缓存区我们当成一个大小为 n bytes的空间，那么：

• 接收区缓存的作用就是，接收对面的数据放在缓存区，供应用程序读。当然了，只有当缓存区可读的数据量(接收低水位标记)到达一定程度（eg:1）的时候，我们才能读到数据，不然不就读不到数据了吗。

• 发送区缓存的作用就是，发送应用程序的数据到缓存区，然后一起发给对面。当然了，只有当缓存区剩余一定空间(发送低水位标记)（eg:2048）,你才能写数据进去，不然可能导致空间不够。

标签：返回,缓存,socket,发送缓冲区,读写,阻塞,接字,就绪,该套
来源： https://www.cnblogs.com/BlueBlueSea/p/14808177.html