摘要：基礎，超文本傳輸協議。不驗證通信方的身份，通信方的身份有可能遭遇偽裝。無法證明報文的完整性，報文有可能遭篡改。多路復用，支持單個連接多次請求，即連接共享，即每一個都是是用作連接共享機制的。

走在前端的大道上

本篇將自己讀過的相關 http/https 方法 文章中，對自己有啟發的章節片段總結在這（會對原文進行刪改）,會不斷豐富提煉總結更新。

HTTP（HyperText Transfer Protocol，超文本傳輸協議）。

WWW（World Wide Web）的三種技術：HTML、HTTP、URL。

RFC（Request for Comments，征求修正意見書），互聯網的設計文檔。

URI（Uniform Resource Indentifier，統一資源標識符）

URL（Uniform Resource Locator，統一資源定位符）

URN（Uniform Resource Name，統一資源名稱），例如 urn:isbn:0-486-27557-4 。

URI 包含 URL 和 URN，目前 WEB 只有 URL 比較流行，所以見到的基本都是 URL。

超文本傳輸??協議（HTTP）是用于傳輸諸如HTML的超媒體文檔的應用層協議。它被設計用于Web瀏覽器和Web服務器之間的通信，但它也可以用于其他目的。 HTTP遵循經典的客戶端-服務端模型，客戶端打開一個連接以發出請求，然后等待它收到服務器端響應。 HTTP是無狀態協議，意味著服務器不會在兩個請求之間保留任何數據（狀態）。

HTTP是明文傳輸的，也就意味著，介于發送端、接收端中間的任意節點都可以知道你們傳輸的內容是什么。這些節點可能是路由器、代理等。

舉個最常見的例子，用戶登陸。用戶輸入賬號，密碼，采用HTTP的話，只要在代理服務器上做點手腳就可以拿到你的密碼了。

用戶登陸 --> 代理服務器（做手腳）--> 實際授權服務器

在發送端對密碼進行加密？沒用的，雖然別人不知道你原始密碼是多少 ，但能夠拿到加密后的賬號密碼，照樣能登陸。

HTTP是應用層協議，位于HTTP協議之下是傳輸協議TCP。TCP負責傳輸，HTTP則定義了數據如何進行包裝。

簡單快速、靈活、無連接、無狀態

請求報文

響應報文

GET ----> 獲取資源
POST ----> 傳輸資源
PUT ----> 更新資源
DELETE ----> 刪除資源
HEAD ----> 獲取報文首部

GET在游覽器回退是無害的，而POST會再次提交請求

GET請求會被游覽器主動緩存，而POST不會，除非手動設置

GET請求參數會被完整的保留在游覽器歷史記錄里，而POST中的參數不會被保留

GET產生的URL地址可以被收藏，而POST不可以

GET參數通過URL傳遞，而POST放在Request body

GET請求只能進行URL編碼，而POST支持多種編碼方式

GET請求在URL中傳遞的參數是有長度限制的，而POST沒有限制

GET請求會把參數直接暴露在URL上，相比POST更安全

對參數的數據類型，GET只接受ASCII字符，而POST沒有限制

HTTPS科普掃盲帖
notes/HTTP

HTTPS相對于HTTP有哪些不同呢？其實就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。

通俗的講，TLS、SSL其實是類似的東西，SSL是個加密套件，負責對HTTP的數據進行加密。TLS是SSL的升級版?，F在提到HTTPS，加密套件基本指的是TLS。

傳輸加密的流程

原先是應用層將數據直接給到TCP進行傳輸，現在改成應用層將數據給到TLS/SSL，將數據加密后，再給到TCP進行傳輸。

對安全或密碼學基礎有了解的同學，應該知道常見的加密手段。一般來說，加密分為對稱加密、非對稱加密（也叫公開密鑰加密）

HTTPS開發的主要目的，是提供對網站服務器的身份認證，保護交換數據的隱私與完整性

HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。

HTTP協議運行在TCP之上，所有傳輸的內容都是明文，內容可能會被竊聽。HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸的內容都經過加密的。

HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。

不驗證通信方的身份，通信方的身份有可能遭遇偽裝。

無法證明報文的完整性，報文有可能遭篡改。

谷歌推行一種協議(HTTP 之下SSL之上[TCP]),可以算是HTTP2的前身,SPDY可以說是綜合了HTTPS和HTTP兩者優點于一體的傳輸協議，比如

壓縮數據(HEADER)

多路復用

優先級(可以給請求設置優先級)

SPDY構成圖：

SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。

HTTP2.0可以說是SPDY的升級版（其實原本也是基于SPDY設計的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，主要是以下兩點

HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS

HTTP2.0 消息頭的壓縮算法采用 HPACK，而非 SPDY 采用的 DEFLATE

http2 新特性

新的二進制格式（Binary Format），HTTP1.x的解析是基于文本?；谖谋緟f議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合?；谶@種考慮HTTP2.0的協議解析決定采用二進制格式，實現方便且健壯。

多路復用（MultiPlexing），支持單個連接多次請求，即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。

header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。

服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。目前，有大多數網站已經啟用HTTP2.0，例如YouTuBe，淘寶網等網站，利用chrome控制臺可以查看是否啟用H2：

chrome=>Network=>Name欄右鍵=>√Protocol

本節參考文章：簡單比較 http https http2、HTTPS科普掃盲帖

關于跨域，有兩個誤區：

? 動態請求就會有跨域的問題

? 跨域只存在于瀏覽器端，不存在于安卓/ios/Node.js/python/ java等其它環境

? 跨域就是請求發不出去了

? 跨域請求能發出去，服務端能收到請求并正常返回結果，只是結果被瀏覽器攔截了之所以會跨域，是因為受到了同源策略的限制，同源策略要求源相同才能正常進行通信，即協議、域名、端口號都完全一致。

不能向工作在不同源的的服務請求數據（client to server）

但是script標簽能夠加載非同源的資源，不受同源策略的影響。

無法獲取不同源的document/cookie等BOM和DOM，可以說任何有關另外一個源的信息都無法得到 （client to client）

如下圖所示：

只要瀏覽器檢測到響應頭帶上了CORS，并且允許的源包括了本網站，那么就不會攔截請求響應。

CORS把請求分為兩種，一種是簡單請求，另一種是需要觸發預檢請求，這兩者是相對的，怎樣才算“不簡單”？只要屬于下面的其中一種就不是簡單請求：
（1）使用了除GET/POST/HEAD之外的請求方式，如PUT/DELETE
（2）使用了除Accept/Accept-Language/Content-Language/Last-Event-ID/Content-Type：只限于三個值application/x-www-form-urlencoded、multipart/form-data、text/plain等幾個常用的http頭這個時候就認為需要先發個預檢請求，預檢請求使用OPTIONS方式去檢查當前請求是否安全

代碼里面只發了一個請求，但在控制臺看到了兩個請求，第一個是OPTIONS，服務端返回：

詳見阮一峰的跨域資源共享CORS詳解

JSONP是利用了script標簽能夠跨域，如下代碼所示：

function updateList (data) {
    console.log(data);
}

$body.append(‘");

代碼先定義一個全局函數，然后把這個函數名通過callback參數添加到script標簽的src，script的src就是需要跨域的請求，然后這個請求返回可執行的JS文本：// script響應返回的js內容為

updateList([{
    name: "hello"
}]);

由于它是一個js，并且已經定義了upldateList函數，所以能正常執行，并且跨域的數據通過傳參得到。這就是JSONP的原理。

跨域分為兩種，一種是跨域請求，另一種訪問跨域的頁面，跨域請求可以通過CORS/JSONP等方法進行訪問，跨域的頁面主要通過postMesssage的方式。由于跨域請求不但能發出去還能帶上cookie，所以要規避跨站請求偽造攻擊的風險，特別是涉及到錢的那種請求。

本節參考文章：我知道的跨域與安全

主要的過程是：
1.瀏覽器解析 -> 2.查詢緩存 -> 3.dns查詢 -> 4.建立鏈接 -> 5.服務器處理請求 -> 6.服務器發送響應 -> 7.客戶端收到頁面 -> 8.解析HTML -> 9.構建渲染樹 -> 10.開始顯示內容(白屏時間) -> 11.首屏內容加載完成(首屏時間) -> 12.用戶可交互(DOMContentLoaded) -> 13.加載完成(load)

跳轉-->應用緩存-->dns-->tcp-->request-->response

本節摘要：

DNS域名解析；

建立TCP連接；

發送HTTP請求；

服務器處理請求；

返回響應結果；

關閉TCP連接；

瀏覽器解析HTML；

瀏覽器布局渲染；

當我們在瀏覽器輸入網址并回車后，一切從這里開始。

我們在瀏覽器輸入網址，其實就是要向服務器請求我們想要的頁面內容，所有瀏覽器首先要確認的是域名所對應的服務器在哪里。將域名解析成對應的服務器IP地址這項工作，是由DNS服務器來完成的。

客戶端收到你輸入的域名地址后，它首先去找本地的hosts文件，檢查在該文件中是否有相應的域名、IP對應關系，如果有，則向其IP地址發送請求，如果沒有，再去找DNS服務器。一般用戶很少去編輯修改hosts文件。

    DNS服務器層次結構

瀏覽器客戶端向本地DNS服務器發送一個含有域名www.cnblogs.com的DNS查詢報文。本地DNS服務器把查詢報文轉發到根DNS服務器，根DNS服務器注意到其com后綴，于是向本地DNS服務器返回comDNS服務器的IP地址。本地DNS服務器再次向comDNS服務器發送查詢請求，comDNS服務器注意到其www.cnblogs.com后綴并用負責該域名的權威DNS服務器的IP地址作為回應。最后，本地DNS服務器將含有www.cnblogs.com的IP地址的響應報文發送給客戶端。

從客戶端到本地服務器屬于遞歸查詢，而DNS服務器之間的交互屬于迭代查詢。
正常情況下，本地DNS服務器的緩存中已有comDNS服務器的地址，因此請求根域名服務器這一步不是必需的。

費了一頓周折終于拿到服務器IP了，下一步自然就是鏈接到該服務器。對于客戶端與服務器的TCP鏈接，必然要說的就是『三次握手』。

三次握手

客戶端發送一個帶有SYN標志的數據包給服務端，服務端收到后，回傳一個帶有SYN/ACK標志的數據包以示傳達確認信息，最后客戶端再回傳一個帶ACK標志的數據包，代表握手結束，連接成功。

上圖也可以這么理解：

客戶端：“你好，在家不，有你快遞?！?/p>

服務端：“在的，送來就行?！?/p>

客戶端：“好嘞?！?/p>

TCP三次握手
client----->server:SYN(發起一個TCP連接，同步報文)
server----->client:SYN+ACK(應答報文，表示已創建連接)
client----->server:ACK(應答報文，表示收到已連接)

與服務器建立了連接后，就可以向服務器發起請求了。這里我們先看下請求報文的結構（如下圖）：

請求報文

在瀏覽器中查看報文首部（以google瀏覽器為例）：

請求行包括請求方法、URI、HTTP版本。首部字段傳遞重要信息，包括請求首部字段、通用首部字段和實體首部字段。我們可以從報文中看到發出的請求的具體信息。具體每個首部字段的作用，這里不做過多闡述。

服務器端收到請求后的由web服務器（準確說應該是http服務器）處理請求，諸如Apache、Ngnix、IIS等。web服務器解析用戶請求，知道了需要調度哪些資源文件，再通過相應的這些資源文件處理用戶請求和參數，并調用數據庫信息，最后將結果通過web服務器返回給瀏覽器客戶端。

服務器處理請求

在HTTP里，有請求就會有響應，哪怕是錯誤信息。這里我們同樣看下響應報文的組成結構：

響應報文

在響應結果中都會有個一個HTTP狀態碼，比如我們熟知的200、301、404、500等。通過這個狀態碼我們可以知道服務器端的處理是否正常，并能了解具體的錯誤。

狀態碼由3位數字和原因短語組成。根據首位數字，狀態碼可以分為五類：

狀態碼類別

為了避免服務器與客戶端雙方的資源占用和損耗，當雙方沒有請求或響應傳遞時，任意一方都可以發起關閉請求。與創建TCP連接的3次握手類似，關閉TCP連接，需要4次握手。

上圖可以這么理解：

客戶端：“兄弟，我這邊沒數據要傳了，咱關閉連接吧?！?/p>

服務端：“收到，我看看我這邊有木有數據了?！?/p>

服務端：“兄弟，我這邊也沒數據要傳你了，咱可以關閉連接了?！?/p>

客戶端：“好嘞?！?/p>

由客戶端發起的關閉連接

    * client----->server:FIN(請求關閉連接)
    * server----->client:ACK(收到了連接，但不會立即關閉，等到報文都發送完再回復一個FIN)
    * server----->client:FIN
    * client----->server:ACK(收到關閉)

由服務端發起的關閉連接

* 當http設置了keepalive定時關閉，服務端會在結束數據傳送后關閉TCP連接

準確地說，瀏覽器需要加載解析的不僅僅是HTML，還包括CSS、JS。以及還要加載圖片、視頻等其他媒體資源。

瀏覽器通過解析HTML，生成DOM樹，解析CSS，生成CSS規則樹，然后通過DOM樹和CSS規則樹生成渲染樹。渲染樹與DOM樹不同，渲染樹中并沒有head、display為none等不必顯示的節點。

要注意的是，瀏覽器的解析過程并非是串連進行的，比如在解析CSS的同時，可以繼續加載解析HTML，但在解析執行JS腳本時，會停止解析后續HTML，這就會出現阻塞問題，關于JS阻塞相關問題，這里不過多闡述,后面會多帶帶開篇講解。

根據渲染樹布局，計算CSS樣式，即每個節點在頁面中的大小和位置等幾何信息。HTML默認是流式布局的，CSS和js會打破這種布局，改變DOM的外觀樣式以及大小和位置。這時就要提到兩個重要概念：repaint和reflow。

repaint：屏幕的一部分重畫，不影響整體布局，比如某個CSS的背景色變了，但元素的幾何尺寸和位置不變。
reflow： 意味著元件的幾何尺寸變了，我們需要重新驗證并計算渲染樹。是渲染樹的一部分或全部發生了變化。這就是Reflow，或是Layout。

所以我們應該盡量減少reflow和repaint，我想這也是為什么現在很少有用table布局的原因之一。

最后瀏覽器繪制各個節點，將頁面展示給用戶。

拓展閱讀：面試必考之http狀態碼有哪些、CDN與DNS知識匯總、前端工程師系列，TCP復習及濃縮總結（全干貨，支持面試）

推薦必讀：5分鐘讓你明白HTTP協議、分分鐘讓你理解HTTPS

本節參考文章：”天龍八步“細說瀏覽器輸入URL后發生了什么

在瀏覽器地址欄輸入URL

瀏覽器查看緩存，如果請求資源在緩存中并且新鮮，跳轉到轉碼步驟

如果資源未緩存，發起新請求

如果已緩存，檢驗是否足夠新鮮，足夠新鮮直接提供給客戶端，否則與服務器進行驗證。

檢驗新鮮通常有兩個HTTP頭進行控制Expires和Cache-Control：

HTTP1.0提供Expires，值為一個絕對時間表示緩存新鮮日期

HTTP1.1增加了Cache-Control: max-age=,值為以秒為單位的最大新鮮時間

瀏覽器解析URL獲取協議，主機，端口，path

瀏覽器組裝一個HTTP（GET）請求報文

瀏覽器獲取主機ip地址（DNS解析），過程如下：

瀏覽器緩存

本機緩存

hosts文件

路由器緩存

ISP DNS緩存

DNS遞歸查詢（可能存在負載均衡導致每次IP不一樣）

打開一個socket與目標IP地址，端口建立TCP鏈接，三次握手如下：

客戶端發送一個TCP的SYN=1，Seq=X的包到服務器端口

服務器發回SYN=1， ACK=X+1， Seq=Y的響應包

客戶端發送ACK=Y+1， Seq=Z

TCP鏈接建立后發送HTTP請求

服務器接受請求并解析，將請求轉發到服務程序，如虛擬主機使用HTTP Host頭部判斷請求的服務程序

服務器檢查HTTP請求頭是否包含緩存驗證信息如果驗證緩存新鮮，返回304等對應狀態碼

處理程序讀取完整請求并準備HTTP響應，可能需要查詢數據庫等操作

服務器將響應報文通過TCP連接發送回瀏覽器

瀏覽器接收HTTP響應，然后根據情況選擇關閉TCP連接或者保留重用，關閉TCP連接的四次握手如下：

主動方發送Fin=1， Ack=Z， Seq= X報文

被動方發送ACK=X+1， Seq=Z報文

被動方發送Fin=1， ACK=X， Seq=Y報文

主動方發送ACK=Y， Seq=X報文

瀏覽器檢查響應狀態嗎：是否為1XX，3XX， 4XX， 5XX，這些情況處理與2XX不同

如果資源可緩存，進行緩存

對響應進行解碼（例如gzip壓縮）

根據資源類型決定如何處理（假設資源為HTML文檔）

解析HTML文檔，構件DOM樹，下載資源，構造CSSOM樹，執行js腳本，這些操作沒有嚴格的先后順序，以下分別解釋

構建DOM樹：

Tokenizing：根據HTML規范將字符流解析為標記

Lexing：詞法分析將標記轉換為對象并定義屬性和規則

DOM construction：根據HTML標記關系將對象組成DOM樹

解析過程中遇到圖片、樣式表、js文件，啟動下載

構建CSSOM樹：

Tokenizing：字符流轉換為標記流

Node：根據標記創建節點

CSSOM：節點創建CSSOM樹

根據DOM樹和CSSOM樹構建渲染樹:

從DOM樹的根節點遍歷所有可見節點，不可見節點包括：

script,meta這樣本身不可見的標簽。

被css隱藏的節點，如display: none

對每一個可見節點，找到恰當的CSSOM規則并應用

發布可視節點的內容和計算樣式

js解析如下：

瀏覽器創建Document對象并解析HTML，將解析到的元素和文本節點添加到文檔中，此時document.readystate為loading

HTML解析器遇到沒有async和defer的script時，將他們添加到文檔中，然后執行行內或外部腳本。這些腳本會同步執行，并且在腳本下載和執行時解析器會暫停。這樣就可以用document.write()把文本插入到輸入流中。同步腳本經常簡單定義函數和注冊事件處理程序，他們可以遍歷和操作script和他們之前的文檔內容

當解析器遇到設置了async屬性的script時，開始下載腳本并繼續解析文檔。腳本會在它下載完成后盡快執行，但是解析器不會停下來等它下載。異步腳本禁止使用document.write()，它們可以訪問自己script和之前的文檔元素

當文檔完成解析，document.readState變成interactive

所有defer腳本會按照在文檔出現的順序執行，延遲腳本能訪問完整文檔樹，禁止使用document.write()

瀏覽器在Document對象上觸發DOMContentLoaded事件

此時文檔完全解析完成，瀏覽器可能還在等待如圖片等內容加載，等這些內容完成載入并且所有異步腳本完成載入和執行，document.readState變為complete,window觸發load事件

顯示頁面（HTML解析過程中會逐步顯示頁面）

OSI 七層涵蓋:物理層,數據鏈路層,網絡層,傳輸層,會話層,表示層,應用層;

五層因特網協議棧其實就是：

應用層(dns,http) DNS解析成IP并發送http請求

傳輸層(tcp,udp) 建立tcp連接（三次握手）

網絡層(IP,ARP) IP尋址 為數據在結點之間傳輸創建邏輯鏈路

數據鏈路層(PPP) 封裝成幀 在通信實體間建立數據鏈路鏈接

物理層(利用物理介質傳輸比特流) 物理傳輸（然后傳輸的時候通過雙絞線，電磁波等各種介質） 主要定義屋里設備如何傳輸數據

五層模型就是"會話,表示,應用層"同為一層;

DNS是應用層協議，事實上他是為其他應用層協議工作的，包括不限于HTTP和SMTP以及FTP，用于將用戶提供的主機名解析為ip地址。
具體過程如下：
(1)瀏覽器緩存: 當用戶通過瀏覽器訪問某域名時，瀏覽器首先會在自己的緩存中查找是否有該域名對應的IP地址（若曾經訪問過該域名且沒有清空緩存便存在)；

(2)系統緩存： 當瀏覽器緩存中無域名對應IP則會自動檢查用戶計算機系統Hosts文件DNS緩存是否有該域名對應IP；

(3)路由器緩存: 當瀏覽器及系統緩存中均無域名對應IP則進入路由器緩存中檢查，以上三步均為客戶端的DNS緩存；

(4)ISP（互聯網服務提供商）DNS緩存: 當在用戶客服端查找不到域名對應IP地址，則將進入ISP DNS緩存中進行查詢。比如你用的是電信的網絡，則會進入電信的DNS緩存服務器中進行查找；(或者向網絡設置中指定的local DNS進行查詢，如果在PC指定了DNS的話，如果沒有設置比如DNS動態獲取，則向ISP DNS發起查詢請求)

(5)根域名服務器: 當以上均未完成，則進入根服務器進行查詢。全球僅有13臺根域名服務器，1個主根域名服務器，其余12為輔根域名服務器。根域名收到請求后會查看區域文件記錄，若無則將其管轄范圍內頂級域名（如.com）服務器IP告訴本地DNS服務器；

(6)頂級域名服務器: 頂級域名服務器收到請求后查看區域文件記錄，若無則將其管轄范圍內主域名服務器的IP地址告訴本地DNS服務器；

(7)主域名服務器: 主域名服務器接受到請求后查詢自己的緩存，如果沒有則進入下一級域名服務器進行查找，并重復該步驟直至找到正確記錄；

(8)保存結果至緩存: 本地域名服務器把返回的結果保存到緩存，以備下一次使用，同時將該結果反饋給客戶端，客戶端通過這個IP地址與web服務器建立鏈接。

A: 域名直接到 IP

CNAME: 可以多個域名映射到一個主機,類似在 Github Page就用 CNAME 指向

MX: 郵件交換記錄,用的不多,一般搭建郵件服務器才會用到

NS: 解析服務記錄,可以設置權重,指定誰解析

TTL: 就是生存時間(也叫緩存時間),一般的域名解析商都有默認值,也可以人為設置

TXT: 一般指某個主機名或域名的說明