《圖解http》筆記

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

1、TCP/IP協議族按層次分別分為以下4層：

應用層： 應用層決定了向使用者提供應用服務時通訊的活動。例如：FTP（檔案傳輸協議）、DNS（域名系統）、http
傳輸層： 傳輸層對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸。協議：TCP（傳輸控制協議）、UDP（使用者資料包協議）
網路層（又名網路互聯層）： 網路層用來處理網路上流動的資料包。資料包是網路傳輸的最小資料單位。該層規定了通過怎樣的路徑（所謂的傳輸線路）到達對方計算機，並把資料包傳送給對方。
與對方計算機之間通過多臺計算機或玩過裝置進行傳輸時，網路層所起的作用就是在眾多的選項內選擇一條傳輸路線。協議： IP協議
鏈路層（又名資料鏈路層，網路介面層）：
用來處理連線網路的硬體部分。包括控制作業系統、硬體的設計驅動、NIC（網路介面卡，即網路卡），及光纖等物理可見部分（還包括聯結器等一切傳輸媒介）。硬體上的範疇均在鏈路層的作用範圍之內。

2、負責傳輸的IP協議

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

3、確保可靠性的TCP協議

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

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

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

5、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協議

1、報文組成：

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

2、HTTP是不儲存狀態的協議

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

3、告知伺服器意圖的HTTP方法

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

4、持久連線節省通訊量

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）方式傳送成為可能。從前傳送請求後需要等待並收到響應，才能傳送下一個請求。管線化技術出現後，不用等待響應亦可直接傳送下一個請求。這樣胖就能夠做到同時並行傳送多個請求，而不需要一個接一個的等待響應。

5、使用Cookie的狀態管理

不可否認，無狀態協議當然有他的有點。由於不必儲存狀態，自然可減少伺服器的CPU幾記憶體資源的消耗。從另一側面來說，也正是因為HTTP協議本身是非常簡單的，所以才會被應用在各種場景裡。
保留無狀態協議這個特徵的同事又要解決讓服務期管理全部客戶端狀態則會成為負擔的矛盾問題，於是引入了Cookie技術。Cookie結束通過在請求和響應報文中寫入Cookie資訊來控制客戶端的狀態。
Cookie會根據從伺服器端傳送的響應報文內的一個叫做Set-Cookie的首部欄位資訊，通知客戶端儲存Cookie。當下次客戶端再往該伺服器傳送請求時，客戶端會自動在請求報文中加入Cookie值後傳送出去。
伺服器端發現客戶端傳送過來的Cookie後，回去檢查究竟是從哪一個客戶端發來的連線請求，然後對比伺服器上的記錄，最後得到之前的狀態資訊。

第三章、HTTP報文內的HTTP資訊

1、HTTP報文

用於HTTP協議互動的資訊叫做HTTP報文。請求端（客戶端）的HTTP報文叫做請求報文，響應端（服務端）的叫做響應報文。HTTP報文字身由多行（用CR+LF做換行符）資料構成的字串文字。
HTTP報文大致可分為報文首部和報文主體兩塊。兩者由最初出現的空行來劃分。通常，並不一定要有報文主體

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

• 請求報文首部：請求行、請求首部欄位、通用首部欄位、實體首部欄位、其他

• 響應報文首部：狀態行、響應首部欄位、通用首部欄位、實體首部欄位、其他

首部組成：

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

• 狀態行：包含表明響應結果狀態碼，原因短語和HTTP版本

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

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

3、傳送多種資料的多部分物件集合

傳送郵件時，我們可以在郵件裡寫入文字並新增多分附件。這是因為採用了MIME（Multipurpose Internet Mail Extensions,多用途因特網郵件擴充套件）機制，它允許郵件處理文字、圖片、視訊等多個不同型別的資料。例如，圖片等二進位制資料以ASCII碼字串編碼的方式指明，就是利用MIME來標記資料型別。而在MIME擴充套件中會使用一種稱為多部分物件集合（Multipart）的方法，來容納多份不同型別的資料。
相應的，HTTP協議中也採納了多部分物件集合，傳送的一份報文主體內可含有多型別實體。通常是在圖片或文字檔案等上傳時使用。

多部分對應集合包含的物件如下。

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

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

1、2** 成功

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

• 200 OK 表示從客戶端發來的請求在伺服器端被正常處理了。 在響應報文內，隨狀態碼一起返回的資訊會因為方法的不同而發生改變。比如，使用GET方法時，對應請求資源的實體會作為響應返回；而使用HEAD方法時，對應請求資源的實體首部不隨報文主體作為響應返回（即在響應中只返回首部，不會返回實體的主體部分）

• 204 No Centent 該狀態碼代表伺服器接收的請求已成功處理，但在返回的響應報文中不包含實體的主體部分，另外，也不允許返回任何實體的主體。比如，當從瀏覽器發出請求處理後，返回204響應，那麼瀏覽器顯示的頁面不會發生更新。
  一般在只需要從客戶端往伺服器傳送資訊，而對客戶端不需要傳送資訊新內容的情況下使用。

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

2、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狀態碼是最理想的。

當301、302、303響應狀態碼返回時，幾乎所有的瀏覽器都會把POST改成GET，並刪除請求報文內的主體，之後請求會自動再次傳送。301、302標準是禁止將POST方法改成GET方法的，但實際會用時大家都這麼做。

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

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

3、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首部

1、HTTP報文首部

HTTP報文組成：報文首部、空行（CR+LF）、報文主體。
HTTP協議的請求和響應報文中必定包含HTTP首部。首部內容為客戶端和伺服器端分別處理請求和響應提供所需要的資訊。對於客戶端使用者來說，這些資訊中的大部分內容都無需親自檢視。
報文首部由幾個欄位構成。

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

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

2、4種HTTP首部欄位型別

HTTP首部欄位根據實際用途被分為以下四種型別

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

• 請求首部欄位（Request Header Fields） 從客戶端向伺服器端傳送請求報文時使用的首部。補充了請求的附加內容、客戶端資訊、響應內容相關優先順序等資訊。

• 響應首部欄位（Response Header Fields） 從伺服器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會使用客戶端附加額外的內容資訊。

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

第七章 確保Web安全的HTTPS

1、HTTP的缺點

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

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

由於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、無法證明報文完整性，可能已遭篡改

所謂完整性是指資訊的準確性。若無法證明其完整性，通常也就意味著無法判斷資訊是否準確。
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）函式計算出雜湊值後儲存。但是我們也經常看到直接儲存明文密碼的做法，而這樣的做法具有導致密碼洩漏的風險。