1. TCP 可靠性如何保證?
- 信道可靠:用三次握手、四次揮手保證連接正確;
- 數(shù)據(jù)正確:分區(qū)編號、校驗和、超時重傳;
- 傳輸控制:流量控制、擁塞控制
2. 重傳機制
TCP可靠傳輸方式是序列號與確認應(yīng)答。當傳送數(shù)據(jù)包丟失時,會用重傳機制解決。常見重傳機制有超時重傳、快速重傳、SACK、D-SACK。

創(chuàng)新互聯(lián)建站專注于汾西網(wǎng)站建設(shè)服務(wù)及定制,我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供汾西營銷型網(wǎng)站建設(shè),汾西網(wǎng)站制作、汾西網(wǎng)頁設(shè)計、汾西網(wǎng)站官網(wǎng)定制、
小程序設(shè)計服務(wù),打造汾西網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供
汾西網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
2.1 超時重傳
TCP協(xié)議要求在發(fā)送端每發(fā)送一個報文段,就啟動一個定時器并等待確認信息;接收端成功接收新數(shù)據(jù)后返回確認信息。若在定時器超時前數(shù)據(jù)未能被確認,TCP就認為報文段中的數(shù)據(jù)已丟失或損壞,需要對報文段中的數(shù)據(jù)重新組織和重傳。
2.2 快速重傳
?如果收到一個失序的報文段時, TCP需要立刻產(chǎn)生一個ACK,這個ACK不應(yīng)該被延時,目的在于讓對方知道收到一個失序的報文,并告訴對方自己希望收到的報文seq,我們不知道這個重復(fù)的ACK的原因,因為還是會等待少量的重復(fù)ACK到來,如果連續(xù)收到3個或者3個以上的dup ACK,就被判斷這個報文被丟失了,于是就需要立即重傳丟失的數(shù)據(jù)段,這個地方不用等待定時器溢出。
3. 滑動窗口協(xié)議
在TCP協(xié)議中,發(fā)送方和接受方通過各自維護自己的緩沖區(qū)。通過商定包的重傳機制等一系列操作,來解決不可靠的問題。為了增加網(wǎng)絡(luò)的吞吐量,想將數(shù)據(jù)包一起發(fā)送過去,便產(chǎn)生了“滑動窗口”協(xié)議 。
滑動窗口實現(xiàn)
在圖中,我們可看出灰色1號2號3號包已經(jīng)發(fā)送完畢,并且已經(jīng)收到Ack。這些包就已經(jīng)是過去式。4、5、6、7號包是黃色的,表示已經(jīng)發(fā)送了。但是并沒有收到對方的Ack,所以也不知道接收方有沒有收到。8、9、10號包是綠色的。是我們還沒有發(fā)送的。這些綠色也就是我們接下來馬上要發(fā)送的包。 可以看出我們的窗口正好是11個。后面的11-16還沒有被讀進內(nèi)存。要等4號-10號包有接下來的動作后,我們的包才會繼續(xù)往下發(fā)送。
正常情況
可以看到4號包對方已經(jīng)被接收到,所以被涂成了灰色。“窗口”就往右移一格,這里只要保證“窗口”是7格的。 我們就把11號包讀進了我們的緩存。進入了“待發(fā)送”的狀態(tài)。8、9號包已經(jīng)變成了黃色,表示已經(jīng)發(fā)送出去了。接下來的操作就是一樣的了,確認包后,窗口往后移繼續(xù)將未發(fā)送的包讀進緩存,把“待發(fā)送“狀態(tài)的包變?yōu)椤币寻l(fā)送“。
丟包情況
有可能我們爆發(fā)過去,對方的Ack丟了。也有可能我們的包并沒有發(fā)送過去。從發(fā)送方角度看就是我們沒有收到Ack。發(fā)生的情況:一直在等Ack。如果一直等不到的話,我們也會把讀進緩存的待發(fā)送的包也一起發(fā)過去。但是,這個時候我們的窗口已經(jīng)發(fā)滿了。所以并不能把12號包讀進來,而是始終在等待5號包的Ack。
超時重發(fā)
這個Ack是要按順序的。必須要等到5的Ack收到,才會把6-11的Ack發(fā)送過去。這樣就保證了滑動窗口的一個順序。 這時候可以看出5號包已經(jīng)接受到Ack,后面的6、7、8號包也已經(jīng)發(fā)送過去已Ack。窗口便繼續(xù)向后移動。
4. 流量控制
如果發(fā)送方把數(shù)據(jù)發(fā)送得過快,接收方可能會來不及接收,這就會造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快,要讓接收方來得及接收。原理這就是運用TCP報文段中的窗口大小字段來控制,發(fā)送方的發(fā)送窗口不可以大于接收方發(fā)回的窗口大小。?接收端將自己可以接收的緩沖區(qū)大小放入 TCP 首部中的 “窗口大小” 字段, 通過ACK端通知發(fā)送端;窗口大小字段越大, 說明網(wǎng)絡(luò)的吞吐量越高;接收端一旦發(fā)現(xiàn)自己的緩沖區(qū)快滿了, 就會將窗口大小設(shè)置成一個更小的值通知給發(fā)送端;發(fā)送端接受到這個窗口之后, 就會減慢自己的發(fā)送速度;如果接收端緩沖區(qū)滿了, 就會將窗口置為0; 這時發(fā)送方不再發(fā)送數(shù)據(jù), 但是需要定期發(fā)送一個窗口探測數(shù)據(jù)段, 使接收端把窗口大小告訴發(fā)送端
問題1:窗口關(guān)閉是什么?怎么解決?
現(xiàn)象:接收方若沒有緩存足夠使用,就會發(fā)送零窗口大小的報文,此時發(fā)送放將發(fā)送窗口設(shè)置為0,停止發(fā)送數(shù)據(jù)。之后接收方有足夠的緩存,發(fā)送了非零窗口大小的報文,但是這個報文在中途丟失,那么發(fā)送方的發(fā)送窗口就一直為零導(dǎo)致死鎖 。解決:TCP連接方收到零窗口通知就啟動計時器,發(fā)送窗口探測報文。探測時,若接收窗口仍為0,那接收報文一方就重新啟動計時器;若不是0,死鎖局面打破。
問題2:糊涂窗口綜合征是什么?怎么解決?
接收方騰出幾個字節(jié)告訴發(fā)送方窗口大小,而發(fā)送方會義無反顧發(fā)送這幾個字節(jié),導(dǎo)致報文利用率很低,這就是糊涂窗口綜合征解決方式:1.讓接收方不通告小窗口給發(fā)送方
if 窗口大小
網(wǎng)站欄目:tcp如何保證可靠性(http協(xié)議哪一層)
文章分享:http://www.rwnh.cn/article48/dhhp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供服務(wù)器托管、網(wǎng)站改版、手機網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計、自適應(yīng)網(wǎng)站、靜態(tài)網(wǎng)站
廣告
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源:
創(chuàng)新互聯(lián)