《圖解TCP/IP》這本書中提到“TCP通過校驗和，序列號，確認應答，重發控制，連接管理以及窗口控制等機制實現可靠性傳輸。”序列號、確認應答、重發控制在TCP三次握手（連接管理）和四次揮手中都有體現，這幾個機制在很多博文中寫的很不錯，我也學習總結過一篇，沒有創新，一直是知識的搬運工。現在我更關心的是窗口控制，流控制，擁塞控制這幾個機制。
首先我會問連接管理，重發控制，確認應答等機制還不能保證可靠性傳輸嗎？爲什麼還需要窗口控制？
事實上前面提到的幾個機制可以保證傳輸的可靠性，但是一條一條信號的發，顯然效率太低了。我們現實生活中批處理被應用於方方面面，考慮一次傳輸一批信號也是常規套路，那一次發多少呢？一次發多少，需要接收方根據能一次收多少決定。
- 接收方怎麼通知發送方自己能接受的數據大小？
TCP在建立連接時，TCP首部字段中包含了接收方將能接受的數據大小，發送到發送者，確定了窗口值的大小。但是這個窗口值在傳輸過程中並不是恆定值，會在超時重傳或者重複應答時根據一定的策略改變窗口值，之後的擁塞控制會詳細描述。
窗口控制是怎麼提高傳輸速率？
傳輸數據時，不需要等待窗口內數據的確認應答可以繼續發送數據，效率顯然會提高，收到一個應答，窗口就會向後滑動。同時如果前面數據確認應答丟失，之後的數據確認應答收到，仍然不需要重發，這也提高了傳輸效率。但是當發送方收到三次同樣的確認應答時，會選擇重發數據。
爲什麼還需要流控制？
我覺得窗口控制確實很好的解決了傳輸速率問題，但是相對靜態不能動態靈活的應對流量不同的情況。流控制正是動態的設置窗口值，來解決流量浪費或流量擁堵。怎麼進行流量控制呢？發送方類似於輪詢機制，不斷的發送探測數據包，來詢問當前接收方能接受的數據大小，然後設置窗口大小。
窗口控制和流控制，提高傳輸速率並且動態設置窗口大小，已然很完美，爲什麼還需要擁塞控制？
其實這個問題寫出來，就發現TCP之前的機制對擁塞控制能力很弱，流控制只是不加重擁堵的狀況，並不能解決擁塞問題。
- 怎麼實現的擁塞控制
首先有一個慢啓動的過程，爲了避免通信剛開始大量數據造成問題。慢啓動時，初始擁塞窗口值設爲1，每次收到應答後擁塞窗口值加1，達到慢啓動的閾值後，以一定的比例增大擁塞窗口。當發生超時重傳時也需要慢啓動修正，慢啓動的閾值設置爲當前擁塞窗口值的一半。當收到三次重複確認應答時，慢啓動的閾值爲當前窗口的一半，窗口也設置爲新閾值+3。