淺談網絡協議(一) 爲什麼要學網絡協議

最近在學習網易研究院雲技術部首席架構師劉超先生的趣談網絡協議,開一個系列記錄一下。

本系列文章是在原作的基礎上修正,並加以自己的見解進行二次編輯,在此特地說明

先看一段代碼

public function hello()
{
    echo 'Hello World';
}

這是一段PHP的代碼,當然即使你不是個PHPer,你也肯定能看懂這段代碼。但是,你不一定知道,這也是一種協議,是人類和計算機溝通的協議,只有通過協議,計算機才知道我們想讓它做什麼。

協議三要素

當然,這種協議更接近人類語言,機器不能直接讀懂,需要進行翻譯,翻譯的工作交給編譯器,也就是compile。

編譯

編譯的過程比較複雜,具體不細說,但是可以看出,計算機語言作爲程序控制一臺計算工作的協議,具備了協議的三個要素:

  • 語法,就是一段內容要符合一定的規則和格式,例如括號要成對,結束要用分號。
  • 語義,就是一段內容要代表某種意義,例如數字減數字是有意義的,數字減文本一般來說就沒有意義。
  • 順序,就是按照某種順序執行。

會了計算機語言,就能讓一臺計算機完成工作了。但是,想要讓互聯網世界的所有機器協同工作。就需要網絡協議。只有通過網絡協議,才能使一大片機器相互協作,共同完成一件事情。

打開瀏覽器,輸入購物網站的地址,瀏覽器會給你一個多彩的頁面。那麼瀏覽器是如何做到這件事情的?之所以能夠呈現多彩的頁面,是因爲它收到了一段來自 HTTP 協議的東西。拿百度舉例,HTTP協議格式就如下面這樣:

HTTP/1.1 200 OK
Date: Tue, 27 Mar 2018 18:00:00 GMT
Content-Type: text/html;charset=UTF-8
Content-Language:zh-ZN
--空行--
<!DOCTYPE html>
<html>
<head>
<base herf="https://www.baidu.com" />
<meta charset="utf-8" /><title>百度一下,你就知道</title>

看看上面的三要素。

首先,符合語法,只有按照上面那個格式來,瀏覽器才能識別。例如,上來是狀態,然後是首部,然後是內容。

第二,符合語義,就是要按照約定的意思來。例如,狀態200代表成功返回,如果不成功則返回404

第三,符合順序,一點瀏覽器,就是發送出一個HTTP請求,然後纔有上面一串返回的東西。

常用的網絡協議

https://www.baidu.com ,這是一個URL,瀏覽器只知道名字是"www.baidu.com", 但是不知道具體的地點,所以不知道應該如何訪問,於是它打開地址簿去查找。這個時候使用一般的地址簿協議DNS去查找,還可以使用另一種更加精準的地址簿查找協議HTTPDNS。

無論哪一種方法查找,最終都會得到這個地址: 183.232.231.173。這個是IP地址,是互聯網世界的門牌號。知道了目標地址,瀏覽器就開始打包它的請求,往往會使用 HTTP 協議;但是對於購物等請求,往往需要進行加密傳輸,因而會使用 HTTPS 協議。無論是什麼協議,裏面都會寫明"你要買什麼,買多少",這些信息都是放在協議中
購買

DNS、HTTP、HTTPS所在的層我們稱爲應用層。經過應用層封裝後,瀏覽器會將應用層的包交給下一層去完成,通過 socket 編程來實現。下一層是傳輸層。傳輸層有兩種協議,一種是無連接的協議UDP,一種是面向連接的協議TCP。對於支付來講,往往使用TCP協議。所謂面向連接就是,TCP會保證這個包能夠達到目的地。如果不能達到,就會重新發送,直到到達。

TCP 協議裏面會有兩個端口,一個是瀏覽器監聽的端口,這個是瀏覽器給予的。一個是服務器監聽的端口,這個是根據上層協議給予的,如果是HTTP協議,就是80,如果是HTTPS,就是443,以此類推。操作系統往往通過端口來判斷,它得到的包應該給哪個進程。在傳輸層中,端口的數據會被帶上。

傳輸層封裝完畢後,數據包繼續交給操作系統的網絡層。網絡層的協議是 IP 協議。在 IP 協議裏面會有源 IP 地址,即瀏覽器所在機器的 IP 地址和目標 IP 地址。

操作系統獲取目標 IP 地址之後,就開始想如何根據IP找到目標機器。操作系統往往會判斷,這個目標 IP 地址是內部地址,還是外部地址。如果是內部地址,從IP就能看出來,但是顯然一般網站服務器地址不在本地,而在遙遠的地方。

要去外部網絡,需要經過網關。而操作系統啓動的時候,就會被 DHCP 協議配置 IP 地址,以及默認的網關的 IP 地址 192.168.1.1。

操作系統如何將 IP 地址發給網關呢?在本地通信基本靠吼,於是操作系統大吼一聲,誰是 192.168.1.1 啊?網關會回答它,我就是,我的本地地址在村東頭。這個本地地址就是MAC地址,而大吼的那一聲是ARP協議。

地址解析協議,即ARP(Address Resolution Protocol),是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到網絡上的所有主機,並接收返回消息,以此確定目標的物理地址;收到返回消息後將該IP地址和物理地址存入本機ARP緩存中並保留一定時間,下次請求時直接查詢ARP緩存以節約資源。地址解析協議是建立在網絡中各個主機互相信任的基礎上的,網絡上的主機可以自主發送ARP應答消息,其他主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存;由此攻擊者就可以向某一主機發送僞ARP應答報文,使其發送的信息無法到達預期的主機或到達錯誤的主機,這就構成了一個ARP欺騙。ARP命令可用於查詢本機ARP緩存中IP地址和MAC地址的對應關係、添加或刪除靜態對應關係等。

OSI模型把網絡工作分爲七層,IP地址在OSI模型的第三層,MAC地址在第二層,彼此不直接打交道。在通過以太網發送IP數據包時,需要先封裝第三層(32位IP地址)、第二層(48位MAC地址)的報頭,但由於發送時只知道目標IP地址,不知道其MAC地址,又不能跨第二、三層,所以需要使用地址解析協議。使用地址解析協議,可根據網絡層IP數據包包頭中的IP地址信息解析出目標硬件地址(MAC地址)信息,以保證通信的順利進行。

於是操作系統將 IP 包交給了下一層,也就是MAC 層。網卡再將包發出去。由於這個包裏面是有 MAC 地址的,因而它能夠到達網關。

網關收到包之後,會根據自己的知識,判斷下一步應該怎麼走。網關往往是一個路由器,到某個 IP 地址應該怎麼走,這個叫作路由表。

外部網絡,即網關與網關之間是通過IP地址聯繫,而一個局域網內部,都可以使用本地的MAC地址進行通信。

網關往往是知道這些“知識”的,因爲網關和臨近的網關也會經常溝通。到哪裏應該怎麼走,這種溝通的協議稱爲路由協議,常用的有OSPF和BGP。

最後一個網關知道這個網絡包要去的地方。於是,通過ARP找到目標服務器的MAC地址,通過這個 MAC 地址就能找到目標服務器。

目標服務器發現 MAC 地址對上了,取下 MAC 頭來,發送給操作系統的網絡層。發現 IP 也對上了,就取下 IP 頭。IP 頭裏會寫上一層封裝的是 TCP 協議,然後將其交給傳輸層,即TCP 層。

在這一層裏,對於收到的每個包,都會有一個回覆的包說明收到了。這個回覆的包絕非這次下單請求的結果,例如購物是否成功,扣了多少錢等,而僅僅是 TCP 層的一個說明,即收到之後的回覆。當然這個回覆,會沿着剛纔來的方向走回去,表示已經收到數據包

如果過一段時間還是沒到,發送端的 TCP 層會重新發送這個包,還是上面的過程,直到有一天收到平安到達的回覆。這個重試絕非你的瀏覽器重新將下單這個動作重新請求一次。對於瀏覽器來講,就發送了一次下單請求,TCP 層不斷自己悶頭重試。除非 TCP 這一層出了問題,例如連接斷了,才輪到瀏覽器的應用層重新發送下單請求。

當網絡包平安到達 TCP 層之後,TCP 頭中有目標端口號,通過這個端口號,可以找到電商網站的進程正在監聽這個端口號,假設一個 nginx,由nginx將這個請求通過socket轉發給電商網站服務器。

電商網站的服務器的進程得到 HTTP 請求的內容,知道了要買東西,買多少。往往一個電商網站最初接待請求的這個 nginx 只是個接待員,負責統籌處理這個請求,而不是所有的事情都自己做。例如,這個接待員要告訴專門管理訂單的進程,登記要買某個商品,買多少,要告訴管理庫存的進程,庫存要減少多少,要告訴支付的進程,應該付多少錢,等等。

如何告訴相關的進程呢?往往通過 RPC 調用,即遠程過程調用的方式來實現。遠程過程調用就是當告訴管理訂單進程的時候,接待員不用關心中間的網絡互連問題,會由 RPC 框架統一處理。RPC 框架有很多種,有基於 HTTP 協議放在 HTTP 的報文裏面的,有直接封裝在 TCP 報文裏面的。

當接待員發現相應的部門都處理完畢,就回復一個 HTTPS 的包,告知下單成功。這個 HTTPS 的包,會像來的時候一樣,經過千難萬險到達你的個人電腦,最終進入瀏覽器,顯示支付成功。

小結 一個簡簡單單的下單過程,中間牽扯到這麼多的協議。而管理一大片機器,更是一件特別有技術含量的事情。除此之外,像最近比較火的雲計算、容器、微服務等技術,也都需要藉助各種協議,來達成大規模機器之間的合作。

這裏列一下之後要講的網絡協議,之後會按照從底層到上層的循序來更新講解。

問題:當網絡包到達一個城市城關的時候,可以直接通過路由得到達下一個城關的IP地址,直接通過IP地址找就可以了,爲什麼還要通過本地的MAC地址呢?

ip是網絡層使用的 mac是鏈路層使用的 ip包最終還是要通過物理鏈接和mac地址進行交互的

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章