tcp可靠傳輸的機制有哪些（面試必看

1、綜述

一、確認和重傳：接收方收到報文就會確認，發送方發送一段時間後沒有收到確認就重傳。

二、數據校驗

三、數據合理分片和排序：

　　UDP：IP數據報大於1500字節,大於MTU.這個時候發送方IP層就須要分片(fragmentation).把數據報分紅若干片,使每一片都小於MTU.而接收方IP層則須要進行數據報的重組.這樣就會多作許多事情,而更嚴重的是,因爲UDP的特性,當某一片數據傳送中丟失時,接收方便沒法重組數據報.將致使丟棄整個UDP數據報.

　　tcp會按MTU合理分片，接收方會緩存未按序到達的數據，從新排序後再交給應用層。

四、流量控制：當接收方來不及處理髮送方的數據，能提示發送方下降發送的速率，防止包丟失。

五、擁塞控制：當網絡擁塞時，減小數據的發送。

2、滑動窗口

　　上面籠統地說了tcp保證可靠傳輸的機制，下面說說如何用滑動窗口來實現。

爲何要使用滑動窗口

由於發送端但願在收到確認前，繼續發送其它報文段。好比說在收到0號報文的確認前還發出了1-3號的報文，這樣提升了信道的利用率。但能夠想一想，0-4發出去後可能要重傳，因此須要一個緩衝區維護這些報文，因此就有了窗口。

　　RTT：往返時間。

窗口是什麼

接收窗口：

　　

　　「接收窗口」大小取決於應用（好比說tomcat：8080端口的監聽進程）、系統、硬件的限制。圖中，接收窗口是31~50，大小爲20。

　　在接收窗口中，黑色的表示已收到的數據，白色的表示未收到的數據。

　　當收到窗口左邊的數據，如27，則丟棄，由於這部分已經交付給主機；

　　當收到窗口左邊的數據，如52，則丟棄，由於還沒輪到它；

　　當收到已收到的窗口中的數據，如32，丟棄；

　　當收到未收到的窗口中的數據，如35，緩存在窗口中。

發送窗口：

　　發送窗口的大小swnd=min（rwnd，cwnd）。rwnd是接收窗口，cwnd用於擁塞控制，暫時能夠理解爲swnd= rwnd =20。

　　圖中分爲四個區段，其中P1到P3是發送窗口。

　　tips：發送窗口以字節爲單位。爲了方便畫圖，圖中展現得像以報文爲單位同樣。但這不影響理解。

3、重傳和確認

何時發確認：這是一個複雜的策略。咱們這裏先簡單地認爲每收到一個報文就發一個確認。

怎麼確認（累計確認）：

　　狀況1：發送ack=31（爲何這個也要發，這個確承認以用於後面的擁塞控制）

　　狀況2：發送ack=34，並把接收窗口左邊緣設置成34，右邊緣設置成53

　　

　　累計確認的好處：狀況1中ack=31比描述收到32和33簡單；壞處：可能要重傳已經接收的數據。

發送方收到確認時怎麼處理：

　　

　　狀況1：收到ack=31，什麼都不作，或者說繼續發送可用窗口中的內容，如42~50

　　狀況2：收到ack=34，發送窗口窗口的左邊緣設置成34，右邊緣設置成53

何時重傳：由於每一個報文都有超時計數器，超時才重傳。超時重傳時間的選擇也是一個策略。

tcp緩存和窗口的關係：窗口是緩存的一部分。

發送緩存=發送窗口+ P3右邊的一部分

接收緩存=接收窗口+部分已確認但主機還沒處理完的數據。

4、流量控制

一圖流，簡單來講就是接收方處理不過來的時候，就把窗口縮小，並把窗口值告訴發送端。

　　

當窗口值爲0，而接受方把窗口值恢復（好比ACK=1，ack=601，rwnd=200），但確認丟失，進入相互等待的死鎖局面。因此若是窗口值爲0，發送端就會開啓一個持續計數器，每一個一段時間詢問一下接收方。

5、擁塞控制

swnd=min（rwnd，cwnd），cwnd就是擁塞窗口大小。

慢開始和擁塞避免

ssthresh：處理擁塞時參照的一個參數。例子中初始值爲16，後來變爲12。

當cwnd> ssthresh，cwnd以慢開始的方法指數增加；

當cwnd< ssthresh，cwnd以擁塞避免的方法線性增加。

值得注意的幾個點

1上圖是cwnd隨傳輸輪次的變化，每過一個RTT就算一輪。

2超時就能夠認爲是擁塞了

快重傳和快恢復：上一個算法的增強版

快重傳：收到3個一樣的確認就馬上重傳，不等到超時；

快恢復：cwnd不是從1從新開始。

　　

標籤: tcp, 滑動窗口

好文要頂 關注我 收藏該文   

淺井光一

關注 - 4

粉絲 - 19

+加關注

1 0

« 上一篇：內存管理

» 下一篇：線程的建立終止和生命週期

posted @ 2016-05-08 19:12 淺井光一 閱讀(5517) 評論(0) 編輯 收藏1、綜述

一、確認和重傳：接收方收到報文就會確認，發送方發送一段時間後沒有收到確認就重傳。

二、數據校驗

三、數據合理分片和排序：

　　UDP：IP數據報大於1500字節,大於MTU.這個時候發送方IP層就須要分片(fragmentation).把數據報分紅若干片,使每一片都小於MTU.而接收方IP層則須要進行數據報的重組.這樣就會多作許多事情,而更嚴重的是,因爲UDP的特性,當某一片數據傳送中丟失時,接收方便沒法重組數據報.將致使丟棄整個UDP數據報.

　　tcp會按MTU合理分片，接收方會緩存未按序到達的數據，從新排序後再交給應用層。

四、流量控制：當接收方來不及處理髮送方的數據，能提示發送方下降發送的速率，防止包丟失。

五、擁塞控制：當網絡擁塞時，減小數據的發送。

2、滑動窗口

　　上面籠統地說了tcp保證可靠傳輸的機制，下面說說如何用滑動窗口來實現。

爲何要使用滑動窗口

由於發送端但願在收到確認前，繼續發送其它報文段。好比說在收到0號報文的確認前還發出了1-3號的報文，這樣提升了信道的利用率。但能夠想一想，0-4發出去後可能要重傳，因此須要一個緩衝區維護這些報文，因此就有了窗口。

　　RTT：往返時間。

窗口是什麼

接收窗口：

　　

　　「接收窗口」大小取決於應用（好比說tomcat：8080端口的監聽進程）、系統、硬件的限制。圖中，接收窗口是31~50，大小爲20。

　　在接收窗口中，黑色的表示已收到的數據，白色的表示未收到的數據。

　　當收到窗口左邊的數據，如27，則丟棄，由於這部分已經交付給主機；

　　當收到窗口左邊的數據，如52，則丟棄，由於還沒輪到它；

　　當收到已收到的窗口中的數據，如32，丟棄；

　　當收到未收到的窗口中的數據，如35，緩存在窗口中。

發送窗口：

　　發送窗口的大小swnd=min（rwnd，cwnd）。rwnd是接收窗口，cwnd用於擁塞控制，暫時能夠理解爲swnd= rwnd =20。

　　圖中分爲四個區段，其中P1到P3是發送窗口。

　　tips：發送窗口以字節爲單位。爲了方便畫圖，圖中展現得像以報文爲單位同樣。但這不影響理解。

3、重傳和確認

何時發確認：這是一個複雜的策略。咱們這裏先簡單地認爲每收到一個報文就發一個確認。

怎麼確認（累計確認）：

　　狀況1：發送ack=31（爲何這個也要發，這個確承認以用於後面的擁塞控制）

　　狀況2：發送ack=34，並把接收窗口左邊緣設置成34，右邊緣設置成53

　　

　　累計確認的好處：狀況1中ack=31比描述收到32和33簡單；壞處：可能要重傳已經接收的數據。

發送方收到確認時怎麼處理：

　　

　　狀況1：收到ack=31，什麼都不作，或者說繼續發送可用窗口中的內容，如42~50

　　狀況2：收到ack=34，發送窗口窗口的左邊緣設置成34，右邊緣設置成53

何時重傳：由於每一個報文都有超時計數器，超時才重傳。超時重傳時間的選擇也是一個策略。

tcp緩存和窗口的關係：窗口是緩存的一部分。

發送緩存=發送窗口+ P3右邊的一部分

接收緩存=接收窗口+部分已確認但主機還沒處理完的數據。

4、流量控制

一圖流，簡單來講就是接收方處理不過來的時候，就把窗口縮小，並把窗口值告訴發送端。

　　

當窗口值爲0，而接受方把窗口值恢復（好比ACK=1，ack=601，rwnd=200），但確認丟失，進入相互等待的死鎖局面。因此若是窗口值爲0，發送端就會開啓一個持續計數器，每一個一段時間詢問一下接收方。

5、擁塞控制

swnd=min（rwnd，cwnd），cwnd就是擁塞窗口大小。

慢開始和擁塞避免

ssthresh：處理擁塞時參照的一個參數。例子中初始值爲16，後來變爲12。

當cwnd> ssthresh，cwnd以慢開始的方法指數增加；

當cwnd< ssthresh，cwnd以擁塞避免的方法線性增加。

值得注意的幾個點

1上圖是cwnd隨傳輸輪次的變化，每過一個RTT就算一輪。

2超時就能夠認爲是擁塞了

快重傳和快恢復：上一個算法的增強版

快重傳：收到3個一樣的確認就馬上重傳，不等到超時；

快恢復：cwnd不是從1從新開始。

做者：kexinJiao 連接：https://www.jianshu.com/p/17d0ad2e8fd2 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。