我們繼續(xù)探索高性能網絡編程,但是我覺得在談系統(tǒng)API之前可以先講一些Linux底層的收發(fā)包過程,如下這是一個簡單的socket編程代碼:
int main() {
...
fd = socket(AF_INET, SOCKET_STREAM, 0);
bind(fd, ...);
listen(fd, ...);
// 如何建立連接
...
afd = accept(fd, ...);
// 如何接收數(shù)據(jù)
...
read(afd, ...);
// 如何發(fā)送數(shù)據(jù)
...
send(afd, ...);
// 如何關閉連接
...
close(fd);
...
}
第一部分:如何建立連接
從上一篇文章我們介紹了網絡協(xié)議,我們知道TCP/IP協(xié)議族劃分了應用層、TCP傳輸層、IP網絡層、鏈路層(以太層驅動)。
如上圖看應用層,通常在網絡編程中我們需要調用accept
的API建立TCP連接,那TCP如何做的呢?
從上圖的流程可以看到:
(1)client端發(fā)起TCP握手,發(fā)送syn包;
(2)內核收到包以后先將當前連接的信息插入到網絡的SYN隊列;
(3)插入成功后會返回握手確認(SYN+ACK);
(4)client端如果繼續(xù)完成TCP握手,回復ACK確認;
(5)內核會將TCP握手完成的包,先將對應的連接信息從SYN隊列取出;
(6)將連接信息丟入到ACCEPT隊列;
(7)應用層sever通過系統(tǒng)調用accept
就能拿到這個連接,整個網絡套接字連接完成;
那基于這個圖,我想問問讀者這里會有什么問題么?
細心的讀者應該可以看出:
1、這里有兩個隊列,必然會有滿的情況,那如果遇到這種情況內核是怎么處理的呢?
(1)如果SYN隊列滿了,內核就會丟棄連接;
(2)如果ACCEPT隊列滿了,那內核不會繼續(xù)將SYN隊列的連接丟到ACCEPT隊列,如果SYN隊列足夠大,client端后續(xù)收發(fā)包就會超時;
(3)如果SYN隊列滿了,就會和(1)一樣丟棄連接;
2、如何控制SYN隊列和ACCEPT隊列的大???
(1)內核2.2版本之前通過listen
的backlog可以設置SYN隊列(半連接狀態(tài)SYN_REVD)和ACCEPT隊列(完全連接狀態(tài)ESTABLISHED)的上限;
(2)內核2.2版本以后backlog只是表示ACCEPT隊列上限,SYN隊列的上限可以通過/proc/sys/net/ipv4/tcp_max_syn_backlog
設置;
3、server端通過accept
一直等,豈不是會卡住收包的線程?
在linux網絡編程中我們都會追求高性能,accept
如果卡住接收線程,性能會上不去,所以socket
編程中就會有阻塞和非阻塞模式。
(1)阻塞模式下的accept
就會卡住,當前線程什么事情都干不了;
(2)非阻塞模式下,可以通過輪詢accept
去處理其他的事情,如果返回EAGAIN,就是ACCEPT隊列為空,如果返回連接信息,就是可以處理當前連接;
第二部分:接收數(shù)據(jù)
(1)當網卡接收到報文并判斷為TCP協(xié)議后,將會調用到內核的tcp_v4_rcv
方法,如果數(shù)據(jù)按順序收到S1
數(shù)據(jù)包,則直接插入receive隊列中;
(2)當收到了S3
數(shù)據(jù)包,在第1步結束后,應該收到S2
序號,但是報文是亂序進來的,則將S3
插入out_of_order隊列(這個隊列存儲亂序報文);
(3)接下來收到S2
數(shù)據(jù)包,如第1步直接進入receive隊列,由于此時out_of_order隊列不像第1步是空的,所以引發(fā)了接來的第4步;
(4)每次向receive隊列插入報文時都會檢查out_of_order隊列,如果遇到期待的序號S3
,則從out_of_order隊列摘除,寫入到receive隊列;
(5)現(xiàn)在應用程序開始調用recv
方法;
(6)經過層層封裝調用,接收TCP消息最終會走到tcp_recvmsg
方法;
(7)現(xiàn)在需要拷貝數(shù)據(jù)從內核態(tài)到用戶態(tài),如果receive隊列為空,會先檢查SO_RCVLOWAT這個閥值(0表示收到指定的數(shù)據(jù)返回,1表示只要讀取到數(shù)據(jù)就返回,系統(tǒng)默認是1),如果已經拷貝的字節(jié)數(shù)到現(xiàn)在還小于它,那么可能導致進程會休眠,等待拷貝更多的數(shù)據(jù);
(8)將數(shù)據(jù)從內核態(tài)拷貝到用戶態(tài),recv
返回拷貝數(shù)據(jù)的大小;
(9)為了選擇降低網絡包延時或者提升吞吐量,系統(tǒng)提供了tcp_low_latency
參數(shù),如果為0值,用戶暫時沒有讀數(shù)據(jù)則數(shù)據(jù)包進入prequeue隊列,提升吞吐量,否則不使用prequeue隊列,進入tcp_v4_do_rcv
,降低延時;
第三部分:發(fā)送數(shù)據(jù)
(1)假設調用send
方法來發(fā)送大于一個MSS(比如2K)的數(shù)據(jù);
(2)內核調用tcp_sendmsg
,實現(xiàn)復制數(shù)據(jù),寫入隊列和組裝tcp協(xié)議頭;
(3)在調用tcp_sendmsg
先需要在內核獲取skb,將用戶態(tài)數(shù)據(jù)拷貝到內核態(tài),內核真正執(zhí)行報文的發(fā)送,與send
方法的調用并不是同步的,即send
方法返回成功,也不一定把IP報文都發(fā)送到網絡中了。因此,需要把用戶需要發(fā)送的用戶態(tài)內存中的數(shù)據(jù),拷貝到內核態(tài)內存中,不依賴于用戶態(tài)內存,也使得進程可以快速釋放發(fā)送數(shù)據(jù)占用的用戶態(tài)內存。但這個拷貝操作并不是簡單的復制,而是把待發(fā)送數(shù)據(jù),按照MSS來劃分成多個盡量達到MSS大小的分片報文段,復制到內核中的sk_buff結構來存放;
(4)將數(shù)據(jù)拷貝到發(fā)送隊列中tcp_write_queue
;
(5)調用tcp_push
發(fā)送數(shù)據(jù)到IP層,這里主要滑動窗口,慢啟動,擁塞窗口的控制和判斷是否使用Nagle算法合并小報文(上一篇已經有介紹);
(6)組裝IP報文頭,通過經過iptables
或者tcpdump
等netfilter模塊過濾,將數(shù)據(jù)交給鄰居子系統(tǒng)(主要功能是查找需要發(fā)送的MAC地址,發(fā)送arp請求,封裝MAC頭等);
(7)調用網卡驅動程序將數(shù)據(jù)發(fā)送出去;
第四部分:關閉連接
關閉連接就是TCP揮手過程,我們都知道TCP連接是一種可靠的連接,那如何才能完整可靠的完成關閉連接呢?linux系統(tǒng)提供了兩個函數(shù):
close
對應tcp_close
方法,通過減少socket的引用次數(shù)實現(xiàn)關閉,僅當引用計數(shù)為0時才會觸發(fā)tcp_close;shutdown
對應tcp_shutdown
方法,不關心socket被引用次數(shù),直接關閉對應的連接;
(1)shutdown可攜帶一個參數(shù),取值有3個,分別意味著:只關閉讀、只關閉寫、同時關閉讀寫;
(2)若shutdown的是半打開的連接,則發(fā)出RST來關閉連接;
(3)若shutdown的是正常連接,那么關閉讀其實與對端是沒有關系的;
(4)若參數(shù)中有標志位為關閉寫,那么下面做的事與close是一致的,發(fā)出FIN包,告訴對方本機不會再發(fā)消息了;
-
驅動器
+關注
關注
53文章
8290瀏覽量
147162 -
連接器
+關注
關注
98文章
14694瀏覽量
137347 -
Linux系統(tǒng)
+關注
關注
4文章
596瀏覽量
27526 -
RST
+關注
關注
0文章
31瀏覽量
7427 -
TCP通信
+關注
關注
0文章
146瀏覽量
4295
發(fā)布評論請先 登錄
相關推薦
MCBSP的收發(fā)過程是如何運行的
求大神詳細介紹一下FPGA嵌入式系統(tǒng)開發(fā)過程中的XBD文件設計
談一下在單片機開發(fā)過程中使用過的幾種調試方案
nodemcu的開發(fā)過程是怎樣的
資源約束下產品開發(fā)過程仿真模型
掌握串口通信協(xié)議的收發(fā)過程
![掌握串口通信協(xié)議的<b class='flag-5'>收發(fā)過程</b>](https://file.elecfans.com/web1/M00/EA/15/o4YBAGBz8reANNgwAAAqv7TxtzA206.jpg)
Linux TCP底層的收發(fā)過程講解
![Linux <b class='flag-5'>TCP</b><b class='flag-5'>底層</b>的<b class='flag-5'>收發(fā)過程</b>講解](https://file1.elecfans.com/web2/M00/8E/A5/wKgZomTIz0GAA-4nAADUpMkvekA622.jpg)
評論