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

1989年為知識共享而誕生的Web，提出了3項WWW構建技術：

標準通用標記語言設為HTML（HyperText Markup Language，超文本標記語言）

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

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

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

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

HTTP/1.1中，所有連接默認都是持久連接（keep-alive），即建立一次TCP連接后可以進行多次HTTP請求和響應

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

Cookie：

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

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

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

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

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

HTTP報文本身是由多行數(shù)據構成的字符串文本。

請求報文與相應報文的結構

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

壓縮傳輸?shù)膬热菥幋a（gzip、compress、deflate、identity）、分割發(fā)送的分塊傳輸編碼

MIME（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展）

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

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

HTTP的缺點

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

加密

通信的加密、內容的加密

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

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

HTTPS采用混合加密機制（非對稱加密+對稱加密）

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

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

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

MAC（Message Authentication Code）報文摘要檢測報文的完整性

用以確認客戶端的客戶端證書

用戶得自行安裝客戶端證書，一般用于網上銀行

補充：抓包工具：wireshark，tcpdump

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

強制緩存（Expires/Cache-Control）

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

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

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

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

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

Last-Modified / If-Modified-Since

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

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

W3school

get可被緩存

get請求保留在瀏覽器歷史紀錄中

get請求可被收藏為書簽

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

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

get只能是url編碼

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

后退和刷新，post會被重新提交

get是冪等的，意味著對同一URL的多個請求應該返回同樣的結果。

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

主動攻擊：

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

被動攻擊：

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

跨域解決方案：

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

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

JSONP（JSON with padding）

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

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

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