HTTP/HTTPS-總結與心得

時間 2019-11-25

原文原文鏈接

前言

HTTP比如互聯網中各類資源的搬運工，做爲程序員的咱們（無論你是哪方面的開發人員）都或多或少地會與其打交道，無論是在工做中仍是面試中，咱們都能看到它們的身影，因此HTTP的重要性不言而喻。前不久一個朋友在參加大大小小的面試中，基本上每一個面試官都會問到，而後他跟我吐槽http知識點太多記不住。因而就有了這篇文章，在個人草稿箱裏躺了一個多月才得以面世（ps:不知如何開頭,而後各類事情...）！html

HTTP/HTTPS相關知識點

TCP/IP

應用層

應用層決定了向用戶提供應用服務時通訊的活動。前端

傳輸層

傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。程序員

網絡層（網路互聯層）

網絡層用來處理在網絡上流動的數據包，數據包是網絡傳輸的最小數據單位，改層規定了經過怎樣的路勁（所謂的傳輸路線）到達對方計算機，並把數據包傳送給對方。web

鏈路層（數據鏈路層，網絡接口層）

用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、網卡、光纖等等，硬件上的範疇均在鏈路層的做用範圍。面試

重點聊一下DNS、TCP、UDP(敲黑板、劃重點):算法

DNS協議

用戶一般經過使用主機名或者域名來訪問對方的計算機，而不是經過IP地址訪問，因此DNS協議應運而生，提供提供域名到服務器IP地址之間的解析服務。數據庫

注：摘抄自《圖解HTTP》(偷個懶。。。)

TCP協議

TCP協議提供可靠的字節流服務，能夠將大塊數據分割成報文段爲單位的數據包進行管理，可以準確可靠地將數據傳遞給對方，爲了準確無誤地將數據送到目標處，TCP協議採用了三次握手策略。瀏覽器

注：摘抄自《圖解HTTP》,此圖畫出了個人心聲

發送端首先發送一個帶SNY標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示創達確認信息，最後發送端再回傳一個帶ACK標誌的數據包，表明鏈接過程結束。緩存

UDP協議

UDP協議與TCP協議同樣用於處理數據包，不一樣的是：在傳送數據前不須要先創建鏈接，正是由於如此，省去和不少的開銷，使得它的速度比較快，一些對實時性要求較高的服務，一般使用的就是UDP協議。安全

PS：其它協議我就不碼字了，問下度娘能夠加深印象^_^

HTTP協議

http協議處於應用層，用於客戶端與服務端之間的通訊，不保存狀態。因此Cookie就誕生了~

Cookie

HTTP是無狀態協議，他不對以前發生過的請求和響應的狀態進行管理，沒法根據以前的狀態進行本次的請求處理。舉個栗子：假設要求登陸認證的web頁面自己沒法進行狀態的管理，如今有100個客戶端，分別向服務器端發送請求，服務器沒法辨別對應的客戶端，每次都須要客戶端從新登陸。

注：摘抄自《圖解HTTP》,畫的太好了~

咱們來看看開發中實際的報文：一、第一次請求（請求報文中-沒有Cookie信息狀態）

咱們再來看看響應報文：

服務器端生成了Cookie信息二、後面的數據請求（請求報文中-都會帶上Cookie信息）

sessionId

通常用來標記用戶，session保存在服務端，而sessionId經過存放在cookie中來傳輸，sessionId在服務器端產生對應着登錄的用戶。

HTTP報文

http請求報文

舉個栗子（百度首頁）：

報文首部信息字段含義，稍後詳解

http響應報文

首部字段

http1.1規範了47種首部字段通用首部字段

請求首部字段

響應首部字段

實體首部字段

瀏覽器緩存機制

敲黑板、劃重點

強緩存

強緩存是利用 http 頭中的 Expires 和 Cache-Control 兩個字段來控制的。強緩存中，當請求再次發出時，瀏覽器會根據其中的 expires 和 cache-control 判斷目標資源是否「命中」強緩存，若命中返回的 HTTP 狀態碼爲200則直接從緩存中獲取資源，不會再與服務端發生通訊。

Cache-Control 相對於 expires 更加準確，它的優先級也更高。當 Cache-Control 與 expires 同時出現時，咱們以 Cache-Control 爲準。

expires 是一個時間戳，接下來若是咱們試圖再次向服務器請求資源，瀏覽器就會先對比本地時間和 expires 的時間戳，若是本地時間小於 expires 設定的過時時間，那麼就直接去緩存中取這個資源。

從這樣的描述中你們也不難猜想，expires 是有問題的，它最大的問題在於對「本地時間」的依賴。若是服務端和客戶端的時間設置可能不一樣，或者我直接手動去把客戶端的時間改掉，那麼 expires 將沒法達到咱們的預期。

考慮到 expires 的侷限性，HTTP1.1 新增了 Cache-Control 字段來完成 expires 的任務。 expires 能作的事情，Cache-Control 都能作；expires 完成不了的事情，Cache-Control 也能作。所以，Cache-Control 能夠視做是 expires 的徹底替代方案。如今咱們給 Cache-Control 字段一個特寫：

如你們所見，在 Cache-Control 中，咱們經過 max-age 來控制資源的有效期。max-age 不是一個時間戳，而是一個時間長度。在本例中，max-age 是 2592000 秒，它意味着該資源在 2592000 秒之內都是有效的，完美地規避了時間戳帶來的潛在問題。

Cache-Control 應用分析

Cache-Control 的神通，可不止於這一個小小的 max-age。以下的用法也很是常見：

s-maxage 優先級高於 max-age，二者同時出現時，優先考慮 s-maxage。若是 s-maxage 未過時，則向代理服務器請求其緩存內容。

這個 s-maxage 不像 max-age 同樣爲你們所熟知。的確，在項目不是特別大的場景下，max-age 足夠用了。但在依賴各類代理的大型架構中，咱們不得不考慮代理服務器的緩存問題。s-maxage 就是用於表示 cache 服務器上（好比 cache CDN）的緩存的有效時間的，並只對 public 緩存有效。

public 與 private

public 與 private 是針對資源是否可以被代理服務緩存而存在的一組對立概念。

若是咱們爲資源設置了 public，那麼它既能夠被瀏覽器緩存，也能夠被代理服務器緩存；若是咱們設置了 private，則該資源只能被瀏覽器緩存。private 爲默認值。但多數狀況下，public 並不須要咱們手動設置，好比有不少線上網站的 cache-control 是這樣的：

設置了 s-maxage，沒設置 public，那麼 CDN 還能夠緩存這個資源嗎？答案是確定的。由於明確的緩存信息（例如「max-age」）已表示響應是能夠緩存的。

no-store與no-cache

no-cache 繞開了瀏覽器：咱們爲資源設置了 no-cache 後，每一次發起請求都不會再去詢問瀏覽器的緩存狀況，而是直接向服務端去確認該資源是否過時（即走咱們下文即將講解的協商緩存的路線）。

no-store 比較絕情，顧名思義就是不使用任何緩存策略。在 no-cache 的基礎上，它連服務端的緩存確認也繞開了，只容許你直接向服務端發送請求、並下載完整的響應。

協商緩存

協商緩存機制下，瀏覽器須要向服務器去詢問緩存的相關信息，進而判斷是從新發起請求、下載完整的響應，仍是從本地獲取緩存的資源。

若是服務端提示緩存資源未改動（Not Modified），資源會被重定向到瀏覽器緩存，這種狀況下網絡請求對應的狀態碼是 304（以下圖）。

Last-Modified 與 Etag

Last-Modified 是一個時間戳，若是咱們啓用了協商緩存，它會在首次請求時隨着 Response Headers 返回：

隨後咱們每次請求時，會帶上一個叫 If-Modified-Since 的時間戳字段，它的值正是上一次 response 返回給它的 last-modified 值：

服務器接收到這個時間戳後，會比對該時間戳和資源在服務器上的最後修改時間是否一致，從而判斷資源是否發生了變化。若是發生了變化，就會返回一個完整的響應內容，並在 Response Headers 中添加新的 Last-Modified 值；不然，返回如上圖的 304 響應，Response Headers 不會再添加 Last-Modified 字段。

使用 Last-Modified 存在一些弊端，這其中最多見的就是這樣兩個場景：

一、咱們編輯了文件，但文件的內容沒有改變。服務端並不清楚咱們是否真正改變了文件，它仍然經過最後編輯時間進行判斷。所以這個資源在再次被請求時，會被當作新資源，進而引起一次完整的響應——不應從新請求的時候，也會從新請求。二、當咱們修改文件的速度過快時（好比花了 100ms 完成了改動），因爲 If-Modified-Since 只能檢查到以秒爲最小計量單位的時間差，因此它是感知不到這個改動的——該從新請求的時候，反而沒有從新請求了。

這兩個場景其實指向了同一個 bug——服務器並無正確感知文件的變化。爲了解決這樣的問題，Etag 做爲 Last-Modified 的補充出現了

Etag 是由服務器爲每一個資源生成的惟一的標識字符串，這個標識字符串是基於文件內容編碼的，只要文件內容不一樣，它們對應的 Etag 就是不一樣的，反之亦然。所以 Etag 可以精準地感知文件的變化。 Etag 和 Last-Modified 相似，當首次請求時，咱們會在響應頭裏獲取到一個最初的標識符字符串，它能夠是這樣的：

那麼下一次請求時，請求頭裏就會帶上一個值相同的、名爲 if-None-Match 的字符串供服務端比對了：

Etag 的生成過程須要服務器額外付出開銷，會影響服務端的性能，這是它的弊端。所以啓用 Etag 須要咱們審時度勢。正如咱們剛剛所提到的——Etag 並不能替代 Last-Modified，它只能做爲 Last-Modified 的補充和強化存在。 Etag 在感知文件變化上比 Last-Modified 更加準確，優先級也更高。當 Etag 和 Last-Modified 同時存在時，以 Etag 爲準。

HTTPS

一張圖告訴你區別：

HTTPS並不是是應用層的一種新協議。只是HTTP通訊接口部分用SSL(Secure Socket Layer) 和TLS(Transport Layer Security)協議代替而已，SSL與TLS在傳輸層與應用層之間對網絡鏈接進行加密。 SSL/TLS:是爲網絡通訊提供安全及數據完整性的一種安全協議. SSL:採用公開密鑰加密（非對稱加密算法）的處理方式來保證網絡通訊的安全，公開密鑰加密使用一對非對稱的密鑰，一把叫作公開密鑰，另外一把叫私有密鑰。

HTTP狀態碼

狀態碼：當客戶端向服務器端發送請求時，描述返回的請求結果，用戶能夠根據狀態碼判斷服務器是正常處理了請求仍是出現了錯誤。狀態碼類別以下：

注：具體的狀態碼，這裏就不一一列舉了...

HTTP版本

上面提到的HTTP都是基於HTTP1.1(目前使用最普遍的版本)

HTTP/2.0

HTTP2.0基於SPDY，主要是改善了數據傳輸的性能和安全性！

二進制編碼：請求數據與相應數據採用二進制編碼，分割成多個幀進行傳輸，效率更高
報文首部壓縮：報文首部採用「HPACK」算法，在客戶端和服務端兩端創建「字典」，用索引號表示重複的字符串，對於相同的數據，不用重複請求和相應發送，減小冗餘數據；採用哈夫曼編碼壓縮整數和字符串，能夠達到50%~90%的壓縮率。
多路由複用：同域名下全部通訊都是在單個鏈接上完成，單個鏈接能夠承載任意數量的雙向數據流

HTTP/2.0:

HTTP/2 的缺點：

TCP以及TCP+TLS創建鏈接開銷一、創建TCP鏈接須要和服務器進行三次握手來確認鏈接成功，須要消耗1.5個RTT以後才能進行數據傳輸. 二、進行TLS鏈接，TLS有兩個版本——TLS1.2和TLS1.3，每一個版本創建鏈接所花的時間不一樣，大體是須要1~2個RTT.
TCP的隊頭阻塞問題 TCP爲了保證可靠傳輸，有個「丟包重傳」機制，丟失的包必需要等待從新傳輸確認，HTTP/2出現丟包時，整個TCP 都要開始等待重傳。

HTTP/3.0

因爲HTTP/2.0的缺陷，Google在推SPDY的時候就已經意識到了這些問題，因而就有了基於 UDP協議的「QUIC」協議，讓HTTP跑在QUIC上而不是TCP上。它在HTTP/2的基礎上又實現了質的飛躍，真正「完美」地解決了「隊頭阻塞」問題。 QUIC協議：

QUIC在UDP的基礎之上增長了一層來保證數據可靠性傳輸，提供了數據包重傳、擁塞控制以及其餘一些TCP中存在的特性
QUIC能夠實現使用0-RTT或者1-RTT來創建鏈接，這意味着QUIC能夠用最快的速度來發送和接收數據
QUIC實現了在同一物理鏈接上能夠有多個獨立的邏輯數據流。實現了數據流的單獨傳輸，就解決了TCP中隊頭阻塞的問題

網絡安全-Web攻擊類型

SQL注入攻擊與OS命令注入攻擊

a、攻擊者設置好攻擊鏈接，引誘用戶觸發鏈接 b、執行惡意代碼後，用戶所持有的Cookie被竊取，用戶權限被惡意使用 c、執行攻擊命令操做服務器上數據資源防禦策略：一、不要使用動態SQL：避免將用戶提供的輸入直接放入SQL語句中；最好使用準備好的語句和參數化查詢，這樣更安全。二、限制數據庫權限和特權：將數據庫用戶的功能設置爲最低要求；這將限制攻擊者在設法獲取訪問權限時能夠執行的操做三、不要將敏感數據保留在純文本中，加密存儲在數據庫中的私有/機密數據