HTTP簡明學習

時間 2019-11-20

標籤 http 簡明學習欄目 HTTP/TCP 简体版

原文原文鏈接

前面的話

　　本文將詳細介紹HTTP主要內容javascript

概述

　　Web 的誕生，源於三大技術的誕生，它們都是當年 Web 之父 Tim Berners-Lee 本身開發的，世界上第一個網站誕生的時間是 1991 年，三大技術的誕生也就是在此以前的不久：css

　　一、能夠指向任何網頁的 URLhtml

　　二、htmljava

　　三、HTTP 協議nginx

　　HTTP 是超文本傳輸協議 Hypertext Transfer Protocol 的縮寫。從服務器上到瀏覽器裏，這個過程是基於 HTTP 協議來傳輸數據的。Web 內容都是存儲在 Web 服務器上的，Web 服務器都是基於 HTTP 協議的，所以也被稱爲 HTTP 服務器。HTTP 服務器存儲了各類類型的數據，若是 HTTP 的客戶端發出請求的話，服務器就會返回數據給客戶端，叫作響應web

　　HTTP 的服務器和客戶端是萬維網（ World Wide Web ）的基本單元。最多見的客戶端就是瀏覽器。瀏覽一個頁面的時候，瀏覽器會向服務器發出一個 HTTP 請求。等到服務器響應返回以後，瀏覽器再去處理響應數據，以美觀的形式展現給用戶chrome

【特性】express

　　HTTP 是一個無狀態的協議。所謂無狀態（ stateless ）意思就是：對於以前的交互沒有記錄。每次交互能用的信息就只有此次交互所攜帶的信息json

　　換句話說，HTTP 協議是沒有辦法記住以前的一次請求的，因此也沒有辦法根據前一次請求來輔助後一次請求。當一個Web 應用看起來彷佛能夠記住以前的交互，例如，能夠記住你的用戶名，其實它採用的技巧已經超出了 HTTP 自己。HTTP 的信息就好像是能夠自銷燬的，每次讀取完畢，馬上就消失了。總之，HTTP 就是無狀態的，也就是不能記錄或者維持某種狀態的。瀏覽器

　　所以，HTTP 方法具備冪等性，一次和屢次請求某一個資源應該具備一樣的反作用

【資源和URL】

　　HTTP 故事的開始是瀏覽器發出請求。可是請求的是什麼呢？是服務器上的資源，英文叫 Resource

　　對應的每個資源，都有一個 URL ，也就是統一資源定位地址，指向這個資源。不過資源分兩種：一種是靜態資源，也就是各類文件了，最多見的就是靜態 HTML ，可是也能夠是 PDF ，json 文件等等。另一種，就是動態資源，也就是 URL 指向的地方不是一個文件，而是一段代碼的入口，服務器通過運算後，才返回運算結果給客戶端。因此，咱們有 https://xiaohuochai.cc/static/main.css ，這個 URL 就是指向一個靜態資源的。若是是 https://xiaohuochai.cc/posts 這個可能就是指向動態資源的，後臺對應的可能就是一個 API

請求和響應

【請求】

　　一、請求行

　　第一行的內容被叫作請求行 Request Line ，具體形式以下

GET/POST [url] HTTP/[version]   GET / HTTP/1.1

　　這一行就是以HTTP 方法（ HTTP Method ）打頭，通常是 GET 或者 POST ，固然還有其餘不太經常使用的方法。當咱們用 GET 發請求的時候，通常咱們就是想要從服務器上 GET （拿到）一些內容，而不是想去修改服務器數據。POST 正好就是用來修改服務器上的數據的。到底要 GET 或者要修改的資源，就是後面的 URL 這一項來指定了。上面例子中，請求的 URL 是 / 。最後就是跟 HTTP 字樣，再跟上究竟是使用的哪一個版本的 HTTP 協議，目前通常都是 HTTP 1.1 了

　　二、請求頭部

[header 名]：[header 值]

> Host: haoqicat.com
> User-Agent: curl/7.43.0
> Accept: */*

　　都是以冒號隔開的鍵值對。上面三項：

Host 表明被請求的主機，也就是 haoqicat.com
User-Agent 表明用戶使用的客戶端，咱們這裏用的是 curl
Accept 後面指明客戶端能夠接受的返回資源的類型，* 表明全部類型都接受

　　三、負載數據

　　header 之下，一個 request 中還可能包含負載數據（ payload ）。這一項，請求中不必定會包含。GET 請求都是不帶負載數據的，POST 請求帶負載數據。這個挺好理解，POST 方法的請求都是要改動服務器數據的，固然要在請求中攜帶數據過去。

　　好比，頁面上有一個表單 form ，填寫幾項數據，而後一點提交，這個就會發出一個 POST 請求，而填寫的數據，就會做爲 payload 成爲請求的一部分

【響應】

　　一、狀態行

　　對於請求有請求行，響應的第一行也很特別，叫作狀態行 （ status line ），基本格式以下

HTTP[版本號] [狀態碼] [狀態信息]

HTTP/1.1 200 OK

　　簡單介紹一下狀態碼

20x 的狀態碼都表明某種成功狀態。最多見的 200 ，它的意義，就正如它後面跟的狀態信息 同樣，表明一切 OK 。
30x 的狀態碼，意味着資源已經被移動到其餘地方了，可是響應中給出了應該跳轉到哪裏去找到這個資源。這個行爲的術語就叫作 redirect （重定向）。
40x 的代碼也都是表明一種客戶端請求錯誤 。一個最多見的狀態碼 404 ，它的意義也跟它後面緊跟的狀態信息所說的 同樣：Page Not Found （頁面未找到）。
50x 的狀態嗎也很常見。返回的若是是這一系列的狀態碼，就意味着 服務器端在處理請求的時候出錯 。50x 出現，對於開發者，通常意味着服務器端代碼出了錯誤。

　　二、響應頭部

[ header 名]: [ header 值]

Server: nginx/1.4.6 (Ubuntu)
Date: Fri, 09 Dec 2016 09:23:59 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding

　　三、響應主體

　　響應主體，response body ，也能夠叫作 payload

<!DOCTYPE html>
<html>
<head>
  <title>xiaohuochai</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  ...
</head>
<body>
...

</body>
</html>

【查詢字符串】

　　GET 請求中攜帶一些數據到服務器端的方法並不惟一，可是一種很是簡單也很是經常使用的方式就是，使用查詢字符串來傳遞數據，或者叫傳遞參數

　　若是打開 chrome 瀏覽器，打開 chrome 開發者工具的 Network 標籤。而後瀏覽器中訪問

http://xiaohuochai.com/?name=xiaohuochai

　　上面的 ?name=xiaohuochai就是所謂的查詢字符串，這裏面傳遞了一個參數，也就是 name ，參數值是 xiaohuochai

　　也能夠傳遞多組參數的，每組之間以 & 隔開

http://xiaohuochai.com/?name=xiaohuochai&email=peter@peter.com

　　甚至能夠寫成這樣

?order=desc&shoe[color]=blue&shoe[type]=converse

　　服務器端若是是 express ，就能夠很方便的用 req.query 來接收傳遞過來的參數

　　若是想添加一個備用郵箱，可使用+來進行鏈接

?name=peter&email=happypeter1983@gmail.com+b@b.com

方法

　　每次發請求的時候，處理請求的 url 以外，還必然有一個請求方法

　　HTTP方法包括以下

GET ，最經常使用的一種，用於從服務器上「獲得」某個資源
POST，往服務器上寫入數據，跟 GET 做用相反
PUT，也是寫入數據，一般的用法是 POST 建立新數據，PUT 用來更新已有數據
DELETE，刪除服務器上的數據
HEAD，跟 GET 同樣，也是請求服務器上的資源，可是隻要響應的 Headers ，這個不太經常使用，不用管
其餘的還有 TRACE，OPTIONS，PATCH 等，都不經常使用

【RestFul】

　　上面的列出的各類 HTTP 方法的使用場合其實沒有嚴格的規定的，若是做爲開發者，非要用 GET 請求來寫數據到服務器，也不是不能夠作到的。可是尊重 HTTP 方法（有時候也叫作 HTTP 動詞）的原本用法，是個好的習慣。

　　Nodejs 開發領域很是經常使用的 RESTful 架構，就是尊重 HTTP 方法本意的一個典範：

GET /posts       # 讀取全部文章
GET /posts/:id   # 讀取一篇文章
POST /posts      # 發佈一篇文章
PUT /posts/:id   # 更新一篇文章
DELTE /posts/:id # 刪除一篇文章
...

　　在 RESTful 的思路里面，HTTP 的方法的本意和用它真正發出請求執行的行爲是很是吻合的

會話

　　會話就是服務器和瀏覽器的保有共同的信息的這段時間。換句話，會話開始和結束，就意味着服務器從認識一個瀏覽器到再也不認識這個瀏覽器

　　會話可讓無狀態的 HTTP 協議保持特定的狀態。這種在客戶端與服務器之間傳遞會話 id的機制，能讓服務器建立一種各次請求之間的持續鏈接狀態。Web 開發人員利用這種人造的狀態，來構建一些」有狀態「的應用場景：例如用戶處於一直登錄的狀態，購物車裏面以前添加的商品，後續訪問中還有等等。不過即便這樣，每個 HTTP 請求本質上來講仍是無狀態的，各次請求之間並不知道彼此的存在。

【技術機制】

　　實現會話的方法不惟一，最多見的一個方式是這樣：

　　一、準備創建會話的時候，服務器會在本身的內存裏建立一個新的變量，例如這個變量叫作 session-3254

　　二、服務器把這個會話的 id 也就是 3254 發送到瀏覽器，瀏覽器會把這個 id 保存到 cookie 中

　　三、每次瀏覽器再去訪問服務器的時候，都會攜帶 cookie 中存放的 3254 這個會話 id 值，這樣瀏覽器就認識這個瀏覽器了

　　四、服務器端的 session-3254 變量中能夠存聽任意的會話數據，例如：用戶名，購物車裏有哪幾件商品等等

　　五、每次瀏覽器訪問服務器，均可以憑藉本身的會話 id 去服務器的 session-3254 變量中去認領屬於個人信息

　　每個請求都會包含這個會話 id ，這樣服務器就能惟一確認客戶端啦。這樣，直到會話過時，客戶端和服務器都是互相認識的

【會話過時】

　　服務器上有多少個瀏覽器在訪問，就會在本身內存中建立多少了相似 session-3254 這樣的變量。可是，還有一點很是重要，在一個會話裏發出的會話 id 是惟一的，並且有一個很短的過時時間。那什麼狀況下會話就會過時呢？

　　一、手動刪掉 cookie 中的會話 id （在 chrome devtools 裏，右鍵 cookies 而後刪除它）

　　二、點一個網站的退出登陸按鈕

　　三、關閉網站有時候也一般能結束會話

【會話劫持】

　　會話 id 做爲一個惟一的令牌來惟一標識一個會話。一般，會話 id 是做爲 cookie 存儲在計算機上的一個隨機字符串.。不少 web 應用的用戶認證系統所在作的事情，當用戶的用戶名和密碼匹配以後，會話 id 會存儲在用戶的瀏覽器裏，這樣下一個請求就不用從新認證了

　　不幸的是，若是一個攻擊者拿到了這個會話 id ，他就會跟我共享這一個會話，那服務器就會把他當成我，個人全部權限，他都不須要知道個人用戶名密碼，均可以得到了

　　這種狀況就須要安全的 HTTP 也就是 HTTPS 來幫忙啦。經過 HTTPS 發送的請求和響應在發送前都會被加密。這意味着若是一個惡意的黑客監聽 HTTP 通訊，他獲得的信息都是加密的，就是截獲了也看不懂是個啥

XSS

　　跨站腳本（英語：Cross-site scripting，一般簡稱爲：XSS）是一種網站應用程序的安全漏洞攻擊，是代碼注入的一種。它容許惡意用戶將代碼注入到網頁上，其餘用戶在觀看網頁時就會受到影響。這類攻擊一般包含了HTML以及用戶端腳本語言。

　　XSS攻擊一般指的是經過利用網頁開發時留下的漏洞，經過巧妙的方法注入惡意指令代碼到網頁，使用戶加載並執行攻擊者惡意製造的網頁程序。這些惡意網頁程序一般是JavaScript，但實際上也能夠包括Java，VBScript，ActiveX，Flash或者甚至是普通的HTML。攻擊成功後，攻擊者可能獲得更高的權限（如執行一些操做）、私密網頁內容、會話和cookie等各類內容

　　如網站上有個評論框，而後惡意訪客在裏面輸入了

Hello World <script>alert('Hello World')</script>

　　網站的行爲被篡改了，或者說網站已經被 XSS 了

　　惡意用戶可使用 HTML 和 javascript 代碼對服務器或者之後訪問這個頁面的用戶發起毀滅性的攻擊。舉個例子，一個攻擊者可使用 javascript 代碼去獲取全部在他以後訪問這個頁面的用戶的會話 id ，而後假裝成這個用戶

【解決辦法】

　　一、消除有問題的輸入。好比script標籤，或者使用一個更安全的輸入格式，好比 Markdown，這樣就能夠阻止 HTML 和 javascript 同時出如今用戶的輸入裏

　　二、在顯示以前轉義用戶輸入的全部數據

　　總結起來一句話，老是對用戶輸入的內容作無害處理

【CSP】

　　CSP 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源能夠加載和執行，等同於提供白名單。它的實現和執行所有由瀏覽器完成，開發者只需提供配置。

　　CSP 大大加強了網頁的安全性。攻擊者即便發現了漏洞，也無法注入腳本，除非還控制了一臺列入了白名單的可信主機

　　兩種方法能夠啓用 CSP。一種是經過 HTTP 頭信息的Content-Security-Policy的字段

Content-Security-Policy: script-src 'self'; object-src 'none';
style-src cdn.example.org third-party.org; child-src https:

　　另外一種是經過網頁的<meta>標籤

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">

　　下面是admin.xiaohuochai.cc的csp配置

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: https://pic.xiaohuochai.site https://static.xiaohuochai.site; style-src 'self' 'unsafe-inline'; frame-src https://demo.xiaohuochai.site https://xiaohuochai.site;";

CSRF

　　跨站請求僞造（Cross-site request forgery），也被稱爲 one-click attack 或者 session riding，一般縮寫爲 CSRF 或者 XSRF，是一種挾制用戶在當前已登陸的Web應用程序上執行非本意的操做的攻擊方法。跟跨網站腳本（XSS）相比，XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任

　　跨站請求攻擊，簡單地說，是攻擊者經過一些技術手段欺騙用戶的瀏覽器去訪問一個本身曾經認證過的網站並執行一些操做（如發郵件，發消息，甚至財產操做如轉帳和購買商品）。因爲瀏覽器曾經認證過，因此被訪問的網站會認爲是真正的用戶操做而去執行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求自己是用戶自願發出的

【防護措施】

　　一、檢查Referer字段

　　HTTP頭中有一個Referer字段，這個字段用以標明請求來源於哪一個地址。在處理敏感數據請求時，一般來講，Referer字段應和請求的地址位於同一域名下。而若是是CSRF攻擊傳來的請求，Referer字段會是包含惡意網址的地址，這時候服務器就能識別出惡意的訪問。

　　這種辦法簡單易行，工做量低，僅須要在關鍵訪問處增長一步校驗。但這種辦法也有其侷限性，因其徹底依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但並沒有法保證來訪的瀏覽器的具體實現，亦沒法保證瀏覽器沒有安全漏洞影響到此字段。而且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能

　　二、添加校驗token

　　因爲CSRF的本質在於攻擊者欺騙用戶去訪問本身設置的地址，因此若是要求在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在cookie中，而且攻擊者沒法僞造的數據做爲校驗，那麼攻擊者就沒法再執行CSRF攻擊。這種數據一般是表單中的一個數據項。服務器將其生成並附加在表單中，其內容是一個僞亂數。當客戶端經過表單提交請求時，這個僞亂數也一併提交上去以供校驗。正常的訪問時，客戶端瀏覽器可以正確獲得並傳回這個僞亂數，而經過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個僞亂數的值，服務器端就會由於校驗token的值爲空或者錯誤，拒絕這個可疑請求

　　三、使用JWT。並將其存儲在本地存儲localStorage中

DDOS

　　典型的 DDoS 攻擊，全稱是 Distributed Denial of Service，翻譯成中文就是分佈式拒絕服務。通常來講是指攻擊者利用「肉雞」對目標網站在較短的時間內發起大量請求，大規模消耗目標網站的主機資源，讓它沒法正常服務。在線遊戲、互聯網金融等領域是 DDoS 攻擊的高發行業

　　如何應對DDOS攻擊？

　　一、高防服務器

　　高防服務器主要是指能獨立硬防護 50Gbps 以上的服務器，可以幫助網站拒絕服務攻擊，按期掃描網絡主節點等，這東西是不錯，就是貴

　　二、黑名單

　　設置黑名單，但也會封鎖正常流量，影響到正常業務

　　三、DDOS清洗

　　對用戶請求數據進行實時監控，及時發現DOS攻擊等異常流量，在不影響正常業務開展的狀況下清洗掉這些異常流量

　　四、CDN

　　在現實中，CDN 服務將網站訪問流量分配到了各個節點中，這樣一方面隱藏網站的真實 IP，另外一方面即便遭遇 DDoS 攻擊，也能夠將流量分散到各個節點中，防止源站崩潰

HTTP2

　　HTTP/2（超文本傳輸協議第2版，最初命名爲HTTP 2.0），簡稱爲h2（基於TLS/1.2或以上版本的加密鏈接）或h2c（非加密鏈接），是HTTP協議的的第二個主要版本，使用於萬維網。 HTTP/2是HTTP協議自1999年HTTP 1.1發佈後的首個更新，主要基於SPDY協議。它由互聯網工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工做小組進行開發。該組織於2014年12月將HTTP/2標準提議遞交至IESG進行討論，於2015年2月17日被批准

　　HTTP/2標準於2015年5月以RFC 7540正式發表。多數主流瀏覽器已經在2015年末支持了該協議。此外，根據W3Techs的數據，在2017年5月，在排名前一千萬的網站中，有13.7%支持了HTTP/2

　　HTTP/2的出現，相比於 HTTP 1.x ，大幅度的提高了 web 性能。在與 HTTP/1.1 徹底語義兼容的基礎上，進一步減小了網絡延遲

【多路複用】

　　多路複用容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息

　　衆所周知，在 HTTP/1.1 協議中，瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量限制。超過限制數目的請求會被阻塞。chrome下是6個，這也是爲什麼一些站點會有多個靜態資源 CDN 域名的緣由之一

　　而HTTP/2 的多路複用(Multiplexing) 則容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息

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

【二進制分幀】

　　HTTP/2 全部性能加強的核心在於新的二進制分幀層，它定義瞭如何封裝 HTTP 消息並在客戶端與服務器之間傳輸

　　這裏所謂的「層」，指的是位於套接字接口與應用可見的高級 HTTP API 之間一個通過優化的新編碼機制：HTTP 的語義（包括各類動詞、方法、標頭）都不受影響，不一樣的是傳輸期間對它們的編碼方式變了。HTTP/1.x 協議以換行符做爲純文本的分隔符，而 HTTP/2 將全部傳輸的信息分割爲更小的消息和幀，並採用二進制格式對它們編碼

【首部壓縮】

　　每一個 HTTP 傳輸都承載一組標頭，這些標頭說明了傳輸的資源及其屬性。在 HTTP/1.x 中，此元數據始終以純文本形式，一般會給每一個傳輸增長 500–800 字節的開銷。若是使用 HTTP Cookie，增長的開銷有時會達到上千字節。爲了減小此開銷和提高性能，HTTP/2 使用 HPACK 壓縮格式壓縮請求和響應標頭元數據

【服務器端推送】

　　HTTP/2 新增的另外一個強大的新功能是，服務器能夠對一個客戶端請求發送多個響應。換句話說，除了對最初請求的響應外，服務器還能夠向客戶端推送額外資源，而無需客戶端明確地請求