我們常常會遇到這種情況,伺服器流量異常,負載過大等等。對於大流量惡意的攻擊訪問,會帶來頻寬的浪費,伺服器壓力,影響業務,往往考慮對同一個ip的連接數,並發數進行限制。 nginx 內建模組限速怎麼使用就不多說了,今天來說說連接數和單一連接數限速的事。話不多說了,來一起看看詳細的介紹吧。
場景:
A公司有100人,A公司只有一個公網IP,假設A公司可能有100個人同時在下載你的網站檔案。
但是,你的連線數限製配置為:
limit_conn_zone $binary_remote_addr zone=perip:1m; server { --- limit_conn perip 1; limit_rate 1024k; --- }
允許單一連線數,單一連線數最大頻寬為1M。
這樣就會有99個人的請求狀態為 503, 其他人如果想下載就必須人工等待(nginx不會通知用戶說A用戶下載完了,該你B用戶下載了)。這樣造成的使用者體驗極差。但是優點也很明顯,頻寬很快就會降下來。
可能有人要問了,你限製成很低的連線數是想搞事情? NO,絕對不是。前面的100個人同時下載網站資源的情況有多大?沒做過統計,但可能性極小。且前端頁面和下載資源不共用一個域名,所以不會影響到前端頁面的存取。
那是誰在大量使用連線數呢?分為兩類:
下載工具類別(迅雷)。
各種各樣的採集程式。
同時進行多個下載任務。
小明快樂的在看電視,瞥了左邊頻幕一眼,握草,帶寬又滿了,來吧,限速吧,
limit_conn_zone $binary_remote_addr zone=perip:1m; server { --- limit_rate 1024k; --- }
小明做瞭如上限速,OK,我告訴你們誰被限速了,當然是瀏覽器下載用戶,360瀏覽器的下載器都不一定能限制,好的,來算算速度吧。
瀏覽器: 2014K
下載器: 1024 * 15(最大連接數) * VIP
採集器: 1024 * 連接數字
所以我們得到以下結論:
頻寬有限,同個IP同時下載的情況很小的,或者說是可以預知的業務,盡量將連線數限制的小一點。
反之,別限制了。就降低單一連線數頻寬吧!要知道大家誰沒事會用瀏覽器自備下載器下載呢?
註:本文只探討nginx限速模組在不同業務下的限速
彩蛋:偶爾發現,將連線數限制為1迅雷不能高速下載了。
相關推薦:
以上是nginx限速之連線數限制詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章!