2. 程式人生 > >從 Linux 原始碼看 socket 的阻塞和非阻塞

從 Linux 原始碼看 socket 的阻塞和非阻塞

阿新 • • 發佈：2018-12-11

從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,如下圖綠線所示:
inet_family


我們跟蹤原始碼呼叫

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)的過載。如下圖所示:
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_proto

從上述程式碼，我們可以清楚的發現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

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 = 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);
		} 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網路協議棧程式碼的人。

原文地址

https://my.oschina.net/alchemystar/blog/1791017

相關推薦

從 Linux 原始碼看 socket 的阻塞和非阻塞

從linux原始碼看socket的阻塞和非阻塞 筆者一直覺得如果能知道從應用到框架再到作業系統的每一處程式碼，是一件Exciting的事情。 大部分高效能網路框架採用的是非阻塞模式。筆者這次就從linux原始碼的角度來闡述socket阻塞(block)和非阻塞(non_block)的區別。 本文

從linux原始碼看socket(tcp)的timeout

# 從linux原始碼看socket(tcp)的timeout ## 前言 網路程式設計中超時時間是一個重要但又容易被忽略的問題,對其的設定需要仔細斟酌。在經歷了數次物理機宕機之後,筆者詳細的考察了在網路程式設計(tcp)中的各種超時設定，於是就有了本篇博文。本文大部分討論的是socket設定為block的情

從Linux原始碼看Socket(TCP)Client端的Connect

# 從Linux原始碼看Socket(TCP)Client端的Connect ## 前言 筆者一直覺得如果能知道從應用到框架再到作業系統的每一處程式碼，是一件Exciting的事情。 今天筆者就來從Linux原始碼的角度看下Client端的Socket在進行Connect的時候到底做了哪些事情。由於篇幅原因

從Linux原始碼看Socket(TCP)的bind

# 從Linux原始碼看Socket(TCP)的bind ## 前言 筆者一直覺得如果能知道從應用到框架再到作業系統的每一處程式碼，是一件Exciting的事情。 今天筆者就來從Linux原始碼的角度看下Server端的Socket在進行bind的時候到底做了哪些事情(基於Linux 3.10核心)。 ##

從Linux原始碼看Socket(TCP)的listen及連線佇列

# 從Linux原始碼看Socket(TCP)的listen及連線佇列 ## 前言 筆者一直覺得如果能知道從應用到框架再到作業系統的每一處程式碼，是一件Exciting的事情。 今天筆者就來從Linux原始碼的角度看下Server端的Socket在進行listen的時候到底做了哪些事情(基於Linux 3.1

從Linux原始碼看Socket(TCP)的accept

# 從Linux原始碼看Socket(TCP)的accept ## 前言 筆者一直覺得如果能知道從應用到框架再到作業系統的每一處程式碼，是一件Exciting的事情。 今天筆者就從Linux原始碼的角度看下Server端的Socket在進行Accept的時候到底做了哪些事情(基於Linux 3.10核心)。

C/C++網路程式設計在windows和linux中將socket設定為阻塞和非阻塞

C/C++網路程式設計在windows和linux中將socket設定為阻塞和非阻塞              在 socket程式設計中，對於socket的讀寫預設都是阻塞的，但有的情況我們需要將其設定為非阻塞，比如做多

socket阻塞和非阻塞的區別【轉】

轉載地址：http://kalogen.iteye.com/blog/670841簡單點說: 阻塞就是幹不完不準回來，   非組賽就是你先幹，我現看看有其他事沒有，完了告訴我一聲 我們拿最常用的send

深入淺出:Linux裝置驅動中的阻塞和非阻塞I/O

今天寫的是Linux裝置驅動中的阻塞和非阻塞I/0，何謂阻塞與非阻塞I/O？簡單來說就是對I/O操作的兩種不同的方式，驅動程式可以靈活的支援使用者空間對裝置的這兩種訪問方式。 一、基本概念： 阻塞操作 ： 是指在執行裝置操作時，若不能獲得資源，則掛起程序直到

網路程式設計Socket的阻塞和非阻塞IO

網路應用程式一個很重要的工作是傳輸資料。傳輸資料的過程不一樣取決於使用哪種“交通工具“，但是傳輸的方式都是一樣的：都是以位元組碼傳輸。JAVA開發網路程式傳輸資料的過程和方式是被抽象了的，我們不需要關注底層介面，只需要使用Java API 或其他網路框架就能達到資料傳輸的目

linux裝置驅動中的阻塞和非阻塞IO

一、等待佇列 1、定義等待佇列頭 wait_queue_head_t my_queue; 2、初始化等待佇列頭 init_waitqueue_head(&my_queue); 3、定義等待佇列 DECLARE_WAITQUEUE(name,tsk); 4、新增/移除

linux中阻塞和非阻塞的區別

所謂阻塞方式block，顧名思義，就是程序或是執行緒執行到這些函式時必須等待某個事件的發生，如果事件沒有發生，程序或執行緒就被阻塞，函式不能立即返回）。 所謂非阻塞方式non-block，就是程序或執行緒執行此函式時不必非要等待事件的發生，一旦執行肯定返回，以返回值的不同來

socket程式設計中send recv阻塞和非阻塞詳解

int send( SOCKET s, const char FAR *buf, int len, int flags ); 不論是客戶還是伺服器應用程式都用send函式來向TCP連線的另一端傳送資料。客戶程式一般用send函式向伺服器傳送請求，而伺服器則通常用send函

socket同步和非同步、阻塞和非阻塞、I/O模型

在進行網路程式設計時，常常見到同步(Sync)/非同步(Async)，阻塞(Block)/非阻塞(Unblock)四種呼叫方式同步/非同步主要針對C端: 同步：c端發出一個功能呼叫時，在沒有得到結果之前，c端死等結果例如：普通B/S模式（同步）：提交請求->等待伺服器處理->處理完畢返回 這個期間

從linux原始碼看epoll

# 從linux原始碼看epoll ## 前言 在linux的高效能網路程式設計中，繞不開的就是epoll。和select、poll等系統呼叫相比,epoll在需要監視大量檔案描述符並且其中只有少數活躍的時候，表現出無可比擬的優勢。epoll能讓核心記住所關注的描述符，並在對應的描述符事件就緒的時候,在epo

從Linux原始碼看TIME_WAIT狀態的持續時間

# 從Linux原始碼看TIME_WAIT狀態的持續時間 ## 前言 筆者一直以為在Linux下TIME\_WAIT狀態的Socket持續狀態是60s左右。線上實際卻存在TIME\_WAIT超過100s的Socket。由於這牽涉到最近出現的一個複雜Bug的分析。所以，筆者就去Linux原始碼裡面，一探究竟。

6、阻塞和非阻塞

失敗 解決 實驗 file iostream pac \n std shell 　　讀常規文件是不會阻塞的，不管讀多少字節，read一定會在有限的時間內返回。但是從終端設備或網絡讀則不一定，如果從終端輸入的數據沒有換行符，調用read讀終端設備就會阻塞，如果網絡上沒有接收到

同步異步以及阻塞和非阻塞的區別

結束 線程 同步異步 成功 -s 區別 狀態 得到 概念 一、同步與異步的區別： 同步：一個服務的完成需要依賴其他服務時，只有等待被依賴的服務完成後，才算完成，這是一種可靠的服務序列。要麽成功都成功，失敗都失敗，服務的狀態可以保持一致。 異步：一個服務的完成需要依賴其他

recv send 阻塞和非阻塞

int send( SOCKET s, const char FAR *buf, int len, int flags ); 不論是客戶還是伺服器應用程式都用send函式來向TCP連線的另一端傳送資料。客戶程式一般用send函式向伺服器傳送請求，而伺服器則通常用send函式來向客戶程式傳送應答。

什麼是同步和非同步，什麼是阻塞和非阻塞

同步和非同步是針對應用程式和核心的互動而言的，同步指的是使用者程序觸發IO操作並等待或者輪詢的去檢視IO操作是否就緒，而非同步是指使用者程序觸發IO操作以後便開始做自己的事情，而當IO操作已經完成的時候會得到IO完成的通知。 以銀行取款為例： 同步：自己親自出馬持銀行卡到銀行取錢（使用同