继续写我的mini服务器monkv。目前还只能支持get方法。
今天用webbench做压测的时候，效果非常差，百思不得其解。按理说我这个mini服务器做的全部工作就是根据url读响应的文件，然后写入客户端socket，正因为处理过程非常简单，所以性能应该很高才对，为什么显示性能很差呢？
找了半天原因，还是epoll设置问题以及对recv和send方法返回值的理解不够，在网上找了资料，找到一篇文章很好，文章链接在后面的参考里面。所以现在把关于epoll以及与epoll对应的I/O的知识再梳理一遍。其实就是把这篇文章里面的东西拷贝了过来，但把一篇文章细细读一遍，然后转述一下，还是很有意义的。
epoll的流程
1，新建服务端socket，暂记为server_sock，将server_sock注册到epoll
2，监听epoll，如果server_sock上有可读事件，说明有来自客户端的新连接，accept客户端连接（* 插入一个问题，回想一下TCP三次握手的流程，accept方法是哪一步返回呢 *），暂记为client_sock，并注册进epoll事件（该客户端socket可以设置非阻塞或者非阻塞）
3，监听epoll，如果客户端socket上有可读事件。用read或者recv方法读取client_sock上的字符串，。有以下几种情况：
recv返回值 > 0：读到了内容，正常处理
recv返回值 = 0：客户端对方的socket关闭，处理方式：关闭客户端socket，删除epoll事件，并且记入log
-
recv返回值 < 0：出错，并且设置errno，出错又分为以下情况：
errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN：连接正常，常见的原因是已经全部读取socket数据，更新epoll事件，并且处理已经读到的内容，需要注意的是如果socket是阻塞的，则会一直阻塞在recv方法上
其他情况，连接异常，处理方式：关闭客户端socket，删除epoll事件，并且记入log
4，读完socket之后，解析字符串，生成响应文本，开始等待epoll的写入事件，调用send方法。send方法的返回值以及对应的含义包括errno和recv方式类似
与I/O相关的errno以及对应的含义
EAGAIN：套接字已标记为非阻塞，而接收操作被阻塞或者接收超时
EBADF：sock不是有效的描述词
ECONNREFUSE：远程主机阻绝网络连接
EFAULT：内存空间访问出错
EINTR：操作被信号中断
EINVAL：参数无效
ENOMEM：内存不足
ENOTCONN：与面向连接关联的套接字尚未被连接上
ENOTSOCK：sock索引的不是套接字 当返回值是0时，为正常关闭连接
EWOULDBLOCK：与EAGAIN相同
还有几个问题不太明白（不知道下面的描述能不能看懂）
- socket上的缓存区是在内核空间吗？
- read或者recv是复制socket缓存区上的内容到指定地址上，复制之后肯定还要删除socket读写缓存以便进行下一次I/O。具体的过程是怎样的？
关于I/O的重要性以及。。。某些吐槽
以前对I/O并不重视，觉得非常简单。我之前是做PHP的（其实如果没有变化的话，今后我也是做PHP的，不过以前是纯PHP程序员，今后可能是伪装成PHPer的C程序员，嘿嘿），类似PHP这种高级语言做的更多是表现层面的事情，已经将I/O封装的很完美了，所以不需要了解I/O的具体细节就可以实现很多炫酷的功能。记得第一次看《Unix环境高级编程》的时候，觉得几乎整本书都在讲I/O，这有什么好讲的呢？现在看，我真是naive呀，too young too simple。
曾经你觉得不值一提的东西，会在将来的某个瞬间，忽然让你莫名的心痛。早岁那知世事艰呀，只是当时已惘然。这是我这些年来一直重复不断的一种体验。
I/O太重要了。从某种意义上说，计算机的工作就两个，计算和I/O，所有的程序无非是趋向于计算或者趋向于I/O。而网络编程，例如HTTP或者TCP，甚至UDP，都是偏向I/O的。对大多数的web应用而言，I/O是网络编程里面资源消耗最大的部分。所以对I/O的理解和熟悉是一个网络工程师的最核心素质之一。
我的路还很长，最近常常陷入一种迷茫，就是感觉自己明白了一个知识点之后随即发现这个知识点背后还有五个六个甚至十个知识点需要去学习。知识是越学越多，又找不到工作，进亦忧退亦忧。我也挺努力的，为人也温和圆润，但就是不知道为什么，我的生活总会陷入一种怪圈。我不胜其烦却无能为力。
说句心里话，这些年，我活得很不尽兴。
参考文章：
