HTTP

秦丨竹發表於2020-10-05
HTTP

首部

通用首部

1. Cache-Control/Pragma    控制快取的行為
    Cache-Control： no-cache  HTTP/1.1
    Pragma： no-cache         HTTP/1.1之前版本
2. Connection       
     管理持久連線。不再轉發的首部欄位名
     Connection:close   HTTP/1.1版本預設連線，可斷開
     Connection:Keep-Alive  HTTP/1.1之前版本的連線
3. Date             HTTP報文建立的日期和時間
4. Trailer          報文末端的首部一覽
5. Transfer-Encoding 指定報文主體的傳輸編碼方式
6. Upgrade          升級為其他協議
7. Via              代理伺服器的相關資訊
     報文經過代理或者閘道器時，會先在首部欄位Via中附加該伺服器的資訊，然後再進行轉發。該欄位不僅用於追蹤報文的轉發，還可以避免請求迴環的發生。所以必須在經過代理時附加該首部欄位內容。
8. Warning          錯誤通知
複製程式碼

請求首部

Accept               使用者代理可處理的媒體型別
Accept-Charset       優先的字符集 
Accept-Encoding      優先的內容編碼
Accept-Language      優先的語言
Authorization        Web認證資訊
Expect               期待伺服器的特定行為
From                 使用者的電子郵箱地址
Host                 請求資源所在的伺服器
If-Match             比較實體標記（ETag）
If-Mdoidied-Since    比較資源的更新時間
If-None-Match        比較實體標記（與IF-Match相反）
If-Range             資源未更新時發生實體Byte的範圍請求
If-Unmodified-Since  比較資源更新時間（與If-Modified-Since相反）
Max-Forwards        最大傳輸逐跳數
Proxy-Authorization 代理伺服器要求客戶端的認證資訊
Range               實體的位元組範圍請求
Referer             對請求中URI的原始獲取方
TE                  傳輸編碼的優先順序
User-Agent          HTTP客戶端程式的資訊
複製程式碼

響應首部

Accept-Ranges       是否支援某種種類的範圍
Age                 資源在代理快取中存在的時間
ETag                資源標識 
Location            令客戶端重定向至指定URI
Proxy-Authenticate  向代理伺服器傳送驗證資訊
Retry-After         對再次發起請求的時機要求
Server              HTTP伺服器的安裝資訊
vary                代理伺服器快取的管理資訊
WWW-Authenticate    伺服器對客戶端的認證資訊
複製程式碼

實體首部

實體首部欄位是包含在請求報文和響應報文中的實體部分所使用的首部。用於補充內容的更新時間和與實體相關的資訊。

Allow               資源可支援的HTTP方法
Content-Encoding    內容的編碼方式
Content-Language    內容的自然語言
Content-Length      內容的長度
Content-Location    返回資料的備用地址
Content-MD5         Base64加密格式的內容 MD5校驗值
Content-Range       內容的位置範圍
Content-Type        內容的媒體型別
Expires             內容過期時間
Last-Modified       內容最後修改時間
複製程式碼

非hHTTP/1.1首部欄位

Cookie
Set-Cookie
Content-Disponsition
複製程式碼

Cookie 服務首部欄位

Set-Cookie 響應首部欄位
Cookie     請求首部欄位

Set-Cookie 欄位的屬性
    NAME=VALUE
    expires=DATE
    path=PATH
    domain=域名
    Secure
    HttpOnly
複製程式碼

HTTPS和HTTP的區別主要如下：

  1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。

  2、http是超文字傳輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。

  3、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。

  4、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。

HTTPS 加密

HTTPS 還是通過了 HTTP 來傳輸資訊，但是資訊通過 TLS 協議進行了加密。
對稱加密和非對稱加密。
複製程式碼

共享金鑰加密/對稱加密

 加密和解密同用一個金鑰的方式。
複製程式碼

公開金鑰加密/非對稱加密

一把為私鑰（私有金鑰），一把為公鑰（公開金鑰），其中私有金鑰不能讓任何人得知，而公開金鑰則可以隨意公佈。
傳送密文的那一端，使用對方的公開金鑰進行加密處理，對方接收到被加密的資訊後，使用私鑰對此密文進行解密。
利用這種方式，不需要傳送用來解密的私鑰。從而解決了共享金鑰加密存在的問題。
複製程式碼

HTTPS通訊步驟

 客戶端在使用HTTPS方式與Web伺服器通訊時有以下幾個步驟，如圖所示。

HTTP
  （1）客戶使用https的URL訪問Web伺服器，要求與Web伺服器建立SSL連線。

  （2）Web伺服器收到客戶端請求後，會傳送一份包含公鑰的網站證書資訊給客戶端。

  （3）客戶端的瀏覽器與Web伺服器開始協商SSL連線的安全等級，也就是資訊加密的等級。

  （4）客戶端的瀏覽器根據雙方同意的安全等級，建立會話金鑰，然後利用網站的公鑰將會話金鑰加密，並傳送給伺服器。

  （5）Web伺服器利用自己的私鑰解密出會話金鑰。

  （6）Web伺服器利用會話金鑰加密與客戶端之間的通訊。

HTTP缺點

明文通訊，內容易竊聽； （通訊加密 內容加密）

不驗證通訊方身份，可遭遇偽裝（查明對手證書）

無法證明報文的完整性

相比HTTP，HTTPS有哪些缺點？

（1）HTTPS協議握手階段比較費時，會使頁面的載入時間延長近50%，增加10%到20%的耗電；

（2）HTTPS連線快取不如HTTP高效，會增加資料開銷和功耗，甚至已有的安全措施也會因此而受到影響；

（3）SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。

（4）SSL證書通常需要繫結IP，不能在同一IP上繫結多個域名，IPv4資源不可能支撐這個消耗。

（5）HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、伺服器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

tcp三次握手

假設主動發起請求的一端為客戶端，被動連線的是服務端。

  1. 起初，兩端都為close狀態；
  2. 通訊開始前，雙方 create TCB。服務端建立完進入listen狀態，等待客戶端傳送資料；
  3. 握手
    1. 第一次握手：客戶端向服務端傳送 連線請求報文 段，包含自身 資料通訊 初始序號，傳送後客戶端進入 syn-sent 狀態；
    2. 第二次握手：服務端收到連線請求報文段，如果同意連線，就會傳送一個包含自身 資料通訊 初始序號 的應答，傳送後進入 syn-received 狀態；
    3. 第三次握手：當客戶端收到應答後，向服務端傳送確認報文。客戶端傳送完這個報文後進入 established 狀態，服務端收到這個應答後也進入established狀態，此時連線建立成功。

HTTP
4.揮手

HTTP
TCP 是全雙工的，在斷開連線時兩端都需要傳送 FIN 和 ACK。

  1. 客戶端認為資料傳送完成，要向服務端傳送連線釋放請求。
  2. B 收到連線釋放請求後，會告訴應用層要釋放 TCP 連結。然後會傳送 ACK 包，並進入 CLOSE_WAIT 狀態，此時表明 A 到 B 的連線已經釋放，不再接收 A 發的資料了。但是因為 TCP 連線是雙向的，所以 B 仍舊可以傳送資料給 A。
  3. B 如果此時還有沒發完的資料會繼續傳送，完畢後會向 A 傳送連線釋放請求，然後 B 便進入 LAST-ACK 狀態。 PS：通過延遲確認的技術（通常有時間限制，否則對方會誤認為需要重傳），可以將第二次和第三次握手合併，延遲 ACK 包的傳送。
  4. A 收到釋放請求後，向 B 傳送確認應答，此時 A 進入 TIME-WAIT 狀態。該狀態會持續 2MSL（最大段生存期，指報文段在網路中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 B 收到確認應答後，也便進入 CLOSED 狀態。
為什麼 A 要進入 TIME-WAIT 狀態，等待 2MSL 時間後才進入 CLOSED 狀態？

為了保證 B 能收到 A 的確認應答。若 A 發完確認應答後直接進入 CLOSED 狀態，如果確認應答因為網路問題一直沒有到達，那麼會造成 B 不能正常關閉。

Flags

標誌位表示當前資料包的型別： SYN: synchronous建立聯機 ACK: acknowledgement確認 (只能為1) PSH: push傳送 FIN: finish結束 RST: reset重置 URG: urgent緊急

get 和 post

  1. 編碼格式不同
  2. 長度限制不同
  3. get可快取
  4. post安全性高

TCP的持久化連線

1. HTTP 協議的初始版本中， 每進行一次 HTTP 通訊就要斷開一次 TCP連線。
   只要一方沒有明確提出斷開連線，則保持TCP連線。

2. 好處在於減少了 TCP 連線的重複建立和斷開所造成的額外開銷，
   減輕了伺服器端的負載。 另外， 減少開銷的那部分時間， 使 HTTP
   請求和響應能夠更早地結束， 這樣 Web 頁面的顯示速度也就相應提高了。在
   HTTP/1.1 中， 所有的連線預設都是持久連線， 但在 HTTP/1.0內並未標準化。
   雖然有一部分伺服器通過非標準的手段實現了持久連線，但伺服器端不一定能夠支援持久連線。 
   毫無疑問， 除了伺服器端， 客戶端也需要支援持久連線。
複製程式碼

TCP的管線化

從前傳送請求後需要等待響應，管線化不用等待響應亦可直接傳送下一個請求。這樣就能夠做到同時並行傳送多個請求， 而不需要一個接一個地等待響應了。
複製程式碼

UDP 和 TCP 區別

首先 UDP 協議是面向無連線的，也就是說不需要在正式傳遞資料之前先連線起雙方。然後 UDP 協議只是資料包文的搬運工，不保證有序且不丟失的傳遞到對端，並且UDP 協議也沒有任何控制流量的演算法，總的來說 UDP 相較於 TCP 更加的輕便。
UDP適合做直播。
複製程式碼

相關文章