TCP

1.確認應(yīng)答ACK機制(可靠核心機制)

需要具體知道序號和確認序號的含義, 每個字節(jié)的內(nèi)容都有序號, 比如發(fā)送方發(fā)送了1~1000, 1001~2000, 的兩段數(shù)據(jù), 但是1001開始的數(shù)據(jù)丟了, 那么接收方就會發(fā)送一個ACK確認報文, 其中的確認序號就1001, 代表我前面的1到1000的數(shù)據(jù)收到了, 下次需要你從1001開始發(fā)送, 這樣發(fā)送方就知道了, 1001~2000丟了, 需要重傳

2. 超時重傳機制(可靠核心機制)

超時時間的重傳, 當我們重傳之后數(shù)據(jù)報可能會被接收方收到多次, 那么如何將其去重呢,就要用到上面的序號了, 序號相同的我只保留一份即可**(因為發(fā)送方是無法區(qū)分是數(shù)據(jù)報丟了, 還是確認的ACK丟了)**

3. 連接管理(面試必考)

• 建立連接 三次握手的過程
• 斷開連接 四次揮手的過程

三次握手來確認通信雙方的發(fā)送和接收能力是否正常

a) 第一次,a給b發(fā)送了一句喂喂喂你能聽見嗎? b如果接收到了這句話, 就證明b現(xiàn)在已經(jīng)知道了a的發(fā)送能力和b的接收能力是正常的, 現(xiàn)在需要驗證自己的發(fā)送能力和a的接收能力, 并將自己知道的也發(fā)送給對方

b)第二次, b就給a 發(fā)送了一個我能聽見, 你可以聽見我嗎? 這樣的話 如果a接收到了b 的這條信息, 那么就證明a剛剛驗證自己的發(fā)送和b的接收是正常的, 同時a自己知道了b的發(fā)送能力 和 a自己的接收能力是好的, 此時a就是知道了雙方的發(fā)送和接收是正常的,但是此時b是正在驗證自己的發(fā)送能力和a 的接收能力是不是好的, 所以我們還需要a再次發(fā)送給b一條消息來告知是好的

c)第三次, a給b說一句我能聽到, 此時b收到了消息, 那么就證明b上面驗證自己的發(fā)送能力和a的接收能力是好的, 此時通信雙方就都知道了雙方的發(fā)送和接收能力是好的, 就可以發(fā)送正文了

四次揮手來斷開雙方連接

a) 首先是數(shù)據(jù)傳輸階段, 通信雙方正常傳輸數(shù)據(jù)

b) 當客戶端數(shù)據(jù)發(fā)送完畢時, 應(yīng)用層調(diào)用close()方法,客戶端會發(fā)送一個FIN = 1其序列號為seq=m（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1）的數(shù)據(jù)報, 此時客戶端進入FIN_WAIT_1階段

c) 當服務(wù)端,一收到了客戶端傳來的FIN報文段,操作系統(tǒng)內(nèi)核就立馬會發(fā)送一個ACK確認報文, 此時服務(wù)端進入CLOSE_WAIT狀態(tài), 半關(guān)閉狀態(tài)此時客戶端就沒有數(shù)據(jù)要發(fā)送了, 但是客戶端還會接收服務(wù)端傳輸過來的數(shù)據(jù), 服務(wù)端之前還有客戶端發(fā)送來的數(shù)據(jù)存在緩沖區(qū)需要處理,所以需要等待處理完之后才會調(diào)用close()方法來發(fā)送一個FIN報文, 服務(wù)端發(fā)送完FIN之后就會立馬進入LAST_ACK狀態(tài)

d) 一當上面的客戶端收到了來自服務(wù)端的ACK報文就會立馬進入FIN_WAIT_2階段, 在這階段一直等待服務(wù)端的FIN報文, 當客戶端收到了FIN報文段就會進入TIME_WAIT狀態(tài), 并發(fā)送ACK確認報文段給服務(wù)端

e) 當服務(wù)端在最后收到了來自客戶端的ACK報文, 那么就會立馬進入CLOSED狀態(tài)斷開連接了

f) 但此時客戶端還不會立馬進入CLOSED狀態(tài), 因為最后的ACK報文段可能丟失, 所以需要等待2*MSL時間來, 確保數(shù)據(jù)丟失的情況下來超時重傳

g) 為什么這個時間是 2*MSL呢?

? 我們假設(shè)FIN/ ACK 報文在網(wǎng)絡(luò)上由客戶端傳輸?shù)椒?wù)端需要花費的最大時間為MSL(就是取個名字), 舉個例子 比如 : 我客戶端發(fā)送了ACK確認報文, 但他在中途丟了, 那么是不是服務(wù)端就一直沒有收到ACK確認報文, 那么他就會重傳 FIN結(jié)束報文, 但此時要是我客戶端直接發(fā)送完ACK后直接關(guān)閉了, 那么就無法響應(yīng)服務(wù)器的二次請求，這樣服務(wù)器會繼續(xù)發(fā)出FIN報文，從而變成了死循環(huán)。所以我們要設(shè)置一個時間段 : 如果在這個時間段內(nèi)接收到了服務(wù)器端的再次請求，則代表客戶端發(fā)出的ACK報文沒有接收成功。反之，則代表服務(wù)器端成功接收響應(yīng)報文，客戶端進入CLOSED狀態(tài)，此次連接成功關(guān)閉。而這個時間，就規(guī)定為了2MSL，即客戶端發(fā)出ACK報文到服務(wù)器端的最大時間 + 服務(wù)器沒有接收到ACK報文再次發(fā)出FIN的最大時間 = 2MSL

4.滑動窗口(結(jié)合確認序號來理解)

是一種用來提高傳輸效率的機制, 批量的發(fā)送數(shù)據(jù), 批量的等待ACK

不等待ACK所發(fā)送的最大數(shù)據(jù)量, 就稱為滑動窗口

每收到一個ACK, 就對應(yīng)的發(fā)后面的數(shù)據(jù), 等待窗口的范圍一直在往后移

5.流量控制

在滑動窗口的機制上, 限制傳輸?shù)男?就是限制窗口的大小)

接收方的接收緩沖區(qū)的空余大小,反向反饋發(fā)送者的滑動窗口大小

ACK報文的報頭中, 有一個"窗口大小"字段, 這個字段就是接收方的接收緩沖區(qū)的空余空間大小

發(fā)送者也會定時的發(fā)送探測報文, 試探接收方的緩沖區(qū)的空余空間

6.擁塞控制

也是限制傳輸效率, 根據(jù)網(wǎng)絡(luò)當前的擁堵情況, 動態(tài)決定實際傳輸?shù)拇翱诖笮?/p>

實際發(fā)送方的窗口大小 = min(擁塞窗口大小, 流量控制窗口大小)

7.延遲應(yīng)答

目的是為了提高效率, 在流量控制的基礎(chǔ)上, 盡量返回一個合理的但是又比較大的窗口

其實就是讓ACK的發(fā)送時間晚一點(在不影響可靠性的前提下)

延遲的時間中就會給應(yīng)用程序提供更多的消費數(shù)據(jù)的機會 ~~ 此時時間到了, 我再發(fā)送ACK, 得到的緩沖區(qū)大小就會比剛剛大一些

不是所有的包都可以延遲應(yīng)答, 有數(shù)量限制和時間限制

8. 捎帶應(yīng)答

在延遲應(yīng)答的基礎(chǔ)上, 為了進一步提高程序運行效率而引進的機制

本質(zhì)上就是把兩個包,合并成為一個就是捎帶, 節(jié)省帶寬

9. 心跳機制

心跳包 就是在客戶端和服務(wù)器間定時通知對方自己狀態(tài)的一個自己定義的命令字，按照一定的時間間隔發(fā)送，類似于心跳，所以叫做心跳包。 用來判斷對方（設(shè)備，進程或其它網(wǎng)元）是否正常運行，采用定時發(fā)送簡單的通訊包，如果在指定時間段內(nèi)未收到對方響應(yīng)，則判斷對方已經(jīng)離線。 用于檢測TCP的異常斷開。

總結(jié)

以上是生活随笔為你收集整理的简谈TCP的八个特性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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