為什么TCP協(xié)議是可靠的？TCP協(xié)議是怎么保證數(shù)據(jù)的可靠的？
答：能夠保證TCP協(xié)議可靠的算法有檢驗(yàn)和，連接管理機(jī)制，ACK應(yīng)答機(jī)制，快速重傳和超時(shí)重傳機(jī)制，滑動(dòng)窗口機(jī)制，擁塞控制機(jī)制，這些機(jī)制共同保證TCP協(xié)議的可靠性。

檢驗(yàn)和：TCP檢驗(yàn)和的計(jì)算與UDP一樣，在計(jì)算時(shí)要加上12byte的偽首部，檢驗(yàn)范圍包括TCP首部及數(shù)據(jù)部分，但是UDP的檢驗(yàn)和字段為可選的，而TCP中是必須有的。計(jì)算方法為：在發(fā)送方將整個(gè)報(bào)文段分為多個(gè)16位的段，然后將所有段進(jìn)行反碼相加，將結(jié)果存放在檢驗(yàn)和字段中，接收方用相同的方法進(jìn)行計(jì)算，如最終結(jié)果為檢驗(yàn)字段所有位是全1則正確（UDP中為0是正確），否則存在錯(cuò)誤?？梢员ＷC接收方能判斷當(dāng)前報(bào)文是否屬于自己要接受的報(bào)文，如果為0，那就是，不為0，則不是，丟棄此報(bào)文。抽象些來(lái)說(shuō)就像是取快遞，你的電話姓名和快遞上的信息一致，你才能確定這是你的快遞，才會(huì)去取，不會(huì)錯(cuò)拿別人的快遞。

序列號(hào)：TCP 對(duì)每個(gè)報(bào)文進(jìn)行編號(hào)，這些編號(hào)就是序列號(hào)。而序列號(hào)有多種作用
a：保證可靠性，當(dāng)接收到的數(shù)據(jù)失序時(shí)，就能立馬知道
b：去除重復(fù)的報(bào)文，數(shù)據(jù)傳輸過(guò)程中的確認(rèn)應(yīng)答，重發(fā)控制，重復(fù)控制等功能都要依靠序列號(hào)來(lái)實(shí)先。
c：提高效率，可以實(shí)現(xiàn)多次發(fā)送，一次確認(rèn)。

ACK應(yīng)答機(jī)制：發(fā)送的每一條消息，都需要對(duì)方發(fā)送一條消息來(lái)回復(fù)消息是否被收到。

主要實(shí)現(xiàn)是TCP的首部來(lái)控制，當(dāng)ACK =1 時(shí)ack才有效，ack等于期望下一個(gè)傳輸過(guò)來(lái)的序號(hào)，也就是上一次接收消息的序號(hào)+1。這樣就可以保證消息能被確認(rèn)接收。（三次握手和四次揮手都在用這個(gè)機(jī)制）

連接管理機(jī)制：三次握手建立連接與四次揮手?jǐn)嚅_(kāi)連接，保證了TCP的全雙工工作。

快重傳和超時(shí)重傳：保證了數(shù)據(jù)能夠不丟失的傳輸數(shù)據(jù)。（注意：超時(shí)重傳機(jī)制和快重傳機(jī)制，同時(shí)存在。誰(shuí)先檢驗(yàn)到報(bào)文失序，誰(shuí)就生效。）

• 快重傳：發(fā)送方連續(xù)收到3個(gè)接收方發(fā)送的同一個(gè)ack時(shí)，此時(shí)快速重傳ack序號(hào)以及其之后的所有數(shù)據(jù)報(bào)。

  
  
  快重傳

• 超時(shí)重傳：當(dāng)發(fā)送方發(fā)送了數(shù)據(jù)給接收方，當(dāng)時(shí)超過(guò)了約定的時(shí)間（RTO）也沒(méi)有接收到確認(rèn)消息，此時(shí)重傳此報(bào)文。（Tips：RTO也就是重傳超時(shí)時(shí)間，這個(gè)時(shí)間由TCP的自適應(yīng)算法生成）

  
  
  超時(shí)重傳

滑動(dòng)窗口：滑動(dòng)窗口既提高了報(bào)文傳輸?shù)男剩脖苊饬税l(fā)送方發(fā)送過(guò)多的數(shù)據(jù)而導(dǎo)致接收方無(wú)法正常處理的異常。數(shù)據(jù)的發(fā)送方和接收方都有滑動(dòng)窗口，對(duì)于發(fā)送方來(lái)說(shuō)，窗口內(nèi)就是可以發(fā)送的報(bào)文，當(dāng)窗口的前沿緊挨的報(bào)文發(fā)送并且確認(rèn)時(shí)，窗口向后移動(dòng)。而窗口的后沿可以向前移動(dòng)，當(dāng)接收方處理不了那么多的報(bào)文時(shí)，就會(huì)發(fā)送消息告訴發(fā)送方，此時(shí)滑動(dòng)窗口就需要縮小，所以后沿前移。但是TCP非常不建議窗口后沿前移。

說(shuō)到滑動(dòng)窗口，就不得不梳理一下消息發(fā)送的過(guò)程中的緩存機(jī)制:

發(fā)送方和接收方的滑動(dòng)窗口工作流程：

發(fā)送方的滑動(dòng)窗口

接收方的滑動(dòng)窗口

內(nèi)部細(xì)節(jié)圖 A為發(fā)送方 B為接收方

伴隨著效率的提升，也會(huì)有問(wèn)題產(chǎn)生，如果消息沒(méi)被確認(rèn)怎么辦如圖所示，假如31，32，33，34，報(bào)文發(fā)送了，32，33，34都被確認(rèn)了，31沒(méi)被確認(rèn)怎么辦呢？這時(shí)就重新發(fā)送31，并且31之后的數(shù)據(jù)報(bào)全部重新發(fā)送。

在圖中我們還會(huì)發(fā)現(xiàn)窗口的前沿和后沿會(huì)移動(dòng)，窗口前沿和后沿都向后移動(dòng)，意味著前沿緊挨的報(bào)文發(fā)送并被確認(rèn)，而后沿的前移意味著，接收端處理那么多消息，請(qǐng)縮小窗口的大小。
所以解決了發(fā)送的數(shù)據(jù)過(guò)多，導(dǎo)致接收端無(wú)法正常接收的異常。

擁塞控制：擁塞控制使得宏觀網(wǎng)絡(luò)中的資源能夠合理的應(yīng)用。實(shí)現(xiàn)的算法有四個(gè)，慢開(kāi)始，擁塞避免，快速回復(fù)，和快速重傳.

1.慢開(kāi)始指一開(kāi)始發(fā)送報(bào)文時(shí)，不清楚網(wǎng)絡(luò)中的情況，試探性的發(fā)送1cwnd(擁塞窗口)的數(shù)據(jù)量。

2.如果沒(méi)有到ssthresh(慢開(kāi)始門(mén)限值)，則以指數(shù)形式增長(zhǎng)，一直到門(mén)限值；

3.當(dāng)?shù)竭_(dá)門(mén)限值時(shí)，此時(shí)采用擁塞避免算法讓擁塞窗口緩慢增長(zhǎng)，即每經(jīng)過(guò)一個(gè)RTT（往返時(shí)間）就把發(fā)送方的擁塞窗口+1，不能是指數(shù)性增長(zhǎng)了，一直到發(fā)生網(wǎng)絡(luò)擁塞為止。

4.當(dāng)發(fā)生網(wǎng)絡(luò)擁塞時(shí)，把ssthresh的值設(shè)置為出現(xiàn)擁塞時(shí)發(fā)送窗口大小的一半，然后把擁塞窗口設(shè)置為1，再次執(zhí)行慢開(kāi)始算法。

5.在發(fā)送方知道只是丟失了個(gè)別的報(bào)文段時(shí)，采用快恢復(fù)算法，將門(mén)限值設(shè)置成擁塞窗口大小的一半，并將擁塞窗口設(shè)置為當(dāng)前門(mén)限值，并執(zhí)行擁塞避免算法。

6.當(dāng)發(fā)送方一連收到3個(gè)對(duì)同一個(gè)報(bào)文段的重復(fù)確認(rèn)時(shí)，采用快速重傳算法，立即進(jìn)行重傳，這樣就不會(huì)出現(xiàn)超時(shí)，可以使整個(gè)網(wǎng)絡(luò)的吞吐量提高約20%。

————————————————
版權(quán)聲明：本文為CSDN博主「nZk丶」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_43729854/article/details/107633250