HTTP 與 HTTPS 的區(qū)別
http：超文本傳輸協(xié)議，設(shè)計目的是為了提供一種發(fā)布和接收 HTML 頁面的方法。
https：是以 數(shù)據(jù)保密性、完整性和身份校驗安全性為目標(biāo)的 HTTP 安全版。
- 傳輸信息安全性不同
http 是超文本傳輸協(xié)議，明文傳輸
https 是 SSL 加密傳輸協(xié)議，密文傳輸 - 端口不同
http 默認80 端口，https 默認 443 端口 - 連接方式不同
http 是無狀態(tài)連接；
https 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，安全性更高 - 證書申請方式不同
http 協(xié)議：免費申請
https 協(xié)議需 CA 證書，一般免費證書較少，需要付費
HTTPS 相對于 HTTP 的改進
雙向的身份認證
客戶端 和服務(wù)端在傳輸數(shù)據(jù)之前，會通過基于X.509 證書對雙方進行身份認證，過程如下：
a) 客戶端發(fā)起 SSL 握手消息給服務(wù)端要求連接。
b) 服務(wù)端將證書發(fā)送給客戶端。
c) 客戶端檢查服務(wù)端證書，確認是否由自己信任的證書簽發(fā)機構(gòu)簽發(fā)(客戶端內(nèi)置了所有受信任 CA 的證書)。 如果不是，將是否繼續(xù)通訊的決定權(quán)交給用戶選擇。如果檢查無誤或者用戶選擇繼續(xù)，則客戶端認可服務(wù)端的身份。
d) 服務(wù)端要求客戶端發(fā)送證書，并檢查是否通過驗證。失敗則關(guān)閉連接，認證成功則從客戶端證書中獲得客戶端的公鑰，一般為 1024 位或者 2048 位。到此，服務(wù)器客戶端雙方的身份認證結(jié)束，雙方確保身份都是真實可靠的。數(shù)據(jù)傳輸?shù)臋C密性
客戶端和服務(wù)端在開始傳輸數(shù)據(jù)之前，會協(xié)商傳輸過程需要使用的加密算法。 客戶端發(fā)送協(xié)商請求給服務(wù)端, 其中包含自己支持的非對成加密的密鑰交換算法 ( 一般是RSA)，數(shù)據(jù)簽名摘要算法 ( 一般是SHA或MD5) ，加密傳輸數(shù)據(jù)的對稱加密算法 ( 一般是DES )，以及加密密鑰的長度。 服務(wù)端接收到消息之后，選中安全性最高的算法，并將選中的算法發(fā)送給客戶端，完成協(xié)商。客戶端生成隨機的字符串，通過協(xié)商好的非對稱加密算法，使用服務(wù)端的公鑰對該字符串進行加密，發(fā)送給服務(wù)端。 服務(wù)端接收到之后，使用自己的私鑰解密得到該字符串。在隨后的數(shù)據(jù)傳輸當(dāng)中，使用這個字符串作為密鑰進行對稱加密。防止重放攻擊
SSL 使用序列號來保護通訊方免受報文重放攻擊。這個序列號被加密后作為數(shù)據(jù)包的負載。在整個 SSL 握手中，都有一個唯一的隨機數(shù)來標(biāo)記 SSL 握手。 這樣防止了攻擊者嗅探整個登錄過程，獲取到加密的登錄數(shù)據(jù)之后，不對數(shù)據(jù)進行解密，而直接重傳登錄數(shù)據(jù)包的攻擊手法。
HTTPS 的優(yōu)點
- 可認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器；
- 是由 SSL+HTTP 協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全；
- 是現(xiàn)行架構(gòu)下最安全的解決方案( 雖然不是絕對安全 )。
HTTPS 的缺點
- 握手階段比較費時，使頁面加載時間延長；
- HTTPS 連接緩存不如 HTTP 高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；
- SSL 證書需要錢，功能越強大費用越高。
- SSL 證書通常需要綁定 IP，不能在同一 IP上綁定多個域名。
瀏覽器輸入一個地址，到頁面展示中間經(jīng)歷了哪些東西
對 URL進行DNS域名解析，得到對應(yīng)的IP地址
DNS域名解析采用的是遞歸查詢的順序為：
先找DNS緩存=>根域名服務(wù)器=>繼續(xù)找找下一級=>找到之后給瀏覽器
緩存的查找順序大概是：
瀏覽器DNS緩存=>系統(tǒng)DNS緩存=>hosts文件查找=>遞歸去服務(wù)器查找根據(jù)IP地址找到對應(yīng)的服務(wù)器并發(fā)起TCP三次握手
TCP是一個端到端的可靠的面向連接的協(xié)議，HTTP基于傳輸層TCP協(xié)議不用擔(dān)心數(shù)據(jù)傳輸?shù)母鞣N問題(如有錯會重傳)
建立一個TCP連接時，需要客戶端和服務(wù)器總共發(fā)送 3 個包
(1). 客戶端發(fā)送一個TCP的SYN標(biāo)志位置 1 的包到服務(wù)器，并進入SYN_SENT狀態(tài)，等待服務(wù)器確認。
(2). 服務(wù)器收到SYN包，必須確認客戶的SYN（ack=x+1），同時自己也發(fā)送一個SYN包（syn=y），即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)
(3). 客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK(ack=y+1），此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。建立TCP 連接后發(fā)送HTTP請求
HTTP請求包含請求頭，或請求體兩部分
請求頭：中包含希望對請求文件的操作的信息
請求體：中包含傳遞給后臺的參數(shù)服務(wù)器響應(yīng)HTTP請求，返回相應(yīng)數(shù)據(jù)包
服務(wù)器收到處理的請求開始做負載平衡，跨域等，文件處理完畢，生成響應(yīng)數(shù)據(jù)包并返回
響應(yīng)包含：響應(yīng)頭和相應(yīng)體，響應(yīng)體就是請求的文件經(jīng)過網(wǎng)絡(luò)傳輸，文件被下載到本地客戶端，瀏覽器收到 HTTP 響應(yīng)，客戶端開始加載
瀏覽器得到 HTML 代碼后開始解析，并請求 HTML 代碼中的資源
如CSS、JS 和 圖片，如果響應(yīng)可以緩存，則存入緩存瀏覽器對頁面進行渲染并呈現(xiàn)給用戶
（1）解析 html 文件是自上而下，先是頭部后是 body
（2）當(dāng)解析到頭部 CSS 外部鏈接時，同步去下載，如果遇到外部 JS 鏈接也是下載
（3）接著解析 body 部分，將 html 文件解析成 DOM 樹
（4）同時等待 css 文件下載并把CSS文件解析成 CSSOM 樹
（5）DOM 樹 和 CSSOM 樹 就組成了 Render Tree 渲染樹
（6）CSS 文件加載不會阻塞 html 文件的解析，但會阻塞 DOM 的渲染，也會阻塞后面 JS 語句的執(zhí)行
（7）在下載 JS 時會阻塞 html 的解析和渲染，又分幾種情況：
a）沒有 defer 和 async 標(biāo)簽的 script 會立即加載并執(zhí)行
b）有 async 標(biāo)簽的 js，js 的加載執(zhí)行和 html 的解析和渲染并行
c）有 defer 標(biāo)簽的 js，js 的加載和 html 的解析和渲染并行
（8）渲染樹一旦有結(jié)構(gòu)模型了，接著就會同步去計算渲染樹節(jié)點的布局位置
（9）計算出來渲染的坐標(biāo)后，又同步去開始渲染
（10）進行過程中如果遇到圖片則跳過去渲染下面內(nèi)容，等待圖片下載成功后會返回來在渲染原來圖片的位置
（11）如果渲染過程中出現(xiàn) JS 代碼調(diào)整 DOM 樹機構(gòu)的情況，也會再次重新來過，從修改 DOM 那步開始
（12）最終所有節(jié)點和資源都會渲染完成，頁面全部渲染結(jié)束。服務(wù)器關(guān)閉
TCP鏈接，TCP四次揮手
為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手？
因為當(dāng) Server 端收到 Client 端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中 ACK 報文是用來應(yīng)答的，SYN 報文是用來同步的。但是關(guān)閉連接時，當(dāng) Server 端收到 FIN 報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個 ACK 報文，告訴Client 端，"你發(fā)的 FIN 報文我收到了"。只有等到 Server 端所有的報文都發(fā)送完了，才能發(fā)送 FIN 報文，因此不能一起發(fā)送。故需要四步握手。
一個 TCP 連接能發(fā)幾個 http 請求？
HTTP 1.0一般情況下，不支持長連接，因此在每次請求發(fā)送完畢之后，TCP 連接即會斷開，因此一個 TCP 發(fā)送一個 HTTP 請求。
但是通過在請求頭帶上 Connection: Keep-Alive 將一條 TCP 連接保持在活躍狀態(tài)。
如果客戶端和服務(wù)端都支持，那么其實也可以發(fā)送多條，不過此方式也有限制。
HTTP 1.1 支持了長連接， HTTP 2.0 版本協(xié)議，支持了多用復(fù)用。
因此只要不斷開 TCP 的連接，HTTP 請求數(shù)也是可以沒有上限地持續(xù)發(fā)送；
常用的 HTTP 方法有哪些？
GET： 用于請求訪問已經(jīng)被URI（統(tǒng)一資源標(biāo)識符）識別的資源，可以通過URL傳參給服務(wù)器
POST：用于傳輸信息給服務(wù)器，主要功能與GET方法類似，但一般推薦使用POST方式。
PUT： 傳輸文件，報文主體中包含文件內(nèi)容，保存到對應(yīng) URI 位置。
HEAD： 獲得報文首部，與 GET 方法類似，只是不返回報文主體，一般用于驗證 URI 是否有效。
DELETE：刪除文件，與 PUT 方法相反，刪除對應(yīng) URI 位置的文件。
OPTIONS：查詢相應(yīng)URI支持的HTTP方法。
GET 請求和 POST 請求的區(qū)別
- 從安全性講，兩者都不安全
GET 請求參數(shù)在 URL 地址上，直接暴露
POST 請求的參數(shù)放 BODY 部分，按 F12 也直接暴露了 - GET 請求因為是向 URL 添加數(shù)據(jù)，不同的瀏覽器廠商，代理服務(wù)器，web服務(wù)器都可能會有自己的長度限制，而 POST 請求無長度限制；
- GET請求一般不具有請求體，因此只能進行 URL 編碼，而POST請求支持多種編碼方式。
- GET請求可以收藏為書簽，POST請求不可以收藏為書簽；
- GET請求可以被緩存，POST請求不可以被緩存
- GET產(chǎn)生一個TCP數(shù)據(jù)包；POST產(chǎn)生兩個TCP數(shù)據(jù)包。
- GET請求：瀏覽器會把 http header 和 data 一并發(fā)送出去，服務(wù)器響應(yīng) 200；
- POST請求：瀏覽器先發(fā)送 header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送 data，服務(wù)器響應(yīng) 200。
HTTPS 工作原理
- 首先HTTP請求服務(wù)端生成證書，客戶端對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰（RSA加密）等進行校驗；
- 客戶端如果校驗通過后，就根據(jù)證書的公鑰的有效， 生成隨機數(shù)，隨機數(shù)使用公鑰進行加密（RSA加密）；
- 消息體產(chǎn)生的后，對它的摘要進行MD5（或者SHA1）算法加密，此時就得到了RSA簽名；
- 發(fā)送給服務(wù)端，此時只有服務(wù)端（RSA私鑰）能解密。
- 解密得到的隨機數(shù)，再用AES加密，作為密鑰（此時的密鑰只有客戶端和服務(wù)端知道）。
常見的HTTP相應(yīng)狀態(tài)碼
200：請求被正常處理
204：請求被受理但沒有資源可以返回
206：客戶端只是請求資源的一部分，服務(wù)器只對請求的部分資源執(zhí)行GET方法，相應(yīng)報文中通過Content-Range指定范圍的資源。
301：永久性重定向
302：臨時重定向
303：與302功能相似，只是它希望客戶端在請求一個URI時，能通過GET方法重定向到另一個URL上
304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關(guān)
307：臨時重定向，與302類似，只是強制要求使用POST方法
400：請求報文語法有誤，服務(wù)器無法識別
401：請求需要認證
403：請求的對應(yīng)資源禁止被訪問
404：服務(wù)器無法找到對應(yīng)資源
500：服務(wù)器內(nèi)部錯誤
503：服務(wù)器正忙
HTTP優(yōu)化方案
TCP復(fù)用：TCP連接復(fù)用是將多個客戶端的HTTP請求復(fù)用到一個服務(wù)器端TCP連接上，而HTTP復(fù)用則是一個客戶端的多個HTTP請求通過一個TCP連接進行處理。前者是負載均衡設(shè)備的獨特功能；而后者是HTTP 1.1協(xié)議所支持的新功能，目前被大多數(shù)瀏覽器所支持。
內(nèi)容緩存：將經(jīng)常用到的內(nèi)容進行緩存起來，那么客戶端就可以直接在內(nèi)存中獲取相應(yīng)的數(shù)據(jù)了。
壓縮：將文本數(shù)據(jù)進行壓縮，減少帶寬
SSL加速（SSL Acceleration）：使用SSL協(xié)議對HTTP協(xié)議進行加密，在通道內(nèi)加密并加速
TCP緩沖：通過采用TCP緩沖技術(shù)，可以提高服務(wù)器端響應(yīng)時間和處理效率，減少由于通信鏈路問題給服務(wù)器造成的連接負擔(dān)。
