TCP之深入淺出send和recv


在這篇文章中,我用深入淺出socket選項行為中的4個選項來介紹send和recv的行為

SO_RCVBUF SO_SNDBUF

先明確一個概念:每個TCP socket在內核中都有一個發送緩沖區和一個接收緩沖區,TCP的全雙工的工作模式以及TCP的滑動窗口便是依賴於這兩個獨立的buffer以及此buffer的填充狀態。接收緩沖區把數據緩存入內核,應用進程一直沒有調用read進行讀取的話,此數據會一直緩存在相應socket的接收緩沖區內。再啰嗦一點,不管進程是否讀取socket,對端發來的數據都會經由內核接收並且緩存到socket的內核接收緩沖區之中。read所做的工作,就是把內核緩沖區中的數據拷貝到應用層用戶的buffer里面,僅此而已。進程調用send發送的數據的時候,最簡單情況(也是一般情況),將數據拷貝進入socket的內核發送緩沖區之中,然后send便會在上層返回。換句話說,send返回之時,數據不一定會發送到對端去(和write寫文件有點類似),send僅僅是把應用層buffer的數據拷貝進socket的內核發送buffer中。后續我會專門用一篇文章介紹read和send所關聯的內核動作。每個UDP socket都有一個接收緩沖區,沒有發送緩沖區,從概念上來說就是只要有數據就發,不管對方是否可以正確接收,所以不緩沖,不需要發送緩沖區。

接收緩沖區被TCP和UDP用來緩存網絡上來的數據,一直保存到應用進程讀走為止。對於TCP,如果應用進程一直沒有讀取,buffer滿了之后,發生的動作是:通知對端TCP協議中的窗口關閉。這個便是滑動窗口的實現。保證TCP套接口接收緩沖區不會溢出,從而保證了TCP是可靠傳輸。因為對方不允許發出超過所通告窗口大小的數據。 這就是TCP的流量控制,如果對方無視窗口大小而發出了超過窗口大小的數據,則接收方TCP將丟棄它。 UDP:當套接口接收緩沖區滿時,新來的數據報無法進入接收緩沖區,此數據報就被丟棄。UDP是沒有流量控制的;快的發送者可以很容易地就淹沒慢的接收者,導致接收方的UDP丟棄數據報。
以上便是TCP可靠,UDP不可靠的實現。

TCP_CORK TCP_NODELAY

這兩個選項是互斥的,打開或者關閉TCP的nagle算法,下面用場景來解釋

典型的webserver向客戶端的應答,應用層代碼實現流程粗略來說,一般如下所示:

  if(條件1{

     buffer_last_modified填充協議內容“Last-Modified: Sat, 04 May 2012 05:28:58 GMT”;

     sendbuffer_last_modified);

  }

 

   if(條件2{

     buffer_expires填充協議內容“Expires: Mon, 14 Aug 2023 05:17:29 GMT”;

     sendbuffer_expires);

   }

 

   。。。

   if(條件N{

     buffer_N填充協議內容“。。。”;

     sendbuffer_N);

   }

 

對於這樣的實現,當前的http應答在執行這段代碼時,假設有M(M<=N)個條件都滿足,那么會有連續的M個send調用,那是不是下層會依次向客戶端發出M個TCP包呢?答案是否定的,包的數目在應用層是無法控制的,並且應用層也是不需要控制的。

我用下列四個假設場景來解釋一下這個答案

由於TCP是流式的,對於TCP而言,每個TCP連接只有syn開始和fin結尾,中間發送的數據是沒有邊界的,多個連續的send所干的事情僅僅是:

假如socket的文件描述符被設置為阻塞方式,而且發送緩沖區還有足夠空間容納這個send所指示的應用層buffer的全部數據,那么把這些數據從應用層的buffer,拷貝到內核的發送緩沖區,然后返回。

 

假如socket的文件描述符被設置為阻塞方式,但是發送緩沖區沒有足夠空間容納這個send所指示的應用層buffer的全部數據,那么能拷貝多少就拷貝多少,然后進程掛起,等到TCP對端的接收緩沖區有空余空間時,通過滑動窗口協議(ACK包的又一個作用----打開窗口)通知TCP本端:“親,我已經做好准備,您現在可以繼續向我發送X個字節的數據了”,然后本端的內核喚醒進程,繼續向發送緩沖區拷貝剩余數據,並且內核向TCP對端發送TCP數據,如果send所指示的應用層buffer中的數據在本次仍然無法全部拷貝完,那么過程重復。。。直到所有數據全部拷貝完,返回。

請注意,對於send的行為,我用了“拷貝一次”,send和下層是否發送數據包,沒有任何關系。

 

假如socket的文件描述符被設置為非阻塞方式,而且發送緩沖區還有足夠空間容納這個send所指示的應用層buffer的全部數據,那么把這些數據從應用層的buffer,拷貝到內核的發送緩沖區,然后返回。

 

假如socket的文件描述符被設置為非阻塞方式,但是發送緩沖區沒有足夠空間容納這個send所指示的應用層buffer的全部數據,那么能拷貝多少就拷貝多少,然后返回拷貝的字節數。多涉及一點,返回之后有兩種處理方式:

1.死循環,一直調用send,持續測試,一直到結束(基本上不會這么搞)。

2.非阻塞搭配epoll或者select,用這兩種東西來測試socket是否達到可發送的活躍狀態,然后調用send(高性能服務器必需的處理方式)。

 

綜上,以及請參考本文前述的SO_RCVBUF和SO_SNDBUF,你會發現,在實際場景中,你能發出多少TCP包以及每個包承載多少數據,除了受到自身服務器配置和環境帶寬影響,對端的接收狀態也能影響你的發送狀況。

 

至於為什么說“應用層也是不需要控制發送行為的”,這個說法的原因是:

軟件系統分層處理、分模塊處理各種軟件行為,目的就是為了各司其職,分工。應用層只關心業務實現,控制業務。數據傳輸由專門的層面去處理,這樣應用層開發的規模和復雜程度會大為降低,開發和維護成本也會相應降低。

 

再回到發送的話題上來:)之前說應用層無法精確控制和完全控制發送行為,那是不是就是不控制了?非也!雖然無法控制,但也要盡量控制!

如何盡量控制?現在引入本節主題----TCP_CORK和TCP_NODELAY。

cork:塞子,塞住

nodelay:不要延遲

 

TCP_CORK:盡量向發送緩沖區中攢數據,攢到多了再發送,這樣網絡的有效負載會升高。簡單粗暴地解釋一下這個有效負載的問題。假如每個包中只有一個字節的數據,為了發送這一個字節的數據,再給這一個字節外面包裝一層厚厚的TCP包頭,那網絡上跑的幾乎全是包頭了,有效的數據只占其中很小的部分,很多訪問量大的服務器,帶寬可以很輕松的被這么耗盡。那么,為了讓有效負載升高,我們可以通過這個選項指示TCP層,在發送的時候盡量多攢一些數據,把他們填充到一個TCP包中再發送出去。這個和提升發送效率是相互矛盾的,空間和時間總是一堆冤家!!

TCP_NODELAY:盡量不要等待,只要發送緩沖區中有數據,並且發送窗口是打開的,就盡量把數據發送到網絡上去。

 

很明顯,兩個選項是互斥的。實際場景中該怎么選擇這兩個選項呢?再次舉例說明

webserver,,下載服務器(ftp的發送文件服務器),需要帶寬量比較大的服務器,用TCP_CORK。

涉及到交互的服務器,比如ftp的接收命令的服務器,必須使用TCP_NODELAY。默認是TCP_CORK。設想一下,用戶每次敲幾個字節的命令,而下層在攢這些數據,想等到數據量多了再發送,這樣用戶會等到發瘋。這個糟糕的場景有個專門的詞匯來形容-----粘(nian拼音二聲)包。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com