《圖解HTTP》讀書筆記

時間 2019-12-06

標籤圖解HTTP 讀書筆記欄目 HTTP/TCP 简体版

原文原文鏈接

《圖解HTTP》讀書筆記

標籤：HTTPhtml

第一章

HTTP（HyperText Transfer Protocol，超文轉移協議，超文本傳輸協議的譯法並不嚴謹。）git

網絡基礎 TCP/IP

TCP/IP 協議族

TCP/IP 協議族是互聯網相關聯的協議的集合。從電纜的規格到IP地址的選定方法、尋找異地用戶的方法、雙方創建通訊的順序，以及Web頁面顯示須要處理的步驟，等等。而HTTP是屬於它內部的一個子集。github

TCP/IP 的分層管理

TCP/IP 協議族按層次分別分爲如下 4 層：應用層、傳輸層、網絡層和數據鏈路層。
分層的好處：把各層之間的接口部分規劃好以後，每一個層次內部的設計就可以自由改動了。並且，層次化以後，設計也變得相對簡單。處於應用層上的應用能夠只考慮分派給本身的任務，而無需弄清對方在地球上哪一個地方、對方的傳輸路線、是否能確保傳輸送達等問題。web

應用層：決定了向用戶提供應用服務時通訊的活動。
TCP/IP 協議族預存了各種通用的應用服務。如 FTP（File Transfer Protocol）、DNS（Domain Name System）和 HTTP。算法
傳輸層：該層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。TCP（Transmission Control Protocol）和 UDP（User Data Protocol，用戶數據報協議）。數據庫
網絡層：網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎麼樣的路徑到達對方計算機，並把數據包傳送給對方。瀏覽器
鏈路層：用來處理網絡的硬件部分。緩存

TCP/IP 通訊傳輸流

利用 TCP/IP 協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則往應用層往上走。安全

用HTTP 舉例來講：首先做爲發送端的客戶端在應用層（HTTP協議）發出一個HTTP請求。
接着，在傳輸層（TCP協議）把從應用層處收到的數據（HTTP請求報文）進行分隔，並在各個報文上打上標記序號及端口號後轉發給網絡層。
在網絡層（IP協議），增長做爲通訊目的地的MAC地址後轉發給鏈路層。這就讓發往網絡的通訊請求準備齊全了。
接收端的服務器在鏈路層接收到數據後，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到客戶端發送過來的HTTP請求。服務器

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部消去。
把數據信息包裝起來的作法稱爲封裝。

與HTTP關係密切的協議：IP、TCP和DNS

負責傳輸的 IP 協議

IP（網際協議）位於網絡層。該協議的做用是把各類數據包傳送給對方。而要保證確實傳送到對方那裏，則須要知足各種條件。其中最重要的兩個條件是 IP 地址和 MAC地址。
IP 地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。IP地址能夠和MAC地址進行配對。

使用ARP協議憑藉MAC地址進行通訊
IP間通訊通訊依賴MAC地址。通訊的雙方一般會通過多臺計算機和網絡設備中轉才能鏈接到對方，而在進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時，會採用ARP協議。該協議是一種用以解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址。

確保可靠性的TCP協議

TCP屬於傳輸層，提供可靠的字節流服務。
字節流服務是指：爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理。
這就是爲何下載高清大圖時，圖片會一塊一塊地加載。

三次握手
爲了準確無誤地將數據送達目標處，TCP協議在發送數據的準備階段採用了三次握手策略（若在握手過程當中某個階段中斷，TCP協議會再次以相同的順序發送相同的數據包）。

固然，除了三次握手，TCP還有其它各類手段確保通訊的可靠性。

負責域名解析的 DNS 服務

DNS服務提供域名到IP 地址之間的解析服務。
便可經過域名查找IP，或逆向從IP地址反查域名服務。

由於域名解析也須要時間，因此能夠提早獲取DNS來提高網頁加載速度。

URI和URL

URI（uniform Resource Identifier）
Uniform：規定統一的格式可方便處理多種不一樣類型的資源。
Resource：可標識的任何東西
Identifier：標識符

URI就是某個協議方案表示的資源的定位標識符。協議方案是指訪問資源所使用的協議類型名稱，如http、ftp。

URI 用字符串標識某一個互聯網資源，而URL表示資源的地點。URL是URI的子集。

表示指定的URI，要使用涵蓋所有必要信息的絕對URI、絕對URL以及相對URL。相對URL是指從瀏覽器中基本URI處指定的URL，如 /image/logo.gif。

絕對URI的格式以下：

第二章簡單的HTTP協議

HTTP協議規定，先從客戶端開始創建通訊，服務端在沒有接收到請求以前不會發送響應。

請求報文由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。

響應報文基本上由協議版本、狀態碼、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。

HTTP是不保存狀態的協議

HTTP是無狀態協議。自身不對請求和響應之間通訊狀態進行保存（即不作持久化處理）。
HTTP之因此設計得如此簡單，是爲了更快地處理大量事物，確保協議的可伸縮性。
HTTP/1.1 隨時無狀態協議，但可經過 Cookie 技術保存狀態。

告知服務器意圖的HTTP方法

GET：獲取資源
POST：傳輸實體主體
PUT：傳輸文件
HEAD：得到報文首部，與GET方法同樣，只是不返回報文主體內容。用於確認URI的有效性及資源更新的日期時間等。
DELETE：刪除文件，與PUT相反（響應返回204 No Content）。
OPTIONS：詢問支持的方法，查詢針對請求URI指定的資源支持的方法（Allow:GET、POST、HEAD、OPTIONS）。
TRACE：追蹤路徑
CONNECT：要求用隧道協議鏈接代理（主要使用SSL（Secure Sockets Layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸）。

向請求URI指定的資源發送請求報文時，採用稱爲方法的命令。方法名區分大小寫，主要要用大寫字母。

持久鏈接節省通訊量

持久鏈接

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。

發送請求一份包含多張圖片的HTML文檔對應的Web頁面，會產生大量通訊開銷。

爲了解決上述TCP鏈接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久鏈接（HTTP Persistent Connections，也稱爲HTTP keep-alive 或 HTTP Connection resue）的方法。
持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態。

持久鏈接的好處在於減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使HTTP請求和響應可以更早地結束，這樣Web頁面的顯示速度也相應提升了。

在HTTP/1.1中，全部鏈接默認都是持久鏈接，但在HTTP/1.0內並未標準化。
毫無疑問，除了服務器端，客戶端也須要支持持久鏈接。

管線化

持久鏈接使得多數請求以管線化方式發送成爲可能。之前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不等等待響應亦可直接發送下一個請求（並行發送多個請求）。

每一個瀏覽器支持的請求併發數不一樣，但可在頁面中使用多個域名加大併發量（由於瀏覽器是基於domain的併發控制，而不是page），不過過多的散佈會致使DNS解析上付出額外的代價。

使用Cookie的狀態管理

Cookie技術經過在請求和響應報文中寫入cookie信息來控制客戶端的狀態。
Cookie會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。

若是您在cookie中設置了HttpOnly屬性，那麼經過js腳本將沒法讀取到cookie信息，這樣能有效的防止XSS攻擊。

Cookie-free Domains：用戶在請求靜態資源時，也會發送cookie信息。對於一個擁有多個靜態資源的網站，這無疑會產生沒必要要的流量。所以咱們能夠啓用與主站不一樣的域名（包括子域名）來放置靜態資源。

第三章 HTTP報文內的HTTP信息

用於HTTP協議交互的信息被稱爲HTTP報文。請求端的HTTP報文叫作請求報文，響應端的叫作響應報文。HTTP報文自己是由多行（用CR+LF作換行符）數據構成的字符串文本。

HTTP報文大體可分爲報文首部和報文主體兩部塊。二者由最初出現的空行（CR+LF、回車符+換行符）來劃分。一般，並不必定要有報文主體。

編碼提高傳輸速率

HTTP在傳輸數據時能夠按照數據原貌直接傳輸，但也能夠在傳輸過程當中經過編碼提高傳輸速率，但這會消耗更多的CPU等資源。

報文主體和實體主體的差別

報文：是HTTP通訊中的基本單位，由8位組字節流組成，經過HTTP通訊傳輸。
實體：做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。

HTTP報文的主體用於傳輸請求或響應的實體主體。
一般，報文主體等於實體主體。只有當傳輸中進行編碼操做時，實體主體的內容發生變化，才致使它和報文主體產生差別。

壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。
常見的內容編碼有：gzip（GNU zip）、compress（UNIX系統的標準壓縮）、deflate（zlib）、identity（不進行編碼）

分隔發送的分塊傳輸編碼

在HTTP通訊過程當中，請求的編碼實體資源還沒有所有傳輸完成以前，瀏覽器沒法顯示請求頁面。在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面。
這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。

分塊傳輸編碼會將實體主體分紅多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0（CR+LF）」來標記。

使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復到編碼前的實體主體。

發送多種數據的多部分對象集合

HTTP協議中採納了多部分對象集合，發送的一份報文主體內可含有多類型實體。一般實在圖片或文本文件等上傳時使用。

獲取部份內容的範圍請求

下載大尺寸的圖片的過程當中，若是網絡中斷，則須要從新下載。所以須要一種可恢復的機制。
實現該功能須要指定下載的實體範圍，像這樣，指定範圍發送的請求叫作範圍請求。
執行範圍請求時，會用到首部字段Range來指定資源的byte範圍。響應會返回狀態碼206 Partial Content。

若是服務器端沒法響應範圍請求，則會返回狀態碼200 OK和完整的實體內容。

內容協商返回最合適的內容

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

返回結果的HTTP狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。
狀態碼如200 OK，以3爲數字和緣由短語組成。
數字中的第一位定義了響應類別，後兩位無分類。響應類別有如下五種：

	類別	緣由短語
1XX	Informational(信息性狀態碼)	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	須要進行附加操做以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	服務器沒法處理請求
5XX	Server Error（服務器錯誤狀態碼）	服務器處理請求出錯

只要遵照狀態碼類別的定義，即便改變 RFC2616 中定義的狀態碼，或服務器端自行建立狀態碼都沒問題。

經常使用的狀態碼14種：

2XX 成功

200 OK：請求被正常處理
204 No Content：通常在只需從客戶端往服務器發送信息，而對客戶端不須要發送新信息內容的狀況下使用。
206 Partial Content：客戶端進行範圍請求

3XX 重定向

301 Moved Permanently：永久重定向。表示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI。
也就是說，若是已經把資源對應的URI保存爲書籤了，這時應該按Location首部字段提示的URI從新保存。
302 Found：臨時性重定向。表示請求的資源已被分配了新的URI，但願用戶（本次）能使用新的URI訪問。
和301 Moved Permanently狀態碼類似，但302狀態碼錶明的資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的URI未來還有可能發生改變。好比，用戶把URI保存成書籤，但不會像301狀態碼出現時那樣去更新書籤，而是仍舊保留返回302狀態碼的頁面對應的URI（在Chrome中，仍是會保存爲重定向後的URI，不解）。
303 See Other：表示因爲請求對應的資源存在着另外一個URI，應使用GET方法定向獲取請求的資源。這與302相似，但303明確表示客戶端應當採用GET方法獲取資源。
304 Not Modified：該狀態碼錶示客戶端發送附帶條件的請求（指採用GET方法的請求報文中包含If-Match,If-Modified-Since，If-None-March，If-Range，If-Unmodified-Since中任一首部。）時，服務器端容許請求訪問資源，但因發生請求爲知足條件的狀況後，直接返回304（服務器端資源未改變，可直接使用客戶端未過時的緩存）。304狀態碼返回時，不包含任何響應的主體部分。
304雖被劃分在3XX類別，可是和重定向沒有關係。
307 Temporary Redirect：臨時重定向。與302有相同含義。307遵照瀏覽器標準，不會從POST變成GET。

就算是304，也須要發出請求與接收響應，也會耗費資源和時間。

4XX 客戶端錯誤

4XX的響應結果代表客戶端是發生錯誤的緣由所在。

400 Bad Request：表示請求報文中存在語法錯誤。
401 Unauthorized：表示發送的請求須要有經過HTTP認證（BASIC認證、DIGEST認證）的認證信息。
403 Forbidden：代表對請求資源的訪問被服務器拒絕了。服務器端可在實體的主體部分對緣由進行描述（可選）
404 Not Found：代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由時時用。

5XX 服務器錯誤

5XX的響應結果代表服務器自己發生錯誤。

500 Interval Server Error：代表服務器端在執行請求時發生了錯誤。也有多是Web應用存在的bug或某些臨時的故障。
503 Service Unavailable：代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入Retry-After首部字段再返回給客戶端。

第五章與HTTP協做的Web服務器

用單臺虛擬主機實現多個域名

HTTP/1.1 規範容許一臺HTTP服務器搭建多個Web站點。這是利用虛擬主機（Virtual Host，又稱虛擬服務器）的功能。

在互聯網上，域名經過DNS服務映射到IP地址以後訪問目標網站。可見，當請求發送到服務器時，已是以IP地址形式訪問了。因此，當一臺託管了兩個域名的服務器接收到請求時就須要弄清楚究竟要訪問哪一個域名。
在相同的IP地址下，因爲虛擬主機能夠寄存多個不一樣主機名和域名的Web網站，所以在發送HTTP請求時，必須在Host首部內完整指定主機名或域名的URI。

通訊數據轉發程序：代理、網關、隧道

HTTP通訊時，除客戶端和服務器之外，還有一些用於通訊數據轉發的應用程序，例如代理、網關、隧道。它們能夠配合服務器工做。

代理：是一種有轉發功能的應用程序，扮演了位於服務器和客戶端「中間人」的角色，接收由客戶端發送的請求並轉發給服務器，同時也接收服務器返回的響應並轉發給客戶端。
網關：是轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。
隧道：是在相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序。

代理

代理不改變請求URI，會直接發送給前方持有資源的目標服務器。
持有資源實體的服務器被稱爲源服務器。

例如：

每次經過代理服務器轉發請求或響應式，會追加寫入via首部信息。

使用代理服務器的理由有：利用緩存技術減小網絡帶寬的流量，組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的，等等。

代理有多種使用方法，按兩種基準分類。一種是是不是否使用緩存，另外一種是是否會修改報文。

代理緩存：代理轉發響應時，緩存代理（Caching Proxy）會預先將資源的副本（緩存）保存在代理服務器上。當代理再次接收到對相同資源的請求時，就能夠不從源服務器那裏獲取資源，而是將以前緩存的資源做爲響應返回。
透明代理：轉發請求或響應時，不對報文作任何加工的代理類型被稱爲透明代理（Transparent Proxy）。反之，對報文內容進行加工的代理被稱爲非透明代理。

網關

網關的工做機制和代理十分類似。而網關能使通訊線路上的服務器提供非HTTP協議服務。
利用網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。好比，網關能夠鏈接數據庫，使用SQL語句查詢數據。另外，在Web購物網站上進行信用卡結算時，網關能夠和信用卡結算系統聯動。

隧道

隧道可按要求創建起一條與其餘服務器的通訊線路，屆時使用SSL等加密手段進行通訊。隧道的目的是確保客戶端與服務器進行安全的通訊。

隧道自己不會去解析HTTP請求。請求保持原樣中轉給以後的服務器。隧道會在通訊雙方斷開鏈接時結束。

保存資源的緩存

緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。利用緩存可減小對源服務器的訪問，節省通訊流量和時間。

緩存服務器是代理服務器的一種。當代理轉發從服務器返回的響應時，代理服務器將會保存一份資源的副本。

緩存服務器的優點在於利用緩存可避免屢次從源服務器轉發資源。所以客戶端可就近從緩存服務器上獲取資源，而源服務器也沒必要屢次處理相同的請求了。

緩存的有效期限

對於緩存服務器和客戶端瀏覽器，當斷定緩存過時或客戶端要求，會向源服務器確認資源的有效性。若失效，瀏覽器會再次請求新資源。

第六章 HTTP首部

HTTP協議的請求和響應報文中一定包含HTTP首部。首部內容爲客戶端和服務器端分別處理請求和響應提供所須要的信息。

HTTP請求報文：由方法、URI、HTTP版本、HTTP首部字段等構成。
HTTP響應報文：由HTTP版本、狀態碼（數字和緣由短語）、HTTP首部字段 3 部分組成。

HTTP首部字段

使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

4種HTTP首部字段類型

HTTP首部字段根據實際通途被分爲如下4種類型：

通用首部字段（General Header Fileds）：請求報文和響應報文兩方都會使用的首部
請求首都字段（Request Header Fields）：從客服端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。
響應首部字段（Response Header Fields）：從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
實體首部字段（Entity Header Fields）：針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

HTTP/1.1首部字段一覽

通用首部字段

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

Cache-Control的no-cache指令表明不緩存過時的資源，而不是不緩存。no-store纔是真正不進行緩存。
Connection首部字段的值爲close時，表明服務器想明確斷開鏈接（HTTP/1.1默認都是持久鏈接）

請求首部字段

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

該表的Accept*字段均可以指定權重q（0-1）。當服務器提供多種內容時，將會首先返回權重最高的。
If-xxx請求首部字段都稱爲條件請求，服務器接收到附帶條件的請求後，只有判斷指定條件爲真時，纔回執行請求。
Referer 的正確拼寫應該是Referrer。當直接在瀏覽器的地址欄輸入URI時，或處於安全考慮時，可不發該首部字段。

響應首部字段

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

幾乎全部瀏覽器在接收到包含首部字段Location的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。

實體首部字段

首部字段名	說明
Allow	資源可支持的HTTP方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的天然語言
Content-Length	實體主體的大小（字節）
Content-Location	替代對應資源的URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置範圍
Content-Type	實體主體的媒體類型
Expires	實體主體過時的日期時間
Last-Modified	資源的最後修改日期時間

爲Cookie服務的首部字段

首部字段名	說明	首部類型
Set-Cookie	開始狀態管理所使用的Cookie信息	響應首部字段
Cookie	服務器接收到的Cookie信息	請求首部字段

Set-Cookie字段的屬性

屬性	說明
NAME=VALUE	賦予Cookie的名稱和其值（必需項）
expires=DATE	Cookie的有效期（若不明確指定則默認爲瀏覽器關閉前爲止）
path=Path	將服務器上的文件目錄做爲Cookie的適用對象（若不指定則默認爲文檔所在的文件目錄）
domain=域名	做爲Cookie適用對象的域名（若不指定則默認爲建立Cookie的服務器的域名）
Secure	僅在HTTPS安全通訊時纔會發送Cookie
HttpOnly	加以限制，使Cookie不能被JavaSript腳本訪問

expires：一旦Cookie從服務器端發送至客戶端，服務器端就不存在能夠顯示刪除Cookie的方法。但可經過覆蓋已過時的Cookie，實現對客戶端Cookie的實質性刪除操做。
path：用來指定cookie被髮送到服務器的哪個目錄路徑下（即被服務器哪一個路徑接收cookie），其中"/"指的是站點根目錄，可在同一臺服務器（即便有多個應用）內共享該cookie。

第七章確保Web安全的HTTPS

HTTP的肯定

通訊使用明文可能會被竊聽
不驗證通訊方的身份就可能遭受假裝
沒法驗證報文完整性，可能已遭篡改

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

第八章確認訪問用戶身份的認證

覈對的信息一般是指如下這些：

密碼：只有本人才會知道的字符串信息
動態令牌：僅限本人持有的設備內顯示的一次性密碼
數字證書：僅限本人（終端）持有的信息
生物認證：指紋和虹膜等本人的生理信息
IC卡等：僅限本人持有的信息

HTTP/1.1 使用的認證方式以下所示：

BASIC認證（基本認證）
DIGEST 認證（摘要認證）w
SSL 客戶端認證
FormBase認證（基於表單認證）

第九章基於HTTP的功能追加協議

HTTP的瓶頸

使用HTTP協議探知服務器上是否有內容更新，就必須頻繁地從客戶端到服務器端進行確認。若是服務器上沒有內容更新，那麼就會產生徒勞的通訊。
若想在現有Web實現所需的功能，一下這些HTTP標準就會成爲瓶頸：

一條鏈接上只可發送一個請求（前面講到，持久化可保持TCP鏈接狀態，但仍完成一次請求/響應後才能進行下一次請求/響應，而管線化方式可以讓一個TCP鏈接並行發送多個請求。）
請求只能從客戶端開始。客戶端不能夠接收除響應之外的指令
請求/響應首部未經壓縮就發送。首部信息越多延遲越大
發送冗長的首部。每次互相發送相同的首部形成的浪費較多
可任意選擇數據壓縮格式。非強制壓縮發送

Comet 的解決方法

一般，服務器接收到請求，在處理完畢後就當即返回響應，但爲了實現推送功能，Comet會先將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。
內容上雖然能夠作到實時更新，但爲了保留響應，一次鏈接的持續時間也變長了。期間，爲了維持鏈接會消耗更多的資源。另外，Comet仍未解決HTTP協議的自己存在的問題。

SPDY

Google 在2010年發佈了 SPDY，其開發目標旨在解決HTTP的性能瓶頸，縮短Web頁面的加載時間。
SPDY沒有徹底改寫HTTP協議，而是在TCP/IP的應用層與運輸層之間經過新加會話層的形式運做。同時，考慮到安全性問題，SPDY規定通訊中使用SSL。

SPDY以會話層的形式加入，控制對數據的流動，但仍是採用HTTP創建通訊鏈接。所以，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP報文等。

使用 SPDY後，HTTP協議額外得到如下功能。

多路複用流：經過單一的TCP鏈接，能夠無限制處理多個HTTP請求。全部請求的處理都在一條TCP鏈接上完成，所以TCP的處理效率獲得提升。
賦予請求優先級：SPDY不只能夠無限制地併發處理請求，還能夠給請求逐個分配優先級順序。這樣主要是爲了在發送多個請求時，解決因帶寬低而致使響應變慢的問題。
壓縮HTTP首部：壓縮HTTP請求和響應的首部。
推送功能：支持服務器主動向客戶端推送數據的功能。
服務器提示功能：服務器能夠主動提示客戶端請求所需的資源。因爲在客戶端發現資源以前就能夠獲知資源的存在，所以在資源已緩存等狀況下，能夠避免發送沒必要要的請求。

使用瀏覽器進行全雙工通訊的 WebSocket

利用Ajax和Comet技術進行通訊能夠提高Web的瀏覽速度。但問題在於通訊若使用HTTP協議，就沒法完全解決瓶頸問題。

WebSocket技術主要是爲了解決Ajax和Comet裏XMLHttpRequst附帶的缺陷所引發的問題。

一旦Web服務器與客戶端之間創建起WebSocket協議的通訊鏈接，以後全部的通訊都依靠這個專用協議進行。通訊過程當中可互相發送JSON、XML、HTML或圖片等任意格式的數據。

WebSocket的主要特色：

推送功能：支持由服務器向客戶端推送數據。
減小通訊量：和HTTP相比，不但每次鏈接時的總開銷減小，並且因爲WebSocket的首部信息很小，通訊量也相應較少。

爲了實現WebSocket通訊，在HTTP鏈接創建以後，須要完成一次「握手」的步驟。

握手·請求：爲了實現WebSocket通訊，須要用到HTTP的Upgrade首部字段，告知服務器通訊協議發生改變，以達到握手的目的。
握手·響應：對於以前的請求，返回狀態碼101 Switching Protocols 的響應。

成功握手確立WebSocket鏈接後，通訊時再也不使用HTTP的數據幀，而採用WebSocket獨立的數據幀。

因爲是創建在HTTP基礎上的協議，所以鏈接的發起方還是客戶端，而一旦確立WebSocket通訊鏈接，不論服務器端仍是客戶端，任意一方均可直接向對方發送報文。

HTTP/2.0

HTTP2中英對照版
 HTTP/2.0 相比1.0有哪些重大改進？

第十一章 Web攻擊技術

簡單的HTTP協議自己並不存在安全性問題，所以協議自己幾乎不會成爲攻擊的對象。應用HTTP協議的服務器和客戶端，以及運行在服務器上的Web應用等資源纔是攻擊目標。

HTTP不具有必要的安全功能，就拿遠程登陸時會用到的SSH協議來講，SSH具有協議級別的認證及會話管理等功能，HTTP協議則沒有。另外在架設SSH服務方面，任何人均可以輕易地建立安全等級高的服務。而HTTP即便已假設好服務器，但開發者須要自行設計並開發認證及會話管理功能來知足Web應用的安全。而自行設計就意味着會出現各類形形色色的實現，可仍在運做的Web應用背後就會隱藏着各類容易被攻擊者濫用的安全漏洞的Bug。

因輸出值轉義不徹底引起的安全漏洞

跨站腳本攻擊（Cross-Site Scripting, XSS）：主要是指在用戶瀏覽器內運行了非法的 HTML 標籤或 JavaScript 腳本。好比富文本編輯器，若是不過濾用戶輸入的數據直接顯示用戶輸入的HTML內容的話，就會有可能運行惡意的 JavaScript 腳本，致使頁面結構錯亂，Cookies 信息被竊取等問題。
SQL注入攻擊（SQL Injection）：是指針對 Web 應用使用的數據庫，經過運行非法的SQL而產生的攻擊。
OS命令攻擊（OS Command Injection）：是指經過 Web 應用，執行非法的操做系統命令達到攻擊的目的。只要在能調用 Shell 函數的地方就有存在被攻擊的風險。
HTTP首部注入攻擊（HTTP Header Injection）：是指攻擊者經過在響應首部字段內插入換行，添加任意響應首部或主體的一種攻擊。
HTTP 響應截斷攻擊：是用在 HTTP 首部注入的一種攻擊。攻擊順序相同，可是要將兩個 %0D%0A%0D%0A 並排插入字符串後發送。利用兩個連續的換行就可做出 HTTP 首部與主體分隔所需的空行了，這樣就能顯示僞造的主體，達到攻擊的目的。
郵件首部注入攻擊（Mail Header Injection）：是指 Web 應用中的郵件發送功能，攻擊者經過向郵件首部 To 或 Subject 內任意添加非法內容發起的攻擊。利用存在安全漏洞的Web網站，可對任意郵件地址發送廣告郵件或病毒郵件。
目錄遍歷攻擊（Directory Traversal）：是指對本無心公開的文件目錄，經過非法截斷其目錄路徑後，達成訪問目的的一種攻擊。好比，經過 ../ 等相對路徑定位到 /etc/passwd 等絕對路徑上。
遠程文件包含漏洞（Remote File Inclusion）：是指當部分腳本內容須要從其餘文件讀入時，攻擊者利用指定外部服務器的URL充當依賴文件，讓腳本讀取以後，就可運行任意腳本的一種攻擊。

因設置或設計上的缺陷引起的安全漏洞

強制瀏覽（Forced Browsing）：是指，從安置在Web服務器的公開目錄下的文件中，瀏覽那些本來非自願公開的文件。好比，沒有對那些須要保護的靜態資源增長權限控制。
不正確的錯誤消息處理（Error Handling Vulerability）：指Web應用的錯誤信息內包含對攻擊者有用的信息。
開放重定向（Open Redirect）：是一種對指定的任意URL做重定向跳轉的功能。而於此功能相關聯的安全漏洞是指，假如指定的重定向 URL 到某個具備惡意的 Web 網站，那麼用戶就會被誘導至那個 Web 網站。

因會話管理疏忽引起的安全漏洞

會話劫持（Session Hijiack）：是指攻擊者經過某種手段拿到了用戶的會話 ID，並不是法使用此會話 ID 假裝成用戶，達到攻擊的目的。
會話固定攻擊（Session Fixation）：對以竊取目標會話ID爲主動攻擊手段的會話劫持而言，會強制用戶使用攻擊者指定的會話 ID，屬於被動攻擊。
跨站點請求僞造（Cross-Site Request Forgeries, CSRF）：是指攻擊者經過設置好陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定等某些狀態更新，屬於被動攻擊。

其它安全漏洞

密碼破解：①經過網絡進行密碼試錯（窮舉法和字典攻擊）；②對已加密密碼的破解（經過窮舉法·字典攻擊進行類推、彩虹表、拿到加密時使用的密鑰、加密算法的漏洞）
點擊劫持：是指利用透明的按鈕或連接作成陷阱，覆蓋在Web頁面之上。而後誘使用戶在不知情的狀況下，單擊那個連接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝（UI Redressing）。
Dos攻擊：是一種讓運行中的服務呈中止狀態的攻擊。有時也叫作服務中止攻擊或拒絕服務攻擊。多臺計算機發起的 Dos 攻擊稱爲 DDoS 攻擊（Distributed Denial of Service attach）。
後門程序：是指開發設置的隱藏入口（如開發階段做爲Debug調用的後門程序），可不按正常步驟使用受限功能。利用後門程序就可以使用本來受限的功能。