起因

是一個高并發(fā)的采集服務(wù)上線后，100m的上行很快就被打滿了。
因為這是一條專線，并且只有這一個服務(wù)在使用，所以可以確定就是它導(dǎo)致的。

但是！這個請求只是一個 GET 請求，同時并沒有很大的請求體，這是為什么呢？

于是使用 charles 重新抓包后發(fā)現(xiàn)，一個 request 的請求居然要占用 1.68kb 的大小!

其中TLS Handshake 就占了 1.27kb。

這種情況下，需要的上行帶寬就是：1.68*20000/1024*8=262.5mbps

也就說明100mbps的上行為何被輕松打滿

TLS Handshake是什么來頭，竟然如此大?

首先要知道HTTPS全稱是：HTTP over TLS，每次建立新的TCP連接通常需要進(jìn)行一次完整的TLS Handshake。在握手過程中，客戶端和服務(wù)器需要交換證書、公鑰、加密算法等信息，這些數(shù)據(jù)占用了較多的字節(jié)數(shù)。

TLS Handshake的內(nèi)容主要包括：

• 客戶端和服務(wù)器的隨機(jī)數(shù)

• 支持的加密算法和TLS版本信息

• 服務(wù)器的數(shù)字證書（包含公鑰）

• 用于生成對稱密鑰的“Pre-Master Secret”

這個過程不僅耗時，還會消耗帶寬和CPU資源。

因此想到最粗暴的解決方案也比較簡單，就是直接使用 HTTP，省去TLS Handshake的過程，那么自然就不會有 TLS 的傳輸了。

那么是否真的有效呢？驗證一下就知道。

將請求協(xié)議改成 http 后：

可以看到請求頭確實不包含 TLS Handshake了!

整個請求只有 0.4kb，節(jié)省了 70% 的大小

目標(biāo)達(dá)成

因此可以說明：在一些不是必須使用 https 的場景下，使用 http 會更加節(jié)省帶寬。

同時因為減少了加密的這個過程，可以觀察到的是，在相同的并發(fā)下，服務(wù)器的負(fù)載有明顯降低。

那么問題來了

如果接口必須使用 https那怎么辦呢?

當(dāng)然還有另外一個解決方案，那就使用使用 Keep-Alive。
headers 中添加 Connection: keep-alive 即可食用。

通過啟用 Keep-Alive，
可以在同一TCP連接上發(fā)送多個HTTPS請求，
而無需每次都進(jìn)行完整的TLS Handshake，
但第一次握手時仍然需要傳輸證書和完成密鑰交換。

對于高并發(fā)的場景也非常適用。

要注意的是

keep-alive 是有超時時間的，超過時間連接會被關(guān)閉，再次請求需要重新建立鏈接。

Nginx 默認(rèn)的 keep-alive 超時是 75 秒，
Apache HTTP 服務(wù)器 通常默認(rèn)的 keep-alive 超時是 5 秒。

ps：
如果你的采集程序使用了大量的代理 ip那么 keep-alive 的效果并不明顯～～
最好的還是使用 http

作者：麥麥麥造
鏈接：https://juejin.cn/post/7409138396792881186
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。