要說我們接觸計算機網(wǎng)絡最多的協(xié)議，那勢必離不開 TCP/IP 協(xié)議了，TCP/IP 協(xié)議同時也是互聯(lián)網(wǎng)中最為著名的協(xié)議，下面我們就來一起聊一下 TCP/IP 協(xié)議。

TCP/IP 的歷史背景

最初還沒有 TCP/IP 協(xié)議的時候，也就是在 20 世紀 60 年代，許多國家和地區(qū)認識到通信技術的重要性。美國國防部希望能夠研究一種即使通信線路被破壞也能夠通過其他路線進行通信的技術。為了實現(xiàn)這種技術，出現(xiàn)了分組網(wǎng)絡。

即使在兩個節(jié)點通信的過程中，幾個節(jié)點遭到破壞，卻依然能夠通過改變線路等方式使兩個節(jié)點之間進行通信。

這種分組網(wǎng)絡促進了ARPANET(Advanced Research Projects Agency Network)的誕生。ARPANET 是第一個具有分布式控制的廣域包分組交換網(wǎng)絡，也是最早實現(xiàn) TCP/IP 協(xié)議的前身。

ARPANET 其實是由 美國國防部高級研究計劃局 計劃建立。

所以，計算機網(wǎng)絡的出現(xiàn)在最一開始是因為軍事研究目的。

20 世紀 90 年代，IOS 開展了 OSI 這一國際標準化的進程，然而卻沒有取得實質(zhì)性的進展，但是卻使 TCP/IP 協(xié)議得到了廣泛使用。

這種致使 TCP/IP 協(xié)議快速發(fā)展的原因可能是由于 TCP/IP 的標準化。也就是說 TCP/IP 協(xié)議中會涉及到 OSI 所沒有的標準，而這種標準將是我們接下來主要探討的內(nèi)容。

這里我們先來認識一下 TCP/IP 協(xié)議，TCP/IP 協(xié)議說的不僅僅只是 TCP 和 IP 這兩種協(xié)議，實際上，TCP/IP 指的是協(xié)議簇，協(xié)議簇是啥呢？簡單來說就是一系列協(xié)議的綜合，如果下次再問你 TCP/IP 協(xié)議有哪些的話，可以把下面這張圖甩給他

以上的協(xié)議匯總起來，就是 TCP/IP 協(xié)議簇。

TCP/IP 標準

TCP/IP 相較于其他協(xié)議的標準，更注重兩點：開放性和實用性，即標準化能否被實際使用。

開放性說的是 TCP/IP 是由IETF討論制定的，而 IETF 本身就是一個允許任何人加入進行討論的組織。

實用性說的是就拿框架來說，如果只浮于理論，而沒有落地的實踐，那么永遠成為不了主流。

TCP/IP 的標準協(xié)議就是我們所熟知的RFC 文檔，當然你可以在網(wǎng)絡上看到。RFC 不僅規(guī)范了協(xié)議標準，還包含了協(xié)議的實現(xiàn)和使用信息。

關于更多 RFC 協(xié)議，你可以看一下官方文檔 https://www.rfc-editor.org/rfc-index.html

這里我們不再詳細展開介紹了，我們這篇文章的重點要放在對 TCP/IP 的研究上。

TCP/IP 協(xié)議簇

下面我們就開始聊一聊 TCP/IP 協(xié)議簇。

TCP/IP 協(xié)議是我們程序員接觸最多的協(xié)議，OSI 模型共有七層，從下到上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、運輸層、會話層、表示層和應用層。但是這顯然是有些復雜的，所以在 TCP/IP 協(xié)議中，它們被簡化為了四個層次

下面我們從通信鏈路層開始介紹一下這些層以及與層之間的協(xié)議。

通信鏈路層

如果非要細分的話，通信鏈路層也可以分為物理層和數(shù)據(jù)鏈路層。

物理層

物理層是 TCP/IP 的最底層是負責傳輸?shù)挠布?，這種硬件就相當于是以太網(wǎng)或電話線路等物理層的設備。

數(shù)據(jù)鏈路層

另外一層是數(shù)據(jù)鏈路層，數(shù)據(jù)鏈路層位于物理層和網(wǎng)絡層中間，數(shù)據(jù)鏈路層定義了在單個鏈路上如何傳輸數(shù)據(jù)。

網(wǎng)絡層

網(wǎng)絡層主要使用IP協(xié)議，IP 協(xié)議基于 IP 地址轉發(fā)分包數(shù)據(jù)。

IP 協(xié)議的主要作用就是將分組數(shù)據(jù)包發(fā)送到目標主機

TCP/IP 分層中的互聯(lián)網(wǎng)層與傳輸層的功能通常由操作系統(tǒng)提供。

IP 還隱含著數(shù)據(jù)鏈路層的功能，通過 IP 協(xié)議，相互通信的主機之間不論經(jīng)過怎樣的底層數(shù)據(jù)鏈路，都能夠實現(xiàn)相互通信。

雖然 IP 也是一種分組交換協(xié)議，但是 IP 卻不具備重發(fā)機制。即使數(shù)據(jù)沒有到達另一端也不會進行重發(fā)，所以 IP 屬于非可靠性協(xié)議。

網(wǎng)絡層還有一種協(xié)議就是ICMP，因為 IP 在數(shù)據(jù)包的發(fā)送過程中可能會出現(xiàn)異常，當 IP 數(shù)據(jù)包因為異常而無法到達目標地址時，需要給發(fā)送端發(fā)送一個異常通知，ICMP 的主要功能就在于此了。鑒于此情況，ICMP 也可以被用來診斷網(wǎng)絡情況。

傳輸層

我們上面剛介紹完 TCP/IP 協(xié)議最重要的 IP 協(xié)議后，下面我們來介紹一下傳輸層協(xié)議，TCP 協(xié)議是傳輸層協(xié)議的一種。

傳輸層就好像高速公路一樣，連接兩個城市的道路。下面是互聯(lián)網(wǎng)的邏輯通道，你可以把它想象成為高速公路。

傳輸層最主要的功能就是讓應用層的應用程序之間完成通信和數(shù)據(jù)交換。在計算機內(nèi)部運行著很多應用程序，每個應用程序都對應一個端口號，我們一般使用端口號來區(qū)分這些應用程序。

傳輸層的協(xié)議主要分為面向有連接的協(xié)議 TCP 和面向無連接的協(xié)議 UDP

TCP

TCP 是一種可靠的協(xié)議，它能夠保證數(shù)據(jù)包的可靠性交付，TCP 能夠正確處理傳輸過程中的丟包、傳輸順序錯亂等異常情況。此外，TCP 還提供擁塞控制用于緩解網(wǎng)絡擁堵。

UDP

UDP 是一種不可靠的協(xié)議，它無法保證數(shù)據(jù)的可靠交付，相比 TCP ，UDP 不會檢查數(shù)據(jù)包是否到達、網(wǎng)絡是否阻塞等情況，但是 UDP 的效率比較高。

UDP 常用于分組數(shù)據(jù)較少或者廣播、多播等視頻通信和多媒體領域。

應用層

在 TCP/IP 協(xié)議簇中，將 OSI 標準模型中的會話層、表示層都歸為了應用層。應用層的架構大多屬于客戶端/服務端模型，提供服務的程序叫做服務端、接受服務的程序叫做客戶端。在這種架構中，服務端通常會提前部署到服務器上，等待客戶端的連接，從而提供服務。

數(shù)據(jù)包的發(fā)送歷程

下面我們來介紹一下一個數(shù)據(jù)包是如何經(jīng)過應用層、運輸層、網(wǎng)絡層和通信鏈路層把一個數(shù)據(jù)包發(fā)送給另外一個數(shù)據(jù)包的。

數(shù)據(jù)包結構

我們首先先來認識一下數(shù)據(jù)包的結構，這里 cxuan 只是給你簡單介紹一下，后面的文章會更加詳細的介紹。

在上面的每個分層中，都會對所發(fā)送的數(shù)據(jù)增加一個首部，這個首部中包含了該層必要的信息。每一層都會對數(shù)據(jù)進行處理并在數(shù)據(jù)包中附上這一層的必要信息。下面我們就來聊一聊數(shù)據(jù)包的發(fā)送過程。

數(shù)據(jù)包發(fā)送歷程

假設主機 A 和主機 B 進行通信，主機 A 想要向主機 B 發(fā)送一個數(shù)據(jù)包，都會經(jīng)歷哪些奇特的操作？

應用層的處理

主機 A 也就是用戶點擊了某個應用或者打開了一個聊天窗口輸入了cxuan，然后點擊了發(fā)送，那么這個 cxuan 就作為一個數(shù)據(jù)包遨游在了網(wǎng)絡中，等下還沒完呢，應用層還需要對這個數(shù)據(jù)包進行處理，包括字符編碼、格式化等等，這一層其實是 OSI 中表現(xiàn)層做的工作，只不過在 TCP/IP 協(xié)議中都歸為了應用層。

數(shù)據(jù)包在發(fā)送的那一刻建立 TCP 連接，這個連接相當于通道，在這之后其他數(shù)據(jù)包也會使用通道傳輸數(shù)據(jù)。

傳輸層的處理

為了描述信息能準確的到達另一方，我們使用 TCP 協(xié)議來進行描述。TCP 會根據(jù)應用的指示，負責建立連接、發(fā)送數(shù)據(jù)和斷開連接。

TCP 會在應用數(shù)據(jù)層的前端附加一個 TCP 首部字段，TCP 首部包含了源端口號和目的端口號，這兩個端口號用于表明數(shù)據(jù)包是從哪里發(fā)出的，需要發(fā)送到哪個應用程序上；TCP 首部還包含序號，用以表示該包中數(shù)據(jù)是發(fā)送端整個數(shù)據(jù)中第幾個字節(jié)的序列號；TCP 首部還包含校驗和，用于判斷數(shù)據(jù)是否損壞，隨后將 TCP 頭部附加在數(shù)據(jù)包的首部發(fā)送給 IP。

網(wǎng)絡層的處理

網(wǎng)絡層主要負責處理數(shù)據(jù)包的是 IP 協(xié)議，IP 協(xié)議將 TCP 傳過來的 TCP 首部和數(shù)據(jù)結合當作自己的數(shù)據(jù)，并在 TCP 首部的前端加上自己的 IP 首部。因此，IP 數(shù)據(jù)包后面會緊跟著 TCP 數(shù)據(jù)包，后面才是數(shù)據(jù)本身。IP 首部包含目的和源地址，緊隨在 IP 首部的還有用來判斷后面是 TCP 還是 UDP 的信息。

IP 包生成后，會由路由控制表判斷應該發(fā)送至哪個主機，IP 修飾后的數(shù)據(jù)包繼續(xù)向下發(fā)送給路由器或者網(wǎng)絡接口的驅動程序，從而實現(xiàn)真正的數(shù)據(jù)傳輸。

如果不知道目標主機的 IP 地址，可以利用ARP(Address Resolution Protocol)地址解析協(xié)議進行查找。

通信鏈路層的處理

經(jīng)由 IP 傳過來的數(shù)據(jù)包，以太網(wǎng)會給數(shù)據(jù)附上以太網(wǎng)首部并進行發(fā)送處理。以太網(wǎng)首部包含接收端的 MAC 地址、發(fā)送端的 MAC 地址以及標志以太網(wǎng)類型的以太網(wǎng)數(shù)據(jù)協(xié)議等。

下面是完整的處理過程和解析過程。

如上圖所示，左側是數(shù)據(jù)的發(fā)送處理過程，應用層的數(shù)據(jù)經(jīng)過層層處理后會變?yōu)榭梢园l(fā)送的數(shù)據(jù)包，經(jīng)過物理介質(zhì)發(fā)送至指定主機中。

數(shù)據(jù)包的接收流程是發(fā)送流程的逆序過程，數(shù)據(jù)包的解析同樣也會經(jīng)過下面這幾步。

通信鏈路的解析

目標主機收到數(shù)據(jù)包后，首先會從以太網(wǎng)的首部找到 MAC 地址判斷是否是發(fā)給自己的數(shù)據(jù)包，如果不是發(fā)給自己的數(shù)據(jù)包則會丟棄該數(shù)據(jù)包。

如果收到的數(shù)據(jù)包是發(fā)送給自己的，就會查找以太網(wǎng)類型判斷是哪種協(xié)議，如果是 IP 協(xié)議就會扔給 IP 協(xié)議進行處理，如果是ARP協(xié)議就會扔給 ARP 協(xié)議進行處理。如果協(xié)議類型是一種無法識別的協(xié)議，就會將該數(shù)據(jù)包直接丟棄。

網(wǎng)絡層的解析

經(jīng)過以太網(wǎng)處理后的數(shù)據(jù)包扔給網(wǎng)絡層進行處理，我們假設協(xié)議類型是 IP 協(xié)議，那么，在 IP 收到數(shù)據(jù)包后就會解析 IP 首部，判斷 IP 首部中的 IP 地址是否和自己的 IP 地址匹配，如果匹配則接收數(shù)據(jù)并判斷上一層協(xié)議是 TCP 還是 UDP；如果不匹配則直接丟棄。

注意：在路由轉發(fā)的過程中，有的時候 IP 地址并不是自己的，這個時候需要借助路由表協(xié)助處理。

傳輸層的處理

在傳輸層中，我們默認使用 TCP 協(xié)議，在 TCP 處理過程中，首先會計算一下校驗和，判斷數(shù)據(jù)是否被損壞。然后檢查是否按照序號接收數(shù)據(jù)，最后檢查端口號，確定具體是哪個應用程序。

數(shù)據(jù)被完整的識別后，會傳遞給由端口號識別的應用程序進行處理。

應用程序的處理

接收端指定的應用程序會處理發(fā)送方傳遞過來的數(shù)據(jù)，通過解碼等操作識別出數(shù)據(jù)的內(nèi)容，然后把對應的數(shù)據(jù)存儲在磁盤上，返回一個保存成功的消息給發(fā)送方，如果保存失敗，則返回錯誤消息。

上面是一個完整的數(shù)據(jù)包收發(fā)過程，在上面的數(shù)據(jù)收發(fā)過程中，涉及到不同層之間的地址、端口號、協(xié)議類型等，那么我們現(xiàn)在就來剖析一下。

數(shù)據(jù)包經(jīng)過每層后，該層協(xié)議都會在數(shù)據(jù)包附上包首部，一個完整的包首部圖如下所示

在數(shù)據(jù)包的發(fā)送過程中，各層依次對數(shù)據(jù)包添加了首部信息，每個首部都包含發(fā)送端和接收端地址以及上一層的協(xié)議類型。以太網(wǎng)會使用 MAC 地址、IP 會使用 IP 地址、TCP/UDP 則會用端口號作為識別兩端主機的地址。

此外，每個分層中的包首部還包含一個識別位，它是用來標識上一層協(xié)議的種類信息。

責任編輯：xj

原文標題：TCP/IP 基礎知識總結

文章出處：【微信公眾號：算法與數(shù)據(jù)結構】歡迎添加關注！文章轉載請注明出處。