2019-07-01NGINX 对资源的“抠门” 和 cosocket 的协程 非阻塞。是 OR 高性能的秘密 1
2019-02-17我知道了是cosocket 1- 2019-02-17pool socket 特性么。我就是确认下，做个笔记。 1
- 2019-02-15NTLM采用挑战应答的认证机制，用户先发认证信息，服务回一个挑战信息，用户通过密码加密这个挑战信息，然后发给服务器校验，但是关键是Exchange服务会检查用户发过来的认证信息和挑战信息的TCP连接，如果不是同一个TCP就无法认证通过。因此，经过反向代理后，服务器检查的是Nginx转发的连接，但是我们发现Nginx转发的用户的认证信息和挑战信息会使用不同的TCP连接转发给后端，那么会被Exchange认证不通过。请问陶老师，Openresty能否控制转发到后端所采用的TCP连接？或者是否有别的解决方法？
作者回复: 还是不理解你说的业务场景，说下我的思路，希望能对你有帮助：
1、Nginx反向代理一定对上下游使用两个不同的TCP连接。
2、所谓检查是不是同一个连接发来的报文，是由操作系统完成的，从来都不是Exchange服务这样的进程能够决定的。因为TCP协议栈是由操作系统实现的。
3、检测是否同一连接报文，是靠TCP五元组及sequence决定的。 1 - 2019-02-15非常感谢您，陶老师
作者回复: ：-）
- 2019-02-15陶老师，您好。我们目前想通过Openresty代理微软的Exchange服务，但是难点在于Nginx无法代理其NTLM认证过程（因为NTLM认证要求单次认证过程中所有的请求必须使用同一个Socket，而经过Nginx代理后，Nginx采用了不同的Socket转发）。请问，如何通过Openresty、Lua提供的各种SDK解决这个问题，您是否可以提一个思路？如果增大Upstream下keepalive参数的值，是否能解决这个问题，会有什么隐患？
作者回复: Socket是操作系统提供的概念，与跨主机的网络通讯是无关的。对这句“因为NTLM认证要求单次认证过程中所有的请求必须使用同一个Socket”我不是很理解。