今天，有個入行不太長時間的前端工程師朋友，問我什麼是什麼是Cookie，我當時很驚訝，作為一個前端工程師不能連Cookie都懂呀。考慮到，現在很多前端工程師、JAVA工程師等都不一定是科班出身，而培訓機構老師只講業務程式碼，或者說在大學學習的內容與生產實際存在一定的差距，這也沒有辦法，當前國情是這樣的，為了讓更多的後來者獲得一些業務程式碼之外的知識，嘗試著寫一個系列，獻給更多的後來者。

我們從以下幾點切入，如果明白了就掠過，方便快速閱讀:

1.HTTP協議
我們知道，HTTP協議是一種不是常連線的協議，可以設想這樣一個情景，伺服器(Server)需要對多個發起請求的客戶端(Client)進行服務，而這種請求是一種請求資料，傳送完畢就可以結束了的情景，如果長時間連線，反而沒有什麼作用，同時，又會消耗很多的系統資源，而對於伺服器來講，這樣的客戶端越多，系統資源開銷也越大，伺服器就越可能不穩定。所以，在HTTP 1.1版本中(如果我沒記錯的話)，將HTTP協議從常連線改為傳送完資料，立即斷開的機制。
2.Cookies

這裡面我用了一個複數，Cookies代表有很多的Cookie，因為你的瀏覽器中記錄的Cookie確確實實有很多。
剛剛我們說過，HTTP協議不是常連線協議，對於常連線協議來講，當然，HTTP協議是基於TCP協議的，直接往建立握手的資料流中寫入資料就可以實現雙向通訊了，很EZ.
但是，不是常連線協議(發完資料，立即斷開)如何來判定訪問者的身份？
這時候，Cookie就排上用場了。
設想這樣一個場景：
使用者C訪問網站S，進入登入頁面，輸入賬戶和密碼後就可以訪問S網站中的內容了，S網站也知道這就是使用者C，而不是使用者B，這種情景，就是Cookie來實現的。
當用戶C輸入使用者名稱、密碼訪問完網站S後，網站S向用戶C的瀏覽器中寫入一個唯一的字串(當然，Cookie就是一個字串)，這個字串是一個Key-Value的形式，什麼是Key-Value呢？周所周知的JSON結構就是一種K-V對形式。

user=wotchin
LoginTime=2017-7-13
……

這種一一對應的結構就是Key-Value結構，就相當於C語言中的陣列中的陣列下標改成了一個字串，不用數字來表示了而已。
那麼，下次，當C使用者訪問S網站的時候，S使用者獲取user欄位，發現是wotchin，網站S認為，很好，在我的網站資料庫中，能夠檢索到wotchin這個內容，就會認為我就是wotchin。
當然，實際不可能是這麼簡單，不然，我隨便改一個user豈不是想變成誰就變成誰了，這個Cookie的內容往往都是加密的，而明文儲存的Cookie往往都是一些無關緊要的內容，譬如登陸時間balabal..
3.Session

剛剛我們講到了Cookie，現在我們說說Session，注意，敲黑板劃重點了，如果你準備入職，但是不知道Session，你要注意聽了，這是面試的重點。
Cookie是儲存在本地的，Session是儲存在伺服器的，他們的本質功能都是相同的，都是為了表明客戶的身份。
那麼問題來了，如果只有伺服器儲存了一個Session，是不是本地的客戶機的瀏覽器就可以不去儲存Cookie了呢？當然不是，如果只有伺服器儲存Session，客戶端不儲存Cookie，伺服器仍然不知道你是誰啊。
那麼Session還有什麼用呢？
問得很好，你注意觀看剛剛說到的Cookie，上面我們說到了，網站從瀏覽器中取回Cookie的鍵值，然後去資料庫中比對是否存在這樣一條記錄。那麼Session的出現就很好解釋了，Session代替了資料庫的功能，提供了一種臨時的資料儲存，用Session的好處是網站後端程式猿可以省不少事情，不用去設計資料庫，不用寫SQL語句去查詢資料庫了，省了好多行程式碼，可以節約時間陪老婆了。
Session儲存在哪？存在伺服器上的Session專有的目錄下。
Session會不會存太多了造成伺服器存不下了？有這個可能，不過Session的壽命很短，對於Java伺服器來講，一般是25-30分鐘，PHP一般是20-30分鐘，到期就自動清除，所以，如果不是存的太多太多，一般不至於存不下。
Session會不會造成效能問題？當然會！！
Session畢竟是一種快取在硬碟上的儲存方式，而且不像關係型資料庫那樣，有比較高效的資料結構(咳咳，一般是B+樹、B-樹的索引)和搜尋演算法，畢竟是業餘選手，儲存得多了，必然會造成效能問題，所以說Session的使用情景是臨時的、少量的、不是那種高併發、高流量的情景。
對於大型的高可用、HA的網站，一般都用Cookie和資料庫搭配使用，Session使用的情景應該慎重考慮。