开篇
之前简单看过一点go原生netpoll，没注意太多细节。最近从头到尾看了一遍，特写篇文章记录下。文章很长，请耐心看完，一定有所收获。
内核空间和用户空间
在linux中，经常能看到两个词语:User space(用户空间)和Kernel space (内核空间)。
简单地说， Kernel space是linux内核运行的空间，User space是用户程序运行的空间。它们之间是相互隔离的。
现代操作系统都是采用虚拟存储器。那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。
操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。
为了保证用户进程不能直接操作内核，保证内核的安全，系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。
针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。空间分配如下图所示：
Kernel space可以调用系统的一切资源。User space 不能直接调用系统资源，在 Linux系统中，所有的系统资源管理都是在内核空间中完成的。
比如读写磁盘文件、分配回收内存、从网络接口读写数据等等。应用程序无法直接进行这样的操作，但是用户程序可以通过内核提供的接口来完成这样的任务。
像下面这样，
应用程序要读取磁盘上的一个文件，它可以向内核发起一个 “系统调用” 告诉内核：”我要读取磁盘上的某某文件”。其实就是通过一个特殊的指令让进程从用户态进入到内核态。
在内核空间中，CPU 可以执行任何的指令，当然也包括从磁盘上读取数据。
具体过程是先把数据读取到内核空间中，然后再把数据拷贝到用户空间并从内核态切换到用户态。
此时应用程序已经从系统调用中返回并且拿到了想要的数据，继续往下执行用户空间执行逻辑。
这样的话，一旦涉及到对I/O的处理，就必然会涉及到在用户态和内核态之间来回切换。
io模型
网上有太多关于I/O模型的文章，看着看着有可能就跑偏了，所以我还是从 <<UNIX 网络编程>> 中总结的5中I/O模型说起吧。
Unix可用的5种I/O模型。
- 阻塞I/O
- 非阻塞I/O
- I/O复用
- 信号驱动式I/O(SIGIO)
- 异步I/O(POSIX的aio_系列函数)
阻塞I/O
阻塞式I/O下，进程调用recvfrom，直到数据到达且被复制到应用程序的缓冲区中或者发生错误才返回，在整个过程进程都是被阻塞的。
非阻塞I/O
从图中可以看出，前三次调用recvfrom中没有数据可返回，因此内核转而立即返回一个EWOULDBLOCK错误。
第四次调用recvfrom时已有一个数据报准备好，它被复制到应用程序缓冲区，于是recvfrom成功返回。
当一个应用程序像这样对一个非阻塞描述符循环调用recvfrom时，我们通常称为轮询(polling)，持续轮询内核，以这种方式查看某个操作是否就绪。
I/O多路复用
有了I/O多路复用(I/O multiplexing)，我们就可以调用 select 或者 poll，阻塞在这两个系统调用中的某一个之上，而不是阻塞在真正的I/O系统调用上。
上面这句话难理解是吧。
说白了这里指的是，在第一步中，我们只是阻塞在select调用上，直到数据报套接字变为可读，返回可读条件，这里并没有发生I/O事件，所以说这一步，并没有阻塞在真正的I/O系统调用上。
其他两种就不过多介绍了。还有一点，我们会经常提到同步I/O和异步I/O。
POSIX 把这两种术语定义如下:
- 同步I/O操作(synchronous I/O opetation) 导致请求进程被阻塞，直到I/O操作完成。
- 异步I/O(asynchronous opetation) 不导致请求进程被阻塞。
基于上面的定义，
异步I/O的关键在于第二步的recrfrom是否会阻塞住用户进程，如果不阻塞，那它就是异步I/O。从上面汇总图中可以看出，只有异步I/O满足POSIX中对异步I/O的定义。
Go netpoller
Go netpoller 底层就是对I/O多路复用的封装。不同平台对I/O多路复用有不同的实现方式。比如Linux的select、poll和epoll。
在MacOS则是kqueue,而Windows是基于异步I/O实现的icop......，基于这些背景，Go针对不同的平台调用实现了多版本的netpoller。
下面我们通过一个demo开始讲解。
很简单一个demo，开启一个tcp服务。然后每来一个连接，就启动一个g去处理连接。处理完毕，关闭连接。
而且我们使用的是同步的模式去编写异步的逻辑，一个连接对应一个g处理，极其简单和易于理解。go标准库中的http.server也是这么干的。
针对上面的tcp服务demo，我们需要关注这段代码底层都发生了什么。
上面代码中主要涉及底层的一些结构。
先简单解释一波。
- TCPListener:我们开启的是一个TCP服务，那当然就是TCP服务的网络监听器。
- netFD:网络描述符。Go中所有的网络操作都是以netFD实现的，它和底层FD做绑定。
- FD:文件描述符。net和os包把这个类型作为一个网络连接或者操作系统文件。其中里面一个字段Sysfd就是具体文件描述符值。
- pollDesc:I/O轮询器。说白了它就是底层事件驱动的封装。其中的runtimeCtx是一个指针类型，具体指向runtime/netpoll 中的pollDesc.
当然图上面结构字段都是阉割版的，但是不影响我们这篇文章。
还有一个问题，为什么结构上需要一层一层嵌入呢？我的理解是每下一层都是更加抽象的一层。它是可以作为上一层具体的一种应用体现。
是不是跟没说一样？哈哈。
举例，比如这里的netFD表示网络描述符。
它的上一层可以是用于TCP的网络监听器TCPListener，那么对应的接口我们能想到的有两个Accept以及close。
对于Accept 动作，一定是返回一个连接类型 Conn ，针对这个连接，它本身也存在一个自己的netFD，那么可想而知一定会有 Write和Read两个操作。
而所有的网络操作都是以netFD实现的。这样，netFD在这里就有两种不同的上层应用体现了。
好了,我们需要搞清楚几件事：
- 一般我们用其他语言写一个tcp服务，必然会写这几步：socket->bind->listen，但是Go就一个Listen，那就意味着底层包装了这些操作。它是在哪一步完成的？
- Go是在什么时候初始化netpoll的，比如linux下初始化epoll实例。
- 当对应fd没有可读或者可写的IO事件而对应被挂起的g，是如何知道fd上的I/O事件已ready，又是如何唤醒对应的g的？
Listen解析
带着这些问题，我们接着看流程。
上图已经把当你调用Listen操作的完整流程全部罗列出来了。
就像我上面列出的结构关系一样，从结构层次来说，每调用下一层，都是为了创建并获取下一层的依赖，因为内部的高度抽象与封装，才使得使用者往往只需调用极少数简单的API接口。
现在我们已经知道事例代码涉及到的结构以及对应流程了。
在传统印象中，创建一个网络服务。需要经过:创建一个socket、bind 、listen这基本的三大步。
前面我们说过，Go中所有的网络操作都是以netFD实现的。go也是在这一层封装这三大步的。所以我们直接从netFD逻辑开始说。
上图是在调用socket函数这一步返回的netFD，可想而知核心逻辑都在这里面。
我们可以把这个函数核心点看成三步。
- 调用sysSocket函数创建一个socket，返回一个文件描述符(file descriptor)，简称fd下文。
- 通过sysSocket返回的fd，调用newFD函数创建一个新的netFD。
- 调用netFD自身的方法listenStream函数，做初始化动作，具体详情下面再说。
在sysSocket函数中，首先会通过socketFunc来创建一个socket，通过层层查看，最终是通过system call来完成这一步。
当获取到对应fd时，会通过syscall.SetNonblock函数把当前这个fd设置成非阻塞模式，这样当这个Listener调用accept函数就不会被阻塞了。
第二步，通过第一步创建socket拿到的fd，创建一个新的netFD。这段代码没啥好解释的。
第三步，也就是最核心的一步，调用netFD自身的listenStream方法。
