計算機網絡體系結構

OSI七層模型

OSI采用了分層的結構化技術，共分七層，物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。

TCP/IP模型

OSI模型比較復雜且學術化，所以我們實際使用的TCP/IP模型，共分4層，鏈路層、網絡層、傳輸層、應用層。兩個模型之間的對應關系如圖所示：

無論什么模型，每一個抽象層建立在低一層提供的服務上，并且為高一層提供服務。

TCP/IP協議族

Transmission Control Protocol/Internet Protocol的簡寫，中譯名為傳輸控制協議/因特網互聯協議，是 Internet 最基本的協議、Internet 國際互聯網絡的基礎，由網絡層的 IP 協議和傳輸層的 TCP 協議組成。協議采用了4層的層級結構。然而在很多情況下，它是利用 IP 進行通信時所必須用到的協議群的統稱。

TCP/IP 網絡傳輸中的數據

每個分層中，都會對所發送的數據附加一個首部，在這個首部中包含了該層必要的信息，如發送的目標地址以及協議相關信息。通常，為協議提供的信息為包首部，所要發送的內容為數據。在下一層的角度看，從上一層收到的包全部都被認為是本層的數據。

網絡中傳輸的數據包由兩部分組成：一部分是協議所要用到的首部，另一部分是上一層傳過來的數據。首部的結構由協議的具體規范詳細定義。在數據包的首部，明確標明了協議應該如何讀取數據。反過來說，看到首部，也就能夠了解該協議必要的信息以及所要處理的數據。

① 應用程序處理
首先應用程序會進行編碼處理，這些編碼相當于 OSI 的表示層功能；
編碼轉化后，郵件不一定馬上被發送出去，這種何時建立通信連接何時發送數據的管理功能，相當于 OSI 的會話層功能。

② TCP 模塊的處理
TCP 根據應用的指示，負責建立連接、發送數據以及斷開連接。TCP 提供將應用層發來的數據順利發送至對端的可靠傳輸。為了實現這一功能，需要在應用層數據的前端附加一個 TCP 首部。

③ IP 模塊的處理
IP 將 TCP 傳過來的 TCP 首部和 TCP 數據合起來當做自己的數據，并在 TCP 首部的前端加上自己的 IP 首部。IP 包生成后，參考路由控制表決定接受此 IP 包的路由或主機。

④ 網絡接口（以太網驅動）的處理
從 IP 傳過來的 IP 包對于以太網來說就是數據。給這些數據附加上以太網首部并進行發送處理，生成的以太網數據包將通過物理層傳輸給接收端。

⑤ 網絡接口（以太網驅動）的處理
主機收到以太網包后，首先從以太網包首部找到 MAC 地址判斷是否為發送給自己的包，若不是則丟棄數據。
如果是發送給自己的包，則從以太網包首部中的類型確定數據類型，再傳給相應的模塊，如 IP、ARP 等。這里的例子則是 IP 。

⑥ IP 模塊的處理
IP 模塊接收到數據后也做類似的處理。從包首部中判斷此 IP 地址是否與自己的 IP 地址匹配，如果匹配則根據首部的協議類型將數據發送給對應的模塊，如 TCP、UDP。這里的例子則是 TCP。
另外嗎，對于有路由器的情況，接收端地址往往不是自己的地址，此時，需要借助路由控制表，在調查應該送往的主機或路由器之后再進行轉發數據。

⑦ TCP 模塊的處理
在 TCP 模塊中，首先會計算一下校驗和，判斷數據是否被破壞。然后檢查是否在按照序號接收數據。最后檢查端口號，確定具體的應用程序。數據被完整地接收以后，會傳給由端口號識別的應用程序。

⑧ 應用程序的處理
接收端應用程序會直接接收發送端發送的數據。通過解析數據，展示相應的內容。

TCP 和 UDP

網際協議IP是TCP/IP中非常重要的協議。負責對數據加上IP地址（有發送它的主機的地址（源地址）和接收它的主機的地址（目的地址））和其他的數據以確定傳輸的目標。

而 TCP 和 UDP 都是傳輸層的協議，傳輸層主要為兩臺主機上的應用程序提供端到端的通信。

但是 TCP 和 UDP 最不同的地方是，TCP 提供了一種可靠的數據傳輸服務，TCP 是面向連接的，也就是說，利用 TCP 通信的兩臺主機首先要經歷一個建立連接的過程，等到連接建立后才開始傳輸數據，而且傳輸過程中采用“帶重傳的肯定確認”技術來實現傳輸的可靠性。TCP 還采用一種稱為“滑動窗口”的方式進行流量控制，發送完成后還會關閉連接。所以 TCP 要比 UDP 可靠的多。

UDP（User Datagram Protocol的簡稱， 中文名是用戶數據報協議）是把數據直接發出去，而不管對方是不是在接收，也不管對方是否能接收的了，也不需要接收方確認，屬于不可靠的傳輸，可能會出現丟包現象，實際應用中要求程序員編程驗證。

注意：
我們一些常見的網絡應用基本上都是基于 TCP 和 UDP 的，這兩個協議又會使用網絡層的 IP 協議。但是我們完全可以繞過傳輸層的 TCP 和 UDP，直接使用 IP，比如 Linux 中 LVS，甚至直接訪問鏈路層，比如 tcpdump 程序就是直接和鏈路層進行通信的。

上圖中，其他一些協議的名稱解釋：
ICMP 控制報文協議
IGMP internet組管理協議
ARP 地址解析協議
RARP 反向地址轉化協議

詳解 TCP 協議特點

TCP 是傳輸層協議，對應 OSI 網絡模型的第四層傳輸層，特點如下。

• TCP 協議是基于鏈接的，也就是傳輸數據前需要先建立好鏈接，然后再進行傳輸。
• TCP 鏈接一旦建立，就可以在鏈接上進行雙向的通信。
• TCP 的傳輸是基于字節流而不是報文，將數據按字節大小進行編號，接收端通過 ACK 來確認收到的數據編號，通過這種機制，TCP 協議能夠保證接收數據的有序性和完整性，因此 TCP 能夠提供可靠性傳輸。
• TCP 還能提供流量控制能力，通過滑動窗口來控制數據的發送速率。滑動窗口的本質是動態緩沖區，接收端根據自己的處理能力，在 TCP 的 Header 中動態調整窗口大小，通過 ACK 應答包通知給發送端，發送端根據窗口大小調整發送的的速度。
• 僅僅有了流量控制能力還不夠，TCP 協議還考慮到了網絡問題可能會導致大量重傳，進而導致網絡情況進一步惡化，因此 TCP 協議還提供擁塞控制。TCP 處理擁塞控制主要用到了慢啟動、擁塞避免、擁塞發生、快速恢復四個算法。

序列號，確認號

• 序列號seq（Sequence Numbers）：用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記
• 確認序號ACK（Acknowledge Number）：在接收端，用來通知發送端數據成功接收;其數值等于發送方的發送序號+1(即接收方期望接收的下一個序列號)；
• 標志位：
  （A）SYN：創建一個連接
  （B）ACK：確認序號有效
  （C）FIN：終結一個連接
  （D）RST：重置連接。
  （E）PSH：接收方應該盡快將這個報文交給應用層。
  （F）URG：緊急指針（urgent pointer）有效。

TCP三次握手

TCP 是基于鏈接的，所以在傳輸數據前需要先建立鏈接，TCP 在傳輸上是雙工傳輸，不區分 Client 端與 Server 端，為了便于理解，我們把主動發起建連請求的一端稱作 Client 端，把被動建立鏈接的一端稱作 Server 端。

如下圖，建連的時序是從上到下，左右兩邊分別代表 Client 端與 Server 端當時的鏈接狀態。

TCP 提供面向有連接的通信傳輸。面向有連接是指在數據通信開始之前先做好兩端之間的準備工作。

所謂三次握手是指建立一個 TCP 連接時需要客戶端和服務器端總共發送三個包以確認連接的建立。在 socket 編程中，這一過程由客戶端執行 connect 來觸發。

第一次握手：客戶端將標志位 SYN 置為1，隨機產生一個值 seq=J，并將該數據包發送給服務器端，客戶端進入 SYN_SENT 狀態，等待服務器端確認。

第二次握手：服務器端收到數據包后由標志位 SYN=1 知道客戶端請求建立連接，服務器端將標志位 SYN 和 ACK 都置為1，ack=J+1，隨機產生一個值 seq=K，并將該數據包發送給客戶端以確認連接請求，服務器端進入 SYN_RCVD 狀態。

第三次握手：客戶端收到確認后，檢查 ack 是否為J+1，ACK 是否為1，如果正確則將標志位 ACK 置為1，ack=K+1，并將該數據包發送給服務器端，服務器端檢查 ack 是否為K+1，ACK 是否為1，如果正確則連接建立成功，客戶端和服務器端進入 ESTABLISHED 狀態，完成三次握手，隨后客戶端與服務器端之間可以開始傳輸數據了。

為什么 TCP 握手需要三次?

TCP 是可靠的傳輸控制協議，而三次握手是保證數據可靠傳輸又能提高傳輸效率的最小次數。

原因：
為了實現可靠數據傳輸， TCP 協議的通信雙方，都必須維護一個序列號， 以標識發送出去的數據包中，哪些是已經被對方收到的。

例如：發送方在發送數據包（假設大小為 10 byte）時， 同時送上一個序號( 假設為 500)，那么接收方收到這個數據包以后， 就可以回復一個確認號（510 = 500 + 10） 告訴發送方 “我已經收到了你的數據包， 你可以發送下一個數據包， 序號從 511 開始” 。

三次握手的過程即是通信雙方相互告知序列號起始值，并確認對方已經收到了序列號起始值的必經步驟。

如果只是兩次握手， 至多只有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認。

至于為什么不是四次，很明顯，三次握手后，通信的雙方都已經知道了對方序列號起始值，也確認了對方知道自己序列號起始值，第四次握手已經毫無必要了。

TCP 的三次握手的漏洞-SYN洪泛攻擊

TCP 三次握手中是有一個缺陷的，就是如果我們利用三次握手的缺陷進行攻擊。這個攻擊就是 SYN 洪泛攻擊。三次握手中有一個第二次握手，服務端向客戶端應答請求，應答請求是需要客戶端 IP 的，攻擊者就偽造這個 IP，往服務器端狂發送第一次握手的內容，當然第一次握手中的客戶端 IP 地址是偽造的，從而服務端忙于進行第二次握手但是第二次握手當然沒有結果，所以導致服務器端被拖累，死機。

面對這種攻擊，有以下的解決方案，最好的方案是防火墻。
無效連接監視釋放
這種方法不停監視所有的連接，包括三次握手的，還有握手一次的，反正是所有的，當達到一定(與)閾值時拆除這些連接，從而釋放系統資源。這種方法對于所有的連接一視同仁，不管是正常的還是攻擊的，所以這種方式不推薦。
延緩TCB分配方法
一般的做完第一次握手之后，服務器就需要為該請求分配一個 TCB（連接控制資源），通常這個資源需要200多個字節。延遲 TCB 的分配，當正常連接建立起來后再分配 TCB 則可以有效地減輕服務器資源的消耗。

使用防火墻
防火墻在確認了連接的有效性后，才向內部的服務器（Listener）發起SYN請求

詳解四次揮手斷連

TCP 的斷連，如下圖所示。

TCP 鏈接的關閉，通信雙方都可以先發起，我們暫且把先發起的一方看作 Client，從圖中看出，通信中 Client 和 Server 兩端的鏈接都是 ESTABLISHED 狀態，然后 Client 先主動發起了關閉鏈接請求，Client 向 Server 發送了一個 FIN 包，表示 Client 端已經沒有數據要發送了，然后 Client 進入了 FIN_WAIT_1 狀態。

Server 端收到 FIN 后，返回 ACK，然后進入 CLOSE_WAIT 狀態。此時 Server 屬于半關閉狀態，因為此時 Client 向 Server 方向已經不會發送數據了，可是 Server 向 Client 端可能還有數據要發送。

當 Server 端數據發送完畢后，Server 端會向 Client 端發送 FIN，表示 Server 端也沒有數據要發送了，此時 Server 進入 LAST_ACK 狀態，就等待 Client 的應答就可以關閉鏈接了。

Client 端收到 Server 端的 FIN 后，回復 ACK，然后進入 TIME_WAIT 狀態。TIME_WAIT 狀態下需要等待 2 倍的最大報文段生存時間，來保證鏈接的可靠關閉，之后才會進入 CLOSED 關閉狀態。而 Server 端收到 ACK 后直接就進入 CLOSED 狀態。

為什么需要等待 2 倍最大報文段生存時間之后再關閉鏈接，原因有兩個：

1. 保證 TCP 協議的全雙工連接能夠可靠關閉；
2. 保證這次連接的重復數據段從網絡中消失，防止端口被重用時可能產生數據混淆。

從這個交互流程可以看出，無論是建連還是斷鏈，都是需要在兩個方向上進行，只不過建連時，Server 端的 SYN 和 ACK 合并為一次發送，而斷鏈時，兩個方向上數據發送停止的時間可能不同，所以不能合并發送 FIN 和 ACK。這就是建連三次握手而斷鏈需要四次的原因。

另外回答斷鏈的問題時，可以提到實際應用中有可能遇到大量 Socket 處在 TIME_WAIT 或者 CLOSE_WAIT 狀態的問題。一般開啟 tcp_tw_reuse 和 tcp_tw_recycle 能夠加快 TIME-WAIT 的 Sockets 回收；而大量 CLOSE_WAIT 可能是被動關閉的一方存在代碼 bug，沒有正確關閉鏈接導致的。

• 為什么要等待 2MSL
  客戶端發送的第4次握手報文，服務器沒有收到。這時候服務器端會再次發送一個 FIN =1 的報文，而這個時候客戶端還處于 TIME_WAIT 狀態，所以可以再次發送確認消息。

如果有大量的連接，每次在連接、關閉時都要經歷三次握手、四次揮手，這很顯然會造成性能低下。因此，HTTP 有一種叫作 keepalive connections 的機制，它可以在傳輸數據后仍然保持連接，當客戶端需要再次獲取數據時，直接使用剛剛空閑下來的連接而無須再次握手。

• 為什么需要三次握手，兩次確認？
  為什么客戶端還要發送一次確認呢，主要是為了防止已失效的鏈接請求報文突然又傳到了服務器端，造成錯誤。比如：客戶端發送鏈接請求，因為網絡或者一些其它因素造成沒有在一定時間到達服務器端，所以客戶沒有收到確認。由于客戶端會重發一次鏈接請求，通過三次握手與服務器建立連接，但是這時上次的請求到達服務器端了，服務器會誤以為客戶端又發了一次新的鏈接請求，會向客戶端發送報文同意建立連接，但是客戶端已經建立連接了，就會放棄該報文，服務端沒有收到響應，也就不會建立連接了。

• 三次握手出現錯誤時的應對措施？
  第一次握手A發送SYN傳輸失敗，A,B都不會申請資源，連接失敗。如果一段時間內發出多個SYN連接請求，那么A只會接受它最后發送的那個SYN的SYN+ACK回應，忽略其他回應全部回應，B中多申請的資源也會釋放

  第二次握手B發送SYN+ACK傳輸失敗，A不會申請資源，B申請了資源，但收不到A的ACK，過一段時間釋放資源。如果是收到了多個A的SYN請求，B都會回復SYN+ACK，但A只會承認其中它最早發送的那個SYN的回應，并回復最后一次握手的ACK

  第三次握手ACK傳輸失敗，B沒有收到ACK，釋放資源，對于后序的A的傳輸數據返回RST(重置連接)。實際上B會因為沒有收到A的ACK會多次發送SYN+ACK，次數是可以設置的，如果最后還是沒有收到A的ACK，則釋放資源，對A的數據傳輸返回RST

TCP的三次握手與四次揮手理解及面試題（很全面）
三次握手與四次揮手面試問題
三次握手和四次揮手
計算機網絡：圖文解析TCP的三次握手、四次揮手