場景:
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
所以我們得到如下結論:
頻寬有限,同個ip同時下載的情況很小的,或者說是可以預知的業務,盡量將連接數限制的小一點。註:本文只探討nginx限速模組在不同業務下的限速
彩蛋:偶爾發現,將連線數限制在1迅雷不能高速下載了。以上是nginx限速之連線數限制的方法的詳細內容。更多資訊請關注PHP中文網其他相關文章!