《HTTP圖解》閱讀筆記

來源:互聯網
上載者:User

標籤:

 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首部欄位列表

通用首部欄位

首部欄位名                說明Cache-Control            控制緩衝的行為Connection                逐跳首部、串連的管理Date                    建立報文的日期時間Pragma                    報文指令Trailer                    報文末端的首部一覽Transfer-Encoding        指定報文主體的傳輸編碼方式Upgrade                    升級為其他協議Via                        Proxy 伺服器的相關資訊Warning                    錯誤通知

請求首部欄位

首部欄位名               說明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       Proxy 伺服器要求用戶端的認證資訊Range                   實體的位元組範圍請求Referer                   對請求中URI的原始擷取方法TE                       傳輸編碼的優先順序User-Agent               HTTP用戶端程式的資訊

響應首部欄位

首部欄位名               說明Accept-Ranges           是否接受位元組範圍請求Age                       推算資源建立經過時間ETag                   資源的匹配資訊Location               令用戶端重新導向至指定的URIProxy-Authenticate       Proxy 伺服器對用戶端的認證資訊Reter-After               對再次發起請求的時機要求Server                   HTTP伺服器的安裝資訊Vary                   Proxy 伺服器緩衝的管理資訊WWW-Authenticate       伺服器對用戶端的認證資訊

實體首部欄位

首部欄位名               說明Allow                   資源可支援的HTTP方法Content-Encoding       實體主體的適用的編碼方式Content-Language       實體主體的自然語言Content-Length           實體主體的大小(單位:位元組)Content-Location       替代對應資源的URIContent-MD5               實體主體的報文摘要Content-Range           實體主體的位置範圍Content-Type           實體主體的媒體類型Expires                   實體主體到期的日期時間Last-Modified           資源的最後修改日期時間

此外,還有一些如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支援的方法

方法              說明                    HTTP版本(支援)GET              資源擷取                 1.0、1.1POST             資源實體主體              1.0、1.1PUT              傳輸檔案                 1.0、1.1   HEAD             獲得報文首部              1.0、1.1DELETE           刪除檔案                 1.0、1.1OPTIONS          詢問支援的方法            1.1TRANCE           追蹤路徑                 1.1CONNECT          要求用隧道協議串連代理     1.1 LINK             建立和資源之間的聯絡       1.0(廢棄)UNLINK           中斷連線關係              1.0(廢棄)

HTTP狀態代碼

HTTP狀態代碼表示用戶端HTTP請求的返回結果,通過狀態代碼,使用者可以知道HTTP請求是否出現問題,問題出在哪,下面簡單羅列一些HTTP狀態代碼:

狀態代碼類別       狀態代碼性質1XX             資訊性狀態代碼2XX             成功狀態代碼3XX             重新導向狀態代碼4XX             用戶端錯誤狀態代碼5XX             伺服器錯誤狀態代碼

一些常見的狀態代碼:

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通訊過程中可以級聯多台Proxy 伺服器,並且轉寄時需要附加Via首部欄位以標記經過的主機資訊。

緩衝

緩衝是Proxy 伺服器或用戶端本地磁碟內儲存的資源副本,利用緩衝來減少對原始伺服器的訪問以便於節省通訊流量和通訊時間,也可以達到更好的互動體驗。

請求的資源如果已經被緩衝則直接由快取服務器返回給用戶端,或者用戶端直接從本地磁碟讀取。緩衝可以設定有效時間,當判斷緩衝到期後,用戶端/快取服務器可像原始伺服器重新請求新資源。

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的程式,開發人員為自身利益植入的程式等

 

《HTTP圖解》閱讀筆記

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.