我們首先了解以下前提知識：
http是一種無狀態性的協議。
我們無法僅從http層瞭解到某個請求是源自於哪一個用戶。
結合到實例裏：
假如我們在瀏覽器裏登錄一個系統，點擊登錄，網站友好的提示：登陸成功。
那麼我們進行下一個操作，比如，點擊打開個人中心，服務器懵了，究竟應該打開誰的個人中心呢？
剛纔我們確實登錄了系統，可是這次我們是發送了另外一個http請求，僅從http層，服務器無法判斷，前面的登錄請求和這裏的打開個人中心請求，是否來自同一個瀏覽器窗口。
cookie是用來辨識客戶端的一種方式，Session是另一種。
一個簡單的例子：
- 當用戶登錄時，我們可以將用戶名及密碼存在cookie裏，用戶在該頁面再次操作時，該頁面存放的cookie將隨着URL請求發送到服務器，服務器得到用戶名和密碼，就能得到該http請求的用戶信息。
cookie遇到了問題：
- cookie不僅可以存放用戶的登錄信息，還可以存放用戶的其他信息，存放的信息較多的時候，每個URL請求都攜帶了一個巨大的cookie，給服務器帶寬帶來了很大的壓力。
我們有了解決辦法：
解決辦法就是session。
爲什麼一定要用用戶名和密碼來判斷用戶呢？
對的，當一個用戶登錄成功之後，我們可以在服務器生成一個特殊的ID（比如我們可以把用戶名和時間戳加一起進行MD5），然後把該ID返回給客戶端，客戶端放在cookie裏，服務器本地也保存一份，接下來，用戶再次向服務器發送請求的時候，cookie裏就只有這個ID，服務器拿到這個ID，就知道了是哪一個用戶發送的請求了。
好像還有點問題沒有解決：
我們現在通過session可以知道用戶是誰了，可是原來保存在cookie裏的其他信息怎麼辦？
我們可以在服務器上給用戶一點儲存空間。
我們把原來要保存在cookie裏的信息全部放在服務器上。比如說，我們創建一個user文件夾，裏面再按session的ID創建一些文件夾，每個文件夾裏面放用戶原來要保存的信息（這裏只是爲了形象，具體實現不是這麼做的）。
這樣，用戶拿着他的sessionID，就能在服務器上找到他的”cookie”。
還有更多的問題：
session好像完美解決了cookie的弱點，那他有什麼缺點呢？
現在的大型網站都是分佈式服務器，session如何在多服務器之間傳遞？如何處理大量session碎片給服務器帶來的負荷？
在這些問題下，cookie好像又成了最佳的解決方案，所以還是應了那句話：沒有最好的編程語言，只有最會運用的程序設計人員。