nginx伺服器帶寬如何配置

❶ nginx在做負載均衡時如何配置

1、下面的架構就是我們今天的演示結構，後端有兩台伺服器，分別是node1和node2，前端是一台web伺服器，然後在web伺服器上做負載均衡，將前端的訪問流量導到後端的兩個節點伺服器上。三個伺服器的IP地址分別是：web：192.168.1.210node1：192.168.1.211node2：192.168.1.212
2、按照這樣的架構，在後端的node1和node2節點上分配配置好需要訪問的網站，然後為了方便測試，我們將兩個網站的主頁分別改成下面的內容。便於區分訪問的節點。
3、後端兩個節點配置好以後，我們再來配置web伺服器里的負載均衡配置，首先使用默認配置，先打開/etc/nginx/nginx.conf配置文件，在http區塊里添加upstream塊內容，及配置了兩個後端伺服器，後端負載均衡集群的名稱是backend，記下這個名稱。
4、然後再打開/etc/nginx/conf.d/default.conf這個配置文件，在server區塊里，把location裡面的內容改成圖中所示內容。即將所有訪問192.168.1.210的流量代理到後端的backend集群里。
5、配置文件配置好以後，使用nginx-t命令測試一下配置文件，保證配置文件是ok狀態，然後執行nginx命令啟動nginx伺服器。
6、啟動後在瀏覽器上輸入前端web伺服器的ip地址192.168.1.210，然後可以看到第一次是node1響應的，然後刷新一下以後，又變成了node2響應的。就這樣實現了負載均衡的效果。由兩個伺服器分別響應，是因為默認的負載均衡演算法是輪詢演算法，即兩個節點輪流來。
7、然後我們還可以嘗試一下加權輪詢演算法，即給不同的節點配置不同的權重，權重高一點的伺服器，響應的多一些，權重第一點的響應少一些。加權輪詢演算法配置，在後端伺服器後面加上權重碼指喚值weight即可。配置好以後，執行nginx-t命令檢測配置文件，確認無誤後，執行nginx-sreload命令重新載入配置文件。
8、通過加權輪詢的方式，我們無法通過手動一次次點擊，最後來統計次數。但是我們可以使用自動化工具來統計。使用的工具是一款叫做httpd-tools的軟體，安裝好以後，提供了一個ab命令
9、然後我們來執行ab命令進行測試，常用的格式是：ab-n1000-c50http://localhost這個命令是在210伺服器上執行的。表示一共執行1000次訪問，每次發送50個請求。
10、然後我們登錄到後端的node1伺服器上，打開nginx的訪問日誌，從中可以看到ab命令測試的訪問信息里，訪問來源都是ApacheBench，因此可以通過可以來源來統計nginx響應的次數。命令是：grepApacheBenchaccess.log|wcnode1和node2節點上的統計結果分別是714和286，如下面圖中所逗羨示，雖然沒有達到5:2的遲凱權重比例，但是也非常接近了。說明這個配置生效了。

❷ [code.nginx] Nginx伺服器高級配置

這里提及的參數是和IPv4網路有關的linux內核參數。我們可以將這些內核參數的值追加到Linux系統的/etc/sysctl.conf文件中，然後使用如下命令使修改生效：

這些常用的參數包括以下這些。
** 1. net.core.netdev_max_backlog參數 **
net.core.netdev_max_backlog，表示當每個網路介面接收數據包的速率比內核處理這些包的速率快時，允許發送到隊列的數據包的最大數目。一般默認值為128（可能不同的Linux系統該數值也不同）。Nginx伺服器中定義的NGX_LISTEN_BACKLOG默認為511.我們可以將它調整一下：

** 2.net.core.somaxconn參數 **
該參數用於調節系統同時發起的TCP連接數，一般默認值為128。在客戶端存在高並發請求的情況下，在默認值較小，可能導致鏈接超時或者重傳問題，我們可以根據實際需要結合並發請求數來調節此值。

** 3.net.ipv4.tcp_max_orphans參數 **
該參數用於設定系統中最多允許存在多少TCP套接字不被關聯到任何一個用戶文件句柄上。如果超過這個數字，沒有與用戶文件句柄關聯的TCP套接字將立即被復位，同時給出警告信息。這個限制只是為了防止簡單的DoS(Denial of Service，拒絕服務)攻擊。一般在系統內存比較充足的情況下，可以增大這個參數的賦值：

** 4.net.ipv4.tcp_max_syn_backlog參數 **
該參數用於記錄尚未收到客戶端確認信息的連接請求的最大值。對於擁有128MB內存的系統而言，此參數的默認值是1024，對小內存的系統則是128。一般在系統內存比較充足的情況下，可以增加這個參數的賦值：

** 5.net.ipv4.tcp_timestamps參數 **
該參數用於設置時間戳，這可以避免序列號的卷繞。在一個1Gb/s的鏈路上，遇到以前用過的序列號的概率很大。當此值賦值為0時，禁用對於TCP時間戳的支持。在默認情況下，TCP協議會讓內核接受這種「異常」的數據包。針對Nginx伺服器來說，建議將其關閉：

** 6.net.ipv4.tcp_synack_retries參數 **
該參數用於設置內核放棄TCP連接之前向客戶端發送SYN+ACK包的數量。為了建立對端的連接服務，伺服器和客戶端需要進行三次握手，第二次握手期間，內核需要發送SYN並附帶一個回應前一個SYN的ACK，這個參數主要影響這個進程，一般賦值為1，即內核放棄連接之前發送一次SYN+ACK包，可以設置其為：

** 7.net.ipv4.tcp_syn_retries參數 **
該參數的作用和上一個參數類似，設置內核放棄建立連接之前發送SYN包的數量，它的賦值和上個參數一樣即可：

在Nginx配置文件中，有這樣兩個指令：worker_processes和worker_cpu_affinity，它們可以針對多核CPU進行配置優化。
** 1.worker_processes指令 **
worker_processes指令用來設置Nginx服務的進程數。官方文檔建議此指令一般設置為1即可，賦值太多會影響系統的IO效率，降低Nginx伺服器的性能。為了讓多核CPU能夠很好的並行處理任務，我們可以將worker_processes指令的賦值適當的增大一些，最好是賦值為機器CPU的倍數。當然，這個值並不是越大越好，Nginx進程太多可能增加主進程調度負擔，也可能影響系統的IO效率。針對雙核CPU，建議設置為2或
4。如果是四核CPU，設置為：

設置好worker_processes指令之後，就很有必要設置worker_cpu_affinity指令。

** 2. worker_cpu_affinity指令 **
worker_cpu_affinity指令用來為每個進程分配CPU的工作內核。這個指令用來為每個進程分配CPU的工作內核。這個指令的設置方法有些麻煩。
如下圖所示：

worker_cpu_affinity指令的值是由幾組二進制值表示的。其中，每一組代表一個進程，每組中的每一位表示該進程使用CPU的情況，1表示使用，0表示不使用。注意，二進制位排列順序和CPU的順序是相反的。建議將不同的進程平均分配到不同的CPU運行內核上。
如果設置的Nginx服務的進程數為4，CPU為4核，因此會有四組值，並且每組有四位，所以，此指令的設置為：

四組二進制數值分別對應4個進程，第一個進程對應0001，表示使用第一個CPU內核。第二個進程對應0010，表示使用第二個CPU內核，以此類推。
如果將worker_processes指令的值賦值為8，即賦值為CPU內核個數的兩倍，則worker_cpu_affinity指令的設置可以是：

如果一台機器的CPU是八核CPU，並且worker_processes指令的值賦值為8，那麼worker_cpu_affinity指令的設置可以是：

** 1.keepalive_timeout指令 **
該指令用於設置Nginx伺服器與客戶端保持連接的超時時間。
這個指令支持兩個選項，中間用空格隔開。第一個選項指定客戶端連接保持活動的超時時間，在這個時間之後，伺服器會關閉此連接。第二個選項可選，其指定了使用Keep-Alive消息頭保持活動的有效時間，如果不設置它，Nginx伺服器不會向客戶端發送Keep-Alive消息頭以保持與客戶端某些瀏覽器（如Mozilla、Konqueror等）的連接，超過設置的時間後，客戶端就可以關閉連接，而不需要伺服器關閉了。你可以根據自己的實際情況設置此值，建議從伺服器的訪問數量、處理速度以及網路狀態方面考慮。下面是此指令的設置示例：

該設置表示Nginx伺服器與客戶端連接保持活動的時間是60s，60s後伺服器與客戶端斷開連接。使用Keep-Alive消息頭保持與客戶端某些瀏覽器（如Mozilla、Konqueror等）的連接時間為50s，50s後瀏覽器主動與伺服器斷開連接。

** 2.send_timeout指令 **
該指令用於設置Nginx伺服器響應客戶端的超時時間，這個超時時間僅針對兩個客戶端和伺服器之間建立連接後，某次活動之間的時間。如果這個時間後客戶端沒有任何活動，Nginx伺服器將會關閉連接。此指令的設置需要考慮伺服器訪問數量和網路狀況等方面。下面是此指令的設置示例：

該設置表示Nginx伺服器與客戶端建立連接後，某次會話中伺服器等待客戶端響應超時10s，就會自動關閉連接。

** 3.client_header_buffer_size指令 **
該指令用於設置Nginx伺服器允許的客戶端請求頭部的緩沖區大小，默認為1KB。此指令的賦值可以根據系統分頁大小來設置。分頁大小可以用以下命令取得：

有過Nginx伺服器工作經驗的可能遇到Nginx伺服器返回400錯誤的情況。查找Nginx伺服器的400錯誤原因比較困難，因為此錯誤並不是每次都會出現，出現錯誤的時候，通常在瀏覽器和日誌里也看不到任何有關提示信息。根據實際的經驗來看，有很大一部分情況是客戶端的請求頭部過大造成的。請求頭部過大，通常是客戶單cookie中寫入了較大的值引起的。於是適當增大此指令的賦值，允許Nginx伺服器接收較大的請求頭部，可以改善伺服器對客戶端的支持能力。一般將此指令賦值為4KB大小，即：

** 4.multi_accept指令 **
該指令用於配置Nginx伺服器是否盡可能多的接收客戶端的網路連接請求，默認值為off。

本節涉及的指令與Nginx伺服器的事件驅動模型密切相關。

其中，number為設置的最大數量。結合worker_processes指令，我們可以計算出Nginx伺服器允許同時連接的客戶端最大數量Client = worker_processes * worker_connections / 2;
在使用Nginx伺服器的過程中，筆者曾經遇到過無法訪問Nginx伺服器的情況，查看日誌發現一直在報如下錯誤:

根據報錯信息，推測可能是Nginx伺服器的最大訪問連接數設置小了。此指令設置的就是Nginx伺服器能接受的最大訪問量，其中包括前端用戶連接也包括其他連接，這個值在理論上等於此指令的值與它允許開啟的工作進程最大數的乘積。此指令一般設置為65535：

此指令的賦值與linux操作系統中進程可以打開的文件句柄數量有關系。按照以上設置修改此項賦值以後，Nginx伺服器報以下錯誤：

究其原因，Linux系統中有一個系統指令open file resource limit，它設置了進程可以打開的文件句柄數量。worker_connections指令的賦值當然不能超過open file resource limit的賦值。可以使用以下命令查看在你的Linux系統中open file resource limit的賦值。

可以通過一下命令將open file resource limit指令的值設為2390251：

這樣，Nginx的worker_connections指令賦值為65535就沒問題了。

其中，limit為Linux平台事件信號隊列的長度上限值。
該指令主要影響事件驅動模型中rfsig模型可以保存的最大信號數。Nginx伺服器的每一個工作進程有自己的事件信號隊列用於暫存客戶端請求發生信號，如果超過長度上線，Nginx伺服器自動轉用poll模型處理未處理器的客戶端請求。為了保證Nginx伺服器對客戶端請求的高效處理，請大家根據實際的客戶端並發請求數量和伺服器運行環境的處理能力設定該值。設置示例為：

其中，number為要設置的數量，默認值均為32。

其中，number為要設置的數量，默認值均為512.
使用kequeue_changes方式，可以設置與內核之間傳遞事件的數量。

其中，number為要設置的數量，默認值均為512。

7.rtsig_signo指令
該指令用於設置rtsig模式使用的兩個信號中的第一個，第二個信號是在第一個信號的編號上加1，語法為：

默認的第一個信號設置為SIGRTMIN+10。

提示
在Linux中可以使用一下命令查看系統支持的SIGRTMIN有哪些。

8.rtsig_overflow_* 指令
該指令代表三個具體的指令，分別為rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。這些指令用來控制當rtsig模式中信號隊列溢出時Nginx伺服器的處理方式，語法結構為：

其中，number是要設定的值。
rtsig_overflow_events指令指定隊列溢出時使用poll庫處理的事件數，默認值為16。
rtsig_overflow_test指令設定poll庫處理完第幾件事件後將清空rtsig模型使用的信號隊列，默認值為32。

rtsig_overflow_threshold指令指定rtsig模式使用的信號隊列中的事件超過多少時就需要清空隊列了。

❸ nginx怎麼計算帶寬body

req_status_zone
語法: req_status_zone name string size
默認值: None
配置塊: http
定義請求狀態ZONE,請求按照string分組來排列，例如：
req_status_zone server_url $server_name$uri 256k;
域名+uri將會形成一條數據，可以看到所有url的帶寬，流量，訪問數
req_status
語法: req_status zone1[ zone2]

❹ 如何給區域網中的伺服器分配帶寬

普通用戶請求下載伺服器上的大文件不會有大問題，下載帶寬通常在幾十M左右，因此一頃絕明個請求對伺服器的帶寬壓力不大。

但當伺服器作為雀告CDN回源時就千萬要注意了，CDN的機房帶寬通常可以達到數百M甚至上G，而IDC機房的帶寬費用往往是根據峰值帶寬來計算。

因此如果CDN回源大文件時不對伺服器帶寬做限制，將會出現瞬間極大峰值，造成不必要的經濟損失。

解決問題的核心在於限制伺服器上行帶寬。

我們通過對nginx增加帶寬限制嘗試解決這個問題。

nginx里有2個配置項

limit_rate <size> 限制單個請求帶寬峰值，512, 1k, 10m

limit_rate_after <size> 當下載超過一定大小後開始限制，100m, 100k

進行宏悉如此配置後，我們用curl進行測試，發現當文件下載超過一定大小後，下載速率就會降到limit_rate設定的帶寬值。

總結：如果網站有大文件資源時，一定要注意下載速率的配置，特別是在做CDN回源時尤其必須對速率進行配置。即便不做CDN回源，在某些特殊場景下也有可能出現高帶寬下載，因此要特別注意