ARP 協(xié)議（Address Resolution Protocol）一種以解析地址的協(xié)議，根據(jù)通信雙方的 IP 地址就可以查出對應(yīng)的 MAC 地址。
MAC（ Media Access Control Address）地址是指網(wǎng)卡所屬的固定的地址
MIME，多部分對象集合（Multipurpose Internet Mail Extensions，多用途因特網(wǎng)郵件擴展），它是一種允許處理文本、圖片、視頻等多種不同類型的數(shù)據(jù)。

第一章：了解 Web 及網(wǎng)絡(luò)基礎(chǔ)

在瀏覽器地址欄輸入 URL 時，可以看到 Web 頁面。當(dāng)然 Web 頁面是不能憑空顯示出來，它需要根據(jù)指定的 URL 到服務(wù)器獲取文件資源，然后讓瀏覽器顯示 Web 頁面。

Web 使用一種名為 HTTP 的協(xié)議作為規(guī)范。HTTP 全稱 HyperText Transfer Protocol，超文本傳輸協(xié)議。

網(wǎng)絡(luò)基礎(chǔ) TCP/IP

TCP/IP 協(xié)議族

什么是協(xié)議？
定義如何探測到通信目標(biāo)，由哪一方發(fā)起通信，使用什么語言通信，怎樣結(jié)束通信，不同的硬件、操作系統(tǒng)之間的通信的規(guī)則。

TCP/IP 是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的總稱，包括各式內(nèi)容，從電纜規(guī)格到 IP 地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序、以及 Web 頁面顯示需要處理的步驟等

TCP/IP 的分層管理

TCP/IP 協(xié)議族分為4層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層
作用:

• 應(yīng)用層：決定了向用戶提供應(yīng)用服務(wù)時通信的活動，HTTP 協(xié)議也處于該層
• 傳輸層：對上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺計算機之間的數(shù)據(jù)傳輸
• 網(wǎng)絡(luò)層：又名網(wǎng)絡(luò)互聯(lián)層，用來處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包
• 鏈路層：又名數(shù)據(jù)鏈路層、網(wǎng)絡(luò)接口層，用來處理連接網(wǎng)絡(luò)硬件部分（屬于硬件范圍）

TCP/IP 通信傳輸流

TCP/IP 通信傳輸流

利用 TCP/IP 協(xié)議族進行網(wǎng)絡(luò)通信時，發(fā)送端（客戶端）從應(yīng)用層往下走，接收端（服務(wù)端）從鏈路層網(wǎng)上走

用 HTTP 舉例：

1. 應(yīng)用層（發(fā)送端）發(fā)送 HTTP 請求
2. 傳輸層（TCP協(xié)議）把從應(yīng)用層接收到的數(shù)據(jù)（HTTP報文）進行分割，并在各個報文上打上標(biāo)記序號及端口號后發(fā)給網(wǎng)絡(luò)層
3. 在網(wǎng)絡(luò)層（IP協(xié)議）增加作為通信目的的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層（發(fā)往網(wǎng)絡(luò)的通信請求就準(zhǔn)備齊全了）

4. 接收端在鏈路層接收到數(shù)據(jù)，按序網(wǎng)上層發(fā)送，達到應(yīng)用層后，才能算真正接收到發(fā)送端發(fā)過來的請求

   
   
   image
   
   

   發(fā)送端在每層之間傳輸時，會打上該層所屬的首部信息；接收端在曾與層之間傳輸時，每經(jīng)過一層會刪除對應(yīng)的首部信息。
   這種把數(shù)據(jù)包轉(zhuǎn)起來的做法叫做封裝

與 HTTP 關(guān)系密切的協(xié)議：IP、TCP 和 DNS

負責(zé)傳輸?shù)?IP 協(xié)議

TCP/IP 協(xié)議族中的 IP 指的是網(wǎng)際協(xié)議。IP 協(xié)議的作用是把各種數(shù)據(jù)包傳送給對方，要保證確實傳送到對方哪里，需要滿足各類條件。其中兩個重要條件是 IP 地址和 MAC 地址（Media Access Control Address）。

IP 地址指明了節(jié)點被分配到的地址，MAC 地址是指網(wǎng)卡所屬的固定的地址。IP 地址可以和 MAC 地址進行配對。IP 地址可變換，MAC 地址基本不會變。

使用 ARP 協(xié)議憑借 MAC 地址進行通信

IP 間的通信依賴 MAC 地址。在網(wǎng)絡(luò)上，通常是經(jīng)過多臺計算機和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才能連接到對方，在中轉(zhuǎn)時，會利用下一站中轉(zhuǎn)設(shè)備的 MAC 地址來搜索下一個中轉(zhuǎn)目標(biāo)，這是會采用 ARP 協(xié)議
（Address Resolution Protocol）。ARP 協(xié)議是一種以解析地址的協(xié)議，根據(jù)通信雙方的 IP 地址就可以查出對應(yīng)的 MAC 地址。

image

確?？煽康?TCP 協(xié)議

TCP 協(xié)議位于傳輸層，提供可靠的字節(jié)流服務(wù)，所謂字節(jié)流服務(wù)是將大塊數(shù)據(jù)分割層以報文段為單位的數(shù)據(jù)包進行管理，方便傳輸。

為了確保準(zhǔn)確無誤的送達目的地，TCP 采用三次握手策略，數(shù)據(jù)發(fā)送出去之后，一定的會向?qū)Ψ酱_認是否成功送達。握手的過程中采用 TCP 的標(biāo)志——SYN（synchronize）和 ACK（acknowledgement）。

發(fā)送端首先發(fā)送一個帶 SYN 標(biāo)志的數(shù)據(jù)包給對方；接收端收到后，回傳一個帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包以示表達確認信息，最后發(fā)送端在回傳一個帶 ACK 標(biāo)志的數(shù)據(jù)包，代表握手結(jié)束。

如果某個階段莫名結(jié)束，TCP 協(xié)議會再次以相同順序發(fā)送相同的數(shù)據(jù)包。

image

負責(zé)域名解析的 DNS 服務(wù)

DNS（Domain Name System）服務(wù)是和 HTTP 協(xié)議一樣位于應(yīng)用層的協(xié)議。它提供域名到 IP 地址之間的解析服務(wù)。

用戶通常通過域名來訪問網(wǎng)站，相比于 IP 地址，域名更符合人類的記憶習(xí)慣。DNS 服務(wù)便應(yīng)運而生，逆向從 IP 地址反查域名服務(wù)。

各協(xié)議與 HTTP 協(xié)議的關(guān)系

image

URI 和 URL

URI（Uniform Resource Identifier）統(tǒng)一資源標(biāo)識符
URL（Uniform Resource Locator）統(tǒng)一資源定位符

image

• 登錄信息：指定用戶名和密碼作為服務(wù)器端獲取資源時必要的登錄信息（可選）
• 服務(wù)器地址：必須指定待訪問的服務(wù)器地址
• 服務(wù)器端口號：指定服務(wù)器連接的網(wǎng)絡(luò)端口號（可選，省略的話使用默認端口號）
• 帶層次的文件路徑：指定服務(wù)器上的文件路徑來定位特指的資源
• 查詢字符串：針對已指定的文件路徑內(nèi)的資源，可以使用查詢字符串傳入任意參數(shù)（可選）
• 片斷標(biāo)識符：使用片段標(biāo)識符通?？蓸?biāo)記出以獲取資源中的資資源（可選）

第二章：簡單的 HTTP 協(xié)議

請求訪問文本或圖像等資源的一端稱為客戶端，提供資源響應(yīng)的一端稱為服務(wù)器端。

HTTP 協(xié)議規(guī)定，請求從客戶端發(fā)出，服務(wù)端響應(yīng)該請求并返回。

請求報文是由請求方法、請求URI、協(xié)議版本、可選的請求首部字段和內(nèi)容實體構(gòu)成的。

image

響應(yīng)報文基本上由協(xié)議版本、狀態(tài)碼（表示成功或失敗的代碼）、以及解釋狀態(tài)碼的原因短語、可選的響應(yīng)首部字段以及實體主體構(gòu)成。

image

HTTP 不保存狀態(tài)協(xié)議

HTTP 是一種不保存狀態(tài)，即無狀態(tài)協(xié)議。它自身不具備保存之前發(fā)送過的請求或響應(yīng)的功能，為了實現(xiàn)保持狀態(tài)的功能，引入了 Cookie 技術(shù)。

告知服務(wù)器意圖的 HTTP 方法

向請求 URI 指定的資源發(fā)送請求報文時，采用稱為方法的命令。方法名要用大寫字母。

持久連接節(jié)省通信量

在 HTTP 初始版本中，由于傳輸數(shù)據(jù)容量比較小，每進行一次 HTTP 通信就要斷開一次 TCP 連接；
隨著 HTTP 普及，傳輸數(shù)據(jù)越來越大，未解決 TCP 連接問題，引入了持久連接（HTTP Persistent Connections，也成為 HTTP keep-alive 或 HTTP connection reuse），特點是：只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。

管線化

持久化連接是的多數(shù)請求以管線化方式發(fā)送稱為可能，可以同時并行發(fā)送多個請求，而不需要一個接一個等待響應(yīng)。

使用 Cookie 的狀態(tài)管理

Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)。
服務(wù)器在接受到請求后，在響應(yīng)報文內(nèi)加入 Set-Cookie，通知客戶端保存 Cookie，當(dāng)下次在發(fā)送請求時，會在請求報文中加入 Cookie 后發(fā)送出去。服務(wù)器在根據(jù)發(fā)送過來的 Cookie 去對比，從而保存狀態(tài)信息。

第三章：HTTP 報文內(nèi)的 HTTP 信息

用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報文，請求端（客戶端）的報文叫做請求報文，響應(yīng)端（服務(wù)端）的叫做響應(yīng)報文。

請求報文及響應(yīng)報文的結(jié)構(gòu)

HTTP 報文 大致可分為報文首部和報文主體，兩者之間由空行（CR+LF）來劃分。
請求報文

image

響應(yīng)報文

image

• 請求行：包含用于請求的方法，請求 URI 和 HTTP 版本
• 狀態(tài)行：包含表明響應(yīng)結(jié)果的狀態(tài)碼，原因短語和 HTTP 版本
• 首部字段：包含表明請求和響應(yīng)的各種條件和屬性的各類首部，一般有4種首部：通用首部、請求首部、響應(yīng)首部、實體首部
• 其他：可能包含 HTTP 的 RFC 里未定義 的首部，如：Cookie

編碼提升傳輸速率

HTTP 在傳輸數(shù)據(jù)時可以按照數(shù)據(jù)原貌直接傳輸，也可以在傳輸時通過編碼提升傳輸速率，但這樣會消耗更多的 CPU 等資源

報文主體和實體主體的差異

• 報文：是 HTTP 通信中的基本單位，由8位組字節(jié)流（octet sequence，其中 octet 為8個比特）組成，通過 HTTP 通信傳輸。
• 實體：作為請求或響應(yīng)的有效載荷數(shù)據(jù)（補充項）被傳輸，其內(nèi)容由實體首部和實體主體組成。

通常報文主體等于實體主體，只有當(dāng)傳輸中進行編碼操作時，實體主體的內(nèi)容發(fā)生變化才會導(dǎo)致它和報文主體產(chǎn)生差異。

壓縮傳輸?shù)膬?nèi)容編碼

內(nèi)容編碼指明應(yīng)用在實體內(nèi)容上的編碼格式，并保存實體信息原樣壓縮。內(nèi)容編碼后的實體由客戶端接收并負責(zé)編碼。

常用的內(nèi)容編碼

• gzip(GNU zip)
• compress(UNIX 系統(tǒng)的標(biāo)準(zhǔn)壓縮)
• deflate(zlib)
• identity(不進行編碼)

分割發(fā)送的分塊傳輸編碼

在 HTTP 通信過程中，在傳輸大容量數(shù)據(jù)時，通過把數(shù)據(jù)分割成多塊，能夠讓瀏覽器逐步顯示頁面的功能稱為分塊傳輸編碼（Chunked Transfer Coding）。

發(fā)送多種數(shù)據(jù)的多部分對象集合

HTTP 協(xié)議采用了多部分對象集合——MIME機制（Multipurpose Internet Mail Extensions，多用途因特網(wǎng)郵件擴展），它是一種允許處理文本、圖片、視頻等多種不同類型的數(shù)據(jù)。

在 HTTP 報文中使用 多部分對象集合時，需要在首部字段里加上 Content-type，使用 boundary 字符串來劃分各個實體的起始行，需要在起始行前插入 "--" 標(biāo)記，，最后以 "--" 結(jié)束。

獲取部分內(nèi)容的范圍請求

指定范圍發(fā)送的請求叫做范圍請求

執(zhí)行范圍請求會用到首部字段 Range 來指定資源的 byte 范圍

請求：
Range: bytes = 5001-10000

響應(yīng)：
Content-Range: bytes 5001-10000/10000

針對范圍請求，響應(yīng)會返回狀態(tài)碼為 206 Partial Content 的響應(yīng)報文，如果服務(wù)器無法響應(yīng)范圍請求，則會返回狀態(tài)碼 200 OK 和完成的實體內(nèi)容。

內(nèi)容協(xié)商返回最合適的內(nèi)容

同一個 Web 網(wǎng)站可能會存在多份相同內(nèi)容的頁面，比如英文版和中文版，當(dāng)瀏覽器默認語言為中文時，訪問 URI 的 Web 頁面時，則會顯示中文版的 Web 頁面，這種機制稱為內(nèi)容協(xié)商（Content Negotiation）。

內(nèi)容協(xié)商機制會在請求報文中用到下面首部字段：

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language

內(nèi)容協(xié)商技術(shù)有3種類型：

• 服務(wù)器驅(qū)動協(xié)商：由服務(wù)器端進行內(nèi)容協(xié)商。以請求的首部字段為參考，在服務(wù)端自動處理。
• 客戶端驅(qū)動協(xié)商：由客戶端進行內(nèi)容協(xié)商。用戶利用瀏覽器提供的可選項列表手動選擇；還可以利用 JavaScript 腳本在 Web 頁面上自動進行選擇。
• 透明協(xié)商：是服務(wù)器驅(qū)動和客戶端驅(qū)動的結(jié)合體，是由服務(wù)器端和客戶端各自進行內(nèi)容協(xié)商的一種方法。

第四章：返回結(jié)果的 HTTP 狀態(tài)碼

狀態(tài)碼告知從服務(wù)器端返回的請求結(jié)果

狀態(tài)碼的職責(zé)是當(dāng)客戶端向服務(wù)器端發(fā)送請求時，描述返回的請求結(jié)果。
狀態(tài)碼由三位數(shù)字和原因短語組成，其中數(shù)字第一位指定了相應(yīng)類別，后兩位無分類。

狀態(tài)碼

1. 2XX 成功：表示請求被正常處理了

• 200 OK 表示從客戶端發(fā)來的請求在服務(wù)器端被正常處理了。
• 204 No Content 請求處理成功，返回的響應(yīng)報文中不含實體的主體部分
• 206 Partial Content 表示客戶端進行范圍請求

2. 3XX 重定向：表明瀏覽器需要執(zhí)行某些特殊處理以正確處理請求

• 301 Moved Permanently 永久重定向
• 302 Found 臨時重定向
• 303 See Other 表示由于請求對應(yīng)的資源存在著另一個 URI，應(yīng)使用 GET 方法定向獲取請求的資源
• 304 Not Modified 表示客戶端發(fā)送附帶條件的請求，服務(wù)器端允許請求訪問資源，但因發(fā)生請求未滿足條件的情況后，直接返回 304 Not Modified。304 狀態(tài)碼返回時，不包含任何響應(yīng)的主體部分，304 雖然被劃分在 3XX 類別中，但和重定向沒有關(guān)系
• 307 Temporary Redirect 臨時重定向，和 302 差不多，它不會把 POST 變成 GET

3. 4XX 客戶端錯誤：表明客戶端發(fā)生錯誤的原因所在

• 400 Bad Request：表示請求報文中存在語法錯誤
• 401 Unauthorized：表示發(fā)送的請求需要有通過 HTTP 認證的認證信息
• 403 Forbidden：表示請求資源被服務(wù)器拒絕了
• 400 Not Found：表示服務(wù)器上無法找到請求資源

4. 5XX 服務(wù)器錯誤：表明服務(wù)器本身發(fā)生錯誤

• 500 Internal Server Error：表示服務(wù)器在執(zhí)行請求時發(fā)生了錯誤
• 503 Serveice Unavailable：表示服務(wù)器暫時處于超負荷或正在停機維護，無法處理請求。

第五章：與 HTTP 協(xié)作的 Web 服務(wù)器

HTTP/1.1 允許一臺 HTTP 服務(wù)器搭建多個 Web 站點
在互聯(lián)網(wǎng)上，域名通過 DNS 服務(wù)映射到 IP 地址之后訪問目標(biāo)網(wǎng)站，在相同 IP 下，發(fā)送 HTTP 請求時，必須在 Host 首部內(nèi)完整指定主機名和域名的 URI

通信數(shù)據(jù)轉(zhuǎn)發(fā)程序：代理、網(wǎng)關(guān)、隧道

• 代理：是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序，它扮演了位于服務(wù)器和客戶端“中間人”的角色
• 網(wǎng)關(guān)：網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器，接受從客戶端發(fā)來的請求時，它就像自己擁有資源的源服務(wù)器一樣對請求進行處理
• 隧道：相隔甚遠的客戶端和服務(wù)器兩者之間進行中轉(zhuǎn)，并保持雙方通信連接的應(yīng)用程序

代理

使用代理服務(wù)器的理由：利用緩存技術(shù)減少網(wǎng)絡(luò)帶寬的流量，組織內(nèi)部針對特定網(wǎng)站的訪問控制，以獲取訪問日志為主要目的

緩存代理：代理轉(zhuǎn)發(fā)時，緩存代理會預(yù)先將資源的副本緩存到代理服務(wù)器上，當(dāng)代理再次接收到相同資源的請求時，就可以不從源服務(wù)器那里獲取資源，而是將緩存的資源作為響應(yīng)返回

透明代理：轉(zhuǎn)發(fā)請求或響應(yīng)時，不對報文做任何加工的代理類型稱為透明代理

網(wǎng)關(guān)：

網(wǎng)關(guān)能使通信線路上的服務(wù)器提供非 HTTP 協(xié)議服務(wù)。
利用網(wǎng)關(guān)能提高通信的安全性

隧道

隧道的目的是確?？蛻舳四芘c服務(wù)器進行安全的通信，隧道本身不會去解析 HTTP 請求，隧道會在通信雙方斷開連接時結(jié)束

保存資源的緩存

緩存是指代理服務(wù)器或客戶端本地磁盤內(nèi)保存的資源副本。利用緩存可減少對源服務(wù)器的訪問，因此也節(jié)省了通信流量和通信時間。

緩存的有效期

緩存服務(wù)器內(nèi)緩存室友有效期的，如果資源更新，緩存就沒有用了，需要重新獲取新的資源
客戶端的緩存同緩存服務(wù)器一樣

第六章：HTTP 首部

HTTP 協(xié)議的請求和響應(yīng)報文中必須必定包含 HTTP 首部。首部內(nèi)容為請求或響應(yīng)所需要的信息

HTTP 請求報文由方法、URI、HTTP 版本、HTTP 首部字段等部分構(gòu)成
HTTP 響應(yīng)報文由 HTTP 版本、狀態(tài)碼、HTTP 首部字段組成

HTTP 首部字段

HTTP 首部字段是構(gòu)成 HTTP 報文的要素之一。使用首部字段是為了給瀏覽器和服務(wù)器提供報文主體大小、所使用的語言、認證信息等內(nèi)容。

4種 HTTP 首部字段類型

• 通用首部字段：請求報文和響應(yīng)報文都會使用的首部
• 請求首部字段：從客戶端向服務(wù)器端發(fā)送請求報文時使用的首部
• 響應(yīng)首部字段：從服務(wù)器端向客戶端返回響應(yīng)報文時使用的首部
• 實體首部字段：針對請求報文和響應(yīng)報文的實體部分使用的首部

通用首部字段

請求首部字段

響應(yīng)首部字段

實體首部字段

第七章：確保 Web 安全的 HTTPS

HTTP的缺點：

• 通信使用明文（不加密），內(nèi)容可能會被竊聽
• 不驗證通信方的身份，因此有可能遭遇偽裝
• 無法證明報文的完整性，所以有可能已遭篡改

通信的加密
HTTP 和 SSL（Secure Socket Layer，安全套連接）或 TLS（Transport Layer Security，安全傳輸層協(xié)議）組合使用，被稱為 HTTPS（HTTP Secure，超文本傳輸安全協(xié)議）

內(nèi)容的加密
把 HTTP 報文里所含的內(nèi)容進行加密，前提需要客戶端和服務(wù)器同時具備加密和解密機制

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

未完待續(xù)...