前言
看到這個標題你可能會說，TCP 連接的建立與斷開，這個我熟，不就是三次握手與四次揮手嘛。且慢，腦海中可以先嘗試回答這幾個問題：
- 四次揮手是誰發起的？
- 如果斷電/斷網了連接會斷開嗎？
- 什么情況下沒有四次揮手連接也會斷開？
這不是面試，而是遇到了實際問題，至於是什么問題，容我先賣個關子，本文也不會解答，后面會有一篇專門的文章來說遇到的問題是啥，所以在講實際問題之前，先弄懂理論。
正常斷開
我們由淺入深，先了解正常情況下 TCP 連接是如何斷開的，下圖為 TCP 三次握手與四次揮手的經典圖（來自《TCP/IP詳解卷1》）
在我們的電腦上，可以使用 **python 的 SimpleHTTPServer ** 來快速起一個 http 服務（http 也是基於 TCP 協議），比如這樣：
python -m SimpleHTTPServer 20880
再通過 nc 或 telnet 這兩個命令來創建 TCP 連接，比如我測試使用 nc 來創建連接
nc -v ip port
Connection to ip port [tcp/*] succeeded! 表示連接成功
我們如何觀察這個連接呢？可以通過 netstat 或 lsof 來查看這條"連接"，這里我使用 lsof（mac 與 Linux 系統的 netstat 命令不太一樣，使用起來有點別扭 ）
lsof -i:20880
無論是客戶端還是服務端都會占用一個端口，不過服務端端口是固定的，客戶端端口是隨機的。
如果我們想看 TCP 連接和斷開時握手與揮手的 TCP 報文怎么查看呢？可以使用 tcpdump 命令
三次握手
tcpdump -A -vv -i any -S host 10.179.245.95
為了方便查看，和上面的經典圖放在了一起
這里的參數需要提一下的是 -S，如果不加 -S 參數看到的第三次握手的ack=1，與書上的理論不太一樣，其實這里只是 tcpdump 簡化了展示，想看實際值需要加 -S
這里的 Flags [S]/[S.]/[.]
- [S] 代表 SYN
- [.] 代表 ACK，[S.] 就是 SYN + ACK
四次揮手
命令與抓三次握手相同，我們抓到如下揮手數據
- [F] 代表 FIN
這張圖有點奇怪，四次揮手居然變成了三次，這其實是 TCP 協議的實現問題，如果第二次與第三次揮手之間沒有數據發送，那么被動斷開連接的一方就可能會把第二次的 ACK 與 第三次的 FIN 合並為一次揮手。
當然我也抓到過正常的四次揮手，大概長這樣
異常斷開
上面鋪墊了這么多，現在開始進入正題。
TCP 連接斷開是誰發起的
我們來思考一個問題：TCP 連接的斷開是誰發起的？程序本身還是操作系統？
我們來看一段非常簡單的 TCP 連接創建與斷開的代碼
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! 時，連接斷開
如果我們在連接斷開前使用 kill -9 強殺進程呢？（這里我用了兩台電腦來測試）
我們發現 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 上可以通過如下文件查看
cat /proc/sys/net/ipv4/tcp_keepalive_time
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes
如果按照這個默認值來看，得2小時沒有數據傳輸，KeepAlive 才開始工作！
而在 Go 中只有兩個參數可以設置：
conn.SetKeepAlive(true)
conn.SetKeepAlivePeriod(5 * time.Second)
其中第二個 SetKeepAlivePeriod 源碼是這樣的：
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 狀態
關閉KeepAlive
關閉 KeepAlive 后，如果沒有數據傳輸，連接永遠不會斷開
斷電/斷網后 server 重啟再恢復
再思考一個場景，如果 client 與 server 建立連接后，沒有數據傳輸，斷掉 server 端的網絡，這時如果把 server 程序重啟一下，再恢復網絡，那這條連接還能用嗎？
如果 server 重啟后，client 還是不發數據，那這條連接看起來還是可用的，因為他們根本不知道對方是個什么情況，但如果此時 client 發送一點數據給 server，你會發現 server 會發送一個 RST 給client，然后 client 就斷開連接了
總結
除了正常情況之外，本文從 TCP 連接斷開的角度結合實驗給出了一些結論：
- TCP 連接斷開的
揮手，在進程崩潰時，會由操作系統內核代勞 - 當 TCP 連接建立后，如果某一方斷電或斷網，如果此時剛好正在發送數據，TCP 數據包發送失敗后會重試，重試達到上限時也會斷開連接
- 當 TCP 連接建立后，如果某一方斷電或斷網，且這條連接沒有數據傳輸時
- 如果開啟了 KeepAlive 則會在一定心跳檢測后斷開連接，這個默認檢測時間大概2個多小時，比較久
- 如果未開啟 KeepAlive 則連接永遠存在
- 如果一方發送 RST 包給另一方，也是會強制對方斷開連接的
搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、源碼閱讀、問題排查、踩坑實踐。
