HTTP相關(guān)

目錄：
1.HTTP 方法
2.HTTP 狀態(tài)碼
3.HTTP 報文
4.HTTP 和 HTTPS 的區(qū)別
5.HTTPS 相關(guān)

HTTP方法

  • GET 獲取資源

當(dāng)前網(wǎng)絡(luò)請求中，絕大部分使用的是 GET 方法。

  • HEAD 獲取報文首部

和GET方法類似，但是不返回報文實體主體部分。
主要用于確認URL的有效性以及資源更新的日期時間等。

  • POST 傳輸實體主體

POST 主要用來傳輸數(shù)據(jù)，而 GET 主要用來獲取資源。
更多 POST 與 GET 的比較請見第九章。

  • PUT 上傳文件

由于自身不帶驗證機制，任何人都可以上傳文件，因此存在安全性問題，一般不使用該方法。

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>
  • PATCH 對資源進行部分修改

PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改。

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[description of changes]
  • DELETE 刪除文件

與 PUT 功能相反，并且同樣不帶驗證機制。

DELETE /file.html HTTP/1.1
  • OPTIONS 查詢支持的方法

查詢指定的 URL 能夠支持的方法。

會返回Allow: GET, POST, HEAD, OPTIONS這樣的內(nèi)容。

  • CONNECT 要求在與代理服務(wù)器通信時建立隧道

使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

CONNECT www.example.com:443 HTTP/1.1
CONNECT
  • TRACE追蹤路徑

服務(wù)器會將通信路徑返回給客戶端。

發(fā)送請求時，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個服務(wù)器就會減 1，當(dāng)數(shù)值為 0 時就停止傳輸。

通常不會使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤）。

不安全的http方法及其危害

1.PUT方法：自身不帶驗證機制，利用PUT方法即可快捷簡單地入侵服務(wù)器，上傳Webshell或其他惡意文件，從而獲取敏感數(shù)據(jù)或服務(wù)器權(quán)限。
2.DELETE方法：自身不帶驗證機制，利用DELETE方法可以刪除服務(wù)器上特定的資源文件，造成惡意攻擊。
3.OPTIONS方法：將會造成服務(wù)器信息暴露，如中間件版本、支持的HTTP方法等。
4.TRACE方法：容易引發(fā)XST攻擊（見網(wǎng)站安全相關(guān)）
5.PATCH方法：修改資源的部分內(nèi)容

HTTP 狀態(tài)碼

HTTP狀態(tài)碼根據(jù)首位數(shù)字的不同，其代表的含義也不同：

1XX：信息狀態(tài)碼
  • 100（Continue）：一切正常，可以繼續(xù)發(fā)送請求
2XX：成功狀態(tài)碼
  • 200（OK）：請求成功
  • 204（No Content）：請求成功，但響應(yīng)報文無實體主體。一般用于客戶端往服務(wù)端發(fā)送信息而不需要返回數(shù)據(jù)時。
  • 206（Partial Content）：客戶端進行了范圍請求，響應(yīng)報文中有 Content-Range 指定范圍的實體內(nèi)容。
3XX：重定向狀態(tài)碼
  • 301（Moved Permanently）：永久重定向
  • 302（Found）：臨時重定向
  • 303（See Other）：臨時重定向，要求瀏覽器不會把重定向請求的 POST 方法改成 GET 方法
    注：雖然 HTTP 協(xié)議規(guī)定 301、302 狀態(tài)下重定向時不允許把 POST 方法改成 GET 方法，但是大多數(shù)瀏覽器都會在 301、302 和 303 狀態(tài)下的重定向把 POST 方法改成 GET 方法。
  • 304（Not Modified）：無變化/未修改/只讀，服務(wù)器對比數(shù)據(jù)發(fā)現(xiàn)未修改，客戶端直接從本地緩存讀取即可，返回該狀態(tài)嗎
  • 307（Temporary Redirect）：臨時重定向，要求post方法
4XX：客戶端狀態(tài)碼
  • 400（Bad Request）：報文語法錯誤
  • 402（Unauthorized）：需要認證，一般是要求登錄
  • 403（Forbidden）：請求被拒絕，一般是權(quán)限不足
  • 404（Not Found）：找不到網(wǎng)頁
    409（Conflict）：請求的資源與該資源的當(dāng)前狀態(tài)發(fā)生沖突
    410（Gone）：資源在服務(wù)器上已被永久性刪除
5XX：服務(wù)端狀態(tài)碼
  • 500（Internal Server Error）：服務(wù)器執(zhí)行請求時法發(fā)生錯誤
  • 503（Service Unavailable）：服務(wù)器超負載/停機維護，現(xiàn)在無法處理請求。校園網(wǎng)選課經(jīng)常返回該值。

最全的HTTP1.1狀態(tài)碼

HTTP 報文

HTTP首部字段包含四種：

  1. 通用首部字段（General Header Fields）：請求和響應(yīng)報文兩方都會使用的首部字段。
首部字段名 說明
Cache-Control： 控制緩存的行為
Connection 控制不再轉(zhuǎn)發(fā)給代理的首部字段、管理持久連接
Date 創(chuàng)建報文的日期時間
Pragma 報文指令
Trailer 報文末端的首部一覽
Transfer-Encoding 指定報文主體的傳輸編碼方式
Upgrade 升級為其他協(xié)議
Via 代理服務(wù)器的相關(guān)信息
Warning 錯誤通知
  1. 請求首部字段（Reauest Header Fields）：客戶端向服務(wù)器發(fā)送請求的報文時使用的首部。補充了請求的附加內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)的優(yōu)先等級信息。
首部字段名 說明
Accept 用戶代理可處理的媒體類型
Accept-Charset 優(yōu)先的字符集
Accept-Encoding 優(yōu)先的內(nèi)容編碼
Accept-Language 優(yōu)先的語言（自然語言）
Authorization Web 認證信息
Expect 期待服務(wù)器的特定行為
From 用戶的電子郵箱地址
Host 請求資源所在服務(wù)器
If-Match 比較實體標記（ETag）
If-Modified-Since 比較資源的更新時間
If-None-Match(1.1) 比較實體標記（與 If-Match 相反）
If-Range(1.1) 資源未更新時發(fā)送實體 Byte 的范圍請求
If-Unmodified-Since(1.1) 比較資源的更新時間（與 If-Modified-Since 相反）
Max-Forwards 最大傳輸逐跳數(shù)
Proxy-Authorization 代理服務(wù)器要求客戶端的認證信息
Range(1.1) 實體的字節(jié)范圍請求（斷點續(xù)傳）
Referer 對請求中 URI 的原始獲取方
TE 傳輸編碼的優(yōu)先級
User-Agent HTTP 客戶端程序的信息
  1. 響應(yīng)首部字段（Response Header Fields）：從服務(wù)器向客戶端響應(yīng)時使用的字段，補充響應(yīng)的附加內(nèi)容，也會要求客戶端附加額外信息
首部字段名 說明
Accept-Ranges 是否接受字節(jié)范圍請求
Age 推算資源創(chuàng)建經(jīng)過時間
ETag(1.1) 資源的匹配信息
Location 令客戶端重定向至指定 URI
Proxy-Authenticate 代理服務(wù)器對客戶端的認證信息
Retry-After 對再次發(fā)起請求的時機要求
Server HTTP 服務(wù)器的安裝信息
Set-Cookie 在瀏覽器種cookie，一旦被種下，當(dāng)瀏覽器訪問符合條件的url地址時，會自動帶上這個cookie
Vary 代理服務(wù)器緩存的管理信息
WWW-Authenticate 服務(wù)器對客戶端的認證信息
  1. 實體首部字段（Entiy Header Fields）|針對請求報文和響應(yīng)報文的實體部分使用首部。補充了資源內(nèi)容更新時間等實體有關(guān)的信息。
首部字段名 說明
Allow 資源可支持的 HTTP 方法
Content-Encoding 實體主體適用的編碼方式
Content-Language 實體主體的自然語言
Content-Length 實體主體的大小
Content-Location 替代對應(yīng)資源的 URI
Content-MD5 實體主體的報文摘要
Content-Range 實體主體的位置范圍
Content-Type 實體主體的媒體類型
Expires 實體主體過期的日期時間
Last-Modified 資源的最后修改日期時間

小知識點：

  • 降低服務(wù)器壓力的方法[參考3]
    細節(jié)可看我的文章HTTP緩存

  • 請求首部字段Referer和安全相關(guān)
    細節(jié)可看我的文章XSS，CSRF，XST等網(wǎng)站安全

  • 請求首部字段Max-Forwards和TRACE、OPTIONS方法有關(guān)系
    細節(jié)可看我的文章

HTTP 和 HTTPS 的區(qū)別

主要區(qū)別如下：
  1. https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
  2. http是超文本傳輸協(xié)議，基于TCP連接，信息是明文傳輸；https運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸內(nèi)容都經(jīng)過加密。
  3. http和https使用的端口不一樣，前者是80，后者是443。
  4. http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

HTTPS 相關(guān)

HTTPS 的工作原理

我們都知道HTTPS能夠加密信息，以免敏感信息被第三方獲取，所以很多銀行網(wǎng)站或電子郵箱等等安全級別較高的服務(wù)都會采用HTTPS協(xié)議。

1. 客戶端發(fā)起HTTPS請求
　　這個沒什么好說的，就是用戶在瀏覽器里輸入一個https網(wǎng)址，然后連接到server的443端口。

2. 服務(wù)端的配置
　　采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請，區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務(wù))。
　　這套證書其實就是一對公鑰和私鑰，如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發(fā)給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

3. 傳送證書
　　這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機構(gòu)，過期時間等等。

4. 客戶端解析證書
　　這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。
如果證書沒有問題，那么就生成一個隨機值，然后用證書對該隨機值進行加密，就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。

5. 傳送加密信息
　　這部分傳送的是用證書加密后的隨機值，目的就是讓服務(wù)端得到這個隨機值，以后客戶端和服務(wù)端的通信就可以通過這個隨機值來進行加密解密了。

6. 服務(wù)段解密信息
　　服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內(nèi)容通過該值進行對稱加密，所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。

7. 傳輸加密后的信息
　　這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原。

8. 客戶端解密信息
　　客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息，于是獲取了解密后的內(nèi)容，整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。

HTTPS 的優(yōu)點

正是由于HTTPS非常的安全，攻擊者無法從中找到下手的地方，從站長的角度來說，HTTPS的優(yōu)點有以下2點：

1. SEO方面
　　谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。

2. 安全性
　　盡管HTTPS并非絕對安全，掌握根證書的機構(gòu)、掌握加密算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案，主要有以下幾個好處：
（1）使用HTTPS協(xié)議可認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器；
（2）HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。
（3）HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

HTTPS 的缺點

雖然說 HTTPS 有很大的優(yōu)勢，但其相對來說，還是有些不足之處的，具體來說，有以下2點：

  1. SEO方面
    　　據(jù)ACM CoNEXT數(shù)據(jù)顯示，使用HTTPS協(xié)議會使頁面的加載時間延長近50%，增加10%到20%的耗電，此外，HTTPS協(xié)議還會影響緩存，增加數(shù)據(jù)開銷和功耗，甚至已有安全措施也會受到影響也會因此而受到影響。
    　　而且HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。
    　　最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

  2. 經(jīng)濟方面
    （1）SSL證書需要錢，功能越強大的證書費用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。
    （2）SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統(tǒng)支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
    （3）HTTPS連接緩存不如HTTP高效，大流量網(wǎng)站如非必要也不會采用，流量成本太高。
    （4）HTTPS連接服務(wù)器端資源占用高很多，支持訪客稍多的網(wǎng)站需要投入更大的成本，如果全部采用HTTPS，基于大部分計算資源閑置的假設(shè)的VPS的平均成本會上去。
    （5）HTTPS協(xié)議握手階段比較費時，對網(wǎng)站的相應(yīng)速度有負面影響，如非必要，沒有理由犧牲用戶體驗。

參考：
[1].CS-Notes
[2].不安全的http方法

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容