[[386495]]

本文轉(zhuǎn)載自微信公眾號(hào)「開發(fā)內(nèi)功修煉」，作者張彥飛allen 。轉(zhuǎn)載本文請(qǐng)聯(lián)系開發(fā)內(nèi)功修煉公眾號(hào)。

在網(wǎng)絡(luò)開發(fā)模型中，有一種非常易于開發(fā)同學(xué)使用的方式，那就是同步阻塞的網(wǎng)絡(luò) IO(在 Java 中習(xí)慣叫 BIO)。

例如我們想請(qǐng)求服務(wù)器上的一段數(shù)據(jù)，那么 C 語言的一段代碼 demo 大概是下面這樣：

int main() 
{ 
 int sk = socket(AF_INET, SOCK_STREAM, 0); 
 connect(sk, ...) 
 recv(sk, ...) 
} 

但是在高并發(fā)的服務(wù)器開發(fā)中，這種網(wǎng)絡(luò) IO 的性能奇差。因?yàn)?/p>

1.進(jìn)程在 recv 的時(shí)候大概率會(huì)被阻塞掉，導(dǎo)致一次進(jìn)程切換

2.當(dāng)連接上數(shù)據(jù)就緒的時(shí)候進(jìn)程又會(huì)被喚醒，又是一次進(jìn)程切換

3.一個(gè)進(jìn)程同時(shí)只能等待一條連接，如果有很多并發(fā)，則需要很多進(jìn)程

如果用一句話來概括，那就是：同步阻塞網(wǎng)絡(luò) IO 是高性能網(wǎng)絡(luò)開發(fā)路上的絆腳石! 俗話說得好，知己知彼方能百戰(zhàn)百勝。所以我們今天先不講優(yōu)化，只深入分析同步阻塞網(wǎng)絡(luò) IO 的內(nèi)部實(shí)現(xiàn)。

在上面的 demo 中雖然只是簡單的兩三行代碼，但實(shí)際上用戶進(jìn)程和內(nèi)核配合做了非常多的工作。先是用戶進(jìn)程發(fā)起創(chuàng)建 socket 的指令，然后切換到內(nèi)核態(tài)完成了內(nèi)核對(duì)象的初始化。接下來 Linux 在數(shù)據(jù)包的接收上，是硬中斷和 ksoftirqd 進(jìn)程在進(jìn)行處理。當(dāng) ksoftirqd 進(jìn)程處理完以后，再通知到相關(guān)的用戶進(jìn)程。

從用戶進(jìn)程創(chuàng)建 socket，到一個(gè)網(wǎng)絡(luò)包抵達(dá)網(wǎng)卡到被用戶進(jìn)程接收到，總體上的流程圖如下：

 

我們今天用圖解加源碼分析的方式來詳細(xì)拆解一下上面的每一個(gè)步驟，來看一下在內(nèi)核里是它們是怎么實(shí)現(xiàn)的。閱讀完本文，你將深刻地理解在同步阻塞的網(wǎng)絡(luò) IO 性能低下的原因!

一、創(chuàng)建一個(gè) socket

開篇源碼中的 socket 函數(shù)調(diào)用執(zhí)行完以后，內(nèi)核在內(nèi)部創(chuàng)建了一系列的 socket 相關(guān)的內(nèi)核對(duì)象(是的，不是只有一個(gè))。它們互相之間的關(guān)系如圖。當(dāng)然了，這個(gè)對(duì)象比圖示的還要更復(fù)雜。我只在圖中把和今天的主題相關(guān)的內(nèi)容展現(xiàn)了出來。

 

我們來翻翻源碼，看下上面的結(jié)構(gòu)是如何被創(chuàng)造出來的。

//file:net/socket.c 
SYSCALL_DEFINE3(socket, int, family, int, type, int, protocol) 
{ 
 ...... 
 retval = sock_create(family, type, protocol, &sock); 
} 

sock_create 是創(chuàng)建 socket 的主要位置。其中 sock_create 又調(diào)用了 __sock_create。

//file:net/socket.c 
int __sock_create(struct net *net, int family, int type, int protocol, 
    struct socket **res, int kern) 
{ 
 struct socket *sock; 
 const struct net_proto_family *pf; 
 
 ...... 
 
 //分配 socket 對(duì)象 
 sock = sock_alloc(); 
 
 //獲得每個(gè)協(xié)議族的操作表 
 pf = rcu_dereference(net_families[family]); 
 
 //調(diào)用每個(gè)協(xié)議族的創(chuàng)建函數(shù)， 對(duì)于 AF_INET 對(duì)應(yīng)的是 
 err = pf->create(net, sock, protocol, kern); 
} 

在 __sock_create 里，首先調(diào)用 sock_alloc 來分配一個(gè) struct sock 對(duì)象。接著在獲取協(xié)議族的操作函數(shù)表，并調(diào)用其 create 方法。對(duì)于 AF_INET 協(xié)議族來說，執(zhí)行到的是 inet_create 方法。

//file:net/ipv4/af_inet.c 
tatic int inet_create(struct net *net, struct socket *sock, int protocol, 
         int kern) 
{ 
 struct sock *sk; 
 
 //查找對(duì)應(yīng)的協(xié)議，對(duì)于TCP SOCK_STREAM 就是獲取到了 
 //static struct inet_protosw inetsw_array[] = 
    //{ 
 //    { 
 //     .type =       SOCK_STREAM, 
 //     .protocol =   IPPROTO_TCP, 
 //     .prot =       &tcp_prot, 
 //     .ops =        &inet_stream_ops, 
 //     .no_check =   0, 
 //     .flags =      INET_PROTOSW_PERMANENT | 
 //            INET_PROTOSW_ICSK, 
 //    }, 
 //} 
    list_for_each_entry_rcu(answer, &inetsw[sock->type], list) { 
 
 //將 inet_stream_ops 賦到 socket->ops 上  
 sock->ops = answer->ops; 
 
 //獲得 tcp_prot 
 answer_prot = answer->prot; 
 
 //分配 sock 對(duì)象， 并把 tcp_prot 賦到 sock->sk_prot 上 
 sk = sk_alloc(net, PF_INET, GFP_KERNEL, answer_prot); 
 
 //對(duì) sock 對(duì)象進(jìn)行初始化 
 sock_init_data(sock, sk); 
} 

在 inet_create 中，根據(jù)類型 SOCK_STREAM 查找到對(duì)于 tcp 定義的操作方法實(shí)現(xiàn)集合 inet_stream_ops 和 tcp_prot。并把它們分別設(shè)置到 socket->ops 和 sock->sk_prot 上。

 

我們?cè)偻驴吹搅?sock_init_data。在這個(gè)方法中將 sock 中的 sk_data_ready 函數(shù)指針進(jìn)行了初始化，設(shè)置為默認(rèn) sock_def_readable()。

//file: net/core/sock.c 
void sock_init_data(struct socket *sock, struct sock *sk)  
{ 
    sk->sk_data_ready   =   sock_def_readable; 
    sk->sk_write_space  =   sock_def_write_space; 
    sk->sk_error_report =   sock_def_error_report; 
} 

當(dāng)軟中斷上收到數(shù)據(jù)包時(shí)會(huì)通過調(diào)用 sk_data_ready 函數(shù)指針(實(shí)際被設(shè)置成了 sock_def_readable()) 來喚醒在 sock 上等待的進(jìn)程。這個(gè)咱們后面介紹軟中斷的時(shí)候再說，這里記住這個(gè)就行了。

至此，一個(gè) tcp對(duì)象，確切地說是 AF_INET 協(xié)議族下 SOCK_STREAM對(duì)象就算是創(chuàng)建完成了。這里花費(fèi)了一次 socket 系統(tǒng)調(diào)用的開銷

二、等待接收消息

接著我們來看 recv 函數(shù)依賴的底層實(shí)現(xiàn)。首先通過 strace 命令跟蹤，可以看到 clib 庫函數(shù) recv 會(huì)執(zhí)行到 recvfrom 系統(tǒng)調(diào)用。

進(jìn)入系統(tǒng)調(diào)用后，用戶進(jìn)程就進(jìn)入到了內(nèi)核態(tài)，通過執(zhí)行一系列的內(nèi)核協(xié)議層函數(shù)，然后到 socket 對(duì)象的接收隊(duì)列中查看是否有數(shù)據(jù)，沒有的話就把自己添加到 socket 對(duì)應(yīng)的等待隊(duì)列里。最后讓出CPU，操作系統(tǒng)會(huì)選擇下一個(gè)就緒狀態(tài)的進(jìn)程來執(zhí)行。整個(gè)流程圖如下：

 

看完了整個(gè)流程圖，接下來讓我們根據(jù)源碼來看更詳細(xì)的細(xì)節(jié)。其中我們今天要關(guān)注的重點(diǎn)是 recvfrom 最后是怎么把自己的進(jìn)程給阻塞掉的(假如我們沒有使用 O_NONBLOCK 標(biāo)記)。

//file: net/socket.c 
SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size, 
  unsigned int, flags, struct sockaddr __user *, addr, 
  int __user *, addr_len) 
{ 
 struct socket *sock; 
 
 //根據(jù)用戶傳入的 fd 找到 socket 對(duì)象 
 sock = sockfd_lookup_light(fd, &err, &fput_needed); 
 ...... 
 err = sock_recvmsg(sock, &msg, size, flags); 
 ...... 
} 

sock_recvmsg ==> __sock_recvmsg => __sock_recvmsg_nosec

static inline int __sock_recvmsg_nosec(struct kiocb *iocb, struct socket *sock, 
           struct msghdr *msg, size_t size, int flags) 
{ 
 ...... 
 return sock->ops->recvmsg(iocb, sock, msg, size, flags); 
} 

調(diào)用 socket 對(duì)象 ops 里的 recvmsg， 回憶我們上面的 socket 對(duì)象圖，從圖中可以看到 recvmsg 指向的是 inet_recvmsg 方法。

//file: net/ipv4/af_inet.c 
int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, 
   size_t size, int flags) 
{ 
 ... 
 
 err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT, 
       flags & ~MSG_DONTWAIT, &addr_len); 

這里又遇到一個(gè)函數(shù)指針，這次調(diào)用的是 socket 對(duì)象里的 sk_prot 下面的 recvmsg方法。同上，得出這個(gè) recvmsg 方法對(duì)應(yīng)的是 tcp_recvmsg 方法。

//file: net/ipv4/tcp.c 
int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, 
  size_t len, int nonblock, int flags, int *addr_len) 
{ 
 int copied = 0; 
 ... 
 do { 
  //遍歷接收隊(duì)列接收數(shù)據(jù) 
  skb_queue_walk(&sk->sk_receive_queue, skb) { 
   ... 
  } 
  ... 
 } 
 
 if (copied >= target) { 
  release_sock(sk); 
  lock_sock(sk); 
 } else //沒有收到足夠數(shù)據(jù)，啟用 sk_wait_data 阻塞當(dāng)前進(jìn)程 
  sk_wait_data(sk, &timeo); 
} 

終于看到了我們想要看的東西，skb_queue_walk 是在訪問 sock 對(duì)象下面的接收隊(duì)列了。

 

如果沒有收到數(shù)據(jù)，或者收到不足夠多，則調(diào)用 sk_wait_data 把當(dāng)前進(jìn)程阻塞掉。

//file: net/core/sock.c 
int sk_wait_data(struct sock *sk, long *timeo) 
{ 
 //當(dāng)前進(jìn)程(current)關(guān)聯(lián)到所定義的等待隊(duì)列項(xiàng)上 
 DEFINE_WAIT(wait); 
 
 // 調(diào)用 sk_sleep 獲取 sock 對(duì)象下的 wait 
 // 并準(zhǔn)備掛起，將進(jìn)程狀態(tài)設(shè)置為可打斷 INTERRUPTIBLE 
 prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE); 
 set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags); 
 
 // 通過調(diào)用schedule_timeout讓出CPU，然后進(jìn)行睡眠 
 rc = sk_wait_event(sk, timeo, !skb_queue_empty(&sk->sk_receive_queue)); 
 ... 

我們?cè)賮碓敿?xì)看下 sk_wait_data 是怎么把當(dāng)前進(jìn)程給阻塞掉的。

 

首先在 DEFINE_WAIT 宏下，定義了一個(gè)等待隊(duì)列項(xiàng) wait。在這個(gè)新的等待隊(duì)列項(xiàng)上，注冊(cè)了回調(diào)函數(shù) autoremove_wake_function，并把當(dāng)前進(jìn)程描述符 current 關(guān)聯(lián)到其 .private成員上。

//file: include/linux/wait.h 
#define DEFINE_WAIT(name) DEFINE_WAIT_FUNC(name, autoremove_wake_function) 
 
#define DEFINE_WAIT_FUNC(name, function)    \ 
 wait_queue_t name = {      \ 
  .private = current,    \ 
  .func  = function,    \ 
  .task_list = LIST_HEAD_INIT((name).task_list), \ 
 } 

緊接著在 sk_wait_data 中 調(diào)用 sk_sleep 獲取 sock 對(duì)象下的等待隊(duì)列列表頭 wait_queue_head_t。sk_sleep 源代碼如下：

//file: include/net/sock.h 
static inline wait_queue_head_t *sk_sleep(struct sock *sk) 
{ 
 BUILD_BUG_ON(offsetof(struct socket_wq, wait) != 0); 
 return &rcu_dereference_raw(sk->sk_wq)->wait; 
} 

接著調(diào)用 prepare_to_wait 來把新定義的等待隊(duì)列項(xiàng) wait 插入到 sock 對(duì)象的等待隊(duì)列下。

//file: kernel/wait.c 
void 
prepare_to_wait(wait_queue_head_t *q, wait_queue_t *wait, int state) 
{ 
 unsigned long flags; 
 
 wait->flags &= ~WQ_FLAG_EXCLUSIVE; 
 spin_lock_irqsave(&q->lock, flags); 
 if (list_empty(&wait->task_list)) 
  __add_wait_queue(q, wait); 
 set_current_state(state); 
 spin_unlock_irqrestore(&q->lock, flags); 
} 

這樣后面當(dāng)內(nèi)核收完數(shù)據(jù)產(chǎn)生就緒時(shí)間的時(shí)候，就可以查找 socket 等待隊(duì)列上的等待項(xiàng)，進(jìn)而就可以找到回調(diào)函數(shù)和在等待該 socket 就緒事件的進(jìn)程了。

最后再調(diào)用 sk_wait_event 讓出 CPU，進(jìn)程將進(jìn)入睡眠狀態(tài)，這會(huì)導(dǎo)致一次進(jìn)程上下文的開銷。

接下來的小節(jié)里我們將能看到進(jìn)程是如何被喚醒的了。

三、軟中斷模塊

接著我們?cè)俎D(zhuǎn)換一下視角，來看負(fù)責(zé)接收和處理數(shù)據(jù)包的軟中斷這邊。關(guān)于網(wǎng)絡(luò)包到網(wǎng)卡后是怎么被網(wǎng)卡接收，最后在交由軟中斷處理的，這里就不多贅述了。感興趣的請(qǐng)看之前的文章《圖解Linux網(wǎng)絡(luò)包接收過程》。我們今天直接從 tcp 協(xié)議的接收函數(shù) tcp_v4_rcv 看起。

 

軟中斷(也就是 Linux 里的 ksoftirqd 進(jìn)程)里收到數(shù)據(jù)包以后，發(fā)現(xiàn)是 tcp 的包的話就會(huì)執(zhí)行到 tcp_v4_rcv 函數(shù)。接著走，如果是 ESTABLISH 狀態(tài)下的數(shù)據(jù)包，則最終會(huì)把數(shù)據(jù)拆出來放到對(duì)應(yīng) socket 的接收隊(duì)列中。然后調(diào)用 sk_data_ready 來喚醒用戶進(jìn)程。

我們看更詳細(xì)一點(diǎn)的代碼：

// file: net/ipv4/tcp_ipv4.c 
int tcp_v4_rcv(struct sk_buff *skb) 
{ 
 ...... 
 th = tcp_hdr(skb); //獲取tcp header 
 iph = ip_hdr(skb); //獲取ip header 
 
 //根據(jù)數(shù)據(jù)包 header 中的 ip、端口信息查找到對(duì)應(yīng)的socket 
 sk = __inet_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest); 
 ...... 
 
 //socket 未被用戶鎖定 
 if (!sock_owned_by_user(sk)) { 
  { 
   if (!tcp_prequeue(sk, skb)) 
    ret = tcp_v4_do_rcv(sk, skb); 
  } 
 } 
} 

在 tcp_v4_rcv 中首先根據(jù)收到的網(wǎng)絡(luò)包的 header 里的 source 和 dest 信息來在本機(jī)上查詢對(duì)應(yīng)的 socket。找到以后，我們直接進(jìn)入接收的主體函數(shù) tcp_v4_do_rcv 來看。

//file: net/ipv4/tcp_ipv4.c 
int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb) 
{ 
 if (sk->sk_state == TCP_ESTABLISHED) {  
 
  //執(zhí)行連接狀態(tài)下的數(shù)據(jù)處理 
  if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len)) { 
   rsk = sk; 
   goto reset; 
  } 
  return 0; 
 } 
 
 //其它非 ESTABLISH 狀態(tài)的數(shù)據(jù)包處理 
 ...... 
} 

我們假設(shè)處理的是 ESTABLISH 狀態(tài)下的包，這樣就又進(jìn)入 tcp_rcv_established 函數(shù)中進(jìn)行處理。

//file: net/ipv4/tcp_input.c 
int tcp_rcv_established(struct sock *sk, struct sk_buff *skb, 
   const struct tcphdr *th, unsigned int len) 
{ 
 ...... 
 
 //接收數(shù)據(jù)到隊(duì)列中 
 eaten = tcp_queue_rcv(sk, skb, tcp_header_len, 
            &fragstolen); 
 
 //數(shù)據(jù) ready，喚醒 socket 上阻塞掉的進(jìn)程 
 sk->sk_data_ready(sk, 0); 

在 tcp_rcv_established 中通過調(diào)用 tcp_queue_rcv 函數(shù)中完成了將接收數(shù)據(jù)放到 socket 的接收隊(duì)列上。

 

如下源碼所示

//file: net/ipv4/tcp_input.c 
static int __must_check tcp_queue_rcv(struct sock *sk, struct sk_buff *skb, int hdrlen, 
    bool *fragstolen) 
{ 
 //把接收到的數(shù)據(jù)放到 socket 的接收隊(duì)列的尾部 
 if (!eaten) { 
  __skb_queue_tail(&sk->sk_receive_queue, skb); 
  skb_set_owner_r(skb, sk); 
 } 
 return eaten; 
} 

調(diào)用 tcp_queue_rcv 接收完成之后，接著再調(diào)用 sk_data_ready 來喚醒在socket上等待的用戶進(jìn)程。 這又是一個(gè)函數(shù)指針。回想上面我們?cè)?創(chuàng)建 socket 流程里執(zhí)行到的 sock_init_data 函數(shù)，在這個(gè)函數(shù)里已經(jīng)把 sk_data_ready 設(shè)置成 sock_def_readable 函數(shù)了(可以ctrl + f 搜索前文)。它是默認(rèn)的數(shù)據(jù)就緒處理函數(shù)。

//file: net/core/sock.c 
static void sock_def_readable(struct sock *sk, int len) 
{ 
 struct socket_wq *wq; 
 
 rcu_read_lock(); 
 wq = rcu_dereference(sk->sk_wq); 
 
 //有進(jìn)程在此 socket 的等待隊(duì)列 
 if (wq_has_sleeper(wq)) 
  //喚醒等待隊(duì)列上的進(jìn)程 
  wake_up_interruptible_sync_poll(&wq->wait, POLLIN | POLLPRI | 
      POLLRDNORM | POLLRDBAND); 
 sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN); 
 rcu_read_unlock(); 
} 

在 sock_def_readable 中再一次訪問到了 sock->sk_wq 下的wait?；貞浵挛覀兦懊嬲{(diào)用 recvfrom 執(zhí)行的最后，通過 DEFINE_WAIT(wait) 將當(dāng)前進(jìn)程關(guān)聯(lián)的等待隊(duì)列添加到 sock->sk_wq 下的 wait 里了。

那接下來就是調(diào)用 wake_up_interruptible_sync_poll 來喚醒在 socket 上因?yàn)榈却龜?shù)據(jù)而被阻塞掉的進(jìn)程了。

//file: include/linux/wait.h 
#define wake_up_interruptible_sync_poll(x, m)    \ 
 __wake_up_sync_key((x), TASK_INTERRUPTIBLE, 1, (void *) (m)) 

//file: kernel/sched/core.c 
void __wake_up_sync_key(wait_queue_head_t *q, unsigned int mode, 
   int nr_exclusive, void *key) 
{ 
 unsigned long flags; 
 int wake_flags = WF_SYNC; 
 
 if (unlikely(!q)) 
  return; 
 
 if (unlikely(!nr_exclusive)) 
  wake_flags = 0; 
 
 spin_lock_irqsave(&q->lock, flags); 
 __wake_up_common(q, mode, nr_exclusive, wake_flags, key); 
 spin_unlock_irqrestore(&q->lock, flags); 
} 

__wake_up_common 實(shí)現(xiàn)喚醒。這里注意下， 該函數(shù)調(diào)用是參數(shù) nr_exclusive 傳入的是 1，這里指的是即使是有多個(gè)進(jìn)程都阻塞在同一個(gè) socket 上，也只喚醒 1 個(gè)進(jìn)程。其作用是為了避免驚群。

//file: kernel/sched/core.c 
static void __wake_up_common(wait_queue_head_t *q, unsigned int mode, 
   int nr_exclusive, int wake_flags, void *key) 
{ 
 wait_queue_t *curr, *next; 
 
 list_for_each_entry_safe(curr, next, &q->task_list, task_list) { 
  unsigned flags = curr->flags; 
 
  if (curr->func(curr, mode, wake_flags, key) && 
    (flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive) 
   break; 
 } 
} 

在 __wake_up_common 中找出一個(gè)等待隊(duì)列項(xiàng) curr，然后調(diào)用其 curr->func?；貞浳覀兦懊嬖?recv 函數(shù)執(zhí)行的時(shí)候，使用 DEFINE_WAIT() 定義等待隊(duì)列項(xiàng)的細(xì)節(jié)，內(nèi)核把 curr->func 設(shè)置成了 autoremove_wake_function。

//file: include/linux/wait.h 
#define DEFINE_WAIT(name) DEFINE_WAIT_FUNC(name, autoremove_wake_function) 
 
#define DEFINE_WAIT_FUNC(name, function)    \ 
 wait_queue_t name = {      \ 
  .private = current,    \ 
  .func  = function,    \ 
  .task_list = LIST_HEAD_INIT((name).task_list), \ 
 } 

在 autoremove_wake_function 中，調(diào)用了 default_wake_function。

//file: kernel/sched/core.c 
int default_wake_function(wait_queue_t *curr, unsigned mode, int wake_flags, 
     void *key) 
{ 
 return try_to_wake_up(curr->private, mode, wake_flags); 
} 

調(diào)用 try_to_wake_up 時(shí)傳入的 task_struct 是 curr->private。這個(gè)就是當(dāng)時(shí)因?yàn)榈却蛔枞倪M(jìn)程項(xiàng)。當(dāng)這個(gè)函數(shù)執(zhí)行完的時(shí)候，在 socket 上等待而被阻塞的進(jìn)程就被推入到可運(yùn)行隊(duì)列里了，這又將是一次進(jìn)程上下文切換的開銷。

小結(jié)

好了，我們把上面的流程總結(jié)一下。內(nèi)核在通知網(wǎng)絡(luò)包的運(yùn)行環(huán)境分兩部分：

第一部分是我們自己代碼所在的進(jìn)程，我們調(diào)用的 socket() 函數(shù)會(huì)進(jìn)入內(nèi)核態(tài)創(chuàng)建必要內(nèi)核對(duì)象。recv() 函數(shù)在進(jìn)入內(nèi)核態(tài)以后負(fù)責(zé)查看接收隊(duì)列，以及在沒有數(shù)據(jù)可處理的時(shí)候把當(dāng)前進(jìn)程阻塞掉，讓出 CPU。

第二部分是硬中斷、軟中斷上下文(系統(tǒng)進(jìn)程 ksoftirqd)。在這些組件中，將包處理完后會(huì)放到 socket 的接收隊(duì)列中。然后再根據(jù) socket 內(nèi)核對(duì)象找到其等待隊(duì)列中正在因?yàn)榈却蛔枞舻倪M(jìn)程，然后把它喚醒。

 

每次一個(gè)進(jìn)程專門為了等一個(gè) socket 上的數(shù)據(jù)就得被從 CPU 上拿下來。然后再換上另一個(gè)進(jìn)程。等到數(shù)據(jù) ready 了，睡眠的進(jìn)程又會(huì)被喚醒?？偣矁纱芜M(jìn)程上下文切換開銷，根據(jù)之前的測試來看，每一次切換大約是 3-5 us(微秒)左右。如果是網(wǎng)絡(luò) IO 密集型的應(yīng)用的話，CPU 就不停地做進(jìn)程切換這種無用功。

在服務(wù)端角色上，這種模式完全沒辦法使用。因?yàn)檫@種簡單模型里的 socket 和進(jìn)程是一對(duì)一的。我們現(xiàn)在要在單臺(tái)機(jī)器上承載成千上萬，甚至十幾、上百萬的用戶連接請(qǐng)求。如果用上面的方式，那就得為每個(gè)用戶請(qǐng)求都創(chuàng)建一個(gè)進(jìn)程。相信你在無論多原始的服務(wù)器網(wǎng)絡(luò)編程里，都沒見過有人這么干吧。

如果讓我給它起一個(gè)名字的話，它就叫單路不復(fù)用(飛哥自創(chuàng)名詞)。那么有沒有更高效的網(wǎng)絡(luò) IO 模型呢?當(dāng)然有，那就是你所熟知的 select、poll 和 epoll了。下次飛哥再開始拆解 epoll 的實(shí)現(xiàn)源碼，敬請(qǐng)期待!

這種模式在客戶端角色上，現(xiàn)在還存在使用的情形。因?yàn)槟愕倪M(jìn)程可能確實(shí)得等 Mysql 的數(shù)據(jù)返回成功之后，才能渲染頁面返回給用戶，否則啥也干不了。

注意一下，我說的是角色，不是具體的機(jī)器。例如對(duì)于你的 php/java/golang 接口機(jī)，你接收用戶請(qǐng)求的時(shí)候，你是服務(wù)端角色。但當(dāng)你再請(qǐng)求 redis 的時(shí)候，就變?yōu)榭蛻舳私巧恕?/p>

 

不過現(xiàn)在有一些封裝的很好的網(wǎng)絡(luò)框架例如 Sogou Workflow，Golang 的 net 包等在網(wǎng)絡(luò)客戶端角色上也早已摒棄了這種低效的模式!