從linux源碼看socket的阻塞和非阻塞


筆者一直以爲若是能知道從應用到框架再到操做系統的每一處代碼,是一件Exciting的事情。
大部分高性能網絡框架採用的是非阻塞模式。筆者此次就從linux源碼的角度來闡述socket阻塞(block)和非阻塞(non_block)的區別。 本文源碼均來自採用Linux-2.6.24內核版本。linux

一個TCP非阻塞client端簡單的例子

若是咱們要產生一個非阻塞的socket,在C語言中以下代碼所示:網絡

// 建立socketint sock_fd = socket(AF_INET, SOCK_STREAM, 0);
...
// 更改socket爲nonblockfcntl(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,以下圖綠線所示:
inet_family
咱們跟蹤源碼調用框架

socket(AF_INET, SOCK_STREAM, 0)
	|->sys_socket 進入系統調用
		|->sock_create
			|->__sock_create

進一步分析__sock_create的代碼判斷:socket

const struct net_proto_family *pf;// RCU(Read-Copy Update)是linux的一種內核同步方法,在此不闡述// family=INETpf = rcu_dereference(net_families[family]);
err = pf->create(net, sock, protocol);

因爲family是AF_INET協議,注意在操做系統裏面定義了PF_INET等於AF_INET,
內核經過函數指針實現了對pf(net_proto_family)的重載。以下圖所示:
net_proto_familytcp

則經過源碼可知,因爲是AF_INET(PF_INET),因此net_families[PF_INET].create=inet_create(之後咱們都用PF_INET表示),即
pf->create = inet_create;
進一步追溯調用:ide

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_proto性能

從上述代碼,咱們能夠清楚的發現sock->ops=&inet_stream_ops;spa

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

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,關係以下圖所示:
fcntl_recvmsg.png

最終的調用邏輯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將當前進程等待。
以下流程圖所示:

tcp_recv

阻塞函數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宏來完成進程間的切換。
以下圖所示:
task_schedule

阻塞後何時恢復運行呢

狀況1:有對應的網絡數據到來

首先咱們看下網絡分組到來的內核路徑,網卡發起中斷後調用netif_rx將事件掛入CPU的等待隊列,並喚起軟中斷(soft_irq),再經過linux的軟中斷機制調用net_rx_action,以下圖所示:

low_recv
注:上圖來自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調度以進行下一步的動做,以下圖所示。

wake_up

狀況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網絡協議棧代碼的人。

相關文章
相關標籤/搜索