前言

TCP（Transmisson Control Protocol）又叫傳輸控制協議作爲傳輸層最重要的協議，對於信息的可靠傳輸有着重要的意義，針對這一協議的攻擊也數不勝數，這裏就對這一協議以及相關內容進行詳細的總結，將從以下幾個方面進行介紹。
本文以韓立剛老師的《計算機網絡》網課爲基礎，感興趣的話可以私信我要資料

文章目錄

前言

1. TCP協議概述

在網絡中，接收端從發送端接收的數據大部分條件下都必須是完整的，一字不落的，否則數據也就失去了意義，比如在下載應用時，下載過程中丟失了一個動態鏈接庫（DLL）文件，那麼這個應用就很可能打不開，只有在很少情況下不需要那麼精準，那麼使用UDP就行，但是TCP使用範圍更廣，下面是其幾個特點。

TCP 是面向連接的傳輸層協議。
利用TCP協議傳輸數據前，必須使client和server通過tcp的三次握手建立連接並協商雙方的各種參數，在傳輸完成後還需要通過四次揮手釋放連接，也就是說在通過tcp協議傳輸時，雙方一直要都處在連接狀態。
每一條 TCP 連接只能有兩個端點(endpoint)，每一條 TCP 連接只能是點對點的（一對一）。
相對於UDP在廣播以及多播中的一對多，TCP連接時一對一的。
TCP 提供可靠交付的服務。
TCP 提供全雙工通信。
這裏說的全雙工大家可以理解爲打電話，雙方都可以收發消息，這是相對於單工和半雙工來說的，UDP就是典型的單工通信（想了解單工、半雙工和全雙工區別的同學可以看這篇文章）
面向字節流。
TCP是以字節爲單位進行傳輸的，不是以位爲單位
簡單過程如下：

其中“1，2，3…”是代表着一個個字節。
詳細過程如下：

6. TCP的連接
TCP 把連接作爲最基本的抽象，每一條 TCP 連接有兩個端點，TCP 連接的端點不是主機，不是主機的IP 地址，不是應用進程，也不是傳輸層的協議端口。TCP 連接的端點叫做套接字(socket) ，而套接字是由IP地址加上端口號拼接而成的。
如下圖：

這裏有一點要補充，現在已經得到廣泛應用的SSL協議（安全套接字協議）和TLS（安全傳輸層）協議中的記錄協議就是應用在傳輸層，通過加密等手段來保證安全。

2.TCP如何實現可靠傳輸

網絡層只負責把數據包從一個網段轉到另一個網段，中間因爲網絡擁塞或者中斷等原因可能導致數據包丟失，那麼其中包括的TCP數據報肯定也就隨之丟失，那麼如何在不穩定的網絡中進行TCP數據報的可靠傳輸（也就是把所有要傳的文件完整的從一臺電腦傳輸到另一臺電腦呢）？
於是就產生了停止-等待協議（Stop-and-Wait）,其原理如下：
（一）先看一下無差錯情況：

在這種情況下A向B發送TCP報文，發送一個，確認一個，然後再發送第二個，這是理想情況，如前言所說，因爲網絡環境的複雜，會存在各種丟包的情況。
下面就來看看在網絡中丟包的各種情況，以及保證在每個情況下保證可靠傳輸的方式
（2）出錯情況
大致分爲如下三種情況：
（a）. 數據包沒有到達B，如圖：

A在發送一個數據後，會爲這個數據設立一個計時，如果在規定的時間內沒有收到B的確認收到的答覆，那麼就會重傳這個數據，這種機制叫做超時重傳，這樣就可以保證每個數據都會傳輸完成。
（b）. 數據包到達了B，B也發送了確認消息，但是在發送給A的過程中丟失，如下圖：

在這種情況下，A像第一種情況下沒有收到B對於M1的確認信息，於是在超時後重傳了M1，這就導致了B接收到了兩次M1，那麼經過比較以後，B就會把相同的數據，也就是第二次傳輸來的M1丟棄，然後再次向A發送確認已經收到M1的消息，讓A繼續發接下來的數據。
（c）. 像b中一樣，數據包到達了B，B也發送了確認消息，但是在發送給A的過程中因爲走了較遠的路由路線，所以遲遲到不了A，這種情況如下：

因爲第一次確認走了遠路，確認信息遲遲到不了A，超過時限以後，A自動重傳，像(b)情況一樣，因爲B計算機已經收到了數據M1，所以會丟棄重複的M1，並再次向A發送確認，如果還是走了遠路沒有到達，那麼就重複這一過程，指導有對於M1的確認信息到達A，A纔開始發送M2數據，而對於後面遲到的對於M1數據的確認信息，A不會再做任何響應，因爲已經對其響應過了。

上面的這四種情況都解決了以後，也就可以實現可靠傳輸了，這種傳輸的方式習慣上被稱爲自動重傳請求ARQ（Automatic Repeat Reauest）,值得注意的是，這個名字容易給人一種誤解，“請求”這個詞是不準確的，B並不需要像A發送重傳請求，A在設定的時間超時後會自動重傳，沒有“請求”的過程。

還有幾點需要注意：

爲了對可能的重傳做準備，在發送完一個分組後，必須暫時保留已發送的分組的副本。
爲了對比發送和確認的數據是否是同一個，需要在發送端和接收端都對數據進行編號，這樣的話，發送端就可以比較受到的確認是對哪一個數據的確認，如果重複的話，就丟棄這個確認，接收端也可以根據編號來比較這個數據是否收到過，從而判斷是丟棄還是發送確認。這裏發送端和接收端的編號應該相同。
超時計時器的重傳時間應當比數據在分組傳輸的平均往返時間更長一些。
這樣纔不會重複分發送多次數據。

但是，雖然利用停止等待協議和ARQ協議可以實現數據的可靠傳輸，這種機制也有一個明顯的缺點，那就是太慢了，每發送一個TCP報文，就得等待一個特定時長或者收到對方的確認信息才能進行下一步操作，這樣對於傳輸信道的利用率就太低了，這裏先介紹一下信道利用率的概念，如圖：

這是數據報文在A B之間傳輸的示意圖，其中，TD 代表A計算機發送一個數據報文所需的時間，RTT是Round-trip-time的縮寫，意思是往返時間，TA是A計算機接收確認信息所需的時間，那麼信道利用率的定義就如圖：

從公式和示意圖都可以看出，要想提高信道利用率並提高發送速度，就要使TD的值儘可能大，下面就來介紹如何提高TD的值。
單個TD的值很難改變，那麼就通過多發送來提高TD的值，如圖：

這種方式叫做流水線傳輸，這樣就能大大增加在信道中傳輸數據的數量，提高傳輸速度。
同樣，這裏也得保證數據的可靠傳輸，由此引進了滑動窗口技術，利用的是連續ARQ，如圖:

對於發送方來說，假設滑動窗口的大小是5，那麼就意味着一直有5個數據在窗口內，窗口內的數據一個個按隊列發送，而不用等確認信息，如圖，發送順序爲1-2-3-4-5，不如在發送3的過程中，收到了1的確認，那麼窗口就把1從窗口中去除（也就是從緩存中刪除），窗口也相應的向前滑動一格，變成了2-3-4-5-6，這樣，收到一個確認刪除一個，往前滑一格。
但是每次都只能接收一個數據的確認顯然速度還是慢，那麼就產生了“累計確認”的方式，如圖：

B計算機在收到1 2 3 三個數據報文以後，只返回3的確認信息，就代表着已經收到了3之前的數據，這樣也就減少了確認數據包所需時間，從而提高了速度。
但是這種方法也有一個缺點，考慮以下情況，如圖：

B計算機收到了1 2和4，但是因爲中間缺少了3，B就只會向A發送1 2 的確認包，就默認4沒有收到，然後A就會再重新發送3,超時以後就會重傳4（後面會講到改進方法）。
因此累積確認有以下特點：
優點是：容易實現，信道利用率高。
缺點是：不能向發送方反映出接收方已經正確收到的所有分組的信息。
下一篇會介紹TCP首部詳解與抓包分析實踐，如有需要，請移步