nginx的超时场景

场景

我就是认真：正确保障网络连接状态的通断，一文读懂Keepalive工作机制_网易订阅

nginx请求服务端

nginx的代理时间（请求服务端的读取数据时间为30s），服务端的响应时间为60s

nginx发送syn包给服务端

服务端发送syn和ack包给nginx

nginx发送ack给服务端

开始数据传输：nginx发送http请求给服务端

服务端返回ack给nginx

nginx此时等待服务端的数据返回

nginx读取时间30s到时，nginx主动断开连接，nginx发送FIN给服务端（也有可能会带ACK，但是这个标识没有用，没什么意义）

服务端发送ACK给nginx

但是服务端不想断开连接，所以服务端没有发送FIN，此时连接为半关闭状态。此时按理说nginx可以接受服务端的数据，但是nginx已经不接收了（这个可能是nginx自己的设置，跟tcp协议不一样的地方）。

等服务端到60s后，服务端数据已经处理完成，发送http包给nginx。

nginx接受到数据包后，（不是FIN包，nginx此时只接受FIN包，这个应该是nginx自己的设置），会发送RST包给服务端。

服务端收到RST包后，需要重置链接（重新发起SYN包）

客户端浏览器与nginx

浏览器发送syn到nginx

nginx发送ack和syn到浏览器

浏览器发送ack到nginx

浏览器发送http请求到nginx

浏览器等待nginx的响应，nginx此时发送请求到上游，因为nginx此时始终没有发送数据给浏览器，所以keepalive_timeout始终不会计时。

nginx到达30s的读取服务端时间后，因为没有从服务端获取到数据，所以此时发送给浏览器http请求504超时的数据包。

浏览器发送ack给nginx

此时nginx继续等待到65s的keepalive_timeout时间后，发送FIN包给浏览器

浏览器收到FIN后，发送ack到nginx

然后浏览器发送FIN给nginx，

nginx收到FIN后，发送ack给浏览器

浏览器收到ack后进入CLOSE状态

ningx等待2MSL后进入CLOSE状态