1. 程式人生 > >圖解HTTP之——網路基礎

圖解HTTP之——網路基礎

1、網路基礎TCP/IP

      為了理解HTTP,我們應該先了解一下TCP/IP協議族。

      通常使用的網路(包括網際網路)是在TCP/IP協議族的基礎上運作的,而HTTP屬於它內部的一個子集。

1.1、TCP/IP協議族

               計算機與網路裝置要相互通訊, 雙方就必須基於相同的方法。 比如,如何探測到通訊目標、 由哪一邊先發起通訊、 使用哪種語言進行通訊、 怎樣結束通訊等規則都需要事先確定。 不同的硬體、 作業系統之間的通訊, 所有的這一切都需要一種規則。 而我們就把這種規則稱為協議(protocol) 。

                   圖:TCP/IP 是網際網路相關的各類協議族的總稱

 把網際網路相關的協議集合起來總稱為TCP/IP。也有的認為TCP/IP是指TCP與IP兩種協議,另一種認為是通訊過程中使用到協議的總稱。

1.2、TCP/IP的分層管理   

TCP/IP 協議族裡重要的一點就是分層。 TCP/IP 協議族按層次分別分為以下 4 層: 應用層、 傳輸層、 網路層和資料鏈路層。 
    把 TCP/IP 層次化是有好處的。 比如, 如果網際網路只由一個協議統籌, 某個地方需要改變設計時, 就必須把所有部分整體替換掉。 而分層之後只需把變動的層替換掉即可。 把各層之間的介面部分規劃好之後, 每個層次內部的設計就能夠自由改動了。

TCP/IP 協議族各層的作用如下。

應用層
   應用層決定了向用戶提供應用服務時通訊的活動。TCP/IP 協議族內預存了各類通用的應用服務。 比如, FTP(FileTransfer Protocol, 檔案傳輸協議) 和 DNS(Domain Name System, 域名系統) 服務就是其中兩類。HTTP 協議也處於該層。

傳輸層
    傳輸層對上層應用層, 提供處於網路連線中的兩臺計算機之間的資料傳輸。 
在傳輸層有兩個性質不同的協議: TCP(Transmission ControlProtocol, 傳輸控制協議) 和 UDP(User Data Protocol, 使用者資料報協議) 。 

網路層(又名網路互連層)
    網路層用來處理在網路上流動的資料包。 資料包是網路傳輸的最小資料單位。 該層規定了通過怎樣的路徑(所謂的傳輸路線) 到達對方計算機, 並把資料包傳送給對方。 

鏈路層(又名資料鏈路層, 網路介面層)
    用來處理連線網路的硬體部分。 包括控制作業系統、 硬體的裝置驅動、 NIC(Network Interface Card, 網路介面卡, 即網絡卡) , 及光纖等物理可見部分(還包括聯結器等一切傳輸媒介) 。 硬體上的範疇均在鏈路層的作用範圍之內。

1.3、TCP/IP通訊傳輸流

      利用 TCP/IP 協議族進行網路通訊時, 會通過分層順序與對方進行通訊。 傳送端從應用層往下走, 接收端則往應用層往上走。       

    我們用 HTTP 舉例來說明, 首先作為傳送端的客戶端在應用層(HTTP 協議) 發出一個想看某個 Web 頁面的 HTTP 請求。

    接著, 為了傳輸方便, 在傳輸層(TCP 協議) 把從應用層處收到的資料(HTTP 請求報文) 進行分割, 並在各個報文上打上標記序號及埠號後轉發給網路層。

     在網路層(IP 協議) , 增加作為通訊目的地的 MAC 地址後轉發給鏈路層。 這樣一來, 發往網路的通訊請求就準備齊全了。

     接收端的伺服器在鏈路層接收到資料, 按序往上層傳送, 一直到應用層。 當傳輸到應用層, 才能算真正接收到由客戶端傳送過來的 HTTP請求。 

傳送端在層與層之間傳輸資料時,沒經過一層必會被打上一個該層所屬的頭部資訊,反之,接收端在層與層傳輸資料時,每經過一層時會把對應的首部資訊消去。

    這種把資料資訊包裝多久起來的做法成為封裝。

2、與HTTP關係密切的協議:IP、TCP和DNS

2.1 負責傳輸的IP協議

按層次分,IP(Internet Protocol)網際協議位於網路層。Internet Protocol 這個名稱可能聽起來有點誇張,但事實正是如此,因為幾乎所有使用網路的系統都會用到 IP 協議。TCP/IP 協議族中的 IP 指的就是網際協議,協議名稱中佔據了一半位置,其重要性可見一斑。可能有人會把“IP”和“IP 地址”搞混,“IP”其實是一種協議的名稱。

IP 協議的作用是把各種資料包傳送給對方。而要保證確實傳送到對方那裡,則需要滿足各類條件。其中兩個重要的條件是 IP 地址和 MAC 地址(Media Access Control Address)。

IP 地址指明瞭節點被分配到的地址,MAC 地址是指網絡卡所屬的固定地址。IP 地址可以和 MAC 地址進行配對。IP 地址可變換,但 MAC 地址基本上不會更改。

使用 ARP 協議憑藉 MAC 地址進行通訊

IP 間的通訊依賴 MAC 地址。在網路上,通訊的雙方在同一區域網(LAN)內的情況是很少的,通常是經過多臺計算機和網路裝置中轉才能連線到對方。而在進行中轉時,會利用下一站中轉裝置的 MAC 地址來搜尋下一個中轉目標。這時,會採用 ARP 協議(Address Resolution Protocol)。ARP 是一種用以解析地址的協議,根據通訊方的 IP 地址就可以反查出對應的 MAC 地址。

沒有人能夠全面掌握網際網路中的傳輸狀況

在到達通訊目標前的中轉過程中,那些計算機和路由器等網路裝置只能獲悉很粗略的傳輸路線。

這種機制稱為路由選擇(routing),有點像快遞公司的送貨過程。想要寄快遞的人,只要將自己的貨物送到集散中心,就可以知道快遞公司是否肯收件發貨,該快遞公司的集散中心檢查貨物的送達地址,明確下站該送往哪個區域的集散中心。接著,那個區域的集散中心自會判斷是否能送到對方的家中。

我們是想通過這個比喻說明,無論哪臺計算機、哪臺網路裝置,它們都無法全面掌握網際網路中的細節。

2.2、確保可靠性的 TCP 協議

按層次分,TCP 位於傳輸層,提供可靠的位元組流服務。

所謂的位元組流服務(Byte Stream Service)是指,為了方便傳輸,將大塊資料分割成以報文段(segment)為單位的資料包進行管理。而可靠的傳輸服務是指,能夠把資料準確可靠地傳給對方。一言以蔽之,TCP 協議為了更容易傳送大資料才把資料分割,而且 TCP 協議能夠確認資料最終是否送達到對方。

確保資料能到達目標

為了準確無誤地將資料送達目標處,TCP 協議採用了三次握手(three-way handshaking)策略。用 TCP 協議把資料包送出去後,TCP 不會對傳送後的情況置之不理,它一定會向對方確認是否成功送達。握手過程中使用了 TCP 的標誌(flag) —— SYN(synchronize) 和 ACK(acknowledgement)。

傳送端首先發送一個帶 SYN 標誌的資料包給對方。接收端收到後,回傳一個帶有 SYN/ACK 標誌的資料包以示傳達確認資訊。最後,傳送端再回傳一個帶 ACK 標誌的資料包,代表“握手”結束。

若在握手過程中某個階段莫名中斷,TCP 協議會再次以相同的順序傳送相同的資料包。

除了上述三次握手,TCP 協議還有其他各種手段來保證通訊的可靠性。

3、負責域名解析的DNS服務

DNS(Domain Name System)服務是和 HTTP 協議一樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。

計算機既可以被賦予 IP 地址,也可以被賦予主機名和域名。比如 www.hackr.jp

使用者通常使用主機名或域名來訪問對方的計算機,而不是直接通過 IP 地址訪問。因為與 IP 地址的一組純數字相比,用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。

但要讓計算機去理解名稱,相對而言就變得困難了。因為計算機更擅長處理一長串數字。

為了解決上述的問題,DNS 服務應運而生。DNS 協議提供通過域名查詢 IP 地址,或逆向從 IP 地址反查域名的服務。

 

4、各種協議與HTTP協議的關係

學習了和 HTTP 協議密不可分的 TCP/IP 協議族中的各種協議後,我們再通過這張圖來了解下 IP 協議、TCP 協議和 DNS 服務在使用 HTTP 協議的通訊過程中各自發揮了哪些作用。

5、URI和URL

與 URI(統一資源識別符號)相比,我們更熟悉 URL(Uniform Resource Locator,統一資源定位符)。URL 正是使用 Web 瀏覽器等訪問 Web 頁面時需要輸入的網頁地址。比如,下圖的 http://hackr.jp/ 就是 URL。

5.1 統一資源識別符號

URI 是 Uniform Resource Identifier 的縮寫。RFC2396 分別對這 3 個單詞進行了如下定義。

Uniform

規定統一的格式可方便處理多種不同型別的資源,而不用根據上下文環境來識別資源指定的訪問方式。另外,加入新增的協議方案(如 http: 或 ftp:)也更容易。

Resource

資源的定義是“可標識的任何東西”。不僅是文件檔案、影象或服務(例如當天的天氣預報)等能夠區別於其他型別的,全都可作為資源。另外,資源不僅可以是單一的,也可以是多數的集合體。

Identifier

表示可標識的物件。也稱為識別符號。

綜上所述,URI 就是由某個協議方案表示的資源的定位識別符號。協議方案是指訪問資源所使用的協議型別名稱。

採用 HTTP 協議時,協議方案就是 http。除此之外,還有 ftp、mailto、telnet、file 等。標準的 URI 協議方案有 30 種左右,由隸屬於國際網際網路資源管理的非營利社團 ICANN(Internet Corporation for Assigned Names and Numbers,網際網路名稱與數字地址分配機構)的 IANA(Internet Assigned Numbers Authority,網際網路號碼分配局)管理頒佈。

URI 用字串標識某一網際網路資源,而 URL 表示資源的地點(網際網路上所處的位置)。可見 URL 是 URI 的子集。

“RFC3986:統一資源識別符號(URI)通用語法”中列舉了幾種 URI 例子,如下所示。

ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:[email protected]
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2

本書接下來的章節中會頻繁出現 URI 這個術語,在充分理解的基礎上,也可用 URL 替換 URI。

5.2 URI 格式

表示指定的 URI,要使用涵蓋全部必要資訊的絕對 URI、絕對 URL 以及相對 URL。相對 URL,是指從瀏覽器中基本 URI 處指定的 URL,形如 /image/logo.gif。

讓我們先來了解一下絕對 URI 的格式。

使用 http: 或 https: 等協議方案名獲取訪問資源時要指定協議型別。不區分字母大小寫,最後附一個冒號(:)。

也可使用 data: 或 javascript: 這類指定資料或指令碼程式的方案名。

登入資訊(認證)

指定使用者名稱和密碼作為從伺服器端獲取資源時必要的登入資訊(身份認證)。此項是可選項。

伺服器地址

使用絕對 URI 必須指定待訪問的伺服器地址。地址可以是類似 hackr.jp 這種 DNS 可解析的名稱,或是 192.168.1.1 這類 IPv4 地址 名,還可以是 [0:0:0:0:0:0:0:1] 這樣用方括號括起來的 IPv6 地址名。

伺服器埠號

指定伺服器連線的網路埠號。此項也是可選項,若使用者省略則自動使用預設埠號。

帶層次的檔案路徑

指定伺服器上的檔案路徑來定位特指的資源。這與 UNIX 系統的檔案目錄結構相似。

查詢字串

針對已指定的檔案路徑內的資源,可以使用查詢字串傳入任意引數。此項可選。

片段識別符號

使用片段識別符號通常可標記出已獲取資源中的子資源(文件內的某個位置)。但在 RFC 中並沒有明確規定其使用方法。該項也為可選項。

並不是所有的應用程式都符合 RFC

有一些用來制定 HTTP 協議技術標準的文件,它們被稱為 RFC(Request for Comments,徵求修正意見書)。

通常,應用程式會遵照由 RFC 確定的標準實現。可以說,RFC 是網際網路的設計文件,要是不按照 RFC 標準執行,就有可能導致無法通訊的狀況。比如,有一臺 Web 伺服器內的應用服務沒有遵照 RFC 的標準實現,那 Web 瀏覽器就很可能無法訪問這臺伺服器了。

由於不遵照 RFC 標準實現就無法進行 HTTP 協議通訊,所以基本上客戶端和伺服器端都會以 RFC 為標準來實現 HTTP 協議。但也存在某些應用程式因客戶端或伺服器端的不同,而未遵照 RFC 標準,反而將自成一套的“標準”擴充套件的情況。

不按 RFC 標準來實現,當然也不必勞心費力讓自己的“標準”符合其他所有的客戶端和伺服器端。但設想一下,如果這款應用程式的使用者非常多,那會發生什麼情況?不難想象,其他的客戶端或伺服器端必然都不得不去配合它。

實際在網際網路上,已經實現了 HTTP 協議的一些伺服器端和客戶端裡就存在上述情況。說不定它們會與本書介紹的 HTTP 協議的實現情況不一樣。

本書接下來要介紹的 HTTP 協議內容,除去部分例外,基本上都以 RFC 的標準為準。