TCP作爲面向連接的協議在實際應用中佔據很重要的地位，其是可靠傳輸協議，保證了數據流的穩定傳輸。現在對TCP做一個簡單的筆記；
一.TCP在通訊中的概覽
如上圖所示，TCP是傳輸層協議，其底層是通過IP層來進行數據收發的；
下面是IP協議的結構：
下面是TCP數據在IP報文中的位置：
下面是TCP協議的結構：
下面是TCP數據傳輸過程：
二.TCP通訊的握手和釋放
首先，TCP在傳輸數據前，需要進行三次握手，流程如下：
但是也存在特殊情況，就是如果在同一主機中，當Peer兩端同時發起SYN來建立連接時，就出現了四次握手來建立連接，如下圖：
其次，TCP在結束數據傳輸時，需要進行四次揮手來釋放連接：
再來看看，TCP的總的時序圖：
然後就是TCP的有限狀態機圖：
三.TCP可靠傳輸流程
1.TCP可靠傳輸的流程的基礎：
（1）滑動窗口協議和連續ARQ協議；
（2）流量控制和阻塞控制；
2.達到的效果：
（1）傳輸信道不產生差錯；
（2）不管發送方以多快的速度發送數據包，接收方總是來得及有序的處理接收到的數據（這有賴於累計確認、超時重傳和擁塞控制等策略）
3.“停止等待協議和自動重傳請求ARQ”對比“滑動窗口協議和連續ARQ協議”
爲了達到“傳輸信道不產生差錯”的目的，需要有發送回覆機制以及數據重傳機制，
最簡單的實現方式就是“停止等待協議和自動重傳請求ARQ”策略，如下圖：
當A給B發送數據包M1後，需要等待B回覆確認包後，A才能發送M2，這就是“停止等待協議”；
當A給B發送數據包M1後，等待確認數據包超時後，就會重新向B發送M1，直到收到確認包，或者超過重傳次數然後嚮應用層報錯；
在這基礎上，爲了加快傳輸速度以及減少流量，於是，出現了“滑動窗口協議和連續ARQ協議”，如下圖：
發送方和接收方商議得出一個窗口長度，發送方在發送數據時，並不只發送一個數據包，而是發送連續的多個數據包，然後接收方接收數據時，也不是每個數據包都回復，而是回覆連續數據包的最後一個數據包（若收到的數據包不連續，就取與以前已收數據包連續的最後一包，若沒有數據包與以前的數據包連續，則不回覆），然後接收方將窗後向前滑動。發送方在收到確認包後，也把窗口向後移動。
4.流量控制
流量控制主要解決了發送方發送能力和接收方接收能力不匹配的問題，同時也限制了流量，如圖：
在建立連接時，發送方根據接收方提供的窗口大小，構造自己的窗口，圖中顯示了前沿和後延兩個數據指針；
當然，在建立連接後，還需要有機制保持發送方和接收方的窗口同步，如圖：
注意，爲了解決“零窗口”報文導致的死鎖狀態，TCP提供了“持續計時器”的機制，當發送方收到“零窗口”報文後，會啓動計時器，若在時間到達之後就會發送“零窗口探測報文”，以此來通過輪詢方式來解決死鎖的狀態；
5.擁塞控制
流量控制是用於點到點傳輸的控制策略，而擁塞控制是針對整個網絡環境的策略。
當網絡環境惡化時，擁塞控制將會有效的控制各點的數據流量，以嘗試達到恢復網絡環境的目的，具體措施如下：
（1）通過慢開始來確定擁塞窗口cwind，同時避免瞬間的大流量造成網絡的癱瘓：
（2）通過快重傳和快恢復來調整cwind：
（3）根據接收窗口rwind和擁塞窗口cwind，來重新確定發送窗口：
發送窗口的上限值 = Min[rwnd， cwnd]
（4）路由器中，爲了維持其穩定性，就出現了流量超載時隨機丟棄數據包的機制，此機制如圖：
爲了迎合這種的策略，減少數據包丟失造成的對TCP通訊的危害，TCP出現了隨機早期檢測機制（random early detection）RED，具體做法就是：監控路由器發送隊列的平均隊列長度Lav，若發現逼近擁堵，則隨機的選擇本地中的幾個連接來提前告知擁塞情況，以提前降低網絡流量。
四. 筆記後的問題和記錄
1.重傳時，發送方和接收方如何處理重複收到的數據包？
答：接收方會丟棄這個數據包同時回覆一個確認包，發送方會直接丟棄這個重複的確認包；
2.若因爲物理故障或其他原因，接收方一直沒收到發送方的任何數據包，導致接收方處於停止狀態而無法通知應用程序AP來關閉連接，怎麼辦？
答：
（1）TCP協議棧裏提供了keepalive機制，開啓了這個屬性後，tcp將會定期的發送keepalive數據包進行連接檢測，若發現異常，則報告給AP；
（2）同時，也可以應用層實現心跳包機制，一般是client發送給server，server和client通過心跳來判定連接是否有效；
