1.Nginx介紹

1.1 什麼是Nginx

Nginx (engine x) 是一個高性能的HTTP和反向代理web服務器，同時也提供了IMAP/POP3/SMTP服務。

那麼何爲正向代理與反向代理呢？說白了，正向代理就是客戶端的代理，反向代理就是服務器端的代理。

1.2 Nginx能做什麼

作爲 Web 服務器：相比 Apache，Nginx 使用更少的資源，支持更多的併發連接，體現更高的效率，這點使 Nginx 尤其受到虛擬主機提供商的歡迎。能夠支持高達 50,000 個併發連接數的響應，感謝 Nginx 爲我們選擇了 epoll and kqueue 作爲開發模型
作爲負載均衡服務器：Nginx 既可以在內部直接支持 Rails 和 PHP，也可以支持作爲 HTTP代理服務器對外進行服務。Nginx 用 C 編寫, 不論是系統資源開銷還是 CPU 使用效率都比 Perlbal 要好的多。
作爲郵件代理服務器：Nginx 同時也是一個非常優秀的郵件代理服務器（最早開發這個產品的目的之一也是作爲郵件代理服務器），Last.fm 描述了成功並且美妙的使用經驗。

1.3 爲什麼要選擇用Nginx

作爲Web服務器，Nginx處理靜態文件、索引文件，自動索引的效率非常高
作爲代理服務器，Nginx可以實現無緩存的反向代理加速，提高網站運行速度
作爲負載均衡服務器，Nginx既可以在內部直接支持Rails和PHP，也可以支持HTTP代理服務器對外進行服務，同時還支持簡單的容錯和利用算法進行負載均衡
在性能方面，Nginx是專門爲性能優化而開發的，實現上非常注重效率。它採用內核Poll模型，可以支持更多的併發連接，最大可以支持對5萬個併發連接數的響應，而且只佔用很低的內存資源
在穩定性方面，Nginx採取了分階段資源分配技術，使得CPU與內存的佔用率非常低。Nginx官方表示，Nginx保持1萬個沒有活動的連接，而這些連接只佔用2.5MB內存，因此，類似DOS這樣的攻擊對Nginx來說基本上是沒有任何作用的
在高可用性方面，Nginx支持熱部署，啓動速度特別迅速，因此可以在不間斷服務的情況下，對軟件版本或者配置進行升級，即使運行數月也無需重新啓動，幾乎可以做到7x24小時不間斷地運行
Nginx 安裝非常的簡單，配置文件非常簡潔（還能夠支持perl語法），Bugs非常少的服務器: Nginx 啓動特別容易，並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啓動

2.Nginx的安裝與配置

2.1 Nginx 安裝

系統平臺：CentOS release 6.6 (Final) 64位。

一、安裝編譯工具及庫文件

yum -y install make zlib zlib-devel gcc-c++ libtool openssl openssl-devel

二、首先要安裝 PCRE

PCRE 作用是讓 Nginx 支持 Rewrite 功能。

1、下載 PCRE 安裝包，下載地址： http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gz

[root@bogon src]# wget http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gz

2、解壓安裝包:

[root@bogon src]# tar zxvf pcre-8.35.tar.gz

3、進入安裝包目錄

[root@bogon src]# cd pcre-8.35

4、編譯安裝

[root@bogon pcre-8.35]# ./configure [root@bogon pcre-8.35]# make && make install

5、查看pcre版本

[root@bogon pcre-8.35]# pcre-config --version

三、安裝 Nginx

1、下載 Nginx，下載地址：http://nginx.org/download/nginx-1.6.2.tar.gz

[root@bogon src]# wget http://nginx.org/download/nginx-1.6.2.tar.gz

2、解壓安裝包

[root@bogon src]# tar zxvf nginx-1.6.2.tar.gz

3、進入安裝包目錄

[root@bogon src]# cd nginx-1.6.2

4、編譯安裝

[root@bogon nginx-1.6.2]# ./configure --prefix=/usr/local/webserver/nginx --with-http_stub_status_module --with-http_ssl_module --with-pcre=/usr/local/src/pcre-8.35 [root@bogon nginx-1.6.2]# make [root@bogon nginx-1.6.2]# make install

5、查看nginx版本

[root@bogon nginx-1.6.2]# /usr/local/webserver/nginx/sbin/nginx -v

到此，nginx安裝完成。

2.2 Nginx配置

注：紅色字體內容爲配置說明

Nginx的配置文件nginx.conf配置詳解如下：

user nginx nginx ;

#Nginx用戶及組：用戶組。window下不指定

worker_processes 8;

#工作進程：數目。根據硬件調整，通常等於CPU數量或者2倍於CPU。

error_log  logs/error.log;

error_log  logs/error.log  notice;

error_log  logs/error.log  info;

#錯誤日誌：存放路徑。

pid logs/nginx.pid;

#pid（進程標識符）：存放路徑。

worker_rlimit_nofile 204800;

指定進程可以打開的最大描述符：數目。

這個指令是指當一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（ulimit -n）與nginx進程數相除，但是nginx分配請求並不是那麼均勻，所以最好與ulimit -n 的值保持一致。

現在在Linux 2.6內核下開啓文件打開數爲65535，worker_rlimit_nofile就相應應該填寫65535。

這是因爲nginx調度時分配請求到進程並不是那麼的均衡，所以假如填寫10240，總併發量達到3-4萬時就有進程可能超過10240了，這時會返回502錯誤。

events

{

use epoll;

#使用epoll的I/O 模型。linux建議epoll，FreeBSD建議採用kqueue，window下不指定。

補充說明:

與apache相類，nginx針對不同的操作系統，有不同的事件模型

A）標準事件模型

Select、poll屬於標準事件模型，如果當前系統不存在更有效的方法，nginx會選擇select或poll

B）高效事件模型

Kqueue：使用於FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用雙處理器的MacOS X系統使用kqueue可能會造成內核崩潰。

Epoll：使用於Linux內核2.6版本及以後的系統。

/dev/poll：使用於Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。

Eventport：使用於Solaris 10。爲了防止出現內核崩潰的問題，有必要安裝安全補丁。

worker_connections 204800;

#每個工作進程的最大連接數量。根據硬件調整，和前面工作進程配合起來用，儘量大，但是別把cpu跑到100%就行。每個進程允許的最多連接數，理論上每臺nginx服務器的最大連接數爲。worker_processes*worker_connections

keepalive_timeout 60;

#keepalive超時時間。

client_header_buffer_size 4k;

#客戶端請求頭部的緩衝區大小。這個可以根據你的系統分頁大小來設置，一般一個請求頭的大小不會超過1k，不過由於一般系統分頁都要大於1k，所以這裏設置爲分頁大小。

分頁大小可以用命令getconf PAGESIZE 取得。

[root@web001 ~]# getconf PAGESIZE

4096

但也有client_header_buffer_size超過4k的情況，但是client_header_buffer_size該值必須設置爲“系統分頁大小”的整倍數。

open_file_cache max=65535 inactive=60s;

#這個將爲打開文件指定緩存，默認是沒有啓用的，max指定緩存數量，建議和打開文件數一致，inactive是指經過多長時間文件沒被請求後刪除緩存。

open_file_cache_valid 80s;

#這個是指多長時間檢查一次緩存的有效信息。

open_file_cache_min_uses 1;

#open_file_cache指令中的inactive參數時間內文件的最少使用次數，如果超過這個數字，文件描述符一直是在緩存中打開的，如上例，如果有一個文件在inactive時間內一次沒被使用，它將被移除。

}

##設定http服務器，利用它的反向代理功能提供負載均衡支持

http

{

include mime.types;

#設定mime類型,類型由mime.type文件定義

default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';

#日誌格式設置。

$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址；

$remote_user：用來記錄客戶端用戶名稱；

$time_local：用來記錄訪問時間與時區；

$request：用來記錄請求的url與http協議；

$status：用來記錄請求狀態；成功是200，

$body_bytes_sent ：記錄發送給客戶端文件主體內容大小；

$http_referer：用來記錄從那個頁面鏈接訪問過來的；

$http_user_agent：記錄客戶瀏覽器的相關信息；

通常web服務器放在反向代理的後面，這樣就不能獲取到客戶的IP地址了，通過$remote_add拿到的IP地址是反向代理服務器的iP地址。反向代理服務器在轉發請求的http頭信息中，可以增加x_forwarded_for信息，用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址。

access_log  logs/host.access.log  main;

access_log  logs/host.access.404.log  log404;

#用了log_format指令設置了日誌格式之後，需要用access_log指令指定日誌文件的存放路徑；

server_names_hash_bucket_size 128;

#保存服務器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。參數hash bucket size總是等於hash表的大小，並且是一路處理器緩存大小的倍數。在減少了在內存中的存取次數後，使在處理器中加速查找hash表鍵值成爲可能。如果hash bucket size等於一路處理器緩存的大小，那麼在查找鍵的時候，最壞的情況下在內存中查找的次數爲2。第一次是確定存儲單元的地址，第二次是在存儲單元中查找鍵值。因此，如果Nginx給出需要增大hash max size 或 hash bucket size的提示，那麼首要的是增大前一個參數的大小.

client_header_buffer_size 4k;

#客戶端請求頭部的緩衝區大小。這個可以根據你的系統分頁大小來設置，一般一個請求的頭部大小不會超過1k，不過由於一般系統分頁都要大於1k，所以這裏設置爲分頁大小。分頁大小可以用命令getconf PAGESIZE取得。

large_client_header_buffers 8 128k;

#客戶請求頭緩衝大小。nginx默認會用client_header_buffer_size這個buffer來讀取header值，如果

header過大，它會使用large_client_header_buffers來讀取。

open_file_cache max=102400 inactive=20s;

#這個指令指定緩存是否啓用。

例: open_file_cache max=1000 inactive=20s;

open_file_cache_valid 30s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

open_file_cache_errors

#語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.

open_file_cache_min_uses

#語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location 這個指令指定了在open_file_cache指令無效的參數中一定的時間範圍內可以使用的最小文件數,如果使用更大的值,文件描述符在cache中總是打開狀態.

open_file_cache_valid

#語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了何時需要檢查open_file_cache中緩存項目的有效信息.

client_max_body_size 300m;

#設定通過nginx上傳文件的大小

sendfile on;

#sendfile指令指定 nginx 是否調用sendfile 函數（zero copy 方式）來輸出文件，對於普通應用，必須設爲on。如果用來進行下載等應用磁盤IO重負載應用，可設置爲off，以平衡磁盤與網絡IO處理速度，降低系統uptime。

tcp_nopush on;

#此選項允許或禁止使用socke的TCP_CORK的選項，此選項僅在使用sendfile的時候使用

proxy_connect_timeout 90;

#後端服務器連接的超時時間_發起握手等候響應超時時間

proxy_read_timeout 180;

#連接成功後_等候後端服務器響應時間_其實已經進入後端的排隊之中等候處理（也可以說是後端服務器處理請求的時間）

proxy_send_timeout 180;

#後端服務器數據回傳時間_就是在規定時間之內後端服務器必須傳完所有的數據

proxy_buffer_size 256k;

#設置從被代理服務器讀取的第一部分應答的緩衝區大小，通常情況下這部分應答中包含一個小的應答頭，默認情況下這個值的大小爲指令proxy_buffers中指定的一個緩衝區的大小，不過可以將其設置爲更小

proxy_buffers 4 256k;

#設置用於讀取應答（來自被代理服務器）的緩衝區數目和大小，默認情況也爲分頁大小，根據操作系統的不同可能是4k或者8k

proxy_busy_buffers_size 256k;

proxy_temp_file_write_size 256k;

#設置在寫入proxy_temp_path時數據的大小，預防一個工作進程在傳遞文件時阻塞太長

proxy_temp_path /data0/proxy_temp_dir;

#proxy_temp_path和proxy_cache_path指定的路徑必須在同一分區

proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;

#設置內存緩存空間大小爲200MB，1天沒有被訪問的內容自動清除，硬盤緩存空間大小爲30GB。

keepalive_timeout 120;

#keepalive超時時間。

tcp_nodelay on;

client_body_buffer_size 512k;

#如果把它設置爲比較大的數值，例如256k，那麼，無論使用firefox還是IE瀏覽器，來提交任意小於256k的圖片，都很正常。如果註釋該指令，使用默認的client_body_buffer_size設置，也就是操作系統頁面大小的兩倍，8k或者16k，問題就出現了。

無論使用firefox4.0還是IE8.0，提交一個比較大，200k左右的圖片，都返回500 Internal Server Error錯誤

proxy_intercept_errors on;

#表示使nginx阻止HTTP應答代碼爲400或者更高的應答。

upstream bakend {

server 127.0.0.1:8027;

server 127.0.0.1:8028;

server 127.0.0.1:8029;

hash $request_uri;

}

#nginx的upstream目前支持4種方式的分配

1、輪詢（默認）

每個請求按時間順序逐一分配到不同的後端服務器，如果後端服務器down掉，能自動剔除。

2、weight

指定輪詢機率，weight和訪問比率成正比，用於後端服務器性能不均的情況。

例如：

upstream bakend {

server 192.168.0.14 weight=10;

server 192.168.0.15 weight=10;

}

2、ip_hash

每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端服務器，可以解決session的問題。

例如：

upstream bakend {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

3、fair（第三方）

按後端服務器的響應時間來分配請求，響應時間短的優先分配。

upstream backend {

server server1;

server server2;

fair;

}

4、url_hash（第三方）

按訪問url的hash結果來分配請求，使每個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。

例：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash算法

upstream backend {

server squid1:3128;

server squid2:3128;

hash $request_uri;

hash_method crc32;

}

tips:

upstream bakend{#定義負載均衡設備的Ip及設備狀態}{

ip_hash;

server 127.0.0.1:9090 down;

server 127.0.0.1:8080 weight=2;

server 127.0.0.1:6060;

server 127.0.0.1:7070 backup;

}

在需要使用負載均衡的server中增加

proxy_pass http://bakend/;

每個設備的狀態設置爲:

1.down表示單前的server暫時不參與負載

2.weight爲weight越大，負載的權重就越大。

3.max_fails：允許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤

4.fail_timeout:max_fails次失敗後，暫停的時間。

5.backup：其它所有的非backup機器down或者忙的時候，請求backup機器。所以這臺機器壓力會最輕。

nginx支持同時設置多組的負載均衡，用來給不用的server來使用。

client_body_in_file_only設置爲On 可以講client post過來的數據記錄到文件中用來做debug

client_body_temp_path設置記錄文件的目錄可以設置最多3層目錄

location對URL進行匹配.可以進行重定向或者進行新的代理負載均衡

##配置虛擬機

server

{

listen 80;

#配置監聽端口

server_name image.***.com;

#配置訪問域名

location ~* \.(mp3|exe)$ {

#對以“mp3或exe”結尾的地址進行負載均衡

proxy_pass http://img_relay$request_uri;

#設置被代理服務器的端口或套接字，以及URL

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#以上三行，目的是將代理服務器收到的用戶的信息傳到真實服務器上

}

location /face {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

proxy_pass http://img_relay$request_uri;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

error_page 404 502 = @fetch;

}

location @fetch {

access_log /data/logs/face.log log404;

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

location /image {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

proxy_pass http://img_relay$request_uri;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

error_page 404 502 = @fetch;

}

location @fetch {

access_log /data/logs/image.log log404;

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

}

註釋：變量

Ngx_http_core_module模塊支持內置變量，他們的名字和apache的內置變量是一致的。

首先是說明客戶請求title中的行，例如$http_user_agent,$http_cookie等等。

此外還有其它的一些變量

$args此變量與請求行中的參數相等

$content_length等於請求行的“Content_Length”的值。

$content_type等同與請求頭部的”Content_Type”的值

$document_root等同於當前請求的root指令指定的值

$document_uri與$uri一樣

$host與請求頭部中“Host”行指定的值或是request到達的server的名字（沒有Host行）一樣

$limit_rate允許限制的連接速率

$request_method等同於request的method，通常是“GET”或“POST”

$remote_addr客戶端ip

$remote_port客戶端port

$remote_user等同於用戶名，由ngx_http_auth_basic_module認證

$request_filename當前請求的文件的路徑名，由root或alias和URI request組合而成

$request_body_file

$request_uri含有參數的完整的初始URI

$query_string與$args一樣

$sheeme http模式（http,https）盡在要求是評估例如

Rewrite ^(.+)$ $sheme://example.com$; Redirect;

$server_protocol等同於request的協議，使用“HTTP/或“HTTP/

$server_addr request到達的server的ip，一般獲得此變量的值的目的是進行系統調用。爲了避免系統調用，有必要在listen指令中指明ip，並使用bind參數。

$server_name請求到達的服務器名

$server_port請求到達的服務器的端口號

$uri等同於當前request中的URI，可不同於初始值，例如內部重定向時或使用index

2.3 Nginx常用操作

常用到的命令如下：

nginx -s stop ：快速關閉Nginx，可能不保存相關信息，並迅速終止web服務。
nginx -s quit ：平穩關閉Nginx，保存相關信息，有安排的結束web服務。
nginx -s reload ：因改變了Nginx相關配置，需要重新加載配置而重載。
nginx -s reopen ：重新打開日誌文件。
nginx -c filename ：爲 Nginx 指定一個配置文件，來代替缺省的。
nginx -t ：不運行，而僅僅測試配置文件。nginx 將檢查配置文件的語法的正確性，並嘗試打開配置文件中所引用到的文件。
nginx -v：顯示 nginx 的版本。
nginx -V：顯示 nginx 的版本，編譯器版本和配置參數。
sudo service nginx status ：查看nginx運行狀態
sudo service nginx restart：重啓
pkill -9 nginx：殺掉nginx運行進程

3.Nginx工作原理

首先，我們通過一個內部結構流程圖來熟悉一下Nginx的工作流程：

3.1 工作原理：

Nginx真正處理請求業務的是Worker之下的線程。worker 進程中，ngx_worker_process_cycle()函數就是這個無限循環的處理函數。在這個函數中，一個請求的簡單處理流程如下：

操作系統提供的機制（例如 epoll, kqueue 等）產生相關的事件。

接收和處理這些事件，如是接收到數據，則產生更高層的 request 對象。

處理 request 的 header 和 body。

產生響應，併發送回客戶端。

完成 request 的處理。

重新初始化定時器及其他事件。

3.1.1 Nginx處理Request請求過程解析

下面我們結合一個請求流程來理解一下Nginx整個過程當中做了哪些事。從 Nginx 的內部來看，一個 HTTP Request 的處理過程涉及到以下幾個階段：

初始化 HTTP Request（讀取來自客戶端的數據，生成 HTTP Request 對象，該對象含有該請求所有的信息）。

處理請求頭。

處理請求體。

如果有的話，調用與此請求（URL 或者 Location）關聯的 handler。

依次調用各 phase handler 進行處理。

我們再通過一個流程圖看看處理過程：

根據註釋，我們可以看到：

Nginx啓動後，首先會根據配置與對應的客戶端進行初始化連接。
而當一個Request進入後，先是對請求頭及請求體進行解析和處理。
處理過程中，通過請求頭找到對應的server config，然後與真實服務器進行連接並進行讀寫事件處理。
最後我們會看到有多個phase handler，就是包含若干個處理階段的一些 handler。一個 phase handler 對這個 request 進行處理，併產生一些輸出。通常 phase handler 是與定義在配置文件中的某個 location 相關聯的。
一個通常會做一下處理：

獲取 location 配置。
產生適當的響應。
發送 response header。
發送 response body。

3.1.2 一個完整的Request請求流程

3.2 keepalive 長連接

在nginx中，對於http1.0與http1.1也是支持長連接的。

什麼是長連接呢？我們知道，http請求是基於TCP協議之上的，那麼，當客戶端在發起請求前，需要先與服務端建立TCP連接，而每一次的TCP連接是需要三次握手來確定的，如果客戶端與服務端之間網絡差一點，這三次交互消費的時間會比較多，而且三次交互也會帶來網絡流量。當然，當連接斷開後，也會有四次的交互，當然對用戶體驗來說就不重要了。而http請求是請求應答式的，如果我們能知道每個請求頭與響應體的長度，那麼我們是可以在一個連接上面執行多個請求的，這就是所謂的長連接，但前提條件是我們先得確定請求頭與響應體的長度。

對於請求來說，如果當前請求需要有body，如POST請求，那麼nginx就需要客戶端在請求頭中指定content-length來表明body的大小，否則返回400錯誤。也就是說，請求體的長度是確定的，那麼響應體的長度呢？先來看看http協議中關於響應body長度的確定：

對於http1.0協議來說，如果響應頭中有content-length頭，則以content-length的長度就可以知道body的長度了，客戶端在接收body時，就可以依照這個長度來接收數據，接收完後，就表示這個請求完成了。而如果沒有content-length頭，則客戶端會一直接收數據，直到服務端主動斷開連接，才表示body接收完了。

而對於http1.1協議來說，如果響應頭中的Transfer-encoding爲chunked傳輸，則表示body是流式輸出，body會被分成多個塊，每塊的開始會標識出當前塊的長度，此時，body不需要通過長度來指定。如果是非chunked傳輸，而且有content-length，則按照content-length來接收數據。否則，如果是非chunked，並且沒有content-length，則客戶端接收數據，直到服務端主動斷開連接。

從上面，我們可以看到，除了http1.0不帶content-length以及http1.1非chunked不帶content-length外，body的長度是可知的。此時，當服務端在輸出完body之後，會可以考慮使用長連接。能否使用長連接，也是有條件限制的。如果客戶端的請求頭中的connection爲close，則表示客戶端需要關掉長連接，如果爲keep-alive，則客戶端需要打開長連接，如果客戶端的請求中沒有connection這個頭，那麼根據協議，如果是http1.0，則默認爲close，如果是http1.1，則默認爲keep-alive。如果結果爲keepalive，那麼，nginx在輸出完響應體後，會設置當前連接的keepalive屬性，然後等待客戶端下一次請求。

當然，nginx不可能一直等待下去，如果客戶端一直不發數據過來，豈不是一直佔用這個連接？所以當nginx設置了keepalive等待下一次的請求時，同時也會設置一個最大等待時間，這個時間是通過選項keepalive_timeout來配置的，如果配置爲0，則表示關掉keepalive，此時，http版本無論是1.1還是1.0，客戶端的connection不管是close還是keepalive，都會強制爲close。

如果服務端最後的決定是keepalive打開，那麼在響應的http頭裏面，也會包含有connection頭域，其值是”Keep-Alive”，否則就是”Close”。如果connection值爲close，那麼在nginx響應完數據後，會主動關掉連接。所以，對於請求量比較大的nginx來說，關掉keepalive最後會產生比較多的time-wait狀態的socket。一般來說，當客戶端的一次訪問，需要多次訪問同一個server時，打開keepalive的優勢非常大，比如圖片服務器，通常一個網頁會包含很多個圖片。打開keepalive也會大量減少time-wait的數量。

參考鏈接：

https://www.php.cn/nginx/421872.html

https://www.jianshu.com/p/6215e5d24553

Nginx配置使用與工作原理

1.Nginx介紹

1.1 什麼是Nginx

1.2 Nginx能做什麼

1.3 爲什麼要選擇用Nginx

2.Nginx的安裝與配置

2.1 Nginx 安裝

2.2 Nginx配置

2.3 Nginx常用操作

3.Nginx工作原理

3.1 工作原理：

3.1.1 Nginx處理Request請求過程解析

3.1.2 一個完整的Request請求流程

3.2 keepalive 長連接

985 碩士程序員，空窗 4 個月沒有 Offer！

一文搞懂 Spring 循環依賴

賽博鬥地主——使用大語言模型扮演Agent智能體玩牌類遊戲。

VScode右鍵打開(添加到右鍵)

記一次 .NET某工控視覺自動化系統卡死分析

WindowsServer--SQL Server搭建主從同步實現讀寫分離 - 事務性分發

java由於越界導致的報錯

使用IP無法連接本地虛擬機上的elasticsearch：curl: (7) Failed connect to 192.168.xxx.xxx:9200 Connection refused

Elasticsearch系列（一）：安裝elasticsearch和常用插件ik分詞器、pinyin、head等

linux切換root時，報su: Authentication failure

日常Exception（十六）：You cant specify target table xxx for update in FROM clause

Docker系列（一）：Docker安裝部署

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結