正文

TCP有限狀態(tài)機(jī)（tcp有限狀態(tài)機(jī)解讀）

發(fā)布時間：2023-03-19 04:56:04 稿源：創(chuàng)意嶺閱讀： 78 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于TCP有限狀態(tài)機(jī)的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、tcp擁塞控制常用算法
2、理解tcp鏈接
3、【tcp】心跳檢測，保活機(jī)制
4、在應(yīng)用層可以檢測到tcp狀態(tài)機(jī)的狀態(tài)嗎

TCP有限狀態(tài)機(jī)（tcp有限狀態(tài)機(jī)解讀）

一、tcp擁塞控制常用算法

tcp擁塞控制常用算法方法如下

TCP協(xié)議有兩個比較重要的控制算法，一個是流量控制，另一個就是阻塞控制。TCP協(xié)議通過滑動窗口來進(jìn)行流量控制，它是控制發(fā)送方的發(fā)送速度從而使接受者來得及接收并處理。而擁塞控制是作用于網(wǎng)絡(luò)，它是防止過多的包被發(fā)送到網(wǎng)絡(luò)中，避免出現(xiàn)網(wǎng)絡(luò)負(fù)載過大，網(wǎng)絡(luò)擁塞的情況。擁塞算法需要掌握其狀態(tài)機(jī)和四種算法。擁塞控制狀態(tài)機(jī)的狀態(tài)有五種，分別是Open，Disorder，CWR，Recovery和Loss狀態(tài)。四個算法為慢啟動，擁塞避免，擁塞發(fā)生時算法和快速恢復(fù)。和TCP一樣，擁塞控制算法也有其狀態(tài)機(jī)。當(dāng)發(fā)送方收到一個Ack時，LinuxTCP通過狀態(tài)機(jī)(state)來決定其接下來的行為，是應(yīng)該降低擁塞窗口cwnd大小，或者保持cwnd不變，還是繼續(xù)增加cwnd。

二、理解tcp鏈接

一般都說TCP 是長連接，但這個連接是真實(shí)存在的嗎。不是的。

這個連接只是操作系統(tǒng)維護(hù)的一個狀態(tài)機(jī)。通過兩臺計算機(jī)直接通過報文交互來改變這個狀態(tài)值。并不是正真的有真實(shí)的鏈路存在。

每次兩臺機(jī)器直接的通信中間通過的節(jié)點(diǎn)可能都是不一樣的，是動態(tài)選擇的。

所以，

服務(wù)器端 TCP 連接的數(shù)量受到內(nèi)存大小的影響，每建立一個連接都要分配一塊內(nèi)存區(qū)域來維護(hù)這個‘連接’。

三、【tcp】心跳檢測，?；顧C(jī)制

為什么要心跳檢查?

因為目前討論的數(shù)據(jù)連接場景，都是無源連接，排除NAT的情況，連接就是存在于src和dest兩端OS中的狀態(tài)機(jī)，為什么會要用無源連接呢，有源是連接建立帶寬就分配好了，不傳有效數(shù)據(jù)這個帶寬也被占用著，這不就浪費(fèi)了，虛擬信號時代的電話就是有源的。

心跳檢查是兩端都要做的，不做的那一端一樣存在狀態(tài)不對而不自知的情況。

狀態(tài)機(jī)在兩端是有可能不一致的，比如一端認(rèn)為這條連接已經(jīng)銷毀，另外一端可能認(rèn)為仍有效。心跳機(jī)制的作用之一就是解決這種不一致的情況，類似“校對”的作用。

在瀏覽器上請求一個需要長時間才得到結(jié)果的請求，最后返回超時錯誤。

你說的情況我們經(jīng)常遇到，我估計你說的就是客戶端自己的超時設(shè)置，也就是如果http響應(yīng)無法在限定時間內(nèi)完成（比如1秒內(nèi)），那么客戶端應(yīng)用程序自己會報timeout錯誤。

這應(yīng)該不是中間設(shè)備做了reset，因為如果是那樣，這個中間設(shè)備應(yīng)該會給客戶端和服務(wù)端都發(fā)TCP RST，然后客戶端報錯會變成ECONNRESET這種（ECONNRESET是linux的網(wǎng)絡(luò)協(xié)議棧報給用戶空間程序的報錯）。

心跳消息顯示push ack是為何呢？

按照TCP協(xié)議（參考RFC793）規(guī)定，操作系統(tǒng)收到有PSH標(biāo)志位的報文后，這些報文不會被駐留在接收緩沖區(qū)，而是要立即通知用戶空間程序來接收。這樣對于用戶空間程序及時收發(fā)處理心跳報文是有利的。

AWS的nlb keep-alive最大是350s，我們的服務(wù)端keep-alive是默認(rèn)配置，客戶端使用了連接池，也進(jìn)行了探測，但是有個騷操作是隨機(jī)選取池子里面的一個鏈接進(jìn)行探測，然后那些超過350s還沒探測的鏈接，再次使用就出問題了。

你說的“隨機(jī)選取池子里面的一個鏈接進(jìn)行探測”，我判斷是健康檢查，就是業(yè)務(wù)健康性（類似k8s的readiness probe），而不是keepalive。

如果是這樣的話，這個健康檢查確實(shí)不是為保活而生的，也很難達(dá)到保活的目的。建議這樣做設(shè)置：client idle timeout < LB idle timeout < server idle timeout，這樣可以盡可能的保證不出現(xiàn)連接失效的情況。

這里說的“?；顣r間”，不是心跳包的間隔，而是空閑?；顣r間，idle timeout。

?；顧C(jī)制：心跳包異常導(dǎo)致應(yīng)用重啟？

https://time.geekbang.org/column/article/482610

如何解決 Keep-Alive 導(dǎo)致 ECONNRESET 的問題

https://zhuanlan.zhihu.com/p/86953757

解決使用 KeepAlive Agent 遇到的 ECONNRESET

https://zhuanlan.zhihu.com/p/34147188