一直以来,实验室内所有笔记本和手机,使用微信发送图片、文件,或进行抢红包、转账等操作都要卡 5-10 秒,近期因同学有频繁发送文件的需求,受到的影响格外大,于是打算分析一下。
网络环境:校园网环境,IPv4 使用自己购买的山东移动的宽带,类似于小区吧。IPv6 通过 CERNET2 。
使用 Wireshark 抓包发现,微信的控制消息通过 IPv6 传递,文件传输通过 IPv4 。上传到某些位于南京的服务器时,出现了大量 TCP 重传。而向广州腾讯云的服务器上传时,一切正常。
收集到的 IP 如下:
南京 腾讯云(异常) 43.137.188.182 、109.244.255.103
南京 腾讯云(正常) 175.27.207.200
广州 腾讯云(正常) 114.132.202.176 175.27.33.109
以 109.244.255.103 为例,异常的细节为:
我疑惑的地方在于 当前的情况看上去像是第三个包(姑且称它为包,毕竟是个 IP 包)丢失。但如果真是 3 号包丢失,2 和 4 之间不过才 200ms ,超时重传不至于间隔如此短暂?如果不是 3 号包丢失,是什么原因导致服务器把第 2 个包又发送了一遍呢?
希望得到的帮助 分析出现该问题的原因,并解决微信发图片慢问题。当前链路上用的是 TPLink 路由器,如果需要,可以考虑在链路上加一台 Linux 服务器设备。但考虑到便捷性,尽量不“过滤重传包”。
其他尝试 屏蔽了 dns.weixin.qq.com.cn 域名,但暂未找到微信的文件服务器是从哪里解析的。或许可以从这上面入手,强制传文件到广东服务器。甚至可以搭建一个代理,对明文的文件传输请求进行劫持、改写。(坑有点大)
附件
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.