《圖解HTTP》閱讀筆記

 

 HTTP基礎的簡單理解

在瞭解HTTP協議以前，咱們先了解下TCP/IP的參考模型，TCP/IP參考模型分爲四層：應用層、傳輸層、網絡層、鏈路層(數據鏈路層)。

應用層：爲不一樣的網絡應用提供所需的服務。

傳輸層：爲應用層實體提供端到端的通訊/傳輸功能，確保數據包的按順序傳送及數據的完整性。

網絡層：處理網絡上流動的數據包，它所包含的協議涉及到數據包在整個網絡上的邏輯傳輸。

鏈路層：監控數據交換，處理網絡鏈接的硬件部分。

TCP/IP通訊傳輸流以下圖所示：

 

HTTP在各層的封裝處理：

 

與HTTP協議密切相關的協議/服務：IP，TCP，DNS

IP協議負責數據包的傳送，固然，這須要配合IP地址和MAC地址，IP間的通訊依賴MAC地址，這就涉及到用以解析地址的ARP協議了。

TCP提供了可靠的字節流服務，對要發送的大塊數據進行分割成小數據包以易於傳輸，而且該協議可確認數據包是否送達到目的方。

DNS服務負責解析域名

URI(統一資源標識符)和URL(統一資源定位符)

URI：一個用於標識某一互聯網資源名稱的字符串。組成：主機名(含端口號)+相對路徑+標識符

URL：對能夠從互聯網上獲得的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標準資源的地址。組成：協議+主機名(含端口號)+相對路徑

區別：URI表示請求資源在互聯網上存在的位置，URL在表示請求資源的位置同時還要說明如何訪問到這個資源，URL是URI的一個子集。參考資源：URL和URI的區別

Cookies

HTTP協議用於客戶端和服務端之間經過請求和響應的交換所達成的通訊，而且它是一種無狀態的協議，不會對請求和響應之間的通訊狀態進行保存(沒法根據前一次請求對此次請求作出處理)，但爲了可以有保存狀態的功能，引入了cookies技術。

持久鏈接

HTTP初始版本時，每進行一次HTTP請求就會斷開一次TCP鏈接，這狀況在早期傳輸文本很小的時候倒也不以爲如何，可是隨着時代的進步，所需傳輸的內容種類愈來愈多和內容愈來愈大了，每次鏈接後都會斷開請求就大幅度的增長了通訊量的開銷了。幸虧，自HTTP/1.1和部分HTTP/1.0來，有了持久鏈接這麼個神奇的東西，它規定了只要任何一方沒有明確的提出斷開鏈接，那麼就保持TCP鏈接狀態。而在維持的TCP鏈接期間，能夠屢次進行HTTP請求來傳輸須要的內容。

HTTP/1.1默認保持持久鏈接，在HTTP的頭部信息中會有Connection: Keep-alive屬性，咱們也能夠經過瀏覽器開發工具的NetWork面板查看這個屬性的狀態及HTTP請求信息：

如何關閉持久鏈接：在響應頭設置Connection屬性爲close.

得益於持久鏈接，HTTP實現了管線化，可以作到同時並行發送多個請求，而無需一個接一個的等待響應。

HTTP請求的內容結構

HTTP協議交互的信息稱爲HTTP報文，經過下面的圖來看看HTTP報文的結構：

除卻空行(回車符、換行符)，大體分爲報文首部和報文主體。報文首部包含請求行(請求的方法、URI、HTTP版本)和狀態行(響應狀態碼、緣由短語、HTTP版本)，首部字段(請求和響應的條件和屬性)，其餘(未定義的首部)。

首部字段

首部字段規定了客戶端如何處理請求和服務端如何處理響應，根據用途可分爲四種：請求首部(請求報文使用的首部)，響應首部(響應報文使用的首部)，通用首部(請求和響應通用的首部)，實體首部(報文實體部分使用的首部)。

HTTP/1.1首部字段列表

通用首部字段

1 2 3 4 5 6 7 8 9 10

首部字段名                   說明 Cache-Control               控制緩存的行爲 Connection                  逐跳首部、鏈接的管理 Date                        建立報文的日期時間 Pragma                      報文指令 Trailer                     報文末端的首部一覽 Transfer-Encoding           指定報文主體的傳輸編碼方式 Upgrade                     升級爲其餘協議 Via                         代理服務器的相關信息 Warning                     錯誤通知

請求首部字段

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

首部字段名                  說明 Accept                     用戶代理可處理的媒體類型 Accept-Charset             優先的字符集 Accept-Encoding            優先的內容編碼 Accept-Language            優先的語言（天然語言） Authorization              Web認證信息 Expect                     期待服務器的特定行爲 From                       用戶的電子郵箱地址 Host                       請求資源所在服務器 if -Match                   比較實體標記（ETag） if -Modified-Since          比較資源的更新時間 if -None-Match              比較實體標記（與 if -Match相反） if -Range                   資源未更新時發送實體Byte的範圍請求 if -Unmodified-Since        比較資源的更新時間（與 if -Modified-Since相反） Max-Forwards               最大傳輸逐跳數 Proxy-Authorization        代理服務器要求客戶端的認證信息 Range                      實體的字節範圍請求 Referer                    對請求中URI的原始獲取方法 TE                         傳輸編碼的優先級 User-Agent                 HTTP客戶端程序的信息

響應首部字段

1 2 3 4 5 6 7 8 9 10

首部字段名                  說明 Accept-Ranges              是否接受字節範圍請求 Age                        推算資源建立通過時間 ETag                       資源的匹配信息 Location                   令客戶端重定向至指定的URI Proxy-Authenticate         代理服務器對客戶端的認證信息 Reter-After                對再次發起請求的時機要求 Server                     HTTP服務器的安裝信息 Vary                       代理服務器緩存的管理信息 WWW-Authenticate           服務器對客戶端的認證信息

實體首部字段

+ View Code

此外，還有一些如Cookie、Set-Cookie和Content-Disposition等在其餘RFC中定義的首部字段也常常會被用到。

傳輸編碼

HTTP傳輸數據的時候能夠傳輸原數據，也能夠在傳輸過程當中編碼以提高傳輸速率。經過傳輸時的編碼處理，能有效的處理大量的訪問請求。經常使用的內容編碼有如下幾種

· gzip(GUN zip)
· compress(UNIX系統的標準壓縮)
· deflate(zlib)
· identity(不進行編碼)

多部分對象集合

HTTP協議中採納了多部分對象集合，容許發送的報文主體內可含有多類型實體。多用於上傳文件或者圖片時使用，能夠設置Content-Type屬性對其進行規定。如如下幾種常見的形式：

Text：用於標準化地表示的文本信息，文本消息能夠是多種字符集和或者多種格式的

Multipart：用於鏈接消息體的多個部分構成一個消息，這些部分能夠是不一樣類型的數據

Application：用於傳輸應用程序數據或者二進制數據

範圍請求

實現這項功能須要指定下載的實體範圍，如：一份1000字節大小的文件，想取300-3000字節範圍內的資源，能夠設置Range:bytes=300-3000;想取300-3000字節和5000字節到最後的資源，能夠設置Range:bytes=300-3000,5000-

內容協商

內容協商機制是指客戶端和服務端就響應資源內容進行交涉，而後提供給客戶最爲適合的資源，內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的基準。涉及到如下首部字段：

· Accept

· Accept-Charset

· Accept-Encoding

· Accept-Language

· Content-Language

內容協商技術又分爲三種類型

服務器驅動協商：服務端以請求的首部字段做爲參考，在服務端處理而且返回對應資源。

客戶端驅動協商：用戶經過瀏覽器提供的可選列表進行手動選擇，或者利用js腳本在web頁面上自行選擇。

透明協商：服務器驅動協商和代理驅動協商的結合體，當一個緩存被提供了構成響應的一系列可得的表現形式，而且維度的差別能徹底被緩存理解，那麼此緩存變得有能力表明源服務器爲那個資源的後續請求去執行服務器驅動協商

內容協商可參考：內容協商

HTTP方法及狀態碼

HTTP方法

HTTP中也包含了一些方法，用於指定請求的資源定期望產生某種行爲。對於這些方法，其中用的最多的是get和post，你們也必定很熟悉了~

HTTP/1.1和HTTP/1.0支持的方法

+ View Code

HTTP狀態碼

HTTP狀態碼錶示客戶端HTTP請求的返回結果，經過狀態碼，用戶能夠知道HTTP請求是否出現問題，問題出在哪，下面簡單羅列一些HTTP狀態碼：

1 2 3 4 5 6

狀態碼類別       狀態碼性質 1XX             信息性狀態碼 2XX             成功狀態碼 3XX             重定向狀態碼 4XX             客戶端錯誤狀態碼 5XX             服務器錯誤狀態碼

一些常見的狀態碼：

1 2 3 4 5 6 7 8 9 10 11 12

200  ok                      正常處理請求 204  no content              服務端接收請求併成功處理，但返回的響應報文不含實體的主體部分 206  partial content         客戶端進行範圍請求，服務端成功執行這部分範圍的get請求 301  moved permanently       永久性重定向 302  found                   臨時性重定向 303  see other               表示因爲請求對於的資源存在另外一個URI，應使用GET方法定向獲取請求的資源 304  not modified            客戶端發送附帶條件的請求，服務端容許訪問資源，但爲知足條件 401  unauthorized            表示發送的請求須要有經過HTTP認證的認證信息 403  forbidden               請求資源的訪問被服務端拒絕 404  not found               服務端沒法找到請求的資源 500  internal server error   服務端執行請求時發生錯誤 503  service unavailable     服務端處於沒法處理請求狀態

HTTP代理及緩存

代理

代理指的是具備轉發功能的應用程序，接收客戶端的請求轉發給服務端，也接收服務端的響應轉發給客戶端。代理不會改變請求的URI，會直接發送給持有資源的服務器。

在HTTP通訊過程當中能夠級聯多臺代理服務器，而且轉發時須要附加Via首部字段以標記通過的主機信息。

緩存

緩存是代理服務器或客戶端本地磁盤內保存的資源副本，利用緩存來減小對源服務器的訪問以便於節省通訊流量和通訊時間，也能夠達到更好的交互體驗。

請求的資源若是已經被緩存則直接由緩存服務器返回給客戶端，或者客戶端直接從本地磁盤讀取。緩存能夠設置有效時間，當判斷緩存過時後，客戶端/緩存服務器可像源服務器從新請求新資源。

HTTP安全升級--HTTPS

講了一些HTTP的優勢後，來看看HTTP的缺點

· 通訊使用明文(未經加密)，內容可能被竊聽

· 不驗證通訊方的身份，請求/響應會遭假裝

· 沒法證實報文的完整性，存在被篡改的可能

互聯網的任何角落都存在通訊內容被竊聽的風險

按照TCP/IP協議的工做機制，通訊內容在全部的通訊線路上都有可能遭受窺視。即便是加密處理過的通訊，也會被窺視到通訊內容，只是通過了加密，就有可能讓人沒法破解出正確完整的報文信息含義，加密後的報文信息自己內容仍是會被看到。

通常來講，竊聽通訊是經過收集在互聯網上流動的數據包來作解析，這些能夠經過抓包和嗅探工具實現，這也使得一些使用公共wifi帳號被盜的事情時有發生。

針對明文傳輸這點，也能夠對報文主體(傳輸內容)進行加密處理

針對身份驗證這點，可經過在本地安裝證書，存儲身份認證信息等

針對確保信息完整性，MD5/SHA-1的散列值校驗，數字簽名等

HTTP => HTTPS

HTTP不帶加密機制，但能夠經過和SSL(安全 套接層...標註下閱讀時的停頓)或TLS(安全層傳輸協議)的組合使用，用SSL創建安全通訊線路後，就能夠在這條線路上歡快的進行HTTP通訊了。因爲結合了SSL，HTTP升級成爲HTTPS(或者 HTTP over SSL)，然而這還不能說是個完整的HTTPS。

完整的HTTPS = HTTP + 加密 + 認證 + 完整性保護

一次完整的HTTPS請求

1.客戶端發送Client Hello報文開始SSL通訊，報文中包含客戶端支持的SSL的指定版本、加密組件列表等

2.服務端可進行SSL通訊時，會以Serve rHello報文做爲應答

3.服務端發送Certificate報文，報文包含公開密鑰證書

4.服務端發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束

5.SSL第一次握手結束後，客戶端以Client Key Exchange報文做爲迴應，其中包含通訊加密中使用的隨機密碼串

6.客戶端發送Change Cipher Spec報文，提示服務端此報文以後的通訊採用符合上一步的隨機密碼串的密鑰加密

7.客戶端發送Finished報文，其中包含鏈接至今所有報文的總體校驗值

8.服務端發送Change Cipher Spec報文

9.服務端發送Finished報文

10.Finished報文交換完畢後，SSL鏈接創建完成

11.應用層協議通訊，HTTP

12.客戶端斷開鏈接，發送close notify

WebSocket 和 http/2.0

WebSocket

WebSocket實現了再Web客戶端和服務端之間的全雙工通訊，一旦Web服務端與客戶端之間創建WebSocket協議的通訊鏈接，以後的全部通訊都依賴這個專用協議進行。

WebSocket具備推送功能，服務端可直接向客戶端推送數據，沒必要等待客戶端的請求；因爲WebSocket一直保持鏈接狀態，而且首部信息小，使得通訊量也相應的減小。

爲了實現WebSocket通訊。須要用到前面說到的HTTP首部字段Upgrade，達到告知服務端通訊協議發生改變，當成功握手確立WebSocket鏈接以後，通訊時再也不使用HTTP的數據幀，而採用WebSocket獨立的數據幀。

HTTP/2.0

核心優點/特性

多路複用：多個請求都是經過一個 TCP 鏈接併發完成(HTTP/1.1管線化在多個請求之間的響應會被阻塞，HTTP/2.0解決了這問題，而且支持優先級和流量控制)

頭部壓縮：報文頭部壓縮處理，數通訊量更小

服務端推送：服務端可以更快的把資源推送給客戶端

語義改進：採用二進制格式傳輸數據

http/2.0參考資料：英文版  中英對照版

Web的攻擊技術

以服務器爲目標的主動攻擊，表明性的有SQL注入和OS命令注入,SQL注入是指攻擊者經過直接訪問Web應用，把攻擊的SQL代碼傳入服務端以執行數據庫來獲取所需的數據信息或篡改數據庫信息(調用SQL語句的方式所產生的漏洞)；OS命令攻擊指的是在服務端執行非法的操做系統命令達到攻擊的目的。

以服務器爲目標的被動攻擊，其模式以下:

1.攻擊者誘導用戶觸發已經設置好的陷阱，啓動發送已嵌入攻擊代碼的HTTP請求

2.含有攻擊代碼的HTTP發送到服務端並容許

3.運行完攻擊代碼後，存在安全漏洞的Web應用便會成爲攻擊者的跳板，致使我的信息被竊取(網絡安全課的知識全還給老師了...起初看到這些，一臉懵逼...)

以客戶端爲目標的主動攻擊，表明性的跨站腳步攻擊(XSS)，經過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標籤或者JavaScript代碼進行的一種攻擊方式，該攻擊可獲取用戶我的信息等

還有HTTP首部注入攻擊、郵件首部注入攻擊、目錄遍歷攻擊、遠程文件所包含的漏洞等

設置或設計致使的安全漏洞

強制瀏覽，從安置在Web服務端的公開目錄下的文件中瀏覽那些本來非自願公開的文件，致使我的信息/內部文件信息的泄露

拋出錯誤信息致使的漏洞，暴露出系統的出錯點，給攻擊者提供了攻擊的突破點

開放重定向，對任意URL做重定向跳轉的功能，攻擊者可誘導用戶到具備惡意的Web站點

會話管理疏忽致使的安全漏洞

會話劫持，攻擊者經過一些手段拿到用戶會話ID，並使用此會話ID假裝成用戶達到攻擊的目的

攻擊者可能得到會話ID的一些方式：

· 經過非正規的生成方法推測出會話ID

· 經過竊聽或XSS攻擊盜取會話ID

· 經過會話固定攻擊強行獲取會話ID

會話固定攻擊，大體模式爲：攻擊者訪問站點拿到未認證的會話ID，設置陷阱強制用戶使用這個會話ID前去認證，一旦用戶觸發陷阱並完成認證，攻擊者就可以使用用戶的身份順利登錄網站

跨站點請求僞造，攻擊者經過設置的陷阱強制對已完成認證的用戶進行非預期的信息某些狀態的更新

其餘安全漏洞

密碼破解，獲取密碼，突破認證(經過網絡密碼試錯或者對已加密的密碼進行破解)，密碼破解如字典攻擊、彩虹表、獲取密鑰、加密算法漏洞等

點擊劫持，又稱界面假裝，大多以透明層元素做爲陷阱以達到攻擊目的

Dos攻擊，讓服務端的服務呈中止狀態(利用訪問請求形成資源過載，資源用盡以中止服務；經過攻擊安全漏洞中止服務)

後門程序，開發者debug的程序，開發者爲自身利益植入的程序等