tcp 連線

redrobot發表於2024-06-18

前言

看到這個標題你可能會說,TCP 連線的建立與斷開,這個我熟,不就是三次握手與四次揮手嘛。且慢,腦海中可以先嚐試回答這幾個問題:

  • 四次揮手是誰發起的?
  • 如果斷電/斷網了連線會斷開嗎?
  • 什麼情況下沒有四次揮手連線也會斷開?

這不是面試,而是遇到了實際問題,至於是什麼問題,容我先賣個關子,本文也不會解答,後面會有一篇專門的文章來說遇到的問題是啥,所以在講實際問題之前,先弄懂理論。

正常斷開

我們由淺入深,先了解正常情況下 TCP 連線是如何斷開的,下圖為 TCP 三次握手與四次揮手的經典圖(來自《TCP/IP詳解卷1》)

img1.png
img1.png

在我們的電腦上,可以使用 python 的 SimpleHTTPServer 來快速起一個 http 服務(http 也是基於 TCP 協議),比如這樣:

python -m SimpleHTTPServer 20880

再透過 nctelnet 這兩個命令來建立 TCP 連線,比如我測試使用 nc 來建立連線

nc -v ip port

Connection to ip port [tcp/*] succeeded! 表示連線成功

img2.png
img2.png

我們如何觀察這個連線呢?可以透過 netstatlsof 來檢視這條"連線",這裡我使用 lsof(mac 與 Linux 系統的 netstat 命令不太一樣,使用起來有點彆扭 )

lsof -i:20880

img3.png
img3.png

無論是客戶端還是服務端都會佔用一個埠,不過服務端埠是固定的,客戶端埠是隨機的。

如果我們想看 TCP 連線和斷開時握手揮手的 TCP 報文怎麼檢視呢?可以使用 tcpdump 命令

三次握手

tcpdump -A -vv -i any -S host 10.179.245.95

為了方便檢視,和上面的經典圖放在了一起

img4.png
img4.png

這裡的引數需要提一下的是 -S,如果不加 -S 引數看到的第三次握手的ack=1,與書上的理論不太一樣,其實這裡只是 tcpdump 簡化了展示,想看實際值需要加 -S

這裡的 Flags [S]/[S.]/[.]

  • S 代表 SYN
  • . 代表 ACK,S. 就是 SYN + ACK

四次揮手

命令與抓三次握手相同,我們抓到如下揮手資料

img5.png
img5.png
  • F 代表 FIN

這張圖有點奇怪,四次揮手居然變成了三次,這其實是 TCP 協議的實現問題,如果第二次與第三次揮手之間沒有資料傳送,那麼被動斷開連線的一方就可能會把第二次的 ACK 與 第三次的 FIN 合併為一次揮手。

當然我也抓到過正常的四次揮手,大概長這樣

img6.png
img6.png

異常斷開

上面鋪墊了這麼多,現在開始進入正題。

TCP 連線斷開是誰發起的

我們來思考一個問題:TCP 連線的斷開是誰發起的?程式本身還是作業系統?

我們來看一段非常簡單的 TCP 連線建立與斷開的程式碼

程式碼語言:txt
複製
tcpAddr, _ := net.ResolveTCPAddr("tcp", "127.0.0.1:20880")
conn, err := net.DialTCP("tcp", nil, tcpAddr)
if err != nil {
	fmt.Println("Client connect error ! " + err.Error())
	return
}

defer func() {
	err := conn.Close()
	fmt.Println("Client connect closed !")
	if err != nil {
		fmt.Println(err)
	}
}()

fmt.Println(conn.LocalAddr().String() + " : Client connected!")
time.Sleep(10 * time.Second)

執行後,效果如下,也符合我們預期:當程式列印 Client connected! 時,能看到連線,當列印 Client connect closed! 時,連線斷開

img7.png
img7.png

如果我們在連線斷開前使用 kill -9 強殺程序呢?(這裡我用了兩臺電腦來測試)

img8.png
img8.png

我們發現 conn.Close() 並沒有執行,但四次揮手還是發生了!

查閱資料發現如下結論:

a、b 兩個正常連線的對端程序。假如 b 程序沒有呼叫 close 就異常終止,那麼傳送 FIN 包是核心 OS 代勞

斷電/斷網時的連線是怎樣斷開的

我們透過上面的實驗發現就算程序異常終止,作業系統也會幫忙發起四次揮手

但如果是斷電或斷網的情況下,作業系統就無法代勞了,這時會怎樣呢?為了便於測試,這裡用兩臺電腦,client 連線 server,斷開 server 的網路來模擬斷網斷電情況。

可以肯定的是斷網,斷電後,連線不會立即斷開,那麼後續連線是否會斷開呢?我們分成下面幾種情況來看

斷網時有資料傳輸

斷網時如果有資料傳送,由於收不到 ACK,所以會重試,但並不會無限重試下去,達到一定的重發次數之後,如果仍然沒有任何確認應答返回,就會判斷為網路或者對端主機發生了異常,強制關閉連線。此時的關閉是直接關閉,而沒有揮手(資料都發不出去,還揮啥手),Linux 下的設定為

最小重傳時間是200ms

最大重傳時間是120s

重傳次數為15

斷網時沒有資料傳輸

斷網時如果沒有資料傳輸,還得看 TCP 連線的 KeepAlive 是否開啟,關於 TCP 的 KeepAlive 簡介如下:

  • TCP KeepAlive 是一種在不影響資料流內容的情況下探測對方的方式,採用 保活計時器實現,當計時器被觸發時,一端傳送保活報文,另一端接收到報文後傳送 ACK 響應
  • 它並不是 TCP 的規範,但大部分的實現都提供了這一機制
  • 該機制存在爭議,有的人保活機制應該在應用程式中實現
開啟KeepAlive

作業系統中有這麼幾個引數控制 KeepAlive 的配置:

  • Keepalive_time:空閒時間,即多長時間連線沒有傳送資料時開始 KeepAlive 檢測
  • Keepalive_intvl:傳送間隔時間,即上述程式碼的設定
  • Keepalive_probs:最多傳送多少個檢測資料包

在 Linux 上可以透過如下檔案檢視

程式碼語言:txt
複製
cat /proc/sys/net/ipv4/tcp_keepalive_time
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes
img9.png
img9.png

如果按照這個預設值來看,得2小時沒有資料傳輸,KeepAlive 才開始工作!

而在 Go 中只有兩個引數可以設定:

程式碼語言:txt
複製
conn.SetKeepAlive(true)
conn.SetKeepAlivePeriod(5 * time.Second)

其中第二個 SetKeepAlivePeriod 原始碼是這樣的:

程式碼語言:txt
複製
func setKeepAlivePeriod(fd *netFD, d time.Duration) error {
	// The kernel expects seconds so round to next highest second.
	secs := int(roundDurationUp(d, time.Second))
	if err := fd.pfd.SetsockoptInt(syscall.IPPROTO_TCP, sysTCP_KEEPINTVL, secs); err != nil {
		return wrapSyscallError("setsockopt", err)
	}
	err := fd.pfd.SetsockoptInt(syscall.IPPROTO_TCP, syscall.TCP_KEEPALIVE, secs)
	runtime.KeepAlive(fd)
	return wrapSyscallError("setsockopt", err)
}

SetKeepAlivePeriod 的引數同時設定了 tcp_keepalive_intvl 和 tcp_keepalive_time,tcp_keepalive_probes 沒法設定

做個簡單測試:client 開啟 KeepAlive 連線 server 後,什麼資料都不傳送,把server 的網斷掉,可以看到 KeepAlive 心跳包,一段時間後連線被置為 CLOSED 狀態

img10.png
img10.png
關閉KeepAlive

關閉 KeepAlive 後,如果沒有資料傳輸,連線永遠不會斷開

斷電/斷網後 server 重啟再恢復

再思考一個場景,如果 client 與 server 建立連線後,沒有資料傳輸,斷掉 server 端的網路,這時如果把 server 程式重啟一下,再恢復網路,那這條連線還能用嗎?

如果 server 重啟後,client 還是不發資料,那這條連線看起來還是可用的,因為他們根本不知道對方是個什麼情況,但如果此時 client 傳送一點資料給 server,你會發現 server 會傳送一個 RST 給client,然後 client 就斷開連線了

img11.png
img11.png

總結

總結

除了正常情況之外,本文從 TCP 連線斷開的角度結合實驗給出了一些結論:

  • TCP 連線斷開的揮手,在程序崩潰時,會由作業系統核心代勞
  • 當 TCP 連線建立後,如果某一方斷電或斷網,如果此時剛好正在傳送資料,TCP 資料包傳送失敗後會重試,重試達到上限時也會斷開連線
  • 當 TCP 連線建立後,如果某一方斷電或斷網,且這條連線沒有資料傳輸時
    • 如果開啟了 KeepAlive 則會在一定心跳檢測後斷開連線,這個預設檢測時間大概2個多小時,比較久
    • 如果未開啟 KeepAlive 則連線永遠存在
  • 如果一方傳送 RST 包給另一方,也是會強制對方斷開連線的

參考:

https://cloud.tencent.com/developer/article/1893375

相關文章