linux – 无需停机即可重新加载新的Nginx配置

httperf --server=127.0.0.1 --port=80 --uri=/ --num-conns=1 --num-calls=10

sudo Nginx -s reload

sudo kill -s HUP [pid]

Errors: @R_106_10586@l 1 client-timo 0 socket-timo 0 connrefused 0 connreset 1

要了解以下答案,需要一些背景知识 @H_618_17@>什么是HTTP persistent connection.
> TCP protocol的基础知识,特别是connection termination工作流程.

@H_618_17@是的,你的测试有些不正确.问题是您的测试使用PERSISTENT连接发送10个请求.您可以通过运行以下测试轻松检查它,并且您将不会重置任何连接(因为您每个连接只发送一个请求)：

httperf --server=127.0.0.1 --port=80 --uri=/ --num-conns=10 --num-calls=1

@H_618_17@如果你看一下nginx documentation,你会发现：

@H_618_17@这是事实,但文档没有提到持久连接发生了什么.我在旧的mailing list中找到了答案.在当前正在运行请求之后,Nginx将通过向客户端发送[FIN,ACK]来启动持久连接关闭.

@H_618_17@为了检查它,我使用WireShark并配置了一个简单的工作服务器,根据请求休眠5秒然后回复.我使用以下命令发送请求：

httperf --server=127.0.0.1 --port=80 --uri=/ --num-conns=1 --num-calls=2

@H_618_17@发出前面提到的命令后,我重新加载了Nginx(当它处理第一个请求时).以下是WireShark嗅探的软件包：

@H_618_17@

@H_618_17@> 3892-3894 – 通常的TCP连接建立.
> 3895 – 客户发送第一个请求.
> 3896 – 服务器承认3895.
>这里执行了Nginx重载.
> 4089 – 服务器发送响应.
> 4090 – 服务器发送了紧密的连接信号.
> 4091 – 客户承认4089.
> 4092 – 客户承认4090.
> 4093 – 客户发送第二个请求(WTF？)
> 4094 – 客户端发送了紧密的连接信号.
> 4095 – 服务器承认4093.
> 4096 – 服务器确认4094.

@H_618_17@那很好,该服务器没有向第二个请求发送任何响应.根据TCP connection termination：

@H_618_17@接下来的问题是客户收到服务器的紧密连接信号后4093发生了什么？

@H_618_17@可能这是answer：

@H_618_17@我不能对此发表评论,因为我不是网络专家.也许其他人可以提供更有见地的答案为什么发送第二个请求.

@H_618_17@UPD以前链接的问题不相关.问separate question问题.

@H_618_17@如mailing list所述：

@H_618_17@我认为它应该在客户端处理.如果连接被服务器关闭,客户端应该打开新连接并重试请求.

@H_618_17@我不知道其他服务器,所以不能在这里提出建议.

@H_618_17@一旦您的客户端正确处理连接关闭,就不应该有任何理由阻止您使用Nginx.