前言
我們經常會遇到這種情況，服務器流量異常，負載過大等等。對于大流量惡意的攻擊訪問，會帶來帶寬的浪費，服務器壓力，影響業務，往往考慮對同一個ip的連接數，并發數進行限制。nginx 內置模塊限速怎么使用就不多說了，今天來說說連接數和單個連接數限速的事。話不多說了，來一起看看詳細的介紹吧。
場景：
A公司有100人，A公司只有一個公網IP，假設A公司可能有100個人同時在下載你的網站文件。
但是，你的連接數限制配置為：
|
1
2
3
4
5
6
7
|
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個人同時下載網站資源的情況有多大呢？沒做過統計，但是可能性極小。并且前端頁面和下載資源不共用一個域名，所以不會影響到前端頁面的訪問。
那都是誰在大量使用連接數呢？分兩類：
- 下載工具類（迅雷）。
- 各種各樣的采集程序。
- 同時進行多個下載任務。
小明快樂的在看電視，瞥了左邊頻幕一眼，握草，帶寬又滿了，來吧，限速吧，
|
1
2
3
4
5
6
|
limit_conn_zone $binary_remote_addr zone=perip:1m;server { --- limit_rate 1024k; ---} |
小明做了如上限速，OK，我告訴你們誰被限速了，當然是瀏覽器下載用戶，360瀏覽器的下載器都不一定能限制，好的，來算算速度吧。
瀏覽器: 2014K
下載器: 1024 * 15(最大連接數) * VIP
采集器: 1024 * 連接數
所以我們得到如下結論：
帶寬有限，同個IP同時下載的情況很小的，或者說是可以預知的業務，盡量將連接數限制的小一點。
反之，別限制了。就降低單個連接數帶寬吧！要知道大家誰沒事會用瀏覽器自帶下載器下載呢？
注：本文只探討nginx限速模塊在不同業務下的限速
彩蛋：偶爾發現，將連接數限制為1迅雷不能高速下載了。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。
原文鏈接：https://segmentfault.com/a/1190000012751223
