从 Linux 源码看 Socket 的阻塞和非阻塞
轉載自?從 Linux 源碼看 Socket 的阻塞和非阻塞
筆者一直覺得如果能知道從應用到框架再到操作系統的每一處代碼，是一件Exciting的事情。
大部分高性能網絡框架采用的是非阻塞模式。筆者這次就從linux源碼的角度來闡述socket阻塞(block)和非阻塞(non_block)的區別。 本文源碼均來自采用Linux-2.6.24內核版本。
一個TCP非阻塞client端簡單的例子
如果我們要產生一個非阻塞的socket,在C語言中如下代碼所示:
// 創建socket int sock_fd = socket(AF_INET, SOCK_STREAM, 0); ... // 更改socket為nonblock fcntl(sock_fd, F_SETFL, fdflags | O_NONBLOCK); // connect .... while(1) { int recvlen = recv(sock_fd, recvbuf, RECV_BUF_SIZE) ; ...... } ...由于網絡協議非常復雜，內核里面用到了大量的面向對象的技巧，所以我們從創建連接開始，一步一步追述到最后代碼的調用點。
socket的創建
很明顯，內核的第一步應該是通過AF_INET、SOCK_STREAM以及最后一個參數0定位到需要創建一個TCP的socket,如下圖綠線所示:
我們跟蹤源碼調用
進一步分析__sock_create的代碼判斷:
const struct net_proto_family *pf; // RCU(Read-Copy Update)是linux的一種內核同步方法，在此不闡述 // family=INET pf = rcu_dereference(net_families[family]); err = pf->create(net, sock, protocol);由于family是AF_INET協議，注意在操作系統里面定義了PF_INET等于AF_INET, 內核通過函數指針實現了對pf(net_proto_family)的重載。如下圖所示:
則通過源碼可知，由于是AF_INET(PF_INET),所以net_families[PF_INET].create=inet_create(以后我們都用PF_INET表示)，即
pf->create = inet_create; 進一步追溯調用:
上面的代碼就是在INET中尋找SOCK_STREAM的過程了 我們再看一下inetsw[SOCK_STREAM]的具體配置:
static struct inet_protosw inetsw_array[] = {{.type = SOCK_STREAM,.protocol = IPPROTO_TCP,.prot = &tcp_prot,.ops = &inet_stream_ops,.capability = -1,.no_check = 0,.flags = INET_PROTOSW_PERMANENT |INET_PROTOSW_ICSK,},...... }這邊也用了重載，AF_INET有TCP、UDP以及Raw三種:
從上述代碼，我們可以清楚的發現sock->ops=&inet_stream_ops;
const struct proto_ops inet_stream_ops = {.family = PF_INET,.owner = THIS_MODULE,.......sendmsg = tcp_sendmsg,.recvmsg = sock_common_recvmsg,...... }即sock->ops->recvmsg = sock_common_recvmsg;
同時sock->sk->sk_prot = tcp_prot;
我們再看下tcp_prot中的各個函數重載的定義:
struct proto tcp_prot = {.name = "TCP",.close = tcp_close,.connect = tcp_v4_connect,.disconnect = tcp_disconnect,.accept = inet_csk_accept,......// 我們重點考察tcp的讀.recvmsg = tcp_recvmsg,...... }fcntl控制socket的阻塞\非阻塞狀態
我們用fcntl修改socket的阻塞\非阻塞狀態。 事實上: fcntl的作用就是將O_NONBLOCK標志位存儲在sock_fd對應的filp結構的f_lags里,如下圖所示。
fcntl(sock_fd, F_SETFL, fdflags | O_NONBLOCK);|->setfl追蹤setfl代碼:
static int setfl(int fd, struct file * filp, unsigned long arg) {......filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);...... }上圖中，由sock_fd在task_struct(進程結構體)->files_struct->fd_array中找到對應的socket的file描述符，再修改file->flags
在調用socket.recv的時候
我們跟蹤源碼調用:
socket.recv|->sys_recv|->sys_recvfrom|->sock_recvmsg|->__sock_recvmsg|->sock->ops->recvmsg由上文可知: sock->ops->recvmsg = sock_common_recvmsg;
sock
值得注意的是,在sock_recmsg中,有對標識O_NONBLOCK的處理
if (sock->file->f_flags & O_NONBLOCK)flags |= MSG_DONTWAIT;上述代碼中sock關聯的file中獲取其f_flags,如果flags有O_NONBLOCK標識，那么就設置msg_flags為MSG_DONTWAIT(不等待)。
fcntl與socket就是通過其共同操作File結構關聯起來的。
繼續跟蹤調用
sock_common_recvmsg
int sock_common_recvmsg(struct kiocb *iocb, struct socket *sock,struct msghdr *msg, size_t size, int flags) {......// 如果flags的MSG_DONTWAIT標識置位，則傳給recvmsg的第5個參數為正,否則為0err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,flags & ~MSG_DONTWAIT, &addr_len);..... }由上文可知: sk->sk_prot->recvmsg 其中sk_prot=tcp_prot,即最終調用的是tcp_prot->tcp_recvmsg,
上面的代碼可以看出，如果fcntl(O_NONBLOCK)=>MSG_DONTWAIT置位=>(flags & MSG_DONTWAIT)>0, 再結合tcp_recvmsg的函數簽名,即如果設置了O_NONBLOCK的話，設置給tcp_recvmsg的nonblock參數>0,關系如下圖所示:
最終的調用邏輯tcp_recvmsg
首先我們看下tcp_recvmsg的函數簽名:
int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,size_t len, int nonblock, int flags, int *addr_len)顯然我們關注焦點在(int nonblock這個參數上):
int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,size_t len, int nonblock, int flags, int *addr_len){...... // copied是指向用戶空間拷貝了多少字節，即讀了多少int copied;// target指的是期望多少字節int target;// 等效為timo = noblock ? 0 : sk->sk_rcvtimeo;timeo = sock_rcvtimeo(sk, nonblock);...... // 如果設置了MSG_WAITALL標識target=需要讀的長度// 如果未設置，則為最低低水位值target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);......do{// 表明讀到數據if (copied) {// 注意，這邊只要!timeo，即nonblock設置了就會跳出循環if (sk->sk_err ||sk->sk_state == TCP_CLOSE ||(sk->sk_shutdown & RCV_SHUTDOWN) ||!timeo ||signal_pending(current) ||(flags & MSG_PEEK))break;}else{// 到這里，表明沒有讀到任何數據// 且nonblock設置了導致timeo=0，則返回-EAGAIN,符合我們的預期if (!timeo) {copied = -EAGAIN;break;}// 這邊如果堵到了期望的數據，繼續，否則當前進程阻塞在sk_wait_data上if (copied >= target) {/* Do not sleep, just process backlog. */release_sock(sk);lock_sock(sk);} elsesk_wait_data(sk, &timeo);} while (len > 0); ......return copied }上面的邏輯歸結起來就是：
(1)在設置了nonblock的時候，如果copied>0,則返回讀了多少字節,如果copied=0，則返回-EAGAIN,提示應用重復調用。
(2)如果沒有設置nonblock，如果讀取的數據>=期望，則返回讀取了多少字節。如果沒有則用sk_wait_data將當前進程等待。
如下流程圖所示:
阻塞函數sk_wait_data
sk_wait_data代碼-函數為:
// 將進程狀態設置為可打斷INTERRUPTIBLEprepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);// 通過調用schedule_timeout讓出CPU，然后進行睡眠rc = sk_wait_event(sk, timeo, !skb_queue_empty(&sk->sk_receive_queue));// 到這里的時候，有網絡事件或超時事件喚醒了此進程，繼續運行clear_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);finish_wait(sk->sk_sleep, &wait);該函數調用schedule_timeout進入睡眠，其進一步調用了schedule函數，首先從運行隊列刪除，其次加入到等待隊列，最后調用和體系結構相關的switch_to宏來完成進程間的切換。
如下圖所示:
阻塞后什么時候恢復運行呢
情況1:有對應的網絡數據到來
首先我們看下網絡分組到來的內核路徑，網卡發起中斷后調用netif_rx將事件掛入CPU的等待隊列，并喚起軟中斷(soft_irq)，再通過linux的軟中斷機制調用net_rx_action，如下圖所示:
注:上圖來自PLKA(<<深入Linux內核架構>>)
緊接著跟蹤next_rx_action
緊接著tcp_v4_rcv:
tcp_input.c tcp_v4_rcv|-tcp_v4_do_rcv|-tcp_rcv_state_process|-tcp_data_queue|-sk->sk_data_ready=sock_def_readable|-wake_up_interruptible|-__wake_up|-__wake_up_common在這里__wake_up_common將停在當前wait_queue_head_t中的進程喚醒，即狀態改為task_running，等待CFS調度以進行下一步的動作,如下圖所示。
情況2:設定的超時時間到來
在前面調用sk_wait_event中調用了schedule_timeout
fastcall signed long __sched schedule_timeout(signed long timeout) {......// 設定超時的回掉函數為process_timeoutsetup_timer(&timer, process_timeout, (unsigned long)current);__mod_timer(&timer, expire);// 這邊讓出CPUschedule();del_singleshot_timer_sync(&timer);timeout = expire - jiffies;out:// 返回經過了多長事件return timeout < 0 ? 0 : timeout; }process_timeout函數即是將此進程重新喚醒
static void process_timeout(unsigned long __data) {wake_up_process((struct task_struct *)__data); }總結
linux內核源代碼博大精深，閱讀其代碼很費周折。希望筆者這篇文章能幫助到閱讀linux網絡協議棧代碼的人。
總結
以上是生活随笔為你收集整理的从 Linux 源码看 Socket 的阻塞和非阻塞的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 被降权的微信怎么恢复（被降权的微信怎么恢
- 下一篇： 门禁微波感应器接线方法？