摘要：服務(wù)器返回狀態(tài)碼時(shí)，設(shè)置響應(yīng)頭的字段。但有可能在斷點(diǎn)續(xù)傳的過程中，資源發(fā)生了修改，就需要判斷，資源有無變化。此外，還可以通過校驗(yàn)報(bào)文的完整性。

1989年為知識(shí)共享而誕生的Web，提出了3項(xiàng)WWW構(gòu)建技術(shù)：

標(biāo)準(zhǔn)通用標(biāo)記語言設(shè)為HTML（HyperText Markup Language，超文本標(biāo)記語言）

文檔傳輸協(xié)議HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）

文檔定位URL（Uniform Resource Locator，統(tǒng)一資源定位符）

無狀態(tài)協(xié)議（不對請求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存，無法實(shí)現(xiàn)狀態(tài)管理），所以后面引入Cookie和LocalStorage等技術(shù)。

請求方法有：GET（獲取資源）、POST（傳輸實(shí)體主體）、PUT（傳輸文件）、HEAD（獲得報(bào)文首部）、DELETE（刪除文件）、OPTIONS（詢問支持的方法）、TRACE（追蹤路徑）、CONNECT（要求用隧道協(xié)議連接代理）

HTTP/1.1中，所有連接默認(rèn)都是持久連接（keep-alive），即建立一次TCP連接后可以進(jìn)行多次HTTP請求和響應(yīng)

管線化，即可并行發(fā)送多個(gè)請求。

Cookie：

1）客戶端發(fā)送請求報(bào)文；
2）服務(wù)器生成包含Cookie信息的響應(yīng)報(bào)文（Set-Cookie字段包含sid）；
3）客戶端發(fā)送帶Cookie信息的請求報(bào)文（Cookie字段的sid）；

HTTP/1.1相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在：

1）持久鏈接，即一次TCP鏈接可支持多次HTTP請求；
2）管線化，即客戶端不用等到之前的http請求結(jié)果返回，就可發(fā)送下一次請求；
3）緩存處理，http1.0采用expires字段，有時(shí)鐘同步問題，http1.1采用Cache-Control；
4）斷點(diǎn)續(xù)傳，優(yōu)化帶寬，增加range字段，返回碼是206（Partial Content）；
5）Host頭域，支持一臺(tái)物理主機(jī)可存在多個(gè)虛擬主機(jī)，一個(gè)IP地址，多個(gè)域名；

HTTP/2.0相較于 HTTP/1.1 協(xié)議的區(qū)別主要體現(xiàn)在：

1）采用WebSocket，支持服務(wù)端推送；
2）多路復(fù)用，連接共享，允許同時(shí)通過單一的HTTP2連接發(fā)起多重的請求-響應(yīng)消息；
3）在tcp與http層間增加了二進(jìn)制分幀層，HTTP/2通信都在一個(gè)連接上完成，這個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流；
4）首部壓縮，HTTP/1.1并不支持 HTTP 首部壓縮，為此 SPDY 和 HTTP/2 應(yīng)運(yùn)而生，SPDY使用的是通用的DEFLATE算法，HTTP/2則使用了專門為首部壓縮而設(shè)計(jì)的 HPACK 算法；
簡書詳解
csdn博客
知乎講解

HTTP報(bào)文本身是由多行數(shù)據(jù)構(gòu)成的字符串文本。

請求報(bào)文與相應(yīng)報(bào)文的結(jié)構(gòu)

請求行：請求的方法、請求URI、HTTP版本
狀態(tài)行：表明響應(yīng)結(jié)果的狀態(tài)碼、原因短語、HTTP版本

壓縮傳輸?shù)膬?nèi)容編碼（gzip、compress、deflate、identity）、分割發(fā)送的分塊傳輸編碼

MIME（Multipurpose Internet Mail Extensions，多用途因特網(wǎng)郵件擴(kuò)展）

1） 200 OK ；請求正常處理
2） 204 No Content ；請求處理成功，但沒有資源可返回
3） 206 Partial Content ； 客戶端進(jìn)行了范圍請求，服務(wù)器成功處理
4） 301 Moved Permanently ； 永久性重定向，即請求的資源已經(jīng)被分配了新的URI
5） 302 Found ； 臨時(shí)重定向，即請求的資源臨時(shí)被分配了新的URI
6） 303 See Other ； 表示請求對應(yīng)的資源存在著另一個(gè)URI，應(yīng)使用GET方法定向獲取
7） 304 Not Modified ； 服務(wù)器資源未改變，可直接使用客戶端未過期的緩存（與重定向無關(guān)）
8） 307 Temporary Redirect ； 臨時(shí)重定向（會(huì)強(qiáng)制瀏覽器不能將POST改為GET方法）
9） 400 Bad Request ； 表示請求報(bào)文中存在語法錯(cuò)誤
10） 401 Unauthorized ； 表明請求需要通過HTTP認(rèn)證，若之前已請求過一次，則表示用戶認(rèn)證失敗
11） 403 Forbidden ； 服務(wù)器拒絕該資源的訪問
12） 404 Not Found ； 服務(wù)器無法找到請求的資源
13） 500 Internal Server Error ； 服務(wù)器發(fā)生內(nèi)部錯(cuò)誤
14） 503 Service Unavailable ； 服務(wù)器超負(fù)荷，無法處理請求
有些時(shí)候，狀態(tài)碼和狀況會(huì)不一致

說明：301和302狀態(tài)碼都是重定向，但區(qū)別是301是永久重定向，302為臨時(shí)重定向。若客戶端將URL保存為書簽，那么301就會(huì)去更新書簽，而302不會(huì)去更新書簽。
重定向：服務(wù)器告訴客戶端，需要重新發(fā)送請求到新的URL。服務(wù)器返回302狀態(tài)碼時(shí)，設(shè)置響應(yīng)頭的Location字段。

HTTP的缺點(diǎn)

1）通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽；—>加密
2）不驗(yàn)證通信方的身份，可能遭遇偽裝；—>驗(yàn)證身份
例子：偽裝的web服務(wù)器；偽裝的客戶端；無訪問權(quán)限的通信方；無法判定無意義請求，可能遭受DoS攻擊；
3） 無法證明報(bào)文的完整性，內(nèi)容可能遭遇篡改；

加密

通信的加密、內(nèi)容的加密

加密方式：對稱密鑰加密（共享密鑰加密）、非對稱密鑰加密（公開密鑰加密）

對稱加密：加密和解密使用相同的密鑰；問題：密鑰如何安全到達(dá)對方；
非對稱加密：一對密鑰（公開密鑰+私有密鑰）；
方式：服務(wù)器擁有一對密鑰，當(dāng)需要加密傳輸時(shí)，服務(wù)器將公開密鑰分發(fā)給客戶端，客戶端利用公開密鑰加密發(fā)送密文給服務(wù)器，服務(wù)器利用私有密鑰解密；
報(bào)文+公開密鑰=密文；密文+公開密鑰!=報(bào)文（技術(shù)上異常困難，離散對數(shù)求值）；
非對稱加密相比對稱加密速度慢；

HTTPS采用混合加密機(jī)制（非對稱加密+對稱加密）

利用非對稱加密 傳輸 對稱加密時(shí)所需的 密鑰，然后采用對稱加密 傳輸主體；

如何判斷服務(wù)器發(fā)來的公開密鑰的真實(shí)性？

借用第三方數(shù)字認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）
1）服務(wù)器將自己的公開密鑰登錄至CA，申請公鑰證書
2）CA頒發(fā)公鑰證書（公開密鑰+CA數(shù)字簽名）
3）服務(wù)器向客戶端發(fā)送公鑰證書
4）客戶端利用瀏覽器內(nèi)置的CA公鑰驗(yàn)證 該公鑰證書的 有效性
5）客戶端使用公開密鑰對報(bào)文加密后發(fā)送

MAC（Message Authentication Code）報(bào)文摘要檢測報(bào)文的完整性

用以確認(rèn)客戶端的客戶端證書

用戶得自行安裝客戶端證書，一般用于網(wǎng)上銀行

補(bǔ)充：抓包工具：wireshark，tcpdump

HTTP緩存分為強(qiáng)制緩存和對比緩存，兩類緩存規(guī)則可以同時(shí)存在，強(qiáng)制緩存優(yōu)先級(jí)高于對比緩存。

強(qiáng)制緩存（Expires/Cache-Control）

HTTP 1.0中Expires的值為服務(wù)端返回的資源到期時(shí)間，所以要求時(shí)鐘同步
HTTP1.1中使用Cache-Control

對比緩存（Etag / If-None-Match 或者Last-Modified / If-Modified-Since ）

對比緩存生效時(shí)，狀態(tài)碼為304，只返回header

Etag / If-None-Match（優(yōu)先級(jí)高）

第一次請求時(shí)，服務(wù)器通過Etag告訴客戶端資源的唯一標(biāo)識(shí)符
再次請求時(shí)，客戶端通過If-None-Match告訴服務(wù)器該資源緩存數(shù)據(jù)庫中的資源標(biāo)識(shí)符，服務(wù)器將其進(jìn)行校驗(yàn)比對，若資源發(fā)生變化（資源標(biāo)識(shí)符變化），則返回修改過的資源，200；若資源未被修改過，則返回304。

Last-Modified / If-Modified-Since

第一次請求時(shí)，服務(wù)器在響應(yīng)請求時(shí)，通過Last-Modified告訴瀏覽器資源的最后修改時(shí)間。
再次請求時(shí)，客戶端通過If-Modified-Since發(fā)送資源的最后修改時(shí)間，服務(wù)器接收到后進(jìn)行校驗(yàn)對比，若資源在該時(shí)間之后被修改過，則返回修改過的資源，200；若資源未被修改過，則返回304。
cnblog講解
個(gè)人理解：客戶端緩存數(shù)據(jù)庫中的資源帶有Expires的時(shí)間、Cache-Control的時(shí)間間隔、If-None-Match的資源標(biāo)識(shí)符 或者 If-Modified-Since的標(biāo)識(shí)時(shí)間。瀏覽器在請求相應(yīng)資源時(shí)，分別判斷資源的各個(gè)標(biāo)識(shí)符，采用緩存資源或者發(fā)送相應(yīng)的http頭部信息給服務(wù)器端進(jìn)行校驗(yàn)。

HTTP1.1 開始支持獲取文件的部分內(nèi)容，通過字段Range 和 Content-Range來實(shí)現(xiàn)。
Range用于請求頭中，指定第一個(gè)字節(jié)和最后一個(gè)字節(jié)的位置。
服務(wù)器會(huì)在 Content-Range 頭部返回當(dāng)前發(fā)送數(shù)據(jù)的范圍和文件總大小。
但有可能在斷點(diǎn)續(xù)傳的過程中，資源發(fā)生了修改，就需要判斷，資源有無變化。這個(gè)通過Etag資源標(biāo)識(shí)符來做，每個(gè)資源Etag的值通過MD5來計(jì)算。
此外，還可以通過MD5校驗(yàn)報(bào)文的完整性。服務(wù)器預(yù)先提供一個(gè)MD5校驗(yàn)和，用戶下載完所有文件以后，用MD5算法計(jì)算下載文件的MD5校驗(yàn)和，然后通過檢查這兩個(gè)校驗(yàn)和是否一致，就能判斷下載的文件是否出錯(cuò)。

W3school

get可被緩存

get請求保留在瀏覽器歷史紀(jì)錄中

get請求可被收藏為書簽

get請求不應(yīng)在處理敏感數(shù)據(jù)時(shí)使用，get請求在url中發(fā)送，post請求在http消息主體中發(fā)送。

get請求長度有限制(url的限制),post請求對數(shù)據(jù)長度沒有要求

get只能是url編碼

get參數(shù)會(huì)顯示在url中

后退和刷新，post會(huì)被重新提交

get是冪等的，意味著對同一URL的多個(gè)請求應(yīng)該返回同樣的結(jié)果。

對資源的增，刪，改，查操作，其實(shí)都可以通過GET/POST完成，不需要用到PUT和DELETE

主動(dòng)攻擊：

1） SQL注入攻擊
方式：把SQL命令插入到表單中提交或URL中的查詢字符串中，以欺騙服務(wù)器執(zhí)行惡意的SQL命令；
解決方法：對用戶的輸入進(jìn)行校驗(yàn)、不使用管理員權(quán)限的數(shù)據(jù)庫連接、機(jī)密信息加密存放；
2） OS命令注入攻擊（利用web應(yīng)用的漏洞）；

被動(dòng)攻擊：

1）跨站腳本攻擊XSS
方式：在正規(guī)網(wǎng)站的URL查詢字段中加入script標(biāo)簽，使客戶端在瀏覽正規(guī)網(wǎng)站的同時(shí)，運(yùn)行JS代碼；
解決辦法：對用戶的輸入進(jìn)行校驗(yàn)、寫到頁面的內(nèi)容先進(jìn)行編碼、用適當(dāng)?shù)姆椒▽?HTML，JS 進(jìn)行轉(zhuǎn)義、將Set-Cookie設(shè)置為HttpOnly，則通過JS腳本無法讀取到cookie信息；
2）跨站點(diǎn)請求偽造（CSRF）
方式：用戶點(diǎn)擊了正規(guī)網(wǎng)站和黑客網(wǎng)站，黑客網(wǎng)站向往正規(guī)網(wǎng)站服務(wù)器發(fā)送了請求，這個(gè)請求會(huì)攜帶用戶本地瀏覽器的cookie，所以得以成功跨站點(diǎn)請求偽造。
解決辦法：1）設(shè)置驗(yàn)證HTTP Referer字段，以確保請求的來源網(wǎng)站的合法性。2）設(shè)置token。
CSDN博客
3）HTTP首部注入（攻擊者在響應(yīng)首部字段內(nèi)插入換行，添加任意響應(yīng)首部或主體）、
4）郵件首部注入攻擊
其他攻擊：DoS攻擊（拒絕服務(wù)攻擊，向服務(wù)器發(fā)送大量請求，造成服務(wù)器資源過載）
DDoS（分布式拒絕服務(wù)攻擊，常利用感染病毒的計(jì)算機(jī)作為攻擊者的攻擊跳板）
CSDN博客

跨域解決方案：

CORS（Cross-Origin Resource Sharing，跨域源資源共享），IE8通過XDomainRequest對象支持CORS，其他瀏覽器通過XHR對象原生支持CORS。

CORS跨域源資源共享需要客戶端和服務(wù)器共同支持，原理是通過自定義的HTTP頭部讓客戶端與服務(wù)器溝通，而目前各大瀏覽器都實(shí)現(xiàn)了對CORS的原生支持。即，當(dāng)跨域請求時(shí)，瀏覽器會(huì)自動(dòng)在HTTP頭部加上自定義字段，比如Origin頭部。也就是說要實(shí)現(xiàn)CORS，需要在服務(wù)器端進(jìn)行設(shè)置。服務(wù)器端返回Access-Control-Allow-Origin字段。CORS請求分為簡單請求、非簡單請求（多一次http請求），默認(rèn)CORS跨源請求都不帶cookie，如果需要帶cookie，則需要設(shè)置Access-Control-Allow-Cendentials:true。
優(yōu)點(diǎn)：支持所有HTTP請求。 缺點(diǎn)：不能兼容老瀏覽器。
阮一峰CORS

JSONP（JSON with padding）

原理：利用script標(biāo)簽沒有跨域限制的特點(diǎn)，客戶端將script腳本的src設(shè)置為服務(wù)器的請求地址。服務(wù)器會(huì)返回一段js代碼，并在本地執(zhí)行，形如：callback({"name":"Nicholas"});，一個(gè)帶參數(shù)的函數(shù)，這個(gè)參數(shù)就是需要請求的json數(shù)據(jù)。這個(gè)函數(shù)名是服務(wù)器端根據(jù)客戶端發(fā)過去的數(shù)據(jù)動(dòng)態(tài)設(shè)置的（原理是字符串拼接）。而這個(gè)函數(shù)會(huì)事先在本地聲明如何處理json數(shù)據(jù)。
優(yōu)點(diǎn)：簡單易用，支持瀏覽器與服務(wù)器雙向通信，無瀏覽器兼容性問題；
缺點(diǎn)：不安全，由于JSONP是從其他域中加載代碼執(zhí)行；難以確定請求是否失敗；只支持GET請求；傳輸格式是字符串，不是json格式；
網(wǎng)絡(luò)上的解釋

其他方法：如html5中postMessage方法，window.name，document.domain

更多博客：https://github.com/Lmagic16/b...