【網絡基礎全家桶】OSI七層、TCP/IP四層、TCP協議（三次握手、四次分手）

OSI七層模型、TCP/IP四層模型

參考：一文讀懂OSI七層模型與TCP/IP四層的區別/聯繫

OSI七層模型

開放式系統互聯（Open System Interconnect，OSI）定義了網絡互連的七層框架（物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層），即ISO開放互連繫統參考模型。

每一層實現各自的功能和協議，並完成與相鄰層的接口通信。

TCP/IP四層模型

OSI參考模型 是學術上和法律上的國際標準，是完整的權威的網絡參考模型。
TCP/IP參考模型 是事實上的國際標準，即現實生活中被廣泛使用的網絡參考模型。

對比 OSI、TCP/IP

（簡圖）

OSI七層網絡模型	TCP/IP四層概念模型	對應網絡協議
應用層（Application）	應用層	HTTP, TFTP, FTP, NFS, WAIS、 SMTP
表示層（Presentation）		Telnet, Rlogin, SNMP, Gopher
會話層（Session）		SMTP, DNS
傳輸層（Transport）	傳輸層	進程和端口 TCP, UDP, DCCP, SCTP, RTP, RSVP 數據的單位成爲數據段 （Segment）
網絡層（Network layer）	網絡層	路由器，防火牆 IP, ICMP, ARP, RARP, AKP, UUCP 數據的單位稱爲數據包（packet）
數據鏈路層（Data Link Layer）	數據鏈路層	網橋，交換機 FDDI, Ethernet, Arpanet, PDN, SLIP, PPP 數據的單位稱爲幀（frame）
物理層（Physical Layer）		網卡，網線，集線器，中繼器，調制解調器 IEEE 802.1A, IEEE 802.2到IEEE 802.11 數據的單位稱爲比特（bit）

（全面）

TCP協議

參考：TCP三次握手詳解及釋放連接過程

（TCP報文結構）

# 三次握手

（流程圖）

• 客戶端 發送連接請求報文段
  將同步序號（Synchronize Sequence Numbers，SYN）標識設爲1
  將序號（Sequence Number，seq）置爲x（x爲隨機產生的一個值）
  然後 進入SYN_SEND狀態 （同步發送狀態）
  

• 服務器 收到SYN報文段進行確認
  將SYN標識位置爲1
  確認序號（Acknowledgment Number，ACK）標識置爲1
  （當ACK=1時，確認字段纔有效。當ACK=0時，確認號無效。）
  序號（Sequence Number，seq）置爲y（y爲隨機產生的一個值）
  確認序號（Acknowledgment Number，ack）置爲x+1
  然後 進入SYN_RECV狀態（同步接收狀態，半連接狀態）
  

• 客戶端 再進行一次確認
  確認序號（Acknowledgment Number，ACK）標識置爲1（此時不用SYN）
  確認序號（Acknowledgment Number，ack）置爲y+1
  序號（Sequence Number，seq）置爲x+1（此時不用SYN）
  發向服務器
  最後客戶端與服務器都進入 ESTABLISHED 狀態 （建立連接狀態）
  

爲什麼在第3步中客戶端還要再進行一次確認呢？
這主要是爲了防止已經失效的連接請求報文段突然又傳回到服務端而產生錯誤的場景：
.

• 所謂"已失效的連接請求報文段"是這樣產生的。
  正常來說，客戶端發出連接請求，但因爲連接請求報文丟失而未收到確認。
  於是客戶端再次發出一次連接請求，後來收到了確認，建立了連接。
  數據傳輸完畢後，釋放了連接，客戶端一共發送了兩個連接請求報文段，其中第一個丟失，第二個到達了服務端，沒有"已失效的連接請求報文段"。
  .
• 現在假定一種異常情況，即客戶端發出的第一個連接請求報文段並沒有丟失，只是在某些網絡節點長時間滯留了，以至於延誤到連接釋放以後的某個時間點纔到達服務端。本來這個連接請求已經失效了，但是服務端收到此失效的連接請求報文段後，就誤認爲這是客戶端又發出了一次新的連接請求。於是服務端又向客戶端發出請求報文段，同意建立連接。假定不採用三次握手，那麼只要服務端發出確認，連接就建立了。
  .
• 由於現在客戶端並沒有發出連接建立的請求，因此不會理會服務端的確認，也不會向服務端發送數據，但是服務端卻以爲新的傳輸連接已經建立了，並一直等待客戶端發來數據，這樣服務端的許多資源就這樣白白浪費了。
  .

採用三次握手的辦法可以防止上述現象的發生。比如在上述的場景下，客戶端不向服務端的發出確認請求，服務端由於收不到確認，就知道客戶端並沒有要求建立連接。

# 四次分手

當客戶端沒有數據再需要發送給服務端時，就需要釋放客戶端的連接，這整個過程爲：

• 客戶端 發送一個報文給服務端（沒有數據）
  其中FIN設置爲1
  序號（Sequence Number，seq）置爲u（隨機）
  客戶端進入 FIN_WAIT_1狀態
  

• 服務端 收到來自客戶端的請求（會做兩件事）

1. 發送一個ACK給客戶端
   ACK置爲1
   確認序號（Acknowledgment Number，ACK）置爲u+1
   Sequence Number爲v
   服務端年進入 CLOSE_WAIT狀態 （等待關閉連接狀態）
   

2. 發送一個FIN給客戶端
   FIN置爲1
   ACK置爲1
   Sequence置爲w
   Acknowledge置爲u+1
   用來關閉服務端到客戶端的數據傳送
   服務端進入 LAST_ACK狀態 （最後一次確認狀態）
   

• 客戶端 收到FIN後，進入TIME_WAIT狀態
  接着發送一個ACK給服務端
  Acknowledge置爲w+1
  Sequence Number置爲u+1
  最後客戶端和服務端都進入 CLOSED狀態
  

# Wireshark 分析數據傳輸過程

參考：Understanding TCP Sequence and Acknowledgment Numbers（扶牆）

看有什麼時候有時間，或者看哪位大大把它翻譯過來把