計(jì)算機(jī)網(wǎng)絡(luò)-tcp連接常見異常

目標(biāo)端口未在監(jiān)聽：(操作系統(tǒng)參與）
解決：TCP的服務(wù)端實(shí)際上就是從網(wǎng)卡的寄存器中讀取數(shù)據(jù)，然后進(jìn)行解析。對于TCP自然會解析出目的端口這個關(guān)鍵信息，然后根據(jù)這個信息查看有沒有這樣的套接字。這個套接字是什么呢？在用戶層面是一個文件句柄，但在內(nèi)核中實(shí)際是一個數(shù)據(jù)結(jié)構(gòu)，里面記錄了很多信息。這個數(shù)據(jù)結(jié)構(gòu)存儲在一個哈希表中，通過函數(shù)__inet_lookup_skb（net/inet_hashtables.h）可以實(shí)現(xiàn)對該數(shù)據(jù)結(jié)構(gòu)的查找。對于上述情況，自然無法找到該套接字，因此TCP服務(wù)端會進(jìn)行錯誤處理，處理的方式就是給客戶端發(fā)送一個RST（通過函數(shù)tcp_v4_send_reset進(jìn)行發(fā)送），告訴客戶端發(fā)生錯誤。可以通過抓包來分析理解。
常見返回：[Errno 111] Connection refused（連接拒絕）

目標(biāo)主機(jī)不存在：(自己的超時計(jì)時器）
這也是一種比較常見的情況，當(dāng)某臺服務(wù)器主機(jī)宕機(jī)了，而客戶端并不知道，仍然嘗試去與其建立連接。這個時候由于宕機(jī)，操作系統(tǒng)幫不上忙，服務(wù)器處于一種完全沒有響應(yīng)的狀態(tài)。那么此時客戶端的TCP會怎么辦呢？最多重傳默認(rèn)為6次，每一次時間間隔都不一樣，而后仍未收到響應(yīng)就會返回ETIMEDOUT錯誤。這是TCP建立連接自己的一個保護(hù)機(jī)制，但是我們要等待75s才能知道這個連接無法建立，對于我們所有服務(wù)來說都太長了。更好的做法是在代碼中給connect設(shè)置一個超時時間。

Server進(jìn)程被阻塞：
由于某些情況，服務(wù)器端進(jìn)程無法響應(yīng)任何請求，比如所在主機(jī)的硬盤滿了，導(dǎo)致進(jìn)程處于完全阻塞，通常我們測試時會用gdb模擬這種情況。上面提到過，建立連接的過程對應(yīng)用程序是不可見的，那么，這時連接可以正常建立。當(dāng)然，客戶端進(jìn)程也可以通過這個連接給服務(wù)器端發(fā)送請求，服務(wù)器端TCP會應(yīng)答ACK表示已經(jīng)收到這個分節(jié)（這里的收到指的是數(shù)據(jù)已經(jīng)在內(nèi)核的緩沖區(qū)里準(zhǔn)備好，由于進(jìn)程被阻塞，無法將數(shù)據(jù)從內(nèi)核的緩沖區(qū)復(fù)制到應(yīng)用程序的緩沖區(qū)），但永遠(yuǎn)不會返回結(jié)果。

Server進(jìn)程暫時關(guān)閉：
這是線上最常見的操作，當(dāng)一個模塊上線時，OP同學(xué)總是會先把舊的進(jìn)程殺死，然后再啟動新的進(jìn)程。那么在這個過程中TCP連接發(fā)生了什么呢。在進(jìn)程正常退出時會自動調(diào)用close函數(shù)來關(guān)閉它所打開的文件描述符，這相當(dāng)于服務(wù)器端來主動關(guān)閉連接——會發(fā)送一個FIN分節(jié)給客戶端TCP；客戶端要做的就是配合對端關(guān)閉連接，TCP會自動響應(yīng)一個ACK，然后再由客戶端應(yīng)用程序調(diào)用close函數(shù)，也就是我們上面所描述的關(guān)閉連接的4次揮手過程。接下來，客戶端還需要定時去重連，以便當(dāng)服務(wù)器端進(jìn)程重新啟動好時客戶端能夠繼續(xù)與之通信。

通信的過程中服務(wù)器端宕機(jī)：
客戶端向服務(wù)器端發(fā)送分節(jié)，由于服務(wù)器端宕機(jī)，不會有任何響應(yīng)，客戶端持續(xù)重傳，然而服務(wù)器始終不能應(yīng)答，重傳數(shù)次之后，大約4~10分鐘才停止，之后返回一個ETIMEDOUT錯誤。

總結(jié)

以上是生活随笔為你收集整理的计算机网络-tcp连接常见异常的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。