- 自動重傳請求（ARQ、平均往返時間）
- 流量控制 （接受窗口rwnd）
- 擁塞控制（擁塞窗口cwnd）
0、概述：
眾所周知，TCP/IP是面向鏈接的可靠傳輸協(xié)議，但是問題是如何實現(xiàn)可靠傳輸?shù)哪?？在我看來，TCP/IP可靠傳輸?shù)幕A(chǔ)是滑動窗口協(xié)議和連續(xù)ARQ協(xié)議，配合著流量控制和擁塞控制，使得整個傳輸過程保證：
傳輸信道不產(chǎn)生差錯
不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù)，接收方總是來得及處理收到的數(shù)據(jù)（通過累計確認、超時重傳、擁塞控制三大模塊保證）
1、停止等待協(xié)議和自動重傳請求(ARQ)
所謂停止等待協(xié)議就是每發(fā)送完一個分組就停止發(fā)送，等待對方的確認。在收到確認后再發(fā)送下一個分組。但是在傳輸過程中可能出現(xiàn)意外，這時候就需要用到ARQ協(xié)議了，比如說：B可能沒有收到A發(fā)送的M1M1
這時候A就會有個超時計時器，當超時計時器到期時沒收到B的確認報文，則A重新發(fā)送M1M1，因此必須保證以下幾點：
A發(fā)送完一個分組后，必須暫時保留已發(fā)送的分組副本，只有收到確認后才能清除分組副本
分組和確認分組都必須進行編號
-
超時計時器設(shè)置的重傳時間應當比數(shù)據(jù)在分組傳輸?shù)耐禃r間更長一些
如果A對于B的發(fā)送的數(shù)據(jù)有一定的延遲，但是B接收到了后A還是重新發(fā)送了同樣的數(shù)據(jù)（可能超時了A認為丟包所以重新發(fā)送了），對于重復的數(shù)據(jù)包和響應信號AB都會不會再處理。
2、以字節(jié)為單位的滑動窗口（累計確認方式）
為了提高信道的利用率，實際上采用了流水線傳輸?shù)姆桨浮?br> 這時就需要使用連續(xù)ARQ協(xié)議和滑動窗口協(xié)議。發(fā)送方和接收方各自維持著發(fā)送窗口和接受窗口，發(fā)送方每收到一個確認，就把發(fā)送窗口向前滑動一個分組的位置。接收方一般采用累計確認方式，即接收方不必對收到的分組逐個發(fā)送確認，而是可以在收到幾個分組后，對按序到達的最后一個分組發(fā)送確認，這樣就表示：到這個分組位置的所有分組都已經(jīng)正確收到了。
- A向B發(fā)送數(shù)據(jù)，B的初始滑動窗口的大小是20；因此A只能發(fā)送滑動窗口大小內(nèi)的數(shù)據(jù)，在發(fā)送了20個字節(jié)的數(shù)據(jù)且沒有得到B的相應ACK信號的之前無法繼續(xù)發(fā)送了；A不是發(fā)一次數(shù)據(jù)就要等B相應再發(fā)下一次數(shù)據(jù)，而是不斷發(fā)送自己在發(fā)送窗口內(nèi)的數(shù)據(jù)，直到發(fā)完。
- B接收到1到6的數(shù)據(jù)包后會發(fā)出相應ACK信號（應該是接收到一部分數(shù)據(jù)后暫時沒有新的數(shù)據(jù)B就會去相應），此時ACK中的seq=7，告訴A要發(fā)序列號為7后面的數(shù)據(jù)了；
- A再接收到相應信號ACK后滑動自己的窗口到序列號為7的位置，此時A中1到6的數(shù)據(jù)就沒有必要一直存放了，可以刪掉了；此時A還可以繼續(xù)發(fā)送滑動窗口中之前未發(fā)送的21到25字節(jié)的數(shù)據(jù)；
-
B在確認收到1到6的數(shù)據(jù)后，B這邊的應用程序就可以開始處理這些確認過的數(shù)據(jù)了。同時B還會繼續(xù)確認A發(fā)送過的數(shù)據(jù)了
如果出現(xiàn)丟包TCP協(xié)議是怎么處理的？
- A向B發(fā)送數(shù)據(jù)，但是由于網(wǎng)絡原因?qū)е虏糠謥G包（7、8、9）
- B發(fā)現(xiàn)自己沒有收到7開頭的數(shù)據(jù)包（但是收到了10、11、12的數(shù)據(jù)包），因此就會發(fā)送選擇性ACK信號，seq=7，這樣A收到該選擇性確認后就知道自己之前發(fā)送的（7、8、9）的數(shù)據(jù)包已經(jīng)丟失了，需要進行重傳，同時也知道了1到6已經(jīng)接受了，就不繼續(xù)發(fā)送10、11、12了。
2、超時重傳時間選擇
RTT表示往返時間，其中的s表示甲醛平均的意思？
