1. 服務端只創建 cookie字符值：
客戶端向服務端發送請求，建立連接。服務端創建 cookie字符值，作爲響應頭返回。
注意：如果客戶端是瀏覽器，會自動存儲這個 Set-Cookie 的值到 瀏覽器的session 中。如果是腳本，可以手動將該 cookie 保存起來（保存位置可能是session、硬盤或其他位置）。也可以將 cookie通過響應頭再次轉發出去。
2. 客戶端（腳本）發送請求，獲取 cookie，並維持一個 session中：
由於腳本的 session中，通過類似 session_id的東西 將 session 共享。當腳本發送的請求返回一個攜帶 set-cookie 的響應時，即將此 set-cookie 中的數據加載到 腳本的 session 中。
那麼每次發送請求時，都可以攜帶此 cookie。（注意：session 是內存的一個區域，並不表示 內存就是 session）
3. 另一種解決方案。客戶端（腳本）發送請求，獲取 cookie，手動存儲到內存、本地硬盤或數據庫中：
腳本獲取 攜帶 set-cookie 的響應， 手動將 cookie保存到內存、硬盤或數據庫中。這樣每次發送請求時，需手動獲取 cookie並放置該 cookie 到此請求的 request header 中。
PS：瀏覽器其實也是維持一個 “智能” session，這個 session 姑且叫它本地 session（或者說是瀏覽器的 session）。當收到 攜帶 set-cookie 的響應頭時，瀏覽器會自動將該 cookie 保存到本地 session 中。不同的 cookie根據域名的不同存到不同的 本地 session中。
當你再次發送請求時，會自動攜帶該域名下的 本地session。當關閉瀏覽器時，該 本地 session也關閉。
此外，如果 set-cookie設置了過期時間，那麼當 本地 session關閉時，可能還會將此 cookie 自動保存到硬盤中。當瀏覽器重新開啓時，會自動 load硬盤中保存的 cookie。
PS：這就跟 數據庫中的 session 一樣。從數據庫中獲取到值，並緩存到 session中。以便下次獲取，而不用每次都從硬盤上讀取。瀏覽器中的 session 是這個原理，服務端的 session也是這個原理。