當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

【学习笔记】传输层：TCP协议（报文段、连接管理{握手}、可靠传输、流量控制、拥塞控制）

發(fā)布時(shí)間：2024/7/23 编程问答 46 豆豆

生活随笔收集整理的這篇文章主要介紹了【学习笔记】传输层：TCP协议（报文段、连接管理{握手}、可靠传输、流量控制、拥塞控制）小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

序號：比如上圖的123傳遞成功后，發(fā)送方要傳送456字節(jié)，那么組成報(bào)文段中的序號就是4。
確認(rèn)號：用序號的例子，123傳遞成功后，接收方發(fā)送的報(bào)文段的確認(rèn)號就是4
（表示123已經(jīng)收到，期待接收到4）
填充：TCP首部大小需要滿足是4B的倍數(shù)，因此需要填充0來結(jié)合選項(xiàng)大小滿足4B
數(shù)據(jù)偏移：由“填充”可知，TCP首部大小不一定是20B，因此需要用“數(shù)據(jù)偏移"部分來記錄TCP首部的實(shí)際大小。
URG = 1：可以直接插隊(duì)到最前面
控制位、窗口可以結(jié)合后面的例子理解，這里可以先看定義。
對于檢驗(yàn)和，UDP的第四個(gè)字段是17，和TCP的6不同。

先看下圖男女對話，TCP的連接釋放過程就類似下圖
半關(guān)閉狀態(tài)：只是單向的連接釋放，而非互相的連接釋放。
ROUND 2(ack=u+1)時(shí)客戶端不用回復(fù)確認(rèn)報(bào)文段，因?yàn)橐呀?jīng)進(jìn)入半關(guān)閉狀態(tài)。
ROUND 3的ack=u+1，因?yàn)镽OUND 2時(shí)客戶端并沒有回送報(bào)文段。
ROUND 3的seq = w，不一定有 w = v + 1，因?yàn)镽OUND 2 - 3之間服務(wù)端可能還在發(fā)信息
ROUND 4等待原理：
1）如果確認(rèn)報(bào)文段丟失了，A會在2MSL內(nèi)收到B重發(fā)的ROUND 3數(shù)據(jù)報(bào)，并重新開始計(jì)算2MSL：如果之后報(bào)文段繼續(xù)丟失，則重來一次這個(gè)操作；如果收到了，就圓滿結(jié)束。
2） 如果不設(shè)置這個(gè)操作，可能會出現(xiàn)因?yàn)閳?bào)文段丟失，導(dǎo)致B一直處于等待報(bào)文段狀態(tài)，無法正常結(jié)束。
3）為什么是2MSL：ROUND 4丟失的情況下，在1MSL的時(shí)候服務(wù)器會重傳ROUND 3，然后再經(jīng)歷一個(gè)1MSL抵達(dá)客戶端，

網(wǎng)絡(luò)層不可靠，靠傳輸層用TCP實(shí)現(xiàn)可靠。
如果是UDP，則在應(yīng)用層實(shí)現(xiàn)可靠。
機(jī)制：校驗(yàn)、序號、確認(rèn)、重傳

發(fā)送123后（發(fā)123時(shí)序號字段為1）
可見此時(shí)兩方緩存都有123，發(fā)送方要等收到確認(rèn)收到123的信息后才能把123從緩存中去掉。（便于在丟失時(shí)可以重傳）
此時(shí)發(fā)送了456、78，但是只有78傳到了。
則接收方回送報(bào)文段時(shí)，報(bào)文段首部確認(rèn)號仍為4
之后補(bǔ)上456后，因?yàn)榻邮辗骄彺嬷幸呀?jīng)有78了，因此回送的報(bào)文段首部確認(rèn)號會是9（累計(jì)確認(rèn)）

RTTs：發(fā)送第一個(gè)時(shí)，RTTs = RTT $_1$ 。
發(fā)送第二個(gè)后，RTTs由RTT $_1$ 和RTT $_2$ 來決定（并非平均），以此類推。

接收方可能會讓發(fā)送方發(fā)送窗口為0，此時(shí)不能再發(fā)送。
此時(shí)接收方把緩存數(shù)據(jù)上傳，傳完后再讓接收方繼續(xù)發(fā)。
在上例結(jié)束后，可能B會讓A繼續(xù)傳輸，但是發(fā)送報(bào)文段丟失。那么可能雙方會一直僵持。解決方法見下圖。

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