1. 由來
long long ago……，在以前瀏覽器只是用來查看文檔的，并沒有其它增刪改的之類的操作。后來萬惡的產品經理提出了各種奇葩的需求，為了解決產品經理的特殊需求，引入了cookie和session的概念，用來保存HTTP的請求狀態。
（PS：比如你增加一個東西，我可以記錄cookie或session。你刪除一個東西我也可以刪除一個cookie或者session。而cookie是存儲在你本地，session是存儲在服務器上的）
2. 奇葩需求
用戶所做的操作配置，換了另外一臺電腦能繼續使用原來的配置
3. 方案一
把用戶的所有配置信息都存儲在cookie里，用戶在換電腦后，重新復制以前的cookie到現在電腦上的瀏覽器里。
4. 發現問題
第一種方案雖然也可行，但是數據存在用戶這里太多了，容易丟，或者被篡改，而且操作也很麻煩，用戶體驗不友好。
5. 方案二
把用戶配置信息存儲到服務器上，生成一個唯一ID（sessionID）給用戶，用戶下次使用這個唯一ID可以直接來服務器上拿數據。
6. 發現問題
然后你可能就會發現了，其實其他人也是可以拿這個唯一的ID進行冒充。比如你在取錢的路上，被劫匪打劫了銀行卡，順便還劫了個色。然后拿著你的銀行卡就可以取錢了，不管是不是你本人。
7. 解決問題
所以為了保護你在取錢的路上不被打劫，所以銀行（服務器）需要一隊武裝部隊進行護送你（HTTPS），銀行要配備武裝部隊，你需要去服務商那拿個個證書（不要以為可以免費請到武裝部隊，所以還是資金的問題），但是這個問題被摒棄了。
8. 最終方案
目前先使用方案二，因為幫別人保管，比讓用戶保管好的多。傳輸一個cookie給服務器上，獲取session信息。比傳輸多個cookie好的多。
9. 行動需求
session保證唯一。（我不管你怎么實現，反正你給我保證唯一就行）
10. 存儲方案
前期需求，先存儲在內存，省時省力，還不需要另外花錢買配置。二次開發后，在考慮存儲在數據庫，緩存之類的，反正到時候在說，萬一還沒上線就死了呢。
11. 安全需求
前期項目人員緊缺，資金匱乏，咱們先怎么簡單怎么來，那就明文傳輸吧。（所以這就是這么多坑的原因了？程序猿：“這鍋我不背”）
12. 實行方案
- 瀏覽器第一次請求網站， 服務端生成 Session ID。
- 把生成的 Session ID 保存到服務端存儲中。
- 把生成的 Session ID 返回給瀏覽器，通過 set-cookie。
- 瀏覽器收到 Session ID， 在下一次發送請求時就會帶上這個 Session ID。
- 服務端收到瀏覽器發來的 Session ID，從 Session 存儲中找到用戶狀態數據，會話建立。
- 此后的請求都會交換這個 Session ID，進行有狀態的會話。
（復制的，懶得寫了，反正意思就是，你想要工資，就帶上你的身份證過來我這，我接過從你手（cookie）里面給我的身份證（sessionID），我從文檔庫（服務器）里找到你的員工資料（session信息），然后在給你工資。沒有你員工信息的話，你可以考慮先入個職啥的，給你辦個身份證，然后下次就可以過來拿工資，咋樣考慮下唄）
13. 項目總結
不管是存儲在cookie里，還是存儲在session里，都可以實現需求，但是具體使用哪種實現就看需求了。但是使用方案二的session的時候會依賴與瀏覽器的cookie
14. cookie和session的區別
- cookie是存儲在本地的，所以可以離線使用。而session是存儲在服務器的，安全更高些。
- cookie容易被篡改數據。而session在明文傳輸的時候容易被劫持唯一ID，冒充用戶。
- session依賴與cookie，而cookie不需要依賴與session。
學到了一個新詞，不吝斧正
