[[322727]]

HTTP 和 HTTPS 的區(qū)別

HTTP 是一種 超文本傳輸協(xié)議(Hypertext Transfer Protocol)，HTTP 是一個(gè)在計(jì)算機(jī)世界里專(zhuān)門(mén)在兩點(diǎn)之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范。

 

HTTP 主要內(nèi)容分為三部分，超文本(Hypertext)、傳輸(Transfer)、協(xié)議(Protocol)。

• 超文本就是不單單只是本文，它還可以傳輸圖片、音頻、視頻，甚至點(diǎn)擊文字或圖片能夠進(jìn)行超鏈接的跳轉(zhuǎn)。
• 上面這些概念可以統(tǒng)稱(chēng)為數(shù)據(jù)，傳輸就是數(shù)據(jù)需要經(jīng)過(guò)一系列的物理介質(zhì)從一個(gè)端系統(tǒng)傳送到另外一個(gè)端系統(tǒng)的過(guò)程。通常我們把傳輸數(shù)據(jù)包的一方稱(chēng)為請(qǐng)求方，把接到二進(jìn)制數(shù)據(jù)包的一方稱(chēng)為應(yīng)答方。
• 而協(xié)議指的就是是網(wǎng)絡(luò)中(包括互聯(lián)網(wǎng))傳遞、管理信息的一些規(guī)范。如同人與人之間相互交流是需要遵循一定的規(guī)矩一樣，計(jì)算機(jī)之間的相互通信需要共同遵守一定的規(guī)則，這些規(guī)則就稱(chēng)為協(xié)議，只不過(guò)是網(wǎng)絡(luò)協(xié)議。

說(shuō)到 HTTP，不得不提的就是 TCP/IP 網(wǎng)絡(luò)模型，一般是五層模型。如下圖所示：

但是也可以分為四層，就是把鏈路層和物理層都表示為網(wǎng)絡(luò)接口層：

還有一種就是 OSI 七層網(wǎng)絡(luò)模型，它就是在五層協(xié)議之上加了表示層和會(huì)話(huà)層：

而 HTTPS 的全稱(chēng)是 Hypertext Transfer Protocol Secure，從名稱(chēng)我們可以看出 HTTPS 要比 HTTPS 多了 secure 安全性這個(gè)概念，實(shí)際上， HTTPS 并不是一個(gè)新的應(yīng)用層協(xié)議，它其實(shí)就是 HTTP + TLS/SSL 協(xié)議組合而成，而安全性的保證正是 TLS/SSL 所做的工作。

也就是說(shuō)，HTTPS 就是身披了一層 SSL 的 HTTP。

那么，HTTP 和 HTTPS 的主要區(qū)別是什么呢?

• 最簡(jiǎn)單的，HTTP 在地址欄上的協(xié)議是以 http:// 開(kāi)頭，而 HTTPS 在地址欄上的協(xié)議是以 https:// 開(kāi)頭

http://www.cxuanblog.com/ 
https://www.cxuanblog.com/ 

• HTTP 是未經(jīng)安全加密的協(xié)議，它的傳輸過(guò)程容易被攻擊者監(jiān)聽(tīng)、數(shù)據(jù)容易被竊取、發(fā)送方和接收方容易被偽造;而 HTTPS 是安全的協(xié)議，它通過(guò) 密鑰交換算法 - 簽名算法 - 對(duì)稱(chēng)加密算法 - 摘要算法 能夠解決上面這些問(wèn)題。



• HTTP 的默認(rèn)端口是 80，而 HTTPS 的默認(rèn)端口是 443。

HTTP Get 和 Post 區(qū)別

HTTP 中包括許多方法，Get 和 Post 是 HTTP 中最常用的兩個(gè)方法，基本上使用 HTTP 方法中有 99% 都是在使用 Get 方法和 Post 方法，所以有必要我們對(duì)這兩個(gè)方法有更加深刻的認(rèn)識(shí)。

get 方法一般用于請(qǐng)求，比如你在瀏覽器地址欄輸入 www.cxuanblog.com 其實(shí)就是發(fā)送了一個(gè) get 請(qǐng)求，它的主要特征是請(qǐng)求服務(wù)器返回資源，而 post 方法一般用于

• 表單的提交，相當(dāng)于是把信息提交給服務(wù)器，等待服務(wù)器作出響應(yīng)，get 相當(dāng)于一個(gè)是 pull/拉的操作，而 post 相當(dāng)于是一個(gè) push/推的操作。
• get 方法是不安全的，因?yàn)槟阍诎l(fā)送請(qǐng)求的過(guò)程中，你的請(qǐng)求參數(shù)會(huì)拼在 URL 后面，從而導(dǎo)致容易被攻擊者竊取，對(duì)你的信息造成破壞和偽造;

/test/demo_form.asp?name1=value1&name2=value2 

而 post 方法是把參數(shù)放在請(qǐng)求體 body 中的，這對(duì)用戶(hù)來(lái)說(shuō)不可見(jiàn)。

POST /test/demo_form.asp HTTP/1.1 
Host: w3schools.com 
name1=value1&name2=value2 

• get 請(qǐng)求的 URL 有長(zhǎng)度限制，而 post 請(qǐng)求會(huì)把參數(shù)和值放在消息體中，對(duì)數(shù)據(jù)長(zhǎng)度沒(méi)有要求。
• get 請(qǐng)求會(huì)被瀏覽器主動(dòng) cache，而 post 不會(huì)，除非手動(dòng)設(shè)置。
• get 請(qǐng)求在瀏覽器反復(fù)的 回退/前進(jìn) 操作是無(wú)害的，而 post 操作會(huì)再次提交表單請(qǐng)求。
• get 請(qǐng)求在發(fā)送過(guò)程中會(huì)產(chǎn)生一個(gè) TCP 數(shù)據(jù)包;post 在發(fā)送過(guò)程中會(huì)產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包。對(duì)于 get 方式的請(qǐng)求，瀏覽器會(huì)把 http header 和 data 一并發(fā)送出去，服務(wù)器響應(yīng) 200(返回?cái)?shù)據(jù));而對(duì)于 post，瀏覽器先發(fā)送 header，服務(wù)器響應(yīng) 100 continue，瀏覽器再發(fā)送 data，服務(wù)器響應(yīng) 200 ok(返回?cái)?shù)據(jù))。

什么是無(wú)狀態(tài)協(xié)議，HTTP 是無(wú)狀態(tài)協(xié)議嗎，怎么解決

無(wú)狀態(tài)協(xié)議(Stateless Protocol) 就是指瀏覽器對(duì)于事務(wù)的處理沒(méi)有記憶能力。舉個(gè)例子來(lái)說(shuō)就是比如客戶(hù)請(qǐng)求獲得網(wǎng)頁(yè)之后關(guān)閉瀏覽器，然后再次啟動(dòng)瀏覽器，登錄該網(wǎng)站，但是服務(wù)器并不知道客戶(hù)關(guān)閉了一次瀏覽器。

HTTP 就是一種無(wú)狀態(tài)的協(xié)議，他對(duì)用戶(hù)的操作沒(méi)有記憶能力。可能大多數(shù)用戶(hù)不相信，他可能覺(jué)得每次輸入用戶(hù)名和密碼登陸一個(gè)網(wǎng)站后，下次登陸就不再重新輸入用戶(hù)名和密碼了。這其實(shí)不是 HTTP 做的事情，起作用的是一個(gè)叫做 小甜餅(Cookie) 的機(jī)制。它能夠讓瀏覽器具有記憶能力。

如果你的瀏覽器允許 cookie 的話(huà)，查看方式 chrome://settings/content/cookies

也就說(shuō)明你的記憶芯片通電了…… 當(dāng)你向服務(wù)端發(fā)送請(qǐng)求時(shí)，服務(wù)端會(huì)給你發(fā)送一個(gè)認(rèn)證信息，服務(wù)器第一次接收到請(qǐng)求時(shí)，開(kāi)辟了一塊 Session 空間(創(chuàng)建了Session對(duì)象)，同時(shí)生成一個(gè) sessionId ，并通過(guò)響應(yīng)頭的 Set-Cookie：JSESSIONID=XXXXXXX 命令，向客戶(hù)端發(fā)送要求設(shè)置 Cookie 的響應(yīng);客戶(hù)端收到響應(yīng)后，在本機(jī)客戶(hù)端設(shè)置了一個(gè) JSESSIONID=XXXXXXX 的 Cookie 信息，該 Cookie 的過(guò)期時(shí)間為瀏覽器會(huì)話(huà)結(jié)束;

接下來(lái)客戶(hù)端每次向同一個(gè)網(wǎng)站發(fā)送請(qǐng)求時(shí)，請(qǐng)求頭都會(huì)帶上該 Cookie信息(包含 sessionId )， 然后，服務(wù)器通過(guò)讀取請(qǐng)求頭中的 Cookie 信息，獲取名稱(chēng)為 JSESSIONID 的值，得到此次請(qǐng)求的 sessionId。這樣，你的瀏覽器才具有了記憶能力。

還有一種方式是使用 JWT 機(jī)制，它也是能夠讓你的瀏覽器具有記憶能力的一種機(jī)制。與 Cookie 不同，JWT 是保存在客戶(hù)端的信息，它廣泛的應(yīng)用于單點(diǎn)登錄的情況。JWT 具有兩個(gè)特點(diǎn)

• JWT 的 Cookie 信息存儲(chǔ)在客戶(hù)端，而不是服務(wù)端內(nèi)存中。也就是說(shuō)，JWT 直接本地進(jìn)行驗(yàn)證就可以，驗(yàn)證完畢后，這個(gè) Token 就會(huì)在 Session 中隨請(qǐng)求一起發(fā)送到服務(wù)器，通過(guò)這種方式，可以節(jié)省服務(wù)器資源，并且 token 可以進(jìn)行多次驗(yàn)證。
• JWT 支持跨域認(rèn)證，Cookies 只能用在單個(gè)節(jié)點(diǎn)的域或者它的子域中有效。如果它們嘗試通過(guò)第三個(gè)節(jié)點(diǎn)訪(fǎng)問(wèn)，就會(huì)被禁止。使用 JWT 可以解決這個(gè)問(wèn)題，使用 JWT 能夠通過(guò)多個(gè)節(jié)點(diǎn)進(jìn)行用戶(hù)認(rèn)證，也就是我們常說(shuō)的跨域認(rèn)證。

UDP 和 TCP 的區(qū)別

TCP 和 UDP 都位于計(jì)算機(jī)網(wǎng)絡(luò)模型中的運(yùn)輸層，它們負(fù)責(zé)傳輸應(yīng)用層產(chǎn)生的數(shù)據(jù)。下面我們就來(lái)聊一聊 TCP 和 UDP 分別的特征和他們的區(qū)別

1. UDP 是什么

UDP 的全稱(chēng)是 User Datagram Protocol，用戶(hù)數(shù)據(jù)報(bào)協(xié)議。它不需要所謂的握手操作，從而加快了通信速度，允許網(wǎng)絡(luò)上的其他主機(jī)在接收方同意通信之前進(jìn)行數(shù)據(jù)傳輸。

數(shù)據(jù)報(bào)是與分組交換網(wǎng)絡(luò)關(guān)聯(lián)的傳輸單元。

UDP 的特點(diǎn)主要有：

• UDP 能夠支持容忍數(shù)據(jù)包丟失的帶寬密集型應(yīng)用程序
• UDP 具有低延遲的特點(diǎn)
• UDP 能夠發(fā)送大量的數(shù)據(jù)包
• UDP 能夠允許 DNS 查找，DNS 是建立在 UDP 之上的應(yīng)用層協(xié)議。

2. TCP 是什么

TCP 的全稱(chēng)是Transmission Control Protocol ，傳輸控制協(xié)議。它能夠幫助你確定計(jì)算機(jī)連接到 Internet 以及它們之間的數(shù)據(jù)傳輸。通過(guò)三次握手來(lái)建立 TCP 連接，三次握手就是用來(lái)啟動(dòng)和確認(rèn) TCP 連接的過(guò)程。一旦連接建立后，就可以發(fā)送數(shù)據(jù)了，當(dāng)數(shù)據(jù)傳輸完成后，會(huì)通過(guò)關(guān)閉虛擬電路來(lái)斷開(kāi)連接。

TCP 的主要特點(diǎn)有：

• TCP 能夠確保連接的建立和數(shù)據(jù)包的發(fā)送
• TCP 支持錯(cuò)誤重傳機(jī)制
• TCP 支持擁塞控制，能夠在網(wǎng)絡(luò)擁堵的情況下延遲發(fā)送
• TCP 能夠提供錯(cuò)誤校驗(yàn)和，甄別有害的數(shù)據(jù)包。

3. TCP 和 UDP 的不同

下面為你羅列了一些 TCP 和 UDP 的不同點(diǎn)，方便理解，方便記憶。

TCP 三次握手和四次揮手

TCP 三次握手和四次揮手也是面試題的熱門(mén)考點(diǎn)，它們分別對(duì)應(yīng) TCP 的連接和釋放過(guò)程。下面就來(lái)簡(jiǎn)單認(rèn)識(shí)一下這兩個(gè)過(guò)程。

1. TCP 三次握手

在了解具體的流程前，我們需要先認(rèn)識(shí)幾個(gè)概念

• SYN：它的全稱(chēng)是 Synchronize Sequence Numbers，同步序列編號(hào)。是 TCP/IP 建立連接時(shí)使用的握手信號(hào)。在客戶(hù)機(jī)和服務(wù)器之間建立 TCP 連接時(shí)，首先會(huì)發(fā)送的一個(gè)信號(hào)。客戶(hù)端在接受到 SYN 消息時(shí)，就會(huì)在自己的段內(nèi)生成一個(gè)隨機(jī)值 X。
• SYN-ACK：服務(wù)器收到 SYN 后，打開(kāi)客戶(hù)端連接，發(fā)送一個(gè) SYN-ACK 作為答復(fù)。確認(rèn)號(hào)設(shè)置為比接收到的序列號(hào)多一個(gè)，即 X + 1，服務(wù)器為數(shù)據(jù)包選擇的序列號(hào)是另一個(gè)隨機(jī)數(shù) Y。
• ACK：Acknowledge character, 確認(rèn)字符，表示發(fā)來(lái)的數(shù)據(jù)已確認(rèn)接收無(wú)誤。最后，客戶(hù)端將 ACK 發(fā)送給服務(wù)器。序列號(hào)被設(shè)置為所接收的確認(rèn)值即 Y + 1。

如果用現(xiàn)實(shí)生活來(lái)舉例的話(huà)就是：小明 - 客戶(hù)端 小紅 - 服務(wù)端

• 小明給小紅打電話(huà)，接通了后，小明說(shuō)喂，能聽(tīng)到嗎，這就相當(dāng)于是連接建立。
• 小紅給小明回應(yīng)，能聽(tīng)到，你能聽(tīng)到我說(shuō)的話(huà)嗎，這就相當(dāng)于是請(qǐng)求響應(yīng)。
• 小明聽(tīng)到小紅的回應(yīng)后，好的，這相當(dāng)于是連接確認(rèn)。在這之后小明和小紅就可以通話(huà)/交換信息了。

2. TCP 四次揮手

在連接終止階段使用四次揮手，連接的每一端都會(huì)獨(dú)立的終止。下面我們來(lái)描述一下這個(gè)過(guò)程。

• 首先，客戶(hù)端應(yīng)用程序決定要終止連接(這里服務(wù)端也可以選擇斷開(kāi)連接)。這會(huì)使客戶(hù)端將 FIN 發(fā)送到服務(wù)器，并進(jìn)入 FIN_WAIT_1 狀態(tài)。當(dāng)客戶(hù)端處于 FIN_WAIT_1 狀態(tài)時(shí)，它會(huì)等待來(lái)自服務(wù)器的 ACK 響應(yīng)。
• 然后第二步，當(dāng)服務(wù)器收到 FIN 消息時(shí)，服務(wù)器會(huì)立刻向客戶(hù)端發(fā)送 ACK 確認(rèn)消息。
• 當(dāng)客戶(hù)端收到服務(wù)器發(fā)送的 ACK 響應(yīng)后，客戶(hù)端就進(jìn)入 FIN_WAIT_2 狀態(tài)，然后等待來(lái)自服務(wù)器的 FIN 消息
• 服務(wù)器發(fā)送 ACK 確認(rèn)消息后，一段時(shí)間(可以進(jìn)行關(guān)閉后)會(huì)發(fā)送 FIN 消息給客戶(hù)端，告知客戶(hù)端可以進(jìn)行關(guān)閉。
• 當(dāng)客戶(hù)端收到從服務(wù)端發(fā)送的 FIN 消息時(shí)，客戶(hù)端就會(huì)由 FIN_WAIT_2 狀態(tài)變?yōu)?TIME_WAIT 狀態(tài)。處于 TIME_WAIT 狀態(tài)的客戶(hù)端允許重新發(fā)送 ACK 到服務(wù)器為了防止信息丟失。客戶(hù)端在 TIME_WAIT 狀態(tài)下花費(fèi)的時(shí)間取決于它的實(shí)現(xiàn)，在等待一段時(shí)間后，連接關(guān)閉，客戶(hù)端上所有的資源(包括端口號(hào)和緩沖區(qū)數(shù)據(jù))都被釋放。

還是可以用上面那個(gè)通話(huà)的例子來(lái)進(jìn)行描述：

• 小明對(duì)小紅說(shuō)，我所有的東西都說(shuō)完了，我要掛電話(huà)了。
• 小紅說(shuō)，收到，我這邊還有一些東西沒(méi)說(shuō)。
• 經(jīng)過(guò)若干秒后，小紅也說(shuō)完了，小紅說(shuō)，我說(shuō)完了，現(xiàn)在可以?huà)鞌嗔?/li>
• 小明收到消息后，又等了若干時(shí)間后，掛斷了電話(huà)。

簡(jiǎn)述 HTTP1.0/1.1/2.0 的區(qū)別

1. HTTP 1.0

HTTP 1.0 是在 1996 年引入的，從那時(shí)開(kāi)始，它的普及率就達(dá)到了驚人的效果。

• HTTP 1.0 僅僅提供了最基本的認(rèn)證，這時(shí)候用戶(hù)名和密碼還未經(jīng)加密，因此很容易收到窺探。
• HTTP 1.0 被設(shè)計(jì)用來(lái)使用短鏈接，即每次發(fā)送數(shù)據(jù)都會(huì)經(jīng)過(guò) TCP 的三次握手和四次揮手，效率比較低。
• HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作為緩存失效的標(biāo)準(zhǔn)。
• HTTP 1.0 不支持?jǐn)帱c(diǎn)續(xù)傳，也就是說(shuō)，每次都會(huì)傳送全部的頁(yè)面和數(shù)據(jù)。
• HTTP 1.0 認(rèn)為每臺(tái)計(jì)算機(jī)只能綁定一個(gè) IP，所以請(qǐng)求消息中的 URL 并沒(méi)有傳遞主機(jī)名(hostname)。

2. HTTP 1.1

HTTP 1.1 是 HTTP 1.0 開(kāi)發(fā)三年后出現(xiàn)的，也就是 1999 年，它做出了以下方面的變化：

• HTTP 1.1 使用了摘要算法來(lái)進(jìn)行身份驗(yàn)證
• HTTP 1.1 默認(rèn)使用長(zhǎng)連接，長(zhǎng)連接就是只需一次建立就可以傳輸多次數(shù)據(jù)，傳輸完成后，只需要一次切斷連接即可。長(zhǎng)連接的連接時(shí)長(zhǎng)可以通過(guò)請(qǐng)求頭中的 keep-alive 來(lái)設(shè)置
• HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等緩存控制標(biāo)頭來(lái)控制緩存失效。
• HTTP 1.1 支持?jǐn)帱c(diǎn)續(xù)傳，通過(guò)使用請(qǐng)求頭中的 Range 來(lái)實(shí)現(xiàn)。
• HTTP 1.1 使用了虛擬網(wǎng)絡(luò)，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)(Multi-homed Web Servers)，并且它們共享一個(gè)IP地址。

3. HTTP 2.0

HTTP 2.0 是 2015 年開(kāi)發(fā)出來(lái)的標(biāo)準(zhǔn)，它主要做的改變?nèi)缦?/p>

• 頭部壓縮，由于 HTTP 1.1 經(jīng)常會(huì)出現(xiàn) User-Agent、Cookie、Accept、Server、Range 等字段可能會(huì)占用幾百甚至幾千字節(jié)，而 Body 卻經(jīng)常只有幾十字節(jié)，所以導(dǎo)致頭部偏重。HTTP 2.0 使用 HPACK 算法進(jìn)行壓縮。
• 二進(jìn)制格式，HTTP 2.0 使用了更加靠近 TCP/IP 的二進(jìn)制格式，而拋棄了 ASCII 碼，提升了解析效率
• 強(qiáng)化安全，由于安全已經(jīng)成為重中之重，所以 HTTP2.0 一般都跑在 HTTPS 上。
• 多路復(fù)用，即每一個(gè)請(qǐng)求都是是用作連接共享。一個(gè)請(qǐng)求對(duì)應(yīng)一個(gè)id，這樣一個(gè)連接上可以有多個(gè)請(qǐng)求。

請(qǐng)你說(shuō)一下 HTTP 常見(jiàn)的請(qǐng)求頭

這個(gè)問(wèn)題比較開(kāi)放，因?yàn)?HTTP 請(qǐng)求頭有很多，這里只簡(jiǎn)單舉出幾個(gè)例子。

HTTP 標(biāo)頭會(huì)分為四種，分別是 通用標(biāo)頭、實(shí)體標(biāo)頭、請(qǐng)求標(biāo)頭、響應(yīng)標(biāo)頭。分別介紹一下

1. 通用標(biāo)頭

通用標(biāo)頭主要有三個(gè)，分別是 Date、Cache-Control 和 Connection

(1) Date

Date 是一個(gè)通用標(biāo)頭，它可以出現(xiàn)在請(qǐng)求標(biāo)頭和響應(yīng)標(biāo)頭中，它的基本表示如下

Date: Wed, 21 Oct 2015 07:28:00 GMT  

表示的是格林威治標(biāo)準(zhǔn)時(shí)間，這個(gè)時(shí)間要比北京時(shí)間慢八個(gè)小時(shí)

(2) Cache-Control

Cache-Control 是一個(gè)通用標(biāo)頭，他可以出現(xiàn)在請(qǐng)求標(biāo)頭和響應(yīng)標(biāo)頭中，Cache-Control 的種類(lèi)比較多，雖然說(shuō)這是一個(gè)通用標(biāo)頭，但是有一些特性是請(qǐng)求標(biāo)頭具有的，有一些是響應(yīng)標(biāo)頭才有的。主要大類(lèi)有 可緩存性、閾值性、 重新驗(yàn)證并重新加載 和其他特性

(3) Connection

Connection 決定當(dāng)前事務(wù)(一次三次握手和四次揮手)完成后，是否會(huì)關(guān)閉網(wǎng)絡(luò)連接。Connection 有兩種，一種是持久性連接，即一次事務(wù)完成后不關(guān)閉網(wǎng)絡(luò)連接

Connection: keep-alive 

另一種是非持久性連接，即一次事務(wù)完成后關(guān)閉網(wǎng)絡(luò)連接

Connection: close 

HTTP1.1 其他通用標(biāo)頭如下：

2. 實(shí)體標(biāo)頭

實(shí)體標(biāo)頭是描述消息正文內(nèi)容的 HTTP 標(biāo)頭。實(shí)體標(biāo)頭用于 HTTP 請(qǐng)求和響應(yīng)中。頭部Content-Length、 Content-Language、 Content-Encoding 是實(shí)體頭。

• Content-Length 實(shí)體報(bào)頭指示實(shí)體主體的大小，以字節(jié)為單位，發(fā)送到接收方。
• Content-Language 實(shí)體報(bào)頭描述了客戶(hù)端或者服務(wù)端能夠接受的語(yǔ)言。
• Content-Encoding 這又是一個(gè)比較麻煩的屬性，這個(gè)實(shí)體報(bào)頭用來(lái)壓縮媒體類(lèi)型。Content-Encoding 指示對(duì)實(shí)體應(yīng)用了何種編碼。

常見(jiàn)的內(nèi)容編碼有這幾種： gzip、compress、deflate、identity ，這個(gè)屬性可以應(yīng)用在請(qǐng)求報(bào)文和響應(yīng)報(bào)文中

Accept-Encoding: gzip, deflate //請(qǐng)求頭 
Content-Encoding: gzip  //響應(yīng)頭 

下面是一些實(shí)體標(biāo)頭字段

3. 請(qǐng)求標(biāo)頭Host

(1) Host

請(qǐng)求頭指明了服務(wù)器的域名(對(duì)于虛擬主機(jī)來(lái)說(shuō))，以及(可選的)服務(wù)器監(jiān)聽(tīng)的 TCP 端口號(hào)。如果沒(méi)有給定端口號(hào)，會(huì)自動(dòng)使用被請(qǐng)求服務(wù)的默認(rèn)端口(比如請(qǐng)求一個(gè) HTTP 的 URL 會(huì)自動(dòng)使用 80 作為端口)。

Host: developer.mozilla.org 

上面的 Accpet、 Accept-Language、Accept-Encoding 都是屬于內(nèi)容協(xié)商的請(qǐng)求標(biāo)頭。

(2) Referer

HTTP Referer 屬性是請(qǐng)求標(biāo)頭的一部分，當(dāng)瀏覽器向 web 服務(wù)器發(fā)送請(qǐng)求的時(shí)候，一般會(huì)帶上 Referer，告訴服務(wù)器該網(wǎng)頁(yè)是從哪個(gè)頁(yè)面鏈接過(guò)來(lái)的，服務(wù)器因此可以獲得一些信息用于處理。

Referer: https://developer.mozilla.org/testpage.html 

(3) If-Modified-Since

If-Modified-Since 通常會(huì)與 If-None-Match 搭配使用，If-Modified-Since 用于確認(rèn)代理或客戶(hù)端擁有的本地資源的有效性。獲取資源的更新日期時(shí)間，可通過(guò)確認(rèn)首部字段 Last-Modified 來(lái)確定。

大白話(huà)說(shuō)就是如果在 Last-Modified 之后更新了服務(wù)器資源，那么服務(wù)器會(huì)響應(yīng) 200，如果在 Last-Modified 之后沒(méi)有更新過(guò)資源，則返回 304。

If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT 

(4) If-None-Match

If-None-Match HTTP 請(qǐng)求標(biāo)頭使請(qǐng)求成為條件請(qǐng)求。對(duì)于 GET 和 HEAD 方法，僅當(dāng)服務(wù)器沒(méi)有與給定資源匹配的 ETag 時(shí)，服務(wù)器才會(huì)以 200 狀態(tài)發(fā)送回請(qǐng)求的資源。對(duì)于其他方法，僅當(dāng)最終現(xiàn)有資源的ETag與列出的任何值都不匹配時(shí)，才會(huì)處理請(qǐng)求。

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a" 

(5) Accept

接受請(qǐng)求 HTTP 標(biāo)頭會(huì)通告客戶(hù)端其能夠理解的 MIME 類(lèi)型

(6) Accept-Charset

accept-charset 屬性規(guī)定服務(wù)器處理表單數(shù)據(jù)所接受的字符集。

常用的字符集有：UTF-8 - Unicode 字符編碼 ;ISO-8859-1 - 拉丁字母表的字符編碼

(7) Accept-Language

首部字段 Accept-Language 用來(lái)告知服務(wù)器用戶(hù)代理能夠處理的自然語(yǔ)言集(指中文或英文等)，以及自然語(yǔ)言集的相對(duì)優(yōu)先級(jí)。可一次指定多種自然語(yǔ)言集。

請(qǐng)求標(biāo)頭我們大概就介紹這幾種，后面會(huì)有一篇文章詳細(xì)深挖所有的響應(yīng)頭的，下面是一個(gè)響應(yīng)頭的匯總，基于 HTTP 1.1

4. 響應(yīng)標(biāo)頭

(1) Access-Control-Allow-Origin

一個(gè)返回的 HTTP 標(biāo)頭可能會(huì)具有 Access-Control-Allow-Origin ，Access-Control-Allow-Origin 指定一個(gè)來(lái)源，它告訴瀏覽器允許該來(lái)源進(jìn)行資源訪(fǎng)問(wèn)。

(2) Keep-Alive

Keep-Alive 表示的是 Connection 非持續(xù)連接的存活時(shí)間，可以進(jìn)行指定。

(3) Server

服務(wù)器標(biāo)頭包含有關(guān)原始服務(wù)器用來(lái)處理請(qǐng)求的軟件的信息。

應(yīng)該避免使用過(guò)于冗長(zhǎng)和詳細(xì)的 Server 值，因?yàn)樗鼈兛赡軙?huì)泄露內(nèi)部實(shí)施細(xì)節(jié)，這可能會(huì)使攻擊者容易地發(fā)現(xiàn)并利用已知的安全漏洞。例如下面這種寫(xiě)法

Server: Apache/2.4.1 (Unix) 

(4) Set-Cookie

Set-Cookie 用于服務(wù)器向客戶(hù)端發(fā)送 sessionID。

(5) Transfer-Encoding

首部字段 Transfer-Encoding 規(guī)定了傳輸報(bào)文主體時(shí)采用的編碼方式。

HTTP /1.1 的傳輸編碼方式僅對(duì)分塊傳輸編碼有效。

(6) X-Frame-Options

HTTP 首部字段是可以自行擴(kuò)展的。所以在 Web 服務(wù)器和瀏覽器的應(yīng)用上，會(huì)出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段。

首部字段 X-Frame-Options 屬于 HTTP 響應(yīng)首部，用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站的 Frame 標(biāo)簽內(nèi)的顯示問(wèn)題。其主要目的是為了防止點(diǎn)擊劫持(clickjacking)攻擊。

下面是一個(gè)響應(yīng)頭的匯總，基于 HTTP 1.1

地址欄輸入 URL 發(fā)生了什么

這道題也是一道經(jīng)常會(huì)考的面試題。那么下面我們就來(lái)探討一下從你輸入 URL 后到響應(yīng)，都經(jīng)歷了哪些過(guò)程。

首先，你需要在瀏覽器中的 URL 地址上，輸入你想訪(fǎng)問(wèn)的地址，如下：

你應(yīng)該訪(fǎng)問(wèn)不到的，對(duì)不對(duì)~

然后，瀏覽器會(huì)根據(jù)你輸入的 URL 地址，去查找域名是否被本地 DNS 緩存，不同瀏覽器對(duì) DNS 的設(shè)置不同，如果瀏覽器緩存了你想訪(fǎng)問(wèn)的 URL 地址，那就直接返回 ip。如果沒(méi)有緩存你的 URL 地址，瀏覽器就會(huì)發(fā)起系統(tǒng)調(diào)用來(lái)查詢(xún)本機(jī) hosts 文件是否有配置 ip 地址，如果找到，直接返回。如果找不到，就向網(wǎng)絡(luò)中發(fā)起一個(gè) DNS 查詢(xún)。

首先來(lái)看一下 DNS 是啥，互聯(lián)網(wǎng)中識(shí)別主機(jī)的方式有兩種，通過(guò)主機(jī)名和 IP 地址。我們?nèi)讼矚g用名字的方式進(jìn)行記憶，但是通信鏈路中的路由卻喜歡定長(zhǎng)、有層次結(jié)構(gòu)的 IP 地址。所以就需要一種能夠把主機(jī)名到 IP 地址的轉(zhuǎn)換服務(wù)，這種服務(wù)就是由 DNS 提供的。DNS 的全稱(chēng)是 Domain Name System 域名系統(tǒng)。DNS 是一種由分層的 DNS 服務(wù)器實(shí)現(xiàn)的分布式數(shù)據(jù)庫(kù)。DNS 運(yùn)行在 UDP 上，使用 53 端口。

DNS 是一種分層數(shù)據(jù)庫(kù)，它的主要層次結(jié)構(gòu)如下

一般域名服務(wù)器的層次結(jié)構(gòu)主要是以上三種，除此之外，還有另一類(lèi)重要的 DNS 服務(wù)器，它是 本地 DNS 服務(wù)器(local DNS server)。嚴(yán)格來(lái)說(shuō)，本地 DNS 服務(wù)器并不屬于上述層次結(jié)構(gòu)，但是本地 DNS 服務(wù)器又是至關(guān)重要的。每個(gè) ISP(Internet Service Provider) 比如居民區(qū)的 ISP 或者一個(gè)機(jī)構(gòu)的 ISP 都有一臺(tái)本地 DNS 服務(wù)器。當(dāng)主機(jī)和 ISP 進(jìn)行連接時(shí)，該 ISP 會(huì)提供一臺(tái)主機(jī)的 IP 地址，該主機(jī)會(huì)具有一臺(tái)或多臺(tái)其本地 DNS 服務(wù)器的 IP地址。通過(guò)訪(fǎng)問(wèn)網(wǎng)絡(luò)連接，用戶(hù)能夠容易的確定 DNS 服務(wù)器的 IP地址。當(dāng)主機(jī)發(fā)出 DNS 請(qǐng)求后，該請(qǐng)求被發(fā)往本地 DNS 服務(wù)器，它起著代理的作用，并將該請(qǐng)求轉(zhuǎn)發(fā)到 DNS 服務(wù)器層次系統(tǒng)中。

首先，查詢(xún)請(qǐng)求會(huì)先找到本地 DNS 服務(wù)器來(lái)查詢(xún)是否包含 IP 地址，如果本地 DNS 無(wú)法查詢(xún)到目標(biāo) IP 地址，就會(huì)向根域名服務(wù)器發(fā)起一個(gè) DNS 查詢(xún)。

注意：DNS 涉及兩種查詢(xún)方式：一種是遞歸查詢(xún)(Recursive query) ，一種是迭代查詢(xún)(Iteration query)。《計(jì)算機(jī)網(wǎng)絡(luò)：自頂向下方法》竟然沒(méi)有給出遞歸查詢(xún)和迭代查詢(xún)的區(qū)別，找了一下網(wǎng)上的資料大概明白了下。

• 如果根域名服務(wù)器無(wú)法告知本地 DNS 服務(wù)器下一步需要訪(fǎng)問(wèn)哪個(gè)頂級(jí)域名服務(wù)器，就會(huì)使用遞歸查詢(xún);
• 如果根域名服務(wù)器能夠告知 DNS 服務(wù)器下一步需要訪(fǎng)問(wèn)的頂級(jí)域名服務(wù)器，就會(huì)使用迭代查詢(xún)。

在由根域名服務(wù)器 -> 頂級(jí)域名服務(wù)器 -> 權(quán)威 DNS 服務(wù)器后，由權(quán)威服務(wù)器告訴本地服務(wù)器目標(biāo) IP 地址，再有本地 DNS 服務(wù)器告訴用戶(hù)需要訪(fǎng)問(wèn)的 IP 地址。

• 第三步，瀏覽器需要和目標(biāo)服務(wù)器建立 TCP 連接，需要經(jīng)過(guò)三次握手的過(guò)程，具體的握手過(guò)程請(qǐng)參考上面的回答。
• 在建立連接后，瀏覽器會(huì)向目標(biāo)服務(wù)器發(fā)起 HTTP-GET 請(qǐng)求，包括其中的 URL，HTTP 1.1 后默認(rèn)使用長(zhǎng)連接，只需要一次握手即可多次傳輸數(shù)據(jù)。
• 如果目標(biāo)服務(wù)器只是一個(gè)簡(jiǎn)單的頁(yè)面，就會(huì)直接返回。但是對(duì)于某些大型網(wǎng)站的站點(diǎn)，往往不會(huì)直接返回主機(jī)名所在的頁(yè)面，而會(huì)直接重定向。返回的狀態(tài)碼就不是 200 ，而是 301,302 以 3 開(kāi)頭的重定向碼，瀏覽器在獲取了重定向響應(yīng)后，在響應(yīng)報(bào)文中 Location 項(xiàng)找到重定向地址，瀏覽器重新第一步訪(fǎng)問(wèn)即可。
• 然后瀏覽器重新發(fā)送請(qǐng)求，攜帶新的 URL，返回狀態(tài)碼 200 OK，表示服務(wù)器可以響應(yīng)請(qǐng)求，返回報(bào)文。

HTTPS 的工作原理

我們上面描述了一下 HTTP 的工作原理，下面來(lái)講述一下 HTTPS 的工作原理。因?yàn)槲覀冎?HTTPS 不是一種新出現(xiàn)的協(xié)議，而是

所以，我們探討 HTTPS 的握手過(guò)程，其實(shí)就是 SSL/TLS 的握手過(guò)程。

TLS 旨在為 Internet 提供通信安全的加密協(xié)議。TLS 握手是啟動(dòng)和使用 TLS 加密的通信會(huì)話(huà)的過(guò)程。在 TLS 握手期間，Internet 中的通信雙方會(huì)彼此交換信息，驗(yàn)證密碼套件，交換會(huì)話(huà)密鑰。

每當(dāng)用戶(hù)通過(guò) HTTPS 導(dǎo)航到具體的網(wǎng)站并發(fā)送請(qǐng)求時(shí)，就會(huì)進(jìn)行 TLS 握手。除此之外，每當(dāng)其他任何通信使用HTTPS(包括 API 調(diào)用和在 HTTPS 上查詢(xún) DNS)時(shí)，也會(huì)發(fā)生 TLS 握手。

TLS 具體的握手過(guò)程會(huì)根據(jù)所使用的密鑰交換算法的類(lèi)型和雙方支持的密碼套件而不同。我們以RSA 非對(duì)稱(chēng)加密來(lái)討論這個(gè)過(guò)程。整個(gè) TLS 通信流程圖如下：

• 在進(jìn)行通信前，首先會(huì)進(jìn)行 HTTP 的三次握手，握手完成后，再進(jìn)行 TLS 的握手過(guò)程
• ClientHello：客戶(hù)端通過(guò)向服務(wù)器發(fā)送 hello 消息來(lái)發(fā)起握手過(guò)程。這個(gè)消息中會(huì)夾帶著客戶(hù)端支持的 TLS 版本號(hào)(TLS1.0 、TLS1.2、TLS1.3) 、客戶(hù)端支持的密碼套件、以及一串 客戶(hù)端隨機(jī)數(shù)。
• ServerHello：在客戶(hù)端發(fā)送 hello 消息后，服務(wù)器會(huì)發(fā)送一條消息，這條消息包含了服務(wù)器的 SSL 證書(shū)、服務(wù)器選擇的密碼套件和服務(wù)器生成的隨機(jī)數(shù)。
• 認(rèn)證(Authentication)：客戶(hù)端的證書(shū)頒發(fā)機(jī)構(gòu)會(huì)認(rèn)證 SSL 證書(shū)，然后發(fā)送 Certificate 報(bào)文，報(bào)文中包含公開(kāi)密鑰證書(shū)。最后服務(wù)器發(fā)送 ServerHelloDone 作為 hello 請(qǐng)求的響應(yīng)。第一部分握手階段結(jié)束。
• 加密階段：在第一個(gè)階段握手完成后，客戶(hù)端會(huì)發(fā)送 ClientKeyExchange 作為響應(yīng)，這個(gè)響應(yīng)中包含了一種稱(chēng)為 The premaster secret 的密鑰字符串，這個(gè)字符串就是使用上面公開(kāi)密鑰證書(shū)進(jìn)行加密的字符串。隨后客戶(hù)端會(huì)發(fā)送 ChangeCipherSpec，告訴服務(wù)端使用私鑰解密這個(gè) premaster secret 的字符串，然后客戶(hù)端發(fā)送 Finished 告訴服務(wù)端自己發(fā)送完成了。

Session key 其實(shí)就是用公鑰證書(shū)加密的公鑰。

實(shí)現(xiàn)了安全的非對(duì)稱(chēng)加密：然后，服務(wù)器再發(fā)送 ChangeCipherSpec 和 Finished 告訴客戶(hù)端解密完成，至此實(shí)現(xiàn)了 RSA 的非對(duì)稱(chēng)加密。