從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,如下圖綠線所示:
我們跟蹤原始碼呼叫
socket(AF_INET, SOCK_STREAM, 0)
|->sys_socket 進入系統呼叫
|->sock_create
|->__sock_create
進一步分析__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_create(struct net *net, struct socket *sock, int protocol){
Sock* sock;
......
// 此處是尋找對應協議處理器的過程
lookup_protocol:
// 迭代尋找protocol==answer->protocol的情況
list_for_each_rcu(p, &inetsw[sock->type]) answer = list_entry(p, struct inet_protosw, list);
/* Check the non-wild match. */
if (protocol == answer->protocol) {
if (protocol != IPPROTO_IP)
break;
}
......
// 這邊answer指的是SOCK_STREAM
sock->ops = answer->ops;
answer_no_check = answer->no_check;
// 這邊sk->prot就是answer_prot=>tcp_prot
sk = sk_alloc(net, PF_INET, GFP_KERNEL, answer_prot);
sock_init_data(sock, sk);
......
}
上面的程式碼就是在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個引數為正,否則為0
err = 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 = nonblock ? 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);
} else
sk_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程式碼-函式為:
// 將程式狀態設定為可打斷INTERRUPTIBLE
prepare_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
next_rx_action
|-process_backlog
......
|->packet_type->func 在這裡我們考慮ip_rcv
|->ipprot->handler 在這裡ipprot過載為tcp_protocol
(handler 即為tcp_v4_rcv)
緊接著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_timeout
setup_timer(&timer, process_timeout, (unsigned long)current);
__mod_timer(&timer, expire);
// 這邊讓出CPU
schedule();
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網路協議棧程式碼的人。
公眾號
關注筆者公眾號，獲取更多幹貨文章:
