tcp擁塞演算法
⑴ 在TCP的擁塞控制中,什麼是慢開始、擁塞避免、快重傳和快恢復演算法
慢開始：在主機剛剛開始發送報文段時可先將擁塞窗口cwnd設置為一個最大報文段MSS的數值。在每收到一個對新的報文段的確認後，將擁塞窗口增加至多一個MSS的數值。
擁塞避免：當擁塞窗口值大於慢開始門限時，停止使用慢開始演算法而改用擁塞避免演算法。
快重傳演算法：發送端只要一連收到三個重復的ACK即可斷定有分組丟失了，就應該立即重傳丟手的報文段而不必繼續等待為該報文段設置的重傳計時器的超時。
接下來執行的不是慢啟動演算法而是擁塞避免演算法。這就是快速恢復演算法。.
防止擁塞的方法
（1）在傳輸層可採用：重傳策略、亂序緩存策略、確認策略、流控制策略和確定超時策略。
（2）在網路層可採用：子網內部的虛電路與數據報策略、分組排隊和服務策略、分組丟棄策略、路由演算法和分組生存管理。
（3）在數據鏈路層可採用：重傳策略、亂序緩存策略、確認策略和流控制策略。
⑵ 常見的tcp擁塞控制有哪幾種演算法
慢啟動：最初的TCP在連接建立成功後會向網路中發送大量的數據包，這樣很容易導致網路中路由器緩存空間耗盡，從而發生擁塞。因此新建立的連接不能夠一開始就大量發送數據包，而只能根據網路情況逐步增加每次發送的數據量，以避免上述現象的發生。具體來說，當新建連接時，cwnd初始化為1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增加1個MSS大小。這樣cwnd的值就隨著網路往返時間(Round Trip Time,RTT)呈指數級增長，事實上，慢啟動的速度一點也不慢，只是它的起點比較低一點而已。我們可以簡單計算下：
開始 ---> cwnd = 1
經過1個RTT後 ---> cwnd = 2*1 = 2
經過2個RTT後 ---> cwnd = 2*2= 4
經過3個RTT後 ---> cwnd = 4*2 = 8
如果帶寬為W，那麼經過RTT*log2W時間就可以占滿帶寬。
擁塞避免：從慢啟動可以看到，cwnd可以很快的增長上來，從而最大程度利用網路帶寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制。TCP使用了一個叫慢啟動門限(ssthresh)的變數，當cwnd超過該值後，慢啟動過程結束，進入擁塞避免階段。對於大多數TCP實現來說，ssthresh的值是65536(同樣以位元組計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值不再指數級往上升，開始加法增加。此時當窗口中所有的報文段都被確認時，cwnd的大小加1，cwnd的值就隨著RTT開始線性增加，這樣就可以避免增長過快導致網路擁塞，慢慢的增加調整到網路的最佳值。
上面討論的兩個機制都是沒有檢測到擁塞的情況下的行為，那麼當發現擁塞了cwnd又該怎樣去調整呢？
首先來看TCP是如何確定網路進入了擁塞狀態的，TCP認為網路擁塞的主要依據是它重傳了一個報文段。上面提到過，TCP對每一個報文段都有一個定時器，稱為重傳定時器(RTO)，當RTO超時且還沒有得到數據確認，那麼TCP就會對該報文段進行重傳，當發生超時時，那麼出現擁塞的可能性就很大，某個報文段可能在網路中某處丟失，並且後續的報文段也沒有了消息，在這種情況下，TCP反應比較「強烈」：
1.把ssthresh降低為cwnd值的一半
2.把cwnd重新設置為1
3.重新進入慢啟動過程。
從整體上來講，TCP擁塞控制窗口變化的原則是AIMD原則，即加法增大、乘法減小。可以看出TCP的該原則可以較好地保證流之間的公平性，因為一旦出現丟包，那麼立即減半退避，可以給其他新建的流留有足夠的空間，從而保證整個的公平性。
其實TCP還有一種情況會進行重傳：那就是收到3個相同的ACK。TCP在收到亂序到達包時就會立即發送ACK，TCP利用3個相同的ACK來判定數據包的丟失，此時進行快速重傳，快速重傳做的事情有：
1.把ssthresh設置為cwnd的一半
2.把cwnd再設置為ssthresh的值(具體實現有些為ssthresh+3)
3.重新進入擁塞避免階段。
後來的「快速恢復」演算法是在上述的「快速重傳」演算法後添加的，當收到3個重復ACK時，TCP最後進入的不是擁塞避免階段，而是快速恢復階段。快速重傳和快速恢復演算法一般同時使用。快速恢復的思想是「數據包守恆」原則，即同一個時刻在網路中的數據包數量是恆定的，只有當「老」數據包離開了網路後，才能向網路中發送一個「新」的數據包，如果發送方收到一個重復的ACK，那麼根據TCP的ACK機制就表明有一個數據包離開了網路，於是cwnd加1。如果能夠嚴格按照該原則那麼網路中很少會發生擁塞，事實上擁塞控制的目的也就在修正違反該原則的地方。
具體來說快速恢復的主要步驟是：
1.當收到3個重復ACK時，把ssthresh設置為cwnd的一半，把cwnd設置為ssthresh的值加3，然後重傳丟失的報文段，加3的原因是因為收到3個重復的ACK，表明有3個「老」的數據包離開了網路。
2.再收到重復的ACK時，擁塞窗口增加1。
3.當收到新的數據包的ACK時，把cwnd設置為第一步中的ssthresh的值。原因是因為該ACK確認了新的數據，說明從重復ACK時的數據都已收到，該恢復過程已經結束，可以回到恢復之前的狀態了，也即再次進入擁塞避免狀態。
快速重傳演算法首次出現在4.3BSD的Tahoe版本，快速恢復首次出現在4.3BSD的Reno版本，也稱之為Reno版的TCP擁塞控制演算法。
可以看出Reno的快速重傳演算法是針對一個包的重傳情況的，然而在實際中，一個重傳超時可能導致許多的數據包的重傳，因此當多個數據包從一個數據窗口中丟失時並且觸發快速重傳和快速恢復演算法時，問題就產生了。因此NewReno出現了，它在Reno快速恢復的基礎上稍加了修改，可以恢復一個窗口內多個包丟失的情況。具體來講就是：Reno在收到一個新的數據的ACK時就退出了快速恢復狀態了，而NewReno需要收到該窗口內所有數據包的確認後才會退出快速恢復狀態，從而更一步提高吞吐量。
SACK就是改變TCP的確認機制，最初的TCP只確認當前已連續收到的數據，SACK則把亂序等信息會全部告訴對方，從而減少數據發送方重傳的盲目性。比如說序號1，2，3，5，7的數據收到了，那麼普通的ACK只會確認序列號4，而SACK會把當前的5，7已經收到的信息在SACK選項裡面告知對端，從而提高性能，當使用SACK的時候，NewReno演算法可以不使用，因為SACK本身攜帶的信息就可以使得發送方有足夠的信息來知道需要重傳哪些包，而不需要重傳哪些包。
⑶ TCP的擁塞控制演算法中,請簡述慢開始演算法和擁塞避免演算法的基本思想
慢開始演算法:
cwnd每收到一個acknowledge增加1
擁塞避免演算法
當cwnd達到或者超過當前設定的threshold後，cwnd每個RTT增加1。
如果發生timeout, cwnd = 1，threshold=cwnd/2. 重新進入慢開始。
如果收到3個重復的acknowledgement, cwnd = threshold = cwnd/2.
⑷ TCP擁塞控制
以下資料參考：為了防止網路的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由「慢啟動(Slow start)」和「擁塞避免(Congestion avoidance)」組成，後來TCP Reno版本中又針對性的加入了「快速重傳(Fast retransmit)」、「快速恢復(Fast Recovery)」演算法，再後來在TCP NewReno中又對「快速恢復」演算法進行了改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)演算法，還有其他方面的大大小小的改進，成為網路研究的一個熱點。TCP的擁塞控制主要原理依賴於一個擁塞窗口(cwnd)來控制，在之前我們還討論過TCP還有一個對端通告的接收窗口(rwnd)用於流量控制。窗口值的大小就代表能夠發送出去的但還沒有收到ACK的最大數據報文段，顯然窗口越大那麼數據發送的速度也就越快，但是也有越可能使得網路出現擁塞，如果窗口值為1，那麼就簡化為一個停等協議，每發送一個數據，都要等到對方的確認才能發送第二個數據包，顯然數據傳輸效率低下。TCP的擁塞控制演算法就是要在這兩者之間權衡，選取最好的cwnd值，從而使得網路吞吐量最大化且不產生擁塞。由於需要考慮擁塞控制和流量控制兩個方面的內容，因此TCP的真正的發送窗口=min(rwnd, cwnd)。但是rwnd是由對端確定的，網路環境對其沒有影響，所以在考慮擁塞的時候我們一般不考慮rwnd的值，我們暫時只討論如何確定cwnd值的大小。關於cwnd的單位，在TCP中是以位元組來做單位的，我們假設TCP每次傳輸都是按照MSS大小來發送數據的，因此你可以認為cwnd按照數據包個數來做單位也可以理解，所以有時我們說cwnd增加1也就是相當於位元組數增加1個MSS大小。慢啟動：最初的TCP在連接建立成功後會向網路中發送大量的數據包，這樣很容易導致網路中路由器緩存空間耗盡，從而發生擁塞。因此新建立的連接不能夠一開始就大量發送數據包，而只能根據網路情況逐步增加每次發送的數據量，以避免上述現象的發生。具體來說，當新建連接時，cwnd初始化為1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增加1個MSS大小。這樣cwnd的值就隨著網路往返時間(Round Trip Time,RTT)呈指數級增長，事實上，慢啟動的速度一點也不慢，只是它的起點比較低一點而已。我們可以簡單計算下： 開始 ---> cwnd = 1 經過1個RTT後 ---> cwnd = 2*1 = 2 經過2個RTT後 ---> cwnd = 2*2= 4 經過3個RTT後 ---> cwnd = 4*2 = 8如果帶寬為W，那麼經過RTT*log2W時間就可以占滿帶寬。擁塞避免：從慢啟動可以看到，cwnd可以很快的增長上來，從而最大程度利用網路帶寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制。TCP使用了一個叫慢啟動門限(ssthresh)的變數，當cwnd超過該值後，慢啟動過程結束，進入擁塞避免階段。對於大多數TCP實現來說，ssthresh的值是65536(同樣以位元組計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值不再指數級往上升，開始加法增加。此時當窗口中所有的報文段都被確認時，cwnd的大小加1，cwnd的值就隨著RTT開始線性增加，這樣就可以避免增長過快導致網路擁塞，慢慢的增加調整到網路的最佳值。上面討論的兩個機制都是沒有檢測到擁塞的情況下的行為，那麼當發現擁塞了cwnd又該怎樣去調整呢？首先來看TCP是如何確定網路進入了擁塞狀態的，TCP認為網路擁塞的主要依據是它重傳了一個報文段。上面提到過，TCP對每一個報文段都有一個定時器，稱為重傳定時器(RTO)，當RTO超時且還沒有得到數據確認，那麼TCP就會對該報文段進行重傳，當發生超時時，那麼出現擁塞的可能性就很大，某個報文段可能在網路中某處丟失，並且後續的報文段也沒有了消息，在這種情況下，TCP反應比較「強烈」：1.把ssthresh降低為cwnd值的一半2.把cwnd重新設置為13.重新進入慢啟動過程。從整體上來講，TCP擁塞控制窗口變化的原則是AIMD原則，即加法增大、乘法減小。可以看出TCP的該原則可以較好地保證流之間的公平性，因為一旦出現丟包，那麼立即減半退避，可以給其他新建的流留有足夠的空間，從而保證整個的公平性。其實TCP還有一種情況會進行重傳：那就是收到3個相同的ACK。TCP在收到亂序到達包時就會立即發送ACK，TCP利用3個相同的ACK來判定數據包的丟失，此時進行快速重傳，快速重傳做的事情有：1.把ssthresh設置為cwnd的一半2.把cwnd再設置為ssthresh的值(具體實現有些為ssthresh+3)3.重新進入擁塞避免階段。後來的「快速恢復」演算法是在上述的「快速重傳」演算法後添加的，當收到3個重復ACK時，TCP最後進入的不是擁塞避免階段，而是快速恢復階段。快速重傳和快速恢復演算法一般同時使用。快速恢復的思想是「數據包守恆」原則，即同一個時刻在網路中的數據包數量是恆定的，只有當「老」數據包離開了網路後，才能向網路中發送一個「新」的數據包，如果發送方收到一個重復的ACK，那麼根據TCP的ACK機制就表明有一個數據包離開了網路，於是cwnd加1。如果能夠嚴格按照該原則那麼網路中很少會發生擁塞，事實上擁塞控制的目的也就在修正違反該原則的地方。具體來說快速恢復的主要步驟是：1.當收到3個重復ACK時，把ssthresh設置為cwnd的一半，把cwnd設置為ssthresh的值加3，然後重傳丟失的報文段，加3的原因是因為收到3個重復的ACK，表明有3個「老」的數據包離開了網路。 2.再收到重復的ACK時，擁塞窗口增加1。3.當收到新的數據包的ACK時，把cwnd設置為第一步中的ssthresh的值。原因是因為該ACK確認了新的數據，說明從重復ACK時的數據都已收到，該恢復過程已經結束，可以回到恢復之前的狀態了，也即再次進入擁塞避免狀態。快速重傳演算法首次出現在4.3BSD的Tahoe版本，快速恢復首次出現在4.3BSD的Reno版本，也稱之為Reno版的TCP擁塞控制演算法。可以看出Reno的快速重傳演算法是針對一個包的重傳情況的，然而在實際中，一個重傳超時可能導致許多的數據包的重傳，因此當多個數據包從一個數據窗口中丟失時並且觸發快速重傳和快速恢復演算法時，問題就產生了。因此NewReno出現了，它在Reno快速恢復的基礎上稍加了修改，可以恢復一個窗口內多個包丟失的情況。具體來講就是：Reno在收到一個新的數據的ACK時就退出了快速恢復狀態了，而NewReno需要收到該窗口內所有數據包的確認後才會退出快速恢復狀態，從而更一步提高吞吐量。SACK就是改變TCP的確認機制，最初的TCP只確認當前已連續收到的數據，SACK則把亂序等信息會全部告訴對方，從而減少數據發送方重傳的盲目性。比如說序號1，2，3，5，7的數據收到了，那麼普通的ACK只會確認序列號4，而SACK會把當前的5，7已經收到的信息在SACK選項裡面告知對端，從而提高性能，當使用SACK的時候，NewReno演算法可以不使用，因為SACK本身攜帶的信息就可以使得發送方有足夠的信息來知道需要重傳哪些包，而不需要重傳哪些包。
⑸ TCP採用哪些機制來實現可靠數據傳輸、流控和擁塞控制
1.採用面向連接的三次握手實現可靠對象傳輸。
2.使用數據窗口機制協商隊列大小實現數據隊列傳輸。
3.通過序列化應答和必要時重發數據包，TCP 為應用程序提供了可靠的傳輸流和虛擬連接服務。
下面是找到的長篇大論中比較好的文章：
一、TCP協議
1、TCP 通過以下方式提供可靠性：
◆ 應用程序分割為TCP認為最合適發送的數據塊。由TCP傳遞給IP的信息單位叫做報文段。
◆ 當TCP發出一個報文段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能記時收到一個確認，它 就重發這個報文段。
◆ 當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常延遲幾分之一秒。
◆ TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化如果收到報文段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到這個報文段。
◆ 既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能失序，因此TCP報文段的到達也可能失序。如果必要，TCP將對收到的數據進行排序，將收到的數據以正確的順序交給應用層。
◆ 既然IP數據報會發生重復，TCP連接端必須丟棄重復的數據。
◆ TCP還能提供流量控制，TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發送接收端緩沖區所能接納的數據。這將防止較快主機致使較慢主機的緩沖區溢出。
另外，TCP對位元組流的內容不作任何解釋。
2、TCP首部：
TCP數據被封裝在一個IP數據報中，格式如下：
IP首部20 TCP首部20 TCP首部
TCP首部格式如下：
16位源埠號 16位目的埠號
32位序號
32位確認序號
4位首部長度 保留6位 U
R
G A
C
K P
S
H R
S
T S
Y
N F
I
N 16位窗口大小
16位檢驗和 16位緊急指針
選項
數據
說明：
（1）每個TCP段都包括源端和目的端的埠號，用於尋找發送端和接收端的應用進程。這兩個值加上IP首部的源端IP地址和目的端IP地址唯一確定一個TCP連接。
（2）序號用來標識從TCP發送端向接收端發送的數據位元組流，它表示在這個報文段中的第一個數據位元組。如果將位元組流看作在兩個應用程序間的單向流動，則TCP用序號對每個位元組進行計數。
（3）當建立一個新連接時，SYN標志變1。序號欄位包含由這個主機選擇的該連接的初始序號ISN，該主機要發送數據的第一個位元組的序號為這個ISN加1，因為SYN標志使用了一個序號。
（4）既然每個被傳輸的位元組都被計數，確認序號包含發送確認的一端所期望收到的下一個序號。因此，確認序號應當時上次已成功收到數據位元組序號加1。只有ACK標志為1時確認序號欄位才有效。
（5）發送ACK無需任何代價，因為32位的確認序號欄位和ACK標志一樣，總是TCP首部的一部分。因此一旦一個連接建立起來，這個欄位總是被設置，ACK標志也總是被設置為1。
（6）TCP為應用層提供全雙工的服務。因此，連接的每一端必須保持每個方向上的傳輸數據序號。
（7）TCP可以表述為一個沒有選擇確認或否認的華東窗口協議。因此TCP首部中的確認序號表示發送方已成功收到位元組，但還不包含確認序號所指的位元組。當前還無法對數據流中選定的部分進行確認。
（8）首部長度需要設置，因為任選欄位的長度是可變的。TCP首部最多60個位元組。
（9）6個標志位中的多個可同時設置為1
◆ URG－緊急指針有效
◆ ACK－確認序號有效
◆ PSH－接收方應盡快將這個報文段交給應用層
◆ RST－重建連接
◆ SYN－同步序號用來發起一個連接
◆ FIN－發送端完成發送任務
（10）TCP的流量控制由連接的每一端通過聲明的窗口大小來提供。窗口大小為位元組數，起始於確認序號欄位指明的值，這個值是接收端期望接收的位元組數。窗口大小是一個16為的欄位，因而窗口大小最大為65535位元組。
（11）檢驗和覆蓋整個TCP報文端：TCP首部和TCP數據。這是一個強制性的欄位，一定是由發送端計算和存儲，並由接收端進行驗證。TCP檢驗和的計算和UDP首部檢驗和的計算一樣，也使用偽首部。
（12）緊急指針是一個正的偏移量，黃蓉序號欄位中的值相加表示緊急數據最後一個位元組的序號。TCP的緊急方式是發送端向另一端發送緊急數據的一種方式。
（13）最常見的可選欄位是最長報文大小MMS，每個連接方通常都在通信的第一個報文段中指明這個選項。它指明本端所能接收的最大長度的報文段。
二、TCP連接的建立和終止
1、建立連接協議
（1） 請求端發送一個SYN段指明客戶打算連接的伺服器的埠，隱疾初始序號(ISN)，這個SYN報文段為報文段1。
（2） 伺服器端發回包含伺服器的初始序號的SYN報文段（報文段2）作為應答。同時將確認序號設置為客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將佔用一個序號。
（3） 客戶必須將確認序號設置為伺服器的ISN加1以對伺服器的SYN報文段進行確認（報文段3）。
這3個報文段完成連接的建立，稱為三次握手。發送第一個SYN的一端將執行主動打開，接收這個SYN並發回下一個SYN的另一端執行被動打開。
2、連接終止協議
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的連接。收到一個FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（1） TCP客戶端發送一個FIN，用來關閉客戶到伺服器的數據傳送（報文段4）。
（2） 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。
（3） 伺服器關閉客戶端的連接，發送一個FIN給客戶端（報文段6）。
（4） 客戶段發回確認，並將確認序號設置為收到序號加1（報文段7）。
3、連接建立的超時
如果與伺服器無法建立連接，客戶端就會三次向伺服器發送連接請求。在規定的時間內伺服器未應答，則連接失敗。
4、最大報文段長度MSS
最大報文段長度表示TCP傳往另一端的最大塊數據的長度。當一個連接建立時，連接的雙方都要通告各自的MSS。
一般，如果沒有分段發生，MSS還是越大越好。報文段越大允許每個報文段傳送的數據越多，相對IP和TCP首部有更高的網路利用率。當TCP發送一個 SYN時，它能將MSS值設置為外出介面的MTU長度減去IP首部和TCP首部長度。對於乙太網，MSS值可達1460。
如果目的地址為非本地的，MSS值通常默認為536，是否本地主要通過網路號區分。MSS讓主機限制另一端發送數據報的長度，加上主機也能控制它發送數據報的長度，這將使以較小MTU連接到一個網路上的主機避免分段。
5、 TCP的半關閉
TCP提供了連接的一端在結束它的發送後還能接收來自另一端數據的能力，這就是TCP的半關閉。
客戶端發送FIN，另一端發送對這個FIN的ACK報文段。當收到半關閉的一端在完成它的數據傳送後，才發送FIN關閉這個方向的連接，客戶端再對這個FIN確認，這個連接才徹底關閉。
6、2MSL連接
TIME_WAIT狀態也稱為2MSL等待狀態。每個TCP必須選擇一個報文段最大生存時間（MSL）。它是任何報文段被丟棄前在網路的最長時間。
處理原則：當TCP執行一個主動關閉，並發回最後一個ACK，該連接必須在TIME_WAIT狀態停留的時間為2MSL。這樣可以讓TCP再次發送最後的ACK以避免這個ACK丟失（另一端超時並重發最後的FIN）。這種2MSL等待的另一個結果是這個TCP連接在2MSL等待期間，定義這個連接的插口不能被使用。
7、平靜時間
TCP在重啟的MSL秒內不能建立任何連接，這就是平靜時間。
8、FIN_WAIT_2狀態
在FIN_WAIT_2狀態我們已經發出了FIN，並且另一端也對它進行了確認。只有另一端的進程完成了這個關閉，我們這端才會從 FIN_WAIT_2狀態進入TIME_WAIT狀態。這意味著我們這端可能永遠保持這個狀態，另一端也將處於CLOSE_WAIT狀態，並一直保持這個狀態直到應用層決定進行關閉。
9、復位報文段
TCP首部的RST位是用於復位的。一般，無論合適一個報文端發往相關的連接出現錯誤，TCP都會發出一個復位報文段。主要情況：
（1）到不存在的埠的連接請求；
（2）異常終止一個連接。
10、同時打開
為了處理同時打開，對於同時打開它僅建立一條連接而不是兩條連接。兩端幾乎在同時發送SYN，並進入SYN_SENT狀態。當每一端收到SYN時，狀態變為SYN_RCVD，同時他們都再發SYN並對收到的SYN進行確認。當雙方都收到SYN及相應的ACK時，狀態都變為ESTABLISHED。一個同時打開的連接需要交換4個報文段，比正常的三次握手多了一次。
11、 同時關閉
當應用層發出關閉命令，兩端均從ESTABLISHED變為FIN_WAIT_1。這將導致雙方各發送一個FIN，兩個FIN經過網路傳送後分別到達另一端。收到FIN後，狀態由FIN_WAIT_1變為CLOSING，並發送最後的ACK。當收到最後的ACK，狀態變為TIME_WAIT。同時關閉和正常關閉的段減緩數目相同。
12、TCP選項
每個選項的開始是1位元組的kind欄位，說明選項的類型。
Kind=1:選項表結束（1位元組） Kind=1:無操作（1位元組） Kind=2：最大報文段長度（4位元組） Kind=3:窗口擴大因子（4位元組） Kind=8:時間戳（10位元組）
三、TCP的超時和重傳
對於每個TCP連接，TCP管理4個不同的定時器。
（1） 重傳定時器用於當希望收到另一端的確認。
（2） 堅持定時器使窗口大小信息保持不斷流動，即使另一端關閉了其接收窗口。
（3） 保活定時器可檢測到一個空閑連接的另一端何時崩潰或重啟。
（4） 2MSL定時器測量一個連接處於TIME_WAIT狀態的時間。
1、往返時間測量
TCP超時和重傳重最重要的就是對一個給定連接的往返時間（RTT）的測量。由於路由器和網路流量均會變化，因此TCP應該跟蹤這些變化並相應地改變超時時間。首先TCP必須測量在發送一個帶有特別序號地位元組和接收到包含該位元組地確認之間的RTT。
2、擁塞避免演算法
該演算法假定由於分組收到損壞引起的丟失是非常少的，因此分組丟失就意味著在源主機和目的主機之間的某處網路上發生了阻塞。有兩種分組丟失的指示：發生超時和收到重復的確認。擁塞避免演算法需要對每個連接維持兩個變數：一個擁塞窗口cwnd和一個慢啟動門限ssthresh。
(1) 對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個位元組。
(2) TCP輸出常式的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發送方使用的流量控制。前者是發送方感受到的網路擁塞的估計，而後者則與接收方在該連接上的可用緩存大小有關。
(3) 當擁塞發生時，ssthresh被設置為當前窗口大小的一般(cwnd和接收方通告窗口大小的最小值，但最小為2個報文段)。此外，如果是超時引起了擁塞，則cwnd被設置為1個報文段。
(4) 當新的數據被對方確認時，就增加cwnd，但增加的方法依賴與是否正在進行慢啟動或擁塞避免。如果cwnd小於或等於ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。
3、快速重傳和快速恢復演算法
如果我們一連串收到3個或以上的重復ACK，就非常可能是一個報文段丟失了。於是我們就重傳丟失的數據報文段，而無需等待超時定時器溢出。
（1） 當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半，重傳丟失的報文段，設置cwnd為ssthresh加上3倍的報文段大小。
（2） 每次收到另一個重復的ACK時，cwnd增加1個報文段大小並發送一個1個分組，如果允許的話。
（3）當下一個確認新數據的ACK到達時，設置cwnd為ssthresh，這個ACK應該時在進行重傳後的一個往返時間內對步驟1重重傳的確認。另外，這個 ACK也應該是對丟失的分組和收到的第一個重復的ACK之間的所有中間報文段的確認。
4、 ICMP差錯
TCP如何處理一個給定的連接返回的ICMP差錯。TCP能夠遇到的最常見的ICMP差錯就是源站抑制、主機不可達和網路不可達。
（1） 一個接收到的源站抑制引起擁塞窗口cwnd被置為1個報文段大小來發起慢啟動，但是慢啟動門限ssthresh沒有變化，所以窗口將打開直到它開放了所有的通路或者發生了擁塞。
（2） 一個接收到的主機不可達或網路不可達實際都被忽略，因為這兩個差錯都被認為是短暫現象。TCP試圖發送引起該差錯的數據，盡管最終有可能會超時。
5、重新分組：
當TCP超時並重傳時，它並不一定要重傳同樣的報文段，相反，TCP允許進行重新分組而發送一個較大的報文段。這是允許的，因為TCP是使用位元組序號而不是報文段序號來進行識別它所要發送的數據和進行確認。
四、TCP的堅持定時器
ACK的傳輸並不可靠，也就是說，TCP不對ACK報文段進行確認，TCP只確認那些包含數據的ACK報文段。為了防止因為ACK報文段丟失而雙方進行等待的問題，發送方用一個堅持定時器來周期性地向接收方查詢。這些從發送方發出地報文段稱為窗口探查。
五、TCP的保活定時器
如果一個給定的連接在2小時內沒有任何動作，那麼伺服器就向客戶發送一個探查報文段。客戶主機必須處於以下4個狀態之一。
(1) 客戶主機依然正常運行，並從伺服器可達。客戶的TCP響應正常，而伺服器也知道對方的正常工作的。伺服器在2小時內將保活定時器復位。
(2) 客戶主機已經崩潰，並且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。伺服器將不能收到對探查的響應，並在75秒後超時。總共發送10個探查，間隔75秒。
(3) 客戶主機崩潰並已經重新啟動。這是伺服器將收到一個對其保活探查的響應，但這個響應是一個復位，使得伺服器終止這個連接。
(4) 客戶主機正常運行，但是從伺服器不可達。
六、TCP的一些性能
1、 路徑MTU發現：
TCP的路徑MTU發現按如下方式進行：在連接建立時，TCP使用輸出介面或對段聲明的MSS中的最下MTU作為其實的報文段大小。路徑MTU發現不允許TCP超過對端聲明的MSS。如果對端沒有指定一個MSS，則默認為536。
一旦選定了起始的報文段大小，在該連接上的所有被TCP發送的IP數據報都將被設置DF位。如果中間路由器需要對一個設置了DF標志的數據報進行分片，它就丟棄這個數據報，並產生一個ICMP的「不能分片」差錯。
如果收到這個ICMP差錯，TCP就減少段大小並進行重傳。如果路由器產生的是一個較新的該類ICMP差錯，則報文段大小被設置位下一跳的MTU減去 IP和TCP的首部長度。如果是一個較舊的該類ICMP差錯，則必須嘗試下一個可能的最小MTU。
2、 長肥管道
一個連接的容量＝帶寬X時延（RTT）。具有大的帶寬時延乘積的網路稱為長肥網路（LFN）。一個運行在LFN的TCP連接稱為長肥管道。管道可以被水平拉長（一個長的RTT）,或被垂直拉高（較高的帶寬），或兩個方向拉伸。
3、窗口擴大選項：
窗口擴大選項使TCP的窗口定義從16位增加到32位，這並不是通過修改TCP首部來實現的，TCP首部仍然使用16位，而是通過定義一個選項實現對16位的擴大操作來完成的。
4、時間戳選項：
時間戳選項使發送方在每個報文段中放置一個時間戳值。接收方在確認中返回這個數值，從而允許發送方為每一個收到的ACK計算RTT。
⑹ tcp/ip採用什麼方法進行擁塞控制
TCP window機制
⑺ TCP協議採取了哪些機制來進行擁塞控制
最初的TCP協議只有基於窗口的流控制（flow control）機制而沒有擁塞控制機制，流控制是一種局部控制機制，其參與者僅僅是發送方和接收方，它只考慮了接收端的接收能力，而沒有考慮到網路的傳輸能力；而擁塞控制則注重於整體，其考慮的是整個網路的傳輸能力，是一種全局控制機制。 擁塞控制機制使得TCP連接在網路發生擁塞時回退（back off），也就是說TCP源端會對網路發出的擁塞指示（congestion notification）（例如丟包、重復的ACK等）作出響應。 針對TCP在控制網路擁塞方面的不足，後來又提出了「慢啟動」（Slow Start）和「擁塞避免」（Congestion Avoidance）演算法。 TCP Reno版本增加了「快速重傳 」（Fast Retransmit）、「快速恢復」（Fast Recovery）演算法，避免了網路擁塞不嚴重時採用「慢啟動」演算法而造成過大地減小發送窗口尺寸的現象，這樣TCP的擁塞控制就由這4個核心部分組成。 近幾年又出現TCP的改進版本如NewReno和選擇性應答（selective acknowledgement，SACK）等。
⑻ 如何在運行的內核中選擇tcp擁塞控制演算法
先查看本機支持的擁賽控制演算法，命令：
cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
如果支持，再以root帳號運行命令：
echo "vegas" >/proc/sys/net/ipv4/tcp_congestion_control
⑼ TCP擁塞窗口的問題
TCP擁塞控制最開始採用慢開始演算法，擁塞窗口值cwnd從1開始按指數增加，1、2、4、8（第1——4次的值）；這時達到了ssthresh的初始值8，轉而採用擁塞避免演算法，擁塞窗口值cwnd從ssthresh初始值8按線性+1增加，因此為9、10、11、12（第4——8次的值）；到了cwnd=12時網路發生超時，這時改ssthreash的值為發生超時時cwnd的值的一半（即為12/2=6），並重新採用慢開始演算法，改cwnd的值為1（這是第9次的值），然後cnwd的值依然按指數增加，2、4（第10、11次），理論上按這個演算法再增加就是cnwd=8了，超過了ssthresh=6，所以第12次開始改為擁塞避免演算法、cwnd的值從6開始按線性+1，即為6、7、8、9（第12——15次）。
純手打，希望能幫助你理解。
⑽ 安卓cpu優化tcp擁塞演算法cubic和reno怎麼選擇
上述具體的論文可以參考：CUBIC: A New TCP-Friendly High-Speed TCP Variant
1. tcp cubic數學模型
CUBIC在設計上簡化了BIC-TCP的窗口調整演算法，在BIC-TCP的窗口調整中會出現一個凹和凸(這里的凹和凸指的是數學意義上的凹和凸，凹函數/凸函數)的增長曲線，CUBIC使用了一個三次函數(即一個立方函數)，在三次函數曲線中同樣存在一個凹和凸的部分，該曲線形狀和BIC-TCP的曲線圖十分相似，於是該部分取代BIC-TCP的增長曲線。另外，CUBIC中最關鍵的點在於它的窗口增長函數僅僅取決於連續的兩次擁塞事件的時間間隔值，從而窗口增長完全獨立於網路的時延RTT，之前講述過的HSTCP存在嚴重的RTT不公平性，而CUBIC的RTT獨立性質使得CUBIC能夠在多條共享瓶頸鏈路的TCP連接之間保持良好的RRTT公平性。
來看下具體細節：當某次擁塞事件發生時，Wmax設置為此時發生擁塞時的窗口值，然後把窗口進行乘法減小，乘法減小因子設為β，當從快速恢復階段退出然後進入到擁塞避免階段，此時CUBIC的窗口增長開始按照「凹」式增長曲線進行增長，該過程一直持續直到窗口再次增長到Wmax，緊接著，該函數轉入「凸」式增長階段。該方式的增長可以使得窗口一直維持在Wmax附近，從而可以達到網路帶寬的高利用率和協議本身的穩定性。
窗口的增長函數如下：
W(t)=C*(t-K)3+Wmax,其中C和β為常量。
t為當前時間距上一次窗口減小的時間差，而K就代表該函數從W增長到Wmax的時間周期，。
當收到ACK後，CUBIC計算利用該演算法計算下一個RTT內的窗口增長速度，即計算W(t+RTT)，該值將作為cwnd的目標值，根據cwnd的大小，CUBIC將進入三種不同模式，如果cwnd會小於在標准TCP下經過上次擁塞之後的時刻t窗口將會達到的值(該值是通過標准TCP的窗口增長函數計算出來的)，那麼CUBIC就處於標准TCP模式，如果小於Wmax，那麼位於凹階段的，如果大於Wmax，那麼處於凸階段。
tcp cubic 內核源代碼調用邏輯
CUBIC整體架構調用的邏輯如下：
1. 連接每收到一個ack，則調用tcp_ack
2. tcp_ack會調用bictcp_acked，用來更新cnt和delayed_ack（用來消除delay包的影響）
3. tcp_ack會調用bictcp_cong_avoid，這是分兩種情況：
（1）snd_cwnd小於慢啟動閾值，處於慢啟動階段，則調用tcp_slow_start
（2）snd_cwnd大於慢啟動閾值，處於擁塞避免階段，則調用bictcp_update來更新bictcp，再調用tcp_cong_avoid_ai
4. tcp_ack中如果檢測到丟包，進入擁塞處理階段，則調用bictcp_recalc_ssthresh來更新慢啟動閾值
5. tcp_ack中完成丟包重傳後，退出擁塞處理階段，則調用bictcp_undo_cwnd來更新
快速重傳：tcp_ack中的丟包檢測，即檢測到連續3個重復ACK。
快速恢復：bictcp_undo_cwnd，直接把snd_cwnd更新為max(snd_cwnd，last_max_cwnd)，和掉包前相差不大。