這本 HTTP 方面的小冊子還蠻不錯,已經二刷了 😜javascript
此次作了一些筆記,方便本身和其餘人翻閱和複習,由於這本書是 2014 年出的第一版,因此有一些不怎麼經常使用的技術,筆記中就省略了,只記一些比較經常使用的 ~php
若是但願獲取本書的 PDF 資源,能夠關注文末二維碼加微信羣找羣主要~html
一般使用的網絡(包括互聯網)是在 TCP/IP 協議族的基礎上運做,而 HTTP 屬於它內部的一個子集。前端
按層次分爲如下 4 層:應用層、傳輸層、網絡層和數據鏈路層。java
利用 TCP/IP 協議族進行網絡通訊時,會經過分層順序與對方進行通訊。發送端從應用層往下走,接收端則往應用層往上走。web
以 HTTP 爲例,一次通訊的過程算法
發送端在層與層之間傳輸數據時,每通過一層時一定會被打上一個該層所屬的首部信息。反之,接收端在層與層傳輸數據時,每通過一層時會把對應的首部消去。sql
這種把數據信息包裝起來的作法稱爲封裝(encapsulate)。數據庫
爲了準確無誤地將數據送達目標處,TCP 協議採用了三次握手(three-way handshaking)策略。握手過程當中使用了 TCP 的標誌(flag) —— SYN(synchronize) 和 ACK(acknowledgement)。瀏覽器
發送端首先發送一個帶 SYN 標誌的數據包給對方。接收端收到後,回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。最後,發送端再回傳一個帶 ACK 標誌的數據包,表明「握手」結束。
發送端首先發送一個帶 SYN 標誌的數據包給對方。接收端收到後,回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。最後,發送端再回傳一個帶 ACK 標誌的數據包,表明「握手」結束。
DNS(Domain Name System)服務是和 HTTP 協議同樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。
經過這張圖來了解下 IP 協議、TCP 協議和 DNS 服務在使用 HTTP 協議的通訊過程當中各自發揮了哪些做用。
瞭解一下 URI 的各部分
http:
或 https:
等協議方案名獲取訪問資源時要指定協議類型。不區分字母大小寫,最後附一個冒號。也可以使用 data:
或 javascript:
這類指定數據或腳本程序的方案名。hackr.jp
這種 DNS 可解析的名稱,或是 192.168.1.1
這類 IPv4 地址名,還能夠是 [0:0:0:0:0:0:0:1]
這樣用方括號括起來的 IPv6 地址名。HTTP 是一種不保存狀態,即無狀態(stateless)協議。HTTP 協議自身不對請求和響應之間的通訊狀態進行保存。這是爲了更快地處理大量事務,確保協議的可伸縮性,而特地把 HTTP 協議設計成如此簡單的。
HTTP1.1 雖然是無狀態協議,但爲了實現指望的保持狀態功能,因而引入了 Cookie 技術。
方法 | 說明 | 支持的 HTTP 協議版本 |
---|---|---|
GET | 獲取資源 | 1.0、1.1 |
POST | 傳輸實體主體 | 1.0、1.1 |
PUT | 傳輸文件 | 1.0、1.1 |
HEAD | 得到報文首部 | 1.0、1.1 |
DELETE | 刪除文件 | 1.0、1.1 |
OPTIONS | 詢問支持的方法 | 1.1 |
TRACE | 追蹤路徑 | 1.1 |
CONNECT | 要求用隧道協議鏈接代理 | 1.1 |
LINK | 創建和資源之間的聯繫 | 1.0 |
UNLINE | 斷開鏈接關係 | 1.0 |
LINK 和 UNLINK 已被 HTTP1.1 廢棄,再也不支持。
HTTP 協議的初始版本中,每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接。
好比,使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時,在發送請求訪問 HTML 頁面資源的同時,也會請求該 HTML 頁面裏包含的其餘資源。所以,每次的請求都會形成無謂的 TCP 鏈接創建和斷開,增長通訊量的開銷。
HTTP1.1 和一部分的 HTTP1.0 想出了持久鏈接(keep-alive)的方法。持久鏈接的特色是,只要任意一端沒有明確提出斷開鏈接,則保持 TCP 鏈接狀態。
持久鏈接的好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷,減輕了服務器端的負載。另外,減小開銷的那部分時間,使 HTTP 請求和響應可以更早地結束,這樣 Web 頁面的顯示速度也就相應提升了。
在 HTTP1.1 中,全部的鏈接默認都是持久鏈接,但在 HTTP1.0 內並未標準化。
持久鏈接使得多數請求以管線化(pipelining)方式發送成爲可能。從前發送請求後需等待並收到響應,才能發送下一個請求。管線化技術出現後,不用等待響應亦可直接發送下一個請求。
這樣就可以作到同時並行發送多個請求,而不須要一個接一個地等待響應了。
用持久鏈接可讓請求更快結束。而管線化技術則比持久鏈接還要快。請求數越多,時間差就越明顯。
HTTP 是無狀態協議,它不對以前發生過的請求和響應的狀態進行管理。也就是說,沒法根據以前的狀態進行本次的請求處理。
假設要求登陸認證的 Web 頁面自己沒法進行狀態的管理(不記錄已登陸的狀態),那麼每次跳轉新頁面不是要再次登陸,就是要在每次請求報文中附加參數來管理登陸狀態。
Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie
的首部字段信息,通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時,客戶端會自動在請求報文中加入 Cookie 值後發送出去。
HTTP 能夠在傳輸過程當中經過編碼提高傳輸速率。
內容編碼指明應用在實體內容上的編碼格式,並保持實體信息原樣壓縮。
經常使用的內容編碼有:gzip(GNU zip)、compress(UNIX 系統的標準壓縮)deflate(zlib)、identity(不進行編碼)
在 HTTP 通訊過程當中,請求的編碼實體資源還沒有所有傳輸完成以前,瀏覽器沒法顯示請求頁面。在傳輸大容量數據時,經過把數據分割成多塊,可以讓瀏覽器逐步顯示頁面。這種把實體主體分塊的功能稱爲分塊傳輸編碼(Chunked Transfer Coding)。
分塊傳輸編碼會將實體主體分紅多個部分(塊)。每一塊都會用十六進制來標記塊的大小,而實體主體的最後一塊會使用「0(CR+LF)」來標記。
使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼,恢復到編碼前的實體主體。
在 HTTP 報文中使用多部分對象集合時,須要在首部字段里加上 Content-type
:
若是下載過程當中遇到網絡中斷的狀況,那就必須重頭開始。爲了解決上述問題,須要一種可恢復的機制。所謂恢復是指能從以前下載中斷處恢復下載。
要實現該功能須要指定下載的實體範圍,指定範圍發送的請求叫作範圍請求(Range Request)。針對範圍請求,響應會返回狀態碼 206。
好比:
Range: bytes=5001-10000
Range: bytes=5001-
Range: bytes=-3000, 5000-7000
內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉,而後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的基準。
包含在請求報文中的某些首部字段(以下)就是判斷的基準:Accept
、Accept-Charset
、Accept-Encoding
、Accept-Language
、Content-Language
有如下幾種類型:
狀態碼的職責是當客戶端向服務器端發送請求時,描述返回的請求結果。藉助狀態碼,用戶能夠知道服務器端是正常處理了請求,仍是出現了錯誤。
數字中的第一位指定了響應類別,後兩位無分類
類別 | 緣由短語 | |
---|---|---|
1XX | Informational(信息性狀態碼) | 接收的請求正在處理 |
2XX | Success(成功狀態碼) | 請求正常處理完畢 |
3XX | Redirection(重定向狀態碼) | 須要進行附加操做以完成請求 |
4XX | Client Error(客戶端錯誤狀態碼) | 服務器沒法處理請求 |
5XX | Server Error(服務器錯誤狀態碼) | 服務器處理請求出錯 |
請求被正常處理了。
瀏覽器須要執行某些特殊的處理以正確處理請求。
If-Match
、If-Modified-Since
、If-None-Match
、If-Range
、If-Unmodified-Since
中任一首部時,服務器端容許請求訪問資源,但未知足條件的狀況。304 狀態碼返回時,不包含任何響應的主體部分。304 雖然被劃分在 3XX 類別中,可是和重定向沒有關係。客戶端發生了錯誤。
WWW-Authenticate
首部用以質詢用戶信息。當瀏覽器初次接收到 401 響應,會彈出認證用的對話窗口。服務器自己發生錯誤。
RetryAfter
首部字段再返回給客戶端。一臺 Web 服務器可搭建多個獨立域名的 Web 網站,也可做爲通訊路徑上的中轉服務器提高傳輸效率。
HTTP1.1 規範容許一個服務器搭建多個 Web 站點,這是虛擬主機(Virtual Host,又稱虛擬服務器)功能。
若是一臺服務器內託管了兩個域名,對應的同一個服務器 IP,當收到請求時就須要弄清楚究竟要訪問哪一個域名,因爲虛擬主機能夠寄存多個不一樣主機名和域名的 Web 網站,所以在發送 HTTP 請求時,必須在 Host
首部內完整指定主機名或域名的 URI。
這些應用程序和服務器能夠將請求轉發給通訊線路上的下一站服務器,而且能接收從那臺服務器發送的響應再轉發給客戶端。
緩存是指代理服務器或客戶端本地保存的資源副本,是代理服務器的一種。
優點在於避免屢次從源服務器轉發資源,客戶端可就近從緩存服務器上獲取資源,而源服務器也沒必要屢次處理相同請求。
客戶端的緩存: 瀏覽器緩存若是有效,沒必要再向服務器請求,而直接從本地讀取。當斷定緩存過時後,會向源服務器確認資源的有效性。若判斷瀏覽器緩存失效,瀏覽器會再次請求新資源。
HTTP 協議的請求和響應報文中一定包含 HTTP 首部,請求報文大約是下面的結構,響應報文相似
HTTP 首部字段將定義成緩存代理和非緩存代理的行爲,分紅 2 種類型。
下面列舉了 HTTP1.1 中的逐跳首部字段。除這 8 個首部字段以外,其餘全部字段都屬於端到端首部。
HTTP 首部根據用途被分爲 4 種 HTTP 首部字段類型,在 HTTP 協議通訊交互中使用到的首部字段,不限於 RFC2616 中定義的 47 種。還有 Cookie、Set-Cookie 和 Content-Disposition 等在其餘 RFC 中定義的,使用頻率也很高。
請求報文和響應報文兩方都會使用的首部。
首部字段名 | 說明 |
---|---|
Cache-Control | 控制緩存的行爲 |
Connection | 逐跳首部、鏈接的管理 |
Date | 建立報文的日期時間 |
Pragma | 報文指令 |
Trailer | 報文末端的首部一覽 |
Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
Upgrade | 升級爲其餘協議 |
Via | 代理服務器的相關信息 |
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 | 代理服務器要求客戶端的認證信息 |
Range | 實體的字節範圍請求 |
Referer | 對請求中 URI 的原始獲取方 |
TE | 傳輸編碼的優先級 |
User-Agent | HTTP 客戶端程序的信息 |
從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容,也會要求客戶端附加額外的內容信息。
首部字段名 | 說明 |
---|---|
Accept-Ranges | 是否接受字節範圍請求 |
Age | 推算資源建立通過時間 |
ETag | 資源的匹配信息 |
Location | 令客戶端重定向至指定URI |
Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
Retry-After | 對再次發起請求的時機要求 |
Server | HTTP服務器的安裝信息 |
Vary | 代理服務器緩存的管理信息 |
WWW-Authenticate | 服務器對客戶端的認證信息 |
針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。
首部字段名 | 說明 |
---|---|
Allow | 資源可支持的HTTP方法 |
Content-Encoding | 實體主體適用的編碼方式 |
Content-Language | 實體主體的天然語言 |
Content-Length | 實體主體的大小(單位:字節) |
Content-Location | 替代對應資源的URI |
Content-MD5 | 實體主體的報文摘要 |
Content-Range | 實體主體的位置範圍 |
Content-Type | 實體主體的媒體類型 |
Expires | 實體主體過時的日期時間 |
Last-Modified | 資源的最後修改日期時間 |
通用首部字段是指請求報文和響應報文都會使用的首部。
no-cache
,表示客戶端將不會接收緩存過的響應,緩存服務器必須把客戶端請求轉發給源服務器。服務器響應中包含 no-cache
,那麼緩存服務器不能對資源進行緩存,源服務器之後也將再也不對緩存服務器請求中提出的資源有效性進行確認,且禁止其對響應資源進行緩存操做。從字面意思上很容易把 no-cache
誤解成爲不緩存,但 no-cache
表明不緩存過時的資源,緩存會向源服務器進行有效期確認後處理資源,no-store 纔是真正地不進行緩存。
Connection
首部字段,可控制再也不轉發給代理的首部字段(即 Hop-by-hop 首部)。Connection
首部字段爲 Close
。HTTP1.1 以前默認都是非持久鏈接。爲此,若是想在舊版本 HTTP 協議上持續鏈接,則需設置 Connection
首部字段爲 Keep-Alive
。代表建立 HTTP 報文的日期和時間。
用於檢測 HTTP 協議及其餘協議是否可以使用更高的版本進行通訊,其參數值能夠用來指定一個徹底不一樣的通訊協議。
從客戶端往服務器端發送請求報文中所使用的字段,用於補充請求的附加信息、客戶端信息、對響應內容相關的優先級等內容。
通知服務器,用戶代理可以處理的媒體類型及媒體類型的相對優先級。可以使用 type/subtype
這種形式,一次指定多種媒體類型。
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
複製代碼
告知服務器,請求的資源所處的互聯網主機名和端口號。Host 首部字段在 HTTP1.1 規範內是惟一一個必須被包含在請求內的首部字段。
請求被髮送至服務器時,主機名會直接用 IP 地址。但若是這時,相同的 IP 地址下部署多個域名,那麼服務器就會沒法理解到底是哪一個域名對應的請求。所以,就須要使用首部字段 Host
來明確指出請求的主機名。若服務器未設定主機名,那直接設空值便可。
形如 If-xxx 這種,均可稱爲條件請求。服務器接收到後,只有判斷指定條件爲真時,纔會執行請求。
首部字段 If-Match,屬附帶條件之一,它會告知服務器匹配資源所用的實體標記(ETag)值。這時的服務器沒法使用弱 ETag 值。服務器會比對 If-Match 的字段值和資源的 ETag 值,僅當二者一致時,纔會執行請求。
能夠用星號 *
,服務器會忽略 ETag
的值,只要資源存在就處理請求。
和 If-Match
做用相反,用於指定 If-None-Match
的實體標記 ETag
值與請求資源的 ETag
不一致時,它就告知服務器處理該請求。
若是在 If-Modified-Since
字段指定的日期時間後資源發生了更新,服務器會接受請求。
指定 If-Modified-Since
字段值的日期時間以後,請求的資源在給定的日期時間以後對內容進行過修改的狀況下才會將資源返回,狀態碼爲 200
,若是請求的資源沒有更新,則返回狀態碼 304 Not Modified 的響應。
If-Unmodified-Since
和 If-Modified-Since
的做用相反。它的做用的是告知服務器,指定的請求資源只有在指定日期時間以後未發生更新,才處理請求。若是在指定日期時間後發生了更新,則以狀態碼 412 Precondition Failed 做爲響應返回。
If-Range
字段若是跟 ETag 值或更新的日期時間一致,那麼就做爲範圍請求處理。反之,則返回全體資源。
由服務器端向客戶端返回響應報文中所使用的字段,用於補充響應的附加信息、服務器信息,以及對客戶端的附加要求等信息。
實體標識,將資源以字符串形式作惟一性標識的方式。服務器會爲每份資源分配對應的 ETag
值。當資源更新時,ETag
值也須要更新。
若在下載過程當中出現鏈接中斷、再鏈接的狀況,都會依照 ETag
值來指定資源。
包含在請求報文和響應報文中的實體部分所使用的首部,用於補充內容的更新時間等與實體相關的信息。
通知客戶端可以支持的全部 HTTP 方法。當服務器接收到不支持的 HTTP 方法時,會以狀態碼 405 Method Not Allowed 做爲響應返回。與此同時,還會把全部能支持的 HTTP 方法寫入首部字段 Allow
後返回。
告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。
主要有:gzip、compress、deflate、identity
代表了實體主體部分的大小(單位是字節)。對實體主體進行內容編碼傳輸時,不能再使用 Content-Length
首部字段。
說明了實體主體內對象的媒體類型,用 type/subtype 形式賦值。
Content-Type: text/html; charset=UTF-8
複製代碼
Expires
會將資源失效的日期告知客戶端。緩存服務器在收到有 Expires
的響應後,會以緩存來應答請求,在 Expires
字段值指定的時間以前,響應的副本會一直被保存。當超過指定的時間後,緩存服務器在請求發送過來時,會轉向源服務器請求資源。
源服務器不但願緩存服務器對資源緩存時,最好在 Expires
字段內寫入與 Date
相同的時間值。
可是,當首部字段 Cache-Control
有指定 max-age
時,比起 Expires
,會優先處理 max-age
指令。
包含源頭服務器認定的資源作出修改的日期及時間。
首部字段名 | 說明 | 首部類型 |
---|---|---|
Set-Cookie | 開始狀態管理所使用的Cookie信息 | 響應首部字段 |
Cookie | 服務器接收到的Cookie信息 | 請求首部字段 |
Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;
複製代碼
屬性 | 說明 |
---|---|
NAME=VALUE | 賦予 Cookie 的名稱和其值(必需項) |
expires=DATE | Cookie 的有效期(若不明確指定則默認爲瀏覽器關閉前爲止) |
path=PATH | 將服務器上的文件目錄做爲Cookie的適用對象(若不指定則默認爲文檔所在的文件目錄) |
domain=域名 | 做爲 Cookie 適用對象的域名 (若不指定則默認爲建立 Cookie 的服務器的域名) |
Secure | 僅在 HTTPS 安全通訊時纔會發送 Cookie |
HttpOnly | 加以限制,使 Cookie 不能被 JavaScript 腳本訪問 |
一旦 Cookie 從服務器端發送至客戶端,服務器端就沒有顯式刪除 Cookie 的方法。但可經過覆蓋已過時的 Cookie,實現對客戶端 Cookie 的實質性刪除操做。
HttpOnly
屬性是 Cookie 的擴展功能,它使 JavaScript 腳本沒法得到 Cookie。其主要目的爲防止跨站腳本攻擊(Cross-site scripting,XSS)對 Cookie 的信息竊取。
Cookie: status=enable
複製代碼
當客戶端想得到 HTTP 狀態管理支持時,就會在請求中包含從服務器接收到的 Cookie。
是針對跨站腳本攻擊(XSS)的一種對策,用於控制瀏覽器 XSS 防禦機制的開關,可指定的字段值以下
HTTP 協議中有可能存在信息竊聽或身份假裝等安全問題,使用 HTTPS 能夠有效地防止這些問題。
把添加了加密及認證機制的 HTTP 稱爲 HTTPS(HTTP Secure)。HTTPS 並不是是應用層的一種新協議,只是 HTTP 通訊接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)協議代替而已。SSL 是獨立於 HTTP 的協議,因此其餘運行在應用層的 SMTP 和 Telnet 等協議都可配合 SSL 協議使用。
HTTPS 採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。若密鑰可以實現安全交換,那麼有可能會考慮僅使用公開密鑰加密來通訊。可是公開密鑰加密與共享密鑰加密相比,其處理速度要慢。
因此取長補短,在交換密鑰環節使用公開密鑰加密方式,以後的創建通訊交換報文階段則使用共享密鑰加密方式。
數字證書認證機構(CA,Certificate Authority)和其相關機關頒發的公開密鑰證書就是認證的能夠信賴的公開密鑰,服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端,以進行公開密鑰加密方式通訊。公鑰證書也可叫作數字證書或直接稱爲證書。
HTTPS 通訊的步驟:
在以上流程中,應用層發送數據時會附加一種叫作 MAC(Message Authentication Code)的報文摘要。MAC 可以查知報文是否遭到篡改,從而保護報文的完整性。
HTTPS 也存在一些問題,那就是當使用 SSL 時,它的處理速度會變慢。它慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗 CPU 及內存等資源,致使處理速度變慢。
和 HTTP 相比,HTTPS 網絡負載可能會變慢 2 到 100 倍。除去和 TCP 鏈接、發送 HTTP 請求響應之外,還必須進行 SSL 通訊,所以總體上處理通訊量不可避免會增長。另外 SSL 必須進行加密處理,在服務器和客戶端都須要進行加解密處理,比 HTTP 消耗更多硬件資源,致使負載加強。
針對速度變慢這一問題,並無根本性的解決方案,通常會使用 SSL 加速器這種(專用服務器)硬件。能提升數倍 SSL 的計算速度,僅在 SSL 處理時發揮功效,分擔負載。
與純文本通訊相比,加密通訊會消耗更多的 CPU 及內存資源。若是每次通訊都加密,會消耗至關多的資源,平攤到一臺計算機上時,可以處理的請求數量一定也會隨之減小。
若是是非敏感信息則使用 HTTP 通訊,只有在包含我的信息等敏感數據時,才利用 HTTPS 加密通訊。能夠僅在那些須要信息隱藏時才加密,以節約資源。
除此以外,想要節約購買證書的開銷也是緣由之一。
一些頁面只想讓特定的人瀏覽,這就引入了認證功能。
HTTP1.1 經常使用的認證方式:
鏈接的發起方還是客戶端,一旦確立 WebSocket 通訊鏈接,服務器與客戶端任意一方均可向對方發送報文。
通訊的創建:
首先使用 HTTP 的 Upgrade 首部字段,告知服務器通訊協議發生改變,進行握手。
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
複製代碼
Sec-WebSocket-Key
字段內記錄着握手過程當中必不可少的鍵值。Sec-WebSocket-Protocol
字段內記錄使用的子協議。
以前的請求將會被返回 101 Switching Protocols 響應
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
複製代碼
Sec-WebSocket-Accept
的字段值是由握手請求中的 Sec-WebSocket-Key
的字段值生成的。
成功握手創建 WebSocket 鏈接以後,通訊時再也不使用 HTTP 的數據幀,而採用 WebSocket 獨立的數據幀。
HTTP/2.0 的目標是改善用戶在使用 Web 時的速度體驗。特色:
HTML(HyperText Markup Language,超文本標記語言)是爲了發送 Web 上的超文本(Hypertext)而開發的標記語言。
超文本是一種文檔系統,可將文檔中任意位置的信息與其餘信息(文本或圖片等)創建關聯,即超連接文本。
Web 應用是指經過 Web 功能提供的應用程序。
CGI 每次接到請求,都要跟着啓動一次,一旦訪問量過大,Web 服務器要承擔至關大的負載。而 Servlet 運行在與 Web 服務器相同的進程中,所以受到的負載較小。
Servlet 的運行環境叫作 Web 容器或 Servlet 容器。隨着 CGI 的普及,每次請求都要啓動新 CGI 程序的 CGI 運行機制逐漸變成了性能瓶頸。而 Servlet 常駐內存,在每次請求時,可啓動相對進程級別更爲輕量的 Servlet,程序的執行效率從而變得更高。
HTTP 協議自己並不存在安全性問題,服務器和客戶端以及運行在服務器上的 Web 應用等資源纔是攻擊目標。
HTTP 就是一個通用的單純協議機制,開發者須要自行設計並開發認證及會話管理功能來知足 Web 應用的安全,所以在運行的應用會隱藏着各類容易被攻擊者濫用的安全漏洞。
從瀏覽器那接收到的 HTTP 請求的所有內容,均可以在客戶端自由地變動、篡改。因此 Web 應用接受到的內容可能與預期數據不一樣。
在 HTTP 請求報文內加載攻擊代碼,就能發起對 Web 應用的攻擊。經過 URL 查詢字段或表單、HTTP 首部、Cookie 等途徑把攻擊代碼傳入,若這時 Web 應用存在安全漏洞,那內部信息就會遭到竊取,或被攻擊者拿到管理權限。
對 Web 攻擊的模式有主動攻擊和被動攻擊兩種
指攻擊者經過直接訪問 Web 應用,把攻擊代碼傳入的攻擊模式。因爲該模式是直接針對服務器上的資源進行攻擊,所以攻擊者須要可以訪問到那些資源。
表明性的是 SQL 注入攻擊和 OS 命令注入攻擊。
指利用圈套策略執行攻擊代碼的攻擊模式。在被動攻擊過程當中,攻擊者不直接對目標 Web 應用訪問發起攻擊。
表明性的是跨站腳本攻擊和跨站點請求僞造。
一般的攻擊步驟
驗證主要有兩種:
通常驗證數據是在客戶端使用 JS,然而客戶端的腳本是能夠篡改的,因此不適合做爲安全對策。
從數據庫或文件系統、HTML、郵件等輸出需處理的數據的時候,針對輸出作值轉義處理是一項相當重要的安全策略。當輸出值轉義不徹底時,會觸發攻擊者傳入的攻擊代碼。
跨站腳本攻擊(Cross-Site Scripting,XSS)是指經過存在安全漏洞的客戶端運行非法的 HTML 標籤或 JavaScript 進行的一種攻擊。動態建立的 HTML 部分有可能隱藏着安全漏洞。
若是用戶填寫的表單是直接做爲 HTML 解析,那麼換成 script
標籤,就中招了。
SQL 注入(SQL Injection)是指針對 Web 應用使用的數據庫,經過運行非法的 SQL 而產生的攻擊。
若是在調用 SQL 語句的方式上存在疏漏,就可能被惡意注入(Injection)非法的 SQL 語句。
好比,若是把表單查詢的字段直接拼接給 SQL 語句,那麼可能會出現下面這個狀況
上面一句查詢的是 上野宣
,下面一句查詢 上野宣'--
SELECT * FROM bookTbl WHERE author = '上野宣' and flag = 1;
SELECT * FROM bookTbl WHERE author = '上野宣'--' and flag = 1;
複製代碼
SQL 語句中的 --
以後全視爲註釋,所以 and flag=1
這個條件被自動忽略了,失去過濾條件,不想顯示的內容也被顯示出來了。
OS 命令注入攻擊(OS Command Injection)是指經過 Web 應用,執行非法的操做系統命令達到攻擊的目的。只要在能調用 Shell 函數的地方就有存在被攻擊的風險。
HTTP 首部注入攻擊(HTTP Header Injection)是指攻擊者經過在響應首部字段內插入換行,添加任意響應首部或主體的一種攻擊。屬於被動攻擊模式。
向首部主體內添加內容的攻擊稱爲 HTTP 響應截斷攻擊(HTTP Response Splitting Attack)。
好比有時候 Web 應用有時會把從外部收到的值,賦給響應首部字段 Location
和 Set-Cookie
。若是攻擊者發送 101%0D%0ASet-Cookie:+SID=123456789
這裏的 %0D%0A
表明的是換行符,那麼就會致使結果返回:
Location: http://example.com/?cat=101(%0D%0A :換行符)
Set-Cookie: SID=123456789
複製代碼
這裏攻擊者就能夠修改任意的 Cookie
信息了。
這個例子中,本來應該屬於首部字段 Location
的查詢值部分,攻擊者輸入的 %0D%0A
成了換行符,結果插入了新的首部字段,實際上攻擊者能夠在響應中插入任意的首部字段。
HTTP 響應截斷攻擊是用在 HTTP 首部注入的一種攻擊。
攻擊順序相同,可是要將兩個 %0D%0A%0D%0A
並排插入字符串後發送。利用這兩個連續的換行就可做出 HTTP 首部與主體分隔所需的空行了,這樣就能顯示僞造的主體,達到攻擊目的。
Set-Cookie: UID=(%0D%0A :換行符)
(%0D%0A :換行符)
<HTML><HEAD><TITLE>以後,想要顯示的網頁內容 <!-- (原來頁面對應的首部字段和主體部分全視爲註釋)
複製代碼
利用這個攻擊,已觸發陷阱的用戶瀏覽器會顯示僞造的 Web 頁面,再讓用戶輸入本身的我的信息等,可達到和跨站腳本攻擊相同的效果。
郵件首部注入(Mail Header Injection)是指 Web 應用中的郵件發送功能,攻擊者經過向郵件首部 To 或 Subject 內任意添加非法內容發起的攻擊。利用存在安全漏洞的 Web 網站,可對任意郵件地址發送廣告郵件或病毒郵件。
目錄遍歷(Directory Traversal)攻擊是指對本無心公開的文件目錄,經過非法截斷其目錄路徑後,達成訪問目的的一種攻擊。這種攻擊有時也稱爲路徑遍歷(Path Traversal)攻擊。
經過 Web 應用對文件處理操做時,在由外部指定文件名的處理存在疏漏的狀況下,用戶可以使用 .../ 等相對路徑定位到 /etc/passed 等絕對路徑上,所以服務器上任意的文件或文件目錄皆有可能被訪問到。這樣一來,就有可能非法瀏覽、篡改或刪除 Web 服務器上的文件。
http://example.com/read.php?log=0401.log
http://example.com/read.php?log=../../etc/passwd
複製代碼
遠程文件包含漏洞(Remote File Inclusion)是指當部分腳本內容須要從其餘文件讀入時,攻擊者利用指定外部服務器的 URL 充當依賴文件,讓腳本讀取以後,就可運行任意腳本的一種攻擊。
對那些本來不肯公開的文件,爲了保證安全會隱蔽其 URL。可一旦知道了那些 URL,也就意味着可瀏覽 URL 對應的文件。好比
http://www.example.com/entry/entry_081202.log
複製代碼
這樣一個路徑,就很容易推測出下一個文件是 entry_081203.log,從而被訪問。
不正確的錯誤消息處理(Error Handling Vulnerability)的安全漏洞是指,Web 應用的錯誤信息內包含對攻擊者有用的信息。與 Web 應用有關的主要錯誤信息以下所示:
開放重定向(Open Redirect)是一種對指定的任意 URL 做重定向跳轉的功能。而於此功能相關聯的安全漏洞是指,假如指定的重定向 URL 到某個具備惡意的 Web 網站,那麼用戶就會被誘導至那個 Web 網站。好比:
http://example.com/?redirect=http://www.tricorder.jp
http://example.com/?redirect=http://hackr.jp
複製代碼
可信度高的 Web 網站若是開放重定向功能,則會被攻擊者用來做爲釣魚攻擊的跳板。
會話劫持(Session Hijack)是指攻擊者經過某種手段拿到了用戶的會話 ID,並不是法使用此會話 ID 假裝成用戶,達到攻擊的目的。
攻擊者在得知該 Web 網站存在可跨站攻擊 XSS 的安全漏洞後,就設置好用 JavaScript 腳本調用 document.cookie
以竊取 Cookie 信息的陷阱,獲取含有會話 ID 的 Cookie。
拿到用戶的會話 ID 後,往本身的瀏覽器的 Cookie 中設置該會話 ID,便可假裝成會話 ID 遭竊的用戶,訪問 Web 網站。
對以竊取目標會話 ID 爲主動攻擊手段的會話劫持而言,會話固定攻擊(Session Fixation)攻擊會強制用戶使用攻擊者指定的會話 ID,屬於被動攻擊。
攻擊者設置好強制用戶使用該會話 ID 的陷阱,並等待用戶拿着這個會話 ID 前去認證。一旦用戶觸發陷阱並完成認證,會話在服務器上的狀態(用戶 A 已認證)就會被記錄下來,再利用以前這個會話 ID 訪問網站。
跨站點請求僞造(Cross-Site Request Forgeries,CSRF)攻擊是指攻擊者經過設置好的陷阱,強制對已完成認證的用戶進行非預期的我的信息或設定信息等某些狀態更新,屬於被動攻擊。
好比這個留言板功能,只容許已認證並登陸的用戶發表內容。用戶的 Cookie 持有已認證的會話 ID。用戶若是點擊了攻擊者留下的惡意代碼連接,則會利用用戶的信息執行操做。
密碼破解攻擊(Password Cracking)即算出密碼,突破認證。
經過網絡進行密碼試錯主要有下面兩種方式:
字典攻擊中有一種利用其餘 Web 網站已泄露的 ID 及密碼列表進行的攻擊,由於不少用戶習慣隨意地在多個 Web 網站使用同一套 ID 及密碼。
對已加密密碼的破解一般有下面幾種方法:
點擊劫持(Clickjacking)是指利用透明的按鈕或連接作成陷阱,覆蓋在 Web 頁面之上。而後誘使用戶在不知情的狀況下,點擊那個連接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝(UI Redressing)。
已設置陷阱的 Web 頁面,表面上內容並沒有不妥,但早已埋入想讓用戶點擊的連接。當用戶點擊到透明的按鈕時,其實是點擊了已指定透明屬性元素的 iframe 頁面。
DoS 攻擊(Denial of Service attack)是一種讓運行中的服務呈中止狀態的攻擊。有時也叫作服務中止攻擊或拒絕服務攻擊。DoS 攻擊的對象不只限於 Web 網站,還包括網絡設備及服務器等。
後門程序(Backdoor)是指開發設置的隱藏入口,可不按正常步驟使用受限功能。利用後門程序就可以使用本來受限制的功能。
可經過監視進程和通訊的狀態發現被植入的後門程序。但設定在 Web 應用中的後門程序,因爲和正常使用時區別不大,一般很難發現。
PS:歡迎你們關注個人公衆號【前端下午茶】,一塊兒加油吧~
另外能夠加入「前端下午茶交流羣」微信羣,長按識別下面二維碼便可加我好友,備註加羣,我拉你入羣~