如何使用 ngx_lua 去强制关闭当前连接？

blahnice · 2013-09-23T11:28:58+00:00

Hello folks! I am happy to announce that the new stable version of ngx_openresty, 1.4.2.8, is now released: http://openresty.org/#Download Special tha...

如何使用 ngx_lua 去强制关闭当前连接？

blahnice

hi，openresty：

先谢谢春哥提供了这么好用的ngx_lua模块，现在碰倒一个问题，想咨询一下。
如果我在access_by_lua中，做访问判断，如果这个访问连接是一个恶意的请求，我想直接shutdown或者 reset 掉当前 request 的 socket 连接，应该如何去做？也就是说，不想让 nginx 执行后续 module，也不反悔任何 HTTP response以免浪费回复流量，直接发 fin 或者 rst tcp 包 close掉这个连接，应该如何实现？
貌似 lua api 里没有提供如此实现，是否必须使用 FFI 调用 nginx 的本身 api？如果是，能否给个简单的 code sample？

谢谢！

agentzh

Hello!

2013/9/22 BlahNice:
> 如果我在access_by_lua中，做访问判断，如果这个访问连接是一个恶意的请求，我想直接shutdown或者 reset 掉当前 request 的 socket 连接，应该如何去做？也就是说，不想让 nginx 执行后续 module，也不反悔任何 HTTP response以免浪费回复流量，直接发 fin 或者 rst tcp 包 close掉这个连接，应该如何实现？

很简单，一行 Lua 代码：

    return ngx.exit(444)

错误码 444 在 nginx 核心中专用于指定断开连接。

另外，请在发贴前先加入本讨论组。订阅的方法是：发送空白邮件到地址 openresty+subscribe@googlegroups.com
否则你的贴子总是需要人工审核才能发表，很麻烦。

Regards,
-agentzh

njbupt

非标准状态码444，表示以不发送任何的Header头来结束连接。

如果想要结束连接，并且发送header呢，有方式吗？

在 2013年9月23日星期一 UTC+8上午11:30:43，agentzh写道：

Hello!

2013/9/22 BlahNice:
> 如果我在access_by_lua中，做访问判断，如果这个访问连接是一个恶意的请求，我想直接shutdown或者 reset 掉当前 request 的 socket 连接，应该如何去做？也就是说，不想让 nginx 执行后续 module，也不反悔任何 HTTP response以免浪费回复流量，直接发 fin 或者 rst tcp 包 close掉这个连接，应该如何实现？

很简单，一行 Lua 代码：

return ngx.exit(444)

错误码 444 在 nginx 核心中专用于指定断开连接。

另外，请在发贴前先加入本讨论组。订阅的方法是：发送空白邮件到地址 openresty...@googlegroups.com
否则你的贴子总是需要人工审核才能发表，很麻烦。

Regards,
-agentzh

agentzh

Hello!

2016-01-21 19:11 GMT-08:00 jun ni:
> 非标准状态码444，表示以不发送任何的Header头来结束连接。
> 如果想要结束连接，并且发送header呢，有方式吗？
>

    ngx.header.connection = "close"
    ngx.eof()

Regards,
-agentzh

njbupt

谢谢春哥回复。

我的应用场景是：header已经发出去了（nginx.status=200）吐给client了，但是后面的处理逻辑server端针对一些异常情况想立即结束连接，现在每次都要等到keepalive_timeout超时，才能断开连接。

在 2016年1月22日星期五 UTC+8下午12:45:28，agentzh写道：

Hello!

2016-01-21 19:11 GMT-08:00 jun ni:
> 非标准状态码444，表示以不发送任何的Header头来结束连接。
> 如果想要结束连接，并且发送header呢，有方式吗？
>

ngx.header.connection = "close"
ngx.eof()

Regards,
-agentzh

yuansheng

> 但是后面的处理逻辑server端针对一些异常情况想立即结束连接，现在每次都要等到keepalive_timeout超时，才能断开连接

对于高并发的服务端，谁主动关闭是需要慎重考虑的。因为主动 close 的一方要承担 time_wait 的代价，

它可能会大量消耗你服务端的 TCP/IP 端口资源，直到无法响应。所以高并发服务端都是由客户端发起

close，服务端只是被动关闭。

设计好你的 HTTP 应答协议，我觉得更靠谱。例如应答体里面有个额外的字段表明后端服务状态，这样无论成功与否，都

可以在应答体中很快速回复内容（回送内容的状态码可能是失败的）。

2016-01-22 13:15 GMT+08:00 jun ni <nj...@gmail.com>:

谢谢春哥回复。
我的应用场景是：header已经发出去了（nginx.status=200）吐给client了，但是后面的处理逻辑server端针对一些异常情况想立即结束连接，现在每次都要等到keepalive_timeout超时，才能断开连接。

在 2016年1月22日星期五 UTC+8下午12:45:28，agentzh写道：
Hello!

2016-01-21 19:11 GMT-08:00 jun ni:
> 非标准状态码444，表示以不发送任何的Header头来结束连接。
> 如果想要结束连接，并且发送header呢，有方式吗？
>

ngx.header.connection = "close"
ngx.eof()

Regards,
-agentzh

--

YuanSheng Wang

---------------------------------------

My Github: https://github.com/membphis

OpenResty lover ^_^

njbupt

嗯嗯，主动关闭time_wait风险这个知道，但是我们针对一些特殊的异常情况（这个情况很少，所以端口资源被耗尽的情况出现概率很小），server端希望能够立即关闭连接，而不情愿看到 client一直等到超时。

谢谢你的回复哈～！

在 2016年1月22日星期五 UTC+8下午1:54:08，YuanSheng写道：

> 但是后面的处理逻辑server端针对一些异常情况想立即结束连接，现在每次都要等到keepalive_timeout超时，才能断开连接

对于高并发的服务端，谁主动关闭是需要慎重考虑的。因为主动 close 的一方要承担 time_wait 的代价，
它可能会大量消耗你服务端的 TCP/IP 端口资源，直到无法响应。所以高并发服务端都是由客户端发起
close，服务端只是被动关闭。

设计好你的 HTTP 应答协议，我觉得更靠谱。例如应答体里面有个额外的字段表明后端服务状态，这样无论成功与否，都
可以在应答体中很快速回复内容（回送内容的状态码可能是失败的）。

2016-01-22 13:15 GMT+08:00 jun ni <njb...@gmail.com>:
谢谢春哥回复。
我的应用场景是：header已经发出去了（nginx.status=200）吐给client了，但是后面的处理逻辑server端针对一些异常情况想立即结束连接，现在每次都要等到keepalive_timeout超时，才能断开连接。

在 2016年1月22日星期五 UTC+8下午12:45:28，agentzh写道：
Hello!

2016-01-21 19:11 GMT-08:00 jun ni:
> 非标准状态码444，表示以不发送任何的Header头来结束连接。
> 如果想要结束连接，并且发送header呢，有方式吗？
>

ngx.header.connection = "close"
ngx.eof()

Regards,
-agentzh

--

--

YuanSheng Wang
---------------------------------------
My Github: https://github.com/membphis
OpenResty lover ^_^