TCP/IP 系列文章
網(wǎng)絡(luò)基礎(chǔ)知識（一）
TCP/IP基礎(chǔ)知識（二）
物理層（三）
數(shù)據(jù)鏈路層（四）
IP 協(xié)議（五）
IP 協(xié)議相關(guān)技術(shù)（六）
TCP與UDP（七）
一、傳輸協(xié)議層
1.1 兩種傳輸層協(xié)議 UDP 和 TCP
在 TCP/IP 中能夠?qū)崿F(xiàn)傳輸功能的，并具有代表性的協(xié)議是 TCP 和 UDP 這兩個協(xié)議。兩者都是流協(xié)議，你可以把它想象成排水管中的水流。
TCP 協(xié)議能夠正確處理丟包問題，保證接收方能夠收到數(shù)據(jù)，與此同時還能夠有效利用網(wǎng)絡(luò)帶寬。然而 TCP 協(xié)議中定義了很多復(fù)雜的規(guī)范，因此效率不如 UDP 協(xié)議，不適合實時的視頻和音頻傳輸。
UDP 協(xié)議是面向無連接的協(xié)議，它只會把數(shù)據(jù)傳遞給接收端，但是不會關(guān)注接收端是否真的收到了數(shù)據(jù)。但是這種特性反而適合多播，實時的視頻和音頻傳輸。因為個別數(shù)據(jù)包的丟失并不會影響視頻和音頻的整體效果。
1.2.1 UDP 首部
UDP 的首部結(jié)構(gòu)比較簡單，如下圖所示。
UDP 首部包含源端口號、目標(biāo)端口號、包長度和校驗和。其中包長度表示 UDP 首部的長度和 UDP 數(shù)據(jù)長度之和。另外，校驗和用來判斷數(shù)據(jù)在傳輸過程中是否損壞。計算這個校驗和的時候，不僅考慮源端口號和目標(biāo)端口號，還要考慮 IP 首部中的源 IP 地址，目標(biāo) IP 地址和協(xié)議號（這些又稱為 UDP 偽首部）。這是因為以上五個要素用于識別通信時缺一不可，如果校驗和只考慮端口號，那么另外三個要素收到破壞時，應(yīng)用就無法得知。這有可能導(dǎo)致不該收到包的應(yīng)用收到了包，該收到包的應(yīng)用反而沒有收到。這個概念同樣適用于即將介紹的 TCP 首部。
1.2.2 TCP 首部
毫無疑問，TCP 首部的結(jié)構(gòu)要比 UDP 復(fù)雜的多。這也是 TCP 傳輸速度低于 UDP 的重要原因之一。
序列號：它表示發(fā)送數(shù)據(jù)的位置，假設(shè)當(dāng)前的序列號為 s，發(fā)送數(shù)據(jù)長度為 l，則下次發(fā)送數(shù)據(jù)時的序列號為 s + l。在建立連接時通常由計算機生成一個隨機數(shù)作為序列號的初始值。
確認應(yīng)答號：它等于下一次應(yīng)該接收到的數(shù)據(jù)的序列號。假設(shè)發(fā)送端的序列號為 s，發(fā)送數(shù)據(jù)的長度為 l，那么接收端返回的確認應(yīng)答號也是 s + l。發(fā)送端接收到這個確認應(yīng)答后，可以認為這個位置以前所有的數(shù)據(jù)都已被正常接收。
數(shù)據(jù)偏移：TCP 首部的長度，單位為 4 字節(jié)。如果沒有可選字段，那么這里的值就是 5。表示 TCP 首部的長度為 20 字節(jié)。
控制位：改字段長度為 8 比特，分別有 8 個控制標(biāo)志。依次是 CWR，ECE，URG，ACK，PSH，RST，SYN 和 FIN。在后續(xù)的文章中你會陸續(xù)接觸到其中的某些控制位。
窗口大?。河糜诒硎緩膽?yīng)答號開始能夠接受多少個 8 位字節(jié)。如果窗口大小為 0，可以發(fā)送窗口探測。
緊急指針：盡在 URG 控制位為 1 時有效。表示緊急數(shù)據(jù)的末尾在 TCP 數(shù)據(jù)部分中的位置。通常在暫時中斷通信時使用（比如輸入 Ctrl + C）。
1.2 關(guān)于端口號(擴充)
首先要知道，只有在目標(biāo)地址、原地址、目標(biāo)端口號、源端口號以及協(xié)議類型（TCP 還是 UDP）這五項內(nèi)容都一致的時候才被認為是同一個通信連接。
服務(wù)端程序在 UNIX 系統(tǒng)中叫做守護進程。如 HTTP 的服務(wù)端程序是 httpd（HTTP 守護進程），而 sshd （SSH 守護進程）。在 UNIX 中并不需要將這些守護進程逐個啟動，而是啟動一個可以代表他們接收到客服端請求的 inetd(互聯(lián)網(wǎng)進程)服務(wù)程序即可。傳輸協(xié)議 TCP 、UDP 通過接受數(shù)據(jù)中的目標(biāo)端口號識別處理程序。
二、TCP 連接和斷開(三次連接,四次揮手斷開連接)
關(guān)于 TCP 連接和斷開連接的過程，可以參考下圖。
2.1 關(guān)于三次握手連接
三次握手建立連接流程:
- 1、（客戶端）：我要建立連接了。
- 2、（服務(wù)端）：我知道你要建立連接了，我這邊沒有問題。
- 3、（客戶端）：我知道你知道我要建立連接了，接下來我們就正式開始通信。
為什么要三次握手，尤其是為何執(zhí)行第三步？
一般的思路可能會覺得只要兩次握手就可以了，第三步確認似乎是多余的。其實不然，網(wǎng)絡(luò)是不可靠的，數(shù)據(jù)包是可能丟失的。假設(shè)沒有第三次確認，客戶端向服務(wù)端發(fā)送了 SYN 請求建立連接。由于延遲，服務(wù)端沒有及時收到這個包。于是客戶端重新發(fā)送一個 SYN 包。假設(shè)服務(wù)端接收到了第二個 SYN 包，建立了通信，一段時間后通信結(jié)束，連接被關(guān)閉。這時候最初被發(fā)送的 SYN 包剛剛抵達服務(wù)端，服務(wù)端又會發(fā)送一次 ACK 確認。由于兩次握手就建立了連接，此時的服務(wù)端就會建立一個新的連接，然而客戶端覺得自己并沒有請求建立連接，所以就不會向服務(wù)端發(fā)送數(shù)據(jù)。從而導(dǎo)致服務(wù)端建立了一個空的連接，白白浪費資源。但是在有了第三步確認時情況就不一樣了，服務(wù)端直到收到客戶端的應(yīng)答后才會建立連接。如果客戶端接受到一個相同的 ACK 包，這時候它會拋棄這個數(shù)據(jù)包，不會和服務(wù)端再次進行，因此避免了服務(wù)端建立空的連接。
建立連接過程中， ACK 確認丟失后，TCP 協(xié)議是如何處理？
按照 TCP 協(xié)議處理丟包的一般方法，服務(wù)端會重新向客戶端發(fā)送數(shù)據(jù)包，直至收到 ACK 確認為止。但實際上這種做法有可能遭到 SYN 泛洪攻擊。所謂的泛洪攻擊，是指發(fā)送方偽造多個 IP 地址，模擬三次握手的過程。當(dāng)服務(wù)器返回 ACK 后，攻擊方故意不確認，從而使得服務(wù)器不斷重發(fā) ACK。由于服務(wù)器長時間處于半連接狀態(tài)，最后消耗過多的 CPU 和內(nèi)存資源導(dǎo)致死機。
正確處理方法是服務(wù)端發(fā)送 RST 報文，進入 CLOSE 狀態(tài)。這個 RST 數(shù)據(jù)包的 TCP 首部中，控制位中的 RST 位被設(shè)置為 1。這表示連接信息全部被初始化，原有的 TCP 通信不能繼續(xù)進行?？蛻舳巳绻€想重新建立 TCP 連接，就必須重新開始一次握手。
2.2 關(guān)于四次揮手斷開連接
四次揮手斷開連接過程：
- 1、（客戶端）：我要關(guān)閉連接了。
- 2、（服務(wù)端）：你那邊的連接可以關(guān)閉了。
- 3、（服務(wù)端）：我這邊也要關(guān)閉連接了。
- 4、（客戶端）：你那邊的連接可以關(guān)閉了。
為什么都要執(zhí)行關(guān)閉操作？
因為連接是雙向的，所以雙方都要主動關(guān)閉自己這一側(cè)的連接。
ACK 丟失怎么辦？
在第三步中，客戶端收到 FIN 包時，會設(shè)置一個計時器，等待相當(dāng)長的一段時間。如果客戶端返回的 ACK 丟失，那么服務(wù)端還會重發(fā) FIN 并重置計時器。假設(shè)在計時器失效前服務(wù)器重發(fā)的 FIN 包沒有到達客戶端，客戶端就會進入 CLOSE 狀態(tài)，從而導(dǎo)致服務(wù)端永遠無法收到 ACK 確認，也就無法關(guān)閉連接。
三、TCP 數(shù)據(jù)包重發(fā)
丟失數(shù)據(jù)包再次重發(fā)的前提是發(fā)送方能夠知道接收方是否成功的接收了消息。
通過序列號和確認應(yīng)答提高可靠性
TCP 中，當(dāng)發(fā)送端的數(shù)據(jù)到達接收端時，接收端會返回一個已收到消息的回執(zhí)通知，該回執(zhí)通知叫做確認應(yīng)答 ACK 。根據(jù) 上面對 TCP 首都的分析可知，該 ACK 的值和發(fā)送端下次發(fā)送數(shù)據(jù)包在整個發(fā)送數(shù)據(jù)中的序列號相等。更明確的說，ACK 除了告訴發(fā)送端已經(jīng)接收到了當(dāng)前數(shù)據(jù)包，還告訴發(fā)送端下次發(fā)送數(shù)據(jù)要從那個位置開始發(fā)。如下示意圖。
然而，實際情況并不總是那么盡如人意。比如下面這兩個問題：
1、因為網(wǎng)絡(luò)問題，如果數(shù)據(jù)包和 ACK 應(yīng)答都丟失，怎么辦？
此時，發(fā)送方如果在一段時間內(nèi)沒有收到 ACK，就會重發(fā)數(shù)據(jù)。
2、由于網(wǎng)絡(luò)延遲的存在，接收方收到重復(fù)的數(shù)據(jù)包怎么辦？
通過 TCP 首部中的 SYN 判斷這個數(shù)據(jù)包是否曾經(jīng)接收過。如果已經(jīng)接收過，就會丟棄這個包。
TCP 窗口
發(fā)送端在數(shù)據(jù)包發(fā)出后，直至 ACK 確認返回以前，發(fā)送端都無法發(fā)送數(shù)據(jù)，顯然是一種浪費，網(wǎng)絡(luò)利用效率和通信性能就越低。這一問題在 TCP 中通過引入”窗口“的概念得以被解決。
利用窗口控制提高速度
”窗口大小“表示無需等待確認應(yīng)答ACK返回之前，可以繼續(xù)發(fā)送數(shù)據(jù)包的最大數(shù)量。
窗口的控制和重發(fā)控制
以下示意圖是窗口控制的概念。
-
在使用窗口控制的過程中，如果是數(shù)據(jù)包已經(jīng)到達對端，但是確認應(yīng)答卻沒有返回該怎么辦？這就是窗口最擅長處理的問題了。假設(shè)發(fā)送發(fā)收到的確認包中的 ACK 第一次是 1001，第二次是 4001。那么我們完全可以相信中間的兩個包是成功被接收的。因為如果有沒接收到的包，接收方是不會增加 ACK 的。而在沒有窗口控制的條件下，發(fā)送方就會重發(fā)第二個和第三個數(shù)據(jù)包。如下圖所示。
ACK丟失的情況 在使用窗口控制的過程中，如果是數(shù)據(jù)包丟失該怎么辦？接收端主機如果接收到一個自己應(yīng)該接受序號以外的數(shù)據(jù)，此時只會針對在此之前收到數(shù)據(jù)返回確認應(yīng)答ACK。如下圖，當(dāng)1001 - 2000 的數(shù)據(jù)包丟失時，發(fā)送端會一直收到系列號為 1001 的確認應(yīng)發(fā)，這個確認應(yīng)答就好像接收端一直在提醒發(fā)送端：“我想接收的是從 1001 開始的數(shù)據(jù)”。當(dāng)發(fā)送端如果連續(xù) 3 次收到同樣的確認應(yīng)答，此時就會針對確認應(yīng)答序列號發(fā)送對應(yīng)的數(shù)據(jù)，這種機制被稱作高速重發(fā)控制。相對于超時重發(fā)機制管理更加有效。如下圖所示。
補充
TCP 和 UDP 的區(qū)別
- TCP 借助滑動窗口協(xié)議或早期的停止等待協(xié)議，可靠傳輸。UDP 屬于不可靠傳輸，但是在 UDP 的基礎(chǔ)之上，自己處理可以變?yōu)榭煽總鬏敚?QQ 的底層通信是借助 UDP。
- TCP 具有流量控制功能。流量控制就是讓發(fā)送方的放松速率不要太快，要讓接收方來得及接收。接收方除了告訴發(fā)送方下一個數(shù)據(jù)序號之外，還會讓發(fā)送方調(diào)整發(fā)送窗口大小。
- TCP 具有網(wǎng)絡(luò)擁塞控制功能。 擁塞控制主要是為了防止過多數(shù)據(jù)注入網(wǎng)絡(luò)中，當(dāng)發(fā)送方遲遲不能收到對方的消息時，猜想當(dāng)前網(wǎng)絡(luò)某處發(fā)生了擁塞。發(fā)送方就會通過慢開始和擁塞避免機制去控制窗口大小。當(dāng)發(fā)生網(wǎng)絡(luò)擁塞時，從1指數(shù)型增長窗口大小，當(dāng)增到特定的時候，再線性增加滑動窗口；當(dāng)再次發(fā)生擁塞時，繼續(xù)重復(fù)之前步驟。
HTTP 如何實現(xiàn)可靠傳輸？
參考 TCP 可靠傳輸
HTTPS 中間人怎么攻擊的？
針對SSL的中間人攻擊方式主要有兩類，分別是SSL劫持攻擊和SSL剝離攻擊：
SSL劫持攻擊
SSL劫持攻擊即SSL證書欺騙攻擊，攻擊者為了獲得HTTPS傳輸?shù)拿魑臄?shù)據(jù)，需要先將自己接入到客戶端和目標(biāo)網(wǎng)站之間；在傳輸過程中偽造服務(wù)器的證書，將服務(wù)器的公鑰替換成自己的公鑰，這樣，中間人就可以得到明文傳輸帶Key1、Key2和Pre-Master-Key，從而竊取客戶端和服務(wù)端的通信數(shù)據(jù)；
但是對于客戶端來說，如果中間人偽造了證書，在校驗證書過程中會提示證書錯誤，由用戶選擇繼續(xù)操作還是返回，由于大多數(shù)用戶的安全意識不強，會選擇繼續(xù)操作，此時，中間人就可以獲取瀏覽器和服務(wù)器之間的通信數(shù)據(jù)
SSL剝離攻擊
這種攻擊方式也需要將攻擊者設(shè)置為中間人，之后見HTTPS范文替換為HTTP返回給瀏覽器，而中間人和服務(wù)器之間仍然保持HTTPS服務(wù)器。由于HTTP是明文傳輸?shù)?，所以中間人可以獲取客戶端和服務(wù)器傳輸數(shù)據(jù)
