1. 本节思维导图
2. 基本的网络编程接口
2.1 基于TCP的通信模型
2.2 基于UDP的通信模型
3. 非阻塞的服务器程序
file、pipe、fifo、socket在默认创建过程中都是阻塞的（block）,非阻塞的接口相比于阻塞型接口的显著差异在于，在被调用之后立即返回，在linux中我们可以使用fcntl()函数来设置描述符的状态
fcntl(fd，F_SETFL, O_NOBLOCK)
fcntl函数重点关注第二个参数中的F_SETFL和F_GETFL设置或获取描述符的状态
状态包括：O_NONBLOCK O_APPEND O_ASYNC
O_DIRCT（最小化或去掉reading和writing的缓存影响.系统将企图避免缓存你的读或写的数据）
在非阻塞的状态下，recv()接口在被调用后立即返回，返回值代表了不同的含义：
（）recv()返回值大于0，表示接收数据完毕，返回值即是接收到的字节数
（）recv()返回值为0，表示链接已经正常断开
（）recv()返回值为-，且errno等于EAGAIN,表示recv操作还没有执行完成
（）recv()返回值为-，且error不等于EAGAIN,表示recv操作遇到系统错误errno
注意：绝不推荐循环调用recv()来检测“操作是否完成”，循环调用recv将大幅度推高CPU占用率，实际操作系统提供了更为高效的方法来检测“操作是否完成”，比如select、epoll
4. select()接口的基于事件驱动的服务器模型
大部分UNIX/LINUX都支持select函数，改函数用于探测多个文件句柄的状态变化，以下为select接口的原型：
FD_ZERO(int fd, fd_set *fds) // fd_set类型变量的所有位都设为0
FD_SET(int fd, fd_set *fds ) // 设置变量的某个位置位
FD_ISSET(int fd, fd_set *fds) // 测试某个位置是否被置位
FD_CLR(int fd, fd_set *fds) // 清除某个位时可以使用
int select(int nfds, fd_set *readfds, fd_set *writefds, df_set *exceptfds, struct timeval *timeout)
关于select更加详细的说明和使用请参考：https://www.cnblogs.com/skyfsm/p/7079458.html
5. 使用epoll实现异步事件通知模型
已经在前面的博客中总结了epoll用法，具体参考：linux之epoll
这里重点说明下accept的使用技巧：
（1）阻塞模式accept存在的问题，考虑这种情况：TCP链接被客户端夭折，即在服务器调用accept之前，客户端主动发送RST终止链接，导致刚刚建立的链接从就绪队列中移除，如果套接口被设置为阻塞模式，服务器就会一直阻塞在accept调用上，直到其它某个客户端建立一个新的链接为止，但是在此期间，服务器单纯地阻塞在accept调用上，就需队列中的其它描述符都得不到处理
解决方法：把监听套接口设为非阻塞，当客户端在服务器调用accept之前中止某个连接时，accept调用可以立即返回-1，这时源自Berkeley的实现会在内核中处理该事件，并不会将该事件同质epoll。而其它实现把errno设置为ECONNABORTED或者EPROTo错误，我们可以忽略这两个错误。
（2）ET模式相爱的accept存在的问题，考虑这种情况：多个链接同时到达时，服务器的TCP就绪队列瞬间基类多喝就绪链接，由于是边缘触发模式，epoll只会通知一次，accept只处理第一个链接，导致TCP就绪队列中剩下的链接都得不到处理
解决方法：用while循环包住accept，处理完TCP就绪队列中的所有链接后再退出循环，如何知道是否处理完就绪队列中的所有链接呢？accept返回-1并且errno设置为EAGAIN就表示所有的链接都处理完。