12期前端衝刺必備指南-HTTP/HTTPS/HTTP2/DNS/TCP/經典題

前言

你們好啊，我是吒兒👦，天天努力一點點💪，就能升職加薪💰當上總經理出任CEO迎娶白富美走上人生巔峯🗻，想一想還有點小激動呢😎。

這是個人第12期文章內容✍，但願可以把每一處知識點，說明白，（固然，若是哪一處不瞭解，能夠在評論區進行探討哦！）⏰，計時開始！

若是您發現本文有幫助，請您點贊，收藏，評論，留下您學習的腳印👣，我很樂意談論😃

學習閱讀這篇文章內容仍是須要一點前端網絡基礎的，至少你用過接口，瞭解事後端啥的。（也瞭解過一點網絡知識，但不怎麼會懂的學習者）

學習Http協議過重要了，瞭解Http協議，能夠了解Web應用程序先後端的交互等

HTTP

什麼是網絡中的HTTP，HTTPS，HTTP2，DNS，TCP，CDN等等，您是否是聽得一頭霧水呢？小朋友您是否是有不少問號？😧

Web創建在HTTP協議上通訊的

那咱們先從HTTP協議開始，HTTP協議：

特色：1.簡單快速，2.靈活，3.無鏈接，4.無狀態（HTTP是一種不保存狀態，無狀態協議-從HTTP/1.1 雖然是無狀態協議，但爲了實現保持狀態功能，引入了 Cookie 技術，有了它就能夠管理狀態了）。（記住咯）

HTTP報文：請求報文，響應報文

請求報文：

1. 請求行：請求方法，請求URL，HTTP協議以及版本；
2. 請求頭，通知服務器有關於客戶端請求的信息
3. 空行，發送回車符和換行符

響應報文：

1. 狀態行
2. 響應頭
3. 空行
4. 響應體

HTTP方法：

主要GET方法獲取數據，POST方法傳輸資源

PUT方法更新資源，DELETE方法刪除資源，HEAD方法得到報文首部

固然做爲程序員經常使用到的HTTP狀態碼：

描述到這裏應該大部分人也是瞭解這部分比較的是吧？那麼接下來我來添加一些內容。

讓咱們瞭解web網絡基礎，咱們知道咱們是使用HTTP協議訪問web的，那麼你知道咱們在網頁瀏覽器中的地址欄中輸入URL時，web頁面是若是呈現的嗎？

第一步👣，瀏覽器根據請求的url交給dns域名解析，找到真實的Ip，向服務器發起請求。

第二步👣，服務器交給後臺處理後，返回響應的數據，瀏覽器接收文件。

第三步👣，瀏覽器對加載到的資源（根據web瀏覽器地址欄中指定的url，web瀏覽器從web服務器獲取文件資源等信息）進行解析，創建相應的內部數據結構。

第四步👣，瀏覽器載入解析到的資源文件，進行頁面渲染，呈現出web頁面。

so，就算你不瞭解其運做原理，也是可以看到web頁面的。

客戶端經過指定的訪問地址獲取服務器資源，服務器使用HTTP協議進行通訊，將資源傳遞給客戶端。

在瀏覽器地址欄內輸入URL以後，信息會被送往某處，而後從某處得到的回覆，內容就會顯示在web頁面上。

so，HTTP協議是超文本傳輸協議，是用於從萬維網服務器傳輸超文本到本地瀏覽器的傳輸協議。

HTTP是基於TCP/IP協議通訊協議來傳遞數據的，主要是客戶端和服務器端之間的通訊格式，不涉及數據包傳輸。

那麼什麼是網絡基礎TCP/IP

網絡基礎TCP/IP

固然說到網絡基礎TCP/IP，就要了解一下TCP/IP協議族啦！

一般使用的網絡是在網絡基礎TCP/IP協議族的基礎上運做的，so，加上剛剛所說的，HTTP就是它內部的一個子集（子集？數學概念）

協議就是定義規則，雙方要定義好規則，事先肯定，才能相互通訊，網絡基礎TCP/IP是互聯網相關的各種協議族的總稱。

在圖解HTTP中，TCP/IP協議族是分4層：應用層，傳輸層，網絡層和數據鏈路層（分層的）。

利用TCP/IP協議族進行網絡通訊：

經過分層順序與對方進行通訊，發送端（客戶端）從應用層往下走，接收端（服務器端）從鏈路層往應用層上走。

即：客戶端，應用層（HTTP客戶端）➡，傳輸層（TCP）➡，網絡層（IP）➡，鏈路層（網絡）➡；服務器端，應用層（HTTP服務器端），⬅傳輸層（TCP），⬅網絡層（IP），⬅鏈路層（網絡）。

從發送端到接收端，發送HTTP請求流程：

發送端，每經過一層增長首部，接收端，每經過一層刪除首部。發送端發起HTTP請求，從發送端：應用層，HTTP數據（HTTP報文）➡，接收TCP首部到傳輸層，即TCP首部包含HTTP數據➡，接收IP數據包到網絡層，即IP首部裏包含TCP首部，TCP首部包含HTTP數據➡，接收網絡架構到鏈路層，即以太網首部包含IP首部，IP首部裏包含TCP首部，TCP首部包含HTTP數據。在發送端是這樣的傳輸。

接着發送端的鏈路層傳送到接收端的鏈路層，就是經過每一層會刪除首部，so，傳輸過來的HTTP數據，（以太網首部👉IP首部👉TCP首部👉HTTP數據），從發送端到接收端，接收端往上走每一層刪除首部（即鏈路層到應用層），so，接收端的鏈路層到網絡層刪除首部後（P首部👉TCP首部👉HTTP數據），一次類推，到接收端的應用層就剩下HTTP數據。

那麼有人說，在計算機網絡的七層協議呢？是的有七層，不過都不會影響的，說一說七層協議，順帶講講。

在主機上：應用層，表示層，會話層，傳輸層；在網絡上：網絡層，鏈路層，物理層。

以上能夠一部分一部分進行學習掌握的知識點。

HTTP 中 GET 與 POST 的區別

在網上衝浪時，看到《99%的人都理解錯了HTTP中GET與POST的區別》這篇文章。

說GET和POST有一個重大區別，GET產生一個TCP數據包；POST產生兩個TCP數據包。

在GET請求，瀏覽器會把http header和data一併發送出去，服務器響應200，而對於POST，瀏覽器發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200。

而後看到這篇文章《據說『99% 的人都理解錯了 HTTP 中 GET 與 POST 的區別』？？》結論是，關於『GET 發一個包，POST 發兩個包』的知識 99% 大概是從這篇文章中得來的《XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?》能夠本身查看哦！（多多提出本身思考，不斷問爲何，去擴展本身知識點的邊緣）

一個TCP鏈接能發多少個HTTP請求

so，一個tcp鏈接裏到底能發幾個http呢？😉，應該是tcp鏈接不斷開，就能夠一直髮送請求，不斷開就能夠隨便發，HTTP2的話能夠一個鏈接裏並行，HTTP/1.1不行的。（開了Pipelining就能夠了吧，http1.1的，可是 Pipelining 默認在瀏覽器是不開的）

（感受應該和網絡情況相關，不會存在必定一種比另外一種快）

一個 TCP 鏈接後是否會在一個 HTTP 請求完成後斷開？

在 HTTP/1.0 中，一個服務器在發送完一個HTTP響應後，會斷開TCP連接。但這樣請求會從新創建和端口TCP鏈接，代價過大。

若是某服務器對Connection: keep-alive 的 Header 進行了支持。表示完成這個HTTP請求後，不用斷開HTTP請求使用TCP的TCP鏈接，能夠被重複使用，以後發送HTTP請求就不用從新創建TCP鏈接了。

維持鏈接好處多多，那麼在HTTP/1.1 就把 Connection 頭寫進標準，除非關閉，不然會維持一段時間的TCP鏈接，默認狀況下鏈接TCP不會斷開，只有在請求報頭中聲明Connection: close 纔會在請求完成後關閉鏈接。

若是維持鏈接，一個 TCP 鏈接是能夠發送多個 HTTP 請求的。

一個 TCP 鏈接中 HTTP 請求發送能夠一塊兒發送麼?

在PiPelining來解決這個問題：（Pipelining 是什麼）

如圖：

這一問題解決後，下面瞭解一下IP,TCP,和DNS(先簡單說明一下，還可能再加深)

IP,TCP,和DNS

說到IP，TCP，DNS這三個協議，固然在網絡通訊中，層次有涉及到因此要說一下不然就忘記了。

TCP/IP 是一類協議系統，它是用於網絡通訊的一套協議集合

tcp的首部格式

首部格式

負責傳輸的IP協議，IP協議（位於網絡層），幾乎全部使用網絡的系統都用到了IP協議，IP協議的做用就是把各類數據包傳送給對方，須要確保兩個重要的條件，IP地址（說明節點被分配到的地址，IP可換）和MAC地址（指網卡所屬的固定地址，MAC地址基本上不會換）。

經過MAC地址使用ARP協議進行通訊，（而ARP是一種用於解析地址的協議，經過通訊方的IP地址就能夠反查對應的MAC地址）。ARP協議用於在通訊雙方須要經過多臺計算機和網絡設備中轉才能到達對方，這個過程當中須要採用ARP協議進行中轉時，利用下一站中轉設備的MAC地址來搜索下一個中轉地址。（若是快遞公司，您做爲寄快遞的人，只知道本身的快遞件送到了快遞公司，這快遞過程當中，您沒法瞭解掌握快遞的過程細節）

就是說發送端嚮往某個IP地址發送數據包（快遞包）就會經過ARP協議進行中轉把數據包發往MAC地址（路由器）某個中轉站，而後接着到達下一個中轉地址（由上一個中轉地址搜索（送往）下一個中轉地址），最後到達接收端。

數據包：

我知道了MAC地址進行通訊過程當中是使用ARP協議的了，可是這是用在通訊雙方不多在同一局域網內的狀況。

TCP協議用於保證可靠性，位於傳輸層，提供字節流服務

字節流服務是將大塊數據分割成以報文段位單位的數據包進行管理（主要是爲了方便傳輸）。

而這裏確保數據可靠性送達，這裏就是咱們常說的TCP協議採用了三次握手，用於保證數據準確無誤的送到目的地。（TCP創建鏈接—三次握手，TCP釋放鏈接—四次揮手(待會說)）

三次握手,四次揮手

握手過程當中使用了TCP標誌，SYN（synchronize）同步信號和ACK（acknowledgement）確認信號。

描述過程是：（三次握手）

第一次握手：發送端，把標有SYN的數據包發給到 接收端，等待對方接收。

第二次握手：接收端接收後，發送標有 SYN/ACK 的數據包給以示傳達確認信息。

第三次握手：發送端收到後，在傳回帶ACK標識的數據包給 接收端，握手接收。

發送端，把標有SYN的數據包發給到 接收端，接收端收到後，發送標有 SYN/ACK 的數據包給 發送端，發送端收到後，發送標有 ACK的數據包給 接收端。

如圖：（SYN、ACK 是 TCP 封包中的 控制位元 ）

描述過程是：四次揮手

一般咱們習慣記憶域名，可是機器間互相指認ip地址，域名與ip地址之間是一一對應的，它們之間的轉換工做稱爲域名解析，域名解析是須要由專門的域名解析服務器來完成。

so，這就須要DNS服務來負責域名解析。

DNS服務來負責域名解析

負責域名解析的 DNS 服務,就是經過域名查詢到具體的 IP。

當客戶機提出查詢請求時，會在本地計算機中的緩存中查找，若是在本地沒法獲取查詢信息，就將查詢請求發給DNS服務器。

開始，客戶機將域名查詢請求發送到本地DNS服務器，在該服務器管理的區域的記錄中查找，若是找到該記錄，就利用此記錄進行解析，若是沒有區域信息能夠知足查詢要求，不能在本地找到客戶機查詢的信息，將請求發送到根域名DNS服務器，用於負責解析客戶機請求的根域部分，將包含下一級域名信息的DNS服務器地址返回給客戶機的DNS服務器地址，最後在目標域名的DNS服務器上找到相應的IP地址信息。

DNS服務是位於應用層的協議，提供域名到IP地址之間的解析服務。（DNS服務能夠加上對域名購買，解析服務的瞭解，更加容易理解一些，這就是一部不經過IP地址訪問，而是使用主機名或域名來訪問對方的計算機），它提供經過域名查找IP地址，也能夠逆向從IP地址查找域名。

流程詳解，就是發送端向DNS發送把某域名下的IP地址告知個人請求，DNS接收到後，把對應的IP地址返回到發送端，發送端經過Ip地址能夠向web服務器發送訪問請求。

so，根據上述總結，我能夠描述HTTP協議的通訊過程：

HTTP協議的通訊過程

客戶端（瀏覽器）在地址欄訪問某域名網頁，向DNS要求發送給對應的IP地址，瀏覽器經過域名在網頁請求某域名下的頁面資源，HTTP協議會生成對目標web服務器的HTTP的請求報文。TCP協議就是將HTTP請求報文分割成報文段，可靠地傳給對方。經過（數據包中轉站）IP協議負責的地方，搜索對方某MAC地址路由器，一邊中轉一邊傳送。到達對方服務器（某Ip地址），TCP協議負責從對方接收接收過來的報文段，重組到達按序號以原來的順序，HTTP協議就對web服務器請求的內容進行處理。

這個過程就是從應用層，傳輸層，網絡層，鏈路層之間的傳遞。

在這裏講到客戶端發送HTTP請求給服務器端的請求報文是什麼？

由於上面說到就講一下請求報文，那麼請求報文是以下圖總體：

這是客戶端的請求報文，那麼服務器端也有，是接收後結果以響應報文形式返回：

用表格，描述GET用於獲取資源：

說明	描述
請求	GET /index.html HTTP/1.1
響應	返回index.html的頁面資源

so，HTTP報文用於HTTP協議交互的信息，報文是由多行數據構成的字符串文本。大體分報文首部和報文主體兩塊。

報文的結構

請求報文和響應報文的結構（找了以下圖片進行解釋）

固然若是還不夠清晰，再次找了幾張圖片：

請求頭

請求體

狀態行

響應頭部

響應體

到了這裏，上面有一些知識點就是在地址欄中輸入的url，URL應該比較常說，它是同一資源定位符，用英文是（Uniform Resource Locator）。url就是輸入地址欄的網頁地址。

URI

說到url，咱們要了解一下URI,它是同一資源標識符。瞭解一下絕對URI的格式。

URI通常都是定位互聯網上的資源，保證在互聯網上任意位置的資源進行訪問（HTTP協議使用URI讓客戶端定位到資源）。以下圖：

快速看到這裏的朋友應該對HTTP瞭解還很不錯呢。

GET和POST的區別？

來道常考面試題：GET和POST的區別？

1. GET在瀏覽器回退不會再次請求，POST會再次提交請求
2. GET請求會被瀏覽器主動緩存，POST不會，要手動設置
3. GET請求參數會被完整保留在瀏覽器歷史記錄裏，POST中的參數不會
4. GET請求在URL中傳送的參數是有長度限制的，而POST沒有限制
5. GET參數經過URL傳遞，POST放在Request body中

HTTP四個版本

分別是HTTP1.0、HTTP1.一、HTTP/2，HTTP/3

HTTP1.0默認是短鏈接，每次與服務器交互，都須要新開一個鏈接。

HTTP1.1版本,默認持久鏈接，只要沒有明確提出端口就一直保持，能夠發送屢次HTTP請求，還有重點在於斷點續傳，利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸。

https協議如今部分網站都用這個。

在網絡上，客戶端和服務端交互，就有可能被挾持，須要用CA（公信機構）來幫客戶端認定服務端是真實的。

這個時候就要去申請一份數字證書，數字證書裏有證書持有者、證書有效期、服務器公鑰等信息。

客戶端用CA的公鑰對證書解密（證書被CA機構的私鑰解密，而後客戶端用CA證書的公鑰解密。）

流程以下圖所示：

管線化和持久鏈接

僅在HTTP/1.1才支持管線化，在持久鏈接前提下，請求一次性打包傳輸過去，響應一次性打包傳遞回來。

管線化技術的出現，不用等待響應亦可直接發送下一個請求。

在HTTP1.1中全部連接默認都是持久鏈接，使用同一個TCP鏈接來發送和接收多個HTTP請求或響應。

持久鏈接（HTTP Persistent Connections，也稱爲 HTTP keep-alive 或 HTTP connection reuse）

好處：

1. 減小了 TCP 鏈接的重複創建和斷開所形成的額 外開銷
2. 減輕了服務器端的負載
3. Web 頁面的顯示速度提升了

Cookie瞭解一下

Cookie 技術經過在請求和響應報文中寫入 Cookie 信 息來控制客戶端的狀態

跨域

什麼是同源策略

同源策略是一種約定，它是瀏覽器最核心的安全功能，所謂同源是指"協議+域名+端口"三者相同。

跨域是請求能發出去，服務端能收到請求並正常返回結果，只是結果被瀏覽器攔截了。

解決跨域：

有 jsonp、iframe、cors、img、HTML5 postMessage等等。其中用到 html 標籤進行跨域的原理就是 html 不受同源策略影響。但只是接受 Get 的請求方式，這個得清楚。

JSONP原理，利用js請求返回不須要域名，沒有跨域問題，即利用 <script> 標籤沒有跨域限制的漏洞，網頁能夠獲得從其餘來源動態產生的 JSON 數據,不安全可能會遭受XSS攻擊。

JSONP 使用簡單且兼容性不錯，可是隻限於 get 請求。

<script src="http:=jsonp"></script>
<script>
    function jsonp(data) {
    	console.log(data)
	}
</script> 
複製代碼

從輸入URL到頁面展現，這中間發生了什麼？

從輸入 URL 到頁面展現完整流程示意圖

輸入url並回車，瀏覽器進程檢查url，組裝協議，構成完整的url，經過進程間通訊（IPC）把url請求發送給網絡進程，接收到url請求後檢查本地緩存是否緩存該請求資源，若是有,則將該資源返回給瀏覽器進程，若是沒有，網絡進程向web服務器發起http請求。

向web服務器發起http請求

1. 進行DNS解析，獲取服務器ip地址，端口
2. 利用ip地址和服務器創建tcp鏈接
3. 構建請求頭信息
4. 發送請求頭信息
5. 服務器響應後，網絡進程接收響應頭和響應信息，並解析響應內容
6. 網絡進程解析響應流程
7. 準備渲染進程
8. 傳輸數據、更新狀態

Web服務器

1. 用單臺虛擬主機實現多個域名
2. HTTP/1.1 規範容許一臺 HTTP 服務器搭建多個 Web 站點

代理、網關、隧 道

來源於《圖解HTTP》

代理：

來源於《圖解HTTP》

網關：

來源於《圖解HTTP》

隧道：

來源於《圖解HTTP》

緩存：

來源於《圖解HTTP》

有效期限：

來源於《圖解HTTP》

web安全

1. 通訊使用明文可能會被竊聽，存在通訊內容被竊聽的風險
2. TCP/IP 可能被竊聽的網絡
3. 加密處理防止被竊聽
4. 沒法證實報文完整性，可能已遭篡改
5. 使用 HTTPS 通訊
6. HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

參考文獻

你猜一個 TCP 鏈接上面能發多少個 HTTP 請求

前端總結--網絡

熬夜寫了一篇HTTP總結

《圖解HTTP》