TCP/IP 系列文章

網絡基礎知識（一）
TCP/IP基礎知識（二）
物理層（三）
數據鏈路層（四）
IP 協議（五）
IP 協議相關技術（六）
TCP與UDP（七）

一、傳輸協議層

1.1 兩種傳輸層協議 UDP 和 TCP

在 TCP/IP 中能夠實現傳輸功能的，并具有代表性的協議是 TCP 和 UDP 這兩個協議。兩者都是流協議，你可以把它想象成排水管中的水流。

TCP 協議能夠正確處理丟包問題，保證接收方能夠收到數據，與此同時還能夠有效利用網絡帶寬。然而 TCP 協議中定義了很多復雜的規范，因此效率不如 UDP 協議，不適合實時的視頻和音頻傳輸。

UDP 協議是面向無連接的協議，它只會把數據傳遞給接收端，但是不會關注接收端是否真的收到了數據。但是這種特性反而適合多播，實時的視頻和音頻傳輸。因為個別數據包的丟失并不會影響視頻和音頻的整體效果。

1.2.1 UDP 首部

UDP 的首部結構比較簡單，如下圖所示。

UDP 首部包含源端口號、目標端口號、包長度和校驗和。其中包長度表示 UDP 首部的長度和 UDP 數據長度之和。另外，校驗和用來判斷數據在傳輸過程中是否損壞。計算這個校驗和的時候，不僅考慮源端口號和目標端口號，還要考慮 IP 首部中的源 IP 地址，目標 IP 地址和協議號（這些又稱為 UDP 偽首部）。這是因為以上五個要素用于識別通信時缺一不可，如果校驗和只考慮端口號，那么另外三個要素收到破壞時，應用就無法得知。這有可能導致不該收到包的應用收到了包，該收到包的應用反而沒有收到。這個概念同樣適用于即將介紹的 TCP 首部。

1.2.2 TCP 首部

TCP 首部

毫無疑問，TCP 首部的結構要比 UDP 復雜的多。這也是 TCP 傳輸速度低于 UDP 的重要原因之一。

• 序列號：它表示發送數據的位置，假設當前的序列號為 s，發送數據長度為 l，則下次發送數據時的序列號為 s + l。在建立連接時通常由計算機生成一個隨機數作為序列號的初始值。

• 確認應答號：它等于下一次應該接收到的數據的序列號。假設發送端的序列號為 s，發送數據的長度為 l，那么接收端返回的確認應答號也是 s + l。發送端接收到這個確認應答后，可以認為這個位置以前所有的數據都已被正常接收。

• 數據偏移：TCP 首部的長度，單位為 4 字節。如果沒有可選字段，那么這里的值就是 5。表示 TCP 首部的長度為 20 字節。

• 控制位：改字段長度為 8 比特，分別有 8 個控制標志。依次是 CWR，ECE，URG，ACK，PSH，RST，SYN 和 FIN。在后續的文章中你會陸續接觸到其中的某些控制位。

• 窗口大小：用于表示從應答號開始能夠接受多少個 8 位字節。如果窗口大小為 0，可以發送窗口探測。

• 緊急指針：盡在 URG 控制位為 1 時有效。表示緊急數據的末尾在 TCP 數據部分中的位置。通常在暫時中斷通信時使用（比如輸入 Ctrl + C）。

1.2 關于端口號(擴充)

首先要知道，只有在目標地址、原地址、目標端口號、源端口號以及協議類型（TCP 還是 UDP）這五項內容都一致的時候才被認為是同一個通信連接。

服務端程序在 UNIX 系統中叫做守護進程。如 HTTP 的服務端程序是 httpd（HTTP 守護進程），而 sshd （SSH 守護進程）。在 UNIX 中并不需要將這些守護進程逐個啟動，而是啟動一個可以代表他們接收到客服端請求的 inetd(互聯網進程)服務程序即可。傳輸協議 TCP 、UDP 通過接受數據中的目標端口號識別處理程序。

二、TCP 連接和斷開(三次連接,四次揮手斷開連接)

關于 TCP 連接和斷開連接的過程，可以參考下圖。

連接和斷開連接

2.1 關于三次握手連接

三次握手建立連接流程:

• 1、（客戶端）：我要建立連接了。
• 2、（服務端）：我知道你要建立連接了，我這邊沒有問題。
• 3、（客戶端）：我知道你知道我要建立連接了，接下來我們就正式開始通信。

為什么要三次握手，尤其是為何執行第三步？

一般的思路可能會覺得只要兩次握手就可以了，第三步確認似乎是多余的。其實不然，網絡是不可靠的，數據包是可能丟失的。假設沒有第三次確認，客戶端向服務端發送了 SYN 請求建立連接。由于延遲，服務端沒有及時收到這個包。于是客戶端重新發送一個 SYN 包。假設服務端接收到了第二個 SYN 包，建立了通信，一段時間后通信結束，連接被關閉。這時候最初被發送的 SYN 包剛剛抵達服務端，服務端又會發送一次 ACK 確認。由于兩次握手就建立了連接，此時的服務端就會建立一個新的連接，然而客戶端覺得自己并沒有請求建立連接，所以就不會向服務端發送數據。從而導致服務端建立了一個空的連接，白白浪費資源。但是在有了第三步確認時情況就不一樣了，服務端直到收到客戶端的應答后才會建立連接。如果客戶端接受到一個相同的 ACK 包，這時候它會拋棄這個數據包，不會和服務端再次進行，因此避免了服務端建立空的連接。

建立連接過程中， ACK 確認丟失后，TCP 協議是如何處理？

按照 TCP 協議處理丟包的一般方法，服務端會重新向客戶端發送數據包，直至收到 ACK 確認為止。但實際上這種做法有可能遭到 SYN 泛洪攻擊。所謂的泛洪攻擊，是指發送方偽造多個 IP 地址，模擬三次握手的過程。當服務器返回 ACK 后，攻擊方故意不確認，從而使得服務器不斷重發 ACK。由于服務器長時間處于半連接狀態，最后消耗過多的 CPU 和內存資源導致死機。

正確處理方法是服務端發送 RST 報文，進入 CLOSE 狀態。這個 RST 數據包的 TCP 首部中，控制位中的 RST 位被設置為 1。這表示連接信息全部被初始化，原有的 TCP 通信不能繼續進行。客戶端如果還想重新建立 TCP 連接，就必須重新開始一次握手。

2.2 關于四次揮手斷開連接

四次揮手斷開連接過程：

• 1、（客戶端）：我要關閉連接了。
• 2、（服務端）：你那邊的連接可以關閉了。
• 3、（服務端）：我這邊也要關閉連接了。
• 4、（客戶端）：你那邊的連接可以關閉了。

為什么都要執行關閉操作？

因為連接是雙向的，所以雙方都要主動關閉自己這一側的連接。

ACK 丟失怎么辦？

在第三步中，客戶端收到 FIN 包時，會設置一個計時器，等待相當長的一段時間。如果客戶端返回的 ACK 丟失，那么服務端還會重發 FIN 并重置計時器。假設在計時器失效前服務器重發的 FIN 包沒有到達客戶端，客戶端就會進入 CLOSE 狀態，從而導致服務端永遠無法收到 ACK 確認，也就無法關閉連接。

三、TCP 數據包重發

丟失數據包再次重發的前提是發送方能夠知道接收方是否成功的接收了消息。

通過序列號和確認應答提高可靠性

TCP 中，當發送端的數據到達接收端時，接收端會返回一個已收到消息的回執通知，該回執通知叫做確認應答 ACK 。根據 上面對 TCP 首都的分析可知，該 ACK 的值和發送端下次發送數據包在整個發送數據中的序列號相等。更明確的說，ACK 除了告訴發送端已經接收到了當前數據包，還告訴發送端下次發送數據要從那個位置開始發。如下示意圖。

然而，實際情況并不總是那么盡如人意。比如下面這兩個問題：
1、因為網絡問題，如果數據包和 ACK 應答都丟失，怎么辦？
此時，發送方如果在一段時間內沒有收到 ACK，就會重發數據。
2、由于網絡延遲的存在，接收方收到重復的數據包怎么辦？
通過 TCP 首部中的 SYN 判斷這個數據包是否曾經接收過。如果已經接收過，就會丟棄這個包。

未收到ACK重發過程

TCP 窗口

發送端在數據包發出后，直至 ACK 確認返回以前，發送端都無法發送數據，顯然是一種浪費，網絡利用效率和通信性能就越低。這一問題在 TCP 中通過引入”窗口“的概念得以被解決。

利用窗口控制提高速度

”窗口大小“表示無需等待確認應答ACK返回之前，可以繼續發送數據包的最大數量。

窗口的控制和重發控制

以下示意圖是窗口控制的概念。

• 在使用窗口控制的過程中，如果是數據包已經到達對端，但是確認應答卻沒有返回該怎么辦？這就是窗口最擅長處理的問題了。假設發送發收到的確認包中的 ACK 第一次是 1001，第二次是 4001。那么我們完全可以相信中間的兩個包是成功被接收的。因為如果有沒接收到的包，接收方是不會增加 ACK 的。而在沒有窗口控制的條件下，發送方就會重發第二個和第三個數據包。如下圖所示。

  
  
  ACK丟失的情況

• 在使用窗口控制的過程中，如果是數據包丟失該怎么辦？接收端主機如果接收到一個自己應該接受序號以外的數據，此時只會針對在此之前收到數據返回確認應答ACK。如下圖，當1001 - 2000 的數據包丟失時，發送端會一直收到系列號為 1001 的確認應發，這個確認應答就好像接收端一直在提醒發送端：“我想接收的是從 1001 開始的數據”。當發送端如果連續 3 次收到同樣的確認應答，此時就會針對確認應答序列號發送對應的數據，這種機制被稱作高速重發控制。相對于超時重發機制管理更加有效。如下圖所示。

高速重發機制

補充

TCP 和 UDP 的區別

• TCP 借助滑動窗口協議或早期的停止等待協議，可靠傳輸。UDP 屬于不可靠傳輸，但是在 UDP 的基礎之上，自己處理可以變為可靠傳輸，如 QQ 的底層通信是借助 UDP。
• TCP 具有流量控制功能。流量控制就是讓發送方的放松速率不要太快，要讓接收方來得及接收。接收方除了告訴發送方下一個數據序號之外，還會讓發送方調整發送窗口大小。
• TCP 具有網絡擁塞控制功能。 擁塞控制主要是為了防止過多數據注入網絡中，當發送方遲遲不能收到對方的消息時，猜想當前網絡某處發生了擁塞。發送方就會通過慢開始和擁塞避免機制去控制窗口大小。當發生網絡擁塞時，從1指數型增長窗口大小，當增到特定的時候，再線性增加滑動窗口；當再次發生擁塞時，繼續重復之前步驟。

HTTP 如何實現可靠傳輸？

參考 TCP 可靠傳輸

HTTPS 中間人怎么攻擊的？

針對SSL的中間人攻擊方式主要有兩類，分別是SSL劫持攻擊和SSL剝離攻擊：

SSL劫持攻擊

SSL劫持攻擊即SSL證書欺騙攻擊，攻擊者為了獲得HTTPS傳輸的明文數據，需要先將自己接入到客戶端和目標網站之間；在傳輸過程中偽造服務器的證書，將服務器的公鑰替換成自己的公鑰，這樣，中間人就可以得到明文傳輸帶Key1、Key2和Pre-Master-Key，從而竊取客戶端和服務端的通信數據；

但是對于客戶端來說，如果中間人偽造了證書，在校驗證書過程中會提示證書錯誤，由用戶選擇繼續操作還是返回，由于大多數用戶的安全意識不強，會選擇繼續操作，此時，中間人就可以獲取瀏覽器和服務器之間的通信數據

SSL剝離攻擊

這種攻擊方式也需要將攻擊者設置為中間人，之后見HTTPS范文替換為HTTP返回給瀏覽器，而中間人和服務器之間仍然保持HTTPS服務器。由于HTTP是明文傳輸的，所以中間人可以獲取客戶端和服務器傳輸數據