TCP兩個(gè)重要窗口
滑動(dòng)窗口
滑動(dòng)窗口是 接受數(shù)據(jù) 端使用的窗口大小，用來告知發(fā)送端接收端的緩存大小，以此可以控制發(fā)送端發(fā)送數(shù)據(jù)的大小，從而達(dá)到流量控制的目的，對(duì)應(yīng)==>rwnd:接收端窗口（receiver window）
對(duì)于流量控制，是一個(gè)端對(duì)端的概念。由接收端返回的rwnd控制。
擁塞窗口
那么對(duì)于數(shù)據(jù)的 發(fā)送數(shù)據(jù) 端就是擁塞窗口，擁塞窗口不代表緩存，擁塞窗口指某一源端數(shù)據(jù)流在一個(gè)RTT內(nèi)可以最多發(fā)送的 數(shù)據(jù)包 數(shù),cwnd:發(fā)送端窗口( congestion window )。
發(fā)送端數(shù)據(jù)結(jié)構(gòu)
為了保證順序性，每?個(gè)包都有?個(gè)ID。在建?連接的時(shí)候，會(huì)商定起始的ID是什么，然后 按照ID?個(gè)個(gè)發(fā)送。為了保證不丟包，對(duì)于發(fā)送的包都要進(jìn)?應(yīng)答，但是這個(gè)應(yīng)答也不是?個(gè)?個(gè)來的，?是會(huì)應(yīng)答某個(gè)之前 的ID，表示都收到了，這種模式稱為累計(jì)確認(rèn)或者累計(jì)應(yīng)答（cumulative acknowledgment）。 為了記錄所有發(fā)送的包和接收的包，TCP也需要發(fā)送端和接收端分別都有緩存來保存這些記錄。發(fā)送端的緩存?是按照包的ID ?個(gè)個(gè)排列，根據(jù)處理的情況分成四個(gè)部分。 第?部分：發(fā)送了并且已經(jīng)確認(rèn)的。這部分就是你交代下屬的，并且也做完了的，應(yīng)該劃掉的。 第?部分：發(fā)送了并且尚未確認(rèn)的。這部分是你交代下屬的，但是還沒做完的，需要等待做完的回復(fù)之后，才能劃掉。 第三部分：沒有發(fā)送，但是已經(jīng)等待發(fā)送的。這部分是你還沒有交代給下屬，但是?上就要交代的。 第四部分：沒有發(fā)送，并且暫時(shí)還不會(huì)發(fā)送的。這部分是你還沒有交代給下屬，?且暫時(shí)還不會(huì)交代給下屬的。 在TCP?，接收端會(huì)給發(fā)送端報(bào)?個(gè)窗?的??，叫Advertised window。這個(gè)窗 ?的??應(yīng)該等于上?的第?部分加上第三部分，就是已經(jīng)交代了沒做完的加上?上要交代的。超過這個(gè)窗?的，接收端做不 過來，就不能發(fā)送了。 于是，發(fā)送端需要保持下?的數(shù)據(jù)結(jié)構(gòu)。
LastByteAcked：第?部分和第?部分的分界線 LastByteSent：第?部分和第三部分的分界線 LastByteAcked + AdvertisedWindow：第三部分和第四部分的分界線 對(duì)于接收端來講，它的緩存?記錄的內(nèi)容要簡(jiǎn)單?些。
擁塞控制和流量控制的區(qū)別
擁塞控制：擁塞控制是作用于網(wǎng)絡(luò)的，它是防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，避免出現(xiàn)網(wǎng)絡(luò)負(fù)載過大的情況；常用的方法就是：
- 慢開始、擁塞避免
- 快重傳、快恢復(fù)
流量控制：流量控制是作用于接收者的，它是控制發(fā)送者的發(fā)送速度從而使接收者來得及接收，防止分組丟失的。
接收端數(shù)據(jù)結(jié)構(gòu)
第?部分：接受并且確認(rèn)過的。也就是我領(lǐng)導(dǎo)交代給我，并且我做完的。 第?部分：還沒接收，但是?上就能接收的。也即是我??的能夠接受的最??作量。 第三部分：還沒接收，也沒法接收的。也即超過?作量的部分，實(shí)在做不完。 對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)就像這樣。
MaxRcvBuffer：最?緩存的量； LastByteRead之后是已經(jīng)接收了，但是還沒被應(yīng)?層讀取的； NextByteExpected是第?部分和第?部分的分界線。 第?部分的窗?有多?呢？ NextByteExpected和LastByteRead的差其實(shí)是還沒被應(yīng)?層讀取的部分占?掉的MaxRcvBuffer的量，我們定義為A。 AdvertisedWindow其實(shí)是MaxRcvBuffer減去A。 也就是：AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)。 那第?部分和第三部分的分界線在哪?呢？NextByteExpected加AdvertisedWindow就是第?部分和第三部分的分界線，其實(shí) 也就是LastByteRead加上MaxRcvBuffer。 其中第?部分??，由于受到的包可能不是順序的，會(huì)出現(xiàn)空擋，只有和第?部分連續(xù)的，可以?上進(jìn)?回復(fù)，中間空著的部 分需要等待，哪怕后?的已經(jīng)來了。
流量控制
如何控制
接收方每次收到數(shù)據(jù)包，可以在發(fā)送確定報(bào)文的時(shí)候，同時(shí)告訴發(fā)送方自己的緩存區(qū)還剩余多少是空閑的，我們也把緩存區(qū)的剩余大小稱之為接收窗口大小，用變量win來表示接收窗口的大小。
發(fā)送方收到之后，便會(huì)調(diào)整自己的發(fā)送速率，也就是調(diào)整自己發(fā)送窗口的大小，當(dāng)發(fā)送方收到接收窗口的大小為0時(shí)，發(fā)送方就會(huì)停止發(fā)送數(shù)據(jù)，防止出現(xiàn)大量丟包情況的發(fā)生。
發(fā)送方何時(shí)再繼續(xù)發(fā)送數(shù)據(jù)
當(dāng)發(fā)送方停止發(fā)送數(shù)據(jù)后，該怎樣才能知道自己可以繼續(xù)發(fā)送數(shù)據(jù)？
我們可以采用這樣的策略：當(dāng)接收方處理好數(shù)據(jù)，接受窗口 win > 0 時(shí)，接收方發(fā)個(gè)通知報(bào)文去通知發(fā)送方，告訴他可以繼續(xù)發(fā)送數(shù)據(jù)了。當(dāng)發(fā)送方收到窗口大于0的報(bào)文時(shí)，就繼續(xù)發(fā)送數(shù)據(jù)。
不過這時(shí)候可能會(huì)遇到一個(gè)問題，假如接收方發(fā)送的通知報(bào)文，由于某種網(wǎng)絡(luò)原因，這個(gè)報(bào)文丟失了，這時(shí)候就會(huì)引發(fā)一個(gè)問題：接收方發(fā)了通知報(bào)文后，繼續(xù)等待發(fā)送方發(fā)送數(shù)據(jù)，而發(fā)送方則在等待接收方的通知報(bào)文，此時(shí)雙方會(huì)陷入一種僵局。
為了解決這種問題，我們采用了另外一種策略：當(dāng)發(fā)送方收到接受窗口 win = 0 時(shí)，這時(shí)發(fā)送方停止發(fā)送報(bào)文，并且同時(shí)開啟一個(gè)定時(shí)器，每隔一段時(shí)間就發(fā)個(gè)測(cè)試報(bào)文去詢問接收方，打聽是否可以繼續(xù)發(fā)送數(shù)據(jù)了，如果可以，接收方就告訴他此時(shí)接受窗口的大小；如果接受窗口大小還是為0，則發(fā)送方再次刷新啟動(dòng)定時(shí)器。
擁塞控制的算法
我們?cè)陂_始假定：
- 數(shù)據(jù)是單方向傳遞，另一個(gè)窗口只發(fā)送確認(rèn)；
- 接收方的緩存足夠大，因此發(fā)送方的大小的大小由網(wǎng)絡(luò)的擁塞程度來決定。
慢開始算法：
cwnd的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口，另外考慮到接受方的接收能力，發(fā)送窗口可能小于擁塞窗口。
慢開始算法的思路就是，不要一開始就發(fā)送大量的數(shù)據(jù)，先探測(cè)一下網(wǎng)絡(luò)的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。
這里用報(bào)文段的個(gè)數(shù)作為擁塞窗口的大小舉例說明慢開始算法，實(shí)際的擁塞窗口大小是以字節(jié)為單位的。
一個(gè)傳輸輪次所經(jīng)歷的時(shí)間其實(shí)就是往返時(shí)間RTT，而且沒經(jīng)過一個(gè)傳輸輪次（transmission round），擁塞窗口cwnd就加倍。
為了防止cwnd增長(zhǎng)過大引起網(wǎng)絡(luò)擁塞，還需設(shè)置一個(gè)慢開始門限ssthresh狀態(tài)變量。ssthresh的用法如下：當(dāng)cwnd<ssthresh時(shí)，使用慢開始算法。 當(dāng)cwnd>ssthresh時(shí)，改用擁塞避免算法。 當(dāng)cwnd=ssthresh時(shí)，慢開始與擁塞避免算法任意
注意，這里的“慢”并不是指cwnd的增長(zhǎng)速率慢，而是指在TCP開始發(fā)送報(bào)文段時(shí)先設(shè)置cwnd=1，然后逐漸增大，這當(dāng)然比按照大的cwnd一下子把許多報(bào)文段突然注入到網(wǎng)絡(luò)中要“慢得多”。
擁塞避免算法
擁塞避免算法讓擁塞窗口緩慢增長(zhǎng)，即每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口按線性規(guī)律緩慢增長(zhǎng)。
無論是在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有按時(shí)收到確認(rèn)，雖然沒有收到確認(rèn)可能是其他原因的分組丟失，但是因?yàn)闊o法判定，所以都當(dāng)做擁塞來處理），就把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送窗口大小的一半（但不能小于2）。然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。
- 擁塞窗口cwnd初始化為1個(gè)報(bào)文段，慢開始門限初始值為16
- 執(zhí)行慢開始算法，指數(shù)規(guī)律增長(zhǎng)到第4輪，即cwnd=16=ssthresh，改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長(zhǎng)
- 假定cwnd=24時(shí)，網(wǎng)絡(luò)出現(xiàn)超時(shí)（擁塞），則更新后的ssthresh=12，cwnd重新設(shè)置為1，并執(zhí)行慢開始算法。當(dāng)cwnd=12=ssthresh時(shí)，改為執(zhí)行擁塞避免算法
乘法減小（Multiplicative Decrease）和加法增大（Additive Increase)
“乘法減小”指的是無論是在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞，就把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送窗口大小的一半，并執(zhí)行慢開始算法，所以當(dāng)網(wǎng)絡(luò)頻繁出現(xiàn)擁塞時(shí)，ssthresh下降的很快，以大大減少注入到網(wǎng)絡(luò)中的分組數(shù)。“加法增大”是指執(zhí)行擁塞避免算法后，使擁塞窗口緩慢增大，以防止過早出現(xiàn)擁塞。常合起來成為AIMD算法。
注意：“擁塞避免”并非完全能夠避免了阻塞，而是使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞。
TCP兩個(gè)重要窗口
滑動(dòng)窗口
滑動(dòng)窗口是接受數(shù)據(jù)端使用的窗口大小，用來告知發(fā)送端接收端的緩存大小，以此可以控制發(fā)送端發(fā)送數(shù)據(jù)的大小，從而達(dá)到流量控制的目的，對(duì)應(yīng)==>rwnd:接收端窗口（receiver window）
對(duì)于流量控制，是一個(gè)端對(duì)端的概念。由接收端返回的rwnd控制。
擁塞窗口
那么對(duì)于數(shù)據(jù)的發(fā)送數(shù)據(jù)端就是擁塞窗口，擁塞窗口不代表緩存，擁塞窗口指某一源端數(shù)據(jù)流在一個(gè)RTT內(nèi)可以最多發(fā)送的 數(shù)據(jù)包 數(shù),cwnd:發(fā)送端窗口( congestion window )。
發(fā)送端數(shù)據(jù)結(jié)構(gòu)
為了保證順序性，每?個(gè)包都有?個(gè)ID。在建?連接的時(shí)候，會(huì)商定起始的ID是什么，然后 按照ID?個(gè)個(gè)發(fā)送。為了保證不丟包，對(duì)于發(fā)送的包都要進(jìn)?應(yīng)答，但是這個(gè)應(yīng)答也不是?個(gè)?個(gè)來的，?是會(huì)應(yīng)答某個(gè)之前 的ID，表示都收到了，這種模式稱為累計(jì)確認(rèn)或者累計(jì)應(yīng)答（cumulative acknowledgment）。 為了記錄所有發(fā)送的包和接收的包，TCP也需要發(fā)送端和接收端分別都有緩存來保存這些記錄。發(fā)送端的緩存?是按照包的ID ?個(gè)個(gè)排列，根據(jù)處理的情況分成四個(gè)部分。第?部分：發(fā)送了并且已經(jīng)確認(rèn)的。這部分就是你交代下屬的，并且也做完了的，應(yīng)該劃掉的。第?部分：發(fā)送了并且尚未確認(rèn)的。這部分是你交代下屬的，但是還沒做完的，需要等待做完的回復(fù)之后，才能劃掉。第三部分：沒有發(fā)送，但是已經(jīng)等待發(fā)送的。這部分是你還沒有交代給下屬，但是?上就要交代的。第四部分：沒有發(fā)送，并且暫時(shí)還不會(huì)發(fā)送的。這部分是你還沒有交代給下屬，?且暫時(shí)還不會(huì)交代給下屬的。在TCP?，接收端會(huì)給發(fā)送端報(bào)?個(gè)窗?的??，叫Advertised window。這個(gè)窗 ?的??應(yīng)該等于上?的第?部分加上第三部分，就是已經(jīng)交代了沒做完的加上?上要交代的。超過這個(gè)窗?的，接收端做不 過來，就不能發(fā)送了。于是，發(fā)送端需要保持下?的數(shù)據(jù)結(jié)構(gòu)。
LastByteAcked：第?部分和第?部分的分界線 LastByteSent：第?部分和第三部分的分界線 LastByteAcked + AdvertisedWindow：第三部分和第四部分的分界線 對(duì)于接收端來講，它的緩存?記錄的內(nèi)容要簡(jiǎn)單?些。
擁塞控制和流量控制的區(qū)別
擁塞控制：擁塞控制是作用于網(wǎng)絡(luò)的，它是防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，避免出現(xiàn)網(wǎng)絡(luò)負(fù)載過大的情況；常用的方法就是：
- 慢開始、擁塞避免
- 快重傳、快恢復(fù)
流量控制：流量控制是作用于接收者的，它是控制發(fā)送者的發(fā)送速度從而使接收者來得及接收，防止分組丟失的。
接收端數(shù)據(jù)結(jié)構(gòu)
第?部分：接受并且確認(rèn)過的。也就是我領(lǐng)導(dǎo)交代給我，并且我做完的。第?部分：還沒接收，但是?上就能接收的。也即是我??的能夠接受的最??作量。第三部分：還沒接收，也沒法接收的。也即超過?作量的部分，實(shí)在做不完。對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)就像這樣。
MaxRcvBuffer：最?緩存的量； LastByteRead之后是已經(jīng)接收了，但是還沒被應(yīng)?層讀取的； NextByteExpected是第?部分和第?部分的分界線。 第?部分的窗?有多?呢？NextByteExpected和LastByteRead的差其實(shí)是還沒被應(yīng)?層讀取的部分占?掉的MaxRcvBuffer的量，我們定義為A。 AdvertisedWindow其實(shí)是MaxRcvBuffer減去A。 也就是：AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)。 那第?部分和第三部分的分界線在哪?呢？NextByteExpected加AdvertisedWindow就是第?部分和第三部分的分界線，其實(shí) 也就是LastByteRead加上MaxRcvBuffer。 其中第?部分??，由于受到的包可能不是順序的，會(huì)出現(xiàn)空擋，只有和第?部分連續(xù)的，可以?上進(jìn)?回復(fù)，中間空著的部 分需要等待，哪怕后?的已經(jīng)來了。
流量控制
如何控制
接收方每次收到數(shù)據(jù)包，可以在發(fā)送確定報(bào)文的時(shí)候，同時(shí)告訴發(fā)送方自己的緩存區(qū)還剩余多少是空閑的，我們也把緩存區(qū)的剩余大小稱之為接收窗口大小，用變量win來表示接收窗口的大小。
發(fā)送方收到之后，便會(huì)調(diào)整自己的發(fā)送速率，也就是調(diào)整自己發(fā)送窗口的大小，當(dāng)發(fā)送方收到接收窗口的大小為0時(shí)，發(fā)送方就會(huì)停止發(fā)送數(shù)據(jù)，防止出現(xiàn)大量丟包情況的發(fā)生。
640830×573
發(fā)送方何時(shí)再繼續(xù)發(fā)送數(shù)據(jù)
當(dāng)發(fā)送方停止發(fā)送數(shù)據(jù)后，該怎樣才能知道自己可以繼續(xù)發(fā)送數(shù)據(jù)？
我們可以采用這樣的策略：當(dāng)接收方處理好數(shù)據(jù)，接受窗口 win > 0 時(shí)，接收方發(fā)個(gè)通知報(bào)文去通知發(fā)送方，告訴他可以繼續(xù)發(fā)送數(shù)據(jù)了。當(dāng)發(fā)送方收到窗口大于0的報(bào)文時(shí)，就繼續(xù)發(fā)送數(shù)據(jù)。
不過這時(shí)候可能會(huì)遇到一個(gè)問題，假如接收方發(fā)送的通知報(bào)文，由于某種網(wǎng)絡(luò)原因，這個(gè)報(bào)文丟失了，這時(shí)候就會(huì)引發(fā)一個(gè)問題：接收方發(fā)了通知報(bào)文后，繼續(xù)等待發(fā)送方發(fā)送數(shù)據(jù)，而發(fā)送方則在等待接收方的通知報(bào)文，此時(shí)雙方會(huì)陷入一種僵局。
為了解決這種問題，我們采用了另外一種策略：當(dāng)發(fā)送方收到接受窗口 win = 0 時(shí)，這時(shí)發(fā)送方停止發(fā)送報(bào)文，并且同時(shí)開啟一個(gè)定時(shí)器，每隔一段時(shí)間就發(fā)個(gè)測(cè)試報(bào)文去詢問接收方，打聽是否可以繼續(xù)發(fā)送數(shù)據(jù)了，如果可以，接收方就告訴他此時(shí)接受窗口的大小；如果接受窗口大小還是為0，則發(fā)送方再次刷新啟動(dòng)定時(shí)器。
640867×696
擁塞控制的算法
我們?cè)陂_始假定：
- 數(shù)據(jù)是單方向傳遞，另一個(gè)窗口只發(fā)送確認(rèn)；
- 接收方的緩存足夠大，因此發(fā)送方的大小的大小由網(wǎng)絡(luò)的擁塞程度來決定。
慢開始算法：
cwnd的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口，另外考慮到接受方的接收能力，發(fā)送窗口可能小于擁塞窗口。
慢開始算法的思路就是，不要一開始就發(fā)送大量的數(shù)據(jù)，先探測(cè)一下網(wǎng)絡(luò)的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。
這里用報(bào)文段的個(gè)數(shù)作為擁塞窗口的大小舉例說明慢開始算法，實(shí)際的擁塞窗口大小是以字節(jié)為單位的。
一個(gè)傳輸輪次所經(jīng)歷的時(shí)間其實(shí)就是往返時(shí)間RTT，而且沒經(jīng)過一個(gè)傳輸輪次（transmission round），擁塞窗口cwnd就加倍。
為了防止cwnd增長(zhǎng)過大引起網(wǎng)絡(luò)擁塞，還需設(shè)置一個(gè)慢開始門限ssthresh狀態(tài)變量。ssthresh的用法如下：當(dāng)cwnd<ssthresh時(shí)，使用慢開始算法。當(dāng)cwnd>ssthresh時(shí)，改用擁塞避免算法。當(dāng)cwnd=ssthresh時(shí)，慢開始與擁塞避免算法任意
注意，這里的“慢”并不是指cwnd的增長(zhǎng)速率慢，而是指在TCP開始發(fā)送報(bào)文段時(shí)先設(shè)置cwnd=1，然后逐漸增大，這當(dāng)然比按照大的cwnd一下子把許多報(bào)文段突然注入到網(wǎng)絡(luò)中要“慢得多”。
擁塞避免算法
擁塞避免算法讓擁塞窗口緩慢增長(zhǎng)，即每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口按線性規(guī)律緩慢增長(zhǎng)。
無論是在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有按時(shí)收到確認(rèn)，雖然沒有收到確認(rèn)可能是其他原因的分組丟失，但是因?yàn)闊o法判定，所以都當(dāng)做擁塞來處理），就把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送窗口大小的一半（但不能小于2）。然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。
- 擁塞窗口cwnd初始化為1個(gè)報(bào)文段，慢開始門限初始值為16
- 執(zhí)行慢開始算法，指數(shù)規(guī)律增長(zhǎng)到第4輪，即cwnd=16=ssthresh，改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長(zhǎng)
- 假定cwnd=24時(shí)，網(wǎng)絡(luò)出現(xiàn)超時(shí)（擁塞），則更新后的ssthresh=12，cwnd重新設(shè)置為1，并執(zhí)行慢開始算法。當(dāng)cwnd=12=ssthresh時(shí)，改為執(zhí)行擁塞避免算法
乘法減小（Multiplicative Decrease）和加法增大（Additive Increase)
“乘法減小”指的是無論是在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞，就把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送窗口大小的一半，并執(zhí)行慢開始算法，所以當(dāng)網(wǎng)絡(luò)頻繁出現(xiàn)擁塞時(shí)，ssthresh下降的很快，以大大減少注入到網(wǎng)絡(luò)中的分組數(shù)。“加法增大”是指執(zhí)行擁塞避免算法后，使擁塞窗口緩慢增大，以防止過早出現(xiàn)擁塞。常合起來成為AIMD算法。
注意：“擁塞避免”并非完全能夠避免了阻塞，而是使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞。
長(zhǎng)肥管道
一個(gè)連接的時(shí)延帶寬積可表示為：capacity(b)=bandwidth(b/s)×round-triptime(s)。也可稱它為兩端的管道大小。具有大的帶寬時(shí)延乘積的網(wǎng)絡(luò)被稱為長(zhǎng)肥網(wǎng)絡(luò)（LongFatNetwork，即LFN），而一個(gè)運(yùn)行在LFN上的TCP連接被稱為長(zhǎng)肥管道。使用長(zhǎng)肥管道會(huì)遇到多種問題。
- TCP首部中窗口大小為16bit，因此窗口大小最大為65535字節(jié)，這就將發(fā)送方發(fā)送但未被確認(rèn)的數(shù)據(jù)的總長(zhǎng)度限制到了65536字節(jié)。對(duì)于LFN管道，這可能會(huì)出現(xiàn)所有的數(shù)據(jù)都還未到達(dá)接收方，但是發(fā)送方已受限于窗口大小而不能繼續(xù)發(fā)送的情形，這就極大的降低了網(wǎng)絡(luò)的吞吐量。擴(kuò)大窗口選項(xiàng)可以解決這個(gè)問題。
- 根據(jù)TCP的擁塞控制，丟失分組會(huì)導(dǎo)致連接進(jìn)行擁塞控制，即便是由于冗余ACK而進(jìn)入了快速恢復(fù)，也會(huì)使得擁塞窗口降低一半，而如果是由于超時(shí)進(jìn)入了慢啟動(dòng)，則擁塞窗口會(huì)變?yōu)?，無論是哪一種情形，發(fā)送方允許被發(fā)送的數(shù)據(jù)量都大量減小了，這會(huì)導(dǎo)致網(wǎng)絡(luò)吞吐量降低。選擇確認(rèn)（SACK）可以用來部分避免該問題，采用該技術(shù)使得接收方可以有選擇的對(duì)無序到達(dá)的報(bào)文段進(jìn)行確認(rèn)而不是采用累積確認(rèn)，這樣被確認(rèn)的報(bào)文段就不會(huì)超時(shí)，也不會(huì)有冗余的ACK。
- TCP并不對(duì)每個(gè)報(bào)文段進(jìn)行RTT測(cè)量。在一個(gè)長(zhǎng)肥網(wǎng)絡(luò)LFN上需要更好的RTT測(cè)量機(jī)制。
- TCP對(duì)每個(gè)字節(jié)數(shù)據(jù)使用一個(gè)32bit無符號(hào)的序號(hào)來進(jìn)行標(biāo)識(shí)。TCP定義了最大的報(bào)文段生存時(shí)間（MSL）來限制報(bào)文段在網(wǎng)絡(luò)中的生存時(shí)間。但是在LFN網(wǎng)絡(luò)上，由于序號(hào)空間是有限的，在已經(jīng)傳輸了4294967296個(gè)字節(jié)以后序號(hào)會(huì)被重用。如果網(wǎng)絡(luò)快到在不到一個(gè)MSL的時(shí)候序號(hào)就發(fā)生了回繞，網(wǎng)絡(luò)中就會(huì)有兩個(gè)具有相同序號(hào)的不同的報(bào)文段，接收方將無法區(qū)分它們的順序。在一個(gè)千兆比特網(wǎng)絡(luò)（1000Mb/s）中只需要34秒就可以完成4294967296個(gè)字節(jié)的發(fā)送。使用TCP的時(shí)間戳選項(xiàng)的PAWS(ProtectionAgainstWrappedSequencenumbers)算法（保護(hù)回繞的序號(hào)）可以解決該問題。
快重傳算法：
快重傳要求接收方在收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)（為的是使發(fā)送方及早知道有報(bào)文段沒有到達(dá)對(duì)方，可提高網(wǎng)絡(luò)吞吐量約20%）而不要等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)。快重傳算法規(guī)定，發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期。如下圖：
SACK 方法
另外一種更好的方式叫：Selective Acknowledgment (SACK)(參看RFC 2018)，這種方式需要在TCP頭里加一個(gè)SACK的東西，ACK還是Fast Retransmit的ACK，SACK則是匯報(bào)收到的數(shù)據(jù)碎版。參看下圖：
這樣，在發(fā)送端就可以根據(jù)回傳的SACK來知道哪些數(shù)據(jù)到了，哪些沒有到。于是就優(yōu)化了Fast Retransmit的算法。當(dāng)然，這個(gè)協(xié)議需要兩邊都支持。在 linux下，可以通過tcp_sack參數(shù)打開這個(gè)功能(Linux 2.4后默認(rèn)打開)。
這里還需要注意一個(gè)問題——接收方Reneging，所謂Reneging的意思就是接收方有權(quán)把已經(jīng)報(bào)給發(fā)送端SACK里的數(shù)據(jù)給丟了。這樣干是不被鼓勵(lì)的，因?yàn)檫@個(gè)事會(huì)把問題復(fù)雜化了，但是，接收方這么做可能會(huì)有些極端情況，比如要把內(nèi)存給別的更重要的東西。所以，發(fā)送方也不能完全依賴SACK，還是要依賴ACK，并維護(hù)Time-Out，如果后續(xù)的ACK沒有增長(zhǎng)，那么還是要把SACK的東西重傳，另外，接收端這邊永遠(yuǎn)不能把SACK的包標(biāo)記為Ack。
注意：SACK會(huì)消費(fèi)發(fā)送方的資源，試想，如果一個(gè)攻擊者給數(shù)據(jù)發(fā)送方發(fā)一堆SACK的選項(xiàng)，這會(huì)導(dǎo)致發(fā)送方開始要重傳甚至遍歷已經(jīng)發(fā)出的數(shù)據(jù)，這會(huì)消耗很多發(fā)送端的資源。詳細(xì)的東西請(qǐng)參看《TCP SACK的性能權(quán)衡》。
TCP四大定時(shí)器
重傳定時(shí)器
重傳定時(shí)器是用來計(jì)算TCP報(bào)文段的超時(shí)重傳時(shí)間的（至于超時(shí)重傳時(shí)間的確定，這里涉及到一大堆的算法，我這里不細(xì)談了）。每發(fā)送一個(gè)報(bào)文段就會(huì)啟動(dòng)重傳定時(shí)器，如果在定時(shí)器時(shí)間到后還沒收到對(duì)該報(bào)文段的確認(rèn)，就重傳該報(bào)文段，并將重傳定時(shí)器復(fù)位，重新計(jì)算；如果在規(guī)定時(shí)間內(nèi)收到了對(duì)該報(bào)文段的確認(rèn)，則撤銷該報(bào)文段的重傳定時(shí)器。
堅(jiān)持定時(shí)器
專門為對(duì)付零窗口通知而設(shè)立的。
主要是為了應(yīng)付零窗口大小通知可能導(dǎo)致的死鎖問題。如果接收端在向發(fā)送端發(fā)送了零窗口報(bào)文段后不久，接收端的接收緩存又有了一些存儲(chǔ)空間，于是接收端向發(fā)送端發(fā)送了一個(gè)非零窗口大小的報(bào)文段，然而這個(gè)報(bào)文段在傳送過程中丟失了，發(fā)送端沒有收到該報(bào)文段，就一直等待接收端發(fā)送非零窗口的報(bào)文通知，而接收端并不知道報(bào)文段丟失了，而是覺得已經(jīng)告訴發(fā)送端了，就會(huì)一直等待發(fā)送端發(fā)送數(shù)據(jù)，如果沒有任何措施的話，這話死鎖的局面會(huì)一直延續(xù)下去。
為了解決這個(gè)問題，TCP為每一個(gè)連接設(shè)有一個(gè)堅(jiān)持定時(shí)器(也叫持續(xù)計(jì)數(shù)器)。只要TCP連接的一方收到對(duì)方的零窗口通知，就啟動(dòng)堅(jiān)持定時(shí)器。若堅(jiān)持定時(shí)器設(shè)置的時(shí)間到期，就發(fā)送一個(gè)零窗口控測(cè)報(bào)文段（該報(bào)文段只有一個(gè)字節(jié)的數(shù)據(jù)，它有一個(gè)序號(hào)，但該序號(hào)永遠(yuǎn)不需要確認(rèn)，因此該序號(hào)可以持續(xù)重傳），之后會(huì)出現(xiàn)以下三種情況：
- 對(duì)方在收到探測(cè)報(bào)文段后，在對(duì)該報(bào)文段的確認(rèn)中給出現(xiàn)在的窗口值，如果窗口值仍未零，則收到這個(gè)報(bào)文段的一方將堅(jiān)持定時(shí)器的值加倍并重啟。堅(jiān)持計(jì)數(shù)器最大只能增加到約60秒，在此之后，每次收到零窗口通知，堅(jiān)持計(jì)數(shù)器的值就定位60秒。
- 對(duì)方在收到探測(cè)報(bào)文段后，在對(duì)該報(bào)文段的確認(rèn)中給出現(xiàn)在的窗口值，如果窗口不為零，那么死鎖的僵局就被打破了。
- 該探測(cè)報(bào)文發(fā)出后，會(huì)同時(shí)啟動(dòng)重傳定時(shí)器，如果重傳定時(shí)器的時(shí)間到期，還沒有收到接收到發(fā)來的響應(yīng)，則超時(shí)重傳探測(cè)報(bào)文。
保活定時(shí)器
保活定時(shí)器是為了應(yīng)對(duì)兩個(gè)TCP連接間出現(xiàn)長(zhǎng)時(shí)間的沒有數(shù)據(jù)傳輸?shù)那闆r。如果客戶已與服務(wù)器建立了TCP連接，但后來客戶端主機(jī)突然故障，則服務(wù)器就不能再收到客戶端發(fā)來的數(shù)據(jù)了，而服務(wù)器肯定不能這樣永久地等下去，保活定時(shí)器就是用來解決這個(gè)問題的。服務(wù)器每收到一次客戶端的數(shù)據(jù)，就重新設(shè)置保活定時(shí)器，通常為2小時(shí)，如果2小時(shí)沒有收到客戶端的數(shù)據(jù)，服務(wù)端就發(fā)送一個(gè)探測(cè)報(bào)文，以后每隔75秒發(fā)送一次，如果連續(xù)發(fā)送10次探測(cè)報(bào)文段后仍沒有收到客戶端的響應(yīng)，服務(wù)器就認(rèn)為客戶端出現(xiàn)了故障，就可以終止這個(gè)連接。
時(shí)間等待計(jì)時(shí)器（2MSL定時(shí)器 ）
2MSL定時(shí)器測(cè)量一個(gè)連接處于TIME—WAIT狀態(tài)的時(shí)間，通常為2MSL（報(bào)文段壽命的兩倍）。2MSL定時(shí)器的設(shè)置主要是為了確保發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)對(duì)方，并防止之前與本連接有關(guān)的由于延遲等原因而導(dǎo)致已失效的報(bào)文被誤判為有效。在連接終止期使用，當(dāng)TCP關(guān)閉連接時(shí)，并不認(rèn)為這個(gè)連接就真正關(guān)閉了，在時(shí)間等待期間，連接還處于一種中間過度狀態(tài)。這樣就可以使重復(fù)的fin報(bào)文段在到達(dá)終點(diǎn)后被丟棄。
TIME_WAIT 確保有足夠的時(shí)間讓對(duì)端收到了ACK，如果被動(dòng)關(guān)閉的那方?jīng)]有收到 ACK，就會(huì)觸發(fā)被動(dòng)端重發(fā) FIN。因?yàn)樽詈笠淮未_認(rèn)應(yīng)答 ACK 報(bào)文段很有可能丟失，因而使被動(dòng)關(guān)閉方處于在LIST_ACK 狀態(tài)的，此時(shí)被動(dòng)關(guān)閉方會(huì)重發(fā)這個(gè) FIN+ACK 報(bào)文段，在這等待的 2MSL 時(shí)間內(nèi)主動(dòng)關(guān)閉方重新收到這個(gè)被動(dòng)關(guān)閉方重發(fā)的 FIN+ACK 報(bào)文段，因此，主動(dòng)關(guān)閉方會(huì)重新發(fā)送確認(rèn)應(yīng)答信息，從而重新啟動(dòng) 2MSL 計(jì)時(shí)器，直到通信雙方都進(jìn)入 CLOSED 狀態(tài)。如果主動(dòng)關(guān)閉方在 TIME_WAIT 狀態(tài)不等待一段時(shí)間就直接釋放連接并進(jìn)入 CLOSED 狀態(tài)，那么主動(dòng)關(guān)閉方無法收到來自被動(dòng)關(guān)閉方重發(fā)的 FIN+ACK 報(bào)文段，也就不會(huì)再發(fā)送一次確認(rèn) ACK 報(bào)文段，因此被動(dòng)關(guān)閉方就無法正常進(jìn)入CLOSED 狀態(tài)。
該定時(shí)器使得有足夠的時(shí)間讓這個(gè)連接不會(huì)跟后面的連接混在一起。防止已失效的請(qǐng)求連接出現(xiàn)在本連接中。在連接處于 2MSL 等待時(shí)，任何遲到的報(bào)文段將被丟棄，因?yàn)樘幱?2MSL等待的、由該插口(插口是IP和端口對(duì)的意思，socket)定義的連接在這段時(shí)間內(nèi)將不能被再用，這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接之前延遲的報(bào)文段。
