標籤:
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圖解》閱讀筆記