HTTP——https、http緩存、get與post、web安全、跨域

HTTP誕生

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

1. 標準通用標記語言設爲HTML（HyperText Markup Language，超文本標記語言）
2. 文檔傳輸協議HTTP（HyperText Transfer Protocol，超文本傳輸協議）
3. 文檔定位URL（Uniform Resource Locator，統一資源定位符）

HTTP特色

• 無狀態協議（不對請求和響應之間的通訊狀態進行保存，沒法實現狀態管理），因此後面引入Cookie和LocalStorage等技術。
• 請求方法有：GET（獲取資源）、POST（傳輸實體主體）、PUT（傳輸文件）、HEAD（得到報文首部）、DELETE（刪除文件）、OPTIONS（詢問支持的方法）、TRACE（追蹤路徑）、CONNECT（要求用隧道協議鏈接代理）
• HTTP/1.1中，全部鏈接默認都是持久鏈接（keep-alive），即創建一次TCP鏈接後能夠進行屢次HTTP請求和響應
• 管線化，便可並行發送多個請求。

• Cookie：

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

http1.0/1.1/2.0的區別

• HTTP/1.1相較於 HTTP/1.0 協議的區別主要體如今：

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

• HTTP/2.0相較於 HTTP/1.1 協議的區別主要體如今：

1）採用WebSocket，支持服務端推送；
2）多路複用，鏈接共享，容許同時經過單一的HTTP2鏈接發起多重的請求-響應消息；
3）在tcp與http層間增長了二進制分幀層，HTTP/2通訊都在一個鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流；
4）首部壓縮，HTTP/1.1並不支持 HTTP 首部壓縮，爲此 SPDY 和 HTTP/2 應運而生，SPDY使用的是通用的DEFLATE算法，HTTP/2則使用了專門爲首部壓縮而設計的 HPACK 算法；
簡書詳解
csdn博客
知乎講解

HTTP報文

• HTTP報文自己是由多行數據構成的字符串文本。
• 請求報文與相應報文的結構

請求行：請求的方法、請求URI、HTTP版本
狀態行：代表響應結果的狀態碼、緣由短語、HTTP版本

• 壓縮傳輸的內容編碼（gzip、compress、deflate、identity）、分割發送的分塊傳輸編碼
• MIME（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展）

HTTP狀態碼

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 ； 服務器發生內部錯誤
14） 503 Service Unavailable ； 服務器超負荷，沒法處理請求
有些時候，狀態碼和情況會不一致

說明：301和302狀態碼都是重定向，但區別是301是永久重定向，302爲臨時重定向。若客戶端將URL保存爲書籤，那麼301就會去更新書籤，而302不會去更新書籤。
重定向：服務器告訴客戶端，須要從新發送請求到新的URL。服務器返回302狀態碼時，設置響應頭的Location字段。

HTTPS（HTTP over SSL，包括加密、認證、完整性保護）

• HTTP的缺點

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

• 加密

  • 通訊的加密、內容的加密
  • 加密方式：對稱密鑰加密（共享密鑰加密）、非對稱密鑰加密（公開密鑰加密）

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

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

利用非對稱加密 傳輸 對稱加密時所需的 密鑰，而後採用對稱加密 傳輸主體；

• 如何判斷服務器發來的公開密鑰的真實性？

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

• MAC（Message Authentication Code）報文摘要檢測報文的完整性
• 用以確認客戶端的客戶端證書

用戶得自行安裝客戶端證書，通常用於網上銀行

• 補充：抓包工具：wireshark，tcpdump

HTTP緩存

• HTTP緩存分爲強制緩存和對比緩存，兩類緩存規則能夠同時存在，強制緩存優先級高於對比緩存。

• 強制緩存（Expires/Cache-Control）

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

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

對比緩存生效時，狀態碼爲304，只返回header

1. Etag / If-None-Match（優先級高）

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

1. Last-Modified / If-Modified-Since

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

http如何斷點續傳

HTTP1.1 開始支持獲取文件的部份內容，經過字段Range 和 Content-Range來實現。
Range用於請求頭中，指定第一個字節和最後一個字節的位置。
服務器會在 Content-Range 頭部返回當前發送數據的範圍和文件總大小。
但有可能在斷點續傳的過程當中，資源發生了修改，就須要判斷，資源有無變化。這個經過Etag資源標識符來作，每一個資源Etag的值經過MD5來計算。
此外，還能夠經過MD5校驗報文的完整性。服務器預先提供一個MD5校驗和，用戶下載完全部文件之後，用MD5算法計算下載文件的MD5校驗和，而後經過檢查這兩個校驗和是否一致，就能判斷下載的文件是否出錯。

get與post區別

W3school

1. get可被緩存
2. get請求保留在瀏覽器歷史紀錄中
3. get請求可被收藏爲書籤
4. get請求不該在處理敏感數據時使用，get請求在url中發送，post請求在http消息主體中發送。
5. get請求長度有限制(url的限制),post請求對數據長度沒有要求
6. get只能是url編碼
7. get參數會顯示在url中
8. 後退和刷新，post會被從新提交
9. get是冪等的，意味着對同一URL的多個請求應該返回一樣的結果。
10. 對資源的增，刪，改，查操做，其實均可以經過GET/POST完成，不須要用到PUT和DELETE

web安全

• 主動攻擊：

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

• 被動攻擊：

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

跨域

跨域解決方案：

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

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

1. JSONP（JSON with padding）

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

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

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