HTTP 的15個常見知識點複習

時間 2019-11-06

標籤 http 常見知識複習欄目 HTTP/TCP 简体版

原文原文鏈接

前言

自從入職新公司到如今，咱們前端團隊內部一直在作 📖每週一練 的知識複習計劃，我以前整理了一個 每週一練之數據結構與算法 學習內容，你們也快去看看~~php

最近三週，主要複習 網絡基礎 相關的知識，今天我把這三週複習的知識和參考答案，整理成本文，歡迎各位朋友互相學習和指點，以爲本文不錯，也歡迎點贊哈💕💕。css

特別喜歡如今的每週學習和分享，哈哈哈~~😄html

📅推薦一個 github 倉庫 —— 《awesome-http》，內容挺棒的。前端

注：本文整理資料來源網絡，有些圖片/段落找不到原文出處，若有侵權，聯繫刪除。node

一. 簡述瀏覽器輸入 URL 地址後發生的事情

1.1 描述

瀏覽器向 DNS 服務器查找輸入 URL 對應的 IP 地址。
NS 服務器返回網站的 IP 地址。
瀏覽器根據 IP 地址與目標 web 服務器在 80 端口上創建 TCP 鏈接。
瀏覽器獲取請求頁面的 HTML 代碼。
瀏覽器在顯示窗口內渲染 HTML 。
窗口關閉時，瀏覽器終止與服務器的鏈接。

1.2 TCP 知識點補充

參考文章：《TCP三次握手和四次揮手協議》nginx

創建 TCP 須要三次握手才能創建，而斷開鏈接則須要四次握手。整個過程以下圖所示：git

TCP三次握手：github

所謂的三次握手，是指創建一個 TCP 鏈接時，須要客戶端和服務器端總共發送三個包，三次握手的目的是鏈接服務器的指定端口，創建 TCP 鏈接，並同步鏈接雙方的序列號和確認號並交換 TCP 窗口大小信息，在 SOCKET 編程中，客戶端執行 connect() 時，將會觸發三次握手：web

TCP四次揮手：面試

TCP鏈接的拆除須要發送四個包，客戶端或者服務器端都可主動發起揮手動做，在SOCKET編程中，任何一方執行close()便可產生揮手操做。

2. 請介紹常見的 HTTP 狀態碼(至少五個)

狀態碼是由 3 位數組成，第一個數字定義了響應的類別，且有五種可能取值:

1xx：指示信息–表示請求已接收，繼續處理。

100 客戶必須繼續發出請求
101 客戶要求服務器根據請求轉換HTTP協議版本

2xx：成功–表示請求已被成功接收、理解、接受。

200 （成功）服務器已成功處理了請求。一般，這表示服務器提供了請求的網頁。
201 （已建立）請求成功而且服務器建立了新的資源。
202 （已接受）服務器已接受請求，但還沒有處理。

3xx：重定向–要完成請求必須進行更進一步的操做。

300 （多種選擇）針對請求，服務器可執行多種操做。服務器可根據請求者 (user agent) 選擇一項操做，或提供操做列表供請求者選擇。
301 （永久移動）請求的網頁已永久移動到新位置。服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302 （臨時移動）服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。

4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現。

400 （錯誤請求）服務器不理解請求的語法。
401 （未受權）請求要求身份驗證。對於須要登陸的網頁，服務器可能返回此響應。
403 （禁止）服務器拒絕請求。

5xx：服務器端錯誤–服務器未能實現合法的請求。

500 （服務器內部錯誤）服務器遇到錯誤，沒法完成請求。
501 （還沒有實施）服務器不具有完成請求的功能。例如，服務器沒法識別請求方法時可能會返回此代碼。
502 （錯誤網關）服務器做爲網關或代理，從上游服務器收到無效響應。
503 （服務不可用）服務器目前沒法使用（因爲超載或停機維護）。一般，這只是暫時狀態。
504 （網關超時）服務器做爲網關或代理，可是沒有及時從上游服務器收到請求。
505 （HTTP 版本不受支持）服務器不支持請求中所用的 HTTP 協議版本。

3. 請介紹常見的 HTTP 頭部(至少五個)

3.1 HTTP 頭部

更多完整內容，能夠查看《HTTP響應頭和請求頭信息對照表》

首部字段名	說明
`Accept`	告訴服務器，客戶端支持的數據類型。
`Accept-Charset`	告訴服務器，客戶端採用的編碼。
`Accept-Encoding`	告訴服務器，客戶機支持的數據壓縮格式。
`Accept-Language`	告訴服務器，客戶機的語言環境。
`Host`	客戶機經過這個頭告訴服務器，想訪問的主機名。
`If-Modified-Since`	客戶機經過這個頭告訴服務器，資源的緩存時間。
`Referer`	客戶機經過這個頭告訴服務器，它是從哪一個資源來訪問服務器的。（通常用於防盜鏈）
`User-Agent`	客戶機經過這個頭告訴服務器，客戶機的軟件環境。
`Cookie`	客戶機經過這個頭告訴服務器，能夠向服務器帶數據。
`Connection`	客戶機經過這個頭告訴服務器，請求完後是關閉仍是保持連接。
`Date`	客戶機經過這個頭告訴服務器，客戶機當前請求時間

3.2 Request Header

參考文章：《HTTP經常使用頭部信息》

舉例：

Request Header	描述
`GET /sample.Jsp HTTP/1.1`	請求行
`Host: www.uuid.online/`	請求的目標域名和端口號
`Origin: http://localhost:8081/`	請求的來源域名和端口號（跨域請求時，瀏覽器會自動帶上這個頭信息）
`Referer: https:/localhost:8081/link?query=xxxxx`	請求資源的完整URI
`User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36`	瀏覽器信息
`Cookie: BAIDUID=FA89F036:FG=1; BD_HOME=1; sugstore=0`	當前域名下的Cookie
`Accept: text/html,image/apng`	表明客戶端但願接受的數據類型是html或者是png圖片類型
`Accept-Encoding: gzip, deflate`	表明客戶端能支持 gzip 和 deflate 格式的壓縮
`Accept-Language: zh-CN,zh;q=0.9`	表明客戶端能夠支持語言 zh-CN 或者 zh (值得一提的是q(0~1)是優先級權重的意思，不寫默認爲1，這裏 zh-CN 是1， zh 是0.9)
`Connection: keep-alive`	告訴服務器，客戶端須要的 tcp 鏈接是一個長鏈接

3.3 Response Header

參考文章：《HTTP經常使用頭部信息》

舉例：

Response Header	描述
`HTTP/1.1 200 OK`	響應狀態行
`Date: Mon, 30 Jul 2018 02:50:55 GMT`	服務端發送資源時的服務器時間
`Expires: Wed, 31 Dec 1969 23:59:59 GMT`	較過期的一種驗證緩存的方式，與瀏覽器（客戶端）的時間比較，超過這個時間就不用緩存（不和服務器進行驗證），適合版本比較穩定的網頁
`Cache-Control: no-cache`	如今最多使用的控制緩存的方式，會和服務器進行緩存驗
`etag: "fb8ba2f80b1d324bb997cbe188f28187-ssl-df"`	通常是Nginx靜態服務器發來的靜態文件簽名，瀏覽在沒有「Disabled cache」狀況下，接收到 etag 後，同一個 url 第二次請求就會自動帶上「If-None-Match」
`Last-Modified: Fri, 27 Jul 2018 11:04:55 GMT`	服務器發來的當前資源最後一次修改的時間，下次請求時，若是服務器上當前資源的修改時間大於這個時間，就返回新的資源內容
`Content-Type: text/html; charset=utf-8`	若是返回是流式的數據，咱們就必須告訴瀏覽器這個頭，否則瀏覽器會下載這個頁面，同時告訴瀏覽器是utf8編碼，不然可能出現亂碼
`Content-Encoding: gzip`	告訴客戶端，應該採用gzip對資源進行解碼
`Connection: keep-alive`	告訴客戶端服務器的tcp鏈接也是一個長鏈接

4. 請列舉經常使用的 HTTP 方法，並介紹 GET 與 POST 請求之間的區別

4.1 HTTP Request Method

參考文章：《HTTP請求方法對照表》

根據 HTTP 標準，HTTP 請求可使用多種請求方法。 HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。 HTTP/1.1 新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

序號	方法	描述
1	GET	請求指定的頁面信息，並返回實體主體。
2	HEAD	相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3	POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。
4	PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
5	DELETE	請求服務器刪除指定的頁面。
6	CONNECT	HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
7	OPTIONS	容許客戶端查看服務器的性能。
8	TRACE	回顯服務器收到的請求，主要用於測試或診斷。
9	PATCH	實體中包含一個表，表中說明與該URI所表示的原內容的區別。
10	MOVE	請求服務器將指定的頁面移至另外一個網絡地址。
11	COPY	請求服務器將指定的頁面拷貝至另外一個網絡地址。
12	LINK	請求服務器創建連接關係。
13	UNLINK	斷開連接關係。
14	WRAPPED	容許客戶端發送通過封裝的請求。
15	Extension-mothed	在不改動協議的前提下，可增長另外的方法。

4.2 GET 與 POST 請求之間的區別

區別內容	GET	POST
點擊返回/刷新按鈕	沒有影響	數據會從新發送（瀏覽器將會提示「數據被從新提交」）
添加書籤	能夠	不能夠
緩存	能夠	不能夠
編碼類型（Encoding type）	`application/x-www-form-rulencoded`	`application/x-www-form-rulencoded` or `multipart/form-data` 請爲二進制數據使用 `multipart` 編碼
歷史記錄	有	沒有
長度限制	有	沒有
數據類型限制	只容許 ASCLll 字符類型	沒有限制，容許二進制數據
安全性	查詢字符串會顯示在地址欄的 URL 上，不安全，請不要使用 GET 請求提交敏感數據	由於數據不會顯示在地址欄中，也不會緩存下來或保存在瀏覽記錄中，因此 POST 請求比 GET 請求安全，但也不是最安全的方式，如須要傳送敏感數據，請使用數據加密。
可見性	查詢字符串在地址欄的 URL 中可見	查詢字符串在地址欄的 URL 中不可見

5. 請分別介紹 Cookie 和 Session 的做用及它們之間的區別

參考文章：《3分鐘搞懂Cookie與Session》

5.1 Cookie簡單介紹

Cookie是存儲在用戶本地計算機上，用於保存一些用戶操做的歷史信息，當用戶再次訪問咱們的服務器的時候，瀏覽器經過HTTP協議，將他們本地的Cookie內容也發到我們服務器上，從而完成驗證。

Cookie 是存儲在瀏覽器客戶的一小片數據；
Cookie 能夠同時被前臺與後臺操做；
Cookie 能夠跨頁面存取；
Cookie 是不能夠跨服務器訪問的；
Cookie 有限制；每一個瀏覽器存儲的個數不能超過300個，每一個服務器不能超過20個，數據量不能超過4K；
Cookie 是有生命週期的，默認與瀏覽器相同，若是進程退出，cookie會被銷燬

5.2 Session

Session 存儲在咱們的服務器上，就是在咱們的服務器上保存用戶的操做信息。

當用戶訪問咱們的網站時，咱們的服務器會成一個 Session ID，而後把 Session ID 存儲起來，再把這個 Session ID發給咱們的用戶，用戶再次訪問咱們的服務器的時候，拿着這個 Session ID就能驗證了，當這個ID能與咱們服務器上存儲的ID對應起來時，咱們就能夠認爲是本身人。

seesion 數據存儲在服務器端；
每個會話分配一個單獨的 session_id;
該 session_id 經過 cookie 傳送到前臺，默認的 session_id 名稱是PHPSESSIONID;
前臺只能看到 Session 的 ID，而不能修改 Session 值;
使用 Session以前須要先開啓會話;
Session存儲在 Session數組 $_SESSION;
Session存儲方式比較安全，可是若是 Session數量過多，會致使服務器性能降低;

5.3 二者區別

	Cookie	session
定義	瀏覽器保存用戶信息的文件，存儲的數量和字符數都有限制	服務器把`sessionID` 和用戶信息、用戶操做，記錄在服務器上，這些記錄就稱爲`session`
相同點	都是爲了存儲用戶相關的信息
存儲	客戶端	服務器
安全性	安全性不高，任何人都能直接查看	安全性高

5.4 二者結合使用

存儲在服務端：經過 cookie存儲一個 session_id，而後具體的數據則是保存在 session中。若是用戶已經登陸，則服務器會在 cookie中保存一個 session_id，下次再次請求的時候，會把該 session_id攜帶上來，服務器根據 session_id在 session庫中獲取用戶的 session數據。就能知道該用戶究竟是誰，以及以前保存的一些狀態信息。這種專業術語叫作 server side session。
將 session數據加密，而後存儲在 cookie中。這種專業術語叫作 client side session。

6. 請介紹 HTTP 請求報文與響應報文格式

6.1 請求報文

請求報文由請求行、請求頭部和請求正文組成：

請求行

格式爲：

請求方法 + 空格 + URL + 空格 + 協議版本 + 回車符 + 換行符
複製代碼

例如：

GET www.baidu.com HTTP/1.1  
複製代碼

常見的請求方法有：GET，HEAD，PUT，POST，TRACE，OPTIONS，DELETE以及擴展方法。

請求頭部

格式爲：

頭部字段名 + 冒號（:） + 值 + 回車符 + 換行符
複製代碼

請求頭部爲請求報文添加了一些附加信息，由「名/值」對組成，每行一對，名和值之間使用冒號分隔。

而且，在請求頭部的最後會有一個空行，表示請求頭部結束，這一行必不可少。

典型的請求頭部有：

請求頭部	說明
Host	接受請求的服務器地址，能夠是IP:端口號，也能夠是域名
User-Agent	發送請求的應用程序名稱
Connection	指定與鏈接相關的屬性，如Connection:Keep-Alive
Accept-Charset	通知服務端能夠發送的編碼格式
Accept-Encoding	通知服務端能夠發送的數據壓縮格式
Accept-Language	通知服務端能夠發送的語言

請求正文

通常使用在 POST 方法中， GET 方法不存在請求正文。
POST 方法適用於須要客戶填寫表單的場合。與請求數據相關的最常使用的請求頭是 Content-Type 和 Content-Length 。

6.2 響應報文

響應報文由狀態行、響應頭部和響應正文組成：

狀態行

格式爲：

協議版本 + 空格 + 狀態碼 + 空格 + 狀態碼描述 + 回車符 + 換行符
複製代碼

狀態碼劃分：

100〜199的狀態碼是 HTTP / 1.1 向協議中引入了信息性狀態碼；
200〜299的狀態碼錶示成功；
300〜399的狀態碼指資源重定向；
400〜499的狀態碼指客戶端請求出錯；
500〜599的狀態碼指服務端出錯；

常見的狀態碼：

狀態碼	說明
200	響應成功
302	跳轉，跳轉地址經過響應頭中的位置屬性指定（JSP中Forward和Redirect之間的區別）
400	客戶端請求有語法錯誤，不能被服務器識別
403	服務器接收到請求，可是拒絕提供服務（認證失敗）
404	請求資源不存在
500	服務器內部錯誤

響應頭部

格式爲：

頭部字段名 + 冒號（:） + 值 + 回車符 + 換行符
複製代碼

常見響應頭部：

響應頭部	說明
`Server`	服務器應用程序軟件的名稱和版本
`Content-Type`	響應正文的類型（是圖片仍是二進制字符串）
`Content-Length`	響應正文長度
`Content-Charset`	響應正文使用的編碼
`Content-Encoding`	響應正文使用的數據壓縮格式
`Content-Language`	響應正文使用的語言

7. HTTP/1.1 有什麼優缺點

參考文章：《HTTP/1.0 HTTP/1.1 HTTP/2.0 主要特性對比》

對於 HTTP/1.1，不只繼承了 HTTP1.0簡單的特色，還克服了諸多 HTTP1.0性能上的問題。

7.1 HTTP/1.1 優勢

增長持久性鏈接

也就是多個請求和響應能夠利用同一個 TCP 鏈接，而不是每一次請求響應都要新建一個TCP鏈接，減小了創建和關閉鏈接的消耗和延遲。

Connection: keep-alive
複製代碼

增長管道機制

增長了管道機制，請求能夠同時發出，可是響應必須按照請求發出的順序依次返回，性能在必定程度上獲得了改善。

分塊傳輸

在 HTTP/1.1 版本中，能夠沒必要等待數據徹底處理完畢再返回，服務器產生部分數據，那麼就發送部分數據，很明此種方式更加優秀一些，能夠節省不少等待時間。

增長 host 字段

使得一個服務器可以用來建立多個 Web 站點。

錯誤提示

HTTP/1.1 引入了一個 Warning 頭域，增長對錯誤或警告信息的描述，此外，在 HTTP/1.1 中新增了24個狀態響應碼(100，101，203，205，206，301，305… )。

帶寬優化

HTTP/1.1 中在請求消息中引入了 range頭域，它容許只請求資源的某個部分。

在響應消息中 Content-Range頭域聲明瞭返回的這部分對象的偏移值和長度。若是服務器相應地返回了對象所請求範圍的內容，則響應碼爲 206（Partial Content），它能夠防止 Cache將響應誤覺得是完整的一個對象，HTTP/1.1 加入了一個新的狀態碼 100（Continue）。客戶端事先發送一個只帶頭域的請求，若是服務器由於權限拒絕了請求，就回送響應碼 401（Unauthorized）；若是服務器接收此請求就回送響應碼 100，客戶端就能夠繼續發送帶實體的完整請求了。

注意，HTTP/1.0 的客戶端不支持 100 響應碼。但可讓客戶端在請求消息中加入 Expect頭域，並將它的值設置爲 100-continue。

7.2 HTTP/1.1 缺點

隊頭阻塞

此版本的網絡延遲問題主要因爲隊頭堵塞致使，雖然經過持久性鏈接獲得改善，可是每個請求的響應依然須要按照順序排隊，若是前面的響應處理較爲耗費時間，那麼一樣很是耗費性能。

技術不成熟

還有此版本雖然引進了管道機制，可是當前存在諸多問題，且默認處於關閉狀態。

浪費資源

http/1.1 請求會攜帶大量冗餘的頭信息，浪費了不少寬帶資源。

8. 相比 HTTP/1.1，HTTP/2.0 有哪些新特性

參考文章：《HTTP1.0 HTTP/1.1 HTTP2.0 主要特性對比》

二進制分幀

在應用層（HTTP/2.0）和傳輸層（TCP or UDP）之間增長一個二進制分幀層，從而突破 HTTP1.1 的性能限制，改進傳輸性能，實現低延遲和高吞吐量。

可見，雖然 HTTP/2.0 的協議和 HTTP1.x 協議之間的規範徹底不一樣了，可是實際上 HTTP/2.0並沒有改變 HTTP1.x 的語義。

簡單來講，HTTP/2.0 只是把原來 HTTP1.x 的 header 和 body 部分用 frame 從新封裝了一層而已。

多路複用（鏈接共享）

容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息，這個強大的功能則是基於「二進制分幀」的特性。

從圖中可見，全部的 HTTP/2.0 通訊都在一個 TCP 鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。

每一個數據流以消息的形式發送，而消息由一或多個幀組成。這些幀能夠亂序發送，而後再根據每一個幀頭部的流標識符（stream id）從新組裝。

首部壓縮

HTTP1.1 不支持 header 數據的壓縮，HTTP/2.0 使用 HPACK 算法對 header 的數據進行壓縮，這樣數據體積小了，在網絡上傳輸就會更快。高效的壓縮算法能夠很大的壓縮 header ，減小發送包的數量從而下降延遲。

服務器推送

在 HTTP/2 中，服務器能夠對客戶端的一個請求發送多個響應，即服務器能夠額外的向客戶端推送資源，而無需客戶端明確的請求。

9. 請簡述 HTTPS 工做原理

9.1 HTTPS 簡介

參考文章：《深刻淺出講解HTTPS工做原理》

HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)協議代替而已。

一般，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL 和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP。

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。也就是說HTTP 加上加密處理和認證以及完整性保護後便是 HTTPS。

HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議，TLS/SSL 的功能實現主要依賴於三類基本算法：散列函數 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

9.2 HTTPS 工做原理

HTTPS 實際上是有兩部分組成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會經過 TLS 進行加密，因此傳輸的數據都是加密後的數據。

客戶端發起HTTPS請求

瀏覽器裏面輸入一個HTTPS網址，而後鏈接到服務端的443端口上。注意這個過程當中客戶端會發送一個密文族給服務端，密文族是瀏覽器所支持的加密算法的清單。

服務端配置

採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面。

這套證書其實就是一對公鑰和私鑰，能夠這麼理解，公鑰就是一把鎖頭，私鑰就是這把鎖的鑰匙，鎖頭能夠給別人對某個東西進行加鎖，可是加鎖完畢以後，只有持有這把鎖的鑰匙才能夠解鎖看到加鎖的內容。

傳送證書

這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構、過時時間等等。

客戶端解析證書

這部分工做是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，如頒發機構、過時時間等等，若是發現異常則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個隨機值，而後用證書對該隨機值進行加密。

注意一下上面提到的"發現異常"。證書中會包含數字簽名，該數字簽名是加密過的，是用頒發機構的私鑰對本證書的公鑰、名稱及其餘信息作hash散列加密而生成的。客戶端瀏覽器會首先找到該證書的根證書頒發機構，若是有，則用該根證書的公鑰解密服務器下發的證書，若是不能正常解密，則就是"發現異常"，說明該證書是僞造的。

傳送加密信息

這部分傳送的是用證書加密後的隨機值，目的就是讓服務端獲得這個隨機值，而後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密和解密了。

服務端解密信息

服務端用私鑰解密後，獲得了客戶端傳過來的隨機值，至此一個非對稱加密的過程結束，看到TLS利用非對稱加密實現了身份認證和密鑰協商。而後把內容經過該值進行對稱加密。

傳輸加密後的信息

這部分是服務端用隨機值加密後的信息，能夠在客戶端被還原。

客戶端解密信息

客戶端用以前生成的隨機值解密服務端傳送過來的信息，因而獲取瞭解密後的內容，至此一個對稱加密的過程結束，看到對稱加密是用於對服務器待傳送給客戶端的數據進行加密用的。整個過程即便第三方監聽了數據，也一籌莫展。

10. HTTP 和 HTTPS 的共同點和區別

https 協議須要到 ca 申請證書，通常免費證書較少，於是須要必定費用。
http 是超文本傳輸協議，信息是明文傳輸， https 則是具備安全性的ssl加密傳輸協議。
http 和 https 使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
http 的鏈接很簡單，是無狀態的； HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 http 協議安全。

11. 什麼是跨域，如何解決跨域

參考文章：《前端常見跨域解決方案（全）》

11.1 什麼是跨域

跨域，指的是瀏覽器不能執行其餘網站的腳本。它是由瀏覽器的同源策略形成的，是瀏覽器對JavaScript施加的安全限制。

什麼是同源策略？

同源策略/SOP（Same origin policy）是一種約定，由Netscape公司1995年引入瀏覽器，它是瀏覽器最核心也最基本的安全功能，若是缺乏了同源策略，瀏覽器很容易受到 XSS 、 CSFR 等攻擊。所謂同源是指"協議+域名+端口"三者相同，即使兩個不一樣的域名指向同一個ip地址，也非同源。

同源策略限制瞭如下行爲：

Cookie、LocalStorage 和 IndexDB 沒法讀取
DOM 和 JS對象沒法獲取
Ajax請求發送不出去

常見跨域場景：

所謂的同源是指：域名、協議、端口均爲相同。

http://www.a.cn/index.html 調用 http://www.a.cn/server.php 非跨域。
http://www.a.cn/index.html 調用 http://www.b.cn/server.php 跨域，主域不一樣。
http://abc.a.cn/index.html 調用 http://def.b.cn/server.php 跨域，子域名不一樣。
http://www.a.cn:8080/index.html 調用 http://www.a.cn/server.php 跨域，端口不一樣。
https://www.a.cn/index.html 調用 http://www.a.cn/server.php 跨域,協議不一樣。
localhost 調用 127.0.0.1 跨域。

11.2 解決跨域

jsonp 跨域
document.domain + iframe 跨域
window.name + iframe 跨域
location.hash + iframe 跨域
postMessage 跨域
跨域資源共享CORS
withCredentials 屬性
WebSocket 協議跨域
node 代理跨域
nginx 代理跨域

具體每一種解決方法，能夠參考：《前端常見跨域解決方案（全）》

12. HTTP 中與緩存相關的頭部有哪些，它們有什麼區別

頭部	優點和特色	劣勢和問題
`Expires`	一、`HTTP 1.0` 產物，能夠在`HTTP 1.0`和`1.1`中使用，簡單易用。二、以時刻標識失效時間。	一、時間是由服務器發送的(`UTC`)，若是服務器時間和客戶端時間存在不一致，可能會出現問題。二、存在版本問題，到期以前的修改客戶端是不可知的。
`Cache-Control`	一、`HTTP 1.1` 產物，以時間間隔標識失效時間，解決了`Expires`服務器和客戶端相對時間的問題。二、比`Expires`多了不少選項設置。	一、`HTTP 1.1`纔有的內容，不適用於`HTTP 1.0` 。二、存在版本問題，到期以前的修改客戶端是不可知的。
`Last-Modified`	一、不存在版本問題，每次請求都會去服務器進行校驗。服務器對比最後修改時間若是相同則返回304，不一樣返回200以及資源內容。	一、只要資源修改，不管內容是否發生實質性的變化，都會將該資源返回客戶端。例如週期性重寫，這種狀況下該資源包含的數據實際上同樣的。二、以時刻做爲標識，沒法識別一秒內進行屢次修改的狀況。三、某些服務器不能精確的獲得文件的最後修改時間。
`ETag`	一、能夠更加精確的判斷資源是否被修改，能夠識別一秒內屢次修改的狀況。二、不存在版本問題，每次請求都回去服務器進行校驗。	一、計算`ETag`值須要性能損耗。二、分佈式服務器存儲的狀況下，計算`ETag`的算法若是不同，會致使瀏覽器從一臺服務器上得到頁面內容後到另一臺服務器上進行驗證時發現`ETag`不匹配的狀況。