网络性能篇

倪朋飞 《Linux 性能优化实战》
33 | 关于 Linux 网络，你必须知道这些（上）
　　网络模型：7层网络模型（OSI 网络模型）与4层网络模型（TCP/IP 网络模型）

Linux 网络收发流程;环形缓冲区、sk_buff 缓冲区、套接字缓冲区；网卡接收数据后，经过几次拷贝才能到用户进程
===================================================================================================
网络包的接收流程


1.当一个网络帧到达网卡后，网卡会通过 DMA 方式，把这个网络包放到收包队列中；然后通过硬中断，告诉中断处理程序已经收到了网络包。

2.接着，网卡中断处理程序会为网络帧分配内核数据结构（sk_buff），并将其拷贝到 sk_buff 缓冲区中；然后再通过软中断，通知内核收到了新的网络帧。

3.接下来，内核协议栈从缓冲区中取出网络帧，并通过网络协议栈，从下到上逐层处理这个网络帧。比如，
    a.在链路层检查报文的合法性，找出上层协议的类型（比如 IPv4 还是 IPv6），再去掉帧头、帧尾，然后交给网络层。
    b.网络层取出 IP 头，判断网络包下一步的走向，比如是交给上层处理还是转发。当网络层确认这个包是要发送到本机后，就会取出上层协议的类型（比如 TCP 还是 UDP），去掉 IP 头，再交给传输层处理。
    c.传输层取出 TCP 头或者 UDP 头后，根据 < 源 IP、源端口、目的 IP、目的端口 > 四元组作为标识，找出对应的 Socket，并把数据拷贝到 Socket 的接收缓存中。

4.最后，应用程序就可以使用 Socket 接口，读取到新接收到的数据了。

--------------------------------------------------------------------------------------------
https://segmentfault.com/a/1190000008836467
    1： 数据包从外面的网络进入物理网卡。如果目的地址不是该网卡，且该网卡没有开启混杂模式，该包会被网卡丢弃。
    2： 网卡将数据包通过DMA的方式写入到指定的内存地址，该地址由网卡驱动分配并初始化。注： 老的网卡可能不支持DMA，不过新的网卡一般都支持。
    3： 网卡通过硬件中断（IRQ）通知CPU，告诉它有数据来了
    4： CPU根据中断表，调用已经注册的中断函数，这个中断函数会调到驱动程序（NIC Driver）中相应的函数
    5： 驱动先禁用网卡的中断，表示驱动程序已经知道内存中有数据了，告诉网卡下次再收到数据包直接写内存就可以了，不要再通知CPU了，这样可以提高效率，避免CPU不停的被中断。
    6： 启动软中断。这步结束后，硬件中断处理函数就结束返回了。由于硬中断处理程序执行的过程中不能被中断，所以如果它执行时间过长，会导致CPU没法响应其它硬件的中断，于是内核引入软中断，这样可以将硬中断处理函数中耗时的部分移到软中断处理函数里面来慢慢处理。

软中断会触发内核网络模块中的软中断处理函数，后续流程如下
    7： 内核中的ksoftirqd进程专门负责软中断的处理，当它收到软中断后，就会调用相应软中断所对应的处理函数，对于上面第6步中是网卡驱动模块抛出的软中断，ksoftirqd会调用网络模块的net_rx_action函数
    8： net_rx_action调用网卡驱动里的poll函数来一个一个的处理数据包
    9： 在pool函数中，驱动会一个接一个的读取网卡写到内存中的数据包，内存中数据包的格式只有驱动知道
    10： 驱动程序将内存中的数据包转换成内核网络模块能识别的skb格式，然后调用napi_gro_receive函数
    11： napi_gro_receive会处理GRO相关的内容，也就是将可以合并的数据包进行合并，这样就只需要调用一次协议栈。然后判断是否开启了RPS，如果开启了，将会调用enqueue_to_backlog
    12： 在enqueue_to_backlog函数中，会将数据包放入CPU的softnet_data结构体的input_pkt_queue中，然后返回，如果input_pkt_queue满了的话，该数据包将会被丢弃，queue的大小可以通过net.core.netdev_max_backlog来配置
    13： CPU会接着在自己的软中断上下文中处理自己input_pkt_queue里的网络数据（调用__netif_receive_skb_core）
    14： 如果没开启RPS，napi_gro_receive会直接调用__netif_receive_skb_core
    15： 看是不是有AF_PACKET类型的socket（也就是我们常说的原始套接字），如果有的话，拷贝一份数据给它。tcpdump抓包就是抓的这里的包。
    16： 调用协议栈相应的函数，将数据包交给协议栈处理。
    17： 待内存中的所有数据包被处理完成后（即poll函数执行完成），启用网卡的硬中断，这样下次网卡再收到数据的时候就会通知CPU

由于是UDP包，所以第一步会进入IP层，然后一级一级的函数往下调：
    ip_rcv： ip_rcv函数是IP模块的入口函数，在该函数里面，第一件事就是将垃圾数据包（目的mac地址不是当前网卡，但由于网卡设置了混杂模式而被接收进来）直接丢掉，然后调用注册在NF_INET_PRE_ROUTING上的函数
    NF_INET_PRE_ROUTING： netfilter放在协议栈中的钩子，可以通过iptables来注入一些数据包处理函数，用来修改或者丢弃数据包，如果数据包没被丢弃，将继续往下走
    routing： 进行路由，如果是目的IP不是本地IP，且没有开启ip forward功能，那么数据包将被丢弃，如果开启了ip forward功能，那将进入ip_forward函数
    ip_forward： ip_forward会先调用netfilter注册的NF_INET_FORWARD相关函数，如果数据包没有被丢弃，那么将继续往后调用dst_output_sk函数
    dst_output_sk： 该函数会调用IP层的相应函数将该数据包发送出去，同下一篇要介绍的数据包发送流程的后半部分一样。
    ip_local_deliver：如果上面routing的时候发现目的IP是本地IP，那么将会调用该函数，在该函数中，会先调用NF_INET_LOCAL_IN相关的钩子程序，如果通过，数据包将会向下发送到UDP层

    udp_rcv： udp_rcv函数是UDP模块的入口函数，它里面会调用其它的函数，主要是做一些必要的检查，其中一个重要的调用是__udp4_lib_lookup_skb，该函数会根据目的IP和端口找对应的socket，如果没有找到相应的socket，那么该数据包将会被丢弃，否则继续
    sock_queue_rcv_skb： 主要干了两件事，一是检查这个socket的receive buffer是不是满了，如果满了的话，丢弃该数据包，然后就是调用sk_filter看这个包是否是满足条件的包，如果当前socket上设置了filter，且该包不满足条件的话，这个数据包也将被丢弃（在Linux里面，每个socket上都可以像tcpdump里面一样定义filter，不满足条件的数据包将会被丢弃）
    __skb_queue_tail： 将数据包放入socket接收队列的末尾
    sk_data_ready： 通知socket数据包已经准备好

socket
    应用层一般有两种方式接收数据，一种是recvfrom函数阻塞在那里等着数据来，这种情况下当socket收到通知后，recvfrom就会被唤醒，然后读取接收队列的数据；
    另一种是通过epoll或者select监听相应的socket，当收到通知后，再调用recvfrom函数去读取接收队列的数据。两种情况都能正常的接收到相应的数据包。
--------------------------------------------------------------------------------------------
45 | 答疑（五）：网络收发过程中，缓冲区位置在哪里？................
Linux 网络的收发流程。这个流程涉及到了多个队列和缓冲区，包括：
    网卡收发网络包时，通过 DMA 方式交互的环形缓冲区；
    网卡中断处理程序为网络帧分配的，内核数据结构 sk_buff 缓冲区；
    应用程序通过套接字接口，与网络协议栈交互时的套接字缓冲区。

1.这些缓冲区都处于内核管理的内存中。
    环形缓冲区，由于需要 DMA 与网卡交互，理应属于网卡设备驱动的范围。
    sk_buff 缓冲区，是一个维护网络帧结构的双向链表，链表中的每一个元素都是一个网络帧（Packet）。
        虽然 TCP/IP 协议栈分了好几层，但上下不同层之间的传递，实际上只需要操作这个数据结构中的指针，而无需进行数据复制。
    套接字缓冲区，则允许应用程序，给每个套接字配置不同大小的接收或发送缓冲区。
        应用程序发送数据，实际上就是将数据写入缓冲区；
        应用程序接收数据，其实就是从缓冲区中读取。至于缓冲区中数据的进一步处理，则由传输层的 TCP 或 UDP 协议来完成。

2.这些缓冲区，跟前面内存部分讲到的 Buffer 和 Cache 有什么关联吗？
    在内存模块曾提到过，内存中提到的 Buffer ，都跟块设备直接相关；而其他的都是 Cache。
    实际上，sk_buff、套接字缓冲、连接跟踪等，都通过 slab 分配器来管理。你可以直接通过 /proc/slabinfo，来查看它们占用的内存大小。
    
--------------------------------------------------------------------------------------------
Linux经典面试题：网卡接收数据后，经过几次拷贝才能到用户进程
https://www.isolves.com/it/rj/czxt/linux/2021-07-04/41098.html

    1、当数据包到达网卡依据配置会将网络数据拷贝到DMA中，并触发硬件中断
    2、驱动程序将从ring buffer中读取，填充内核skbuff结构。执行上层协议栈操作
    3、socket read操作将数据从内核拷贝到用户态

Linux 网络收发流程;环形缓冲区、sk_buff 缓冲区、套接字缓冲区；网卡接收数据后，经过几次拷贝才能到用户进程

网络包的发送流程
https://segmentfault.com/a/1190000008926093

了解网络包的接收流程后，就很容易理解网络包的发送流程。网络包的发送流程就是上图的右半部分，很容易发现，网络包的发送方向，正好跟接收方向相反。

1.首先，应用程序调用 Socket API（比如 sendmsg）发送网络包。

2.由于这是一个系统调用，所以会陷入到内核态的套接字层中。套接字层会把数据包放到 Socket 发送缓冲区中。

3.接下来，网络协议栈从 Socket 发送缓冲区中，取出数据包；再按照 TCP/IP 栈，从上到下逐层处理。比如，传输层和网络层，分别为其增加 TCP 头和 IP 头，执行路由查找确认下一跳的 IP，并按照 MTU 大小进行分片。

4.分片后的网络包，再送到网络接口层，进行物理地址寻址，以找到下一跳的 MAC 地址。然后添加帧头和帧尾，放到发包队列中。这一切完成后，会有软中断通知驱动程序：发包队列中有新的网络帧需要发送。

5.最后，驱动程序通过 DMA ，从发包队列中读出网络帧，并通过物理网卡把它发送出去。
网络包的发送流程

34 | 关于 Linux 网络，你必须知道这些（下）

性能指标：带宽、吞吐量、延时、PPS、网络的可用性（网络能否正常通信）、并发连接数（TCP 连接数量）、丢包率（丢包百分比）、重传率（重新传输的网络包比例）
=========================================================================================================================
带宽，表示链路的最大传输速率，单位通常为 b/s （比特 / 秒）。
吞吐量，表示单位时间内成功传输的数据量，单位通常为 b/s（比特 / 秒）或者 B/s（字节 / 秒）。吞吐量受带宽限制，而吞吐量 / 带宽，也就是该网络的使用率。
延时，表示从网络请求发出后，一直到收到远端响应，所需要的时间延迟。在不同场景中，这一指标可能会有不同含义。比如，它可以表示，建立连接需要的时间（比如 TCP 握手延时），或一个数据包往返所需的时间（比如 RTT）。
PPS，是 Packet Per Second（包 / 秒）的缩写，表示以网络包为单位的传输速率。PPS 通常用来评估网络的转发能力，比如硬件交换机，通常可以达到线性转发（即 PPS 可以达到或者接近理论最大值）。而基于 Linux 服务器的转发，则容易受网络包大小的影响。

除了这些指标，网络的可用性（网络能否正常通信）、并发连接数（TCP 连接数量）、丢包率（丢包百分比）、重传率（重新传输的网络包比例）等也是常用的性能指标。

性能指标：带宽、吞吐量、延时、PPS、网络的可用性（网络能否正常通信）、并发连接数（TCP 连接数量）、丢包率（丢包百分比）、重传率（重新传输的网络包比例）

ifconfig、ip -s addr 输出解析
================================================================================================
$ ifconfig eth0
eth0: flags=4163 mtu 1500
      inet 10.240.0.30 netmask 255.240.0.0 broadcast 10.255.255.255
      inet6 fe80::20d:3aff:fe07:cf2a prefixlen 64 scopeid 0x20
      ether 78:0d:3a:07:cf:3a txqueuelen 1000 (Ethernet)
      RX packets 40809142 bytes 9542369803 (9.5 GB)
      RX errors 0 dropped 0 overruns 0 frame 0
      TX packets 32637401 bytes 4815573306 (4.8 GB)
      TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
​
$ ip -s addr show dev eth0
    2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
      link/ether 78:0d:3a:07:cf:3a brd ff:ff:ff:ff:ff:ff
      inet 10.240.0.30/12 brd 10.255.255.255 scope global eth0
          valid_lft forever preferred_lft forever
      inet6 fe80::20d:3aff:fe07:cf2a/64 scope link
          valid_lft forever preferred_lft forever
      RX: bytes packets errors dropped overrun mcast
       9542432350 40809397 0       0       0       193
      TX: bytes packets errors dropped carrier collsns
       4815625265 32637658 0       0       0       0

第一，网络接口的状态标志。ifconfig 输出中的 RUNNING ，或 ip 输出中的 LOWER_UP ，都表示物理网络是连通的，即网卡已经连接到了交换机或者路由器中。如果你看不到它们，通常表示网线被拔掉了。
第二，MTU 的大小。MTU 默认大小是 1500，根据网络架构的不同（比如是否使用了 VXLAN 等叠加网络），你可能需要调大或者调小 MTU 的数值。
第三，网络接口的 IP 地址、子网以及 MAC 地址。这些都是保障网络功能正常工作所必需的，你需要确保配置正确。
第四，网络收发的字节数、包数、错误数以及丢包情况，特别是 TX 和 RX 部分的 errors、dropped、overruns、carrier 以及 collisions 等指标不为 0 时，通常表示出现了网络 I/O 问题。其中：
    errors 表示发生错误的数据包数，比如校验错误、帧同步错误等；
    dropped 表示丢弃的数据包数，即数据包已经收到了 Ring Buffer，但因为内存不足等原因丢包；
    overruns 表示超限数据包数，即网络 I/O 速度过快，导致 Ring Buffer 中的数据包来不及处理（队列满）而导致的丢包；
    carrier 表示发生 carrirer 错误的数据包数，比如双工模式不匹配、物理电缆出现问题等；
    collisions 表示碰撞数据包数。

ifconfig、ip -s addr 输出解析

套接字信息：netstat -nlp、ss -ltnp；协议栈统计信息：netstat -s、ss -s
================================================================================================
$ netstat -nlp | head -n 3      # -p 表示显示进程信息
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
    tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      840/systemd-resolve


$ ss -ltnp | head -n 3          # -p 表示显示进程信息
    State    Recv-Q    Send-Q        Local Address:Port        Peer Address:Port
    LISTEN   0         128           127.0.0.53%lo:53               0.0.0.0:*        users:(("systemd-resolve",pid=840,fd=13))
    LISTEN   0         128                 0.0.0.0:22               0.0.0.0:*        users:(("sshd",pid=1459,fd=3))


接收队列（Recv-Q）和发送队列（Send-Q）需要你特别关注，它们通常应该是 0。当你发现它们不是 0 时，说明有网络包的堆积发生。

在不同套接字状态下，它们的含义不同:
    当套接字处于连接状态（Established）时，
        Recv-Q 表示套接字缓冲还没有被应用程序取走的字节数（即接收队列长度）。
        而 Send-Q 表示还没有被远端主机确认的字节数（即发送队列长度）。

    当套接字处于监听状态（Listening）时，
        Recv-Q 表示全连接队列的长度。
        而 Send-Q 表示全连接队列的最大长度。

所谓全连接，是指服务器收到了客户端的 ACK，完成了 TCP 三次握手，然后就会把这个连接挪到全连接队列中。这些全连接中的套接字，还需要被 accept() 系统调用取走，服务器才可以开始真正处理客户端的请求。
与全连接队列相对应的，还有一个半连接队列。所谓半连接是指还没有完成 TCP 三次握手的连接，连接只进行了一半。服务器收到了客户端的 SYN 包后，就会把这个连接放到半连接队列中，然后再向客户端发送 SYN+ACK 包。

---------------------------------------------------------------------------------------------------
协议栈统计信息

$ netstat -s
    ...
    Tcp:
        3244906 active connection openings
        23143 passive connection openings
        115732 failed connection attempts
        2964 connection resets received
        1 connections established
        13025010 segments received
        17606946 segments sent out
        44438 segments retransmitted
        42 bad segments received
        5315 resets sent
        InCsumErrors: 42
    ...
$ ss -s
    Total: 186 (kernel 1446)
    TCP:   4 (estab 1, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 0
    Transport Total     IP        IPv6
    *    1446      -         -
    RAW    2         1         1
    UDP    2         2         0
    TCP    4         3         1
    ...

ss 只显示已经连接、关闭、孤儿套接字等简要统计，而 netstat 则提供的是更详细的网络协议栈信息。
套接字信息：netstat -nlp、ss -ltnp；协议栈统计信息：netstat -s、ss -s

网络吞吐和 PPS ：sar -n DEV；带宽用 ethtool 来查询；连通性和延时：ping测试
==================================================================================================================
sar 增加 -n 参数就可以查看网络的统计信息，比如网络接口（DEV）、网络接口错误（EDEV）、TCP、UDP、ICMP 等等

$ sar -n DEV 1      # 数字1表示每隔1秒输出一组数据
Linux 4.15.0-1035 (ubuntu)   01/06/19   _x86_64_  (2 CPU)
13:21:40        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
13:21:41         eth0     18.00     20.00      5.79      4.25      0.00      0.00      0.00      0.00
13:21:41      docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
13:21:41           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

    rxpck/s 和 txpck/s 分别是接收和发送的 PPS，单位为包 / 秒。
    rxkB/s 和 txkB/s 分别是接收和发送的吞吐量，单位是 KB/ 秒。
    rxcmp/s 和 txcmp/s 分别是接收和发送的压缩数据包数，单位是包 / 秒。
    %ifutil 是网络接口的使用率，即半双工模式下为 (rxkB/s+txkB/s)/Bandwidth，而全双工模式下为 max(rxkB/s, txkB/s)/Bandwidth。

--------------------------------------------------------------------------------------------------------------
Bandwidth 可以用 ethtool 来查询，它的单位通常是 Gb/s 或者 Mb/s，不过注意这里小写字母 b ，表示比特而不是字节。我们通常提到的千兆网卡、万兆网卡等，单位也都是比特。
$ ethtool eth0 | grep Speed
  Speed: 1000Mb/s

--------------------------------------------------------------------------------------------------------------
# -c3表示发送三次ICMP包后停止
$ ping -c3 114.114.114.114
PING 114.114.114.114 (114.114.114.114) 56(84) bytes of data.
64 bytes from 114.114.114.114: icmp_seq=1 ttl=54 time=244 ms
64 bytes from 114.114.114.114: icmp_seq=2 ttl=47 time=244 ms
64 bytes from 114.114.114.114: icmp_seq=3 ttl=67 time=244 ms
--- 114.114.114.114 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 244.023/244.070/244.105/0.034 ms

网络吞吐和 PPS ：sar -n DEV；带宽用 ethtool 来查询；连通性和延时：ping测试

35 | 基础篇：C10K 和 C1000K 回顾

C100的网络处理模型
在 C10K 以前，Linux 中网络处理都用同步阻塞的方式，也就是每个请求都分配一个进程或者线程。
    问题：请求数只有 100 个时，这种方式自然没问题，但增加到 10000 个请求时，10000 个进程或线程的调度、上下文切换乃至它们占用的内存，都会成为瓶颈。

C100升级至C10K的优化：I/O 模型优化：I/O 多路复用(select/poll、epoll、异步 I/O)+工作模型优化（主进程+多个 worker 子进程；监听到相同端口的多进程模型）
=========================================================================================================================
I/O 模型优化

 I/O 事件通知的方式：水平触发和边缘触发，它们常用在套接字接口的文件描述符中。
    水平触发：只要文件描述符可以非阻塞地执行 I/O ，就会触发通知。
        也就是说，应用程序可以随时检查文件描述符的状态，然后再根据状态，进行 I/O 操作。
    边缘触发：只有在文件描述符的状态发生改变（也就是 I/O 请求达到）时，才发送一次通知。
        这时候，应用程序需要尽可能多地执行 I/O，直到无法继续读写，才可以停止。如果 I/O 没执行完，或者因为某种原因没来得及处理，那么这次通知也就丢失了。


 I/O 多路复用:
    第一种，使用非阻塞 I/O 和水平触发通知，比如使用 select 或者 poll。
        根据刚才水平触发的原理，select 和 poll 需要从文件描述符列表中，找出哪些可以执行 I/O ，然后进行真正的网络 I/O 读写。
        由于 I/O 是非阻塞的，一个线程中就可以同时监控一批套接字的文件描述符，这样就达到了单线程处理多请求的目的。
        问题：应用软件使用 select 和 poll 时，需要对这些文件描述符列表进行轮询，这样，请求数多的时候就会比较耗时。并且，select 和 poll 还有一些其他的限制。
            select 使用固定长度的位相量，表示文件描述符的集合，因此会有最大描述符数量的限制。
            比如，在 32 位系统中，默认限制是 1024。并且，在 select 内部，检查套接字状态是用轮询的方法，处理耗时跟描述符数量是 O(N) 的关系。
            poll 改进了 select 的表示方法，换成了一个没有固定长度的数组，这样就没有了最大描述符数量的限制（当然还会受到系统文件描述符限制）。
            但应用程序在使用 poll 时，同样需要对文件描述符列表进行轮询，这样，处理耗时跟描述符数量就是 O(N) 的关系。
            除此之外，应用程序每次调用 select 和 poll 时，还需要把文件描述符的集合，从用户空间传入内核空间，由内核修改后，再传出到用户空间中。这一来一回的内核空间与用户空间切换，也增加了处理成本。
    第二种，使用非阻塞 I/O 和边缘触发通知，比如 epoll。
        epoll 使用红黑树，在内核中管理文件描述符的集合，这样，就不需要应用程序在每次操作时都传入、传出这个集合。
        epoll 使用事件驱动的机制，只关注有 I/O 事件发生的文件描述符，不需要轮询扫描整个集合。
    第三种，使用异步 I/O（Asynchronous I/O，简称为 AIO）。
        异步 I/O 允许应用程序同时发起很多 I/O 操作，而不用等待这些操作完成。
        而在 I/O 完成后，系统会用事件通知（比如信号或者回调函数）的方式，告诉应用程序。这时，应用程序才会去查询 I/O 操作的结果。
            由于异步 I/O 跟我们的直观逻辑不太一样，想要使用的话，一定要小心设计，其使用难度比较高。

工作模型优化
    第一种，主进程 + 多个 worker 子进程，这也是最常用的一种模型。这种方法的一个通用工作模式就是：
        主进程执行 bind() + listen() 后，创建多个子进程；
        然后，在每个子进程中，都通过 accept() 或 epoll_wait() ，来处理相同的套接字。
        例如nginx：是由主进程和多个 worker 进程组成。
            主进程主要用来初始化套接字，并管理子进程的生命周期；
            而 worker 进程，则负责实际的请求处理。
        惊群：
            当网络 I/O 事件发生时，多个进程被同时唤醒，但实际上只有一个进程来响应这个事件，其他被唤醒的进程都会重新休眠。
        为了避免惊群问题， Nginx 在每个 worker 进程中，都增加一个了全局锁（accept_mutex）。这些 worker 进程需要首先竞争到锁，只有竞争到锁的进程，才会加入到 epoll 中，这样就确保只有一个 worker 子进程被唤醒。
        进程的管理、调度、上下文切换的成本非常高。那为什么使用多进程模式的 Nginx ，却具有非常好的性能呢？
            最主要的一个原因就是，这些 worker 进程，实际上并不需要经常创建和销毁，而是在没任务时休眠，有任务时唤醒。只有在 worker 由于某些异常退出时，主进程才需要创建新的进程来代替它。
    
    第二种，监听到相同端口的多进程模型。
        在这种方式下，所有的进程都监听相同的接口，并且开启 SO_REUSEPORT 选项，由内核负责将请求负载均衡到这些监听进程中去。
            由于内核确保了只有一个进程被唤醒，就不会出现惊群问题了。
            不过要注意，想要使用 SO_REUSEPORT 选项，需要用 Linux 3.9 以上的版本才可以。
----------------------------------------------------------------------------------------
C10K 问题的根源，一方面在于系统有限的资源；另一方面，也是更重要的因素，是同步阻塞的 I/O 模型以及轮询的套接字接口，限制了网络事件的处理效率。
    Linux 2.6 中引入的 epoll ，完美解决了 C10K 的问题，现在的高性能网络方案都基于 epoll。

C100升级至C10K的优化：I/O 模型优化：I/O 多路复用(select/poll、epoll、异步 I/O)+工作模型优化（主进程+多个 worker 子进程；监听到相同端口的多进程模型）

C10K升级至C100K的优化
========&#