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