性能網絡編程總結

時間  2020-08-02
標籤 性能 網絡 編程 總結 欄目 系統性能 简体版
原文   原文鏈接
 

高性能網絡編程總結及《TCP/IP Sockets編程(C語言實現) (第2版)》 代碼下載(連接以及文件打包)

2016-03-01 17:04  2322人閱讀  評論(1)  收藏  舉報
  分類：

目錄(?)[+]html

http://blog.csdn.NET/column/details/high-perf-network.htmlnode

http://blog.csdn.net/russell_tao/article/details/9111769
react

高性能網絡編程（一）----accept創建鏈接
linux

最近在部門內作了個高性能網絡編程的培訓，近日整理了下PPT，欲寫成一系列文章從應用角度談談它。
編寫服務器時，許多程序員習慣於使用高層次的組件、中間件（例如OO（面向對象）層層封裝過的開源組件），相比於服務器的運行效率而言，他們更關注程序開發的效率，追求更快的完成項目功能點、但願應用代碼徹底不關心通信細節。他們更喜歡在OO世界裏，去實現某個接口、實現這個組件預約義的各類模式、設置組件參數來達到目的。學習複雜的通信框架、底層細節，在習慣於使用OO語言的程序員眼裏是絕對事倍功半的。以上作法無可厚非，但有必定的侷限性，本文講述的網絡編程頭前冠以「高性能」，它是指程序員設計編寫的服務器須要處理很大的吞吐量，這與簡單網絡應用就有了質的不一樣。由於：一、高吞吐量下，容易觸發到一些設計上的邊界條件；二、偶然性的小几率事件，會在高吞吐量下變成必然性事件。三、IO是慢速的，高吞吐量一般意味着高併發，如同一時刻存在數以萬計、十萬計、百萬計的TCP活動鏈接。因此，作高性能網絡編程不能僅僅知足於學會開源組件、中間件是如何幫我實現指望功能的，對於企業級產品來講，須要瞭解更多的知識。

掌握高性能網絡編程，涉及到對網絡、操做系統協議棧、進程與線程、常見的網絡組件等知識點，須要有豐富的項目開發經驗，可以權衡服務器運行效率與項目開發效率。如下圖來談談我我的對高性能網絡編程的理解。

上面這張圖中，由上至下有如下特色：
•關注點，逐漸由特定業務向通用技術轉移
•使用場景上，由專業領域向通用領域轉移
•靈活性上要求愈來愈高
•性能要求愈來愈高
•對細節、原理的掌握，要求愈來愈高
•對各類異常狀況的處理，要求愈來愈高
•穩定性愈來愈高，bug率愈來愈少
在作應用層的網絡編程時，若服務器吞吐量大，則應該適度瞭解以上各層的關注點。

如上圖紅色文字所示，我認爲編寫高性能服務器的關注點有3個：
一、若是基於通用組件編程，關注點可能是在組件如何封裝套接字編程細節。爲了使應用程序不感知套接字層，這些組件每每是經過各類回調機制來嚮應用層代碼提供網絡服務，一般，出於爲應用層提供更高的開發效率，組件都大量使用了線程（Nginx等是個例外），固然，使用了線程後每每能夠下降代碼複雜度。但多線程引入的併發解決機制仍是須要重點關注的，特別是鎖的使用。另外，使用多線程意味着把應用層的代碼複雜度扔給了操做系統，大吞吐量時，須要關注多線程給操做系統內核帶來的性能損耗。
基於通用組件編程，爲了程序的高性能運行，須要清楚的瞭解組件的如下特性：怎麼使用IO多路複用或者異步IO的？怎麼實現併發性的？ 怎麼組織線程模型的？ 怎麼處理高吞吐量引起的異常狀況的？

二、通用組件只是在封裝套接字，操做系統是經過提供套接字來爲進程提供網絡通信能力的。因此，不瞭解套接字編程，每每對組件的性能就沒有原理上的認識。學習套接字層的編程是有必要的，或許不多會本身從頭去寫，但操做系統的API提供方式經久不變，一經學會，受用終身，同時在項目的架構設計時，選用何種網絡組件就很是準確了。
學習套接字編程，關注點主要在：套接字的編程方法有哪些？阻塞套接字的各方法是如何阻塞住當前代碼段的？非阻塞套接字上的方法如何不阻塞當前代碼段的？IO多路複用機制是怎樣與套接字結合的？異步IO是如何實現的？網絡協議的各類異常狀況、操做系統的各類異常狀況是怎麼經過套接字傳遞給應用性程序的？

三、網絡的複雜性會影響到服務器的吞吐量，並且，高吞吐量場景下，多種臨界條件會致使應用程序的不正常，特別是組件中有bug或考慮不周或沒有配置正確時。瞭解網絡分組能夠定位出這些問題，能夠正確的配置系統、組件，能夠正確的理解系統的瓶頸。
這裏的關注點主要在：TCP、UDP、IP協議的特色？linux等操做系統如何處理這些協議的？使用tcpdump等抓包工具分析各網絡分組。

通常掌握以上3點，就能夠揮灑自如的實現高性能網絡服務器了。

下面具體談談如何作到高性能網絡編程。
衆所周知，IO是計算機上最慢的部分，先不看磁盤IO，針對網絡編程，天然是針對網絡IO。網絡協議對網絡IO影響很大，當下， TCP/IP協議是毫無疑問的主流協議，本文就主要以TCP協議爲例來講明網絡IO。
網絡IO中應用服務器每每聚焦於如下幾個由網絡IO組成的功能中：A）與客戶端創建起TCP鏈接。B）讀取客戶端的請求流。C）向客戶端發送響應流。D）關閉TCP鏈接。E）向其餘服務器發起TCP鏈接。
要掌握住這5個功能，不只僅須要熟悉一些API的使用，更要理解底層網絡如何與上層API之間互相發生影響。同時，還須要對不一樣的場景下，如何權衡開發效率、進程、線程與這些API的組合使用。下面依次來講說這些網絡IO。


一、 與客戶端創建起TCP鏈接
談這個功能前，先來看看網絡、協議、應用服務器間的關係 ：

上圖中可知：
爲簡化不一樣場景下的編程，TCP/IP協議族劃分了應用層、TCP傳輸層、IP網絡層、鏈路層等，每一層只專一於少許功能。
例如，IP層只專一於每個網絡分組如何到達目的主機，而無論目的主機如何處理。
傳輸層最基本的功能是專一於端到端，也就是一臺主機上的進程發出的包，如何到達目的主機上的某個進程。固然，TCP層爲了可靠性，還額外須要解決3個大問題：丟包（網絡分組在傳輸中存在的丟失）、重複（協議層異常引起的多個相同網絡分組）、延遲（好久後網絡分組纔到達目的地）。
鏈路層則只關心以太網或其餘二層網絡內網絡包的傳輸。

回到應用層，每每只須要調用相似於accept的API就能夠創建TCP鏈接。創建鏈接的流程你們都瞭解--三次握手，它如何與accept交互呢？下面以一個不太精確卻通俗易懂的圖來講明之：

研究過backlog含義的朋友都很容易理解上圖。這兩個隊列是內核實現的，當服務器綁定、監聽了某個端口後，這個端口的SYN隊列和ACCEPT隊列就創建好了。客戶端使用connect向服務器發起TCP鏈接，當圖中1.1步驟客戶端的SYN包到達了服務器後，內核會把這一信息放到SYN隊列（即未完成握手隊列）中，同時回一個SYN+ACK包給客戶端。一段時間後，在較中2.1步驟中客戶端再次發來了針對服務器SYN包的ACK網絡分組時，內核會把鏈接從SYN隊列中取出，再把這個鏈接放到ACCEPT隊列（即已完成握手隊列）中。而服務器在第3步調用accept時，其實就是直接從ACCEPT隊列中取出已經創建成功的鏈接套接字而已。

現有咱們能夠來討論應用層組件：爲什麼有的應用服務器進程中，會單獨使用1個線程，只調用accept方法來創建鏈接，例如tomcat；有的應用服務器進程中，卻用1個線程作全部的事，包括accept獲取新鏈接。

緣由在於：首先，SYN隊列和ACCEPT隊列都不是無限長度的，它們的長度限制與調用listen監聽某個地址端口時傳遞的backlog參數有關。既然隊列長度是一個值，那麼，隊列會滿嗎？固然會，若是上圖中第1步執行的速度大於第2步執行的速度，SYN隊列就會不斷增大直到隊列滿；若是第2步執行的速度遠大於第3步執行的速度，ACCEPT隊列一樣會達到上限。第一、2步不是應用程序可控的，但第3步倒是應用程序的行爲，假設進程中調用accept獲取新鏈接的代碼段長期得不到執行，例如獲取不到鎖、IO阻塞等。

那麼，這兩個隊列滿了後，新的請求到達了又將發生什麼？
若SYN隊列滿，則會直接丟棄請求，即新的SYN網絡分組會被丟棄；若是ACCEPT隊列滿，則不會致使放棄鏈接，也不會把鏈接從SYN列隊中移出，這會加重SYN隊列的增加。因此，對應用服務器來講，若是ACCEPT隊列中有已經創建好的TCP鏈接，卻沒有及時的把它取出來，這樣，一旦致使兩個隊列滿了後，就會使客戶端不能再創建新鏈接，引起嚴重問題。
因此，如TOMCAT等服務器會使用獨立的線程，只作accept獲取鏈接這一件事，以防止不能及時的去accept獲取鏈接。

那麼，爲何如Nginx等一些服務器，在一個線程內作accept的同時，還會作其餘IO等操做呢？
這裏就帶出阻塞和非阻塞的概念。應用程序能夠把listen時設置的套接字設爲非阻塞模式（默認爲阻塞模式），這兩種模式會致使accept方法有不一樣的行爲。對阻塞套接字，accept行爲以下圖：

這幅圖中能夠看到，阻塞套接字上使用accept，第一個階段是等待ACCEPT隊列不爲空的階段，它耗時不定，由客戶端是否向本身發起了TCP請求而定，可能會耗時很長。
對非阻塞套接字，accept會有兩種返回，以下圖：

非阻塞套接字上的accept，不存在等待ACCEPT隊列不爲空的階段，它要麼返回成功並拿到創建好的鏈接，要麼返回失敗。

因此，企業級的服務器進程中，若某一線程既使用accept獲取新鏈接，又繼續在這個鏈接上讀、寫字符流，那麼，這個鏈接對應的套接字一般要設爲非阻塞。緣由如上圖，調用accept時不會長期佔用所屬線程的CPU時間片，使得線程可以及時的作其餘工做。


  

高性能網絡編程2----TCP消息的發送

標籤： tcpkernelnaglesocketlinux
2013-07-18 16:37  17001人閱讀  評論(33)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。nginx

在上一篇中，咱們已經創建好的TCP鏈接，對應着操做系統分配的1個套接字。操做TCP協議發送數據時，面對的是數據流。一般調用諸如send或者write方法來發送數據到另外一臺主機，那麼，調用這樣的方法時，在操做系統內核中發生了什麼事情呢？咱們帶着如下3個問題來細細分析：發送方法成功返回時，能保證TCP另外一端的主機接收到嗎？能保證數據已經發送到網絡上了嗎？套接字爲阻塞或者非阻塞時，發送方法作的事情有何不一樣？

要回答上面3個問題涉及了很多知識點，咱們先在TCP層面上看看，發送方法調用時內核作了哪些事。我不想去羅列內核中的數據結構、方法等，畢竟大部分應用程序開發者不須要了解這些，僅以一幅示意圖粗略表示，以下：

圖1 一種典型場景下發送TCP消息的流程
再詳述上圖10個步驟前，先要澄清幾個概念：MTU、MSS、 tcp_write_queue發送隊列、阻塞與非阻塞套接字、擁塞窗口、滑動窗口、 Nagle算法。
當咱們調用發送方法時，會把咱們代碼中構造好的消息流做爲參數傳遞。這個消息流可大可小，例如幾個字節，或者幾兆字節。當消息流較大時，將有可能出現分片。咱們先來討論分片問題。

一、MSS與TCP的分片
由上一篇文中可知，TCP層是第4層傳輸層，第3層IP網絡層、第2層數據鏈路層具有的約束條件一樣對TCP層生效。下面來看看數據鏈路層中的一個概念：最大傳輸單元MTU。
不管何種類型的數據鏈路層，都會對網絡分組的長度有一個限制。例如以太網限制爲1500字節，802.3限制爲1492字節。當內核的IP網絡層試圖發送報文時，若一個報文的長度大於MTU限制，就會被分紅若干個小於MTU的報文，每一個報文都會有獨立的IP頭部。

看看IP頭部的格式：

圖2 IP頭部格式
能夠看到，其指定IP包總長度的是一個16位（2字節）的字段，這意味一個IP包最大能夠是65535字節。
若TCP層在以太網中試圖發送一個大於1500字節的消息，調用IP網絡層方法發送消息時，IP層會自動的獲取所在局域網的MTU值，並按照所在網絡的MTU大小來分片。IP層同時但願這個分片對於傳輸層來講是透明的，接收方的IP層會根據收到的多個IP包頭部，將發送方IP層分片出的IP包重組爲一個消息。
這種IP層的分片效率是不好的，由於必須全部分片都到達才能重組成一個包，其中任何一個分片丟失了，都必須重發全部分片。因此，TCP層會試圖避免IP層執行數據報分片。

爲了不IP層的分片，TCP協議定義了一個新的概念：最大報文段長度MSS。它定義了一個TCP鏈接上，一個主機指望對端主機發送單個報文的最大長度。TCP3次握手創建鏈接時，鏈接雙方都要互相告知本身指望接收到的MSS大小。例如（使用tcpdump抓包）：
15:05:08.230782 IP 10.7.80.57.64569 > houyi-vm02.dev.sd.aliyun.com.tproxy: S 3027092051:3027092051(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
15:05:08.234267 IP houyi-vm02.dev.sd.aliyun.com.tproxy > 10.7.80.57.64569: S 26006838:26006838(0) ack 3027092052 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 9>
15:05:08.233320 IP 10.7.80.57.64543 > houyi-vm02.dev.sd.aliyun.com.tproxy: P 78972532:78972923(391) ack 12915963 win 255
因爲例子中兩臺主機都在以太網內，以太網的MTU爲1500，減去IP和TCP頭部的長度，MSS就是1460，三次握手中，SYN包都會攜帶指望的MSS大小。

當應用層調用TCP層提供的發送方法時，內核的TCP模塊在tcp_sendmsg方法裏，會按照對方告知的MSS來分片，把消息流分爲多個網絡分組（如圖1中的3個網絡分組），再調用IP層的方法發送數據。

這個MSS就不會改變了嗎？
會的。上文說過，MSS就是爲了不IP層分片，在創建握手時告知對方指望接收的MSS值並不必定靠得住。由於這個值是預估的，TCP鏈接上的兩臺主機若處於不一樣的網絡中，那麼，鏈接上可能有許多中間網絡，這些網絡分別具備不一樣的數據鏈路層，這樣，TCP鏈接上有許多個MTU。特別是，若中間途徑的MTU小於兩臺主機所在的網絡MTU時，選定的MSS仍然太大了，會致使中間路由器出現IP層的分片。
怎樣避免中間網絡可能出現的分片呢？
經過IP頭部的DF標誌位，這個標誌位是告訴IP報文所途經的全部IP層代碼：不要對這個報文分片。若是一個IP報文太大必需要分片，則直接返回一個ICMP錯誤，說明必需要分片了，且待分片路由器網絡接受的MTU值。這樣，鏈接上的發送方主機就能夠從新肯定MSS。


二、發送方法返回成功後，數據必定發送到了TCP的另外一端嗎？
答案固然是否認的。解釋這個問題前，先來看看TCP是如何保證可靠傳輸的。
TCP把本身要發送的數據流裏的每個字節都當作一個序號，可靠性是要求鏈接對端在接收到數據後，要發送ACK確認，告訴它已經接收到了多少字節的數據。也就是說，怎樣確保數據必定發送成功了呢？必須等待發送數據對應序號的ACK到達，才能確保數據必定發送成功。 TCP層提供的send或者write這樣的方法是不會作這件事的，看看圖1，它究竟作了哪些事。

圖1中分爲10步。
（1）應用程序試圖調用send方法來發送一段較長的數據。
（2）內核主要經過tcp_sendmsg方法來完成。
（3）（4）內核真正執行報文的發送，與send方法的調用並非同步的。即，send方法返回成功了，也不必定把IP報文都發送到網絡中了。所以，須要把用戶須要發送的用戶態內存中的數據，拷貝到內核態內存中，不依賴於用戶態內存，也使得進程能夠快速釋放發送數據佔用的用戶態內存。但這個拷貝操做並非簡單的複製，而是把待發送數據，按照MSS來劃分紅多個儘可能達到MSS大小的分片報文段，複製到內核中的sk_buff結構來存放，同時把這些分片組成隊列，放到這個TCP鏈接對應的 tcp_write_queue發送隊列中 。
（5）內核中爲這個TCP鏈接分配的內核緩存是有限的（ /proc/sys/net/core/wmem_default ）。當沒有多餘的內核態緩存來複制用戶態的待發送數據時，就須要調用一個方法 sk_stream_wait_memory來等待滑動窗口移動，釋放出一些緩存出來（收到ACK後，不須要再緩存原來已經發送出的報文，由於既然已經確認對方收到，就不須要定時重發，天然就釋放緩存了）。例如：
[cpp]  view plain  copy
  1. wait_for_memory:  
  2.             if (copied)  
  3.                 tcp_push(sk, tp, flags & ~MSG_MORE, mss_now, TCP_NAGLE_PUSH);  
  4.   
  5.             if ((err = sk_stream_wait_memory(sk, &timeo)) != 0)  
  6.                 goto do_error;  

這裏的 sk_stream_wait_memory方法接受一個參數timeo，就是等待超時的時間。這個時間是tcp_sendmsg方法剛開始就拿到的，以下：
[cpp]  view plain  copy
  1. timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);  

看看其實現：
[cpp]  view plain  copy
  1. static inline long sock_sndtimeo(const struct sock *sk, int noblock)  
  2. {  
  3.     return noblock ? 0 : sk->sk_sndtimeo;  
  4. }  

也就是說，當這個套接字是阻塞套接字時，timeo就是SO_SNDTIMEO選項指定的發送超時時間。若是這個套接字是非阻塞套接字， timeo變量就會是0。
實際上，sk_stream_wait_memory對於非阻塞套接字會直接返回，並將 errno錯誤碼置爲EAGAIN。
（6）在圖1的例子中，咱們假定使用了阻塞套接字，且等待了足夠久的時間，收到了對方的ACK，滑動窗口釋放出了緩存。
（7）將剩下的用戶態數據都組成MSS報文拷貝到內核態的sk_buff中。
（8）最後，調用tcp_push等方法，它最終會調用IP層的方法來發送tcp_write_queue隊列中的報文。
注意，IP層返回時，並不必定是把報文發送了出去。
（9）（10）發送方法返回。

從圖1的10個步驟中可知，不管是使用阻塞仍是非阻塞套接字，發送方法成功返回時（不管所有成功或者部分紅功），既不表明TCP鏈接的另外一端主機接收到了消息，也不表明本機把消息發送到了網絡上，只是說明，內核將會試圖保證把消息送達對方。


三、 Nagle算法、 滑動窗口、擁塞窗口對發送方法的影響
圖1第8步tcp_push方法作了些什麼呢？先來看看主要的流程：

圖3 發送TCP消息的簡易流程

下面簡單看看這幾個概念：
（1）滑動窗口
滑動窗口你們都比較熟悉，就不詳細介紹了。TCP鏈接上的雙方都會通知對方本身的接收窗口大小。而對方的接收窗口大小就是本身的發送窗口大小。tcp_push在發送數據時固然須要與發送窗口打交道。發送窗口是一個時刻變化的值，隨着ACK的到達會變大，隨着發出新的數據包會變小。固然，最大也只能到三次握手時對方通告的窗口大小。tcp_push在發送數據時，最終會使用tcp_snd_wnd_test方法來判斷當前待發送的數據，其序號是否超出了發送滑動窗口的大小，例如：
[cpp]  view plain  copy
  1. //檢查這一次要發送的報文最大序號是否超出了發送滑動窗口大小  
  2. static inline int tcp_snd_wnd_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss)  
  3. {  
  4.         //end_seq待發送的最大序號  
  5.     u32 end_seq = TCP_SKB_CB(skb)->end_seq;  
  6.   
  7.     if (skb->len > cur_mss)  
  8.         end_seq = TCP_SKB_CB(skb)->seq + cur_mss;  
  9.   
  10.         //snd_una是已經發送過的數據中，最小的沒被確認的序號；而snd_wnd就是發送窗口的大小  
  11.     return !after(end_seq, tp->snd_una + tp->snd_wnd);  
  12. }  


（2）慢啓動和擁塞窗口
因爲兩臺主機間的網絡可能很複雜，經過廣域網時，中間的路由器轉發能力多是瓶頸。也就是說，若是一方簡單的按照另外一方主機三次握手時通告的滑動窗口大小來發送數據的話，可能會使得網絡上的轉發路由器性能雪上加霜，最終丟失更多的分組。這時，各個操做系統內核都會對TCP的發送階段加入慢啓動和擁塞避免算法。慢啓動算法說白了，就是對方通告的窗口大小隻表示對方接收TCP分組的能力，不表示中間網絡可以處理分組的能力。因此，發送方請悠着點發，確保網絡很是通暢了後，再按照對方通告窗口來敞開了發。
擁塞窗口就是下面的cwnd，它用來幫助慢啓動的實現。鏈接剛創建時，擁塞窗口的大小遠小於發送窗口，它其實是一個MSS。每收到一個ACK，擁塞窗口擴大一個MSS大小，固然，擁塞窗口最大隻能到對方通告的接收窗口大小。固然，爲了不指數式增加，擁塞窗口大小的增加會更慢一些，是線性的平滑的增加過程。
因此，在tcp_push發送消息時，還會檢查擁塞窗口，飛行中的報文數要小於擁塞窗口個數，而發送數據的長度也要小於擁塞窗口的長度。
以下所示，首先用 unsigned int tcp_cwnd_test方法檢查飛行的報文數是否小於擁塞窗口個數（多少個MSS的個數） ：
[cpp]  view plain  copy
  1. static inline unsigned int tcp_cwnd_test(struct tcp_sock *tp, struct sk_buff *skb)  
  2. {  
  3.     u32 in_flight, cwnd;  
  4.   
  5.     /* Don't be strict about the congestion window for the final FIN.  */  
  6.     if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)  
  7.         return 1;  
  8.   
  9.         //飛行中的數據，也就是沒有ACK的字節總數  
  10.     in_flight = tcp_packets_in_flight(tp);  
  11.     cwnd = tp->snd_cwnd;  
  12.         //若是擁塞窗口容許，須要返回依據擁塞窗口的大小，還能發送多少字節的數據  
  13.     if (in_flight < cwnd)  
  14.         return (cwnd - in_flight);  
  15.   
  16.     return 0;  
  17. }  

再經過tcp_window_allows方法獲取擁塞窗口與滑動窗口的最小長度，檢查待發送的數據是否超出：
[cpp]  view plain  copy
  1. static unsigned int tcp_window_allows(struct tcp_sock *tp, struct sk_buff *skb, unsigned int mss_now, unsigned int cwnd)  
  2. {  
  3.     u32 window, cwnd_len;  
  4.   
  5.     window = (tp->snd_una + tp->snd_wnd - TCP_SKB_CB(skb)->seq);  
  6.     cwnd_len = mss_now * cwnd;  
  7.     return min(window, cwnd_len);  
  8. }  


（3）是否符合NAGLE算法？
Nagle算法的初衷是這樣的：應用進程調用發送方法時，可能每次只發送小塊數據，形成這臺機器發送了許多小的TCP報文。對於整個網絡的執行效率來講，小的TCP報文會增長網絡擁塞的可能，所以，若是有可能，應該將相臨的TCP報文合併成一個較大的TCP報文（固然仍是小於MSS的）發送。
Nagle算法要求一個TCP鏈接上最多隻能有一個發送出去還沒被確認的小分組，在該分組的確認到達以前不能發送其餘的小分組。
內核中是經過  tcp_nagle_test 方法實現該算法的。咱們簡單的看下：
[cpp]  view plain  copy
  1.   
[cpp]  view plain  copy
  1. static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff *skb,  
  2.                  unsigned int cur_mss, int nonagle)  
  3. {  
  4.     //nonagle標誌位設置了，返回1表示容許這個分組發送出去  
  5.     if (nonagle & TCP_NAGLE_PUSH)  
  6.         return 1;  
  7.   
  8.     //若是這個分組包含了四次握手關閉鏈接的FIN包，也能夠發送出去  
  9.     if (tp->urg_mode ||  
  10.         (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN))  
  11.         return 1;  
  12.   
  13.         //檢查Nagle算法  
  14.     if (!tcp_nagle_check(tp, skb, cur_mss, nonagle))  
  15.         return 1;  
  16.   
  17.     return 0;  
  18. }  

再來看看 tcp_nagle_check方法，它與上一個方法不一樣，返回0表示能夠發送，返回非0則不能夠，正好相反。
[cpp]  view plain  copy
  1. static inline int tcp_nagle_check(const struct tcp_sock *tp,  
  2.                   const struct sk_buff *skb,   
  3.                   unsigned mss_now, int nonagle)  
  4. {  
  5.         //先檢查是否爲小分組，即報文長度是否小於MSS  
  6.     return (skb->len < mss_now &&  
  7.         ((nonagle&TCP_NAGLE_CORK) ||  
  8.         //若是開啓了Nagle算法  
  9.          (!nonagle &&  
  10.         //若已經有小分組發出（packets_out表示「飛行」中的分組）尚未確認  
  11.           tp->packets_out &&  
  12.           tcp_minshall_check(tp))));  
  13. }  

最後看看tcp_minshall_check作了些什麼：
[cpp]  view plain  copy
  1. static inline int tcp_minshall_check(const struct tcp_sock *tp)  
  2. {  
  3.         //最後一次發送的小分組尚未被確認  
  4.     return after(tp->snd_sml,tp->snd_una) &&  
  5.                 //將要發送的序號是要大於等於上次發送分組對應的序號  
  6.         !after(tp->snd_sml, tp->snd_nxt);  
  7. }  

想象一種場景，當對請求的時延很是在乎且網絡環境很是好的時候（例如同一個機房內），Nagle算法能夠關閉，這實在也不必。使用TCP_NODELAY套接字選項就能夠關閉Nagle算法。看看setsockopt是怎麼與上述方法配合工做的：
[cpp]  view plain  copy
  1. static int do_tcp_setsockopt(struct sock *sk, int level,  
  2.         int optname, char __user *optval, int optlen)  
  3.         ...  
  4.     switch (optname) {  
  5.         ...  
  6.     case TCP_NODELAY:  
  7.         if (val) {  
  8.                         //若是設置了TCP_NODELAY，則更新nonagle標誌  
  9.             tp->nonagle |= TCP_NAGLE_OFF|TCP_NAGLE_PUSH;  
  10.             tcp_push_pending_frames(sk, tp);  
  11.         } else {  
  12.             tp->nonagle &= ~TCP_NAGLE_OFF;  
  13.         }  
  14.         break;  
  15.         }  
  16. }  

能夠看到，nonagle標誌位就是這麼更改的。


固然，調用了IP層的方法返回後，也未必就保證此時數據必定發送到網絡中去了。
下一篇咱們探討如何接收TCP消息，以及接收到ack後內核作了些什麼。

  

高性能網絡編程3----TCP消息的接收

標籤： linuxtcp高性能服務器網絡編程
2013-08-26 18:55  17975人閱讀  評論(29)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。程序員

這篇文章將試圖說明應用程序如何接收網絡上發送過來的TCP消息流，因爲篇幅所限，暫時忽略ACK報文的回覆和接收窗口的滑動。
爲了快速掌握本文所要表達的思想，咱們能夠帶着如下問題閱讀：
一、應用程序調用read、recv等方法時，socket套接字能夠設置爲阻塞或者非阻塞，這兩種方式是如何工做的？
二、若socket爲默認的阻塞套接字，此時recv方法傳入的len參數，是表示必須超時（SO_RCVTIMEO）或者接收到len長度的消息，recv方法纔會返回嗎？並且，socket上能夠設置一個屬性叫作SO_RCVLOWAT，它會與len產生什麼樣的交集，又是決定recv等接收方法何時返回？
三、應用程序開始收取TCP消息，與程序所在的機器網卡上接收到網絡裏發來的TCP消息，這是兩個獨立的流程。它們之間是如何互相影響的？例如，應用程序正在收取消息時，內核經過網卡又在這條TCP鏈接上收到消息時，到底是如何處理的？若應用程序沒有調用read或者recv時，內核收到TCP鏈接上的消息後又是怎樣處理的？
四、recv這樣的接收方法還能夠傳入各類flags，例如MSG_WAITALL、MSG_PEEK、MSG_TRUNK等等。它們是如何工做的？
五、1個socket套接字可能被多個進程在使用，出現併發訪問時，內核是怎麼處理這種情況的？
六、linux的sysctl系統參數中，有相似tcp_low_latency這樣的開關，默認爲0或者配置爲1時是如何影響TCP消息處理流程的？


書接上文。本文將經過三幅圖講述三種典型的接收TCP消息場景，理清內核爲實現TCP消息的接收所實現的4個隊列容器。固然，瞭解內核的實現並非目的，而是如何使用socket接口、如何配置操做系統內核參數，才能使TCP傳輸消息更高效，這纔是最終目的。

不少同窗不但願被內核代碼擾亂了思惟，如何閱讀本文呢？
我會在圖1的步驟都介紹完了纔來從代碼上說明tcp_v4_rcv等主要方法。像flags參數、非阻塞套接字會產生怎樣的效果我是在代碼介紹中說的。而後我會介紹圖二、圖3，介紹它們的步驟時我會穿插一些上文沒有涉及的少許代碼。不喜歡瞭解內核代碼的同窗請直接看完圖1的步驟後，請跳到圖二、圖3中，我認爲這3幅圖覆蓋了主要的TCP接收場景，可以幫助你理清其流程。

接收消息時調用的系統方法要比上一篇發送TCP消息複雜許多。接收TCP消息的過程能夠一分爲二：首先是PC上的網卡接收到網線傳來的報文，經過軟中斷內核拿到而且解析其爲TCP報文，而後TCP模塊決定如何處理這個TCP報文。其次，用戶進程調用read、recv等方法獲取TCP消息，則是將內核已經從網卡上收到的消息流拷貝到用戶進程裏的內存中。

第一幅圖描述的場景是，TCP鏈接上將要收到的消息序號是S1（TCP上的每一個報文都有序號，詳見《TCP/IP協議詳解》），此時操做系統內核依次收到了序號S1-S2的報文、S3-S四、S2-S3的報文，注意後兩個包亂序了。以後，用戶進程分配了一段len大小的內存用於接收TCP消息，此時，len是大於S4-S1的。另外，用戶進程始終沒有對這個socket設置過SO_RCVLOWAT參數，所以，接收閥值SO_RCVLOWAT使用默認值1。另外，系統參數tcp_low_latency設置爲0，即從操做系統的整體效率出發，使用prequeue隊列提高吞吐量。固然，因爲用戶進程收消息時，並無新包來臨，因此此圖中prequeue隊列始終爲空。先不細表。
圖1以下：

上圖中有13個步驟，應用進程使用了阻塞套接字，調用recv等方法時flag標誌位爲0，用戶進程讀取套接字時沒有發生進程睡眠。內核在處理接收到的TCP報文時使用了4個隊列容器（當鏈表理解也可），分別爲receive、out_of_order、prequeue、backlog隊列，本文會說明它們存在的意義。下面詳細說明這13個步驟。
一、當網卡接收到報文並判斷爲TCP協議後，將會調用到內核的tcp_v4_rcv方法。此時，這個TCP鏈接上須要接收的下一個報文序號剛好就是S1，而這一步裏，網卡上收到了S1-S2的報文，因此，tcp_v4_rcv方法會把這個報文直接插入到receive隊列中。
注意：receive隊列是容許用戶進程直接讀取的，它是將已經接收到的TCP報文，去除了TCP頭部、排好序放入的、用戶進程能夠直接按序讀取的隊列。因爲socket不在進程上下文中（也就是沒有進程在讀socket），因爲咱們須要S1序號的報文，而剛好收到了S1-S2報文，所以，它進入了receive隊列。

二、接着，咱們收到了S3-S4報文。在第1步結束後，這時咱們須要收到的是S2序號，但到來的報文倒是S3打頭的，怎麼辦呢？進入out_of_order隊列！從這個隊列名稱就能夠看出來，全部亂序的報文都會暫時放在這。

三、仍然沒有進入來讀取socket，但又過來了咱們指望的S2-S3報文，它會像第1步同樣，直接進入receive隊列。不一樣的時，因爲此時out_of_order隊列不像第1步是空的，因此，引起了接來的第4步。

四、每次向receive隊列插入報文時都會檢查out_of_order隊列。因爲收到S2-S3報文後，期待的序號成爲了S3，這樣，out_of_order隊列裏的惟一報文S3-S4報文將會移出本隊列而插入到receive隊列中（這件事由tcp_ofo_queue方法完成）。

五、終於有用戶進程開始讀取socket了。作過應用端編程的同窗都知道，先要在進程裏分配一塊內存，接着調用read或者recv等方法，把內存的首地址和內存長度傳入，再把創建好鏈接的socket也傳入。固然，對這個socket還能夠配置其屬性。這裏，假定沒有設置任何屬性，都使用默認值，所以，此時socket是阻塞式，它的SO_RCVLOWAT是默認的1。固然，recv這樣的方法還會接收一個flag參數，它能夠設置爲MSG_WAITALL、MSG_PEEK、MSG_TRUNK等等，這裏咱們假定爲最經常使用的0。進程調用了recv方法。

六、不管是何種接口，C庫和內核通過層層封裝，接收TCP消息最終必定會走到tcp_recvmsg方法。下面介紹代碼細節時，它會是重點。

七、在tcp_recvmsg方法裏，會首先鎖住socket。爲何呢？所以socket是能夠被多進程同時使用的，同時，內核中斷也會操做它，而下面的代碼都是核心的、操做數據的、有狀態的代碼，不能夠被重入的，鎖住後，再有用戶進程進來時拿不到鎖就要休眠在這了。內核中斷看到被鎖住後也會作不一樣的處理，參見圖二、圖3。

八、此時，第1-4步已經爲receive隊列裏準備好了3個報文。最上面的報文是S1-S2，將它拷貝到用戶態內存中。因爲第5步flag參數並無攜帶MSG_PEEK這樣的標誌位，所以，再將S1-S2報文從receive隊列的頭部移除，從內核態釋放掉。反之，MSG_PEEK標誌位會致使receive隊列不會刪除報文。因此，MSG_PEEK主要用於多進程讀取同一套接字的情形。

九、如第8步，拷貝S2-S3報文到用戶態內存中。固然，執行拷貝前都會檢查用戶態內存的剩餘空間是否足以放下當前這個報文，不足以時會直接返回已經拷貝的字節數。
十、同上。

十一、receive隊列爲空了，此時會先來檢查SO_RCVLOWAT這個閥值。若是已經拷貝的字節數到如今還小於它，那麼可能致使進程會休眠，等待拷貝更多的數據。第5步已經說明過了，socket套接字使用的默認的SO_RCVLOWAT，也就是1，這代表，只要讀取到報文了，就認爲能夠返回了。
作完這個檢查了，再檢查backlog隊列。backlog隊列是進程正在拷貝數據時，網卡收到的報文會進這個隊列。此時若backlog隊列有數據，就順帶處理下。圖3會覆蓋這種場景。

十二、在本圖對應的場景中，backlog隊列是沒有數據的，已經拷貝的字節數爲S4-S1，它是大於1的，所以，釋放第7步里加的鎖，準備返回用戶態了。

1三、用戶進程代碼開始執行，此時recv等方法返回的就是S4-S1，即從內核拷貝的字節數。


圖1描述的場景是最簡單的1種場景，下面咱們來看看上述步驟是怎樣經過內核代碼實現的（如下代碼爲2.6.18內核代碼）。


咱們知道，linux對中斷的處理是分爲上半部和下半部的，這是處於系統總體效率的考慮。咱們將要介紹的都是在網絡軟中斷的下半部裏，例如這個tcp_v4_rcv方法。圖1中的第1-4步都是在這個方法裏完成的。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. int tcp_v4_rcv(struct sk_buff *skb)  
  2. {  
  3.         ... ...  
  4.     //是否有進程正在使用這個套接字，將會對處理流程產生影響  
  5.         //或者從代碼層面上，只要在tcp_recvmsg裏，執行lock_sock後只能進入else，而release_sock後會進入if  
  6.     if (!sock_owned_by_user(sk)) {  
  7.         {  
  8.             //當 tcp_prequeue 返回0時，表示這個函數沒有處理該報文  
  9.             if (!tcp_prequeue(sk, skb))//若是報文放在prequeue隊列，即表示延後處理，不佔用軟中斷過長時間  
  10.                 ret = tcp_v4_do_rcv(sk, skb);//不使用prequeue或者沒有用戶進程讀socket時（圖3進入此分支），馬上開始處理這個報文  
  11.         }  
  12.     } else  
  13.         sk_add_backlog(sk, skb);//若是進程正在操做套接字，就把skb指向的TCP報文插入到backlog隊列（圖3涉及此分支）  
  14.         ... ...  
  15. ｝  

圖1第1步裏，咱們從網絡上收到了序號爲S1-S2的包。此時，沒有用戶進程在讀取套接字，所以，sock_owned_by_user(sk)會返回0。因此，tcp_prequeue方法將獲得執行。簡單看看它：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static inline int tcp_prequeue(struct sock *sk, struct sk_buff *skb)  
  2. {  
  3.     struct tcp_sock *tp = tcp_sk(sk);  
  4.   
  5.     //檢查tcp_low_latency，默認其爲0，表示使用prequeue隊列。tp->ucopy.task不爲0，表示有進程啓動了拷貝TCP消息的流程  
  6.     if (!sysctl_tcp_low_latency && tp->ucopy.task) {  
  7.         //到這裏，一般是用戶進程讀數據時沒讀到指定大小的數據，休眠了。直接將報文插入prequeue隊列的末尾，延後處理  
  8.         __skb_queue_tail(&tp->ucopy.prequeue, skb);  
  9.         tp->ucopy.memory += skb->truesize;  
  10.         //固然，雖然一般是延後處理，但若是TCP的接收緩衝區不夠用了，就會馬上處理prequeue隊列裏的全部報文  
  11.         if (tp->ucopy.memory > sk->sk_rcvbuf) {  
  12.             while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) {  
  13.                                 //sk_backlog_rcv就是下文將要介紹的tcp_v4_do_rcv方法  
  14.                 sk->sk_backlog_rcv(sk, skb1);  
  15.             }  
  16.         } else if (skb_queue_len(&tp->ucopy.prequeue) == 1) {  
  17.                         //prequeue裏有報文了，喚醒正在休眠等待數據的進程，讓進程在它的上下文中處理這個prequeue隊列的報文  
  18.             wake_up_interruptible(sk->sk_sleep);  
  19.         }  
  20.   
  21.         return 1;  
  22.     }  
  23.     //prequeue沒有處理  
  24.     return 0;  
  25. }  

因爲tp->ucopy.task此時是NULL，因此咱們收到的第1個報文在tcp_prequeue函數裏直接返回了0，所以，將由 tcp_v4_do_rcv方法處理。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)  
  2. {  
  3.     if (sk->sk_state == TCP_ESTABLISHED) { /* Fast path */  
  4.         //當TCP鏈接已經創建好時，是由tcp_rcv_established方法處理接收報文的  
  5.         if (tcp_rcv_established(sk, skb, skb->h.th, skb->len))  
  6.             goto reset;  
  7.   
  8.         return 0;  
  9.     }  
  10.         ... ...  
  11. ｝  

tcp_rcv_established方法在圖1裏，主要調用tcp_data_queue方法將報文放入隊列中，繼續看看它又幹了些什麼事：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)  
  2. {  
  3.     struct tcp_sock *tp = tcp_sk(sk);  
  4.   
  5.     //若是這個報文是待接收的報文（看seq），它有兩個出路：進入receive隊列，正如圖1；直接拷貝到用戶內存中，如圖3  
  6.     if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {  
  7.                 //滑動窗口外的包暫不考慮，篇幅有限，下次再細談  
  8.         if (tcp_receive_window(tp) == 0)  
  9.             goto out_of_window;  
  10.   
  11.         //若是有一個進程正在讀取socket，且正準備要拷貝的序號就是當前報文的seq序號  
  12.         if (tp->ucopy.task == current &&  
  13.             tp->copied_seq == tp->rcv_nxt && tp->ucopy.len &&  
  14.             sock_owned_by_user(sk) && !tp->urg_data) {  
  15.             //直接將報文內容拷貝到用戶態內存中，參見圖3  
  16.             if (!skb_copy_datagram_iovec(skb, 0, tp->ucopy.iov, chunk)) {  
  17.                 tp->ucopy.len -= chunk;  
  18.                 tp->copied_seq += chunk;  
  19.             }  
  20.         }  
  21.   
  22.         if (eaten <= 0) {  
  23. queue_and_out:  
  24.                         //若是沒有可以直接拷貝到用戶內存中，那麼，插入receive隊列吧，正如圖1中的第一、3步  
  25.             __skb_queue_tail(&sk->sk_receive_queue, skb);  
  26.         }  
  27.                 //更新待接收的序號，例如圖1第1步中，更新爲S2  
  28.         tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;  
  29.   
  30.                 //正如圖1第4步，這時會檢查out_of_order隊列，若它不爲空，須要處理它  
  31.         if (!skb_queue_empty(&tp->out_of_order_queue)) {  
  32.                         //tcp_ofo_queue方法會檢查out_of_order隊列中的全部報文  
  33.             tcp_ofo_queue(sk);  
  34.         }  
  35.     }  
  36.         ... ...  
  37.   
  38.     //這個包是無序的，又在接收滑動窗口內，那麼就如圖1第2步，把報文插入到out_of_order隊列吧  
  39.     if (!skb_peek(&tp->out_of_order_queue)) {  
  40.         __skb_queue_head(&tp->out_of_order_queue,skb);  
  41.     } else {  
  42.                     ... ...  
  43.             __skb_append(skb1, skb, &tp->out_of_order_queue);  
  44.     }  
  45. }  

圖1第4步時，正是經過tcp_ofo_queue方法把以前亂序的S3-S4報文插入receive隊列的。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static void tcp_ofo_queue(struct sock *sk)  
  2. {  
  3.     struct tcp_sock *tp = tcp_sk(sk);  
  4.     __u32 dsack_high = tp->rcv_nxt;  
  5.     struct sk_buff *skb;  
  6.         //遍歷out_of_order隊列  
  7.     while ((skb = skb_peek(&tp->out_of_order_queue)) != NULL) {  
  8.         ... ...  
  9.                 //若這個報文能夠按seq插入有序的receive隊列中，則將其移出out_of_order隊列  
  10.         __skb_unlink(skb, &tp->out_of_order_queue);  
  11.                 //插入receive隊列  
  12.         __skb_queue_tail(&sk->sk_receive_queue, skb);  
  13.                 //更新socket上待接收的下一個有序seq  
  14.         tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;  
  15.     }  
  16. }  


下面再介紹圖1第6步提到的tcp_recvmsg方法。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. //參數裏的len就是read、recv方法裏的內存長度，flags正是方法的flags參數，nonblock則是阻塞、非阻塞標誌位  
  2. int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,  
  3.         size_t len, int nonblock, int flags, int *addr_len)  
  4. {  
  5.     //鎖住socket，防止多進程併發訪問TCP鏈接，告知軟中斷目前socket在進程上下文中  
  6.     lock_sock(sk);  
  7.   
  8.         //初始化errno這個錯誤碼  
  9.     err = -ENOTCONN;  
  10.   
  11.     //若是socket是阻塞套接字，則取出SO_RCVTIMEO做爲讀超時時間；若爲非阻塞，則timeo爲0。下面會看到timeo是如何生效的  
  12.     timeo = sock_rcvtimeo(sk, nonblock);  
  13.   
  14.     //獲取下一個要拷貝的字節序號  
  15.     //注意：seq的定義爲u32 *seq;，它是32位指針。爲什麼？由於下面每向用戶態內存拷貝後，會更新seq的值，這時就會直接更改套接字上的copied_seq  
  16.     seq = &tp->copied_seq;  
  17.     //當flags參數有MSG_PEEK標誌位時，意味着此次拷貝的內容，當再次讀取socket時（好比另外一個進程）還能再次讀到  
  18.     if (flags & MSG_PEEK) {  
  19.         //因此不會更新copied_seq，固然，下面會看到也不會刪除報文，不會從receive隊列中移除報文  
  20.         peek_seq = tp->copied_seq;  
  21.         seq = &peek_seq;  
  22.     }  
  23.   
  24.     //獲取SO_RCVLOWAT最低接收閥值，固然，target其實是用戶態內存大小len和SO_RCVLOWAT的最小值  
  25.     //注意：flags參數中若攜帶MSG_WAITALL標誌位，則意味着必須等到讀取到len長度的消息才能返回，此時target只能是len  
  26.     target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);  
  27.   
  28.         //如下開始讀取消息  
  29.     do {  
  30.         //從receive隊列取出1個報文  
  31.         skb = skb_peek(&sk->sk_receive_queue);  
  32.         do {  
  33.             //沒取到退出當前循環  
  34.             if (!skb)  
  35.                 break;  
  36.   
  37.   
  38.             //offset是待拷貝序號在當前這個報文中的偏移量，在圖一、二、3中它都是0，只有由於用戶內存不足以接收完1個報文時才爲非0  
  39.             offset = *seq - TCP_SKB_CB(skb)->seq;  
  40.             //有些時候，三次握手的SYN包也會攜帶消息內容的，此時seq是多出1的（SYN佔1個序號），因此offset減1  
  41.             if (skb->h.th->syn)  
  42.                 offset--;  
  43.             //若偏移量還有這個報文以內，則認爲它須要處理  
  44.             if (offset < skb->len)  
  45.                 goto found_ok_skb;  
  46.   
  47.             skb = skb->next;  
  48.         } while (skb != (struct sk_buff *)&sk->sk_receive_queue);  
  49.   
  50.         //若是receive隊列爲空，則檢查已經拷貝的字節數，是否達到了SO_RCVLOWAT或者長度len。知足了，且backlog隊列也爲空，則能夠返回用戶態了，正如圖1的第11步  
  51.         if (copied >= target && !sk->sk_backlog.tail)  
  52.             break;  
  53.   
  54.                 //在tcp_recvmsg裏，copied就是已經拷貝的字節數  
  55.         if (copied) {  
  56.             ... ...  
  57.         } else {  
  58.                         //一個字節都沒拷貝到，但若是shutdown關閉了socket，同樣直接返回。固然，本文不涉及關閉鏈接  
  59.             if (sk->sk_shutdown & RCV_SHUTDOWN)  
  60.                 break;  
  61.   
  62.             //若是使用了非阻塞套接字，此時timeo爲0  
  63.             if (!timeo) {  
  64.                                 //非阻塞套接字讀取不到數據時也會返回，錯誤碼正是EAGAIN  
  65.                 copied = -EAGAIN;  
  66.                 break;  
  67.             }  
  68.                         ... ...  
  69.         }  
  70.   
  71.         //tcp_low_latency默認是關閉的，圖一、圖2都是如此，圖3則例外，即圖3不會走進這個if  
  72.         if (!sysctl_tcp_low_latency && tp->ucopy.task == user_recv) {  
  73.             //prequeue隊列就是爲了提升系統總體效率的，即prequeue隊列有可能不爲空，這是由於進程休眠等待時可能有新報文到達prequeue隊列  
  74.             if (!skb_queue_empty(&tp->ucopy.prequeue))  
  75.                 goto do_prequeue;  
  76.         }  
  77.   
  78.         //若是已經拷貝了的字節數超過了最低閥值  
  79.         if (copied >= target) {  
  80.             //release_sock這個方法會遍歷、處理backlog隊列中的報文  
  81.             release_sock(sk);  
  82.             lock_sock(sk);  
  83.         } else  
  84.             sk_wait_data(sk, &timeo);//沒有讀取到足夠長度的消息，所以會進程休眠，若是沒有被喚醒，最長睡眠timeo時間  
  85.   
  86.         if (user_recv) {  
  87.             if (tp->rcv_nxt == tp->copied_seq &&  
  88.                 !skb_queue_empty(&tp->ucopy.prequeue)) {  
  89. do_prequeue:  
  90.                                 //接上面代碼段，開始處理prequeue隊列裏的報文  
  91.                 tcp_prequeue_process(sk);  
  92.             }  
  93.         }  
  94.   
  95.         //繼續處理receive隊列的下一個報文  
  96.         continue;  
  97.   
  98.     found_ok_skb:  
  99.         /* Ok so how much can we use? */  
  100.         //receive隊列的這個報文從其能夠使用的偏移量offset，到總長度len之間，能夠拷貝的長度爲used  
  101.         used = skb->len - offset;  
  102.         //len是用戶態空閒內存，len更小時，固然只能拷貝len長度消息，總不能致使內存溢出吧  
  103.         if (len < used)  
  104.             used = len;  
  105.   
  106.         //MSG_TRUNC標誌位表示不要管len這個用戶態內存有多大，只管拷貝數據吧  
  107.         if (!(flags & MSG_TRUNC)) {  
  108.             {  
  109.                 //向用戶態拷貝數據  
  110.                 err = skb_copy_datagram_iovec(skb, offset,  
  111.                         msg->msg_iov, used);  
  112.             }  
  113.         }  
  114.   
  115.         //由於是指針，因此同時更新copied_seq--下一個待接收的序號  
  116.         *seq += used;  
  117.         //更新已經拷貝的長度  
  118.         copied += used;  
  119.         //更新用戶態內存的剩餘空閒空間長度  
  120.         len -= used;  
  121.   
  122.                 ... ...  
  123.     } while (len > 0);  
  124.   
  125.     //已經裝載了接收器  
  126.     if (user_recv) {  
  127.         //prequeue隊列不爲空則處理之  
  128.         if (!skb_queue_empty(&tp->ucopy.prequeue)) {  
  129.             tcp_prequeue_process(sk);  
  130.         }  
  131.   
  132.         //準備返回用戶態，socket上再也不裝載接收任務  
  133.         tp->ucopy.task = NULL;  
  134.         tp->ucopy.len = 0;  
  135.     }  
  136.   
  137.     //釋放socket時，還會檢查、處理backlog隊列中的報文  
  138.     release_sock(sk);  
  139.     //向用戶返回已經拷貝的字節數  
  140.     return copied;  
  141. }  


圖2給出了第2種場景，這裏涉及到prequeue隊列。用戶進程調用recv方法時，鏈接上沒有任何接收並緩存到內核的報文，而socket是阻塞的，因此進程睡眠了。而後網卡中收到了TCP鏈接上的報文，此時prequeue隊列開始產生做用。圖2中tcp_low_latency爲默認的0，套接字socket的SO_RCVLOWAT是默認的1，仍然是阻塞socket，以下圖：

簡單描述上述11個步驟：
一、用戶進程分配了一塊len大小的內存，將其傳入recv這樣的函數，同時socket參數皆爲默認，即阻塞的、SO_RCVLOWAT爲1。調用接收方法，其中flags參數爲0。

二、C庫和內核最終調用到tcp_recvmsg方法來處理。

三、鎖住socket。

四、因爲此時receive、prequeue、backlog隊列都是空的，即沒有拷貝1個字節的消息到用戶內存中，而咱們的最低要求是拷貝至少SO_RCVLOWAT爲1長度的消息。此時，開始進入阻塞式套接字的等待流程。最長等待時間爲SO_RCVTIMEO指定的時間。
這個等待函數叫作sk_wait_data，有必要看下其實現：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. int sk_wait_data(struct sock *sk, long *timeo)  
  2. {  
  3.         //注意，它的自動喚醒條件有兩個，要麼timeo時間到達，要麼receive隊列不爲空  
  4.     rc = sk_wait_event(sk, timeo, !skb_queue_empty(&sk->sk_receive_queue));  
  5. }  

sk_wait_event也值得咱們簡單看下：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. #define sk_wait_event(__sk, __timeo, __condition)       \  
  2. ({  int rc;                         \  
  3.     release_sock(__sk);                 \  
  4.     rc = __condition;                   \  
  5.     if (!rc) {                      \  
  6.         *(__timeo) = schedule_timeout(*(__timeo));  \  
  7.     }                           \  
  8.     lock_sock(__sk);                    \  
  9.     rc = __condition;                   \  
  10.     rc;                         \  
  11. })  

注意，它在睡眠前會調用release_sock，這個方法會釋放socket鎖，使得下面的第5步中，新到的報文再也不只能進入backlog隊列。

五、這個套接字上指望接收的序號也是S1，此時網卡剛好收到了S1-S2的報文，在tcp_v4_rcv方法中，經過調用tcp_prequeue方法把報文插入到prequeue隊列中。

六、插入prequeue隊列後，此時會接着調用wake_up_interruptible方法，喚醒在socket上睡眠的進程。參見tcp_prequque方法。

七、用戶進程被喚醒後，從新調用lock_sock接管了這個socket，此後再進來的報文都只能進入backlog隊列了。

八、進程醒來後，先去檢查receive隊列，固然仍然是空的；再去檢查prequeue隊列，發現有一個報文S1-S2，正好是socket鏈接待拷貝的起始序號S1，因而，從prequeue隊列中取出這個報文並把內容複製到用戶內存中，再釋放內核中的這個報文。

九、目前已經拷貝了S2-S1個字節到用戶態，檢查這個長度是否超過了最低閥值（即len和SO_RCVLOWAT的最小值）。

十、因爲SO_RCVLOWAT使用了默認的1，因此準備返回用戶。此時會順帶再看看backlog隊列中有沒有數據，如有，則檢查這個無序的隊列中是否有能夠直接拷貝給用戶的報文。固然，此時是沒有的。因此準備返回，釋放socket鎖。

十一、返回用戶已經拷貝的字節數。

圖3給出了第3種場景。這個場景中，咱們把系統參數tcp_low_latency設爲1，socket上設置了SO_RCVLOWAT屬性的值。服務器先是收到了S1-S2這個報文，但S2-S1的長度是小於SO_RCVLOWAT的，用戶進程調用recv方法讀套接字時，雖然讀到了一些，但沒有達到最小閥值，因此進程睡眠了，與此同時，在睡眠前收到的亂序的S3-S4包直接進入backlog隊列。此時先到達了S2-S3包，因爲沒有使用prequeue隊列，而它起始序號正是下一個待拷貝的值，因此直接拷貝到用戶內存中，總共拷貝字節數已知足SO_RCVLOWAT的要求！最後在返回用戶前把backlog隊列中S3-S4報文也拷貝給用戶了。以下圖：

簡明描述上述15個步驟：
一、內核收到報文S1-S2，S1正是這個socket鏈接上待接收的序號，所以，直接將它插入有序的receive隊列中。

二、用戶進程所處的linux操做系統上，將sysctl中的tcp_low_latency設置爲1。這意味着，這臺服務器但願TCP進程可以更及時的接收到TCP消息。用戶調用了recv方法接收socket上的消息，這個socket上設置了SO_RCVLOWAT屬性爲某個值n，這個n是大於S2-S1，也就是第1步收到的報文大小。這裏，仍然是阻塞socket，用戶依然是分配了足夠大的len長度內存以接收TCP消息。

三、經過tcp_recvmsg方法來完成接收工做。先鎖住socket，避免併發進程讀取同一socket的同時，也在告訴內核網絡軟中斷處理到這一socket時要有不一樣行爲，如第6步。

四、準備處理內核各個接收隊列中的報文。

五、receive隊列中的有序報文可直接拷貝，在檢查到S2-S1是小於len以後，將報文內容拷貝到用戶態內存中。

六、在第5步進行的同時，socket是被鎖住的，這時內核又收到了一個S3-S4報文，所以報文直接進入backlog隊列。注意，這個報文不是有序的，由於此時鏈接上期待接收序號爲S2。

七、在第5步，拷貝了S2-S1個字節到用戶內存，它是小於SO_RCVLOWAT的，所以，因爲socket是阻塞型套接字（超時時間在本文中忽略），進程將不得不轉入睡眠。轉入睡眠以前，還會幹一件事，就是處理backlog隊列裏的報文，圖2的第4步介紹過休眠方法sk_wait_data，它在睡眠前會執行release_sock方法，看看是如何實現的：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. void fastcall release_sock(struct sock *sk)  
  2. {  
  3.     mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);  
  4.   
  5.     spin_lock_bh(&sk->sk_lock.slock);  
  6.         //這裏會遍歷backlog隊列中的每個報文  
  7.     if (sk->sk_backlog.tail)  
  8.         __release_sock(sk);  
  9.         //這裏是網絡中斷執行時，告訴內核，如今socket並不在進程上下文中  
  10.     sk->sk_lock.owner = NULL;  
  11.     if (waitqueue_active(&sk->sk_lock.wq))  
  12.         wake_up(&sk->sk_lock.wq);  
  13.     spin_unlock_bh(&sk->sk_lock.slock);  
  14. }  

再看看__release_sock方法是如何遍歷backlog隊列的：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static void __release_sock(struct sock *sk)  
  2. {  
  3.     struct sk_buff *skb = sk->sk_backlog.head;  
  4.   
  5.         //遍歷backlog隊列  
  6.     do {  
  7.         sk->sk_backlog.head = sk->sk_backlog.tail = NULL;  
  8.         bh_unlock_sock(sk);  
  9.   
  10.         do {  
  11.             struct sk_buff *next = skb->next;  
  12.   
  13.             skb->next = NULL;  
  14.                         //處理報文，其實就是tcp_v4_do_rcv方法，上文介紹過，再也不贅述  
  15.             sk->sk_backlog_rcv(sk, skb);  
  16.   
  17.             cond_resched_softirq();  
  18.   
  19.             skb = next;  
  20.         } while (skb != NULL);  
  21.   
  22.         bh_lock_sock(sk);  
  23.     } while((skb = sk->sk_backlog.head) != NULL);  
  24. }  

此時遍歷到S3-S4報文，但由於它是失序的，因此從backlog隊列中移入out_of_order隊列中（參見上文說過的tcp_ofo_queue方法）。

八、進程休眠，直到超時或者receive隊列不爲空。

九、內核接收到了S2-S3報文。注意，這裏因爲打開了tcp_low_latency標誌位，這個報文是不會進入prequeue隊列以待進程上下文處理的。

十、此時，因爲S2是鏈接上正要接收的序號，同時，有一個用戶進程正在休眠等待接收數據中，且它要等待的數據起始序號正是S2，因而，這種種條件下，使得這一步同時也是網絡軟中斷執行上下文中，把S2-S3報文直接拷貝進用戶內存。

十一、上文介紹tcp_data_queue方法時你們能夠看到，每處理完1個有序報文（不管是拷貝到receive隊列仍是直接複製到用戶內存）後都會檢查out_of_order隊列，看看是否有報文能夠處理。那麼，S3-S4報文剛好是待處理的，因而拷貝進用戶內存。而後喚醒用戶進程。

十二、用戶進程被喚醒了，固然喚醒後會先來拿到socket鎖。如下執行又在進程上下文中了。

1三、此時會檢查已拷貝的字節數是否大於SO_RCVLOWAT，以及backlog隊列是否爲空。二者皆知足，準備返回。

1四、釋放socket鎖，退出tcp_recvmsg方法。

1五、返回用戶已經複製的字節數S4-S1。


好了，這3個場景讀完，想必你們對於TCP的接收流程是怎樣的已經很是清楚了，本文起始的6個問題也在這一大篇中都涉及到了。下一篇咱們來討論TCP鏈接的關閉。

高性能網絡編程4--TCP鏈接的關閉

標籤： tcpcloseshutdown四次握手網絡編程
2013-10-26 12:24  9907人閱讀  評論(2)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。redis

TCP鏈接的關閉有兩個方法close和shutdown，這篇文章將盡可能精簡的說明它們分別作了些什麼。
爲方便閱讀，咱們能夠帶着如下5個問題來閱讀本文：
一、當socket被多進程或者多線程共享時，關閉鏈接時有何區別？
二、關鏈接時，若鏈接上有來自對端的還未處理的消息，會怎麼處理？
三、關鏈接時，若鏈接上有本進程待發送卻將來得及發送出的消息，又會怎麼處理？
四、so_linger這個功能的用處在哪？
五、對於監聽socket執行關閉，和對處於ESTABLISH這種通信的socket執行關閉，有何區別？

下面分三部分進行：首先說說多線程多進程關閉鏈接的區別；再用一幅流程圖談談close；最後用一幅流程圖說說shutdown。

先不提其原理和實現，從多進程、多線程下 close和shutdown方法調用時的區別提及。
看看close與shutdown這兩個系統調用對應的內核函數：（參見unistd.h文件）
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. #define __NR_close                               3  
  2. __SYSCALL(__NR_close, sys_close)  
  3. #define __NR_shutdown                           48  
  4. __SYSCALL(__NR_shutdown, sys_shutdown)  

但sys_close和sys_shutdown這兩個系統調用最終是由tcp_close和tcp_shutdown方法來實現的，調用過程以下圖所示：

sys_shutdown與多線程和多進程都沒有任何關係，而sys_close則否則，上圖中能夠看到，層層封裝調用中有一個方法叫fput，它有一個引用計數，記錄這個socket被引用了多少次。在說明多線程或者多進程調用close的區別前，先在代碼上簡單看下close是怎麼調用的，對內核代碼沒興趣的同窗能夠僅看fput方法：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. void fastcall fput(struct file *file)  
  2. {  
  3.     if (atomic_dec_and_test(&file->f_count))//檢查引用計數，直到爲0纔會真正去關閉socket  
  4.         __fput(file);  
  5. }  

當這個socket的引用計數f_count不爲0時，是不會觸發到真正關閉TCP鏈接的tcp_close方法的。
那麼，這個引用計數的意義何在呢？爲了說明它，先要說道下進程與線程的區別。

你們知道，所謂線程其實就是「輕量級」的進程。建立進程只能是一個進程（父進程）建立另外一個進程（子進程），子進程會複製父進程的資源，這裏的」複製「針對不一樣的資源其意義是不一樣的，例如對內存、文件、TCP鏈接等。建立進程是由clone系統調用實現的，而建立線程時一樣也是clone實現的，只不過clone的參數不一樣，其行爲也很不一樣。這個話題是很大的，這裏咱們僅討論下TCP鏈接。
在clone系統調用中，會調用方法copy_files來拷貝文件描述符（包括socket）。建立線程時，傳入的flag參數中包含標誌位CLONE_FILES，此時，線程將會共享父進程中的文件描述符。而建立進程時沒有這個標誌位，這時，會把進程打開的全部文件描述符的引用計數加1，即把file數據結構的f_count成員加1，以下：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static int copy_files(unsigned long clone_flags, struct task_struct * tsk)  
  2. {  
  3.     if (clone_flags & CLONE_FILES) {  
  4.         goto out;//建立線程  
  5.     }  
  6.     newf = dup_fd(oldf, &error);  
  7. out:  
  8.     return error;  
  9. }  

再看看dup_fd方法：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static struct files_struct *dup_fd(struct files_struct *oldf, int *errorp)  
  2. {  
  3.     for (i = open_files; i != 0; i--) {  
  4.         struct file *f = *old_fds++;  
  5.         if (f) {  
  6.             get_file(f);//建立進程  
  7.         }  
  8.     }  
  9. }  

get_file宏就會加引用計數。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. #define get_file(x) atomic_inc(&(x)->f_count)  

因此，子進程會將父進程中已經創建的socket加上引用計數。當進程中close一個socket時，只會減小引用計數，僅當引用計數爲0時纔會觸發tcp_close。

到這裏，對於第一個問題的close調用天然有告終論：單線程（進程）中使用close與多線程中是一致的，但這二者與多進程的行爲並不一致，多進程中共享的同一個socket必須都調用了close纔會真正的關閉鏈接。

而shutdown則否則，這裏是沒有引用計數什麼事的，只要調用了就會去試圖按需關閉鏈接。因此，調用shutdown與多線程、多進程無關。


下面咱們首先深刻探討下close的行爲，由於close比較shutdown來講要複雜許多。順便回答其他四個問題。
TCP鏈接是一種雙工的鏈接，何謂雙工？即鏈接雙方能夠並行的發送或者接收消息，而無須顧及對方此時到底在發仍是收消息。這樣，關閉鏈接時，就存在3種情形：徹底關閉鏈接；關閉發送消息的功能；關閉接收消息的功能。其中，後二者就叫作半關閉，由shutdown實現（因此 shutdown多出一個參數正是控制關閉發送或者關閉接收），前者由close實現。

TCP鏈接是一種可靠的鏈接，在這裏能夠這麼理解：既要確認本機發出的包獲得確認，又要確認收到的任何消息都已告知鏈接的對端。
如下主要從雙工、可靠性這兩點上理解鏈接的關閉。

TCP雙工的這個特性使得鏈接的正常關閉須要四次握手，其含義爲：主動端關閉了發送的功能；被動端承認；被動端也關閉了發送的功能；主動端承認。
但還存在程序異常的情形，此時，則經過異常的那端發送RST復位報文通知另外一端關閉鏈接。
下圖是close的主要流程：

這個圖稍複雜，這是由於它覆蓋了關閉監聽句柄、關閉普通鏈接、關閉設置了SO_LINGER的鏈接這三種主要場景。

1）關閉監聽句柄
先從最右邊的分支說說關閉監聽socket的那些事。用於listen的監聽句柄也是使用close關閉，關閉這樣的句柄含義固然很不一樣，它自己並不對應着某個TCP鏈接，可是，附着在它之上的卻可能有半成品鏈接。什麼意思呢？以前說過TCP是雙工的，它的打開須要三次握手，三次握手也就是3個步驟，其含義爲：客戶端打開接收、發送的功能；服務器端承認並也打開接收、發送的功能；客戶端承認。當第一、2步驟完成、第3步步驟未完成時，就會在服務器上有許多半鏈接，close這個操做主要是清理這些鏈接。
參照上圖，close首先會移除keepalive定時器。keepalive功能經常使用於服務器上，防止僵死、異常退出的客戶端佔用服務器鏈接資源。移除此定時器後，若ESTABLISH狀態的TCP鏈接在tcp_keepalive_time時間（如服務器上常配置爲2小時）內沒有通信，服務器就會主動關閉鏈接。
接下來，關閉每個半鏈接。如何關閉半鏈接？這時固然不能發FIN包，即正常的四次握手關閉鏈接，而是會發送RST復位標誌去關閉請求。處理完全部半打開的鏈接close的任務就基本完成了。

2）關閉普通ESTABLISH狀態的鏈接（未設置so_linger）
首先檢查是否有接收到卻未處理的消息。
若是close調用時存在收到遠端的、沒有處理的消息，這時根據close這一行爲的意義，是要丟棄這些消息的。但丟棄消息後，意味着鏈接遠端誤覺得發出的消息已經被本機收處處理了（由於ACK包確認過了），但實際上確是收到未處理，此時也不能使用正常的四次握手關閉，而是會向遠端發送一個RST非正常復位關閉鏈接。這個作法的依據請參考draft-ietf-tcpimpl-prob-03.txt文檔3.10節， Failure to RST on close with data pending。因此，這也要求咱們程序員在關閉鏈接時，要確保已經接收、處理了鏈接上的消息。

若是此時沒有未處理的消息，那麼進入發送FIN來關閉鏈接的階段。
這時，先看看是否有待發送的消息。前一篇已經說過，發消息時要計算滑動窗口、擁塞窗口、angle算法等，這些因素可能致使消息會延遲發送的。若是有待發送的消息，那麼要盡力保證這些消息都發出去的。因此，會在最後一個報文中加入FIN標誌，同時，關閉用於減小網絡中小報文的angle算法，向鏈接對端發送消息。若是沒有待發送的消息，則構造一個報文，僅含有FIN標誌位，發送出去關閉鏈接。

3）使用了so_linger的鏈接
首先要澄清，爲什麼要有so_linger這個功能？由於咱們可能有強可靠性的需求，也就是說，必須確保發出的消息、FIN都被對方收到。例如，有些響應發出後調用close關閉鏈接，接下來就會關閉進程。若是close時發出的消息其實丟失在網絡中了，那麼，進程忽然退出時鏈接上發出的RST就可能被對方收到，並且，以前丟失的消息不會有重發來保障可靠性了。
so_linger用來保證對方收到了close時發出的消息，即，至少須要對方經過發送ACK且到達本機。
怎麼保證呢？等待！close會阻塞住進程，直到確認對方收到了消息再返回。然而，網絡環境又得複雜的，若是對方老是不響應怎麼辦？因此還須要l_linger這個超時時間，控制close阻塞進程的最長時間。注意，務必慎用so_linger，它會在不經意間下降你程序中代碼的執行速度（close的阻塞）。

因此，當這個進程設置了so_linger後，前半段依然沒變化。檢查是否有未讀消息，如有則發RST關鏈接，不會觸發等待。接下來檢查是否有未發送的消息時與第2種情形一致，設好FIN後關閉angle算法發出。接下來，則會設置最大等待時間l_linger，而後開始將進程睡眠，直到確認對方收到後纔會醒來，將控制權交還給用戶進程。

這裏須要注意，so_linger不是確保鏈接被四次握手關閉再使close返回，而只是保證我方發出的消息都已被對方收到。例如，若對方程序寫的有問題，當它收到FIN進入CLOSE_WAIT狀態，卻一直不調用close發出FIN，此時，對方仍然會經過ACK確認，我方收到了ACK進入FIN_WAIT2狀態，但沒收到對方的FIN，我方的close調用卻不會再阻塞，close直接返回，控制權交還用戶進程。

從上圖可知，so_linger還有個偏門的用法，若l_linger超時時間竟被設爲0，則不會觸發FIN包的發送，而是直接RST復位關閉鏈接。我我的認爲，這種玩法確沒多大用處。


最後作個總結。調用close時，可能致使發送RST復位關閉鏈接，例若有未讀消息、打開so_linger但l_linger卻爲0、關閉監聽句柄時半打開的鏈接。更多時會致使發FIN來四次握手關閉鏈接，但打開so_linger可能致使close阻塞住等待着對方的ACK代表收到了消息。

最後來看看較爲簡單的shutdown。

解釋下上圖：
1）shutdown可攜帶一個參數，取值有3個，分別意味着：只關閉讀、只關閉寫、同時關閉讀寫。
對於監聽句柄，若是參數爲關閉寫，顯然沒有任何意義。但關閉讀從某方面來講是有意義的，例如再也不接受新的鏈接。看看最右邊藍色分支，針對監聽句柄，若參數爲關閉寫，則不作任何事；若爲關閉讀，則把端口上的半打開鏈接使用RST關閉，與close一模一樣。
2）若shutdown的是半打開的鏈接，則發出RST來關閉鏈接。
3）若shutdown的是正常鏈接，那麼關閉讀其實與對端是沒有關係的。只要本機把接收掉的消息丟掉，其實就等價於關閉讀了，並不必定非要對端關閉寫的。實際上，shutdown正是這麼幹的。若參數中的標誌位含有關閉讀，只是標識下，當咱們調用read等方法時這個標識就起做用了，會使進程讀不到任何數據。
4）若參數中有標誌位爲關閉寫，那麼下面作的事與close是一致的：發出FIN包，告訴對方，本機不會再發消息了。


以上，就是close與shutdown的主要行爲，同時也回答了本文最初的5個問題。下一篇，咱們開始討論多路複用中常見的epoll。

高性能網絡編程5--IO複用與併發編程

標籤： epoll網絡編程高性能邊緣觸發ET
2013-12-04 15:57  13784人閱讀  評論(4)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。算法

對於服務器的併發處理能力，咱們須要的是：每一毫秒服務器都能及時處理這一毫秒內收到的數百個不一樣TCP鏈接上的報文，與此同時，可能服務器上還有數以十萬計的最近幾秒沒有收發任何報文的相對不活躍鏈接。同時處理多個並行發生事件的鏈接，簡稱爲併發；同時處理萬計、十萬計的鏈接，則是高併發。服務器的併發編程所追求的就是處理的併發鏈接數目無限大，同時維持着高效率使用CPU等資源，直至物理資源首先耗盡。

併發編程有不少種實現模型，最簡單的就是與「線程」捆綁，1個線程處理1個鏈接的所有生命週期。優勢：這個模型足夠簡單，它能夠實現複雜的業務場景，同時，線程個數是能夠遠大於CPU個數的。然而，線程個數又不是能夠無限增大的，爲何呢？由於線程何時執行是由操做系統內核調度算法決定的，調度算法並不會考慮某個線程可能只是爲了一個鏈接服務的，它會作大一統的玩法：時間片到了就執行一下，哪怕這個線程一執行就會不得不繼續睡眠。這樣來回的喚醒、睡眠線程在次數很少的狀況下，是廉價的，但若是操做系統的線程總數不少時，它就是昂貴的（被放大了），由於這種技術性的調度損耗會影響到線程上執行的業務代碼的時間。舉個例子，這時大部分擁有不活躍鏈接的線程就像咱們的國企，它們執行效率過低了，它老是喚醒就睡眠在作無用功，而它喚醒爭到CPU資源的同時，就意味着處理活躍鏈接的民企線程減小得到了CPU的機會，CPU是核心競爭力，它的無效率進而影響了GDP總吞吐量。咱們所追求的是併發處理數十萬鏈接，當幾千個線程出現時，系統的執行效率就已經沒法知足高併發了。

對高併發編程，目前只有一種模型，也是本質上惟一有效的玩法。
從這個系列的前4篇文章可知，鏈接上的消息處理，能夠分爲兩個階段：等待消息準備好、消息處理。當使用默認的阻塞套接字時（例如上面提到的1個線程捆綁處理1個鏈接），每每是把這兩個階段合而爲一，這樣操做套接字的代碼所在的線程就得睡眠來等待消息準備好，這致使了高併發下線程會頻繁的睡眠、喚醒，從而影響了CPU的使用效率。

高併發編程方法固然就是把兩個階段分開處理。即，等待消息準備好的代碼段，與處理消息的代碼段是分離的。固然，這也要求套接字必須是非阻塞的，不然，處理消息的代碼段很容易致使條件不知足時，所在線程又進入了睡眠等待階段。那麼問題來了，等待消息準備好這個階段怎麼實現？它畢竟仍是等待，這意味着線程仍是要睡眠的！解決辦法就是，線程主動查詢，或者讓1個線程爲全部鏈接而等待！
這就是IO多路複用了。多路複用就是處理等待消息準備好這件事的，但它能夠同時處理多個鏈接！它也可能「等待」，因此它也會致使線程睡眠，然而這沒關係，由於它一對多、它能夠監控全部鏈接。這樣，當咱們的線程被喚醒執行時，就必定是有一些鏈接準備好被咱們的代碼執行了，這是有效率的！沒有那麼多個線程都在爭搶處理「等待消息準備好」階段，整個世界終於清淨了！

多路複用有不少種實現，在linux上，2.4內核前主要是select和poll，如今主流是epoll，它們的使用方法彷佛很不一樣，但本質是同樣的。
效率卻也不一樣，這也是epoll徹底替代了select的緣由。

簡單的談下epoll爲什麼會替代select。
前面提到過，高併發的核心解決方案是1個線程處理全部鏈接的「等待消息準備好」，這一點上epoll和select是無爭議的。但select預估錯誤了一件事，就像咱們開篇所說，當數十萬併發鏈接存在時，可能每一毫秒只有數百個活躍的鏈接，同時其他數十萬鏈接在這一毫秒是非活躍的。select的使用方法是這樣的：
返回的活躍鏈接 ==select（所有待監控的鏈接）
何時會調用select方法呢？在你認爲須要找出有報文到達的活躍鏈接時，就應該調用。因此，調用select在高併發時是會被頻繁調用的。這樣，這個頻繁調用的方法就頗有必要看看它是否有效率，由於，它的輕微效率損失都會被「頻繁」二字所放大。它有效率損失嗎？顯而易見，所有待監控鏈接是數以十萬計的，返回的只是數百個活躍鏈接，這自己就是無效率的表現。被放大後就會發現，處理併發上萬個鏈接時，select就徹底力不從心了。

看幾個圖。當併發鏈接爲一千如下，select的執行次數不算頻繁，與epoll彷佛並沒有多少差距：

然而，併發數一旦上去，select的缺點被「執行頻繁」無限放大了，且併發數越多越明顯：

再來講說epoll是如何解決的。它很聰明的用了3個方法來實現select方法要作的事：
新建的epoll描述符==epoll_create()
epoll_ctrl(epoll描述符，添加或者刪除全部待監控的鏈接)
返回的活躍鏈接 ==epoll_wait（ epoll描述符 ）
這麼作的好處主要是：分清了頻繁調用和不頻繁調用的操做。例如，epoll_ctrl是不太頻繁調用的，而epoll_wait是很是頻繁調用的。這時，epoll_wait卻幾乎沒有入參，這比select的效率高出一大截，並且，它也不會隨着併發鏈接的增長使得入參愈加多起來，致使內核執行效率降低。

epoll是怎麼實現的呢？其實很簡單，從這3個方法就能夠看出，它比select聰明的避免了每次頻繁調用「哪些鏈接已經處在消息準備好階段」的 epoll_wait時，是不須要把全部待監控鏈接傳入的。這意味着，它在內核態維護了一個數據結構保存着全部待監控的鏈接。這個數據結構就是一棵紅黑樹，它的結點的增長、減小是經過epoll_ctrl來完成的。用我在《深刻理解Nginx》第8章中所畫的圖來看，它是很是簡單的：

圖中左下方的紅黑樹由全部待監控的鏈接構成。左上方的鏈表，同是目前全部活躍的鏈接。因而，epoll_wait執行時只是檢查左上方的鏈表，並返回左上方鏈表中的鏈接給用戶。這樣，epoll_wait的執行效率能不高嗎？

最後，再看看epoll提供的2種玩法ET和LT，即翻譯過來的邊緣觸發和水平觸發。其實這兩個中文名字倒也有些貼切。這2種使用方式針對的仍然是效率問題，只不過變成了epoll_wait返回的鏈接如何可以更準確些。
例如，咱們須要監控一個鏈接的寫緩衝區是否空閒，知足「可寫」時咱們就能夠從用戶態將響應調用write發送給客戶端 。可是，或者鏈接可寫時，咱們的「響應」內容還在磁盤上呢，此時如果磁盤讀取還未完成呢？確定不能使線程阻塞的，那麼就不發送響應了。可是，下一次epoll_wait時可能又把這個鏈接返回給你了，你還得檢查下是否要處理。可能，咱們的程序有另外一個模塊專門處理磁盤IO，它會在磁盤IO完成時再發送響應。那麼，每次epoll_wait都返回這個「可寫」的、卻沒法馬上處理的鏈接，是否符合用戶預期呢？

因而，ET和LT模式就應運而生了。LT是每次知足期待狀態的鏈接，都得在epoll_wait中返回，因此它一視同仁，都在一條水平線上。ET則否則，它傾向更精確的返回鏈接。在上面的例子中，鏈接第一次變爲可寫後，如果程序未向鏈接上寫入任何數據，那麼下一次epoll_wait是不會返回這個鏈接的。ET叫作 邊緣觸發，就是指，只有鏈接從一個狀態轉到另外一個狀態時，纔會觸發epoll_wait返回它。可見，ET的編程要複雜很多，至少應用程序要當心的防止epoll_wait的返回的鏈接出現：可寫時未寫數據後卻期待下一次「可寫」、可讀時未讀盡數據卻期待下一次「可讀」。

固然，從通常應用場景上它們性能是不會有什麼大的差距的，ET可能的優勢是，epoll_wait的調用次數會減小一些，某些場景下鏈接在沒必要要喚醒時不會被喚醒（此喚醒指epoll_wait返回）。但若是像我上面舉例所說的，有時它不單純是一個網絡問題，跟應用場景相關。固然，大部分開源框架都是基於ET寫的，框架嘛，它追求的是純技術問題，固然力求盡善盡美。

高性能網絡編程6--reactor反應堆與定時器管理

標籤： 網絡編程反應堆定時器redislibevent
2013-12-20 19:37  10841人閱讀  評論(7)  收藏  舉報
  分類：
 

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。編程

反應堆開發模型被絕大多數高性能服務器所選擇，上一篇所介紹的IO多路複用是它的實現基礎。定時觸發功能一般是服務器必備組件，反應堆模型每每還不得不將定時器的管理囊括在內。本篇將介紹反應堆模型的特色和用法。

首先咱們要談談，網絡編程界爲何須要反應堆？有了IO複用，有了epoll，咱們已經能夠使服務器併發幾十萬鏈接的同時，維持高TPS了，難道這還不夠嗎？
個人答案是，技術層面足夠了，但在軟件工程層面倒是不夠的。
程序使用IO複用的難點在哪裏呢？1個請求雖然由屢次IO處理完成，但相比傳統的單線程完整處理請求生命期的方法，IO複用在人的大腦思惟中並不天然，由於，程序員編程中，處理請求A的時候，假定A請求必須通過多個IO操做A1-An（兩次IO間可能間隔很長時間），每通過一次IO操做，再調用IO複用時，IO複用的調用返回裏，很是可能再也不有A，而是返回了請求B。即請求A會常常被請求B打斷，處理請求B時，又被C打斷。這種思惟下，編程容易出錯。
形象的說，傳統編程方法就好像是到了銀行營業廳裏，每一個窗口前排了長隊，業務員們在窗口後一個個的解決客戶們的請求。一個業務員能夠盡情思考着客戶A依次提出的問題，例如：
「我要買2萬XX理財產品。「
「看清楚了，5萬起售。」
「等等，查下我活期餘額。」
「餘額5萬。」
「那就買 5萬吧。」
業務員開始錄入信息。
」對了，XX理財產品年利率8%？」
「是預期8%，最低無利息保本。「
」早不說，拜拜，我去買餘額寶。「
業務員無表情的刪着已經錄入的信息進行事務回滾。
」下一個！「

用了IO複用則是大師業務員開始挑戰極限，在超大營業廳裏給客戶們人手一個牌子，黑壓壓的客戶們都在大廳中，有問題時舉牌申請提問，大師目光敏銳點名指定某人提問，該客戶迅速獲得大師的答覆後，要通過一段時間思考，查查本身的銀袋子，諮詢下LD，才能再次進行下一個提問，直到獲得完整的滿意答覆退出大廳。例如：大師剛指導A填寫轉賬單的某一項，B又來申請兌換泰銖，給了B兌換單後，C又來辦理定轉活，而後D與F在爭搶有限的圓珠筆時出現了不和諧現象，被大師叫停業務，暫時等待。
這就是基於事件驅動的IO複用編程比起傳統1線程1請求的方式來，有難度的設計點了，客戶們都是上帝，既不能出錯，還不能厚此薄彼。

當沒有反應堆時，咱們可能的設計方法是這樣的：大師把每一個客戶的提問都記錄下來，當客戶A提問時，首先查閱A以前問過什麼作過什麼，這叫聯繫上下文，而後再根據上下文和當前提問查閱有關的銀行規章制度，有針對性的回答A，並把回答也記錄下來。當圓滿回答了A的全部問題後，刪除A的全部記錄。

回到碼農生涯，即，某一瞬間，服務器共有10萬個併發鏈接，此時，一次IO複用接口的調用返回了100個活躍的鏈接等待處理。先根據這100個鏈接找出其對應的對象，這並不難，epoll的返回鏈接數據結構裏就有這樣的指針能夠用。接着，循環的處理每個鏈接，找出這個對象此刻的上下文狀態，再使用read、write這樣的網絡IO獲取這次的操做內容，結合上下文狀態查詢此時應當選擇哪一個業務方法處理，調用相應方法完成操做後，若請求結束，則刪除對象及其上下文。

這樣，咱們就陷入了面向過程編程方法之中了，在面向應用、快速響應爲王的移動互聯網時代，這樣作遲早得把本身玩死。咱們的主程序須要關注各類不一樣類型的請求，在不一樣狀態下，對於不一樣的請求命令選擇不一樣的業務處理方法。這會致使隨着請求類型的增長，請求狀態的增長，請求命令的增長，主程序複雜度快速膨脹，致使維護愈來愈困難，苦逼的程序員不再敢輕易接新需求、重構。

反應堆是解決上述軟件工程問題的一種途徑，它也許並不優雅，開發效率上也不是最高的，但其執行效率與面向過程的使用IO複用卻幾乎是等價的，因此，不管是nginx、memcached、redis等等這些高性能組件的代名詞，都義無反顧的一頭扎進了反應堆的懷抱中。
反應堆模式能夠在軟件工程層面，將事件驅動框架分離出具體業務，將不一樣類型請求之間用OO的思想分離。一般，反應堆不只使用IO複用處理網絡事件驅動，還會實現定時器來處理時間事件的驅動（請求的超時處理或者定時任務的處理），就像下面的示意圖：

這幅圖有5點意思：
（1）處理應用時基於OO思想，不一樣的類型的請求處理間是分離的。例如，A類型請求是用戶註冊請求，B類型請求是查詢用戶頭像，那麼當咱們把用戶頭像新增多種分辨率圖片時，更改B類型請求的代碼處理邏輯時，徹底不涉及A類型請求代碼的修改。

（2）應用處理請求的邏輯，與事件分發框架徹底分離。什麼意思呢？即寫應用處理時，不用去管什麼時候調用IO複用，不用去管什麼調用epoll_wait，去處理它返回的多個socket鏈接。應用代碼中，只關心如何讀取、發送socket上的數據，如何處理業務邏輯。事件分發框架有一個抽象的事件接口，全部的應用必須實現抽象的事件接口，經過這種抽象才把應用與框架進行分離。

（3）反應堆上提供註冊、移除事件方法，供應用代碼使用，而分發事件方法，一般是循環的調用而已，是否提供給應用代碼調用，仍是由框架簡單粗暴的直接循環使用，這是框架的自由。

（4）IO多路複用也是一個抽象，它能夠是具體的select，也能夠是epoll，它們只必須提供採集到某一瞬間全部待監控鏈接中活躍的鏈接。

（5）定時器也是由反應堆對象使用，它必須至少提供4個方法，包括添加、刪除定時器事件，這該由應用代碼調用。最近超時時間是須要的，這會被反應堆對象使用，用於確認select或者epoll_wait執行時的阻塞超時時間，防止IO的等待影響了定時事件的處理。遍歷也是由反應堆框架使用，用於處理定時事件。

下面用極簡流程來形象說明下反應堆是如何處理一個請求的，下圖中桔色部分皆爲反應堆的分發事件流程：

能夠看到，分發IO、定時器事件都由反應堆框架來完成，應用代碼只會關注於如何處理可讀、可寫事件。
固然，上圖是極度簡化的流程，實際上要處理的異常狀況都沒有列入。

這裏能夠看到，爲何定時器集合須要提供最近超時事件距離如今的時間？由於，調用epoll_wait或者select時，並不可以始終傳入-1做爲timeout參數。由於，咱們的服務器主營業務每每是網絡請求處理，若是網絡請求不多時，那麼CPU的全部時間都會被頻繁卻又沒必要要的epoll_wait調用所佔用。在服務器閒時使進程的CPU利用率下降是頗有意義的，它能夠使服務器上其餘進程獲得更多的執行機會，也能夠延長服務器的壽命，還能夠省電。這樣，就須要傳入準確的timeout最大阻塞時間給epoll_wait了。

什麼樣的timeout時間纔是準確的呢？這等價於，咱們須要準確的分析，什麼樣的時段進程能夠真正休息，進入sleep狀態？
一個沒有意義的答案是：不須要進程執行任務的時間段內是能夠休息的。
這就要求咱們仔細想一想，進程作了哪幾類任務，例如：
一、全部網絡包的處理，例如TCP鏈接的創建、讀寫、關閉，基本上全部的正常請求都由網絡包來驅動的。對這類任務而言，沒有新的網絡分組到達本機時，就是能夠使進程休息的時段。
二、定時器的管理，它與網絡、IO複用無關，雖然它們在業務上可能有相關性。定時器裏的事件須要及時的觸發執行，不能由於其餘緣由，例如阻塞在epoll_wait上時耽誤了定時事件的處理。當一段時間內，能夠預判沒有定時事件達到觸發條件時（這也是提供接口查詢最近一個定時事件距當下的時間的意義所在），對定時任務的管理而言，進程就能夠休息了。
三、其餘類型的任務，例如磁盤IO執行完成，或者收到其餘進程的signal信號，等等，這些任務明顯不須要執行的時間段內，進程能夠休息。

因而，使用反應堆模型的進程代碼中，一般除了epoll_wait這樣的IO複用外，其餘調用都會基於無阻塞的方式使用。因此，epoll_wait的timeout超時時間，就是除網絡外，其餘任務所能容許的進程睡眠時間。而只考慮常見的定時器任務時，就像上圖中那樣，只須要定時器集合可以提供最近超時事件到如今的時間便可。

從這裏也能夠推導出，定時器集合一般會採用有序容器這樣的數據結構，好處是：
一、容易取到最近超時事件的時間。
二、能夠從最近超時事件開始，向後依次遍歷已經超時的事件，直到第一個沒有超時的事件爲止便可中止遍歷，不用所有遍歷到。

所以，粗暴的採用無序的數據結構，例如普通的鏈表，一般是不足取的。但事無絕對，redis就是用了個毫無順序的鏈表，緣由何在？由於redis的客戶端鏈接沒有超時概念，因此對於併發的成千上萬個連上，都不會由於超時被斷開。redis的定時器惟一的用途在於定時的將內存數據刷到磁盤上，這樣的定時事件一般只有個位數，其性能可有可無。

若是定時事件很是多，綜合插入、遍歷、刪除的使用頻率，使用樹的機會最多，例如小根堆（libevent）、二叉平衡樹（nginx紅黑樹）。固然，場景特殊時，盡能夠用有序數組、跳躍表等等實現。


綜上所述，反應堆模型開發效率上比起直接使用IO複用要高，它一般是單線程的，設計目標是但願單線程使用一顆CPU的所有資源，但也有附帶優勢，即每一個事件處理中不少時候能夠不考慮共享資源的互斥訪問。但是缺點也是明顯的，如今的硬件發展，已經再也不遵循摩爾定律，CPU的頻率受制於材料的限制再也不有大的提高，而改成是從核數的增長上提高能力，當程序須要使用多核資源時，反應堆模型就會悲劇，爲什麼呢？
若是程序業務很簡單，例如只是簡單的訪問一些提供了併發訪問的服務，就能夠直接開啓多個反應堆，每一個反應堆對應一顆CPU核心，這些反應堆上跑的請求互不相關，這是徹底能夠利用多核的。例如Nginx這樣的http靜態服務器。
若是程序比較複雜，例如一塊內存數據的處理但願由多核共同完成，這樣反應堆模型就很難作到了，須要昂貴的代價，引入許多複雜的機制。因此，你們就能夠理解像redis、nodejs這樣的服務，爲何只能是單線程，爲何memcached簡單些的服務確能夠是多線程。

  

高性能網絡編程7--tcp鏈接的內存使用

標籤： tcpmemorykernel緩存linux
2014-01-23 17:47  15540人閱讀  評論(19)  收藏  舉報
  分類：
 
 

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。數組

當服務器的併發TCP鏈接數以十萬計時，咱們就會對一個TCP鏈接在操做系統內核上消耗的內存多少感興趣。socket編程方法提供了SO_SNDBUF、SO_RCVBUF這樣的接口來設置鏈接的讀寫緩存，linux上還提供瞭如下系統級的配置來總體設置服務器上的TCP內存使用，但這些配置看名字卻有些互相沖突、概念模糊的感受，以下（sysctl -a命令能夠查看這些配置）：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. net.ipv4.tcp_rmem = 8192 87380 16777216  
  2. net.ipv4.tcp_wmem = 8192 65536 16777216  
  3. net.ipv4.tcp_mem = 8388608 12582912 16777216  
  4. net.core.rmem_default = 262144  
  5. net.core.wmem_default = 262144  
  6. net.core.rmem_max = 16777216  
  7. net.core.wmem_max = 16777216  

還有一些較少被說起的、也跟TCP內存相關的配置：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. net.ipv4.tcp_moderate_rcvbuf = 1  
  2. net.ipv4.tcp_adv_win_scale = 2  

（注：爲方便下文講述，介紹以上系統配置時前綴省略掉，配置值以空格分隔的多個數字以數組來稱呼，例如tcp_rmem[2]表示上面第一行最後一列16777216。）

網上能夠找到不少這些系統配置項的說明，然而每每仍是讓人費解，例如，tcp_rmem[2]和rmem_max彷佛都跟接收緩存最大值有關，但它們卻能夠不一致，究竟有什麼區別？或者tcp_wmem[1]和wmem_default彷佛都表示發送緩存的默認值，衝突了怎麼辦？在用抓包軟件抓到的syn握手包裏，爲何TCP接收窗口大小彷佛與這些配置徹底不要緊？

TCP鏈接在進程中使用的內存大小變幻無窮，一般程序較複雜時可能不是直接基於socket編程，這時平臺級的組件可能就封裝了TCP鏈接使用到的用戶態內存。不一樣的平臺、組件、中間件、網絡庫都大不相同。而內核態爲TCP鏈接分配內存的算法則是基本不變的，這篇文章將試圖說明TCP鏈接在內核態中會使用多少內存，操做系統使用怎樣的策略來平衡宏觀的吞吐量與微觀的某個鏈接傳輸速度。這篇文章也將一如既往的面向應用程序開發者，而不是系統級的內核開發者，因此，不會詳細的介紹爲了一個TCP鏈接、一個TCP報文操做系統分配了多少字節的內存，內核級的數據結構也不是本文的關注點，這些也不是應用級程序員的關注點。這篇文章主要描述linux內核爲了TCP鏈接上傳輸的數據是怎樣管理讀寫緩存的。


1、緩存上限是什麼？

（1）先從應用程序編程時能夠設置的 SO_SNDBUF、SO_RCVBUF提及。

不管何種語言，都對TCP鏈接提供基於setsockopt方法實現的 SO_SNDBUF、SO_RCVBUF，怎麼理解這兩個屬性的意義呢？
SO_SNDBUF、SO_RCVBUF都是個體化的設置，即，只會影響到設置過的鏈接，而不會對其餘鏈接生效。 SO_SNDBUF表示這個鏈接上的內核寫緩存上限。實際上，進程設置的SO_SNDBUF也並非真的上限，在內核中會把這個值翻一倍再做爲寫緩存上限使用，咱們不須要糾結這種細節，只須要知道，當設置了 SO_SNDBUF時，就至關於劃定了所操做的TCP鏈接上的寫緩存可以使用的最大內存。然而，這個值也不是能夠由着進程隨意設置的，它會受制於系統級的上下限，當它大於上面的系統配置wmem_max（ net.core.wmem_max ）時，將會被wmem_max替代（一樣翻一倍）；而當它特別小時，例如在2.6.18內核中設計的寫緩存最小值爲2K字節，此時也會被直接替代爲2K。

SO_RCVBUF表示鏈接上的讀緩存上限，與SO_SNDBUF相似，它也受制於rmem_max配置項，實際在內核中也是2倍大小做爲讀緩存的使用上限。SO_RCVBUF設置時也有下限，一樣在2.6.18內核中若這個值小於256字節就會被256所替代。


（2）那麼，能夠設置的 SO_SNDBUF、SO_RCVBUF 緩存使用上限與實際內存到底有怎樣的關係呢？

TCP鏈接所用內存主要由讀寫緩存決定，而讀寫緩存的大小隻與實際使用場景有關，在實際使用未達到上限時， SO_SNDBUF、SO_RCVBUF是不起任何做用的。對讀緩存來講，接收到一個來自鏈接對端的TCP報文時，會致使讀緩存增長，固然，若是加上報文大小後讀緩存已經超過了讀緩存上限，那麼這個報文會被丟棄從而讀緩存大小維持不變。何時讀緩存使用的內存會減小呢？當進程調用read、recv這樣的方法讀取TCP流時，讀緩存就會減小。所以，讀緩存是一個動態變化的、實際用到多少才分配多少的緩衝內存，當這個鏈接很是空閒時，且用戶進程已經把鏈接上接收到的數據都消費了，那麼讀緩存使用內存就是0。

寫緩存也是一樣道理。當用戶進程調用send或者write這樣的方法發送TCP流時，就會形成寫緩存增大。固然，若是寫緩存已經到達上限，那麼寫緩存維持不變，向用戶進程返回失敗。而每當接收到TCP鏈接對端發來的ACK確認了報文的成功發送時，寫緩存就會減小，這是由於TCP的可靠性決定的，發出去報文後因爲擔憂報文丟失而不會銷燬它，可能會由重發定時器來重發報文。所以，寫緩存也是動態變化的，空閒的正常鏈接上，寫緩存所用內存一般也爲0。

所以，只有當接收網絡報文的速度大於應用程序讀取報文的速度時，可能使讀緩存達到了上限，這時這個緩存使用上限纔會起做用。所起做用爲：丟棄掉新收到的報文，防止這個TCP鏈接消耗太多的服務器資源。一樣，當應用程序發送報文的速度大於接收對方確認ACK報文的速度時，寫緩存可能達到上限，從而使send這樣的方法失敗，內核不爲其分配內存。


2、緩存的大小與TCP的滑動窗口到底有什麼關係？

（1） 滑動窗口的大小與緩存大小確定是有關的，但卻不是一一對應的關係，更不會與緩存上限具備一一對應的關係。所以，網上不少資料介紹rmem_max等配置設置了滑動窗口的最大值，與咱們tcpdump抓包時看到的win窗口值徹底不一致，是講得通的。下面咱們來細探其分別在哪裏。

讀緩存的做用有2個：一、將無序的、落在接收滑動窗口內的TCP報文緩存起來；二、當有序的、能夠供應用程序讀取的報文出現時，因爲應用程序的讀取是延時的，因此會把待應用程序讀取的報文也保存在讀緩存中。因此，讀緩存一分爲二，一部分緩存無序報文，一部分緩存待延時讀取的有序報文。 這兩部分緩存大小之和因爲受制於同一個上限值，因此它們是會互相影響的，當應用程序讀取速率過慢時，這塊過大的應用緩存將會影響到套接字緩存，使接收滑動窗口縮小，從而通知鏈接的對端下降發送速度，避免無謂的網絡傳輸。當應用程序長時間不讀取數據，形成應用緩存將套接字緩存擠壓到沒空間，那麼鏈接對端會收到接收窗口爲0的通知，告訴對方：我如今消化不了更多的報文了。

反之，接收滑動窗口也是一直在變化的，咱們用tcpdump抓三次握手的報文：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. 14:49:52.421674 IP houyi-vm02.dev.sd.aliyun.com.6400 > r14a02001.dg.tbsite.net.54073: S 2736789705:2736789705(0) ack 1609024383 win 5792 <mss 1460,sackOK,timestamp 2925954240 2940689794,nop,wscale 9>  

能夠看到初始的接收窗口是5792，固然也遠小於最大接收緩存（稍後介紹的tcp_rmem[1]）。
這固然是有緣由的，TCP協議須要考慮複雜的網絡環境，因此使用了慢啓動、擁塞窗口（參見 高性能網絡編程2----TCP消息的發送 ），創建鏈接時的初始窗口並不會按照接收緩存的最大值來初始化。這是由於，過大的初始窗口從宏觀角度，對整個網絡可能形成過載引起惡性循環，也就是考慮到鏈路上各環節的諸多路由器、交換機可能扛不住壓力不斷的丟包（特別是廣域網），而微觀的TCP鏈接的雙方卻只按照本身的讀緩存上限做爲接收窗口，這樣雙方的發送窗口（對方的接收窗口）越大就對網絡產生越壞的影響。慢啓動就是使初始窗口儘可能的小，隨着接收到對方的有效報文，確認了網絡的有效傳輸能力後，纔開始增大接收窗口。

不一樣的linux內核有着不一樣的初始窗口，咱們以廣爲使用的linux2.6.18內核爲例，在以太網裏，MSS大小爲1460，此時初始窗口大小爲4倍的MSS，簡單列下代碼（ *rcv_wnd即初始接收窗口 ）：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. int init_cwnd = 4;  
  2. if (mss > 1460*3)  
  3.  init_cwnd = 2;  
  4. else if (mss > 1460)  
  5.  init_cwnd = 3;  
  6. if (*rcv_wnd > init_cwnd*mss)  
  7.  *rcv_wnd = init_cwnd*mss;  

你們可能要問，爲什麼上面的抓包上顯示窗口實際上是5792，並非1460*4爲5840呢？這是由於1460想表達的意義是：將1500字節的MTU去除了20字節的IP頭、20字節的TCP頭之後，一個最大報文可以承載的有效數據長度。但有些網絡中，會在TCP的可選頭部裏，使用12字節做爲時間戳使用，這樣，有效數據就是MSS再減去12，初始窗口就是（1460-12）*4=5792，這與窗口想表達的含義是一致的，即：我可以處理的有效數據長度。

在linux3之後的版本中，初始窗口調整到了10個MSS大小，這主要來自於GOOGLE的建議。緣由是這樣的，接收窗口雖然常以指數方式來快速增長窗口大小（擁塞閥值如下是指數增加的，閥值以上進入擁塞避免階段則爲線性增加，並且，擁塞閥值自身在收到128以上數據報文時也有機會快速增長），如果傳輸視頻這樣的大數據，那麼隨着窗口增長到 （接近） 最大讀緩存後，就會「開足馬力」傳輸數據，但如果一般都是幾十KB的網頁，那麼太小的初始窗口尚未增長到合適的窗口時，鏈接就結束了。這樣相比較大的初始窗口，就使得用戶須要更多的時間（RTT）才能傳輸完數據，體驗很差。

那麼這時你們可能有疑問，當窗口從初始窗口一路擴張到最大接收窗口時，最大接收窗口就是最大讀緩存嗎？
不是，由於必須分一部分緩存用於應用程序的延時報文讀取。到底會分多少出來呢？這是可配的系統選項，以下：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. net.ipv4.tcp_adv_win_scale = 2  

這裏的 tcp_adv_win_scale意味着，將要拿出1/(2^ tcp_adv_win_scale )緩存出來作應用緩存。即，默認 tcp_adv_win_scale配置爲2時，就是拿出至少1/4的內存用於應用讀緩存，那麼，最大的接收滑動窗口的大小隻能到達讀緩存的3/4。


（2）最大讀緩存到底應該設置到多少爲合適呢？

當應用緩存所佔的份額經過 tcp_adv_win_scale配置肯定後，讀緩存的上限應當由最大的TCP接收窗口決定。初始窗口可能只有4個或者10個MSS，但在無丟包情形下隨着報文的交互窗口就會增大，當窗口過大時，「過大」是什麼意思呢？即，對於通信的兩臺機器的內存而言不算大，可是對於整個網絡負載來講過大了，就會對網絡設備引起惡性循環，不斷的由於繁忙的網絡設備形成丟包。而窗口太小時，就沒法充分的利用網絡資源。因此，通常會以BDP來設置最大接收窗口（可計算出最大讀緩存）。BDP叫作帶寬時延積，也就是帶寬與網絡時延的乘積，例如若咱們的帶寬爲2Gbps，時延爲10ms，那麼帶寬時延積BDP則爲2G/8*0.01=2.5MB，因此這樣的網絡中能夠設最大接收窗口爲2.5MB，這樣最大讀緩存能夠設爲4/3*2.5MB=3.3MB。

爲何呢？由於BDP就表示了網絡承載能力，最大接收窗口就表示了網絡承載能力內能夠不經確認發出的報文。以下圖所示：

常常說起的所謂長肥網絡，「長」就是是時延長，「肥」就是帶寬大，這二者任何一個大時，BDP就大，都應致使最大窗口增大，進而致使讀緩存上限增大。因此在長肥網絡中的服務器，緩存上限都是比較大的。（固然，TCP原始的16位長度的數字表示窗口雖然有上限，但在RFC1323中定義的彈性滑動窗口使得滑動窗口能夠擴展到足夠大。）

發送窗口實際上就是TCP鏈接對方的接收窗口，因此你們能夠按接收窗口來推斷，這裏再也不囉嗦。


3、linux的TCP緩存上限自動調整策略
那麼，設置好最大緩存限制後就高枕無憂了嗎？對於一個TCP鏈接來講，可能已經充分利用網絡資源，使用大窗口、大緩存來保持高速傳輸了。好比在長肥網絡中，緩存上限可能會被設置爲幾十兆字節，但系統的總內存倒是有限的，當每個鏈接都全速飛奔使用到最大窗口時，1萬個鏈接就會佔用內存到幾百G了，這就限制了高併發場景的使用，公平性也得不到保證。咱們但願的場景是，在併發鏈接比較少時，把緩存限制放大一些，讓每個TCP鏈接開足馬力工做；當併發鏈接不少時，此時系統內存資源不足，那麼就把緩存限制縮小一些，使每個TCP鏈接的緩存儘可能的小一些，以容納更多的鏈接。

linux爲了實現這種場景，引入了自動調整內存分配的功能，由 tcp_moderate_rcvbuf配置決定，以下：
net.ipv4.tcp_moderate_rcvbuf = 1
默認 tcp_moderate_rcvbuf配置爲1，表示打開了TCP內存自動調整功能。若配置爲0，這個功能將不會生效（慎用）。

另外請注意：當咱們在編程中對鏈接設置了 SO_SNDBUF、SO_RCVBUF，將會使linux內核再也不對這樣的鏈接執行自動調整功能！

那麼，這個功能究竟是怎樣起做用的呢？看如下配置：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. net.ipv4.tcp_rmem = 8192 87380 16777216  
  2. net.ipv4.tcp_wmem = 8192 65536 16777216  
  3. net.ipv4.tcp_mem = 8388608 12582912 16777216  

tcp_rmem[3]數組表示任何一個TCP鏈接上的讀緩存上限，其中 tcp_rmem[0]表示最小上限， tcp_rmem[1]表示初始上限（注意，它會覆蓋適用於全部協議的rmem_default配置）， tcp_rmem[2]表示最大上限。
tcp_wmem[3]數組表示寫緩存，與 tcp_rmem[3]相似，再也不贅述。

tcp_mem[3]數組就用來設定TCP內存的總體使用情況，因此它的值很大（它的單位也不是字節，而是頁--4K或者8K等這樣的單位！）。這3個值定義了TCP總體內存的無壓力值、壓力模式開啓閥值、最大使用值。以這3個值爲標記點則內存共有4種狀況：

一、當TCP總體內存小於tcp_mem[0]時，表示系統內存整體無壓力。若以前內存曾經超過了tcp_mem[1]使系統進入內存壓力模式，那麼此時也會把壓力模式關閉。
這種狀況下，只要TCP鏈接使用的緩存沒有達到上限（注意，雖然初始上限是 tcp_rmem[1]，但這個值 是可變的，下文會詳述），那麼新內存的分配必定是成功的。

二、當TCP內存在 tcp_mem[0]與 tcp_mem[1]之間時，系統可能處於內存壓力模式，例如總內存剛從 tcp_mem[1]之上下來； 也多是在非壓力模式下，例如總內存剛從 tcp_mem[0]如下上來。
此時，不管是否在壓力模式下，只要TCP鏈接所用緩存未超過 tcp_rmem[0]或者 tcp_wmem[0]，那麼都必定都能成功分配新內存。不然，基本上就會面臨分配失敗的情況。（注意：還有一些例外場景容許分配內存成功，因爲對於咱們理解這幾個配置項意義不大，故略過。）

三、當TCP內存在 tcp_mem[1]與 tcp_mem[2]之間時，系統必定處於系統壓力模式下。其餘行爲與上同。

四、當TCP內存在 tcp_mem[2]之上時，毫無疑問，系統必定在壓力模式下，並且此時全部的新TCP緩存分配都會失敗。

下圖爲須要新緩存時內核的簡化邏輯：

當系統在非壓力模式下，上面我所說的每一個鏈接的讀寫緩存上限，纔有可能增長，固然最大也不會超過 tcp_rmem[2]或者 tcp_wmem[2]。相反，在壓力模式下，讀寫緩存上限則有可能減小，雖然上限可能會小於 tcp_rmem[0]或者 tcp_wmem[0] 。

因此，粗略的總結下，對這3個數組能夠這麼看：
一、只要系統TCP的整體內存超了  tcp_mem[2]  ，新內存分配都會失敗。
二、tcp_rmem[0]或者tcp_wmem[0]優先級也很高，只要條件1不超限，那麼只要鏈接內存小於這兩個值，就保證新內存分配必定成功。
三、只要整體內存不超過tcp_mem[0]，那麼新內存在不超過鏈接緩存的上限時也能保證分配成功。
四、tcp_mem[1]與tcp_mem[0]構成了開啓、關閉內存壓力模式的開關。在壓力模式下，鏈接緩存上限可能會減小。在非壓力模式下，鏈接緩存上限可能會增長，最多增長到 tcp_rmem[2]或者 tcp_wmem[2]。

做者所屬大學Baylor的網站，在相關的頁面上提供了下載。

http://cs.ecs.baylor.edu/~donahoo/practical/CSockets2/textcode.html

後來發現這篇日誌訪問挺高的，乾脆本身打個包放上來了。

http://files.cnblogs.com/wuyuegb2312/Sockets%E7%BC%96%E7%A8%8B%E6%BA%90%E7%A0%81.rar

初學Sockets編程(一) 基本的TCP套接字

　　前段時間剛開始學習《TCP/IP Sockets編程(C語言實現) (第2版)》一書，又被告知建議先去看一下《UNIX網絡編程(第一卷)》的部份內容會對理解其理論知識有所幫助，因而稍微停滯了一下。幾天前所練習的實例已經有所生疏，所以爲了複習這部份內容（前面所提起的第一本書第2章），此文便做爲複習筆記（書本關鍵內容摘錄），而之後各章節的學習也但願能作到及時總結和複習。

　　本章示例的工做方式：客戶鏈接服務器併發送它的數據；服務器簡單地把它接收到的任何內容發送回客戶並斷開鏈接。


1.典型的TCP客戶的通訊步驟

⑴使用socket()建立TCP套接字

　　參數涉及地址族、使用的協議，正確建立返回一個句柄。

⑵使用connect()創建到達服務器的鏈接

　　參數涉及套接字句柄、服務器的地址結構中的地址和端口標識，其中地址結構須要強制轉換爲泛型類型。

⑶使用send()和recv()通訊

　　send()參數涉及套接字句柄、發送內容、發送長度；返回值爲發送的字節數，錯誤返回爲-1。

　　recv()參數涉及套接字句柄、接收緩衝區、緩衝區大小、調用方式；返回值爲接受的字節數，返回0表示另外一端應用程序關閉了TCP鏈接，返回-1表示失敗。

⑷使用close()關閉鏈接


示例爲以前提供的下載頁面的TCPEchoClient4.c。


2.基本的TCP服務器通訊的常規步驟

⑴使用socket()建立TCP套接字

⑵利用bind()給套接字分配端口號

參數涉及套接字句柄、服務器的本機地址結構中的地址和端口標識，其中地址結構須要強制轉換爲泛型類型，若是不是很是關心所在地址能夠用inaddr_any。

⑶使用listen()告訴系統容許對該端口創建鏈接

　　參數涉及套接字句柄、最大容許鏈接數。

⑷反覆執行如下操做

  • 調用accept()爲每一個客戶鏈接獲取新的套接字

　　參數涉及以前的套接字句柄，建立成功後即將填寫的本機地址結構，該地址結構的長度，其中地址結構須要強制轉換爲泛型類型，返回一個新套接字的句柄。

  • 使用send()和recv()經過新的套接字與客戶通訊
  • 使用close()關閉客戶鏈接


示例爲以前提供的下載頁面的TCPEchoServer4.c以及TCPServerUtility.c中的HandleTCPClient()。


3.指定地址

 

⑴通用地址

struct sockaddr { 　　sa_family_t sa_family; //Address family (e.g.，AF_INET) 　　char sa_data[14]; };　　

⑵IPv4地址

 

複製代碼 
struct in_addr {
　　uint32_t s_addr;
};

　　struct sockaddr_in {
　　sa_family_t sin_family;　　//Internet protocol  (AF_INET)
　　in_port_t sin_port;　　　　//Address port　　　(16bits)
　　struct in_addr sin_addr;　//IPv4 address　　　 (32bits)
　　char sin_zero[8];　　　　//Not used
};
複製代碼

　　⑶IPv6地址（已按照上一篇文章更改）

複製代碼 
struct in_addr {
　　uint8_t s_addr[16];//Internet address(128bits)
};
struct sockaddr_in6 {
　　sa_family_t sin6_family;　　//Internet protocol(AF_INET6)
　　in_port_t sin6_port;　　　　//Address port(16bits)
　　uint32_t sin6_flowinfo;　　//Flow information
　　struct in6_addr sin6_addr;//IPv6 address (128bits)
　　uint32_t sin6_scope_id;　　//Scope identifier
};
複製代碼

　　⑷地址轉換

int inet_pton(int addressFamily, constchar*src , void*dst)
//把地址從可打印的字符串(*src)轉換爲數字(dst引用的地址)

constchar*inet_ntop(int addressFamily, constvoid*src, char*dst,socklen_t dstBytes)
//把地址從數字轉化爲可打印的形式

　　⑸獲取套接字的關聯地址

int getpeername(int socket, struct sockaddr *remoteAddress, socklen_t (addressLength)
int getsockname(int socket, struct sockaddr (localAddress, socklen_t (addressLength)

　　4.其餘

　　爲了便於在同一臺計算機的終端上進行調試，須要先在後臺執行服務器程序（參數等全部內容的最後面加一個&），再執行客戶機程序，發送到127.0.0.1便可。相關調試時用到的進程操做還有ps(查看當前運行進程)、kill（關閉進程）。

初學Sockets編程(二) 關於名稱和地址族

　　這一章的核心內容是getaddrinfo()函數。

　

int getaddrinfo(constchar*hostStr, constchar* serviceStr, conststruct addrinfo *hints, 
struct addrinfo **results)
//須要配合下面函數進行使用
void freeaddrinfo(struct addrinfo *addrList) //釋放建立的結果鏈表
const char *gai_strerror(int errorCode) //若是getaddrinfo返回非0值，能夠描述出錯的是什麼

 

　　含義：

　　hostStr　　　　主機名稱或地址，以NULL結尾的字符串

　　serviceStr　　  服務名稱或端口號，以NULL結尾的字符串

　　hints　　　　　要返回信息的種類，能夠實現選擇

　　results　　 存儲一個指向包含結果的鏈表的指針

　對於addrinfo結構，以下所示：

複製代碼 
struct addrinfo {
　　int ai_flags;//Flags to control info resolution
　　int ai_family;//Family:AF_INET,AF_INET6,AF_UNSPEC
　　int ai_socktype;//Socket type:SOCK_STREAM,SOCK_DGRAM
　　int ai_protocol;//Protocol: 0(default) or IPPROTO_XXX
　　socklen_t ai_addrlen;//Length of socket address ai_addr
　　struct sockaddr *ai_addr;//Socket address for socket
　　char*ai_canonname;//Canonical name
　　struct addrinfo *ai_next;//Next addrinfo in linked list
};
複製代碼

 

　　利用getaddrinfo()函數編寫出的SetupTCPClientSocket()和SetupTCPServerSocket()能夠很方便地隱藏IPv4和IPv6地址的差別，根據它重寫的TCPEchoClient.c和TCPEchoServer.c就能夠同時處理兩種類型的地址了。


　　本章最後還提到了從Internet地址獲取主機名稱的getnameinfo()和獲取本身主機名稱的gethostname()，再也不詳述。

初學Sockets編程(三) UDP套接字

　　UDP的過程通訊看上去比TCP簡單一些，但也有許多細節須要注意。好比，UDP套接字使用前沒必要鏈接，TCP相似於電話通訊，UDP相似於郵件通訊，UDP套接字就像一個郵箱，能夠把許多不一樣來源的信件或包裹放入其中。所以，在示例UDPEchoClient.c中，是須要用SockAddrsEqual()來檢測回送的數據包是不是以前所送往的服務器回送的，儘管在示例中不太可能出現這種狀況。

　　程序使用的地址結構、套接字的建立仍是與TCP相差無幾。因爲沒有創建鏈接的步驟，不須要調用listen()，一旦套接字具備地址就準備好接受消息。同時UDP也不須要使用accept()爲每一個客戶獲取一個新的套接字，而是利用綁定到想要端口號的相同套接字當即調用recvfrom()。這樣，在接收數據報的同時須要獲知起來源。如下是發送和接收用到的函數。

ssize_t sendto(int socket, constvoid*msg, size_t msgLength, int flags, conststruct sockaddr *destAddr, socklen_t addrLen) //前4個參數與send()相同，另外兩個指向消息的目的地 ssize_t recvfrom(int socket, void*msg, size_t msgLength, int flags, struct sockaddr *srcAddr,socklen_t *addrLen) //前4個參數與recv()相同，另外兩個告知調用者所接受的數據報的來源 //addrLen是一個輸入/輸出型的參數，須要傳遞一個指針

　　TCP 調用send()時，數據已經複製進緩衝區中以進行傳輸，可能不會實際的傳輸；UDP不會重傳，這意味着當其調用sendto()時，就已經把消息傳遞給底層，而且已經（或者很快將要）發送出去。

　　UDP對不一樣消息的字節保留邊界，recvfrom()不會返回多個數據塊。當參數設定小於第一個數據塊大小時，剩餘字節將會被丟棄而無指示。所以緩衝區應該大於協議容許的最大消息，其最大負載是65507字節。


 　　UDP 套接字上調用connect()能夠用於固定經過套接字發送的未來數據報的目的地址。一旦鏈接，能夠用send()代替sendto()、recv()代替recvfrom()，但這不改變UDP的行爲方式。


初學Sockets編程(四) 發送和接收數據

　　　　放假歸來，半個月沒看書了，稍微有些生疏。被安排了新的工做，老的自學任務還需繼續完成。

 

　　這一章內容比較多，按小節整理了一下。

 

1、編碼整數

1.整數型的大小

　　由通訊過程雙方交換信息的協議標準引伸出了編碼的整數，進而探討了各個整數類型的大小(char、int、long、int8_t、uint8_t等)、獲取它們的長度的方法——sizeof()、而且有一個簡單的程序示例TestSizes.c來展現。

2.傳輸順序

　　多個字節編碼的整數，是從最高有效位（大端、左端）仍是從最低有效位（小端、右端）發送，也是傳輸雙方須要協調的。大多數協議使用大端順序，所以它也被稱爲網絡字節順序。

3.符號擴展

　　利用補碼進行符號擴展；不一樣長度的數據類型複製時的補位。

 

　　這一小節使用了一個例子BruteForceCoding.c來展現如何進行移位和掩碼操做，至關繁瑣。

4.在流中包裝套接字

　　使用fdopen、fclose、fflush。

5.結構填充

　　優化結構成員的排列順序能夠避免一些沒必要要的填充。或者，安排額外的結構成員使得其成爲可控制的填充部分。

6.字符串和文本
　　利用wcstombs()和mbstowcs()進行寬字符和適於傳輸的字符序列之間的轉換。
7.位操做
2、構造、成幀和解析消息

　　這一部分是一個示例。爲了便於複習，把各個組件功能註釋一下。與前幾章不一樣的是，這裏沒有用相似receive()這樣的函數，而是採用流的方式進行處理。

　　VoteClientTCP.c 客戶端，用於發送請求。請求有兩種，投票和質詢。

　　VoteServerTCP.c 服務器端，接收請求，並根據不一樣請求，修改或僅查詢服務器端數據，並回送。

　　DelimFramer.c 基於界定符成幀，包含了從流複製字節到緩衝區直到遇到界定符的GetNextMsg( )和根據界定符把緩衝區字節複製到流中的PutMsg( )。

　　LengthFramer.c 基於長度成幀，包含的兩個函數與DelimFramer.c提供的兩個函數同名，不一樣的是它們基於長度成幀。此時消息格式有所不一樣，按照前面的約定，兩個字節的前綴中保存了這個消息的長度。

　　VoteEncodingText.c 基於文本進行消息編碼，包含把序列轉化爲消息結構的Encode( )和把消息結構轉化爲字節序列的Decode( )。其中用到的strtok( )第一次分割後，每次分割都要利用NULL做爲第一個參數；strtoll( )的用法以下：

 

longlongint strtoll(constchar*nptr, char**endptr, intbase);
//把nptr按照以base爲進制進行轉換。endptr非空時把第一個無效字符存放至endptr。參考資料

　　VoteEncodingBin.c 基於二進制消息編碼，包含的兩個函數與VoteEncodingText.c提供的兩個函數同名，不一樣的是使用固定大小的消息。

　　這樣，把VoteServerTCP.c、兩個成幀模塊之1、兩個編碼模塊之一以及輔助模塊DieWithMessage.c、TCPClientUtility.c、TCPServerUtility.c和AddressUtility.c一塊兒編譯便可得到服務器程序。客戶端同理，二者須要使用相同的組合。


p.s.第五章程序還沒有測試，因爲有其它項目須要進行，暫時擱置TCP/IP Socket編程的學習。

 

高性能網絡編程總結及《TCP/IP Sockets編程(C語言實現) (第2版)》 代碼下載(連接以及文件打包)

2016-03-01 17:04  2322人閱讀  評論(1)  收藏  舉報
  分類：

目錄(?)[+]

http://blog.csdn.NET/column/details/high-perf-network.html

http://blog.csdn.net/russell_tao/article/details/9111769

高性能網絡編程（一）----accept創建鏈接

最近在部門內作了個高性能網絡編程的培訓，近日整理了下PPT，欲寫成一系列文章從應用角度談談它。
編寫服務器時，許多程序員習慣於使用高層次的組件、中間件（例如OO（面向對象）層層封裝過的開源組件），相比於服務器的運行效率而言，他們更關注程序開發的效率，追求更快的完成項目功能點、但願應用代碼徹底不關心通信細節。他們更喜歡在OO世界裏，去實現某個接口、實現這個組件預約義的各類模式、設置組件參數來達到目的。學習複雜的通信框架、底層細節，在習慣於使用OO語言的程序員眼裏是絕對事倍功半的。以上作法無可厚非，但有必定的侷限性，本文講述的網絡編程頭前冠以「高性能」，它是指程序員設計編寫的服務器須要處理很大的吞吐量，這與簡單網絡應用就有了質的不一樣。由於：一、高吞吐量下，容易觸發到一些設計上的邊界條件；二、偶然性的小几率事件，會在高吞吐量下變成必然性事件。三、IO是慢速的，高吞吐量一般意味着高併發，如同一時刻存在數以萬計、十萬計、百萬計的TCP活動鏈接。因此，作高性能網絡編程不能僅僅知足於學會開源組件、中間件是如何幫我實現指望功能的，對於企業級產品來講，須要瞭解更多的知識。

掌握高性能網絡編程，涉及到對網絡、操做系統協議棧、進程與線程、常見的網絡組件等知識點，須要有豐富的項目開發經驗，可以權衡服務器運行效率與項目開發效率。如下圖來談談我我的對高性能網絡編程的理解。

上面這張圖中，由上至下有如下特色：
•關注點，逐漸由特定業務向通用技術轉移
•使用場景上，由專業領域向通用領域轉移
•靈活性上要求愈來愈高
•性能要求愈來愈高
•對細節、原理的掌握，要求愈來愈高
•對各類異常狀況的處理，要求愈來愈高
•穩定性愈來愈高，bug率愈來愈少
在作應用層的網絡編程時，若服務器吞吐量大，則應該適度瞭解以上各層的關注點。

如上圖紅色文字所示，我認爲編寫高性能服務器的關注點有3個：
一、若是基於通用組件編程，關注點可能是在組件如何封裝套接字編程細節。爲了使應用程序不感知套接字層，這些組件每每是經過各類回調機制來嚮應用層代碼提供網絡服務，一般，出於爲應用層提供更高的開發效率，組件都大量使用了線程（Nginx等是個例外），固然，使用了線程後每每能夠下降代碼複雜度。但多線程引入的併發解決機制仍是須要重點關注的，特別是鎖的使用。另外，使用多線程意味着把應用層的代碼複雜度扔給了操做系統，大吞吐量時，須要關注多線程給操做系統內核帶來的性能損耗。
基於通用組件編程，爲了程序的高性能運行，須要清楚的瞭解組件的如下特性：怎麼使用IO多路複用或者異步IO的？怎麼實現併發性的？ 怎麼組織線程模型的？ 怎麼處理高吞吐量引起的異常狀況的？

二、通用組件只是在封裝套接字，操做系統是經過提供套接字來爲進程提供網絡通信能力的。因此，不瞭解套接字編程，每每對組件的性能就沒有原理上的認識。學習套接字層的編程是有必要的，或許不多會本身從頭去寫，但操做系統的API提供方式經久不變，一經學會，受用終身，同時在項目的架構設計時，選用何種網絡組件就很是準確了。
學習套接字編程，關注點主要在：套接字的編程方法有哪些？阻塞套接字的各方法是如何阻塞住當前代碼段的？非阻塞套接字上的方法如何不阻塞當前代碼段的？IO多路複用機制是怎樣與套接字結合的？異步IO是如何實現的？網絡協議的各類異常狀況、操做系統的各類異常狀況是怎麼經過套接字傳遞給應用性程序的？

三、網絡的複雜性會影響到服務器的吞吐量，並且，高吞吐量場景下，多種臨界條件會致使應用程序的不正常，特別是組件中有bug或考慮不周或沒有配置正確時。瞭解網絡分組能夠定位出這些問題，能夠正確的配置系統、組件，能夠正確的理解系統的瓶頸。
這裏的關注點主要在：TCP、UDP、IP協議的特色？linux等操做系統如何處理這些協議的？使用tcpdump等抓包工具分析各網絡分組。

通常掌握以上3點，就能夠揮灑自如的實現高性能網絡服務器了。

下面具體談談如何作到高性能網絡編程。
衆所周知，IO是計算機上最慢的部分，先不看磁盤IO，針對網絡編程，天然是針對網絡IO。網絡協議對網絡IO影響很大，當下， TCP/IP協議是毫無疑問的主流協議，本文就主要以TCP協議爲例來講明網絡IO。
網絡IO中應用服務器每每聚焦於如下幾個由網絡IO組成的功能中：A）與客戶端創建起TCP鏈接。B）讀取客戶端的請求流。C）向客戶端發送響應流。D）關閉TCP鏈接。E）向其餘服務器發起TCP鏈接。
要掌握住這5個功能，不只僅須要熟悉一些API的使用，更要理解底層網絡如何與上層API之間互相發生影響。同時，還須要對不一樣的場景下，如何權衡開發效率、進程、線程與這些API的組合使用。下面依次來講說這些網絡IO。


一、 與客戶端創建起TCP鏈接
談這個功能前，先來看看網絡、協議、應用服務器間的關係 ：

上圖中可知：
爲簡化不一樣場景下的編程，TCP/IP協議族劃分了應用層、TCP傳輸層、IP網絡層、鏈路層等，每一層只專一於少許功能。
例如，IP層只專一於每個網絡分組如何到達目的主機，而無論目的主機如何處理。
傳輸層最基本的功能是專一於端到端，也就是一臺主機上的進程發出的包，如何到達目的主機上的某個進程。固然，TCP層爲了可靠性，還額外須要解決3個大問題：丟包（網絡分組在傳輸中存在的丟失）、重複（協議層異常引起的多個相同網絡分組）、延遲（好久後網絡分組纔到達目的地）。
鏈路層則只關心以太網或其餘二層網絡內網絡包的傳輸。

回到應用層，每每只須要調用相似於accept的API就能夠創建TCP鏈接。創建鏈接的流程你們都瞭解--三次握手，它如何與accept交互呢？下面以一個不太精確卻通俗易懂的圖來講明之：

研究過backlog含義的朋友都很容易理解上圖。這兩個隊列是內核實現的，當服務器綁定、監聽了某個端口後，這個端口的SYN隊列和ACCEPT隊列就創建好了。客戶端使用connect向服務器發起TCP鏈接，當圖中1.1步驟客戶端的SYN包到達了服務器後，內核會把這一信息放到SYN隊列（即未完成握手隊列）中，同時回一個SYN+ACK包給客戶端。一段時間後，在較中2.1步驟中客戶端再次發來了針對服務器SYN包的ACK網絡分組時，內核會把鏈接從SYN隊列中取出，再把這個鏈接放到ACCEPT隊列（即已完成握手隊列）中。而服務器在第3步調用accept時，其實就是直接從ACCEPT隊列中取出已經創建成功的鏈接套接字而已。

現有咱們能夠來討論應用層組件：爲什麼有的應用服務器進程中，會單獨使用1個線程，只調用accept方法來創建鏈接，例如tomcat；有的應用服務器進程中，卻用1個線程作全部的事，包括accept獲取新鏈接。

緣由在於：首先，SYN隊列和ACCEPT隊列都不是無限長度的，它們的長度限制與調用listen監聽某個地址端口時傳遞的backlog參數有關。既然隊列長度是一個值，那麼，隊列會滿嗎？固然會，若是上圖中第1步執行的速度大於第2步執行的速度，SYN隊列就會不斷增大直到隊列滿；若是第2步執行的速度遠大於第3步執行的速度，ACCEPT隊列一樣會達到上限。第一、2步不是應用程序可控的，但第3步倒是應用程序的行爲，假設進程中調用accept獲取新鏈接的代碼段長期得不到執行，例如獲取不到鎖、IO阻塞等。

那麼，這兩個隊列滿了後，新的請求到達了又將發生什麼？
若SYN隊列滿，則會直接丟棄請求，即新的SYN網絡分組會被丟棄；若是ACCEPT隊列滿，則不會致使放棄鏈接，也不會把鏈接從SYN列隊中移出，這會加重SYN隊列的增加。因此，對應用服務器來講，若是ACCEPT隊列中有已經創建好的TCP鏈接，卻沒有及時的把它取出來，這樣，一旦致使兩個隊列滿了後，就會使客戶端不能再創建新鏈接，引起嚴重問題。
因此，如TOMCAT等服務器會使用獨立的線程，只作accept獲取鏈接這一件事，以防止不能及時的去accept獲取鏈接。

那麼，爲何如Nginx等一些服務器，在一個線程內作accept的同時，還會作其餘IO等操做呢？
這裏就帶出阻塞和非阻塞的概念。應用程序能夠把listen時設置的套接字設爲非阻塞模式（默認爲阻塞模式），這兩種模式會致使accept方法有不一樣的行爲。對阻塞套接字，accept行爲以下圖：

這幅圖中能夠看到，阻塞套接字上使用accept，第一個階段是等待ACCEPT隊列不爲空的階段，它耗時不定，由客戶端是否向本身發起了TCP請求而定，可能會耗時很長。
對非阻塞套接字，accept會有兩種返回，以下圖：

非阻塞套接字上的accept，不存在等待ACCEPT隊列不爲空的階段，它要麼返回成功並拿到創建好的鏈接，要麼返回失敗。

因此，企業級的服務器進程中，若某一線程既使用accept獲取新鏈接，又繼續在這個鏈接上讀、寫字符流，那麼，這個鏈接對應的套接字一般要設爲非阻塞。緣由如上圖，調用accept時不會長期佔用所屬線程的CPU時間片，使得線程可以及時的作其餘工做。


  

高性能網絡編程2----TCP消息的發送

標籤： tcpkernelnaglesocketlinux
2013-07-18 16:37  17001人閱讀  評論(33)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。

在上一篇中，咱們已經創建好的TCP鏈接，對應着操做系統分配的1個套接字。操做TCP協議發送數據時，面對的是數據流。一般調用諸如send或者write方法來發送數據到另外一臺主機，那麼，調用這樣的方法時，在操做系統內核中發生了什麼事情呢？咱們帶着如下3個問題來細細分析：發送方法成功返回時，能保證TCP另外一端的主機接收到嗎？能保證數據已經發送到網絡上了嗎？套接字爲阻塞或者非阻塞時，發送方法作的事情有何不一樣？

要回答上面3個問題涉及了很多知識點，咱們先在TCP層面上看看，發送方法調用時內核作了哪些事。我不想去羅列內核中的數據結構、方法等，畢竟大部分應用程序開發者不須要了解這些，僅以一幅示意圖粗略表示，以下：

圖1 一種典型場景下發送TCP消息的流程
再詳述上圖10個步驟前，先要澄清幾個概念：MTU、MSS、 tcp_write_queue發送隊列、阻塞與非阻塞套接字、擁塞窗口、滑動窗口、 Nagle算法。
當咱們調用發送方法時，會把咱們代碼中構造好的消息流做爲參數傳遞。這個消息流可大可小，例如幾個字節，或者幾兆字節。當消息流較大時，將有可能出現分片。咱們先來討論分片問題。

一、MSS與TCP的分片
由上一篇文中可知，TCP層是第4層傳輸層，第3層IP網絡層、第2層數據鏈路層具有的約束條件一樣對TCP層生效。下面來看看數據鏈路層中的一個概念：最大傳輸單元MTU。
不管何種類型的數據鏈路層，都會對網絡分組的長度有一個限制。例如以太網限制爲1500字節，802.3限制爲1492字節。當內核的IP網絡層試圖發送報文時，若一個報文的長度大於MTU限制，就會被分紅若干個小於MTU的報文，每一個報文都會有獨立的IP頭部。

看看IP頭部的格式：

圖2 IP頭部格式
能夠看到，其指定IP包總長度的是一個16位（2字節）的字段，這意味一個IP包最大能夠是65535字節。
若TCP層在以太網中試圖發送一個大於1500字節的消息，調用IP網絡層方法發送消息時，IP層會自動的獲取所在局域網的MTU值，並按照所在網絡的MTU大小來分片。IP層同時但願這個分片對於傳輸層來講是透明的，接收方的IP層會根據收到的多個IP包頭部，將發送方IP層分片出的IP包重組爲一個消息。
這種IP層的分片效率是不好的，由於必須全部分片都到達才能重組成一個包，其中任何一個分片丟失了，都必須重發全部分片。因此，TCP層會試圖避免IP層執行數據報分片。

爲了不IP層的分片，TCP協議定義了一個新的概念：最大報文段長度MSS。它定義了一個TCP鏈接上，一個主機指望對端主機發送單個報文的最大長度。TCP3次握手創建鏈接時，鏈接雙方都要互相告知本身指望接收到的MSS大小。例如（使用tcpdump抓包）：
15:05:08.230782 IP 10.7.80.57.64569 > houyi-vm02.dev.sd.aliyun.com.tproxy: S 3027092051:3027092051(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
15:05:08.234267 IP houyi-vm02.dev.sd.aliyun.com.tproxy > 10.7.80.57.64569: S 26006838:26006838(0) ack 3027092052 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 9>
15:05:08.233320 IP 10.7.80.57.64543 > houyi-vm02.dev.sd.aliyun.com.tproxy: P 78972532:78972923(391) ack 12915963 win 255
因爲例子中兩臺主機都在以太網內，以太網的MTU爲1500，減去IP和TCP頭部的長度，MSS就是1460，三次握手中，SYN包都會攜帶指望的MSS大小。

當應用層調用TCP層提供的發送方法時，內核的TCP模塊在tcp_sendmsg方法裏，會按照對方告知的MSS來分片，把消息流分爲多個網絡分組（如圖1中的3個網絡分組），再調用IP層的方法發送數據。

這個MSS就不會改變了嗎？
會的。上文說過，MSS就是爲了不IP層分片，在創建握手時告知對方指望接收的MSS值並不必定靠得住。由於這個值是預估的，TCP鏈接上的兩臺主機若處於不一樣的網絡中，那麼，鏈接上可能有許多中間網絡，這些網絡分別具備不一樣的數據鏈路層，這樣，TCP鏈接上有許多個MTU。特別是，若中間途徑的MTU小於兩臺主機所在的網絡MTU時，選定的MSS仍然太大了，會致使中間路由器出現IP層的分片。
怎樣避免中間網絡可能出現的分片呢？
經過IP頭部的DF標誌位，這個標誌位是告訴IP報文所途經的全部IP層代碼：不要對這個報文分片。若是一個IP報文太大必需要分片，則直接返回一個ICMP錯誤，說明必需要分片了，且待分片路由器網絡接受的MTU值。這樣，鏈接上的發送方主機就能夠從新肯定MSS。


二、發送方法返回成功後，數據必定發送到了TCP的另外一端嗎？
答案固然是否認的。解釋這個問題前，先來看看TCP是如何保證可靠傳輸的。
TCP把本身要發送的數據流裏的每個字節都當作一個序號，可靠性是要求鏈接對端在接收到數據後，要發送ACK確認，告訴它已經接收到了多少字節的數據。也就是說，怎樣確保數據必定發送成功了呢？必須等待發送數據對應序號的ACK到達，才能確保數據必定發送成功。 TCP層提供的send或者write這樣的方法是不會作這件事的，看看圖1，它究竟作了哪些事。

圖1中分爲10步。
（1）應用程序試圖調用send方法來發送一段較長的數據。
（2）內核主要經過tcp_sendmsg方法來完成。
（3）（4）內核真正執行報文的發送，與send方法的調用並非同步的。即，send方法返回成功了，也不必定把IP報文都發送到網絡中了。所以，須要把用戶須要發送的用戶態內存中的數據，拷貝到內核態內存中，不依賴於用戶態內存，也使得進程能夠快速釋放發送數據佔用的用戶態內存。但這個拷貝操做並非簡單的複製，而是把待發送數據，按照MSS來劃分紅多個儘可能達到MSS大小的分片報文段，複製到內核中的sk_buff結構來存放，同時把這些分片組成隊列，放到這個TCP鏈接對應的 tcp_write_queue發送隊列中 。
（5）內核中爲這個TCP鏈接分配的內核緩存是有限的（ /proc/sys/net/core/wmem_default ）。當沒有多餘的內核態緩存來複制用戶態的待發送數據時，就須要調用一個方法 sk_stream_wait_memory來等待滑動窗口移動，釋放出一些緩存出來（收到ACK後，不須要再緩存原來已經發送出的報文，由於既然已經確認對方收到，就不須要定時重發，天然就釋放緩存了）。例如：
[cpp]  view plain  copy
  1. wait_for_memory:  
  2.             if (copied)  
  3.                 tcp_push(sk, tp, flags & ~MSG_MORE, mss_now, TCP_NAGLE_PUSH);  
  4.   
  5.             if ((err = sk_stream_wait_memory(sk, &timeo)) != 0)  
  6.                 goto do_error;  

這裏的 sk_stream_wait_memory方法接受一個參數timeo，就是等待超時的時間。這個時間是tcp_sendmsg方法剛開始就拿到的，以下：
[cpp]  view plain  copy
  1. timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);  

看看其實現：
[cpp]  view plain  copy
  1. static inline long sock_sndtimeo(const struct sock *sk, int noblock)  
  2. {  
  3.     return noblock ? 0 : sk->sk_sndtimeo;  
  4. }  

也就是說，當這個套接字是阻塞套接字時，timeo就是SO_SNDTIMEO選項指定的發送超時時間。若是這個套接字是非阻塞套接字， timeo變量就會是0。
實際上，sk_stream_wait_memory對於非阻塞套接字會直接返回，並將 errno錯誤碼置爲EAGAIN。
（6）在圖1的例子中，咱們假定使用了阻塞套接字，且等待了足夠久的時間，收到了對方的ACK，滑動窗口釋放出了緩存。
（7）將剩下的用戶態數據都組成MSS報文拷貝到內核態的sk_buff中。
（8）最後，調用tcp_push等方法，它最終會調用IP層的方法來發送tcp_write_queue隊列中的報文。
注意，IP層返回時，並不必定是把報文發送了出去。
（9）（10）發送方法返回。

從圖1的10個步驟中可知，不管是使用阻塞仍是非阻塞套接字，發送方法成功返回時（不管所有成功或者部分紅功），既不表明TCP鏈接的另外一端主機接收到了消息，也不表明本機把消息發送到了網絡上，只是說明，內核將會試圖保證把消息送達對方。


三、 Nagle算法、 滑動窗口、擁塞窗口對發送方法的影響
圖1第8步tcp_push方法作了些什麼呢？先來看看主要的流程：

圖3 發送TCP消息的簡易流程

下面簡單看看這幾個概念：
（1）滑動窗口
滑動窗口你們都比較熟悉，就不詳細介紹了。TCP鏈接上的雙方都會通知對方本身的接收窗口大小。而對方的接收窗口大小就是本身的發送窗口大小。tcp_push在發送數據時固然須要與發送窗口打交道。發送窗口是一個時刻變化的值，隨着ACK的到達會變大，隨着發出新的數據包會變小。固然，最大也只能到三次握手時對方通告的窗口大小。tcp_push在發送數據時，最終會使用tcp_snd_wnd_test方法來判斷當前待發送的數據，其序號是否超出了發送滑動窗口的大小，例如：
[cpp]  view plain  copy
  1. //檢查這一次要發送的報文最大序號是否超出了發送滑動窗口大小  
  2. static inline int tcp_snd_wnd_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss)  
  3. {  
  4.         //end_seq待發送的最大序號  
  5.     u32 end_seq = TCP_SKB_CB(skb)->end_seq;  
  6.   
  7.     if (skb->len > cur_mss)  
  8.         end_seq = TCP_SKB_CB(skb)->seq + cur_mss;  
  9.   
  10.         //snd_una是已經發送過的數據中，最小的沒被確認的序號；而snd_wnd就是發送窗口的大小  
  11.     return !after(end_seq, tp->snd_una + tp->snd_wnd);  
  12. }  


（2）慢啓動和擁塞窗口
因爲兩臺主機間的網絡可能很複雜，經過廣域網時，中間的路由器轉發能力多是瓶頸。也就是說，若是一方簡單的按照另外一方主機三次握手時通告的滑動窗口大小來發送數據的話，可能會使得網絡上的轉發路由器性能雪上加霜，最終丟失更多的分組。這時，各個操做系統內核都會對TCP的發送階段加入慢啓動和擁塞避免算法。慢啓動算法說白了，就是對方通告的窗口大小隻表示對方接收TCP分組的能力，不表示中間網絡可以處理分組的能力。因此，發送方請悠着點發，確保網絡很是通暢了後，再按照對方通告窗口來敞開了發。
擁塞窗口就是下面的cwnd，它用來幫助慢啓動的實現。鏈接剛創建時，擁塞窗口的大小遠小於發送窗口，它其實是一個MSS。每收到一個ACK，擁塞窗口擴大一個MSS大小，固然，擁塞窗口最大隻能到對方通告的接收窗口大小。固然，爲了不指數式增加，擁塞窗口大小的增加會更慢一些，是線性的平滑的增加過程。
因此，在tcp_push發送消息時，還會檢查擁塞窗口，飛行中的報文數要小於擁塞窗口個數，而發送數據的長度也要小於擁塞窗口的長度。
以下所示，首先用 unsigned int tcp_cwnd_test方法檢查飛行的報文數是否小於擁塞窗口個數（多少個MSS的個數） ：
[cpp]  view plain  copy
  1. static inline unsigned int tcp_cwnd_test(struct tcp_sock *tp, struct sk_buff *skb)  
  2. {  
  3.     u32 in_flight, cwnd;  
  4.   
  5.     /* Don't be strict about the congestion window for the final FIN.  */  
  6.     if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)  
  7.         return 1;  
  8.   
  9.         //飛行中的數據，也就是沒有ACK的字節總數  
  10.     in_flight = tcp_packets_in_flight(tp);  
  11.     cwnd = tp->snd_cwnd;  
  12.         //若是擁塞窗口容許，須要返回依據擁塞窗口的大小，還能發送多少字節的數據  
  13.     if (in_flight < cwnd)  
  14.         return (cwnd - in_flight);  
  15.   
  16.     return 0;  
  17. }  

再經過tcp_window_allows方法獲取擁塞窗口與滑動窗口的最小長度，檢查待發送的數據是否超出：
[cpp]  view plain  copy
  1. static unsigned int tcp_window_allows(struct tcp_sock *tp, struct sk_buff *skb, unsigned int mss_now, unsigned int cwnd)  
  2. {  
  3.     u32 window, cwnd_len;  
  4.   
  5.     window = (tp->snd_una + tp->snd_wnd - TCP_SKB_CB(skb)->seq);  
  6.     cwnd_len = mss_now * cwnd;  
  7.     return min(window, cwnd_len);  
  8. }  


（3）是否符合NAGLE算法？
Nagle算法的初衷是這樣的：應用進程調用發送方法時，可能每次只發送小塊數據，形成這臺機器發送了許多小的TCP報文。對於整個網絡的執行效率來講，小的TCP報文會增長網絡擁塞的可能，所以，若是有可能，應該將相臨的TCP報文合併成一個較大的TCP報文（固然仍是小於MSS的）發送。
Nagle算法要求一個TCP鏈接上最多隻能有一個發送出去還沒被確認的小分組，在該分組的確認到達以前不能發送其餘的小分組。
內核中是經過  tcp_nagle_test 方法實現該算法的。咱們簡單的看下：
[cpp]  view plain  copy
  1.   
[cpp]  view plain  copy
  1. static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff *skb,  
  2.                  unsigned int cur_mss, int nonagle)  
  3. {  
  4.     //nonagle標誌位設置了，返回1表示容許這個分組發送出去  
  5.     if (nonagle & TCP_NAGLE_PUSH)  
  6.         return 1;  
  7.   
  8.     //若是這個分組包含了四次握手關閉鏈接的FIN包，也能夠發送出去  
  9.     if (tp->urg_mode ||  
  10.         (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN))  
  11.         return 1;  
  12.   
  13.         //檢查Nagle算法  
  14.     if (!tcp_nagle_check(tp, skb, cur_mss, nonagle))  
  15.         return 1;  
  16.   
  17.     return 0;  
  18. }  

再來看看 tcp_nagle_check方法，它與上一個方法不一樣，返回0表示能夠發送，返回非0則不能夠，正好相反。
[cpp]  view plain  copy
  1. static inline int tcp_nagle_check(const struct tcp_sock *tp,  
  2.                   const struct sk_buff *skb,   
  3.                   unsigned mss_now, int nonagle)  
  4. {  
  5.         //先檢查是否爲小分組，即報文長度是否小於MSS  
  6.     return (skb->len < mss_now &&  
  7.         ((nonagle&TCP_NAGLE_CORK) ||  
  8.         //若是開啓了Nagle算法  
  9.          (!nonagle &&  
  10.         //若已經有小分組發出（packets_out表示「飛行」中的分組）尚未確認  
  11.           tp->packets_out &&  
  12.           tcp_minshall_check(tp))));  
  13. }  

最後看看tcp_minshall_check作了些什麼：
[cpp]  view plain  copy
  1. static inline int tcp_minshall_check(const struct tcp_sock *tp)  
  2. {  
  3.         //最後一次發送的小分組尚未被確認  
  4.     return after(tp->snd_sml,tp->snd_una) &&  
  5.                 //將要發送的序號是要大於等於上次發送分組對應的序號  
  6.         !after(tp->snd_sml, tp->snd_nxt);  
  7. }  

想象一種場景，當對請求的時延很是在乎且網絡環境很是好的時候（例如同一個機房內），Nagle算法能夠關閉，這實在也不必。使用TCP_NODELAY套接字選項就能夠關閉Nagle算法。看看setsockopt是怎麼與上述方法配合工做的：
[cpp]  view plain  copy
  1. static int do_tcp_setsockopt(struct sock *sk, int level,  
  2.         int optname, char __user *optval, int optlen)  
  3.         ...  
  4.     switch (optname) {  
  5.         ...  
  6.     case TCP_NODELAY:  
  7.         if (val) {  
  8.                         //若是設置了TCP_NODELAY，則更新nonagle標誌  
  9.             tp->nonagle |= TCP_NAGLE_OFF|TCP_NAGLE_PUSH;  
  10.             tcp_push_pending_frames(sk, tp);  
  11.         } else {  
  12.             tp->nonagle &= ~TCP_NAGLE_OFF;  
  13.         }  
  14.         break;  
  15.         }  
  16. }  

能夠看到，nonagle標誌位就是這麼更改的。


固然，調用了IP層的方法返回後，也未必就保證此時數據必定發送到網絡中去了。
下一篇咱們探討如何接收TCP消息，以及接收到ack後內核作了些什麼。

  

高性能網絡編程3----TCP消息的接收

標籤： linuxtcp高性能服務器網絡編程
2013-08-26 18:55  17975人閱讀  評論(29)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。

這篇文章將試圖說明應用程序如何接收網絡上發送過來的TCP消息流，因爲篇幅所限，暫時忽略ACK報文的回覆和接收窗口的滑動。
爲了快速掌握本文所要表達的思想，咱們能夠帶着如下問題閱讀：
一、應用程序調用read、recv等方法時，socket套接字能夠設置爲阻塞或者非阻塞，這兩種方式是如何工做的？
二、若socket爲默認的阻塞套接字，此時recv方法傳入的len參數，是表示必須超時（SO_RCVTIMEO）或者接收到len長度的消息，recv方法纔會返回嗎？並且，socket上能夠設置一個屬性叫作SO_RCVLOWAT，它會與len產生什麼樣的交集，又是決定recv等接收方法何時返回？
三、應用程序開始收取TCP消息，與程序所在的機器網卡上接收到網絡裏發來的TCP消息，這是兩個獨立的流程。它們之間是如何互相影響的？例如，應用程序正在收取消息時，內核經過網卡又在這條TCP鏈接上收到消息時，到底是如何處理的？若應用程序沒有調用read或者recv時，內核收到TCP鏈接上的消息後又是怎樣處理的？
四、recv這樣的接收方法還能夠傳入各類flags，例如MSG_WAITALL、MSG_PEEK、MSG_TRUNK等等。它們是如何工做的？
五、1個socket套接字可能被多個進程在使用，出現併發訪問時，內核是怎麼處理這種情況的？
六、linux的sysctl系統參數中，有相似tcp_low_latency這樣的開關，默認爲0或者配置爲1時是如何影響TCP消息處理流程的？


書接上文。本文將經過三幅圖講述三種典型的接收TCP消息場景，理清內核爲實現TCP消息的接收所實現的4個隊列容器。固然，瞭解內核的實現並非目的，而是如何使用socket接口、如何配置操做系統內核參數，才能使TCP傳輸消息更高效，這纔是最終目的。

不少同窗不但願被內核代碼擾亂了思惟，如何閱讀本文呢？
我會在圖1的步驟都介紹完了纔來從代碼上說明tcp_v4_rcv等主要方法。像flags參數、非阻塞套接字會產生怎樣的效果我是在代碼介紹中說的。而後我會介紹圖二、圖3，介紹它們的步驟時我會穿插一些上文沒有涉及的少許代碼。不喜歡瞭解內核代碼的同窗請直接看完圖1的步驟後，請跳到圖二、圖3中，我認爲這3幅圖覆蓋了主要的TCP接收場景，可以幫助你理清其流程。

接收消息時調用的系統方法要比上一篇發送TCP消息複雜許多。接收TCP消息的過程能夠一分爲二：首先是PC上的網卡接收到網線傳來的報文，經過軟中斷內核拿到而且解析其爲TCP報文，而後TCP模塊決定如何處理這個TCP報文。其次，用戶進程調用read、recv等方法獲取TCP消息，則是將內核已經從網卡上收到的消息流拷貝到用戶進程裏的內存中。

第一幅圖描述的場景是，TCP鏈接上將要收到的消息序號是S1（TCP上的每一個報文都有序號，詳見《TCP/IP協議詳解》），此時操做系統內核依次收到了序號S1-S2的報文、S3-S四、S2-S3的報文，注意後兩個包亂序了。以後，用戶進程分配了一段len大小的內存用於接收TCP消息，此時，len是大於S4-S1的。另外，用戶進程始終沒有對這個socket設置過SO_RCVLOWAT參數，所以，接收閥值SO_RCVLOWAT使用默認值1。另外，系統參數tcp_low_latency設置爲0，即從操做系統的整體效率出發，使用prequeue隊列提高吞吐量。固然，因爲用戶進程收消息時，並無新包來臨，因此此圖中prequeue隊列始終爲空。先不細表。
圖1以下：

上圖中有13個步驟，應用進程使用了阻塞套接字，調用recv等方法時flag標誌位爲0，用戶進程讀取套接字時沒有發生進程睡眠。內核在處理接收到的TCP報文時使用了4個隊列容器（當鏈表理解也可），分別爲receive、out_of_order、prequeue、backlog隊列，本文會說明它們存在的意義。下面詳細說明這13個步驟。
一、當網卡接收到報文並判斷爲TCP協議後，將會調用到內核的tcp_v4_rcv方法。此時，這個TCP鏈接上須要接收的下一個報文序號剛好就是S1，而這一步裏，網卡上收到了S1-S2的報文，因此，tcp_v4_rcv方法會把這個報文直接插入到receive隊列中。
注意：receive隊列是容許用戶進程直接讀取的，它是將已經接收到的TCP報文，去除了TCP頭部、排好序放入的、用戶進程能夠直接按序讀取的隊列。因爲socket不在進程上下文中（也就是沒有進程在讀socket），因爲咱們須要S1序號的報文，而剛好收到了S1-S2報文，所以，它進入了receive隊列。

二、接着，咱們收到了S3-S4報文。在第1步結束後，這時咱們須要收到的是S2序號，但到來的報文倒是S3打頭的，怎麼辦呢？進入out_of_order隊列！從這個隊列名稱就能夠看出來，全部亂序的報文都會暫時放在這。

三、仍然沒有進入來讀取socket，但又過來了咱們指望的S2-S3報文，它會像第1步同樣，直接進入receive隊列。不一樣的時，因爲此時out_of_order隊列不像第1步是空的，因此，引起了接來的第4步。

四、每次向receive隊列插入報文時都會檢查out_of_order隊列。因爲收到S2-S3報文後，期待的序號成爲了S3，這樣，out_of_order隊列裏的惟一報文S3-S4報文將會移出本隊列而插入到receive隊列中（這件事由tcp_ofo_queue方法完成）。

五、終於有用戶進程開始讀取socket了。作過應用端編程的同窗都知道，先要在進程裏分配一塊內存，接着調用read或者recv等方法，把內存的首地址和內存長度傳入，再把創建好鏈接的socket也傳入。固然，對這個socket還能夠配置其屬性。這裏，假定沒有設置任何屬性，都使用默認值，所以，此時socket是阻塞式，它的SO_RCVLOWAT是默認的1。固然，recv這樣的方法還會接收一個flag參數，它能夠設置爲MSG_WAITALL、MSG_PEEK、MSG_TRUNK等等，這裏咱們假定爲最經常使用的0。進程調用了recv方法。

六、不管是何種接口，C庫和內核通過層層封裝，接收TCP消息最終必定會走到tcp_recvmsg方法。下面介紹代碼細節時，它會是重點。

七、在tcp_recvmsg方法裏，會首先鎖住socket。爲何呢？所以socket是能夠被多進程同時使用的，同時，內核中斷也會操做它，而下面的代碼都是核心的、操做數據的、有狀態的代碼，不能夠被重入的，鎖住後，再有用戶進程進來時拿不到鎖就要休眠在這了。內核中斷看到被鎖住後也會作不一樣的處理，參見圖二、圖3。

八、此時，第1-4步已經爲receive隊列裏準備好了3個報文。最上面的報文是S1-S2，將它拷貝到用戶態內存中。因爲第5步flag參數並無攜帶MSG_PEEK這樣的標誌位，所以，再將S1-S2報文從receive隊列的頭部移除，從內核態釋放掉。反之，MSG_PEEK標誌位會致使receive隊列不會刪除報文。因此，MSG_PEEK主要用於多進程讀取同一套接字的情形。

九、如第8步，拷貝S2-S3報文到用戶態內存中。固然，執行拷貝前都會檢查用戶態內存的剩餘空間是否足以放下當前這個報文，不足以時會直接返回已經拷貝的字節數。
十、同上。

十一、receive隊列爲空了，此時會先來檢查SO_RCVLOWAT這個閥值。若是已經拷貝的字節數到如今還小於它，那麼可能致使進程會休眠，等待拷貝更多的數據。第5步已經說明過了，socket套接字使用的默認的SO_RCVLOWAT，也就是1，這代表，只要讀取到報文了，就認爲能夠返回了。
作完這個檢查了，再檢查backlog隊列。backlog隊列是進程正在拷貝數據時，網卡收到的報文會進這個隊列。此時若backlog隊列有數據，就順帶處理下。圖3會覆蓋這種場景。

十二、在本圖對應的場景中，backlog隊列是沒有數據的，已經拷貝的字節數爲S4-S1，它是大於1的，所以，釋放第7步里加的鎖，準備返回用戶態了。

1三、用戶進程代碼開始執行，此時recv等方法返回的就是S4-S1，即從內核拷貝的字節數。


圖1描述的場景是最簡單的1種場景，下面咱們來看看上述步驟是怎樣經過內核代碼實現的（如下代碼爲2.6.18內核代碼）。


咱們知道，linux對中斷的處理是分爲上半部和下半部的，這是處於系統總體效率的考慮。咱們將要介紹的都是在網絡軟中斷的下半部裏，例如這個tcp_v4_rcv方法。圖1中的第1-4步都是在這個方法裏完成的。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. int tcp_v4_rcv(struct sk_buff *skb)  
  2. {  
  3.         ... ...  
  4.     //是否有進程正在使用這個套接字，將會對處理流程產生影響  
  5.         //或者從代碼層面上，只要在tcp_recvmsg裏，執行lock_sock後只能進入else，而release_sock後會進入if  
  6.     if (!sock_owned_by_user(sk)) {  
  7.         {  
  8.             //當 tcp_prequeue 返回0時，表示這個函數沒有處理該報文  
  9.             if (!tcp_prequeue(sk, skb))//若是報文放在prequeue隊列，即表示延後處理，不佔用軟中斷過長時間  
  10.                 ret = tcp_v4_do_rcv(sk, skb);//不使用prequeue或者沒有用戶進程讀socket時（圖3進入此分支），馬上開始處理這個報文  
  11.         }  
  12.     } else  
  13.         sk_add_backlog(sk, skb);//若是進程正在操做套接字，就把skb指向的TCP報文插入到backlog隊列（圖3涉及此分支）  
  14.         ... ...  
  15. ｝  

圖1第1步裏，咱們從網絡上收到了序號爲S1-S2的包。此時，沒有用戶進程在讀取套接字，所以，sock_owned_by_user(sk)會返回0。因此，tcp_prequeue方法將獲得執行。簡單看看它：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static inline int tcp_prequeue(struct sock *sk, struct sk_buff *skb)  
  2. {  
  3.     struct tcp_sock *tp = tcp_sk(sk);  
  4.   
  5.     //檢查tcp_low_latency，默認其爲0，表示使用prequeue隊列。tp->ucopy.task不爲0，表示有進程啓動了拷貝TCP消息的流程  
  6.     if (!sysctl_tcp_low_latency && tp->ucopy.task) {  
  7.         //到這裏，一般是用戶進程讀數據時沒讀到指定大小的數據，休眠了。直接將報文插入prequeue隊列的末尾，延後處理  
  8.         __skb_queue_tail(&tp->ucopy.prequeue, skb);  
  9.         tp->ucopy.memory += skb->truesize;  
  10.         //固然，雖然一般是延後處理，但若是TCP的接收緩衝區不夠用了，就會馬上處理prequeue隊列裏的全部報文  
  11.         if (tp->ucopy.memory > sk->sk_rcvbuf) {  
  12.             while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) {  
  13.                                 //sk_backlog_rcv就是下文將要介紹的tcp_v4_do_rcv方法  
  14.                 sk->sk_backlog_rcv(sk, skb1);  
  15.             }  
  16.         } else if (skb_queue_len(&tp->ucopy.prequeue) == 1) {  
  17.                         //prequeue裏有報文了，喚醒正在休眠等待數據的進程，讓進程在它的上下文中處理這個prequeue隊列的報文  
  18.             wake_up_interruptible(sk->sk_sleep);  
  19.         }  
  20.   
  21.         return 1;  
  22.     }  
  23.     //prequeue沒有處理  
  24.     return 0;  
  25. }  

因爲tp->ucopy.task此時是NULL，因此咱們收到的第1個報文在tcp_prequeue函數裏直接返回了0，所以，將由 tcp_v4_do_rcv方法處理。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)  
  2. {  
  3.     if (sk->sk_state == TCP_ESTABLISHED) { /* Fast path */  
  4.         //當TCP鏈接已經創建好時，是由tcp_rcv_established方法處理接收報文的  
  5.         if (tcp_rcv_established(sk, skb, skb->h.th, skb->len))  
  6.             goto reset;  
  7.   
  8.         return 0;  
  9.     }  
  10.         ... ...  
  11. ｝  

tcp_rcv_established方法在圖1裏，主要調用tcp_data_queue方法將報文放入隊列中，繼續看看它又幹了些什麼事：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)  
  2. {  
  3.     struct tcp_sock *tp = tcp_sk(sk);  
  4.   
  5.     //若是這個報文是待接收的報文（看seq），它有兩個出路：進入receive隊列，正如圖1；直接拷貝到用戶內存中，如圖3  
  6.     if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {  
  7.                 //滑動窗口外的包暫不考慮，篇幅有限，下次再細談  
  8.         if (tcp_receive_window(tp) == 0)  
  9.             goto out_of_window;  
  10.   
  11.         //若是有一個進程正在讀取socket，且正準備要拷貝的序號就是當前報文的seq序號  
  12.         if (tp->ucopy.task == current &&  
  13.             tp->copied_seq == tp->rcv_nxt && tp->ucopy.len &&  
  14.             sock_owned_by_user(sk) && !tp->urg_data) {  
  15.             //直接將報文內容拷貝到用戶態內存中，參見圖3  
  16.             if (!skb_copy_datagram_iovec(skb, 0, tp->ucopy.iov, chunk)) {  
  17.                 tp->ucopy.len -= chunk;  
  18.                 tp->copied_seq += chunk;  
  19.             }  
  20.         }  
  21.   
  22.         if (eaten <= 0) {  
  23. queue_and_out:  
  24.                         //若是沒有可以直接拷貝到用戶內存中，那麼，插入receive隊列吧，正如圖1中的第一、3步  
  25.             __skb_queue_tail(&sk->sk_receive_queue, skb);  
  26.         }  
  27.                 //更新待接收的序號，例如圖1第1步中，更新爲S2  
  28.         tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;  
  29.   
  30.                 //正如圖1第4步，這時會檢查out_of_order隊列，若它不爲空，須要處理它  
  31.         if (!skb_queue_empty(&tp->out_of_order_queue)) {  
  32.                         //tcp_ofo_queue方法會檢查out_of_order隊列中的全部報文  
  33.             tcp_ofo_queue(sk);  
  34.         }  
  35.     }  
  36.         ... ...  
  37.   
  38.     //這個包是無序的，又在接收滑動窗口內，那麼就如圖1第2步，把報文插入到out_of_order隊列吧  
  39.     if (!skb_peek(&tp->out_of_order_queue)) {  
  40.         __skb_queue_head(&tp->out_of_order_queue,skb);  
  41.     } else {  
  42.                     ... ...  
  43.             __skb_append(skb1, skb, &tp->out_of_order_queue);  
  44.     }  
  45. }  

圖1第4步時，正是經過tcp_ofo_queue方法把以前亂序的S3-S4報文插入receive隊列的。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static void tcp_ofo_queue(struct sock *sk)  
  2. {  
  3.     struct tcp_sock *tp = tcp_sk(sk);  
  4.     __u32 dsack_high = tp->rcv_nxt;  
  5.     struct sk_buff *skb;  
  6.         //遍歷out_of_order隊列  
  7.     while ((skb = skb_peek(&tp->out_of_order_queue)) != NULL) {  
  8.         ... ...  
  9.                 //若這個報文能夠按seq插入有序的receive隊列中，則將其移出out_of_order隊列  
  10.         __skb_unlink(skb, &tp->out_of_order_queue);  
  11.                 //插入receive隊列  
  12.         __skb_queue_tail(&sk->sk_receive_queue, skb);  
  13.                 //更新socket上待接收的下一個有序seq  
  14.         tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;  
  15.     }  
  16. }  


下面再介紹圖1第6步提到的tcp_recvmsg方法。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. //參數裏的len就是read、recv方法裏的內存長度，flags正是方法的flags參數，nonblock則是阻塞、非阻塞標誌位  
  2. int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,  
  3.         size_t len, int nonblock, int flags, int *addr_len)  
  4. {  
  5.     //鎖住socket，防止多進程併發訪問TCP鏈接，告知軟中斷目前socket在進程上下文中  
  6.     lock_sock(sk);  
  7.   
  8.         //初始化errno這個錯誤碼  
  9.     err = -ENOTCONN;  
  10.   
  11.     //若是socket是阻塞套接字，則取出SO_RCVTIMEO做爲讀超時時間；若爲非阻塞，則timeo爲0。下面會看到timeo是如何生效的  
  12.     timeo = sock_rcvtimeo(sk, nonblock);  
  13.   
  14.     //獲取下一個要拷貝的字節序號  
  15.     //注意：seq的定義爲u32 *seq;，它是32位指針。爲什麼？由於下面每向用戶態內存拷貝後，會更新seq的值，這時就會直接更改套接字上的copied_seq  
  16.     seq = &tp->copied_seq;  
  17.     //當flags參數有MSG_PEEK標誌位時，意味着此次拷貝的內容，當再次讀取socket時（好比另外一個進程）還能再次讀到  
  18.     if (flags & MSG_PEEK) {  
  19.         //因此不會更新copied_seq，固然，下面會看到也不會刪除報文，不會從receive隊列中移除報文  
  20.         peek_seq = tp->copied_seq;  
  21.         seq = &peek_seq;  
  22.     }  
  23.   
  24.     //獲取SO_RCVLOWAT最低接收閥值，固然，target其實是用戶態內存大小len和SO_RCVLOWAT的最小值  
  25.     //注意：flags參數中若攜帶MSG_WAITALL標誌位，則意味着必須等到讀取到len長度的消息才能返回，此時target只能是len  
  26.     target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);  
  27.   
  28.         //如下開始讀取消息  
  29.     do {  
  30.         //從receive隊列取出1個報文  
  31.         skb = skb_peek(&sk->sk_receive_queue);  
  32.         do {  
  33.             //沒取到退出當前循環  
  34.             if (!skb)  
  35.                 break;  
  36.   
  37.   
  38.             //offset是待拷貝序號在當前這個報文中的偏移量，在圖一、二、3中它都是0，只有由於用戶內存不足以接收完1個報文時才爲非0  
  39.             offset = *seq - TCP_SKB_CB(skb)->seq;  
  40.             //有些時候，三次握手的SYN包也會攜帶消息內容的，此時seq是多出1的（SYN佔1個序號），因此offset減1  
  41.             if (skb->h.th->syn)  
  42.                 offset--;  
  43.             //若偏移量還有這個報文以內，則認爲它須要處理  
  44.             if (offset < skb->len)  
  45.                 goto found_ok_skb;  
  46.   
  47.             skb = skb->next;  
  48.         } while (skb != (struct sk_buff *)&sk->sk_receive_queue);  
  49.   
  50.         //若是receive隊列爲空，則檢查已經拷貝的字節數，是否達到了SO_RCVLOWAT或者長度len。知足了，且backlog隊列也爲空，則能夠返回用戶態了，正如圖1的第11步  
  51.         if (copied >= target && !sk->sk_backlog.tail)  
  52.             break;  
  53.   
  54.                 //在tcp_recvmsg裏，copied就是已經拷貝的字節數  
  55.         if (copied) {  
  56.             ... ...  
  57.         } else {  
  58.                         //一個字節都沒拷貝到，但若是shutdown關閉了socket，同樣直接返回。固然，本文不涉及關閉鏈接  
  59.             if (sk->sk_shutdown & RCV_SHUTDOWN)  
  60.                 break;  
  61.   
  62.             //若是使用了非阻塞套接字，此時timeo爲0  
  63.             if (!timeo) {  
  64.                                 //非阻塞套接字讀取不到數據時也會返回，錯誤碼正是EAGAIN  
  65.                 copied = -EAGAIN;  
  66.                 break;  
  67.             }  
  68.                         ... ...  
  69.         }  
  70.   
  71.         //tcp_low_latency默認是關閉的，圖一、圖2都是如此，圖3則例外，即圖3不會走進這個if  
  72.         if (!sysctl_tcp_low_latency && tp->ucopy.task == user_recv) {  
  73.             //prequeue隊列就是爲了提升系統總體效率的，即prequeue隊列有可能不爲空，這是由於進程休眠等待時可能有新報文到達prequeue隊列  
  74.             if (!skb_queue_empty(&tp->ucopy.prequeue))  
  75.                 goto do_prequeue;  
  76.         }  
  77.   
  78.         //若是已經拷貝了的字節數超過了最低閥值  
  79.         if (copied >= target) {  
  80.             //release_sock這個方法會遍歷、處理backlog隊列中的報文  
  81.             release_sock(sk);  
  82.             lock_sock(sk);  
  83.         } else  
  84.             sk_wait_data(sk, &timeo);//沒有讀取到足夠長度的消息，所以會進程休眠，若是沒有被喚醒，最長睡眠timeo時間  
  85.   
  86.         if (user_recv) {  
  87.             if (tp->rcv_nxt == tp->copied_seq &&  
  88.                 !skb_queue_empty(&tp->ucopy.prequeue)) {  
  89. do_prequeue:  
  90.                                 //接上面代碼段，開始處理prequeue隊列裏的報文  
  91.                 tcp_prequeue_process(sk);  
  92.             }  
  93.         }  
  94.   
  95.         //繼續處理receive隊列的下一個報文  
  96.         continue;  
  97.   
  98.     found_ok_skb:  
  99.         /* Ok so how much can we use? */  
  100.         //receive隊列的這個報文從其能夠使用的偏移量offset，到總長度len之間，能夠拷貝的長度爲used  
  101.         used = skb->len - offset;  
  102.         //len是用戶態空閒內存，len更小時，固然只能拷貝len長度消息，總不能致使內存溢出吧  
  103.         if (len < used)  
  104.             used = len;  
  105.   
  106.         //MSG_TRUNC標誌位表示不要管len這個用戶態內存有多大，只管拷貝數據吧  
  107.         if (!(flags & MSG_TRUNC)) {  
  108.             {  
  109.                 //向用戶態拷貝數據  
  110.                 err = skb_copy_datagram_iovec(skb, offset,  
  111.                         msg->msg_iov, used);  
  112.             }  
  113.         }  
  114.   
  115.         //由於是指針，因此同時更新copied_seq--下一個待接收的序號  
  116.         *seq += used;  
  117.         //更新已經拷貝的長度  
  118.         copied += used;  
  119.         //更新用戶態內存的剩餘空閒空間長度  
  120.         len -= used;  
  121.   
  122.                 ... ...  
  123.     } while (len > 0);  
  124.   
  125.     //已經裝載了接收器  
  126.     if (user_recv) {  
  127.         //prequeue隊列不爲空則處理之  
  128.         if (!skb_queue_empty(&tp->ucopy.prequeue)) {  
  129.             tcp_prequeue_process(sk);  
  130.         }  
  131.   
  132.         //準備返回用戶態，socket上再也不裝載接收任務  
  133.         tp->ucopy.task = NULL;  
  134.         tp->ucopy.len = 0;  
  135.     }  
  136.   
  137.     //釋放socket時，還會檢查、處理backlog隊列中的報文  
  138.     release_sock(sk);  
  139.     //向用戶返回已經拷貝的字節數  
  140.     return copied;  
  141. }  


圖2給出了第2種場景，這裏涉及到prequeue隊列。用戶進程調用recv方法時，鏈接上沒有任何接收並緩存到內核的報文，而socket是阻塞的，因此進程睡眠了。而後網卡中收到了TCP鏈接上的報文，此時prequeue隊列開始產生做用。圖2中tcp_low_latency爲默認的0，套接字socket的SO_RCVLOWAT是默認的1，仍然是阻塞socket，以下圖：

簡單描述上述11個步驟：
一、用戶進程分配了一塊len大小的內存，將其傳入recv這樣的函數，同時socket參數皆爲默認，即阻塞的、SO_RCVLOWAT爲1。調用接收方法，其中flags參數爲0。

二、C庫和內核最終調用到tcp_recvmsg方法來處理。

三、鎖住socket。

四、因爲此時receive、prequeue、backlog隊列都是空的，即沒有拷貝1個字節的消息到用戶內存中，而咱們的最低要求是拷貝至少SO_RCVLOWAT爲1長度的消息。此時，開始進入阻塞式套接字的等待流程。最長等待時間爲SO_RCVTIMEO指定的時間。
這個等待函數叫作sk_wait_data，有必要看下其實現：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. int sk_wait_data(struct sock *sk, long *timeo)  
  2. {  
  3.         //注意，它的自動喚醒條件有兩個，要麼timeo時間到達，要麼receive隊列不爲空  
  4.     rc = sk_wait_event(sk, timeo, !skb_queue_empty(&sk->sk_receive_queue));  
  5. }  

sk_wait_event也值得咱們簡單看下：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. #define sk_wait_event(__sk, __timeo, __condition)       \  
  2. ({  int rc;                         \  
  3.     release_sock(__sk);                 \  
  4.     rc = __condition;                   \  
  5.     if (!rc) {                      \  
  6.         *(__timeo) = schedule_timeout(*(__timeo));  \  
  7.     }                           \  
  8.     lock_sock(__sk);                    \  
  9.     rc = __condition;                   \  
  10.     rc;                         \  
  11. })  

注意，它在睡眠前會調用release_sock，這個方法會釋放socket鎖，使得下面的第5步中，新到的報文再也不只能進入backlog隊列。

五、這個套接字上指望接收的序號也是S1，此時網卡剛好收到了S1-S2的報文，在tcp_v4_rcv方法中，經過調用tcp_prequeue方法把報文插入到prequeue隊列中。

六、插入prequeue隊列後，此時會接着調用wake_up_interruptible方法，喚醒在socket上睡眠的進程。參見tcp_prequque方法。

七、用戶進程被喚醒後，從新調用lock_sock接管了這個socket，此後再進來的報文都只能進入backlog隊列了。

八、進程醒來後，先去檢查receive隊列，固然仍然是空的；再去檢查prequeue隊列，發現有一個報文S1-S2，正好是socket鏈接待拷貝的起始序號S1，因而，從prequeue隊列中取出這個報文並把內容複製到用戶內存中，再釋放內核中的這個報文。

九、目前已經拷貝了S2-S1個字節到用戶態，檢查這個長度是否超過了最低閥值（即len和SO_RCVLOWAT的最小值）。

十、因爲SO_RCVLOWAT使用了默認的1，因此準備返回用戶。此時會順帶再看看backlog隊列中有沒有數據，如有，則檢查這個無序的隊列中是否有能夠直接拷貝給用戶的報文。固然，此時是沒有的。因此準備返回，釋放socket鎖。

十一、返回用戶已經拷貝的字節數。

圖3給出了第3種場景。這個場景中，咱們把系統參數tcp_low_latency設爲1，socket上設置了SO_RCVLOWAT屬性的值。服務器先是收到了S1-S2這個報文，但S2-S1的長度是小於SO_RCVLOWAT的，用戶進程調用recv方法讀套接字時，雖然讀到了一些，但沒有達到最小閥值，因此進程睡眠了，與此同時，在睡眠前收到的亂序的S3-S4包直接進入backlog隊列。此時先到達了S2-S3包，因爲沒有使用prequeue隊列，而它起始序號正是下一個待拷貝的值，因此直接拷貝到用戶內存中，總共拷貝字節數已知足SO_RCVLOWAT的要求！最後在返回用戶前把backlog隊列中S3-S4報文也拷貝給用戶了。以下圖：

簡明描述上述15個步驟：
一、內核收到報文S1-S2，S1正是這個socket鏈接上待接收的序號，所以，直接將它插入有序的receive隊列中。

二、用戶進程所處的linux操做系統上，將sysctl中的tcp_low_latency設置爲1。這意味着，這臺服務器但願TCP進程可以更及時的接收到TCP消息。用戶調用了recv方法接收socket上的消息，這個socket上設置了SO_RCVLOWAT屬性爲某個值n，這個n是大於S2-S1，也就是第1步收到的報文大小。這裏，仍然是阻塞socket，用戶依然是分配了足夠大的len長度內存以接收TCP消息。

三、經過tcp_recvmsg方法來完成接收工做。先鎖住socket，避免併發進程讀取同一socket的同時，也在告訴內核網絡軟中斷處理到這一socket時要有不一樣行爲，如第6步。

四、準備處理內核各個接收隊列中的報文。

五、receive隊列中的有序報文可直接拷貝，在檢查到S2-S1是小於len以後，將報文內容拷貝到用戶態內存中。

六、在第5步進行的同時，socket是被鎖住的，這時內核又收到了一個S3-S4報文，所以報文直接進入backlog隊列。注意，這個報文不是有序的，由於此時鏈接上期待接收序號爲S2。

七、在第5步，拷貝了S2-S1個字節到用戶內存，它是小於SO_RCVLOWAT的，所以，因爲socket是阻塞型套接字（超時時間在本文中忽略），進程將不得不轉入睡眠。轉入睡眠以前，還會幹一件事，就是處理backlog隊列裏的報文，圖2的第4步介紹過休眠方法sk_wait_data，它在睡眠前會執行release_sock方法，看看是如何實現的：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. void fastcall release_sock(struct sock *sk)  
  2. {  
  3.     mutex_release(&sk->sk_lock.dep_map, 1, _RET_IP_);  
  4.   
  5.     spin_lock_bh(&sk->sk_lock.slock);  
  6.         //這裏會遍歷backlog隊列中的每個報文  
  7.     if (sk->sk_backlog.tail)  
  8.         __release_sock(sk);  
  9.         //這裏是網絡中斷執行時，告訴內核，如今socket並不在進程上下文中  
  10.     sk->sk_lock.owner = NULL;  
  11.     if (waitqueue_active(&sk->sk_lock.wq))  
  12.         wake_up(&sk->sk_lock.wq);  
  13.     spin_unlock_bh(&sk->sk_lock.slock);  
  14. }  

再看看__release_sock方法是如何遍歷backlog隊列的：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static void __release_sock(struct sock *sk)  
  2. {  
  3.     struct sk_buff *skb = sk->sk_backlog.head;  
  4.   
  5.         //遍歷backlog隊列  
  6.     do {  
  7.         sk->sk_backlog.head = sk->sk_backlog.tail = NULL;  
  8.         bh_unlock_sock(sk);  
  9.   
  10.         do {  
  11.             struct sk_buff *next = skb->next;  
  12.   
  13.             skb->next = NULL;  
  14.                         //處理報文，其實就是tcp_v4_do_rcv方法，上文介紹過，再也不贅述  
  15.             sk->sk_backlog_rcv(sk, skb);  
  16.   
  17.             cond_resched_softirq();  
  18.   
  19.             skb = next;  
  20.         } while (skb != NULL);  
  21.   
  22.         bh_lock_sock(sk);  
  23.     } while((skb = sk->sk_backlog.head) != NULL);  
  24. }  

此時遍歷到S3-S4報文，但由於它是失序的，因此從backlog隊列中移入out_of_order隊列中（參見上文說過的tcp_ofo_queue方法）。

八、進程休眠，直到超時或者receive隊列不爲空。

九、內核接收到了S2-S3報文。注意，這裏因爲打開了tcp_low_latency標誌位，這個報文是不會進入prequeue隊列以待進程上下文處理的。

十、此時，因爲S2是鏈接上正要接收的序號，同時，有一個用戶進程正在休眠等待接收數據中，且它要等待的數據起始序號正是S2，因而，這種種條件下，使得這一步同時也是網絡軟中斷執行上下文中，把S2-S3報文直接拷貝進用戶內存。

十一、上文介紹tcp_data_queue方法時你們能夠看到，每處理完1個有序報文（不管是拷貝到receive隊列仍是直接複製到用戶內存）後都會檢查out_of_order隊列，看看是否有報文能夠處理。那麼，S3-S4報文剛好是待處理的，因而拷貝進用戶內存。而後喚醒用戶進程。

十二、用戶進程被喚醒了，固然喚醒後會先來拿到socket鎖。如下執行又在進程上下文中了。

1三、此時會檢查已拷貝的字節數是否大於SO_RCVLOWAT，以及backlog隊列是否爲空。二者皆知足，準備返回。

1四、釋放socket鎖，退出tcp_recvmsg方法。

1五、返回用戶已經複製的字節數S4-S1。


好了，這3個場景讀完，想必你們對於TCP的接收流程是怎樣的已經很是清楚了，本文起始的6個問題也在這一大篇中都涉及到了。下一篇咱們來討論TCP鏈接的關閉。

高性能網絡編程4--TCP鏈接的關閉

標籤： tcpcloseshutdown四次握手網絡編程
2013-10-26 12:24  9907人閱讀  評論(2)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。

TCP鏈接的關閉有兩個方法close和shutdown，這篇文章將盡可能精簡的說明它們分別作了些什麼。
爲方便閱讀，咱們能夠帶着如下5個問題來閱讀本文：
一、當socket被多進程或者多線程共享時，關閉鏈接時有何區別？
二、關鏈接時，若鏈接上有來自對端的還未處理的消息，會怎麼處理？
三、關鏈接時，若鏈接上有本進程待發送卻將來得及發送出的消息，又會怎麼處理？
四、so_linger這個功能的用處在哪？
五、對於監聽socket執行關閉，和對處於ESTABLISH這種通信的socket執行關閉，有何區別？

下面分三部分進行：首先說說多線程多進程關閉鏈接的區別；再用一幅流程圖談談close；最後用一幅流程圖說說shutdown。

先不提其原理和實現，從多進程、多線程下 close和shutdown方法調用時的區別提及。
看看close與shutdown這兩個系統調用對應的內核函數：（參見unistd.h文件）
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. #define __NR_close                               3  
  2. __SYSCALL(__NR_close, sys_close)  
  3. #define __NR_shutdown                           48  
  4. __SYSCALL(__NR_shutdown, sys_shutdown)  

但sys_close和sys_shutdown這兩個系統調用最終是由tcp_close和tcp_shutdown方法來實現的，調用過程以下圖所示：

sys_shutdown與多線程和多進程都沒有任何關係，而sys_close則否則，上圖中能夠看到，層層封裝調用中有一個方法叫fput，它有一個引用計數，記錄這個socket被引用了多少次。在說明多線程或者多進程調用close的區別前，先在代碼上簡單看下close是怎麼調用的，對內核代碼沒興趣的同窗能夠僅看fput方法：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. void fastcall fput(struct file *file)  
  2. {  
  3.     if (atomic_dec_and_test(&file->f_count))//檢查引用計數，直到爲0纔會真正去關閉socket  
  4.         __fput(file);  
  5. }  

當這個socket的引用計數f_count不爲0時，是不會觸發到真正關閉TCP鏈接的tcp_close方法的。
那麼，這個引用計數的意義何在呢？爲了說明它，先要說道下進程與線程的區別。

你們知道，所謂線程其實就是「輕量級」的進程。建立進程只能是一個進程（父進程）建立另外一個進程（子進程），子進程會複製父進程的資源，這裏的」複製「針對不一樣的資源其意義是不一樣的，例如對內存、文件、TCP鏈接等。建立進程是由clone系統調用實現的，而建立線程時一樣也是clone實現的，只不過clone的參數不一樣，其行爲也很不一樣。這個話題是很大的，這裏咱們僅討論下TCP鏈接。
在clone系統調用中，會調用方法copy_files來拷貝文件描述符（包括socket）。建立線程時，傳入的flag參數中包含標誌位CLONE_FILES，此時，線程將會共享父進程中的文件描述符。而建立進程時沒有這個標誌位，這時，會把進程打開的全部文件描述符的引用計數加1，即把file數據結構的f_count成員加1，以下：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static int copy_files(unsigned long clone_flags, struct task_struct * tsk)  
  2. {  
  3.     if (clone_flags & CLONE_FILES) {  
  4.         goto out;//建立線程  
  5.     }  
  6.     newf = dup_fd(oldf, &error);  
  7. out:  
  8.     return error;  
  9. }  

再看看dup_fd方法：
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. static struct files_struct *dup_fd(struct files_struct *oldf, int *errorp)  
  2. {  
  3.     for (i = open_files; i != 0; i--) {  
  4.         struct file *f = *old_fds++;  
  5.         if (f) {  
  6.             get_file(f);//建立進程  
  7.         }  
  8.     }  
  9. }  

get_file宏就會加引用計數。
[cpp]  view plain  copy
 
  在CODE上查看代碼片 派生到個人代碼片
  1. #define get_file(x) atomic_inc(&(x)->f_count)  

因此，子進程會將父進程中已經創建的socket加上引用計數。當進程中close一個socket時，只會減小引用計數，僅當引用計數爲0時纔會觸發tcp_close。

到這裏，對於第一個問題的close調用天然有告終論：單線程（進程）中使用close與多線程中是一致的，但這二者與多進程的行爲並不一致，多進程中共享的同一個socket必須都調用了close纔會真正的關閉鏈接。

而shutdown則否則，這裏是沒有引用計數什麼事的，只要調用了就會去試圖按需關閉鏈接。因此，調用shutdown與多線程、多進程無關。


下面咱們首先深刻探討下close的行爲，由於close比較shutdown來講要複雜許多。順便回答其他四個問題。
TCP鏈接是一種雙工的鏈接，何謂雙工？即鏈接雙方能夠並行的發送或者接收消息，而無須顧及對方此時到底在發仍是收消息。這樣，關閉鏈接時，就存在3種情形：徹底關閉鏈接；關閉發送消息的功能；關閉接收消息的功能。其中，後二者就叫作半關閉，由shutdown實現（因此 shutdown多出一個參數正是控制關閉發送或者關閉接收），前者由close實現。

TCP鏈接是一種可靠的鏈接，在這裏能夠這麼理解：既要確認本機發出的包獲得確認，又要確認收到的任何消息都已告知鏈接的對端。
如下主要從雙工、可靠性這兩點上理解鏈接的關閉。

TCP雙工的這個特性使得鏈接的正常關閉須要四次握手，其含義爲：主動端關閉了發送的功能；被動端承認；被動端也關閉了發送的功能；主動端承認。
但還存在程序異常的情形，此時，則經過異常的那端發送RST復位報文通知另外一端關閉鏈接。
下圖是close的主要流程：

這個圖稍複雜，這是由於它覆蓋了關閉監聽句柄、關閉普通鏈接、關閉設置了SO_LINGER的鏈接這三種主要場景。

1）關閉監聽句柄
先從最右邊的分支說說關閉監聽socket的那些事。用於listen的監聽句柄也是使用close關閉，關閉這樣的句柄含義固然很不一樣，它自己並不對應着某個TCP鏈接，可是，附着在它之上的卻可能有半成品鏈接。什麼意思呢？以前說過TCP是雙工的，它的打開須要三次握手，三次握手也就是3個步驟，其含義爲：客戶端打開接收、發送的功能；服務器端承認並也打開接收、發送的功能；客戶端承認。當第一、2步驟完成、第3步步驟未完成時，就會在服務器上有許多半鏈接，close這個操做主要是清理這些鏈接。
參照上圖，close首先會移除keepalive定時器。keepalive功能經常使用於服務器上，防止僵死、異常退出的客戶端佔用服務器鏈接資源。移除此定時器後，若ESTABLISH狀態的TCP鏈接在tcp_keepalive_time時間（如服務器上常配置爲2小時）內沒有通信，服務器就會主動關閉鏈接。
接下來，關閉每個半鏈接。如何關閉半鏈接？這時固然不能發FIN包，即正常的四次握手關閉鏈接，而是會發送RST復位標誌去關閉請求。處理完全部半打開的鏈接close的任務就基本完成了。

2）關閉普通ESTABLISH狀態的鏈接（未設置so_linger）
首先檢查是否有接收到卻未處理的消息。
若是close調用時存在收到遠端的、沒有處理的消息，這時根據close這一行爲的意義，是要丟棄這些消息的。但丟棄消息後，意味着鏈接遠端誤覺得發出的消息已經被本機收處處理了（由於ACK包確認過了），但實際上確是收到未處理，此時也不能使用正常的四次握手關閉，而是會向遠端發送一個RST非正常復位關閉鏈接。這個作法的依據請參考draft-ietf-tcpimpl-prob-03.txt文檔3.10節， Failure to RST on close with data pending。因此，這也要求咱們程序員在關閉鏈接時，要確保已經接收、處理了鏈接上的消息。

若是此時沒有未處理的消息，那麼進入發送FIN來關閉鏈接的階段。
這時，先看看是否有待發送的消息。前一篇已經說過，發消息時要計算滑動窗口、擁塞窗口、angle算法等，這些因素可能致使消息會延遲發送的。若是有待發送的消息，那麼要盡力保證這些消息都發出去的。因此，會在最後一個報文中加入FIN標誌，同時，關閉用於減小網絡中小報文的angle算法，向鏈接對端發送消息。若是沒有待發送的消息，則構造一個報文，僅含有FIN標誌位，發送出去關閉鏈接。

3）使用了so_linger的鏈接
首先要澄清，爲什麼要有so_linger這個功能？由於咱們可能有強可靠性的需求，也就是說，必須確保發出的消息、FIN都被對方收到。例如，有些響應發出後調用close關閉鏈接，接下來就會關閉進程。若是close時發出的消息其實丟失在網絡中了，那麼，進程忽然退出時鏈接上發出的RST就可能被對方收到，並且，以前丟失的消息不會有重發來保障可靠性了。
so_linger用來保證對方收到了close時發出的消息，即，至少須要對方經過發送ACK且到達本機。
怎麼保證呢？等待！close會阻塞住進程，直到確認對方收到了消息再返回。然而，網絡環境又得複雜的，若是對方老是不響應怎麼辦？因此還須要l_linger這個超時時間，控制close阻塞進程的最長時間。注意，務必慎用so_linger，它會在不經意間下降你程序中代碼的執行速度（close的阻塞）。

因此，當這個進程設置了so_linger後，前半段依然沒變化。檢查是否有未讀消息，如有則發RST關鏈接，不會觸發等待。接下來檢查是否有未發送的消息時與第2種情形一致，設好FIN後關閉angle算法發出。接下來，則會設置最大等待時間l_linger，而後開始將進程睡眠，直到確認對方收到後纔會醒來，將控制權交還給用戶進程。

這裏須要注意，so_linger不是確保鏈接被四次握手關閉再使close返回，而只是保證我方發出的消息都已被對方收到。例如，若對方程序寫的有問題，當它收到FIN進入CLOSE_WAIT狀態，卻一直不調用close發出FIN，此時，對方仍然會經過ACK確認，我方收到了ACK進入FIN_WAIT2狀態，但沒收到對方的FIN，我方的close調用卻不會再阻塞，close直接返回，控制權交還用戶進程。

從上圖可知，so_linger還有個偏門的用法，若l_linger超時時間竟被設爲0，則不會觸發FIN包的發送，而是直接RST復位關閉鏈接。我我的認爲，這種玩法確沒多大用處。


最後作個總結。調用close時，可能致使發送RST復位關閉鏈接，例若有未讀消息、打開so_linger但l_linger卻爲0、關閉監聽句柄時半打開的鏈接。更多時會致使發FIN來四次握手關閉鏈接，但打開so_linger可能致使close阻塞住等待着對方的ACK代表收到了消息。

最後來看看較爲簡單的shutdown。

解釋下上圖：
1）shutdown可攜帶一個參數，取值有3個，分別意味着：只關閉讀、只關閉寫、同時關閉讀寫。
對於監聽句柄，若是參數爲關閉寫，顯然沒有任何意義。但關閉讀從某方面來講是有意義的，例如再也不接受新的鏈接。看看最右邊藍色分支，針對監聽句柄，若參數爲關閉寫，則不作任何事；若爲關閉讀，則把端口上的半打開鏈接使用RST關閉，與close一模一樣。
2）若shutdown的是半打開的鏈接，則發出RST來關閉鏈接。
3）若shutdown的是正常鏈接，那麼關閉讀其實與對端是沒有關係的。只要本機把接收掉的消息丟掉，其實就等價於關閉讀了，並不必定非要對端關閉寫的。實際上，shutdown正是這麼幹的。若參數中的標誌位含有關閉讀，只是標識下，當咱們調用read等方法時這個標識就起做用了，會使進程讀不到任何數據。
4）若參數中有標誌位爲關閉寫，那麼下面作的事與close是一致的：發出FIN包，告訴對方，本機不會再發消息了。


以上，就是close與shutdown的主要行爲，同時也回答了本文最初的5個問題。下一篇，咱們開始討論多路複用中常見的epoll。

高性能網絡編程5--IO複用與併發編程

標籤： epoll網絡編程高性能邊緣觸發ET
2013-12-04 15:57  13784人閱讀  評論(4)  收藏  舉報
  分類：
 
   

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。

對於服務器的併發處理能力，咱們須要的是：每一毫秒服務器都能及時處理這一毫秒內收到的數百個不一樣TCP鏈接上的報文，與此同時，可能服務器上還有數以十萬計的最近幾秒沒有收發任何報文的相對不活躍鏈接。同時處理多個並行發生事件的鏈接，簡稱爲併發；同時處理萬計、十萬計的鏈接，則是高併發。服務器的併發編程所追求的就是處理的併發鏈接數目無限大，同時維持着高效率使用CPU等資源，直至物理資源首先耗盡。

併發編程有不少種實現模型，最簡單的就是與「線程」捆綁，1個線程處理1個鏈接的所有生命週期。優勢：這個模型足夠簡單，它能夠實現複雜的業務場景，同時，線程個數是能夠遠大於CPU個數的。然而，線程個數又不是能夠無限增大的，爲何呢？由於線程何時執行是由操做系統內核調度算法決定的，調度算法並不會考慮某個線程可能只是爲了一個鏈接服務的，它會作大一統的玩法：時間片到了就執行一下，哪怕這個線程一執行就會不得不繼續睡眠。這樣來回的喚醒、睡眠線程在次數很少的狀況下，是廉價的，但若是操做系統的線程總數不少時，它就是昂貴的（被放大了），由於這種技術性的調度損耗會影響到線程上執行的業務代碼的時間。舉個例子，這時大部分擁有不活躍鏈接的線程就像咱們的國企，它們執行效率過低了，它老是喚醒就睡眠在作無用功，而它喚醒爭到CPU資源的同時，就意味着處理活躍鏈接的民企線程減小得到了CPU的機會，CPU是核心競爭力，它的無效率進而影響了GDP總吞吐量。咱們所追求的是併發處理數十萬鏈接，當幾千個線程出現時，系統的執行效率就已經沒法知足高併發了。

對高併發編程，目前只有一種模型，也是本質上惟一有效的玩法。
從這個系列的前4篇文章可知，鏈接上的消息處理，能夠分爲兩個階段：等待消息準備好、消息處理。當使用默認的阻塞套接字時（例如上面提到的1個線程捆綁處理1個鏈接），每每是把這兩個階段合而爲一，這樣操做套接字的代碼所在的線程就得睡眠來等待消息準備好，這致使了高併發下線程會頻繁的睡眠、喚醒，從而影響了CPU的使用效率。

高併發編程方法固然就是把兩個階段分開處理。即，等待消息準備好的代碼段，與處理消息的代碼段是分離的。固然，這也要求套接字必須是非阻塞的，不然，處理消息的代碼段很容易致使條件不知足時，所在線程又進入了睡眠等待階段。那麼問題來了，等待消息準備好這個階段怎麼實現？它畢竟仍是等待，這意味着線程仍是要睡眠的！解決辦法就是，線程主動查詢，或者讓1個線程爲全部鏈接而等待！
這就是IO多路複用了。多路複用就是處理等待消息準備好這件事的，但它能夠同時處理多個鏈接！它也可能「等待」，因此它也會致使線程睡眠，然而這沒關係，由於它一對多、它能夠監控全部鏈接。這樣，當咱們的線程被喚醒執行時，就必定是有一些鏈接準備好被咱們的代碼執行了，這是有效率的！沒有那麼多個線程都在爭搶處理「等待消息準備好」階段，整個世界終於清淨了！

多路複用有不少種實現，在linux上，2.4內核前主要是select和poll，如今主流是epoll，它們的使用方法彷佛很不一樣，但本質是同樣的。
效率卻也不一樣，這也是epoll徹底替代了select的緣由。

簡單的談下epoll爲什麼會替代select。
前面提到過，高併發的核心解決方案是1個線程處理全部鏈接的「等待消息準備好」，這一點上epoll和select是無爭議的。但select預估錯誤了一件事，就像咱們開篇所說，當數十萬併發鏈接存在時，可能每一毫秒只有數百個活躍的鏈接，同時其他數十萬鏈接在這一毫秒是非活躍的。select的使用方法是這樣的：
返回的活躍鏈接 ==select（所有待監控的鏈接）
何時會調用select方法呢？在你認爲須要找出有報文到達的活躍鏈接時，就應該調用。因此，調用select在高併發時是會被頻繁調用的。這樣，這個頻繁調用的方法就頗有必要看看它是否有效率，由於，它的輕微效率損失都會被「頻繁」二字所放大。它有效率損失嗎？顯而易見，所有待監控鏈接是數以十萬計的，返回的只是數百個活躍鏈接，這自己就是無效率的表現。被放大後就會發現，處理併發上萬個鏈接時，select就徹底力不從心了。

看幾個圖。當併發鏈接爲一千如下，select的執行次數不算頻繁，與epoll彷佛並沒有多少差距：

然而，併發數一旦上去，select的缺點被「執行頻繁」無限放大了，且併發數越多越明顯：

再來講說epoll是如何解決的。它很聰明的用了3個方法來實現select方法要作的事：
新建的epoll描述符==epoll_create()
epoll_ctrl(epoll描述符，添加或者刪除全部待監控的鏈接)
返回的活躍鏈接 ==epoll_wait（ epoll描述符 ）
這麼作的好處主要是：分清了頻繁調用和不頻繁調用的操做。例如，epoll_ctrl是不太頻繁調用的，而epoll_wait是很是頻繁調用的。這時，epoll_wait卻幾乎沒�
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程