http簡單整理

HTTP和HTTPS

HTTP 版本

1.0(1996) -> 1.1(1999) -> 2(2000)

1.0

• 每次都從新建立鏈接

1.1

• keep-alive 保持鏈接
• 斷點續傳
• 選擇性傳遞數據
• 支持hostname

缺點：

• 通訊使用明文(不加密)，內容可能會被竊聽
• 不驗證通訊方的身份，所以有可能遭遇假裝
• 沒法證實報文的完整性，因此有可能已遭篡改

2.0

• HTTP1.x的解析是基於文本, HTTP2.0的協議解析決定採用二進制格式
• HTTP1.x的header帶有大量信息, HTTP2.0使用encoder來減小須要傳輸的header大小
• HTTP2.0徹底兼容HTTP1.x的語義, 對於不支持HTTP2.0的瀏覽器，NGINX會自動向下兼容的
• 除了對最初請求的響應外，服務器還能夠額外向客戶端推送資源，而無需客戶端明確地請求

https有什麼不一樣

• HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。
• HTTP協議運行在TCP之上，全部傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，全部傳輸的內容都通過加密的。
• HTTP和HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
• HTTPS能夠有效的防止運營商劫持，解決了防劫持的一個大問題。

• HTTPS 比 HTTP 要慢 2 到 100 倍

三次握手和四次分手

• 第一次握手：創建鏈接時，客戶端A發送SYN包（SYN=1）到服務器B，並進入SYN_SEND狀態，等待服務器B確認。
• 第二次握手：服務器B收到SYN包，必須確認客戶A的SYN（ACK=x+1），同時本身也發送一個SYN包（SYN=1），即SYN+ACK包，此時服務器B進入SYN_RECV狀態。
• 第三次握手：客戶端A收到服務器B的SYN＋ACK包，向服務器B發送確認包ACK（ACK=y+1），此包發送完畢，客戶端A和服務器B進入ESTABLISHED狀態，完成三次握手。以後就能夠進行數據傳送了。

• 第一次揮手：客戶端向服務器發送一個FIN報文段，序列號爲u，此時，客戶端進入FIN_WAIT_1狀態，這表示客戶端沒有數據要發送給服務器了
• 第二次揮手：服務器收到了客戶端發送的FIN報文段，向客戶端回一個ACK報文段，序列號爲u+1,客戶端進入FIN_WAIT_2狀態，服務器告訴客戶端，我也沒有數據要發送了，能夠進行關閉鏈接了
• 第三次揮手：服務器向客戶端發送FIN報文段，請求關閉鏈接，同時服務器進入CLOSE_WAIT狀態
• 第四次揮手：客戶端收到服務器發送的FIN報文段，向服務器發送ACK報文段，而後客戶端進入TIME_WAIT狀態;服務器收到客戶端的ACK報文段之後，就關閉鏈接;此時，客戶端等待2MSL後依然沒有收到回覆，則證實服務器已正常關閉，此時，客戶端也能夠關閉鏈接了

方法

GET
POST
PUT
DELETE
OPTION 查詢請求的支持狀況
HEAD 只發送頭部信息，確認URI的有效性和資源更新時間
TRACE 追蹤路徑，讓服務端返回以前發送的請求信息
CONNECT 用隧道協議連接代理，進行加密傳輸

狀態碼

200 表示從客戶端發來的請求在服務器端被正常處理了
204 該狀態碼錶明服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分 , 通常在只須要從客戶端往服務器發送信息，而對客戶端不須要發送新信息內容的狀況下使用。
206 該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由 Content-Range指定範圍的實體內容。
301 永久性重定向
302 臨時性重定向
303 該狀態碼錶示因爲請求對應的資源存在着另外一個 ### URI，應使用GET方法定向獲取請求的資源
304 該狀態碼錶示客戶端發送附帶條件的請求時，服務器端容許請求訪問資源，但未知足條件的狀況 （附帶條件的請求是指採用 GET 方法的請求報文中包含 If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since 中任一首部 ）
307 臨時重定向 , 會遵守瀏覽器標準，不會從 POST變成 GET
400 該狀態碼錶示請求報文中存在語法錯誤 , 瀏覽器 會像 ### 200 OK同樣對待該狀態碼
401 該狀態碼錶示發送的請求須要有經過 HTTP認證
403
404
500 服務器端在執行請求時發生了錯誤
503 服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求

瀏覽器的最大鏈接數

在 HTTP/1.1 協議中

瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量限制。超過限制數目的請求會被阻塞。

keep-alive是指服務器和客戶端的多個請求響應共用一個TCP鏈接，而不是每次請求響應都新建一個鏈接完了後關閉

http1.1 和 http 2請求差別

HTTP/2 能夠很容易的去實現多流並行而不用依賴創建多個 TCP 鏈接，
HTTP/2 把 HTTP 協議通訊的基本單位縮小爲一個一個的幀，這些幀對應着邏輯流中的消息，
並行地在同一個 TCP 鏈接上, 下降了請求延遲。

緩存

和緩存相關的頭部字段

Pragma和Expires 在 http1.0 時代，給客戶端設定緩存方式可經過這兩個字段來規範。雖然這兩個字段早可拋棄，但爲了作http協議的向下兼容，你仍是能夠看到不少網站依舊會帶上這兩個字段

Cache-Control 區分對緩存機制的支持狀況， 請求頭和響應頭都支持這個屬性，報文中同時出現了 Expires 和 Cache-Control，則以 Cache-Control 爲準。優先級 Pragma -> Cache-Control -> Expires

做爲請求首部：

做爲響應首部：

Last-Modified 服務器將資源傳遞給客戶端時，會將資源最後更改的時間以「Last-Modified: GMT」的形式加在實體首部上一塊兒返回給客戶端.

客戶端會爲資源標記上該信息，下次再次請求時，會把該信息附帶在請求報文中一併帶給服務器去作檢查，若傳遞的時間值與服務器上該資源最終修改時間是一致的，則說明該資源沒有被修改過，直接返回304狀態碼，內容爲空，這樣就節省了傳輸數據量 。若是兩個時間不一致，則服務器會發回該資源並返回200狀態碼，和第一次請求時相似。這樣保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端可以獲得最新的資源。一個304響應比一個靜態資源一般小得多，這樣就節省了網絡帶寬。

If-Modified-Since: Last-Modified-value 該請求首部告訴服務器若是客戶端傳來的最後修改時間與服務器上的一致，則直接回送304 和響應報頭便可。當前各瀏覽器均是使用的該請求首部來向服務器傳遞保存的 Last-Modified 值

If-Unmodified-Since: Last-Modified-value 該值告訴服務器，若Last-Modified沒有匹配上（資源在服務端的最後更新時間改變了），則應當返回412(Precondition Failed) 狀態碼給客戶端.

Last-Modified 存在必定問題，若是在服務器上，一個資源被修改了，但其實際內容根本沒發生改變，會由於Last-Modified時間匹配不上而返回了整個實體給客戶端（即便客戶端緩存裏有個如出一轍的資源）。

ETag 爲了解決上述Last-Modified可能存在的不許確的問題，Http1.1還推出了 ETag 實體首部字段。 服務器會經過某種算法，給資源計算得出一個惟一標誌符（好比md5標誌），在把資源響應給客戶端的時候，會在實體首部加上「ETag: 惟一標識符」一塊兒返回給客戶端

客戶端會保留該 ETag 字段，並在下一次請求時將其一併帶過去給服務器。服務器只須要比較客戶端傳來的ETag跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。

若是服務器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的ETag）發給客戶端；若是ETag是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

If-None-Match: ETag-value 當前各瀏覽器均是使用的該請求首部來向服務器傳遞保存的 ETag 值。

Ctrl + F5 / Cmd+Shift+R 強制瀏覽器不使用緩存

引用1

nginx -> gzip

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_comp_level 5;
gzip_types text/plain application/x-javascript text/css application/xml text/javascript;

# 開啓gzip
gzip on;

# 啓用gzip壓縮的最小文件，小於設置值的文件將不會壓縮
gzip_min_length 1k;

# gzip 壓縮級別，1-10，數字越大壓縮的越好，也越佔用CPU時間，後面會有詳細說明
gzip_comp_level 2;

# 進行壓縮的文件類型。javascript有多種形式。其中的值能夠在 mime.types 文件中找到。
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;

# 是否在http header中添加Vary: Accept-Encoding，建議開啓
gzip_vary on;

# 禁用IE 6 gzip
gzip_disable "MSIE [1-6]\.";

gzip
語法：gzip on/off
默認值：off
做用域：http, server, location
說明：開啓或者關閉 gzip 模塊，這裏使用 on 表示啓動

gzip_min_length
語法：gzip_min_length length
默認值：gzip_min_length 0
做用域：http, server, location
說明：設置容許壓縮的頁面最小字節數，頁面字節數從header頭中的Content-Length中進行獲取。默認值是0，無論頁面多大都壓縮。建議設置成大於1k的字節數，小於1k可能會越壓越大。

gzip_buffers
語法: gzip_buffers number size
默認值: gzip_buffers 4 4k/8k
做用域: http, server, location
說明：設置系統獲取幾個單位的緩存用於存儲gzip的壓縮結果數據流。4 16k 表明以 16k 爲單位，按照原始數據大小以 16k 爲單位的4倍申請內存。

gzip_comp_level
語法: gzip_comp_level 1..9
默認值: gzip_comp_level 1
做用域: http, server, location
說明：gzip壓縮比，1 壓縮比最小處理速度最快，9 壓縮比最大但處理最慢（傳輸快但比較消耗cpu）。這裏設置爲 5。

gzip_types
語法: gzip_types mime-type [mime-type ...]
默認值: gzip_types text/html
做用域: http, server, location
說明：匹配MIME類型進行壓縮，（不管是否指定）"text/html" 類型老是會被壓縮的。這裏設置爲 text/plain application/x-javascript text/css application/xml text/javascript。