tcp在傳送端和接收端有兩個視窗，傳送端的是擁塞視窗而接收端的就叫做接收視窗，兩個視窗的作用不同 ，所謂的流量控制就是收發端的速率要匹配，決定權在接收端而不在傳送端，因為傳送的慢了可以提速，而 接收不了就意味著丟包，這就好比冷了可以穿衣而熱了只有扒皮一樣。因此對於收發端，流量控制主要由接 收端控制，因此接收視窗就表示「我能接收多少」，按照這個數字傳送，在該連線獨佔網路並且頻寬無限的 情況下流量是平滑的。接收端的接收視窗將按照自己的能力向前滑動。 然而網路環境不是那麼理想的，第一任何連線不能獨佔頻寬，第二，頻寬也不是無限，因此即使接收 端建議傳送端傳送多少資料，傳送端也有確保公平的義務，因此傳送端也有乙個視窗，叫做擁塞視窗，指當 前的網路狀況只能傳送這麼多資料報，一般傳送端可以傳送的資料是接收視窗和擁塞視窗的最小值，由於 tcp是全雙工的協議，連線兩端都是接收者和傳送者，因此每端都有兩個視窗，其中的擁塞視窗和實際的發 送視窗自己維護，而接收視窗要在tcp協議頭中傳給對方，讓對方根據這個視窗和自己的擁塞視窗抉擇自己 的實際傳送視窗。
1.慢啟動並不慢
慢啟動是一種擁塞控制機制，只影響擁塞視窗，注意，實際的傳送視窗需要取擁塞視窗和對端傳來的接收窗 口的最小值，慢啟動的過程中，擁塞視窗不斷增加，因為tcp連線剛啟動，並不知道網路的實際情況，需要 用一種試探的方式慢慢平滑增加傳送視窗的大小，增加的過程是十分快的，是指數增長的，直到發生擁塞或 者達到事前配置好的乙個閥值，如是是擁塞發生了，那麼肯定要調整擁塞視窗了，事實上由於慢啟動實際很 快，如果僅僅有慢啟動，那麼網路很快就擁堵不堪了。
2.擁塞發現
每乙個資料報都有乙個定時器，如果定時器超時還沒有ack回來，那麼就說明該資料沒有到達目的地，十有 **是網路擁塞了，tcp的設計者必須假定網路交通事故率很低，此時tcp傳送端將採取措施，最重要的就是 重新開始慢啟動，並且將慢啟動閥值減小，當擁塞視窗到達該閥值的時候(由於閥值減小了，肯定比剛開始 的慢啟動過程先到這種狀態)，實行另一種擁塞控制方法--擁塞避免，就是擁塞避免，其實就是將慢啟動的 指數增加視窗大小改為線性增加，從而漸漸將擁塞視窗調整到乙個合適的大小。
3.快速重傳
還有一種情況會直接使用擁塞避免，那就是當傳送端收到三個重複的ack的時候，說明接收端收到了三個序 列號靠後資料報，但都不是接收視窗最前面的那個，因此說明那個資料十有**是丟了，因此可以**擁塞 發生了，因此將擁塞視窗減半，然後線性增加，這就是加增乘減原則。順便，tcp接收資料的順序只要在窗 口內並不一定非要按序，只要os的協議棧實現支援快取視窗內的斷序資料即可。
4.加增乘減原則
該原則體現了公平，因為擁塞視窗增加只會優惠到自己，而減小卻會優惠很多別的連線，每乙個連線都有維 護公平的義務，本著優惠均等的原則，自己的行為應該讓包括自己在內的所有連線得到均等的實惠，因此優 惠只有乙個自己的時候用加法，而優惠很多大家的時候用乘法。
5.快速恢復演算法
快速重傳雖然通過減半擁塞視窗的辦法可以減緩擁塞，但是自己過分的讓步可能會引起別人貪婪地掠奪，雖 然我讓步了，減半了擁塞視窗，但是我是靠接收了三個重複ack才得到這個訊息的，而不是乙個包的超時， 如果在第乙個重複ack時我就開始快速重傳，那麼此時我的擁塞視窗已經加了三個了，因此需要補償我無辜 的等待三個ack，因此快速恢復過程是對快速重傳的修正，將擁塞視窗減半後加上了3
6.擁塞視窗何時穩定
如果僅僅考慮擁塞控制，那麼貌似擁塞視窗會一直這麼指數增-乘減-加增-乘減-指數增-...迴圈下去，是的 ，確實是這樣，但是通過統計tcp連線的速率和流量，發現並不是這樣，而是傳送端的視窗總是會穩定於一 個特定的值，而該值就是接受方的接收視窗的大小，最終，一切都被定格在了接收方的協議棧處理效能以及 緩衝區記憶體情況了，擁塞視窗只要增加到接收方的接收視窗就不再增加和減少了，除非接收視窗增加或者減 小以及擁塞發生了，總之，擁塞視窗和接收視窗的最小值決定傳送視窗，如果擁塞視窗增加到了接收視窗的 大小就不再繼續慢啟動或者擁塞避免。
7.網路裝置和端機的能力
tcp的流量控制在端機，而擁塞卻取決於中間的路由器等網路裝置以及網線，它們處理能力的匹配至關重要 ，雖然端機遠遠不敵中間裝置，可是中間裝置卻由多數端機分享，試想如果端機的效能超越了網路裝置，那 麼流量控制視窗將會很大，如此擁塞視窗將在增加到流控視窗之前出現擁塞，如此一來將會導致頻繁調整發 送視窗，流控視窗也就失去了意義，雖然接收端能收那麼多資料，可是傳送端卻怎麼也到不了該制高點，雖 然到不了但是還是會不懈的慢啟動-擁塞停等-快速重傳-...儼然網路上的西西弗斯神話。
8.tcp是全雙工不停等的
如果按照很多教科書上所講的方式理解tcp，那麼tcp就是乙個半雙工的協議，一方在傳送了資料之後必須等 待確認才能繼續傳送，就是一問一答式，可是看一下tcp的協議頭，包含乙個ack欄位和seq欄位，這就說明 tcp可以在傳送資料的時候將ack一同捎帶過來，正是如此它才是全雙工的。另外它也不是乙個單純的停等協 議，而是基於視窗機制的批量傳送/確認協議。
9.乙個比喻
開車的人或者看過司機開車都知道，汽車的效能和道路的路況(擁塞程度和限速等)以及司機的技術水平共同 決定車能開多快，如果情況一，路況不好(擁塞控制)，那麼再好的車再好的司機都會不停的做剎車，踩油門 ，換檔等動作，所有車都一樣，看起來不夠穩定，如果情況二，路況好，司機也好，但車不好(流量控制)， 雖然很穩定，但白瞎了這條路和司機了，如果情況三，路好，車好，司機不夠嫻熟(流量控制)，司機的動作 和第一種情況一樣，但是好的司機卻不這樣。情況一指的是網路裝置不好，情況二指的是端機不好，情況三 可能是下面的情況，端機好，可是端機上的諸如記憶體管理演算法之類的軟效能很糟糕。
TCP的流量控制
為了提高通道的利用率tcp協議不使用停止等待協議，而是使用連續arq協議，意思就是可以連續發出若干個分組然後等待確認，而不是傳送乙個分組就停止並等待該分組的確認。tcp的兩端都有傳送 接收快取和傳送 接收視窗。tcp的快取是乙個迴圈佇列，其中傳送視窗可以用3個指標表示。而傳送視窗的大小受tcp資料報...
TCP的流量控制
為了提高通道的利用率tcp協議不使用停止等待協議，而是使用連續arq協議，意思就是可以連續發出若干個分組然後等待確認，而不是傳送乙個分組就停止並等待該分組的確認。tcp的兩端都有傳送 接收快取和傳送 接收視窗。tcp的快取是乙個迴圈佇列，其中傳送視窗可以用3個指標表示。而傳送視窗的大小受tcp資料報...
TCP的流量控制
為了提高通道的利用率tcp協議不使用停止等待協議，而是使用連續arq協議，意思就是可以連續發出若干個分組然後等待確認，而不是傳送乙個分組就停止並等待該分組的確認。tcp的兩端都有傳送 接收快取和傳送 接收視窗。tcp的快取是乙個迴圈佇列，其中傳送視窗可以用3個指標表示。而傳送視窗的大小受tcp資料報...