當前位置：首頁 > 运维知识 > Nginx >内容正文

Nginx

Nginx面试题整理

發布時間：2023/12/10 Nginx 37 豆豆

生活随笔收集整理的這篇文章主要介紹了 Nginx面试题整理小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

nginx返回狀態碼

一些常見的狀態碼

200 - 服務器成功返回網頁 404 - 請求的網頁不存在 304 - Not Modified. 原來緩沖的還可以使用 500 - 大多是代碼問題，或者sql報錯 501 - 服務器不具備完成請求的功能 502 - Bad Gateway fpm進程掛掉或者后端程序過長時間未返回。 503 - Service Unavailable 當遇到這個狀態碼的時候表示服務臨時不可用，比如nginx配置了頻率限制，而client端又超過了配置的限制后就會收到503的響應。 504 - Gateway Time-out nginx的fastcgi模塊有一個fastcgi_read_timeout配置，它表示從FastCGI server獲取數據的超時時間。如果超過這個配置客戶端就是收到504的響應。

HTTP 狀態碼的完整列表

　　**1xx(**臨時響應)表示臨時響應并需要請求者繼續執行操作的狀態碼。**100**(繼續)請求者應當繼續提出請求。服務器返回此代碼表示已收到請求的第一部分，正在等待其余部分。**101**(切換協議)請求者已要求服務器切換協議，服務器已確認并準備切換。**2xx** (成功)表示成功處理了請求的狀態碼。**200**(成功)服務器已成功處理了請求。通常，這表示服務器提供了請求的網頁。如果是對您的 robots.txt 文件顯示此狀態碼，則表示 Googlebot 已成功檢索到該文件。**201**(已創建)請求成功并且服務器創建了新的資源。**202**(已接受)服務器已接受請求，但尚未處理。**203**(非授權信息)服務器已成功處理了請求，但返回的信息可能來自另一來源。**204**(無內容)服務器成功處理了請求，但沒有返回任何內容。**205**(重置內容)服務器成功處理了請求，但沒有返回任何內容。與 204 響應不同，此響應要求請求者重置文檔視圖(例如，清除表單內容以輸入新內容)。**206**(部分內容)服務器成功處理了部分 GET 請求。**3xx **(重定向)要完成請求，需要進一步操作。通常，這些狀態碼用來重定向。Google 建議您在每次請求中使用重定向不要超過 5 次。您可以使用網站管理員工具查看一下 Googlebot 在抓取重定向網頁時是否遇到問題。診斷下的網絡抓取頁列出了由于重定向錯誤導致 Googlebot 無法抓取的網址。**300**(多種選擇)針對請求，服務器可執行多種操作。服務器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。**301**(永久移動)請求的網頁已永久移動到新位置。服務器返回此響應(對 GET 或 HEAD 請求的響應)時，會自動將請求者轉到新位置。您應使用此代碼告訴 Googlebot 某個網頁或網站已永久移動到新位置。**302**(臨時移動)服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來響應以后的請求。此代碼與響應 GET 和 HEAD 請求的 301 代碼類似，會自動將請求者轉到不同的位置，但您不應使用此代碼來告訴 Googlebot 某個網頁或網站已經移動，因為 Googlebot 會繼續抓取原有位置并編制索引。**303**(查看其他位置)請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。對于除 HEAD 之外的所有請求，服務器會自動轉到其他位置。**304**(未修改)自從上次請求后，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。

nginx返回4xx

403 Forbidden 訪問被拒絕

一、由于啟動用戶和nginx工作用戶不一致所致

查看nginx的啟動用戶，發現是nobody，而為是用root啟動的
命令：

ps aux | grep "nginx: worker process" | awk'{print $1}'

1.2將nginx.config的user改為和啟動用戶一致，
命令：

vi conf/nginx.conf

二、缺少index.html或者index.php文件，就是配置文件中index index.html index.htm這行中的指定的文件。

server {listen 80;server_name localhost;index index.php index.html;root /data/www/;}

如果在/data/www/下面沒有index.php,index.html的時候，直接文件，會報403 forbidden。

三、權限問題，如果nginx沒有web目錄的操作權限，也會出現403錯誤。

解決辦法：修改web目錄的讀寫權限，或者是把nginx的啟動用戶改成目錄的所屬用戶，重啟Nginx即可解決

chmod -R 777 /data chmod -R 777 /data/www/

四、SELinux設置為開啟狀態（enabled）的原因。
查看當前selinux的狀態

/usr/sbin/sestatus

將SELINUX=enforcing 修改為 SELINUX=disabled 狀態

vi /etc/selinux/config#SELINUX=enforcing SELINUX=disabled

重啟生效
reboot

404 NOT FOUND

一、頁面找不到，可能是url錯了。

二、也可能是配置文件的問題。
在/etc/nginx/conf.d 下有default.conf 和nginx.conf 兩個配置文件,
前者是默認的配置,后者是我的個性化配置
nginx 運行的時候加載了conf.d文件夾下的所有.conf結尾的文件
default.conf 覆蓋了nginx.conf配置,原因:
因為在nginx的配置中,conf.d文件夾中的配置文件優先級是按照字母順序來的,default.conf 的優先級大于nginx.conf,覆蓋了nginx.conf的配置

nginx返回5xx

簡述5xx出現原因

500：大多是代碼問題，或者sql報錯。

501：服務器不具備完成請求的功能。例如，服務器無法識別請求方法時可能會返回此代碼。

502：nginx在這里充當的是反向代理服務器的角色，是把http協議請求轉成fastcgi協議的請求，通過fastcgi_pass指令傳遞給php-fpm進程，當php-fpm進程響應的內容是nginx無法理解的響應，就會返回502 bad gateway。

503：服務器目前無法使用（由于超載或停機維護）。通常，這只是暫時狀態。（服務不可用）。一個http請求占用一個php-fpm進程，瞬時請求量過大時，沒有足夠的php-fpm進程去處理請求，就會返回503 service unavailable。

504: 單個php-fpm進程阻塞超過nginx的時間閾值返回504 gateway timeout。

505：服務器不支持請求中所用的 HTTP 協議版本。（HTTP 版本不受支持）

500錯誤

1、500 Internal Server Error 內部服務錯誤：顧名思義500錯誤一般是服務器遇到意外情況，而無法完成請求。

2、500出錯的可能性：

a、編程語言語法錯誤，web腳本錯誤 b、并發高時，因為系統資源限制，而不能打開過多的文件

3、一般解決思路：

a、查看nginx、php的錯誤日志文件，從而看出端倪 b、如果是too many open files，修改nginx的worker_rlimit_nofile參數，使用ulimit查看系統打開文件限制，修改/etc/security/limits.conf，還是出現too many open files，那就要考慮做負載均衡，把流量分散到不同服務器上去了 c、如果是腳本的問題，則需要修復腳本錯誤，優化代碼

501

服務器不具備完成請求的功能。例如：服務器無法識別請求方法時可能會返回。

502 Bad Gateway

網關超時。
fpm進程掛掉或者后端程序過長時間未返回。

503 Service Unavailable

解釋：服務臨時不可用。
問題原因：
nginx配置了頻率限制，client端又超過了配置的限制，比如單個ip并發設置過小。

504 Gateway Time-out

nginx的fastcgi模塊有一個fastcgi_read_timeout配置，它表示從FastCGI server獲取數據的超時時間，增加它的等待時間，可以達到優化。

505 HTTP Version Not Supported

狀態碼是說服務器并不支持在請求中所標明 HTTP 版本。該狀態是新加入 HTTP 1.1的

502、504的區別

502、504問題出現的可能性，一般是web服務器故障、程序進程不夠。

a、使用nginx代理，而后端服務器發生故障；或者php-cgi進程數不夠用；php執行時間長，或者是php-cgi進程死掉；已經fastCGI使用情況等都會導致502、504錯誤。

b、502 是指請求的php-fpm已經執行，但是由于某種原因而沒有執行完畢，最終導致php-fpm進程終止。一般來說，與php-fpm.conf的設置有關，也與php的執行程序性能有關，網站的訪問量大，而php-cgi的進程數偏少。針對這種情況的502錯誤，只需增加php-fpm的進程數。具體就是修改/usr/local/php/etc/php-fpm.conf文件，將其中的max_children值適當增加。這個數據要依據你的服務器的配置進行設置。一般一個php-cgi進程占20M內存，你可以自己計算下，適量增多。然后php-fpm然后重啟一下.

c、504 表示超時，也就是客戶端所發出的請求沒有到達網關，請求沒有到可以執行的php-fpm。與nginx.conf的配置也有關系。

通俗的來說，nginx作為一個代理服務器，將請求轉發到其他服務器或者php-cgi來處理，當nginx收到了無法理解的響應時，就返回502。當nginx超過自己配置的超時時間還沒有收到請求時，就返回504錯誤。

nginx返回502，504詳解

502 Bad Gateway

官方解釋：作為網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。

上面說到nginx收到了無法理解的響應，什么是無法理解的響應呢？

nginx無法與php-fpm進行連接。
nginx在連接php-fpm一段時間后發現與php-fpm的連接被斷開。

那么什么時候會出現上面的情況呢？

php-fpm沒有啟動,nginx無法將請求交給php-fpm
php-fpm運行腳本超時，php-fpm終止了腳本的執行和執行腳本的Worker進程，nginx發現自己與php-fpm的連接斷開

php-fpm沒有啟動

我們關閉php-fpm，刷新頁面，發現返回502錯誤：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-4PYaPLOW-1658491396350)(http://img.qdhgrc.com/cf32c2e53063778c811d06d57da96851)]

php-fpm請求超時

我們首先將php-fpm.conf中的max_terminate_request改成5s：

request_terminate_timeout = 5

在php腳本中添加如下語句：

sleep(20);

刷新頁面，發現返回502錯誤：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-MODSmpaw-1658491396353)(http://img.qdhgrc.com/cf32c2e53063778c811d06d57da96851)]

其他502原因的檢測

1、查看當前的PHP FastCGI進程數是否夠用

netstat -anpo | grep "php-cgi" | wc –l

如果實際使用的【FastCGI進程數】接近預設的【FastCGI進程數】，那么，說明【FastCGI進程數】不夠用，需要增大。

2、部分PHP程序的執行時間超過了Nginx的等待時間

可以適當增加nginx.conf配置文件中FastCGI的timeout時間。php.ini中memory_limit設低了會出錯，修改了php.ini的memory_limit為64M，重啟nginx，如果發現恢復了，那么就是PHP的內存不足的原因。

3、max-children和max-requests

主機上運行著nginx php(fpm) xcache的話，訪問量日均 300W pv左右。如果是近期出現php頁面打開很慢，cpu使用率突然降至很低，系統負載突然升至很高，查看網卡的流量，也會發現突然降到了很低這樣的情況，而且這種情況只持續數秒鐘就恢復，這時檢查php-fpm的日志文件發現了一些線索：

1）Sep 30 08:32:23.289973 \[NOTICE\] fpm\_unix\_init\_main()， line 271: getrlimit(nofile): max:51200， cur:51200 2）Sep 30 08:32:23.290212 \[NOTICE\] fpm\_sockets\_init\_main()， line 371: using inherited socket fd=10， “127.0.0.1:9000″ 3）Sep 30 08:32:23.290342 \[NOTICE\] fpm\_event\_init\_main()， line 109: libevent: using epoll 4）Sep 30 08:32:23.296426 \[NOTICE\] fpm\_init()， line 47: fpm is running， pid 30587

看顯示的這幾句的前面，是1000多行的關閉children和開啟children的日志。因為php-fpm有一個參數 max_requests，該參數指明每個children最多處理多少個請求后便會被關閉，默認的設置是500。因為php是把請求輪詢給每個children，在大流量下，每個children到達max_requests所用的時間都差不多，這樣就造成所有的children基本上在同一時間被關閉。

在這期間，nginx無法將php文件轉交給php-fpm處理，所以cpu會降至很低，不用處理php，更不用執行sql，而負載會升至很高，關閉和開啟children、nginx等待php-fpm，網卡流量也降至很低，nginx無法生成數據傳輸給客戶端。

解決方式：增加children的數量，并且將 max_requests 設置為 0 或者一個比較大的值，打開 /usr/local/php/etc/php-fpm.conf，調大以下兩個參數，但是要根據主機實際情況，數值過大也不行。然后再重啟php-fpm，就能恢復了。

4、增加緩沖區容量大小

將nginx的error log打開，發現【pstream sent too big header while reading response header from upstream】這樣的錯誤提示。大概意思是nginx緩沖區有一個bug造成的，網站的頁面消耗占用緩沖區可能過大。

參考國外系統管理員寫的修改辦法，增加了緩沖區容量大小設置，502問題徹底解決。后來系統管理員又對參數做了調整只保留了2個設置參數：client head buffer，fastcgi buffer size。

5、PHP腳本的最大執行時間

max_execution_time //php.ini request_terminate_timeout //php.ini

這兩項都是用來配置PHP腳本的最大執行時間。超時時php-fpm會終止腳本的執行，同時還會終止執行腳本的Worker進程。

如上，php-fpm child 18822被terminate后重新生成了新的Worker進程19164,所以nginx發現與自己通信的連接斷了，就自然會返回502錯誤給客戶端。客戶端需再次發起請求重新建立新的連接，表象是刷新下瀏覽器即重新發起請求

所以只需將這兩項的值適當調大，讓PHP腳本不會因為執行時間長而被終止從而與nginx激活連接丟失。

request_terminate_timeout優先級高于max_execution_time，不想改全局的php.ini，只改php-fpm的配置就可以了。這里暫且調到600秒

request_terminate_timeout = 600

504 Bad Gateway timeout

504 即 nginx 超過了自己設置的超時時間，不等待 php-fpm 的返回結果，直接給客戶端返回 504 錯誤。但是此時 php-fpm 依然還在處理請求（在沒有超出自己的超時時間的情況下）.

這里有三個相關的配置：

fastcgi_connect_timeout 300;

指定連接到后端 FastCGI 的超時時間.
fastcgi_send_timeout 300;

向 FastCGI 傳送請求的超時時間，這個值是指已經完成兩次握手后向FastCGI傳送請求的超時時間.
fastcgi_read_timeout 300;

接收 FastCGI 應答的超時時間，這個值是指已經完成兩次握手后接收FastCGI應答的超時時間.

網關超時，客戶端所發出的請求沒有到達網關,在限定時間內沒有得到php-fpm，或者完成php-fpm的傳輸數據的工作而超時。比方說：即nginx的worker去php-fpm進程池去處理，但是沒有fpm進程可以使用了，等啊等，還是沒有，返回504。

場景
nginx的fastcgi模塊有一個fastcgi_read_timeout配置，它表示從FastCGI server獲取數據的超時時間。如果超過這個配置客戶端就是收到504的響應。比如執行了一段非常耗時的查詢語句，nginx的相關fastcgi等待配置超時后，就會返回504，但是php-fpm還在運行。

解決辦法

location ~ \.php$ {fastcgi_connect_timeout 180;//優化點fastcgi_read_timeout 600;//優化點fastcgi_send_timeout 600;//優化點fastcgi\_pass unix:/tmp/php-fpm.sock;fastcgi\_index index.php;include fastcgi.conf; }

調高上面標紅的3個值后，主要是read和send兩項(默認Nginx超時為60)，完美地解決了504錯誤。

并且可以配置在http，server級別，也可以配置在location級別。

factcgi_connect_{read|send|timeout}是對fastcgi_pass生效 proxy_connect_{read|send|timeout|是對proxy_pass生效

優化方案

簡述優化項

啟動用戶更改為非root，比如nginx，降權更安全 worker_processes 改為cpu核心數 worker_cpu_affinity 開啟多核CPU使用 errorlog 配置crit盡量精簡寫log，減少磁盤IO worker_rlimit_nofile 自行配置nginx的worker進程打開的最大文件數，網絡IO事件模型使用 epoll worker_connections 設置一個worker可以打開的最大連接數錯誤頁面上的nginx版本信息關閉，提升安全性開啟sendfile（）函數，sendfile可以在磁盤和tcp socket之間互相copy數據開啟gzip，會大量減少我們的發數據的量開啟nginx緩存，設置Web緩存區名稱為cache_one，內存緩存空間大小為200MB，1天沒有被訪問的內容自動清除，硬盤緩存空間大小為30GB

具體配置項

#頭部配置 user nginx nginx; #定義nginx的啟動用戶，不建議使用root worker_processes 4;　　#定位為cpu的內核數量，因為我的環境配置是4核，所以就寫4。不過這值最多也就是8，8個以上也就沒什么意義了，想繼續提升性能只能參考下面一項配置 worker_cpu_affinity 0001 0010 0100 1000;　　#此項配置為開啟多核CPU，對你先弄提升性能有很大幫助nginx默認是不開啟的,1為開啟，0為關閉，因此先開啟第一個倒過來寫，第一位0001（關閉第四個、關閉第三個、關閉第二個、開啟第一個）第二位0010（關閉第四個、關閉第三個、開啟第二個、關閉第一個）第三位0100（關閉第四個、開啟第三個、關閉第二個、關閉第一個）后面的依次類推，有智商的應該都可以看懂了吧？那么如果是16核或者8核cpu，就注意為00000001、00000010、00000100，總位數與cpu核數一樣。 error_log /data/logs/nginx/error.log crit;　　　　　　#這兩項基本不用我說 pid /usr/local/nginx/nginx.pid; #Specifies the value for maximum file descriptors that can be opened by this process. worker_rlimit_nofile 65535;　　　　#這個值為nginx的worker進程打開的最大文件數，如果不配置，會讀取服務器內核參數（通過ulimit -a查看），如果內核的值設置太低會讓nginx報錯（too many open file），但是在此設置后，就會讀取自己配置的參數不去讀取內核參數 events { use epoll;　　　　#客戶端線程輪詢方法、內核2.6版本以上的建議使用epoll worker_connections 65535;　　#設置一個worker可以打開的最大連接數 } http { include mime.types; default_type application/octet-stream; #charset gb2312; server_tokens off;　　　　#為錯誤頁面上的nginx版本信息，建議關閉，提升安全性 server_names_hash_bucket_size 128; client_header_buffer_size 32k; large_client_header_buffers 4 32k; client_max_body_size 8m; sendfile``on``;　　　　　　#開啟sendfile（）函數，sendfile可以再磁盤和tcp socket之間互相copy數據。 tcp_nopush ``on``;　　#告訴nginx在數據包中發送所有頭文件，而不是一個一個的發 #keepalive_timeout 15; keepalive_timeout 120; tcp_nodelay``on``; proxy_intercept_errors``on``; fastcgi_intercept_errors``on``; fastcgi_connect_timeout 1300; fastcgi_send_timeout 1300; fastcgi_read_timeout 1300; fastcgi_buffer_size 512k; fastcgi_buffers 4 512k; fastcgi_busy_buffers_size 512k; fastcgi_temp_file_write_size 512k; proxy_connect_timeout 20s; proxy_send_timeout 30s; proxy_read_timeout 30s; gzip``on``;　　　　　　　　　　　　#gzip是告訴nginx采用gzip后的數據來傳輸文件，會大量減少我們的發數據的量 gzip_min_length 1k; gzip_buffers 4 16k; gzip_http_version 1.0; gzip_comp_level 2; gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png; gzip_vary``on``; gzip_disable msie6; #limit_zone crawler $binary_remote_addr 10m; log_format main ``'$http_host $remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' '$request_time $upstream_response_time'``; #proxy_temp_path和proxy_cache_path指定的路徑必須在同一分區,因為它們之間是硬鏈接的關系 #proxy_temp_path /var/cache/nginx/proxy_temp_dir; #設置Web緩存區名稱為cache_one，內存緩存空間大小為200MB，1天沒有被訪問的內容自動清除，硬盤緩存空間大小為30GB。 #proxy_cache_path /var/cache/nginx/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g; include /usr/local/nginx/conf/vhosts/*.conf; error_page 404 = https:``//www.niu.com/404/; #error_page 500 502 503 504 = http://service.niu.com/alien/; }

內核參數優化

如果是高并發架構，需要在nginx的服務器上添加如下的內核參數

這些參數追加到/etc/sysctl.conf,然后執行sysctl -p 生效。

每個網絡接口接收數據包速度比內核處理速度快的時候，允許發送隊列數目數據包的最大數

net.core.netdev_max_backlog = 262144
調節系統同時發起的tcp連接數

net.core.somaxconn = 262144
該參數用于設定系統中最多允許存在多少TCP套接字不被關聯到任何一個用戶文件句柄上，主要目的為防止Ddos攻擊

net.ipv4.tcp_max_orphans = 262144
該參數用于記錄尚未收到客戶端確認信息的連接請求的最大值
net.ipv4.tcp_max_syn_backlog = 262144
nginx服務上建議關閉（既為0）

net.ipv4.tcp_timestamps = 0
該參數用于設置內核放棄TCP連接之前向客戶端發送SYN+ACK包的數量，為了建立對端的連接服務，服務器和客戶端需要進行三次握手，第二次握手期間，內核需要發送SYN并附帶一個回應前一個SYN的ACK，這個參
數主要影響這個過程，一般賦予值為1，即內核放棄連接之前發送一次SYN＋ACK包。

net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1

其他一些優化方面

． gzip壓縮優化
． expires緩存
．網絡IO事件模型優化
．隱藏軟件名稱和版本號
．防盜鏈優化
．禁止惡意域名解析
．禁止通過IP地址訪問網站
． HTTP請求方法優化
．防DOS攻擊單IP并發連接的控制，與連接速率控制
. 嚴格設置web站點目錄的權限
. 將nginx進程以及站點運行于監牢模式
. 通過robot協議以及HTTP_USER_AGENT防爬蟲優化
. 配置錯誤頁面根據錯誤碼指定網頁反饋給用戶
. nginx日志相關優化訪問日志切割輪詢，不記錄指定元素日志、最小化日志目錄權限
. 限制上傳到資源目錄的程序被訪問，防止木馬入侵系統破壞文件
. FastCGI參數buffer和cache配置文件的優化
. php.ini和php-fpm.conf配置文件的優化
. 有關web服務的Linux內核方面深度優化（網絡連接、IO、內存等）
. nginx加密傳輸優化（SSL）
. web服務器磁盤掛載及網絡文件系統的優化
. 使用nginx cache

lvs，keepalive和nginx的關系

keepalived

keepalived是一個類似于layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived是自動完成，不需人工干涉。

特點

自動完成，不需人工干涉

簡介

Keepalived的作用是檢測服務器的狀態，如果有一臺web服務器宕機，或工作出現故障，Keepalived將檢測到，并將有故障的服務器從系統中剔除，同時使用其他服務器代替該服務器的工作，當服務器工作正常后Keepalived自動將服務器加入到服務器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的服務器。

工作原理

Layer3,4,5工作在IP/TCP協議棧的IP層，TCP層，及應用層,原理分別如下：

Layer3：Keepalived使用Layer3的方式工作式時，Keepalived會定期向服務器群中的服務器發送一個ICMP的數據包（既我們平時用的Ping程序）,如果發現某臺服務的IP地址沒有激活，Keepalived便報告這臺服務器失效，并將它從服務器群中剔除，這種情況的典型例子是某臺服務器被非法關機。Layer3的方式是以服務器的IP地址是否有效作為服務器工作正常與否的標準。

Layer4:如果您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP端口的狀態來決定服務器工作正常與否。如web server的服務端口一般是80，如果Keepalived檢測到80端口沒有啟動，則Keepalived將把這臺服務器從服務器群中剔除。

Layer5：Layer5對指定的URL執行HTTP GET。然后使用MD5算法對HTTP GET結果進行求和。如果這個總數與預期值不符，那么測試是錯誤的，服務器將從服務器池中移除。該模塊對同一服務實施多URL獲取檢查。如果您使用承載多個應用程序服務器的服務器，則此功能很有用。此功能使您能夠檢查應用程序服務器是否正常工作。MD5摘要是使用genhash實用程序（包含在keepalived軟件包中）生成的。

作用

Keepalived軟件起初是專為LVS負載均衡軟件設計的，用來管理并監控LVS集群系統中各個服務節點的狀態，后來又加入了可以實現高可用的VRRP功能。因此，Keepalived除了能夠管理LVS軟件外，還可以作為其他服務（例如：Nginx、Haproxy、MySQL等）的高可用解決方案軟件。

Keepalived軟件主要是通過VRRP協議實現高可用功能的。VRRP是Virtual Router RedundancyProtocol(虛擬路由器冗余協議）的縮寫，VRRP出現的目的就是為了解決靜態路由單點故障問題的，它能夠保證當個別節點宕機時，整個網絡可以不間斷地運行。

所以，Keepalived 一方面具有配置管理LVS的功能，同時還具有對LVS下面節點進行健康檢查的功能，另一方面也可實現系統網絡服務的高可用功能。

keepalived官網

http://www.keepalived.org

lvs

負載均衡的類型

負載均衡可以采用硬件設備（例如常常聽見的 F5），也可以采用軟件負載
商用硬件負載設備成本通常較高（一臺幾十萬甚至上百萬），所以一般情況下會采用軟件負載
軟件負載解決的兩個核心問題是：選誰、轉發，其中最著名的是 lvs

lvs 是什么？

英文全稱是 Linux Virtual Server，即 Linux 虛擬服務器
由章文嵩博士發起的自由軟件項目，它的官方站點是 www.linuxvirtualserver.org
Linux2.4 內核以后，LVS 已經是 Linux 標準內核的一部分
可以將請求分發給后端真實服務器處理
有許多比較著名網站和組織都在使用 LVS 架設的集群系統，例如：Linux 的門戶網站（www.linux.com）、向 RealPlayer 提供音頻視頻服務而聞名的 Real 公司（www.real.com ）、全球最大的開源網站（sourceforge.net）等。

調度算法

1.輪詢調度

輪詢調度（Round Robin 簡稱’RR’）算法就是按依次循環的方式將請求調度到不同的服務器上，該算法最大的特點就是實現簡單。輪詢算法假設所有的服務器處理請求的能力都一樣的，調度器會將所有的請求平均分配給每個真實服務器。

2.加權輪詢調度

加權輪詢（Weight Round Robin 簡稱’WRR’）算法主要是對輪詢算法的一種優化與補充，LVS會考慮每臺服務器的性能，并給每臺服務器添加一個權值，如果服務器A的權值為1，服務器B的權值為2，則調度器調度到服務器B的請求會是服務器A的兩倍。權值越高的服務器，處理的請求越多。

3.最小連接調度

最小連接調度（Least Connections 簡稱’LC’）算法是把新的連接請求分配到當前連接數最小的服務器。最小連接調度是一種動態的調度算法，它通過服務器當前活躍的連接數來估計服務器的情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1；當連接中斷或者超時，其連接數減1。

（集群系統的真實服務器具有相近的系統性能，采用最小連接調度算法可以比較好地均衡負載。)

4.加權最小連接調度

加權最少連接（Weight Least Connections 簡稱’WLC’）算法是最小連接調度的超集，各個服務器相應的權值表示其處理性能。服務器的缺省權值為1，系統管理員可以動態地設置服務器的權值。加權最小連接調度在調度新連接時盡可能使服務器的已建立連接數和其權值成比例。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。

5.基于局部的最少連接

基于局部的最少連接調度（Locality-Based Least Connections 簡稱’LBLC’）算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用于Cache集群系統，因為在Cache集群客戶請求報文的目標IP地址是變化的。這里假設任何后端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和Cache命中率，從而提升整個集群系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則使用’最少連接’的原則選出一個可用的服務器，將請求發送到服務器。

6.帶復制的基于局部性的最少連接

帶復制的基于局部性的最少連接（Locality-Based Least Connections with Replication 簡稱’LBLCR’）算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統，它與LBLC算法不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。按’最小連接’原則從該服務器組中選出一一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按’最小連接’原則從整個集群中選出一臺服務器，將該服務器加入到這個服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。

7.目標地址散列調度

目標地址散列調度（Destination Hashing 簡稱’DH’）算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且并未超載，將請求發送到該服務器，否則返回空。

8.源地址散列調度U

源地址散列調度（Source Hashing 簡稱’SH’）算法先根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且并未超載，將請求發送到該服務器，否則返回空。它采用的散列函數與目標地址散列調度算法的相同，它的算法流程與目標地址散列調度算法的基本相似。

9.最短的期望的延遲

最短的期望的延遲調度（Shortest Expected Delay 簡稱’SED’）算法基于WLC算法。舉個例子吧，ABC三臺服務器的權重分別為1、2、3 。那么如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED算法后會進行一個運算

A：（1+1）/1=2 B：（1+2）/2=3/2 C：（1+3）/3=4/3 就把請求交給得出運算結果最小的服務器。

10.最少隊列調度

最少隊列調度（Never Queue 簡稱’NQ’）算法，無需隊列。如果有realserver的連接數等于0就直接分配過去，不需要在進行SED運算。

三種轉發規則

NAT：簡單理解，就是數據進出都通過 LVS，性能不是很好。
TUNL：簡單理解：隧道。
DR:最高效的負載均衡規則。

NAT

NAT（Network Address Translation）即網絡地址轉換，其作用是通過數據報頭的修改，使得位于企業內部的私有IP地址可以訪問外網，以及外部用用戶可以訪問位于公司內部的私有IP主機。VS/NAT工作模式拓撲結構如圖2所示，LVS負載調度器可以使用兩塊網卡配置不同的IP地址，eth0設置為私鑰IP與內部網絡通過交換設備相互連接，eth1設備為外網IP與外部網絡聯通。

第一步，用戶通過互聯網DNS服務器解析到公司負載均衡設備上面的外網地址，相對于真實服務器而言，LVS外網IP又稱VIP（Virtual IP Address），用戶通過訪問VIP，即可連接后端的真實服務器（Real Server），而這一切對用戶而言都是透明的，用戶以為自己訪問的就是真實服務器，但他并不知道自己訪問的VIP僅僅是一個調度器，也不清楚后端的真實服務器到底在哪里、有多少真實服務器。

第二步，用戶將請求發送至124.126.147.168，此時LVS將根據預設的算法選擇后端的一臺真實服務器（192.168.0.1~192.168.0.3），將數據請求包轉發給真實服務器，并且在轉發之前LVS會修改數據包中的目標地址以及目標端口，目標地址與目標端口將被修改為選出的真實服務器IP地址以及相應的端口。

第三步，真實的服務器將響應數據包返回給LVS調度器，調度器在得到響應的數據包后會將源地址和源端口修改為VIP及調度器相應的端口，修改完成后，由調度器將響應數據包發送回終端用戶，另外，由于LVS調度器有一個連接Hash表，該表中會記錄連接請求及轉發信息，當同一個連接的下一個數據包發送給調度器時，從該Hash表中可以直接找到之前的連接記錄，并根據記錄信息選出相同的真實服務器及端口信息。

TUN

在LVS（NAT）模式的集群環境中，由于所有的數據請求及響應的數據包都需要經過LVS調度器轉發，如果后端服務器的數量大于10臺，則調度器就會成為整個集群環境的瓶頸。我們知道，數據請求包往往遠小于響應數據包的大小。因為響應數據包中包含有客戶需要的具體數據，所以LVS（TUN）的思路就是將請求與響應數據分離，讓調度器僅處理數據請求，而讓真實服務器響應數據包直接返回給客戶端。VS/TUN工作模式拓撲結構如圖3所示。其中，IP隧道（IP tunning）是一種數據包封裝技術，它可以將原始數據包封裝并添加新的包頭（內容包括新的源地址及端口、目標地址及端口），從而實現將一個目標為調度器的VIP地址的數據包封裝，通過隧道轉發給后端的真實服務器（Real Server），通過將客戶端發往調度器的原始數據包封裝，并在其基礎上添加新的數據包頭（修改目標地址為調度器選擇出來的真實服務器的IP地址及對應端口），LVS（TUN）模式要求真實服務器可以直接與外部網絡連接，真實服務器在收到請求數據包后直接給客戶端主機響應數據。

DR

在LVS（TUN）模式下，由于需要在LVS調度器與真實服務器之間創建隧道連接，這同樣會增加服務器的負擔。與LVS（TUN）類似，DR模式也叫直接路由模式，其體系結構如圖4所示，該模式中LVS依然僅承擔數據的入站請求以及根據算法選出合理的真實服務器，最終由后端真實服務器負責將響應數據包發送返回給客戶端。與隧道模式不同的是，直接路由模式（DR模式）要求調度器與后端服務器必須在同一個局域網內，VIP地址需要在調度器與后端所有的服務器間共享，因為最終的真實服務器給客戶端回應數據包時需要設置源IP為VIP地址，目標IP為客戶端IP，這樣客戶端訪問的是調度器的VIP地址，回應的源地址也依然是該VIP地址（真實服務器上的VIP），客戶端是感覺不到后端服務器存在的。由于多臺計算機都設置了同樣一個VIP地址，所以在直接路由模式中要求調度器的VIP地址是對外可見的，客戶端需要將請求數據包發送到調度器主機，而所有的真實服務器的VIP地址必須配置在Non-ARP的網絡設備上，也就是該網絡設備并不會向外廣播自己的MAC及對應的IP地址，真實服務器的VIP對外界是不可見的，但真實服務器卻可以接受目標地址VIP的網絡請求，并在回應數據包時將源地址設置為該VIP地址。調度器根據算法在選出真實服務器后，在不修改數據報文的情況下，將數據幀的MAC地址修改為選出的真實服務器的MAC地址，通過交換機將該數據幀發給真實服務器。整個過程中，真實服務器的VIP不需要對外界可見。

lvs 的體系結構

最前端的負載均衡層，用 Load Balancer 表示
中間的服務器集群層，用 Server Array 表示
最底端的數據共享存儲層，用 Shared Storage 表示
在用戶看來，所有的內部應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務

和keepAlived 組合使用

因為所有的請求都要經過負載均衡，所以負載均衡必然是非常重要，不能掛掉，說白了就是要 keep the lvs alived。
提供的功能就是可以配置 2 臺 LVS，一臺主機，一臺備機。并且檢測任何一個節點是否還活著。

lvs 的優點

抗負載能力強，因為 lvs 工作方式的邏輯是非常之簡單，而且工作在網絡 4 層僅做請求分發之用，沒有流量，所以在效率上基本不需要太過考慮。
有完整的雙機熱備方案，當節點出現故障時，lvs 會自動判別，所以系統整體是非常穩定的。
基本上能支持所有應用，因為 lvs 工作在 4 層，所以它可以對幾乎所有應用做負載均衡，包括 http、數據庫、聊天室等等。

lvs 負載均衡機制

lvs 是四層負載均衡，也就是說建立在 OSI 模型的第四層——傳輸層之上
傳輸層上有 TCP/UDP，lvs 支持 TCP/UDP 的負載均衡
因為 LVS 是四層負載均衡，因此它相對于其它高層負載均衡的解決辦法，比如 DNS 域名輪流解析、應用層負載的調度、客戶端的調度等，它的效率是非常高的
lvs 的轉發可以通過修改 IP 地址實現（NAT 模式）
lvs 的轉發還可以通過修改直接路由實現（DR 模式）

lvs+keepAlived 的應用場景

大型網站負載均衡。

lvs 與 nginx 對比（簡單）

負載度： lvs 優于 nginx
穩定度： lvs 優于 nginx
服務器性能要求： lvs 優于 nginx
網絡層數的效率： lvs 優于 nginx（網絡七層：應用層、會話層、表示層、傳輸層、網絡層、鏈路層、物理層）
功能多少： nginx 優于 lvs

lvs與nginx區別（深度）

lvs和nginx都可以用作多機負載方案，他們各有優缺點，在生產環境中需要好好分析實際情況并加以利用。

一、lvs的優勢

1.抗負載能力強，因為lvs工作方式的邏輯是非常簡單的，而且工作再網絡層第4層，僅作請求分發用，沒有流量，所以在效率上基本不需要太過考慮。lvs一般很少出現故障，即使出現故障一般也是其他地方（如內存、CPU等）出現問題導致lvs出現問題。

2.配置性地，這通常是一大劣勢同時也是一大優勢，因為沒有太多的可配置的選項，所以除了增減服務器，并不需要經常去觸碰它，大大減少了人為出錯的幾率。

3.工作穩定，因為其本省抗負載能力很強，所以穩定性高也是順理成章的事，另外各種lvs都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什么問題，節點出現故障的話，lvs會自動判別，所以系統整體式非常穩定的。

4.無流量，lvs僅僅分發請求，而流量并不從它本身出去，所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。

5.lvs基本上能支持所有應用，因為綠色工作在第4層，所以它可以對幾乎所有應用做負載均衡，包括http、數據庫、聊天室等。

另外：lvs也不是完全能判別節點故障的，比如在wlc分配方式下，集群里有一個節點沒有配置vip，會使整個集群不能使用，這時使用wrr分配方式則會丟掉一臺機器。目前這個問題還在進一步測試中。所以用lvs也得多多當心為妙。

二、nginx和lvs作對比的結果

1.nginx工作在網絡的第7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下lvs并不具備這樣的功能，所以nginx單憑這點可以利用的場合就遠多于lvs了；但nginx有用的這些功能使其可調整度要高于lvs，所以經常要去觸碰觸碰，由lvs的第2條優點來看，觸碰多了，人為出現問題的幾率也就會大。

2.nginx對網絡的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當于單機擁有了備份線路；lvs就比較依賴于網絡環境，目前來看服務器在同一網段內并且lvs使用direct方式分流，效果較能得到保證。另外注意，lvs需要向托管商至少申請多于一個ip來做visual ip，貌似是不能用本省的ip來做VIP的。要做好lvs管理員，確實得跟進學習很多有關網絡通信方面的知識，就不再是一個http那么簡單了。

3.nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日志打印出來。lvs的安裝和配置、測試就要花比較長的時間，因為同上所述，lvs對網絡依賴性比較大，很多時候不能配置成功都是因為網絡問題而不是配置問題，出了問題要解決也相應的會麻煩的多。

4.nginx也同樣能承受很高負載且穩定，但負載度很穩定度差lvs還有幾個等級：nginx處理所有流量所以受限于機器IO和配置；本身的bug也還是難以避免的；nginx沒有現成的雙機熱備方案，所以跑在單機上還是風險比較大，單機上的事情全都很難說。

5.nginx可以檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節點。目前lvs中ldirectd也能支持針對服務器內部的情況來監控，但lvs的原理使其不能重發請求。重發請求這點，比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，nginx會把上傳切到另一臺服務器重新處理，而lvs就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而惱火。

6.nginx對請求的異步處理可以幫助節點服務器減輕負載，鍵入使用Apache直接對外服務，那么出現很多的窄帶鏈接時Apache服務器將會占用大量內存而不能釋放，使用多于一個nginx做Apache代理的話，這些窄帶鏈接會被nginx擋住，Apache上就不會堆積過多的請求，這樣就減少了相當多的內存占用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對Apache還是有很大幫助你的。lvs沒有這些功能，也就無法能比較。

7.nginx能支持http和Email（Email的功能估計比較少人用），lvs所支持的應用在這點上會比nginx更過。

在使用上，一般最前端所采取的的策略應是lvs，也就是dns的指向應為lvs均衡器，lvs的優點另它非常適合做這個任務。

重要的ip地址，最好交由lvs托管，比如數據庫的ip、webservice服務器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而來。所以將這些重要ip交給lvs托管式最為穩妥的，這樣做的唯一缺點是需要VIP數量會比較多。

nginx可以作為lvs節點機器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比nginx弱不少，性能上也有所遜色于nginx。

nginx也可以作為中層代理使用，這一層面nginx基本上無對手，唯一可以撼動nginx的就只有lighttpd了，不過lighttpd目前還沒有能做到nginx完全的功能，配置也不那么清晰易讀。另外，中層代理的ip也是重要的，所以中層代理業擁有一個VIP和lvs是最完美的方案了。

nginx也可以作為網頁靜態服務器。

具體的應用還得具體分析，如果是比較小的網站（日pv<1000萬），用nginx就完全可以了，如果機器也不少，可以用dns輪詢，lvs所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候要多多考慮利用lvs。

說明

使用nginx+keepalived實現負載均衡，解決單點與高流量并發問題。為什么要用nginx而不用lvs？

7個理由：

1.高并發連接：官方測試能夠支撐5萬并發連接，在實際生產環境中跑到2——3萬并發連接數。

2.內存消耗少：在3萬并發連接數下，開啟的10個nginx進程才消耗150M內存（150*10=150M）。

3.配置文件非常簡單：風格跟程序一樣通俗易懂。

4.成本低廉：nginx為開源軟件，可以免費使用。而購買F5 big-ip、netscaler等硬件負載均衡交換機則需要十多萬至幾十萬人民幣。

（使用nginx做七層負載均衡的理由？）

5.支持rewrite重寫規則：能夠根據域名、url的不同，將http請求分到不同的后端服務器群組。

6.內置的健康檢查功能：如果nginx proxy后端的某臺web服務器宕機了，不會影響前端訪問。

7.節省帶寬：支持gzip壓縮，可以添加瀏覽器本地緩存的header頭。

進一步說明

keepalived是linux下面實現vrrp備份路由的高可靠性運行件。基于keepalived設計的服務模式能夠真正做到主服務器和備份服務器故障時ip瞬間無縫交接。

nginx是基于linux2.6內核中epoll模型http服務器，與Apache進程派生模式不同的是nginx進程基于master+slave多進程模型，自身具有非常穩定的子進程管理功能。在master進程分配模式下，master進程永遠不進行業務處理，只是進行任務分發，從而達到master進程的存活高可靠性，slave進程所有的業務信號都由主進程發出，slave進城所有的超時任務都會被master終止，屬于阻塞式人物模型。

服務器ip存活檢測是由keepalived自己本身完成的，將2臺服務器配置成keepalived互為主輔關系，任意一方機器故障對方都能夠將ip接管過去。

keepalived的服務器ip通過其配置文件進行管理，依靠其自身的進程去確定服務器的存活狀態，如果在需要對服務器進程在線維護的情況下，只需要停掉被維護機器的keepalived服務進程，另外一臺服務器就能夠接管該臺服務器的所有應用。

現實意義

nginx實現了web服務器的高可用，如果流量入口的nginx服務器掛了，那么就web服務不可用了。
所以在nginx做負載均衡之前，用lvs做osi網絡協議的四層負載均衡，實現nginx的高可用。lvs主要解決的是這個問題。

nginx配置https

#server端基本配置 server { listen 80; listen 443 ssl spdy; server_name io.123.com; include ssl/io.com;　　　　　　#注意看下一個文件 location / { proxy_pass http:``//lb_io; if``($scheme = http ) { return``301 https:``//$host$request_uri;　　　　#此項配置為轉換為https的基本配置 } proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection``"upgrade"``; } access_log /data/logs/nginx/access/niuaero.log main; } ssl_certificate ssl/ca/io.com.pem;　　　　#這個為購買的https證書，供應商會生成 ssl_certificate_key ssl/ca/io.com.key; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #啟用TLS1.1、TLS1.2要求OpenSSL1.0.1及以上版本，若您的OpenSSL版本低于要求，請使用 ssl_protocols TLSv1; ssl_ciphers HIGH:!RC4:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!EXP:+MEDIUM; ssl_prefer_server_ciphers ``on``;

nginx配置反爬蟲

#以下內容添加nginx虛擬主機配置里，proxypass之后if ($http_user_agent ~* (Scrapy|Curl|HttpClient)) { return``403; }

#禁止指定UA及UA為空的訪問
if( $KaTeX parse error: Expected group after '^' at position 413: \dotsts|Linguee Bot|^?$ ") {
return 403; `
}

#禁止非GET|HEAD|POST方式的抓取

if`($request_method !~ ^(GET|HEAD|POST)$) { return 403; }

nginx日志分析

Nginx日志格式

$remote_addr - $remote_user [$ time_local] “$request” $status $body_bytes_sent "$ http_referer" “ $http_user_agent" "$ http_x_forwarded_for”’

1）統計日志中訪問最多的10個IP

思路：對第一列進行去重，并輸出出現的次數

方法1：

awk '{a[$1]++}END{for(i in a)print a[i],i|"sort -k1 -nr|head -n10"}' access.log

方法2：

awk ‘{print $1}’ access.log |sort |uniq -c |sort -k1 -nr |head -n10

說明：a[$1]++ 創建數組a，以第一列作為下標，使用運算符++作為數組元素，元素初始值為0。處理一個IP時，下標是IP，元素加1，處理第二個IP時，下標是IP，元素加1，如果這個IP已經存在，則元素再加1，也就是這個IP出現了兩次，元素結果是2，以此類推。因此可以實現去重，統計出現次數。

2）統計日志中訪問大于100次的IP

方法1：awk ‘{a[$1]++}END{for(i in a){if(a[i]>100)print i,a[i]}}’ access.log

方法2：awk ‘{a[$1]++;if(a[$1]>100){b[$1]++}}END{for(i in b){print i,a[i]}}’ access.log

說明：方法1是將結果保存a數組后，輸出時判斷符合要求的IP。方法2是將結果保存a數組時，并判斷符合要求的IP放到b數組，最后打印b數組的IP。

3）統計2019年3月14日一天內訪問最多的10個IP

思路：先過濾出這個時間段的日志，然后去重，統計出現次數

方法1:awk ‘$4>=“[14/Mar/2019:00:00:01” && $4<=“[14/Mar/2019:23:59:59” {a[$1]++}END{for(i in a)print a[i],i|“sort -k1 -nr|head -n10”}’ access.log

方法2： sed -n ‘/[14/Mar/2019:00:00:01/,/[14/Mar/2019:23:59:59/p’ access.log |sort |uniq -c |sort -k1 -nr |head -n10 #前提開始時間與結束時間日志中必須存在

4）統計訪問最多的前10個頁面（$request）

awk ‘{a[$7]++}END{for(i in a)print a[i],i|“sort -k1 -nr|head -n10”}’ access.log

5）統計每個URL訪問內容的總大小（$body_bytes_sent）

awk ‘{a[$7]++;size[$7]+=$10}END{for(i in a)print a[i],size[i],i}’ access.log

6）統計每個IP訪問狀態碼數量（$status）

awk ‘{a[$1" "$9]++}END{for(i in a)print i,a[i]}’ access.log

7）統計訪問狀態碼為404的IP及出現次數

awk ‘{if($9~/404/)a[$1" "$9]++}END{for(i in a)print i,a[i]}’ access.log

優化Nginx中FastCGI參數

優化項

fastcgi_cache_path/usr/local/nginx/fastcgi_cache levels=1:2keys_zone=TEST:10minactive=5m;

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

fastcgi_buffer_size 64k;

fastcgi_buffers 464k;

fastcgi_busy_buffers_size 128k;

fastcgi_temp_file_write_size 128k;

fastcgi_cache TEST;

fastcgi_cache_valid 2003021h;

fastcgi_cache_valid 3011d;

fastcgi_cache_valid any 1m;

說明

第一行是為FastCGI緩存指定一個文件路徑、目錄結構等級、關鍵字區域存儲時間和非活動刪除時間。
fastcgi_connect_timeout指定連接到后端FastCGI的超時時間。
fastcgi_send_timeout指定向FastCGI傳送請求的超時時間，這個值是已經完成兩次握手后向FastCGI傳送請求的超時時間。
fastcgi_read_timeout指定接收FastCGI應答的超時時間，這個值是已經完成兩次握手后接收FastCGI應答的超時時間。
fastcgi_buffer_size用于指定讀取FastCGI應答第一部分需要用多大的緩沖區，這個值表示將使用1個64KB的緩沖區讀取應答的第一部分（應答頭），可以設置為fastcgi_buffers選項指定的緩沖區大小。
fastcgi_buffers指定本地需要用多少和多大的緩沖區來緩沖FastCGI的應答請求。如果一個PHP腳本所產生的頁面大小為256KB，那么會為其分配4個64KB的緩沖區來緩存；如果頁面大小大于256KB，那么大于256KB的部分會緩存到fastcgi_temp指定的路徑中，但是這并不是好方法，因為內存中的數據處理速度要快于硬盤。一般這個值應該為站點中PHP腳本所產生的頁面大小的中間值，如果站點大部分腳本所產生的頁面大小為256KB，那么可以把這個值設置為“16 16k”、“4 64k”等。
fastcgi_busy_buffers_size的默認值是fastcgi_buffers的兩倍。
fastcgi_temp_file_write_size表示在寫入緩存文件時使用多大的數據塊，默認值是fastcgi_buffers的兩倍。
fastcgi_cache表示開啟FastCGI緩存并為其指定一個名稱。開啟緩存非常有用，可以有效降低CPU的負載，并且防止502錯誤的發生，但是開啟緩存也會引起很多問題，要視具體情況而定。
fastcgi_cache_valid、fastcgi用來指定應答代碼的緩存時間，實例中的值表示將200和302應答緩存一個小時，將301應答緩存1天，其他應答均緩存1分鐘。

總結

以上是生活随笔為你收集整理的Nginx面试题整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：计算机网申兴趣爱好怎么写,银行网申个人特
下一篇：计算机网络asp视频教程,轻轻松松学编程