《圖解http》閱讀筆記--web及網路基礎

摘要： 通常使用的網路（包括網際網路）是在 TCP / IP 協議族的基礎上運作的，而 HTTP 屬於它內部的一個子集。Web 使用一種名為 HTTP（HyperText Transfer Protocol，超文字傳輸協議）的協議作為規範，完成從客戶端（指通過傳送請求獲取伺服器資源的 Web 瀏覽器...

通常使用的網路（包括網際網路）是在 TCP / IP 協議族的基礎上運作的，而 HTTP 屬於它內部的一個子集。Web 使用一種名為 HTTP（HyperText Transfer Protocol，超文字傳輸協議）的協議作為規範，完成從客戶端（指通過傳送請求獲取伺服器資源的 Web 瀏覽器等）到伺服器端等一系列運作流程，而協議是指規則的約定。可以說，Web 是建立在 HTTP 協議上通訊的。

協議

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

TCP / IP 協議族

像這樣把與網際網路相關聯的協議集合起來總稱為 TCP / IP，如 HTTP、FTP、DNS、TCP 都為 TCP / IP 協議集合下的協議。

OSI與TCP/IP分層模型

TCP / IP 協議族裡最重要的一點就是分層，分層的好處是隻需把各層之間的介面部分規劃好，每個層次的內部設計就能自由改動，而不會影響到整體。TCP / IP 協議族按層次分別為以下四層：

• 應用層，決定了向用戶提供應用服務時通訊的活動。 TCP / IP 協議族內預存了各類通用的應用服務，比如，FTP（File Transfer Protocol，檔案傳輸協議）和 DNS（Domain Name System，域名系統）服務就是其中兩類，HTTP 協議也處於該層；
• 傳輸層，對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸。 在傳輸層有兩個性質不同的協議：TCP（Transmission Control Protocol，傳輸控制協議）和 UDP（User Data Protocol，使用者資料報協議）；
• 網路層（又名網路互連層），用來處理在網路上流動的資料包。 資料包是網路傳輸的最小資料單位，該層規定了通過怎樣的路徑（所謂的傳輸路線）到達物件計算機，並把資料包傳送給對方。與對方計算機之間通過多臺計算機或網路裝置進行傳輸時，網路層起的作用就是在眾多的選項內選擇一條傳輸路線；
• 資料鏈路層（又名資料鏈路層，網路介面層），用來處理連線網路的硬體部分. 包括控制作業系統、硬體的裝置驅動、NIC（Network Interface Card，網路介面卡，即網絡卡），及光纖等物理可見部分（還包括聯結器等一切傳輸媒介）。硬體上的範疇均在鏈路層的作用範圍之內。

TCP / IP 通訊傳輸流

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

1. 首先作為傳送端的客戶端在應用層（HTTP 協議）發出一個想看某個 Web 頁面的 HTTP 請求；
2. 接著，為了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的資料（HTTP 請求報文）進行分割，並在各個報文上打上標記序號及埠號後轉發給網路層；
3. 在網路層（IP 協議），增加作為通訊目的地的 MAC 地址後轉發給鏈路層；
4. 這樣一來，發往網路的通訊請求就準備齊全了。接收端的伺服器在鏈路層接收到資料，按序往上層傳送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端傳送過來的 HTTP請求。

傳送端在層與層之間傳輸資料時，每經過一層時必定會被打上一個該層所屬的首部資訊。反之，接收端在層與層傳輸資料時，每經過一層時會把對應的首部消去。這種把資料資訊包裝起來的做法稱為封裝（encapsulate）。

OSI參考模型分層說明

OSI參考模型通訊過程

• 1、打包資料時，每一層在處理上一層傳過來的資料時，會在資料上附上當前層的首部資訊後傳給下一層；
• 2、解包資料時，每一層在處理下一層傳過來的資料時，會將當前層的首部資訊與資料分開，將資料傳給上一層。
• 3、資料通訊過程:

分層	每層的操作
應用層	在資料前面加首部，首部包括資料內容、源地址和目標地址，同時也會處理異常的反饋資訊。
表示層	將特有的資料格式轉換為通用的資料格式，同時也會加上表示層的首部資訊以供解析。
會話層	對何時連線，以何種方式連線，連線多久，何時斷開等做記錄。同時也會加會話層的首部資訊。
傳輸層	建立連線，斷開連線，確認資料是否傳送成功和執行失敗重發任務。
網路層	負責將資料發到目標地址，也包含首部資訊。
資料鏈路層	通過物理的傳輸介質實現資料的傳輸。
物理層	將0/1轉換成物理的傳輸介質，通過MAC地址進行傳輸。

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

• 負責傳輸的 IP 協議，通過 IP 地址和 MAC 地址將資料送往對方。 按層次分，IP（Internet Protocol）網際協議位於網路層。TCP / IP 協議族中的 IP 指的是網際協議，是一種協議的名稱。IP 協議的作用是把各種資料包傳送給對方。而要保證確實傳送到對方那裡，則需要滿足各類條件。其中兩個重要的條件是 IP 地址和 MAC 地址（Media Access Control Address）。IP 地址指明瞭節點被分配到的地址，MAC 地址是指網絡卡所屬的固定地址。IP 地址可以和 MAC 地址進行配對。IP 地址可變換，但 MAC 地址基本上不會更改。在網路上，通訊的雙方通常是經過多臺計算機和網路裝置中轉才能連線到對方。而在進行中轉時，會利用下一站中轉裝置的 MAC 地址來搜尋下一個中轉目標。這時，會採用 ARP 協議（Address Resolution Protocol），一種用以解析地址的協議，根據通訊方的 IP 地址就可以反查出對應的 MAC 地址。在到達通訊目標前的中轉過程中，那些計算機和路由器等網路裝置只能獲悉很粗略的傳輸路線，這種機制稱為路由選擇（routing）；

• 確保可靠性的 TCP 協議，使用了三次握手策略確保資料傳送成功。 按層次分，TCP 位於傳輸層，提供可靠的位元組流服務。所謂的位元組流服務（Byte Stream Service）是指，為了方便傳輸，將大塊資料分割成以報文段（segment）為單位的資料包進行管理。而可靠的傳輸服務是指，能夠把資料準確可靠地傳給對方。即 TCP 協議為了更容易傳送大資料才把資料分割，而且 TCP 協議採用三次握手策略。

簡單示意圖：

1. 客戶端–傳送帶有 SYN 標誌的資料包–一次握手–服務端
2. 服務端–傳送帶有 SYN/ACK 標誌的資料包–二次握手–客戶端
3. 客戶端–傳送帶有帶有 ACK 標誌的資料包–三次握手–服務端

• 四次揮手

  

  斷開一個 TCP 連線則需要“四次揮手”：

1. 客戶端-傳送一個 FIN，用來關閉客戶端到伺服器的資料傳送
2. 伺服器-收到這個 FIN，它發回一 個 ACK，確認序號為收到的序號加1 。和 SYN 一樣，一個 FIN 將佔用一個序號
3. 伺服器-關閉與客戶端的連線，傳送一個FIN給客戶端
4. 客戶端-發回 ACK 報文確認，並將確認序號設定為收到序號加1

• 負責域名解析的 DNS 服務，提供域名到 IP 地址之間的解析服務。 DNS（Domain Name System）服務是和 HTTP 協議一樣位於應用層的協議，它提供域名到 IP 地址之間的解析服務。計算機既可以被賦予 IP 地址，也可以被賦予主機名和域名。使用者通常使用主機名或域名來訪問對方的計算機，DNS 協議提供通過域名查詢 IP 地址，傳送給計算機的是 IP 地址。計算機可通過 DNS 協議的逆向從 IP 地址反查域名。

概括下請求響應的流程：

1. 客戶端發起請求，想訪問某個主機名或域名；
2. DNS 協議對主機名或域名進行解析，得到 IP 地址；
3. HTTP 協議將請求報文分割成多個報文段來發送；
4. IP 協議通過 IP 地址和 MAC 地址將資料送往對方；
5. TCP 協議使用三次握手策略確保資料傳送成功，按序號以原來的順序重組請求報文；
6. 服務端獲得請求報文，進行處理，處理結果同樣使用 TCP / IP 協議進行回傳。

URI 和 URL

URL（Uniform Resource Locator，統一資源定位符），使用 Web 瀏覽器等訪問 Web 頁面時需要輸入的網頁地址，比如www.google.com/ 。URI 是 Uniform Resource Identifier 的縮寫，這三個單詞分別表示：

• Uniform，規定統一的格式可方便處理多種不同型別的資源，而不用根據上下文環境來識別資源指定的訪問方式。另外，加入新增的協議方案（如 http: 或 ftp:）也更容易；
• Resource，資源的定義是“可標識的任何東西”。除了文件檔案、影象或服務（例如當天的天氣預報）等能夠區別於其他型別的，全都可作為資源。另外，資源不僅可以是單一的，也可以是多數的集合體；
• Identifier，表示可標識的物件。也稱為識別符號；

綜上所述，URI 就是由某個協議方案表示的資源的定位識別符號。協議方案是指訪問資源所使用的協議型別名稱。採用 HTTP 協議時，協議方案就是 http。URI 用字串標識某一網際網路資源，而 URL表示資源的地點（網際網路上所處的位置），可見 URL是 URI 的子集。

絕對URI 格式

以 “ user:[email protected]:80/dir/index.h… 為例：

• "http://" ，協議方案名。使用 http: 或 https: 等協議方案名獲取訪問資源時要指定協議型別。不區分字母大小寫，最後附一個冒號（:）。也可使用 data: 或 javascript: 這類指定資料或指令碼程式的方案名；
• "user:pass" ，登入資訊（認證）。指定使用者名稱和密碼作為從伺服器端獲取資源時必要的登入資訊（身份認證），此項是可選項；
• "www.example.jp" ，伺服器地址。使用絕對 URI 必須指定待訪問的伺服器地址。地址可以是類似 hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 地址名，還可以是 [0:0:0:0:0:0:0:1] 這樣用方括號括起來的 IPv6 地址名；
• "80"，伺服器埠號。指定伺服器連線的網路埠號。此項也是可選項，若使用者省略則自動使用預設埠號；
• "dir/index.html"，帶層次的檔案路徑。指定伺服器上的檔案路徑來定位特指的資源。這與 UNIX 系統的檔案目錄結構相似；
• "uid=1"，查詢字串。針對已指定的檔案路徑內的資源，可以使用查詢字串傳入任意引數，此項可選；
• "ch1"，使用片段識別符號通常可標記出已獲取資源中的子資源（文件內的某個位置）。但在 RFC 中並沒有明確規定其使用方法，該項也為可選項。

常見的面試題

TCP三次握手

為什麼要三次握手？

三次握手的目的是建立可靠的通訊通道，說到通訊，簡單來說就是資料的傳送與接收，而三次握手最主要的目的就是雙方確認自己與對方的傳送與接收是正常的。

• 第一次握手：Client 什麼都不能確認；Server 確認了對方傳送正常
• 第二次握手：Client 確認了：自己傳送、接收正常，對方傳送、接收正常；Server 確認了：自己接收正常，對方傳送正常
• 第三次握手：Client 確認了：自己傳送、接收正常，對方傳送、接收正常；Server 確認了：自己傳送、接收正常，對方傳送、接收正常

所以三次握手就能確認雙發收發功能都正常，缺一不可。、

為什麼要傳回 SYN?

接收端傳回傳送端所傳送的 SYN 是為了告訴傳送端，我接收到的資訊確實就是你所傳送的訊號了。 SYN 是 TCP/IP 建立連線時使用的握手訊號。在客戶機和伺服器之間建立正常的 TCP 網路連線時，客戶機首先發出一個 SYN 訊息，伺服器使用 SYN-ACK 應答表示接收到了這個訊息，最後客戶機再以 ACK(Acknowledgement[漢譯：確認字元 ,在資料通訊傳輸中，接收站發給傳送站的一種傳輸控制字元。它表示確認發來的資料已經接受無誤。 ]）訊息響應。這樣在客戶機和伺服器之間才能建立起可靠的TCP連線，資料才可以在客戶機和伺服器之間傳遞。

為什麼TCP客戶端最後還要傳送一次確認呢？

一句話，主要防止已經失效的連線請求報文突然又傳送到了伺服器，從而產生錯誤。

• 如果使用的是兩次握手建立連線，假設有這樣一種場景，客戶端傳送了第一個請求連線並且沒有丟失，只是因為在網路結點中滯留的時間太長了，由於TCP的客戶端遲遲沒有收到確認報文，以為伺服器沒有收到，此時重新向伺服器傳送這條報文，此後客戶端和伺服器經過兩次握手完成連線，傳輸資料，然後關閉連線。此時此前滯留的那一次請求連線，網路通暢了到達了伺服器，這個報文字該是失效的，但是，兩次握手的機制將會讓客戶端和伺服器再次建立連線，這將導致不必要的錯誤和資源的浪費。
• 如果採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文並且回覆了確認報文，但是客戶端不會再次發出確認。由於伺服器收不到確認，就知道客戶端並沒有請求連線。

四次揮手

為什麼要四次揮手?

任何一方都可以在資料傳送結束後發出連線釋放的通知，待對方確認後進入半關閉狀態。當另一方也沒有資料再發送的時候，則發出連線釋放通知，對方確認後就完全關閉了TCP連線。

舉個例子：A 和 B 打電話，通話即將結束後，A 說“我沒啥要說的了”，B回答“我知道了”，但是 B 可能還會有要說的話，A 不能要求 B 跟著自己的節奏結束通話，於是 B 可能又巴拉巴拉說了一通，最後 B 說“我說完了”，A 回答“知道了”，這樣通話才算結束。

為什麼客戶端最後還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設定不同的MSL值。

1. 第一，保證客戶端傳送的最後一個ACK報文能夠到達伺服器，因為這個ACK報文可能丟失，站在伺服器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我傳送的請求斷開報文它沒有收到，於是伺服器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出迴應報文，並且會重啟2MSL計時器。

2. 第二，防止類似與“三次握手”中提到了的“已經失效的連線請求報文段”出現在本連線中。客戶端傳送完最後一個確認報文後，在這個2MSL時間中，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣新的連線中不會出現舊連線的請求報文。

為什麼建立連線是三次握手，關閉連線確是四次揮手呢？

建立連線的時候， 伺服器在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給客戶端。 而關閉連線時，伺服器收到對方的FIN報文時，僅僅表示對方不再發送資料了但是還能接收資料，而自己也未必全部資料都發送給對方了，所以己方可以立即關閉，也可以傳送一些資料給對方後，再發送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次。