ACK機(jī)制

1. ACK機(jī)制是發(fā)送方與接收方的一個(gè)相互確認(rèn)
2. 客戶(hù)端向服務(wù)端發(fā)送連接請(qǐng)求，此時(shí)服務(wù)端要回饋給客戶(hù)端ACK，以表示服務(wù)端接到了客戶(hù)端請(qǐng)求，這是第一和的第二次握手
3. 客戶(hù)端接收到服務(wù)端響應(yīng)后，同樣也要回饋服務(wù)端的響應(yīng)，告知服務(wù)端我收到了你的回饋，我們可以進(jìn)行傳輸數(shù)據(jù)了，此時(shí)客戶(hù)端就會(huì)帶著數(shù)據(jù)發(fā)送給服務(wù)端。、
4. 以上就是ACK機(jī)制，只有當(dāng)雙方都確認(rèn)了，才會(huì)進(jìn)行數(shù)據(jù)發(fā)送

流量控制

1. 流量控制是接收方發(fā)起的，即服務(wù)器端
2. 服務(wù)器端通過(guò)win來(lái)告知客戶(hù)端自己還剩多少流量來(lái)接受數(shù)據(jù)
3. 比如服務(wù)端告知客戶(hù)端我只有200個(gè)字段的流量了，則此時(shí)服務(wù)端會(huì)攜帶一個(gè)rwnd = 200的報(bào)文給客戶(hù)端，這是客戶(hù)端就知道了服務(wù)端能接收的流量，那么客戶(hù)端發(fā)送的數(shù)據(jù)包就不會(huì)超過(guò)200字節(jié)

擁塞控制

1. 擁塞控制是發(fā)送方發(fā)起的，即客戶(hù)端，是一種自適應(yīng)算法，利用多種機(jī)制，根據(jù)網(wǎng)絡(luò)狀況自動(dòng)調(diào)整發(fā)送頻率，以避免網(wǎng)絡(luò)擁堵
2. 慢啟動(dòng)：發(fā)送端會(huì)以一個(gè)較小的窗口值開(kāi)始發(fā)送，每收到一個(gè)ACK后，下一次窗口值就會(huì)翻倍增加，知道窗口值達(dá)到最大值位置。如果過(guò)程中沒(méi)有丟包，那就會(huì)加快發(fā)送的速度頻率，如果丟包，就會(huì)降低發(fā)送速度
3. 快速重傳：當(dāng)發(fā)送端發(fā)送的數(shù)據(jù)報(bào)文沒(méi)有在規(guī)定時(shí)間內(nèi)收到ACK回復(fù)，發(fā)送端會(huì)認(rèn)為該數(shù)據(jù)報(bào)文丟失了，那客戶(hù)端就會(huì)立刻重傳
4. 擁塞避免：當(dāng)收到3個(gè)重復(fù)ACK，注意，這里是收到。發(fā)送端會(huì)認(rèn)為網(wǎng)絡(luò)擁塞，他會(huì)減少發(fā)送速率。并降低發(fā)送端發(fā)送的數(shù)據(jù)量，從而減少網(wǎng)絡(luò)擁塞現(xiàn)象

重傳機(jī)制

1. 觸發(fā)重傳也有很多種方式
2. 超時(shí)重傳：超過(guò)等待時(shí)間依然沒(méi)有收到ACK響應(yīng)，則會(huì)重傳, 一般來(lái)說(shuō)超時(shí)時(shí)間(RTO) > 往返時(shí)間(RTT), 往返時(shí)間就是發(fā)送到服務(wù)端，再由服務(wù)端返回的兩段時(shí)間相加
3. 快速重傳(數(shù)據(jù)驅(qū)動(dòng)): TCP會(huì)給每個(gè)包編號(hào)seq， 第一個(gè)包編號(hào)就是隨機(jī)數(shù)，接收方收到多個(gè)包后，方便組裝還原，如果發(fā)生丟包，可以知道是哪一個(gè)包丟了。
4. 比如服務(wù)端收到6號(hào)包，但沒(méi)有收到14號(hào)包，ACK就會(huì)記錄，期待收到14號(hào)包。過(guò)了一段時(shí)間，14號(hào)包還是沒(méi)收到，但是收到了24號(hào)包，ACK里面編號(hào)不會(huì)變化，會(huì)一直期待收到14號(hào)包。所以就會(huì)不斷的重試。當(dāng)客戶(hù)端收到了3個(gè)連續(xù)的ACK回復(fù) 或 超時(shí)了還沒(méi)收到ACK，會(huì)認(rèn)為14號(hào)包丟失，會(huì)重新發(fā)14號(hào)包，因?yàn)?4號(hào)包已經(jīng)記錄在A(yíng)CK編號(hào)里面了，所以客戶(hù)端收到的ACK就會(huì)有期待14號(hào)包的信息，重傳成功后，雙方才會(huì)進(jìn)行正常通信。
5. 缺點(diǎn)：快速重傳解決了時(shí)間超時(shí)問(wèn)題，但存在重傳的時(shí)候，究竟是重傳丟失的那一個(gè)包，還是重傳丟失包之后的所有包。因?yàn)閬G失的包會(huì)導(dǎo)致后面的包不會(huì)記錄在A(yíng)CK中，所以此時(shí)客戶(hù)端時(shí)不知道后面的包是否已經(jīng)收到

TCP傳輸優(yōu)化-Nagle算法，即流量控制算法

1. TCP協(xié)議中，無(wú)論發(fā)送多少大小的數(shù)據(jù)，每次都會(huì)帶上協(xié)議頭
2. 如果數(shù)據(jù)量太小，甚至小于協(xié)議頭的數(shù)據(jù)量，并且請(qǐng)求頻率極高，那么就會(huì)浪費(fèi)資源，協(xié)議頭的內(nèi)容就會(huì)占很大資源，并且頻率高，數(shù)據(jù)小，也會(huì)造成擁塞，并占用資源
3. TCP默認(rèn)開(kāi)啟了Nagle算法
4. Nagle算法會(huì)將多個(gè)小包囤積 并 合并，然后一起發(fā)送，類(lèi)似于kafka的buffer機(jī)制。
5. Nagle算法只有當(dāng)收到服務(wù)器響應(yīng)的時(shí)候，才會(huì)發(fā)送第二個(gè)包，否則不會(huì)發(fā)送。當(dāng)然也不會(huì)一直等，當(dāng)長(zhǎng)時(shí)間沒(méi)收到服務(wù)器響應(yīng)，超過(guò)了超時(shí)時(shí)間，則會(huì)立即發(fā)送，即使每收到服務(wù)器響應(yīng)也會(huì)發(fā)送。或者數(shù)據(jù)長(zhǎng)度達(dá)到了MSS大小時(shí)，即使沒(méi)收到服務(wù)端響應(yīng)，也會(huì)立即發(fā)送第二個(gè)數(shù)據(jù)包
6. 缺點(diǎn)：實(shí)時(shí)性差，延遲很大，因?yàn)檎Ｇ闆r下只有收到服務(wù)器響應(yīng)，才會(huì)發(fā)送第二個(gè)數(shù)據(jù)包，所以當(dāng)實(shí)時(shí)性是強(qiáng)需求時(shí)，需要關(guān)閉Nagle算法

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-692097.html

到了這里，關(guān)于【HBZ分享】TCP可靠性傳輸如何保證的？的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！