大型站點TCP IP協議優化

作為乙個dau上百萬或千萬的站點，不僅僅需要做好**應用程式、資料庫的優化，還應從tcp/ip協議層去進行相關的優化；

在我的工作中，曾使用到了以下的幾種基本的優化方式：

在linux系統裡，所有的網路連線都是通過檔案描述符（file descriptor）來實現的，因此乙個程序所能開啟的檔案描述符數量決定了這個程序所能建立的最大連線數；

由於linux系統對程序的檔案描述符數量限制是1024；對於大規模的分布式站點來說，這樣的連線數限制是遠遠不夠的，建議適當增大該值：

首先在linux中查詢檔案描述符數量限制：

ulimit -n

* soft nofile 10000

* hard nofile 10000

重啟系統之後，再使用ulimit -n檢視得到的結果就是10000了。

在tcp斷開連線的四次揮手結束階段，連線斷開的發起方會進入到time_wait狀態。

在你的linux伺服器上執行如下命令：

netstat -n | grep
'tcp
'

在輸出的最後一列你可能會看到值為time_wait的行，這代表該tcp連線已經進入了time_wait狀態，進入到該狀態的連線是不會釋放的，預設情況下需要等待2msl的時間（1msl大致等於ttl衰減為0的時間，在rfc 793中規定為2分鐘）。因此在斷開連線之後的2個2分鐘時間段內，連線會一直保持為time_wait並持有檔案控制代碼不釋放，在大型站點中會導致伺服器連線很快背耗盡，實際上對於現在的網速，等待2msl（4分鐘）的時間過長，建議將該時間設定為30秒即可：

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

執行 sudo /sbin/sysctl -p 命令，使修改立即生效。

在tcp協議中，延遲確認（delayed ack）是一把雙刃劍；在絕大多數情況下，延遲確認在伺服器收到資料報之後，不需要對每個資料報立刻響應ack，而是將多個資料報的ack響應合併為乙個，從而提高了網路傳輸的效能並降低了網路的負載，然而在某些條件下，也會帶來負面影響；

影響主要有兩方面：

正如上面所述，延遲確認是一把雙刃劍，在大多數環境下具有促進作用，因此關閉與否識情況而定，在某些情況下可以適當減小延遲確認超時時間。

上面談到延遲確認帶來的兩方面影響中，在第二個方面裡提到了丟包之後傳送方需要等到接收方響應ack之後，才會重發丟失的包；如接收到ack 4時才重發第4個包，而後接收到ack 5時重發第5個包，接收到ack 6時重發第6個包......，如果丟包數量較大時，這個步驟會顯得格外的綿長。

sack（selective acknowledgment）解決了這個問題，它使得接收方在收到第8個包之後響應的ack seq=4這個包裡，會把它已經收到的包序列號也寫入（這裡是8，代表第8個包已經收到）；接收方在收到這個ack包之後，就可以知道第1、2、3、8四個包傳送成功，從而推斷出需要重發第4、5、6、7這四個包。

sack是雙方面的，需要傳送方和接收方同時啟用才能生效。

tcp作為乙個面向連線的安全可靠的傳輸協議，它也有很多天然的缺陷，例如上面談到的失敗重發問題，以及其他諸如建立/斷開連線需要三次握手四次揮手的問題、傳送包時的隊頭阻塞問題，因此傳輸的效能並不夠好；google提出了基於udp協議的上層quic協議；它在建立/斷開連線時無需三次握手四次揮手，它採用raid5演算法緩解了tcp協議中丟包時的失敗重傳問題。

現在google的chrome瀏覽器、microsoft的edge瀏覽器都支援quic協議，同時即將到來的http/3也是建立在quic協議之上（rfc 9000）。

大型站點TCP IP協議優化

大型站點的搜尋營銷

解讀大型站點和小型站點的seo區別

TCP IP協議 TCP IP協議棧及框架

大型站點TCP IP協議優化

大型站點的搜尋營銷

解讀大型站點和小型站點的seo區別

TCP IP協議 TCP IP協議棧及框架

相關推薦