網絡協議 一、計算機網絡體系結構 二、地址和端口號 二、TCP概述

一、計算機網絡體系結構

1.1、OSI七層模型

開放系統互連參考模型 (Open System Interconnect 簡稱OSI）是國際標準化組織(ISO)和國際電報電話諮詢委員會(CCITT)聯合制定的開放系統互連參考模型，爲開放式互連信息系統提供了一種功能結構的框架。其目的是爲異種計算機互連提供一個共同的基礎和標準框架，併爲保持相關標準的一致性和兼容性提供共同的參考。這裏所說的開放系統，實質上指的是遵循OSI參考模型和相關協議能夠實現互連的具有各種應用目的的計算機系統。

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

1.2、TCP/IP模型

OSI模型比較複雜且學術化，所以我們實際使用的TCP/IP模型，共分4層，鏈路層、網絡層、傳輸層、應用層。

• 兩個模型之間的對應關係如圖所示：

1.3、TCP/IP協議族

Transmission Control Protocol/Internet Protocol的簡寫，中譯名爲傳輸控制協議/因特網互聯協議，是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。協議採用了4層的層級結構。然而在很多情況下，它是利用 IP 進行通信時所必須用到的協議羣的統稱。也就是說，它其實是個協議家族，由很多個協議組成，並且是在不同的層， 是互聯網的基礎通信架構。

1.4、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 模塊中，首先會計算一下校驗和，判斷數據是否被破壞。然後檢查是否在按照序號接收數據。最後檢查端口號，確定具體的應用程序。數據被完整地接收以後，會傳給由端口號識別的應用程序。

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

• 包：是全能性術語；
• 幀：用於表示數據鏈路層中包的單位；
• 片：是 IP中數據的單位；
• 段：則表示 TCP 數據流中的信息；
• 消息：是指應用協議中數據的單位。

1.5、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 反向地址轉化協議

二、地址和端口號

2.1、MAC 地址

MAC地址全稱叫做媒體訪問控制地址，也稱爲局域網地址（LAN Address），MAC位址，以太網地址（Ethernet Address）或物理地址（Physical Address），由網絡設備製造商生產時寫在硬件內部。MAC地址與網絡無關，也即無論將帶有這個地址的硬件（如網卡、集線器、路由器等）接入到網絡的何處，都有相同的MAC地址，它由廠商寫在網卡的BIOS裏，從理論上講，除非盜來硬件（網卡），否則是沒有辦法冒名頂替的。

MAC地址共48位（6個字節）。前24位由IEEE（電氣和電子工程師協會）決定如何分配，後24位由實際生產該網絡設備的廠商自行制定。例如：FF:FF:FF:FF:FF:FF或FF-FF-FF-FF-FF-FF

2.2、IP地址

P地址（Internet Protocol Address）的全稱叫作互聯網協議地址，它的本義是爲互聯網上的每一個網絡和每一臺主機配置一個唯一的邏輯地址，用來與物理地址作區分。
所以IP 地址用來識別 TCP/IP 網絡中互連的主機和路由器。IP地址基於邏輯，比較靈活，不受硬件限制，也容易記憶。
IP地址分爲：IPv4和IPv6。我們這裏着重講的是IPv4地址，IP地址是由32位的二進制數組成，它們通常被分爲4個“8位二進制數”，我們可以把它理解爲4個字節，格式表示爲：（A.B.C.D）。其中，A，B，C，D這四個英文字母表示爲0-255的十進制的整數。例：192.168.1.1。

2.3、IP地址和MAC地址之間的區別

• 1、對於網絡中的一些設備，路由器或者是PC及而言，IP地址的設計是出於拓撲設計出來的，只要在不重複IP地址的情況下，它是可以隨意更改的；而MAC地址是根據生產廠商燒錄好的，它一般不能改動的，一般來說，當一臺PC機的網卡壞了之後，更換了網卡之後MAC地址就會變了。
• 2、在前面的介紹裏面，它們最明顯的區別就是長度不同，IP地址的長度爲32位，而MAC地址爲48位。
• 3、它們的尋址協議層不同。IP地址應用於OSI模型的網絡層，而MAC地址應用在OSI模型的數據鏈路層。 數據鏈路層協議可以使數據從一個節點傳遞到相同鏈路的另一個節點上（通過MAC地址），而網絡層協議使數據可以從一個網絡傳遞到另一個網絡上（ARP根據目的IP地址，找到中間節點的MAC地址，通過中間節點傳送，從而最終到達目的網絡）。
• 4、分配依據不同。IP地址的分配是基於我們自身定義的網絡拓撲，MAC地址的分配是基於製造商。

2.4、端口號

用來識別同一臺計算機中進行通信的不同應用程序。因此，它也被稱爲程序地址。

端口號的確定

• 標準既定的端口號：這種方法也叫靜態方法。它是指每個應用程序都有其指定的端口號。但並不是說可以隨意使用任何一個端口號。例如 HTTP、FTP、TELNET 等廣爲使用的應用協議中所使用的端口號就是固定的。這些端口號被稱爲知名端口號，分佈在 0~1023 之間；除知名端口號之外，還有一些端口號被正式註冊，它們分佈在 1024~49151 之間，不過這些端口號可用於任何通信用途。
• 時序分配法：服務器有必要確定監聽端口號，以讓客戶端程序訪問服務器上的服務。但是使用服務的客戶端沒必要確定端口號。在這種方法下，客戶端應用程序完全可以不用自己設置端口號，而全權交給操作系統進行分配。動態分配的端口號範圍在 49152~65535 之間。

綜述

所以一般來說，不管計算機中有多少網卡，每個網卡都會有自己的MAC 地址，這個MAC 地址是不會變化的。而每個網卡在正常工作的情況下，都會有一個IP地址，這個IP地址完全是可以變化的。而這臺計算機中承載的各種應用程序可以擁有自己的端口號，然後通過服務器的網卡，正確地進行網絡通信。
所以通過源IP地址、目標IP地址、協議號（協議類型）、源端口號以及目標端口號這五個元素唯一性的識別一個網絡上的通信。

二、TCP概述

TCP（Transmission Control Protocol）是面向連接的通信協議，通過三次握手建立連接，然後才能開始數據的讀寫，通訊完成時要拆除連接，由於TCP是面向連接的所以只能用於端到端的通訊。

TCP提供的是一種可靠的數據流服務，數據有可能被拆分後發送，那麼採用超時重傳機制是和應答確認機制是組成TCP可靠傳輸的關鍵設計。
而超時重傳機制中最最重要的就是重傳超時（RTO，Retransmission TimeOut）的時間選擇，很明顯，在工程上和現實中網絡環境是十分複雜多變的，有時候可能突然的抽風，有時候可能突然的又很順暢。在數據發送的過程中，如果用一個固定的值一直作爲超時計時器的時長是非常不經濟也非常不準確的方法，這樣的話，超時的時長就需要根據網絡情況動態調整，就需要採樣統計一個數據包從發送端發送出去到接收到這個包的回覆這段時長來動態設置重傳超時值，這個時長就是爲RTT，學名往返時延，round-trip time，然後再根據這個RTT通過各種算法和公式平滑RTT值後，最終確定重傳超時值。
而IP層進行數據傳輸時，是不能保證數據包按照發送的順序達到目的機器。當IP將把它們向‘上’傳送到TCP層後，TCP將包排序並進行錯誤檢查。TCP數據包中包括序號和確認，所以未按照順序收到的包可以被排序，而損壞的包可以被重傳。

TCP還採用一種稱爲滑動窗口的方式進行流量控制，所謂窗口實際表示接收能力，用以限制發送方的發送速度。

同時TCP還允許在一個TCP連接上，通信的雙方可以同時傳輸數據，也就是所謂的全雙工。

面向連接的服務（例如Telnet、FTP、rlogin、X Windows和SMTP）需要高度的可靠性，所以它們使用了TCP。DNS在某些情況下使用TCP（發送和接收域名數據庫），但使用UDP傳送有關單個主機的信息。

2.1、TCP 的基本特性

• 面向連接
• 可靠性
• RTT 和 RTO
• 數據排序
• 流量控制
• 全雙工

2.2、TCP三次握手

• SYN ： 請求報文
• seq : 系列號（隨機數），鏈接之後傳輸數據在這個序列號基礎上增加值進行校驗。
• ACK : 應答信號
• ack : seq + 1

建立一個TCP連接時，需要客戶端和服務
端總共發送3個包以確認連接的建立。

• 第一次 握手
  客戶端請求建立連接。
• 第二次握手
  服務端應答客戶端，並請求建立連接。
• 第三次握手
  客戶端針對服務端請求確認應答

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狀態，完成三次握手，隨後客戶端與服務器端之間可以開始傳輸數據了。

2.2.1、爲什麼TCP握手需要三次?

TCP是可靠的傳輸控制協議，而三次握手是保證數據可靠傳輸又能提高傳輸效率的最小次數。爲什麼？RFC793，也就是TCP的協議RFC中就談到了原因，這是因爲：

爲了實現可靠數據傳輸，TCP協議的通信雙方，都必須維護一個序列號， 以標識發送出去的數據包中，哪些是已經被對方收到的。
舉例說明：發送方在發送數據包（假設大小爲 10 byte）時， 同時送上一個序號( 假設爲 500)，那麼接收方收到這個數據包以後， 就可以回覆一個確認號（510 = 500 + 10） 告訴發送方 “我已經收到了你的數據包， 你可以發送下一個數據包， 序號從 511 開始” 。

三次握手的過程即是通信雙方相互告知序列號起始值，並確認對方已經收到了序列號起始值的必經步驟。
如果只是兩次握手， 至多隻有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認。
至於爲什麼不是四次，很明顯，三次握手後，通信的雙方都已經知道了對方序列號起始值，也確認了對方知道自己序列號起始值，第四次握手已經毫無必要了。

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

• 定義
  通過網絡服務所在的端口發送大量僞造原地址的攻擊報文，發送到服務端，造成服務端上的半開連接隊列被佔滿，從而阻
  止其他用戶進行訪問。

• 原理
  攻擊者客戶端利用僞造的IP地址向服務端發出請求(第一次握手)，而服務端的響應(第二次握手)的報文將永遠發送不到真實的客戶端，服務端在等待客戶端的第三次握手(永遠都不會有的)，服務端在等待這種半開的連接過程中消耗了資源，如果有成千上萬的這種連接，主機資源將被耗盡，從而達到攻擊的目的。會造成服務器死機。

面對這種攻擊，有以下的解決方案，最好的方案是防火牆。

• 解決方案

• 1、無效連接監視釋放
  這種方法不停監視所有的連接，包括三次握手的，還有握手一次的，反正是所有的，當達到一定(與)閾值時拆除這些連接，從而釋放系統資源。這種方法對於所有的連接一視同仁，不管是正常的還是攻擊的，所以這種方式不推薦。

• 2、延緩TCB分配方法
  一般的做完第一次握手之後，服務器就需要爲該請求分配一個TCB（連接控制資源），通常這個資源需要200多個字節。延遲TCB的分配，當正常連接建立起來後再分配TCB則可以有效地減輕服務器資源的消耗。

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

2.3、TCP中的四次揮手

斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發。

由於TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當甲方完成數據發送任務後，發送一個FIN給乙方來終止這一方向的連接，乙方收到一個FIN只是意味着不會再收到甲方數據了，但是乙方依然可以給甲方發送數據，直到這乙方也發送了FIN給甲方。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉。

由此可見，TCP建立一個連接需3個分節，終止一個連接則需4個分節。

• (1)某個應用進程首先調用close，我們稱該端執行主動關閉（active close)。該端的TCP於是發送一個FIN分節，表示數據發送完畢，應用進程進入FIN-WAIT-1（終止等待1）狀態。

• (2）接收到這個FIN的對端執行被動關閉(passive close)，發出確認報文。這個FIN由TCP確認。因爲FIN的接收意味着接收端應用進程在相應連接上再無額外數據可接收。接收端進入了CLOSE-WAIT（關閉等待）狀態，這時候處於半關閉狀態，即主動關閉端已經沒有數據要發送了，但是被動關閉端若發送數據，主動關閉端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAI狀態持續的時間。主動關閉端收到確認報文後進入FIN-WAIT-2（終止等待2）狀態。

• (3)一段時間後，被動關閉的應用進程將調用close關閉它的套接字。這導致它的TCP也發送一個FIN。

• (4)接收這個最終FIN的原發送端TCP（即執行主動關閉的那一端）確認這個FIN發出一個確認ACK報文，並進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗MSL（最長報文段壽命/最長分節生命期 max segement lifetime，MSL是任何IP數據報能夠在因特網中存活的最長時間，任何TCP實現都必須爲MSL選擇一個值。RFC 1122[Braden 1989]的建議值是2分鐘，不過源自Berkelcy的實現傳統上改用30秒這個值。這意味着TIME_WAIT狀態的持續時間在1分鐘到4分鐘之間）的時間後，當主動關閉端撤銷相應的TCB（傳輸控制塊）後，才進入CLOSED狀態。

• (5) 被動關閉端只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，被動關閉端結束TCP連接的時間要比主動關閉端早一些。

既然每個方向都需要一個FIN和一個ACK，因此通常需要4個分節。我們使用限定詞“通常”是因爲：某些情形下步驟1的FIN隨數據一起發送;另外，步驟2和步驟3發送的分節都出自執行被動關閉那-一端，有可能被合併成一個分節。

簡化過程

• 第一次揮手：客戶端發送關閉請求
• 第二次揮手：服務端響應客戶端關閉請求
• 第三次揮手：服務端發送關閉請求
• 第四次揮手：客戶端發送關閉確認請求

2.3.1、爲什麼TCP的揮手需要四次？

TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接。

所以對全雙工模式來說，爲了徹底關閉，就需要通信兩端的4次交互。

2.3.2、爲什麼需要TIME-WAIT狀態？

TIME_WAIT狀態存在的原因有兩點

• 1、可靠的終止TCP連接。
• 2、保證讓遲來的TCP報文有足夠的時間被識別並丟棄。

根據前面的四次握手的描述，我們知道，客戶端收到服務器的連接釋放的FIN報文後，必鬚髮出確認。如最後這個ACK確認報文丟失，那麼服務器沒有收到這個ACK確認報文，就要重發FIN連接釋放報文，客戶端要在某個狀態等待這個FIN連接釋放報文段然後回覆確認報文段，這樣才能可靠的終止TCP連接。

在Linux系統上，一個TCP端口不能被同時打開多次，當一個TCP連接處於TIME_WAIT狀態時，我們無法使用該鏈接的端口來建立一個新連接。反過來思考，如果不存在TIME_WAIT狀態，則應用程序能過立即建立一個和剛關閉的連接相似的連接（這裏的相似，是指他們具有相同的IP地址和端口號）。這個新的、和原來相似的連接被稱爲原來連接的化身。新的化身可能受到屬於原來連接攜帶應用程序數據的TCP報文段（遲到的報文段），這顯然是不該發生的。這是TIME_WAIT狀態存在的第二個原因。

https://zhuanlan.zhihu.com/p/199284611?utm_source=wechat_session