We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hi, 首先对mars项目致敬,阅读了一部分源码,发现其对移动网络确实做了许多优化。� 这篇文章中提到:印象比较深刻的某地的用户反馈连接 WiFi 时,微信不可用,后来 tcpdump 发现,当包的大小超过一定大小后就发不出去。解决方案:在 WiFi 网络下强制把 MSS 改为1400(代码见 unix_socket.cc)。 我们遇到的问题与你在文章中提到的类似,也是请求长度超过mss后,在用户的wifi环境下出现拆包后,请求失败。据我们分析,不一定是与运营商有关系,而是跟路由器组网方式、路由器MTU设置有一定关系。 另外想问一下,据了解mss是最终由服务端与客户端协商定下的,为什么不通过服务端降低mss,来最终减小mss值,而是直接在客户端设置更小的mss?
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Hi, 首先对mars项目致敬,阅读了一部分源码,发现其对移动网络确实做了许多优化。�
这篇文章中提到:印象比较深刻的某地的用户反馈连接 WiFi 时,微信不可用,后来 tcpdump 发现,当包的大小超过一定大小后就发不出去。解决方案:在 WiFi 网络下强制把 MSS 改为1400(代码见 unix_socket.cc)。
我们遇到的问题与你在文章中提到的类似,也是请求长度超过mss后,在用户的wifi环境下出现拆包后,请求失败。据我们分析,不一定是与运营商有关系,而是跟路由器组网方式、路由器MTU设置有一定关系。
另外想问一下,据了解mss是最终由服务端与客户端协商定下的,为什么不通过服务端降低mss,来最终减小mss值,而是直接在客户端设置更小的mss?
The text was updated successfully, but these errors were encountered: