https的主要缺點是需要設定連線，每次新的tls連續都需要握手，以便建立共享的加密金鑰，這個握手過程在標準tcp的握手過程之上還需要兩個額外的來回過程，用這樣乙個高延時的連線，在**第乙個位元組傳輸之前需要三個來回就讓人感覺這個**有點慢。
tls有幾個特徵可以用來消除額外的來回，比如重用乙個會話session，兩個標準會話重用機制是 session ids (rfc 5246) 和 session tickets (rfc 5077)，使用其中乙個技術，乙個客戶端可以重用之前建立的會話，這個會話是之前和伺服器進行握手成功的，這樣可以減少一次來回過程。
基於sessionid的會話重用適合現代所有瀏覽器，firefox和chrome還支援 session tickets，伺服器端的支援也廣泛使用，nginx, apache, haproxy, iis等等都支援session id 和session ticket。
重用乙個加密的會話是很容易，前提是客戶端和伺服器端都儲存了會話key，通過每個連線給出的唯一標識，伺服器知道乙個進來的連線是否已經在之前建立過，如果伺服器在會話中也已經有會話key，它就能重用。
session id需要伺服器儲存會話狀態如會話key等，這樣下次連線才能復用，這就需要伺服器儲存很多狀態資訊，耗費了大量記憶體。
session id共享復用在apache中可以通過sslsessioncache 配置，在nginx可以通過ssl_session_cache設定。
在會話ticket復用中，伺服器不用為每個session儲存狀態，它用乙個blob資料儲存狀態，然後將它發給客戶端用來維護後來連線，會話ticket允許伺服器將其儲存狀態委託給客戶端，類似http cookie一樣。
乙個會話ticket是乙個加密的資料blob，其中包含需要重用的tls連線資訊，如會話key等，它一般是使用ticket key加密，因為ticket key伺服器端也知道，在初始握手中伺服器傳送乙個會話ticket到客戶端，儲存到客戶端本地，當重用會話時，客戶端傳送會話ticket到伺服器，伺服器解密然後重用會話。
會話ticket有潛在的安全問題，一些tls加密元件如ecdhe-rsa-aes128-sha256提供乙個安全屬性成為向前安全forward secrecy，如果黑客獲得了伺服器的證書私鑰，他們也不能獲得會話來破解。
使用tls 會話ticket，偷竊了ticket key1後不會允許黑客來解密先前的會話，這是的ticket key非常有價值，為了保持向前安全forward secrecy, ticket key應該經常輪換。
使用負載平衡器時，這些復用技術會遇到挑戰，對於乙個伺服器復用乙個連線，它需要先前會話的key，如果先前會話在其他伺服器上，新的伺服器必須得到原來會話的key。
這個問題被cloudflare 和 twitter使用系統產生乙個集中統一的key來解決，ticket key被乙個集中的統一的伺服器定期建立，安全地發給所有伺服器，實現會話ticket共享需要你的架構有乙個定製系統的抉擇。
降低建立乙個連線的來回過程使得**載入速度提高，對於使用https的**，會話儲存可以用於提高連線建立的速度，而正確的實現方式，才能讓頁面載入時間更漂亮的縮短，特別是在有負載平衡的場合 。
Session提高requests的抓取速度小技巧
使用requests抓取資料的時候，爬蟲會模擬瀏覽器的行為，但是可能不知道，當開啟乙個網頁的時候，requests.get 可能速度很快，但是如果幾十個上百個 的時候呢，這個差距就出來了，例如下面。import requests import time start time.time for in ...
http請求的session管理
常見的session保持方式是，當瀏覽器向服務端發起http請求時，服務端檢查在http頭部cookie引數裡是否包含sessionid，如果有sessionid就根據sessionid去檢視儲存在伺服器端的session，session裡儲存的當前會話的一些資訊。如果sessionid沒有服務端就...
http基礎 cookie和session的區別
1.cookie 是一種傳送到客戶瀏覽器的文字串控制代碼，並儲存在客戶機硬碟上，可以用來在某個web站點會話間持久的保持資料。session其實指的就是訪問者從到達某個特定主頁到離開為止的那段時間。session其實是利用cookie進行資訊處理的，當使用者首先進行了請求後，服務端就在使用者瀏覽器上...