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

網絡基礎 TCP / IP

  一般使用的網絡（包括互聯網）是在 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參考模型通訊過程

• 一、打包數據時，每一層在處理上一層傳過來的數據時，會在數據上附上當前層的首部信息後傳給下一層；
• 二、解包數據時，每一層在處理下一層傳過來的數據時，會將當前層的首部信息與數據分開，將數據傳給上一層。
• 三、數據通訊過程:

分層	每層的操做
應用層	在數據前面加首部，首部包括數據內容、源地址和目標地址，同時也會處理異常的反饋信息。
表示層	將特有的數據格式轉換爲通用的數據格式，同時也會加上表示層的首部信息以供解析。
會話層	對什麼時候鏈接，以何種方式鏈接，鏈接多久，什麼時候斷開等作記錄。同時也會加會話層的首部信息。
傳輸層	創建鏈接，斷開鏈接，確認數據是否發送成功和執行失敗重發任務。
網絡層	負責將數據發到目標地址，也包含首部信息。
數據鏈路層	經過物理的傳輸介質實現數據的傳輸。
物理層	將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:pass@www.example.jp: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通常都會分開發送，從而致使多了一次。

參考文章：

• 《圖解http》
• blog.csdn.net/qzcsu/artic…