一、客戶端識別
每天都有數以億計的客戶端與Web服務器通信，服務器是怎麼知道它在和誰對話呢？
- 承載用戶身份信息的HTTP首部
- 客戶端 IP，通過用戶的 IP 地址對其進行識別
- 用戶登錄，用認證的方式識別用戶
- 胖 URL，在 URL 中嵌入識別信息的技術
- cookie
承載用戶信息的首部有 From(用戶的E-mail地址)、Authorization、Client-IP、Cookie。
以 From 爲例，每個用戶都有不同的郵箱地址，按理來說是可以標識用戶的，但爲什麼不用呢？
Web 服務器並不都是善意的，有些惡意服務器會收集這些郵箱，然後發送令人厭惡的廣告，另外也是不安全的。
然後是客戶端 IP 也就是 Client-IP 首部，這個很容易想到，一個 IP 只能代表一個客戶端，不能代表用戶。
再然後就是用戶登錄，也就是 Authorization 首部，這裏詳細說一下：
當用戶訪問一個資源時，比如個人信息，這時服務器就會要求用戶登錄，輸入用戶名和密碼等信息。
只要用戶輸入了用戶名和密碼，瀏覽器就會重複原請求，並添加 Authorization 首部，值爲用戶名和密碼的 Base64 加密。
今後的請求要登錄時，瀏覽器就會把 Authorization 首部及其值發送出去。甚至沒要求登錄時也會發送出去。
以上談到 Authorization 的值爲 Base64 加密，該加密是可逆的，所以並不安全。
什麼是胖 URL 呢？舉個例子吧：
<a href="/exec/obidos/tg/browse/-/229220/ref=gr_gifts/002-114565-8016838">All Gifts</a>
比如上面的 002-114565-8016838 就是一個標識碼，每個用戶訪問都不同。這就被稱爲胖 URL。
這種方式有很明顯的缺點：醜陋、該 URL 不可以共享，否則將會泄漏個人信息、沒有公共的緩存、服務器要重寫 HTML增加負荷......
二、Cookie
好啦，下面重點來了，cookie 是當前識別用戶並實現持久會話的最好方式，我們來介紹一下它：
可以籠統的將 cookie 分爲兩類：會話 cookie 和 持久 cookie。
會話 cookie 是一種臨時 cookie，用戶退出瀏覽器時，會話 cookie 就被刪除了。
持久 cookie 存儲在硬盤上，瀏覽器退出，計算機重啓時它仍在，不過它有一個過期時間。
如果設置了 Discard 參數，或者沒有設置 Expires 或 Max-Age 參數來說明擴展的過期時間，這個 cookie 就是會話 cookie。
同胖 URL 思路一樣，也是給訪問的用戶打上一個標籤。cookie 中包含了一個由 name=value 這樣信息構成的任意列表。
並通過 Set-Cookie 或 Set-Coookie2 HTTP響應(擴展)首部將其貼到用戶身上去。
以 Google 瀏覽器爲例：
| Name | cookie 的名字 |
| Value | cookie 的值 |
| Domain | cookie 的域，那些站點可以看到 cookie |
| Path | 域中與 Cookie 相關的路徑前綴，那些域前綴可以看到 cookie |
| Expires/Max-Age | Expires 是過期日期，Max-Age 是過期剩餘秒數 |
| Size | 此 cookie 的大小，不知道怎麼算的哈 |
| HttpOnly | 是否 js 腳本可以讀取該 cookie |
| Secure | 是否只有在使用 SSL 連接時才發送這個 cookie |
| SameSite | 用來防止 CSRF 攻擊和用戶追蹤 |
| Priority | cookie 的優先級，當 cookie 數量超出時，優先級最低的會被刪掉 |
以上屬性需要詳細解釋一下的就是 Domain 和 Path:
瀏覽器內部的 cookie 罐中可以有成百上千個 cookie，但瀏覽器不會將每個 cookie 都發送給所有的站點。
總之，瀏覽器只向服務器發送服務器產生的那些 cookie。
1、Domain 屬性
比如下面這個HTTP響應首部就是告訴瀏覽器將 cookie user="mary17" 發送給域 “.airtravelbargains.com” 中的所有站點。
Set-cookie: user="mary17"; domain="airtravelbargains.com"
如果用戶訪問的是 www.airtravelbargains.com、specials.airtravelbargains.com 或任意以 .airtravelbargains.com 結尾的結點，
Cookie: user="mary17" 都會被髮布出去。
2、Path 屬性
例如，某個 Web 服務器可能是兩個組織共享的，每個組織都有獨立的 cookie。
Set-cookie: pref=compact; domain="airtravelbargains.com"; path="/autos/"
如果用戶訪問 http://www.airtravelbargains.com/specials.html，就只會獲得這個 cookie: Cookie: user="mary17"
如果用戶訪問 http://www.airtravelbargains.com/autos/cheapo/index.html，就會獲得兩個 cookie：
Cookie: user="mary17"
Cooke: pref="compact"
3、Cookie 有兩個版本：Set-cookie、Set-cookie2，區別就是首部的 Name 不同，還有就是後者屬性更多一些。
三、安全 HTTP
HTTPS 是最流行的 HTTP 安全形式，HTTPS 的 URL 是以 https://，而不是 http:// 開頭。
使用 HTTPS 時，所有的 HTTP 請求和響應數據在發送到網絡之前，都要進行加密。
HTTPS 在 HTTP 下面提供了一個傳輸級的密碼安全層，可以使用 SSL，也可以使用 TLS(TLS 是 SSL 的升級版)。
大部分困難的編碼以及解碼工作都是在安全層完成的，所以 Web 客戶端和服務器無需過多的修改其協議處理邏輯。
四、密碼
任意兩人之間要進行私密通信，都需要一個只有彼此才能理解的語言。
比如循環移位(n) 編碼器：
// 密鑰=1，右移1位
明文：Meet me at the pier at midnight。
密文：nffu nf bu uif qjfs bu njeojhiu。
// 密鑰=2，右移2位
明文：Meet me at the pier at midnight。
密文：oggv og cv vig rkgt cv okfpkijv。
// 密鑰=3，右移3位
明文：Meet me at the pier at midnight。
密文：phhw ph dw wkh slhu dw plgqlijkw。
給定一段明文報文 P、一個編碼函數 E 和一個數字編碼密鑰 e，就可以生成一段經過編碼的密文 C。
通過解碼函數 D 和解碼密鑰 d，就可以將密文 C 解碼爲原始的明文 P。
1、對稱密鑰加密技術
對稱密鑰加密技術是指，編碼時和解碼時的密鑰時一樣的，常見的有 DES、RC2、RC4。
缺點：如果很多人要和 web 站點通信，那每個人和 web 站點都要建立一個私有密鑰，數量將是很龐大的。
2、公開密鑰加密技術
公開密鑰加密技術沒有爲每對主機使用單獨的加密/解密密鑰，而是使用了兩個非對稱密鑰，常見的有 RSA。
一個用來對主機報文編碼，一個用來對主機報文解碼。編碼密鑰是衆所周知的，但是隻有主機才知道私有的解密密鑰。
五、數字簽名
數字簽名是附加在報文上特殊加密效驗，用來說明是誰編寫的報文，同時證明報文未被篡改過。
數字簽名通常是用非對稱公開密鑰技術產生的。因爲只有所有者才知道其私有密鑰，所有可以將作者的私有密鑰當作一種指紋使用。
六、數字證書
典型的數字證書如下格式：
證書版本號 -----------------------|
證書序列號 -----------------------|
證書籤名算法 --------------------|
證書頒發者 ---------------------------》 數字簽名函數
有效期 -----------------------------| |
對象名稱 --------------------------| |
對象公開密鑰 --------------------| |
其他擴展信息 --------------------| |
數字簽名 《---------------------------------------|
通過 HTTPS 建立了一個安全 Web 事務後，現代瀏覽器都會自動獲取所連接服務器的數字證書。
如果服務器沒有證書，安全連接就會失敗。
七、HTTPS 細節介紹
HTTPS 就是在安全的傳輸層上發送的 HTTP，安全層是通過 SSL 或其替代協議 TLS 來實現的。
URL 爲 http 開頭的，默認情況下客戶端會打開一條到服務器 80 端口的連接。
URL 爲 https 開頭的，默認情況下客戶端會打開一條到服務器 443 端口的連接。
如果沒有安全層，HTTP 的傳輸時非常簡單的，在建立連接後，發送一條請求報文，接收一條響應報文，最後關閉連接就完事了。
因爲有了安全層，建立連接後，客戶端和服務器就會初始化 SSL\TSL 層，對加密參數進行溝通，互換密鑰。
SSL握手完成後，SSL 初始化就完成了，客戶端就可以把請求報文發送給安全層了，在將這些報文發送給 TCP 之前，要對其進行加密。
SSL握手的過程：1、交換協議版本號，2、選擇一個兩端都瞭解的密碼，3、對兩端身份進行認證，4、生成臨時會話密鑰，加密信道。
SSL 支持雙向認證，將服務器證書承載回客戶端，再將客戶端證書回送給服務器。
但是瀏覽時並不經常使用客戶端證書，大部分用戶甚至都沒有自己的客戶端證書，但是安全 HTTPS 事務總是要求使用服務器證書的。