《圖解http》筆記

第1章、瞭解Web幾網絡基礎

一、TCP/IP協議族按層次分別分爲如下4層：

應用層： 應用層決定了向用戶提供應用服務時通訊的活動。例如：FTP（文件傳輸協議）、DNS（域名系統）、http
傳輸層： 傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。協議：TCP（傳輸控制協議）、UDP（用戶數據報協議）
網絡層（又名網絡互聯層）： 網絡層用來處理網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑（所謂的傳輸線路）到達對方計算機，並把數據包傳送給對方。
與對方計算機之間經過多臺計算機或玩過設備進行傳輸時，網絡層所起的做用就是在衆多的選項內選擇一條傳輸路線。協議： IP協議
鏈路層（又名數據鏈路層，網絡接口層）：
用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設計驅動、NIC（網絡適配器，即網卡），及光纖等物理可見部分（還包括鏈接器等一切傳輸媒介）。硬件上的範疇均在鏈路層的做用範圍以內。

二、負責傳輸的IP協議

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

三、確保可靠性的TCP協議

按層次分，TCP位於傳輸層，提供可靠的字節流服務。
所謂的字節流服務是指，爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理。而可靠的傳輸服務是指可以把數據準確可靠的傳給對方。一言蔽之，TCP協議爲了更容易的傳送大數據把數據分割，並且TCP協議可以確認數據最終是否送達到對方。 爲了準確無誤的將數據送達目標處，TCP協議採用了三次握手策略。用TCP協議把數據包送出去以後，TCP不會對傳送後的狀況置之不理，它必定會向對方確認是否成功送達。握手過程當中使用了TCP的標誌（flag）---SYN（synchronize）和ACK（ackonwledgement）。 發送端首先發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端在回傳一個帶ACK標誌的數據包，表明「握手」結束。 若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。

四、負責域名解析的DNS服務

DNS（Domain Name System）服務時和HTTP協議同樣位於應用層的協議。他提供域名到IP地址之間的解析服務。
計算機既能夠被賦予IP地址，也惡意被賦予主機名和域名。好比www.hackr.jp。
用戶一般使用主機名或域名來訪問對方的計算機，而不是直接經過IP地址訪問。由於與IP地址的一組純數字相比，用字幕配合數字的表示形式來指定計算機名更符合人類的記憶習慣。
但要讓計算機去理解名稱，相對而言就變得困難了。由於計算機更擅長處理一長串數字。
爲了解決上述的問題，DNS服務應運而生。DNS協議提供經過域名查找IP地址，或逆向從IP地址反查域名的服務。

五、URI和URL

URI（統一資源標識符）用字符串標識某一互聯網資源，而URL（統一資源定位符）標識資源的地點（互聯網上所處的位置）。
URI格式： user:pass@www.example.jp:80/dir/index.h…
使用http：或者https:等協議方案名獲取訪問資源時要指定協議類型。不區分字母大小寫，最後附一個冒號（：）。
也可使用data：或javascrip：這類指定數據或腳本程序的方案名。

• 登陸信息（認證）：指定用戶名和密碼做爲從服務器獲取資源時必要的登陸信息（身份認證）。此項是可選項。
• 服務器地址：使用絕對URI必須指定待訪問的服務器地址。地址能夠是相似hackr.jp這種DNS能夠解析的名稱，或是192.168.1.1這類IPv4地址名，還能夠是[0:0:0:0:0:0:0:1]這樣用方括號括起來的IPv6地址名。
• 服務器端口號：指定服務器鏈接的網絡端口號。此項也是可選項，若用戶省略則自動使用默認端口號。
• 帶層次的文件路徑：指定服務器上的文件路徑來定位特指的資源。這與UNIX系統的文件目錄結構類似。
• 查詢字符串：針對已指定的文件路徑內的資源，可使用字符串傳入任意參數。此項可選。
• 片斷標識符：使用片斷標識符一般可標記處已獲取資源中的子資源（文檔內的某個位置）。但在RFC中並無明確規定其使用方法。該項也爲可選項。（並非全部的應用程序都會符合RFC）

第二章、簡單的HTTP協議

一、報文組成：

請求報文組成：請求方法、請求URI、協議版本、可選的請求首部字段和內容實體
響應報文組成：協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體

二、HTTP是不保存狀態的協議

HTTP是一種不保存裝填，即無狀態（stateless）協議。HTTP協議自己不對請求和響應之間的通訊狀態進行保存。也就是說在HTTP這個級別，協議對於發送過的請求或響應都不作持久化處理。
HTTP/1.1雖然是無狀態協議，但爲了實現指望的保持狀態功能，因而引入了Cookie技術。

三、告知服務器意圖的HTTP方法

• GET:獲取資源
• POST：傳輸實體主體
• PUT：傳輸文件
• HEAD：獲取報文首部
• DELETE：刪除文件
• OPTIONS：詢問支持的方法
• TRACE：追蹤路徑
• CONNECT：要求用隧道協議鏈接代理

四、持久鏈接節省通訊量

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。爲解決TCP鏈接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久鏈接（HTTP Persistent Connects，也成爲HTTP keep-alive或HTTP connection reuse）的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開了解，則保持TCP鏈接狀態。
持久鏈接的好處在於減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使HTTP請求和相應可以更早的結束，這樣Web頁面的顯示速度也就提升了。
在HTTP/1.1中，全部的鏈接默認都是持久鏈接，但在HTTP/1.0內並未標準化。雖然有一部分服務器經過非標準的手段實現了持久鏈接，但服務器端不必定可以支持持久鏈接。毫無疑問，除了服務器端，客戶端也須要支持持久鏈接。
管線化：持久鏈接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後須要等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。這樣胖就可以作到同時並行發送多個請求，而不須要一個接一個的等待響應。

五、使用Cookie的狀態管理

不能否認，無狀態協議固然有他的有點。因爲沒必要保存狀態，天然可減小服務器的CPU幾內存資源的消耗。從另外一側面來講，也正是由於HTTP協議自己是很是簡單的，因此纔會被應用在各類場景裏。
保留無狀態協議這個特徵的同事又要解決讓服務期管理所有客戶端狀態則會成爲負擔的矛盾問題，因而引入了Cookie技術。Cookie結束經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
Cookie會根據從服務器端發送的響應報文內的一個叫作Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。
服務器端發現客戶端發送過來的Cookie後，回去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。

第三章、HTTP報文內的HTTP信息

一、HTTP報文

用於HTTP協議交互的信息叫作HTTP報文。請求端（客戶端）的HTTP報文叫作請求報文，響應端（服務端）的叫作響應報文。HTTP報文自己由多行（用CR+LF作換行符）數據構成的字符串文本。
HTTP報文大體可分爲報文首部和報文主體兩塊。二者由最初出現的空行來劃分。一般，並不必定要有報文主體

二、請求報文及響應報文的結構

• 請求報文首部：請求行、請求首部字段、通用首部字段、實體首部字段、其餘

• 響應報文首部：狀態行、響應首部字段、通用首部字段、實體首部字段、其餘

首部組成：

• 請求行：包含用於請求的方法，請求URI和HTTP版本

• 狀態行：包含代表響應結果狀態碼，緣由短語和HTTP版本

• 首部字段：包含表示請求和響應的各類條件和屬性的各種首部。通常包含四種：分別是：通用首部、請求首部、響應首部、和實體首部

• 其餘：可能包含HTTP的RFC裏未定義的首部（Cookie等）

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

發送郵件時，咱們能夠在郵件裏寫入文字並添加多分附件。這是由於採用了MIME（Multipurpose Internet Mail Extensions,多用途因特網郵件擴展）機制，它容許郵件處理文本、圖片、視頻等多個不一樣類型的數據。例如，圖片等二進制數據以ASCII碼字符串編碼的方式指明，就是利用MIME來標記數據類型。而在MIME擴展中會使用一種稱爲多部分對象集合（Multipart）的方法，來容納多份不一樣類型的數據。
相應的，HTTP協議中也採納了多部分對象集合，發送的一份報文主體內可含有多類型實體。一般是在圖片或文本文件等上傳時使用。

多部分對應集合包含的對象以下。

• multipart/form-data:在Web表單文件上傳時使用
• multipart/byteranges:狀態碼206（Partial Content，部份內容）響應報文包含了多個範圍的內容時使用

第四章 返回結果的HTTP狀態碼

一、2** 成功

2** 的響應結果代表請求被正常處理了。

• 200 OK 表示從客戶端發來的請求在服務器端被正常處理了。 在響應報文內，隨狀態碼一塊兒返回的信息會由於方法的不一樣而發生改變。好比，使用GET方法時，對應請求資源的實體會做爲響應返回；而使用HEAD方法時，對應請求資源的實體首部不隨報文主體做爲響應返回（即在響應中只返回首部，不會返回實體的主體部分）

• 204 No Centent 該狀態碼錶明服務器接收的請求已成功處理，但在返回的響應報文中不包含實體的主體部分，另外，也不容許返回任何實體的主體。好比，當從瀏覽器發出請求處理後，返回204響應，那麼瀏覽器顯示的頁面不會發生更新。
  通常在只須要從客戶端往服務器發送信息，而對客戶端不須要發送信息新內容的狀況下使用。

• 206 Partical Content 該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定範圍的實體內容。

二、3** 重定向

3**響應結果代表瀏覽器須要執行某些特殊的處理以正確處理請求。

• 301 Moved Permanently 永久性重定向。該狀態碼錶示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI。也就是說，若是已經把資源對應的URI保存爲書籤了，這時應該按Location首部字段提示的URI從新保存。
  像下方給出的請求URI，當指定資源路徑的最後忘記添加斜槓「/」,就會產生301狀態碼
  example.com/sample

• 302 Found 臨時性重定向。該狀態碼錶示請求的資源已被從新分配了新的URI，但願用戶（本次）能使用新的URI訪問。
  和301 Moved Permanently狀態碼類似，但302狀態碼錶明的資源不是被永久移動，只是臨時性性質的。換句話說，已移動的資源對應的URI未來還有可能發生改變。好比，用戶把URI保存成書籤，但不會像301狀態碼出現時那樣去更新書籤，而是仍舊保留返回302狀態碼的頁面對應的URI。

• 303 See Other 該狀態碼錶示因爲請求對應的資源存在着另外一個URI，應使用GET方法定向獲取請求的資源。
  303狀態碼和302Found狀態碼有着相同的功能，但303狀態碼明確表示客戶端應當採用GET方法獲取資源，這點與302狀態碼有區別。
  好比，當使用POST方法訪問CGI程序，其執行後的處理結果是但願客戶端能以GET方法重定向到另外一個URI上去時，返回303狀態碼。雖然302Found狀態碼也能夠實現相同的功能，但這裏使用303狀態碼是最理想的。

當30一、30二、303響應狀態碼返回時，幾乎全部的瀏覽器都會把POST改爲GET，並刪除請求報文內的主體，以後請求會自動再次發送。30一、302標準是禁止將POST方法改爲GET方法的，但實際會用時你們都這麼作。

• 304 Not Modified 該狀態碼錶示客戶端發送附帶條件的請求時，服務器端容許請求訪問資源，但因發生請求未知足條件的狀況後，直接返回304Not Modified（服務器資源未發生改變，可直接使用客戶端未過時的緩存）。304狀態碼返回時，不包含任何響應的主體部分。304雖然被劃分在3**類別中，可是和重定向沒有關係。

• 307 Temporary Redirect 臨時重定向。該狀態碼與302Found有着相同的含義。儘管302標準禁止POST變換成GET，但實際使用時你們並不遵照。
  307會遵守瀏覽器標準，不會POST變成GET。可是，對於處理響應時的行爲，每種瀏覽器有可能會出現不一樣的狀況。

三、4** 客戶端錯誤

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

• 400 Bad Request 該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。另外，瀏覽器會像200 OK同樣對待該狀態碼。

• 401 Unauthorized 該狀態碼錶示發送的請求須要有經過HTTP認證（BASIC認證DIGEST認證）的認證信息。另外若以前已進行過1次請求，則表示用戶認證失敗。
  返回含有401的響應必須包含一個適用於被請求資源的WWW-Authenticate首部用以質詢（challenge）用戶信息。當瀏覽器初次接受到401響應，會彈出認證用的對話窗口。

• 403 Forbidden 該狀態碼代表對請求資源的訪問被服務器拒絕了。服務器端沒有必要給出拒絕的詳細理由，但若是想做說明的話，能夠在實體的主體部分對緣由進行描述，這樣就能讓用戶看到了。
  未得到文件系統的訪問受權，訪問權限出現某些問題（從未受權的發送源IP地址試圖訪問）等列舉的狀況均可能是發生403的緣由。

• 404 Not Found 該狀態碼代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求切不想說明理由時使用。

5** 服務器錯誤

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

• 500 Internal Server Error 該狀態碼代表服務器端在執行請求時發生了錯誤。也有多是Web應用存在的bug或某些臨時的故障。

• 503 Service Unavailable 該狀態碼代表服務器暫時處於超負荷或正在進行停機維護，如今沒法處理請求。若是實現得知解除以上狀況須要的時間，最好寫入Retry-After首部字段在返回給客戶端。

第六章 HTTP首部

一、HTTP報文首部

HTTP報文組成：報文首部、空行（CR+LF）、報文主體。
HTTP協議的請求和響應報文中一定包含HTTP首部。首部內容爲客戶端和服務器端分別處理請求和響應提供所須要的信息。對於客戶端用戶來講，這些信息中的大部份內容都無需親自查看。
報文首部由幾個字段構成。

• HTTP請求報文 在請求報文中，HTTP報文首部由方法、URI、HTTP版本、HTTP首部字段等部分構成。

• HTTP響應報文 在響應中，HTTP報文首部由HTTP版本、狀態碼（數字和緣由短語）、HTTP首部字段3部分構成。

二、4種HTTP首部字段類型

HTTP首部字段根據實際用途被分爲如下四種類型

• 通用首部字段（General Header Fields） 請求報文和響應報文兩方都會使用的首部。

• 請求首部字段（Request Header Fields） 從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。

• 響應首部字段（Response Header Fields） 從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會使用客戶端附加額外的內容信息。

• 實體首部字段（Entity Header Fields） 針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

第七章 確保Web安全的HTTPS

一、HTTP的缺點

• 通訊使用明文（不加密），內容可能會被竊聽
• 不驗證通訊方的身份，所以有可能遭遇假裝
• 沒法證實報文的完整性，因此有可能已遭篡改

二、通訊使用明文可能會被竊聽

因爲HTTP自己不具有加密的功能，因此也沒法作到對通訊總體（使用HTTP協議通訊的請求和響應的內容）進行加密。即，HTTP報文使用明文（指未通過加密的報文）方式發送。

2.1 TCP/IP是可能被竊聽的網絡
若是要問問什麼通訊時不加密是一個缺點，這是由於，按TCP/IP協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。
所謂互聯網，是由能連通到全世界的網絡組成的。不管世界哪一個角落的服務器在和客戶端通訊時，在此不排除某個環節中會遭到窺視行爲。
即便已通過加密處理的通訊，也會被窺視到通訊內容，這點和未加密的通訊時相同的。只是說若是通訊通過加密，就有可能讓人沒法破解報文信息的含義，但加密處理後的報文信息自己仍是會被看到的。

2.2 加密處理防止被竊聽

• 通訊的加密 一種方式就是將通訊加密。HTTP協議中沒有加密機制，但能夠經過和SSL（Secure Socket Layer，安全套階層）或TLS（Transport Layer Security，安全傳輸層協議）的組合使用，加密HTTP的通訊內容。
  用SSL創建安全通訊線路以後，就能夠在這條線路上進行HTTP通訊了。與SSL組合使用的HTTP被稱爲HTTPS（HTTP Secure,超文本傳輸安全協議）或HTTP over SSL。

• 內容的加密 還有一種將參與通訊內容自己的加密方式。因爲HTTP協議中沒有加密機制，那麼就對HTTP協議傳輸的內容自己加密。即把HTTP報文裏所含的內容進行加密處理。
  在這種狀況下，客戶端須要對HTTP報文進行加密處理後在發送請求。
  誠然，爲了作到有效的內容加密，前提是要求客戶端和服務器同事具有加密和解密機制。主要應用在Web服務中。有一點必須引發注意，因爲該方式不一樣於SSL或TLS將整個通訊線路加密處理，因此內容仍有被篡改的風險。

3不驗證通訊方的身份就可能遭遇假裝

HTTP協議中的請求和響應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中URI真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端」等相似問題。
3.1 任何人均可以發起請求
在HTTP協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發送請求。另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的IP地址和端口號沒有被Web服務器設定訪問限制的前提下）。
HTTP協議的實現自己很是簡單，不管是誰發送過來的請求都會返回響應，所以不確認通訊方，會存在如下各類隱患：

• 沒法肯定請求發送至目標的Web服務器是不是按真實意圖返回響應的那臺服務器。有多是已假裝的Web服務器。
• 沒法肯定響應返回到的客戶端是不是按真實意圖接收響應的那個客戶端。有多是已假裝的客戶端。
• 沒法肯定正在通訊的雙方是否具有訪問權限。由於某些Web服務器上保存着重要的的信息，只想發給特定用戶通訊的權限。
• 沒法斷定請求是來自何方，出自誰手
• 即便是無心義的請求也會照單全收。沒法阻止海量請求下的DoS攻擊（Denial of Service，拒絕服務攻擊）。

3.2 查找對手的證書 雖然使用HTTP協議沒法肯定通訊方，但若是使用SSL則能夠。SSL不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於肯定方。
證書由指的新人的第三方機構頒發，用以證實服務器和客戶端是實際存在的。另外，僞造證書從技術角度來講是異常困難的一件事。因此只要可以確認通訊方（服務器或客戶端）持有的證書，便可判斷通訊方的真實意圖。
經過使用證書，以證實通訊方就是意料中的服務器。這對使用者我的來說，也減小了我的信息泄露的危險性。
另外，客戶端持有證書便可完成我的身份的確認，也可用Web網站的認證環節。

四、沒法證實報文完整性，可能已遭篡改

所謂完整性是指信息的準確性。若沒法證實其完整性，一般也就意味着沒法判斷信息是否準確。
4.1接收到的內容可能有誤
因爲HTTP協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後知道對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應時先後相同的。
如何防止篡改
雖然有使用HTTP協議肯定報文完整性的方法，但事實上並不便捷、可靠。其中經常使用的是MD5和SHA-1等散列值校驗的方法，以及用來確認文件的數字簽名方法。

5 HTTPS採用混合加密機制

HTTPS採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。若密鑰可以實現安全交換，那麼有可能胡考慮僅使用公開密鑰加密來通訊。可是公開密鑰加密與共享密鑰加密相比，其處理速度更慢。
因此應充分利用二者各自的優點，將多種方法組合起來用於通訊。在交換密鑰環節使用公開密鑰加密方式，以後的簡歷通訊交換報文階段則使用共享密鑰加密方式。

6 HTTPS的安全通訊機制

• 步驟1：客戶端經過發送Client Hello報文開始SSL通訊。報文中包含客戶端支持的SSL的指定版本、加密組織（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
• 步驟2：服務器可進行SSL通訊時，會以Server Hello報文做爲應答。和客戶端同樣，在報文中包含SSL版本以及加密組件。服務器的加密組織內容是從接收到的客戶端加密組件篩選出來的。
• 步驟3：以後服務器發送Certificate報文。報文中包含公開密鑰證書。
• 步驟4：最後服務器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。
• 步驟5：SSL第一次握手結束以後，客戶端以Client Key Exchange報文做爲響應。報文中包含通訊加密中使用的一種被稱爲Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。
• 步驟6:接着客戶端繼續發送Change Cipher Spec報文。該報文會提示服務器，在此安博文以後的通訊會採用Pre-master secret密鑰加密。
• 步驟7：客戶端發送Finished報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。
• 步驟8：服務器一樣發送Change Cipher Spec報文。
• 步驟9：服務器一樣發送Finished報文。
• 步驟10：服務器和客戶端的Finished報文交換完畢以後，SSL鏈接就算創建完成。固然，通訊會收到SSL的保護。今後處開始進行應用層協議的通訊，即發送HTTP請求。
• 步驟11：應用層協議通訊，即發送HTTP響應。
• 步驟12：最後由客戶端斷開鏈接。斷開鏈接時，發送close_notify報文。這步以後再發送TCP FIN報文來關閉與TCP的通訊。

7 SSL變慢緣由

HTTPS也存在一些問題，那就是使用SSL時，他的處理速度會變慢。
SSL的慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗CPU及內存等資源，致使處理速度變慢。
和使用HTTP相比，網絡負載可能會變慢2-100倍。除去和TCP鏈接、發送HTTP請求·響應意外，還必須進行SSL通訊，所以總體處理通訊量不可避免會增長。
另外一是SSL必須進行加密處理。在服務器和客戶端都須要進行加密和解密的運算處理。所以從結果上講，比起HTTP會更多的消耗服務器和客戶端的硬件資源，致使負載增長。
針對速度變慢這一問題，並無根本性的解決方法，咱們會使用SSL加速器這種（專用服務器）硬件來改善該問題。該硬件爲SSL通訊專用硬件，相對軟件來說，可以提升數倍SSL的計算速度。盡在處理SSL時發揮SSL加速器的功效，以分擔負載。

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

1 Session管理及Cookie應用

基於表單認證的標準規範還沒有有定論，通常會用Cookie來管理Session（會話）。
基於表單認證自己是經過服務器端的Web應用，將客戶端發送過來的用戶ID和密碼與以前登陸過的信息作匹配來進行認證的。
但鑑於HTTP是無狀態協議，以前已認證成功的用戶狀態沒法經過協議層面保存下來。即，沒法實現狀態管理，所以即便當該用戶下一次繼續訪問，也沒法區分他與其餘的用戶。因而咱們會使用Cookie在管理Session，以彌補HTTP協議中不存在的狀態管理功能。

• 步驟1：客戶端把用戶ID和密碼等登陸信息放入報文的實體部分，一般是以POST方法把請求發送給服務器。而這時，會使用HTTPS通訊來進行HTML表單畫面的顯示和用戶輸入數據的發送。

• 步驟2：服務器會發送用以識別用戶的Session ID。經過驗證從客戶端發送過來的登陸信息進行身份認證，而後把用戶的認證狀態與Session ID綁定後記錄在服務器端。
  向客戶端返回響應時，會在首部字段Set-Cookie內寫入Session ID（如PHPSESSID=028a8c···）。
  你能夠把Session ID想象成一種用以區分不用用戶的等位號。然而，若是Session ID被第三方盜走，對方就能夠假裝成你的身份進行惡意操做了。所以必須防止Session ID被盜，或被猜出。爲了作到這點，Session ID應使用難以推測的字符串，且服務器端也須要進行有效的管理，保證其安全性。
  另外，爲減輕跨站腳本攻擊（XSS）形成的損失，建議事先將Cookie內加上httponly屬性。

• 步驟3：客戶單接受從服務器端發來的Session ID後，會將其做爲Cookie保存在本地。下次向服務器發送請求時，瀏覽器會自動發送Cookie，因此Session ID也隨之發送到服務器。服務器可經過驗證接收到的Session ID識別用戶和其認證狀態。

除了以上介紹的應用實例，還有應用其餘不一樣方法的案例。 另外，不只基於表單認證的登陸信息及認證過程都無錶轉化的方法，服務器端應如何保存用戶提交的密碼等登陸信息等也沒有標準化。 一般，一種安全的保存方法是，先利用給密碼加鹽（salt）的方式增長額外信息，在使用散列（hash）函數計算出散列值後保存。可是咱們也常常看到直接保存明文密碼的作法，而這樣的作法具備致使密碼泄漏的風險。