今天在測試時發現http和https效能差距明顯(nginx)，個人在POSTMAN測試後發現的現象：
1 http第一次訪問比較慢
2 https第一次訪問會比較慢
3 http 和https存在非常明顯的差異，http和https第一訪問用時效能差距十分明顯，但第二次訪問用時差距不大了。
雖然伺服器在牆外，但這個速度還是無法接受，整理了下需要回答這三個問題所需要用到的知識，關於更專業的tcp http https知識以後再整理成文章。

1 HTTP和HTTPS

1.1 HTTP

HTTP屬於應用層協議，在傳輸層使用TCP協議，在網路層使用IP協議。HTTP協議是無狀態的，開啟一個伺服器上的網頁和上一次開啟這個伺服器上的網頁之間沒有任何聯絡，但HTTP是一個無狀態的面向連線（傳輸層為tcp協議）的協議。
HTTP = TCP 握手+ http傳送資料

1.2 HTTPS

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層（傳輸過程加密 雙匙加密），HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
HTTPS= TCP握手 + SSL握手 + http傳送資料
第一次測試：1258ms 第二次625ms

1.3 TCP握手

http和https 傳輸層均為TCP，所以在正式傳輸資料前，TCP都會三次握手建立連結

2 http長連線和短連線

2.1 HTTP短連線

在HTTP/1.0中預設使用短連線。也就是說，客戶端和伺服器每進行一次HTTP操作，就建立一次連線，任務結束就中斷連線。每遇到一個Web資源，瀏覽器就會重新建立一個HTTP會話。
流程：建立連線-傳輸資料-斷開連線 ………. 建立連線-傳輸資料-斷開連線

2.2 HTTP長連線

從HTTP/1.1起，預設使用長連線，用以保持連線特性。使用長連線的HTTP協議，會在響應頭加入這行程式碼：

Connection:keep-alive

在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如nginx）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。
流程：建立連線-傳輸資料- 保持連線 -傳輸資料- 斷開連線

從本質上來講，HTTP僅僅是應用層的協議，TCP才是真正的傳輸層協議，因此TCP才有真正的長連線短連線的說法。

2.3 TCP層長連線與短連線

2.3.1 TCP短連線

TCP短連線的流程：client向server發起連線請求，server接到請求，然後雙方建立連線。client向server傳送訊息，server迴應client，請求完成，這時候雙方任意都可以發起close操作，不過一般都是client先發起close操作。上述可知，短連線一般只會在 client/server間傳遞一次請求操作。

2.3.2 TCP長連線

TCP長連線的流程：client向server發起連線，server接受client連線，雙方建立連線，client與server完成一次請求後，它們之間的連線並不會主動關閉，後續的讀寫操作會繼續使用這個連線。

TCP的保活功能主要為伺服器應用提供。如果客戶端已經消失而連線未斷開，則會使得伺服器上保留一個半開放的連線，而伺服器又在等待來自客戶端的資料，此時伺服器將永遠等待客戶端的資料。保活功能就是試圖在服務端器端檢測到這種半開放的連線。

在HTTP/1.0中預設使用短連線。也就是說，客戶端和伺服器每進行一次HTTP操作，就建立一次連線，任務結束就中斷連線。

3 結論

1 http第一次訪問比較慢
因為HTTP是建立在TCP上，TCP握手會佔用一定時間，而之後因為nginx設定，即該連結並沒有被關閉（http長連線）
一定時間內訪問不用握手。

2 https第一次訪問會比較慢
原理同上，但建立連結時應該加上SSL握手時間。

3 http 和https存在非常明顯的差異，http和https第一訪問用時效能差距十分明顯，但第二次訪問用時差距不大了。
第一次差距明顯的原因是SSL握手較為耗時，而第二次訪問時間均下降並相差不多的原因是因為保持了Http長連線均未再次握手，所以差距不大。nginx 對ssl握手後的狀態用session ID 進行了快取，https訪問不會差異較大。

4 如何優化http用時

4.1 nginx 配置長連線引數

http {
　　keepalive_timeout 20; --長連線timeout
        keepalive_requests 8192; --每個連線最大請求數
}

4.2 https 握手時間優化

https握手非常耗時的原始在：RSA演算法，它對效能的影響佔了75%左右。
以上文章提出的優化策略：
1 首先第一步也是最簡單的一個優化策略，就是減少完全握手的發生，因為完全握手它非常消耗時間；
2 對於不能減少的完全握手，對於必須要發生的完全握手，對於需要直接消耗CPU進行的握手，我們使用代理計算；
3 對稱加密的優化；

4.3 websocket帶來的優勢

HTTP1.1帶來了長連線，不用每一次都重新三次握手建立連線，省略了握手的浪費，但是長連線裡每一次請求仍然會發送重複http頭造成資源浪費，這裡就有一個WebSocket協議用來解決這種需要頻繁傳輸資料的情況。

5 參考連結