关于 nginx 验证 url 请求和 PHP 验证 url 请求效率问题

[2384036992]

有类似这样的 url 请求： http://aaabbbccc.com/aaa.php?uid=123456&timestamp=1542871794&nonce=abcdefghij&sign=86b2d2fe14824347a376d2a551b7c07b

我想的是在 nginx 就验证 url 是否合法，不合法直接 return 403。
webserver 用的是 openresty-1.13.6.2，php 是 php7.1，nonce 是存在 redis 里的 60 秒过期，需要从 redis 读取 nonce 值是否存在， 如果在 nginx 层面验证 timestamp，nonce 和 sign，效率会不会比在 php 里面验证效率高？会不会导致别的不需要验证的 url 请求阻塞？
验证方法写在 location /aaa.php { } 里面吗？
谢谢各位指点帮助!

[raysonx]

合适的工具做合适的事，Ngnix 就让它老老实实地做反向代理以及提供静态资源，把逻辑放在程序代码里。

[raysonx]

Nginx 官方有一篇文章，楼主英语好的话可以去读一下 https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/

[2384036992]

@raysonx 我先看下哈

[v2dead]

这种简单的事情不需要问啊，跑几个压力测试就知道了。别人的经验不见得对你的真实业务有所帮助。而且这点效率本身不见得有什么值得优化的，要是一定要上 php 的话，从部署和开发的简单性来看，肯定放到 php 端简单很多。
而且上面发的是 if is evil，但你用的是 openresty，靠 lua 模块做验证和这个似乎没什么关系。

[v2dead]

对了，这篇 ifisevil 是有中文版的，记得就在《 openresty 最佳实践》里面有介绍。

[oott123]

理论上讲你逻辑都写在 openresty 效率更高，甚至你干脆做成 nginx 模块效率还要高一些。不过程序设计总讲究一个取舍，业务逻辑放 php 会不会更好理解？修改起来会不会更方便？写代码的人会不会更开心？

[lihongjie0209]

这个就和把业务逻辑写在储存过程中一样



1. 违反了单一职责原则, 你把代码和部署环境强耦合了.
2. 违反了开闭原则, 扩展性和灵活性肯定不如写在代码中好.
3. 违反了依赖倒置原则, web 服务器是一种部署方式, 是细节, 业务代码不应该依赖于任何细节.
4. 违反了过早优化原则, 没有经过测试的优化都是瞎搞.

[2384036992]

@lihongjie0209 3Q!