浏览 495
测试发现，在正常情况下，一个udp客户端使用同一个源端口访问nginx，并连续发送多个数据包，nginx转发到upstream server时都会用同一个会话（源port相同）
但是在多客户端情况下（100个客户端，每个客户端使用绑定一个源端口），分别持续向nginx发送udp数据，nginx转发到upstream server时，会有部分转发没有使用同一个会话（比如有90个客户端的请求转发时使用了同一个源端口转发，另外10个没有使用同一个源端口进行转发）
请教大佬，这个是哪个参数没有设置好吗？应该怎么调试呢，谢谢
按点赞数排序
按时间排序
没有回答，我就只能自己回答了。
查了下代码，进行gdb跟踪调试后发现：这个主要是因为，每个worker单独维护一个前后端 “链路”关联的四元组信息，在多个worker的情况下，不同的worker保存“链路”关联信息相互独立，彼此不共享。因此即使是相同的IP和端口发来的消息，只要是分配到不同的worker进行处理，都有可能查不到之前的“链路”关联信息，从而无法复用。
解决办法：
1. 单worker配置（性能可能偏低）
2. 修改代码，使用共享内存保存已有的前后端“链路”关联信息，不同worker之间共享结果
赞同2
回复
举报回答于2023-08-29 14:22
没太明白什么意思，您的源端口是指客户端发送udp的sport？还是nginx转发的port？如果是前者为什么要关注客户端sport呢？如果是后者可以采用proxy_bind做客户端ip+port透传。eg: proxy_bind $remote_addr:$remote_port transparent;
赞同0
回复举报回答于2023-10-25 18:34
没有回答，我就只能自己回答了。
这个主要是因为，每个worker单独维护一个前后端 “链路”关联的四元组信息，在多个worker的情况下，不同的worker保存“链路”关联信息相互独立，彼此不共享。因此即使是相同的IP和端口发来的消息，只要是分配到不同的worker进行处理，都有可能查不到之前的“链路”关联信息，从而无法复用。
解决办法：
1. 单worker配置（性能可能偏低）
2. 修改代码，使用共享内存保存已有的前后端“链路”关联信息，不同worker之间共享结果
赞同0
回复举报回答于2023-08-29 14:20
1、IETF的QUIC已经有33个草案了，这是RFC规范，所以现在Nginx不太会去支持其他QUIC版本了。目前Nginx的quic分支，是基于最新的RFC 33 draft草案实现的。你可以参考下spdy与HTTP2在Nginx上的实现，那时HTTP2迟迟未推出时，google的spdy广为使用，Nginx推出了spdy模块，所以这其实是个开发效率、成本的权衡问题。
2、拥塞控制由应用层来实现，还是由内核来实现，对于网络安全性来说，这并不是问题。对于网络来说，每一台主机也未必可信。对于Linux来说，内核也是可以去改的。所以，长期来看，拥塞控制不会是问题，个人看法。
3、11.27号在GOPS上海站还会做HTTP3的进一步探讨。
点赞 0
浏览 1.9k这个我理解IPv4和IPv6关于 transparent 的设置上是没有区别的，只是需要注意的是，IPv6的IP透传需要glibc版本达到一定的条件，我记得是glibc 2.26以上才支持。
查看命令 rpm -aq | grep glibc
然后配合路由表设置，在连路上抓包可看到真实的client ipv6地址，可以根据这个帖子 实际测一下，亲测有效，测试转发成功了 https://www.nginx.org.cn/article/detail/76
点赞 0浏览 540
微信公众号
加入微信群
