Cookie 的誕生
若先從一個最為陽春的網路溝通方式來看，當一個 Client 端和一個 Server 端發送請求，並由 Server 端處理後進行響應，這一整個過程會因為 http 的無狀態特性，不著痕跡也不留紀錄。問題在於，多數時候留些有用的東西比較好。
假設今天我們透過帳號密碼登入，進到了某個平台服務的會員個人頁面，而這些會員頁面如果沒有登入是無法訪問到的。換句話說，如果在過程中什麼都沒存的話，勢必每一次訪問不同的會員頁面，都需要輸入一次帳號密碼來驗證身分，那想必十分破壞用戶體驗。
Cookie 的概念正是為了要解決這問題而誕生的，在 Client 端第一次發送請求至 Server 端時，Server 端在處理過程中便生成一個標示，也就是 Cookie。這 Cookie 中存了些需要的資料，並且包裝好連同響應一起回覆給 Client 端，讓他在下次發送請求時，可以不用重複麻煩的輸入流程，就可以發送帶有必備資料的請求。
而這些存在於 Client 端的 Cookie 也是會有期限的，若無特別設置的話，Cookie 會在 Client 端瀏覽器被關閉的時刻慘遭清除。若特別去設定，則可以使其持久化，在 Golang 中可以這麼設定他：
避免鬼打牆，我先表明有 import "time" 和 "net/http" 兩個包~！line 3 的部分我設定期限為三天後，line 4 描述了 Cookie 中所需內容，並在 line 5 完成 Cookie 的設置。
Session 的誕生
Cookie 的出現固然解決了大半問題，但仍有些缺陷，比如說她是個存在於客戶端的文件資料，很容易在 Client 端被拿來動手腳的。再者，Cookie 中若包含著機密的資料像是帳號密碼等等，每次發送請求都跟著出去一次，那被攔截或竊聽的風險可就大大提高了。因此便有了 Session 誕生的理由。
同樣是在 Client 端與 Server 端進行首次溝通 hand shaking 時，Server 端生成了一個 Session，可以把它視為一種維持兩端溝通的方案，並存於 Server 端。同時會生成一把與 Session 相對應的鑰匙，也就是 session id，並隨著響應回復至 Client 端。
Session 建立完成後，接下來的溝通 Client 端發送請求時便會帶上這串 session id，送達 Server 端時便會開始查找對應的 Session 以繼續進行溝通。此方法雖可有效提高安全性，但是當多個 Session 囤積在 Server 端時光是想就覺得不對勁，所以仍是要做出適當的抉擇。
使用 Session 就一定可靠嗎？
想想 Cookie 的問題出在哪裡，便可以知道 Session 也有同樣問題，只是不那麼明顯。對於儲存資料的 Cookie ，一旦被有心人士取得其中資料便會發生問題，而 Session id 同理，只不過要再帶上他發送請求給 Server 端進行類似盜用詐欺的行為而已。Session 仍是有風險存在的，那該怎麼辦？
Cookieonly
其中一個方法便是強制 Session id 僅能由 Cookie 在發送請求時帶上，而無法透過 url 引數的方式帶上。同時降 Cookie 設置為 httponly，使其僅能在 http 溝通時被訪問，避免被從其他管道惡意讀取。
Token
另外也可以在每次 Client 端發送請求時，附上一組隨機生成的 Token，並在 Server 端進行重複性驗證，以確保請求的唯一性。
Refresh Session id
每隔一段時間就重新生成一組 Session id 也是個可能的方法，如此ㄧ來便會提高第三方竊取的成本，並增加捕捉到惡意行為的機會。
Ref
https://github.com/astaxie/build-web-application-with-golang
