從TCP協(xié)議到TCP通信的各種異常現(xiàn)象和分析(上)
很多人總覺得學(xué)習(xí)TCP/IP協(xié)議沒什么用,覺得日常編程開發(fā)只需要知道socket接口怎么用就可以了。如果大家定位過線上問題就會知道,實(shí)際上并非如此。如果應(yīng)用在局域網(wǎng)內(nèi),且設(shè)備一切正常的情況下可能確實(shí)如此,但如果一旦出現(xiàn)諸如中間交換機(jī)不穩(wěn)定、物理服務(wù)器宕機(jī)或者其它異常情況時(shí),此時(shí)引起的問題如果只停留在套接字接口的理解層面將無法解決。因此,深入理解TCP/IP協(xié)議,對我們分析異常問題有很大的幫助。
下圖是網(wǎng)絡(luò)通信中常見的架構(gòu),也就是CS架構(gòu)。其中程序包括兩部分,分別為客戶端(Client)和服務(wù)端(Server)。當(dāng)然,實(shí)際的環(huán)境還要復(fù)雜的多,在客戶端和服務(wù)端之間可能有多種不同種類和數(shù)量的設(shè)備,這些設(shè)備都會增加網(wǎng)絡(luò)通信的復(fù)雜性。自然,也會增加程序開發(fā)容錯(cuò)的復(fù)雜性。
圖1 基本架構(gòu)
TCP的基本流程
在分析異常情況之前,我們先回憶一下TCP協(xié)議的基本邏輯。在客戶端和服務(wù)端能夠收發(fā)數(shù)據(jù)之前首先必需建立連接。連接的建立在協(xié)議層面也是通過收發(fā)數(shù)據(jù)包完成,只不過在用戶層面就是客戶端調(diào)用了一個(gè)connect函數(shù)。連接的過程俗稱“三次握手”,具體流程如圖2所示。
圖2 TCP的三次握手流程
TCP連接的斷開也是比較復(fù)雜的,需要經(jīng)過所謂的“四次揮手”的流程。其原因是因?yàn)門CP是雙工通信,分別需要從客戶端和服務(wù)端2側(cè)斷開連接。
圖3 TCP的四次揮手
另外一個(gè)比較重要的內(nèi)容是TCP協(xié)議的狀態(tài)轉(zhuǎn)換,理解了這個(gè)內(nèi)容,我們才能清楚出現(xiàn)各種異常情況下數(shù)據(jù)包的內(nèi)容。
圖4 TCP狀態(tài)轉(zhuǎn)換圖
本文只是簡單回憶一下TCP的基本流程,詳細(xì)的內(nèi)容可以參考本號之前的文章《從TCP到Socket,徹底理解網(wǎng)絡(luò)編程是怎么回事》
異常情況分析
了解了TCP的基本流程之后,我們再看一下各種異常情況。這些異常情況才是我們在后續(xù)解決問題的時(shí)候的關(guān)鍵。了解了這些異常情況及原理,后面解決問題才能游刃有余。
1. 試圖與一個(gè)不存在的端口建立連接(主機(jī)正常)
這里的不存在的端口是指在服務(wù)器端沒有程序監(jiān)聽在該端口。我們的客戶端就調(diào)用connect,試圖與其建立連接。這時(shí)會發(fā)生什么呢?
這種情況下我們在客戶端通常會收到如下異常內(nèi)容:
- [Errno 111] Connection refused(連接拒絕)
具體含義可以查一下Linux的相關(guān)手冊,或者用搜索引擎搜索一下。試想一下,服務(wù)端本來就沒有程序監(jiān)聽在這個(gè)接口,因此在服務(wù)端是無法完成連接的建立過程的。我們參考‘三次握手’的流程可以知道當(dāng)客戶端的SYNC包到達(dá)服務(wù)端時(shí),TCP協(xié)議沒有找到監(jiān)聽的套接字,就會向客戶端發(fā)送一個(gè)錯(cuò)誤的報(bào)文,告訴客戶端產(chǎn)生了錯(cuò)誤。而該錯(cuò)誤報(bào)文就是一個(gè)包含RST的報(bào)文。這種異常情況也很容易模擬,我們只需要寫一個(gè)小程序,連接服務(wù)器上沒有監(jiān)聽的端口即可。如下是通過wireshark捕獲的數(shù)據(jù)包,可以看到紅色部分的RST報(bào)文。
圖5 數(shù)據(jù)包截圖
繼續(xù)深入理解一下,在操作系統(tǒng)層面,TCP的服務(wù)端實(shí)際上就是從網(wǎng)卡的寄存器中讀取數(shù)據(jù),然后進(jìn)行解析。對于TCP自然會解析出目的端口這個(gè)關(guān)鍵信息,然后根據(jù)這個(gè)信息查看有沒有這樣的套接字。這個(gè)套接字是什么呢?在用戶層面是一個(gè)文件句柄,但在內(nèi)核中實(shí)際是一個(gè)數(shù)據(jù)結(jié)構(gòu),里面記錄了很多信息。這個(gè)數(shù)據(jù)結(jié)構(gòu)存儲在一個(gè)哈希表中,通過函數(shù)__inet_lookup_skb(net/inet_hashtables.h)可以實(shí)現(xiàn)對該數(shù)據(jù)結(jié)構(gòu)的查找。對于上述情況,自然無法找到該套接字,因此TCP服務(wù)端會進(jìn)行錯(cuò)誤處理,處理的方式就是給客戶端發(fā)送一個(gè)RST(通過函數(shù)tcp_v4_send_reset進(jìn)行發(fā)送)。
2. 試圖與一個(gè)某端口建立連接但該主機(jī)已經(jīng)宕機(jī)(主機(jī)宕機(jī))
這也是一種比較常見的情況,當(dāng)某臺服務(wù)器主機(jī)宕機(jī)了,而客戶端并不知道,仍然嘗試去與其建立連接。這種場景也是分為2種情況的,一種是剛剛宕機(jī),另外一種是宕機(jī)了很長時(shí)間。為什么要分這2種情況?
這主要根ARP協(xié)議有關(guān)系,ARP會在本地緩存失效,TCP客戶端就無法想目的服務(wù)端發(fā)送數(shù)據(jù)包了。
- (192.168.1.100) 位于 08:00:27:1a:7a:0a [ether] 在 eth0
了解了上述情況,我們分析一下剛剛宕機(jī)的情況,此時(shí)客戶端是可以向服務(wù)端發(fā)送數(shù)據(jù)包的。但是由于服務(wù)器宕機(jī),因此不會給客戶端發(fā)送任何回復(fù)。
圖6 數(shù)據(jù)包截圖
由于客戶端并不知道服務(wù)端宕機(jī),因此會重復(fù)發(fā)送SYNC數(shù)據(jù)包,如圖6所示,可以看到客戶端每隔幾秒會向服務(wù)端發(fā)送一個(gè)SYNC數(shù)據(jù)包。這里面具體的時(shí)間是跟TCP協(xié)議相關(guān)的,具體時(shí)間不同的操作系統(tǒng)實(shí)現(xiàn)可能稍有不同。
3. 建立連接時(shí),服務(wù)器應(yīng)用被阻塞(或者僵死)
還有一種情況是在客戶端建立連接的過程中服務(wù)端應(yīng)用處于僵死狀態(tài),這種情況在實(shí)際中也會經(jīng)常出現(xiàn)(我們假設(shè)僅僅應(yīng)用程序僵死,而內(nèi)核沒有僵死)。此時(shí)會出現(xiàn)什么狀態(tài)?TCP的三次是否可以完成?客戶端是否可以收發(fā)數(shù)據(jù)?
在用戶層面我們知道,服務(wù)端通過accept接口返回一個(gè)新的套接字,這時(shí)就可以和客戶端進(jìn)行數(shù)據(jù)往來了。也就是在用戶層面來說,accept返回結(jié)果說明3次握手完成了,否則accept會被阻塞。在我們假設(shè)的情況下,其實(shí)就相當(dāng)于應(yīng)用程序無法進(jìn)行accept操作了。
如果想徹底理解上面我們假設(shè)的問題,需要理解兩點(diǎn),一點(diǎn)是accept函數(shù)具體做了什么,另外一點(diǎn)是TCP三次握手的本質(zhì)。
我們先試著理解***點(diǎn),accept會通過軟中斷陷入內(nèi)核中,最終會調(diào)用tcp協(xié)議的inet_csk_accept函數(shù),該函數(shù)會從隊(duì)列中查找是否有處于ESTABLISHED狀態(tài)的套接字。如果有則返回該套接字,否則阻塞當(dāng)前進(jìn)程。也就是說這里只是一個(gè)查詢的過程,并不參與三次握手的任何邏輯。
三次握手的本質(zhì)是什么呢?實(shí)際上就是客戶端與服務(wù)端一個(gè)不斷交流的過程,而這個(gè)交流過程就是通過3個(gè)數(shù)據(jù)包完成的。而這個(gè)數(shù)據(jù)包的發(fā)送和處理實(shí)際上都是在內(nèi)核中完成的。對于TCP的服務(wù)端來說,當(dāng)它收到SYNC數(shù)據(jù)包時(shí),就會創(chuàng)建一個(gè)套接字的數(shù)據(jù)結(jié)構(gòu)并給客戶端回復(fù)ACK,再次收到客戶端的ACK時(shí)會將套接字?jǐn)?shù)據(jù)結(jié)構(gòu)的狀態(tài)轉(zhuǎn)換為ESTABLISHED,并將其發(fā)送就緒隊(duì)列中。而這整個(gè)過程跟應(yīng)用程序沒有半毛錢的關(guān)系。
當(dāng)上面套接字加入就緒隊(duì)列時(shí),accept函數(shù)就被喚醒了,然后就可以獲得新的套接字并返回。但我們回過頭來看一下,在accept返回之前,其實(shí)三次握手已經(jīng)完成,也就是連接已經(jīng)建立了。
另外一個(gè)是如果accept沒有返回,客戶端是否可以發(fā)送數(shù)據(jù)?答案是可以的。因?yàn)閿?shù)據(jù)的發(fā)送和接受都是在內(nèi)核態(tài)進(jìn)行的??蛻舳税l(fā)送數(shù)據(jù)后,服務(wù)端的網(wǎng)卡會先接收,然后通過中斷通知IP層,再上傳到TCP層。TCP層根據(jù)目的端口和地址將數(shù)據(jù)存入關(guān)聯(lián)的緩沖區(qū)。如果此時(shí)應(yīng)用程序有讀操作(例如read或recv),那么數(shù)據(jù)會從內(nèi)核態(tài)的緩沖區(qū)拷貝到用戶態(tài)的緩存。否則,數(shù)據(jù)會一直在內(nèi)核態(tài)的緩沖區(qū)中??偟膩碚f,TCP的客戶端是否可以發(fā)送數(shù)據(jù)與服務(wù)端程序是否工作沒有任何關(guān)系。
當(dāng)然,如果是整個(gè)機(jī)器都卡死了,那就是另外一種情況了。這種情況就我們之前分析的第2種情況一直了。因?yàn)?,由于機(jī)器完全卡死,TCP服務(wù)端無法接受任何消息,自然也無法給客戶端發(fā)送任何應(yīng)答報(bào)文。
總結(jié)
今天我們主要介紹了連接建立過程中的各種異常情況,還有另外一種情況是在數(shù)據(jù)的傳輸過程中。比如傳輸過程中服務(wù)器突然掉電,或者程序crash等,后續(xù)我們將詳細(xì)這些異常情況下在協(xié)議層的表現(xiàn)。