Http首次訪問較慢原因

2021-08-21 04:53:20 字數 2622 閱讀 3010

今天在測試時發現http和https效能差距明顯(nginx),個人在postman測試後發現的現象:

1 http第一次訪問比較慢

2 https第一次訪問會比較慢

3 http 和https存在非常明顯的差異,http和https第一訪問用時效能差距十分明顯,但第二次訪問用時差距不大了。

雖然伺服器在牆外,但這個速度還是無法接受,整理了下需要回答這三個問題所需要用到的知識,關於更專業的tcp http https知識以後再整理成文章。

2 http長連線和短連線

3 結論

4 如何優化http用時

5 參考鏈結

http屬於應用層協議,在傳輸層使用tcp協議,在網路層使用ip協議。http協議是無狀態的,開啟乙個伺服器上的網頁和上一次開啟這個伺服器上的網頁之間沒有任何聯絡,但http是乙個無狀態的面向連線(傳輸層為tcp協議)的協議。

http = tcp 握手+ http傳送資料

https(全稱:hyper text transfer protocol over secure socket layer),是以安全為目標的http通道,簡單講是http的安全版。即http下加入ssl層(傳輸過程加密 雙匙加密),https的安全基礎是ssl,因此加密的詳細內容就需要ssl。

https= tcp握手 + ssl握手 + http對稱加密 傳送資料

第一次測試:1258ms 第二次625ms

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

在http/1.0中預設使用短連線。也就是說,客戶端和伺服器每進行一次http操作,就建立一次連線,任務結束就中斷連線。每遇到乙個web資源,瀏覽器就會重新建立乙個http會話。

流程:建立連線-傳輸資料-斷開連線 ………. 建立連線-傳輸資料-斷開連線

從http/1.1起,預設使用長連線,用以保持連線特性。使用長連線的http協議,會在響應頭加入這行**:

connection:keep-alive
在使用長連線的情況下,當乙個網頁開啟完成後,客戶端和伺服器之間用於傳輸http資料的tcp連線不會關閉,客戶端再次訪問這個伺服器時,會繼續使用這一條已經建立的連線。keep-alive不會永久保持連線,它有乙個保持時間,可以在不同的伺服器軟體(如nginx)中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。

流程:建立連線-傳輸資料- 保持連線 -傳輸資料- 斷開連線

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

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

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

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

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

1 http第一次訪問比較慢

因為http是建立在tcp上,tcp握手會占用一定時間,而之後因為nginx設定,即該鏈結並沒有被關閉(http長連線)

一定時間內訪問不用握手。

2 https第一次訪問會比較慢

原理同上,但建立鏈結時應該加上ssl握手時間。

3 http 和https存在非常明顯的差異,http和https第一訪問用時效能差距十分明顯,但第二次訪問用時差距不大了。

第一次差距明顯的原因是ssl握手較為耗時,而第二次訪問時間均下降並相差不多的原因是因為保持了http長連線均未再次握手,所以差距不大。nginx 對ssl握手後的狀態用session id 進行了快取,https訪問不會差異較大。

http
關於https耗時有一篇非常好的文章可供參考:

https握手非常耗時的原始在:rsa演算法,它對效能的影響佔了75%左右。

以上文章提出的優化策略:

1 首先第一步也是最簡單的乙個優化策略,就是減少完全握手的發生,因為完全握手它非常消耗時間;

2 對於不能減少的完全握手,對於必須要發生的完全握手,對於需要直接消耗cpu進行的握手,我們使用**計算;

3 對稱加密的優化;

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

https耗時分析文章:

解決github訪問速度較慢的方案

本人在某日搜查資料的時候,發現訪問github的速度非常慢,但是自己又很想訪問。於是乎皮皮淇開始尋找一些方法來提高速度。通過查修改host檔案 用繞過dns解析,在本地直接繫結host 在本地host檔案中新增對映 路徑是在 c windows system32 drivers etc 1用note...

tomcat第一次訪問較慢

使用tomcat啟動ssm框架專案時,第一次訪問特別忙,之後訪問速度正常。可能是因為使用了dispatcherservlet但一開始沒有初始化。在進行訪問時才初始化。在web.xml的dispatcherservlet配置中加入load on startup springmvcservlet nam...

解決linux伺服器訪問較慢的問題

具體執行步驟 1 測試到伺服器某個埠的掉包率 2 檢視伺服器的dns位址是否配置正確 3 檢視伺服器網段的arp狀態 4 使用監控工具實時檢視伺服器流量是否正常 5 調整有關網路的核心引數,與正常伺服器做對比 proc sys目錄下 6 測試修改某引數後檢視系統是否有改進 檢視某一種協議包怎麼樣 a...