一个关于 App Store、关于 TCP 的很诡异的问题

2019-07-08 10:52:22 +08:00
 wang48ql

最近我们游戏项目在提交 App Store 审核,遇到无法理解的问题了。

表现是 HTTP 正常,tcp 异常。

tcp 的异常是,对方( App Store 审核者)连接我的服务器时,syn 可以正常收发,

也就是说 tcp 的连接是成功创建了的,

并且服务器可以收到对方发来的 psh 包,

但是服务器给对方发 psh 包时,对方永远都收不到,最后 tcp timeout 关掉连接。

服务器是买的 EC2,在加州,

从国内访问是正常的,并且我在加州另买一台 ec2 模拟客户端进行交互,也是成功的,

IPV4 和 IPV6 两种方式也测过了,都是正常的。

难受的点就在于,无法重现 App Store 出现的这个问题,并且提交给他们审核了多次,100%出问题。

想问各位 V 友,有遇到过这么奇怪的问题吗,有什么好的思路解决。

附上抓包的内容:

对方第 1 次访问:

02:25:59.732643 IP 17.222.113.29.64835 > ip-172-31-0-183.us-west-1.compute.internal.gw: Flags [S], seq 174102115, win 65535, options [mss 1363,nop,wscale 5,nop,nop,TS val 1284957903 ecr 0,sackOK,eol], length 0

02:25:59.732668 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [S.], seq 4049788313, ack 174102116, win 26847, options [mss 8961,sackOK,TS val 316630609 ecr 1284957903,nop,wscale 7], length 0

02:25:59.737832 IP 17.222.113.29.64835 > ip-172-31-0-183.us-west-1.compute.internal.gw: Flags [.], ack 1, win 32803, options [nop,nop,TS val 1284957911 ecr 316630609], length 0

02:25:59.752922 IP 17.222.113.29.64835 > ip-172-31-0-183.us-west-1.compute.internal.gw: Flags [P.], seq 1:64, ack 1, win 32803, options [nop,nop,TS val 1284957925 ecr 316630609], length 63

02:25:59.752932 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [.], ack 64, win 210, options [nop,nop,TS val 316630630 ecr 1284957925], length 0

02:25:59.753757 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316630630 ecr 1284957925], length 39

02:25:59.959845 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316630837 ecr 1284957925], length 39

02:26:00.166847 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316631044 ecr 1284957925], length 39

02:26:00.581847 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316631459 ecr 1284957925], length 39

02:26:01.410851 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316632288 ecr 1284957925], length 39

02:26:03.070846 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316633948 ecr 1284957925], length 39

02:26:06.386853 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316637264 ecr 1284957925], length 39

02:26:13.026860 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316643904 ecr 1284957925], length 39

对方第 2 次访问:

02:26:20.379661 IP 17.222.113.29.64836 > ip-172-31-0-183.us-west-1.compute.internal.gw: Flags [S], seq 3752180301, win 65535, options [mss 1363,nop,wscale 5,nop,nop,TS val 1284976275 ecr 0,sackOK,eol], length 0

02:26:20.379689 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [S.], seq 929342483, ack 3752180302, win 26847, options [mss 8961,sackOK,TS val 316651256 ecr 1284976275,nop,wscale 7], length 0

02:26:20.384702 IP 17.222.113.29.64836 > ip-172-31-0-183.us-west-1.compute.internal.gw: Flags [.], ack 1, win 32803, options [nop,nop,TS val 1284976278 ecr 316651256], length 0

02:26:20.389008 IP 17.222.113.29.64836 > ip-172-31-0-183.us-west-1.compute.internal.gw: Flags [P.], seq 1:64, ack 1, win 32803, options [nop,nop,TS val 1284976282 ecr 316651256], length 63

02:26:20.389027 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [.], ack 64, win 210, options [nop,nop,TS val 316651266 ecr 1284976282], length 0

02:26:20.389816 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316651266 ecr 1284976282], length 39

02:26:20.594849 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316651472 ecr 1284976282], length 39

02:26:20.800843 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316651678 ecr 1284976282], length 39

02:26:21.213843 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316652091 ecr 1284976282], length 39

02:26:22.038843 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316652916 ecr 1284976282], length 39

02:26:23.690849 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316654568 ecr 1284976282], length 39

02:26:26.306860 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316657184 ecr 1284957925], length 39

02:26:26.994847 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316657872 ecr 1284976282], length 39

02:26:33.602847 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316664480 ecr 1284976282], length 39

02:26:46.818847 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316677696 ecr 1284976282], length 39

02:26:52.898853 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316683776 ecr 1284957925], length 39

02:26:59.753367 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64835: Flags [F.], seq 40, ack 64, win 210, options [nop,nop,TS val 316690630 ecr 1284957925], length 0

02:27:13.250847 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [P.], seq 1:40, ack 64, win 210, options [nop,nop,TS val 316704128 ecr 1284976282], length 39

02:27:20.390533 IP ip-172-31-0-183.us-west-1.compute.internal.gw > 17.222.113.29.64836: Flags [F.], seq 40, ack 64, win 210, options [nop,nop,TS val 316711267 ecr 1284976282], length 0

我们自己测试都是正常的,就不贴出抓包的内容了。

1823 次点击
所在节点    问与答
17 条回复
ech0x
2019-07-08 10:54:30 +08:00
被 tcp 阻断了?
goofool
2019-07-08 11:29:10 +08:00
HTTP 也是 TCP,你这防火墙开放端口了吗
wang48ql
2019-07-08 11:37:15 +08:00
@ech0x 阻断是啥意思?我自己测试是正常的,提交到 App Store 审核才异常。
@goofool 开了,我自己测试是正常的,提交到 App Store 审核才异常。
Cipool
2019-07-08 11:53:30 +08:00
排除法,直接换台服务器试试
wang48ql
2019-07-08 13:57:21 +08:00
@Cipool 我目前用 CentOS,其他的不熟悉,有什么推荐吗
fffang
2019-07-08 13:59:39 +08:00
我上次遇到这个问题的时候,是因为我 url 写了 ip
wang48ql
2019-07-08 14:38:35 +08:00
@fffang 可以详细说说吗,你是指客户端代码里写了 ip?我这边客户端是可以访问到服务端的,http 是正常的。
exmario
2019-07-08 14:50:23 +08:00
给对方发测试工具,pcClient/apk 之类,连接上之后隔几秒发送一次请求,然后写 log 什么的,对方走 4g/wifi 各一遍,基本就能定位到是不是网络问题
wang48ql
2019-07-08 15:08:59 +08:00
@exmario 肯定是网路问题。从抓包结果来看,很像是对面屏蔽了非常用端口的数据包。
因为 http 的 80 端口是正常通信的,而 tcp 服务是我们自定义的 3000 端口,就无法通信。
但是 apple 是不会配合我们这些小开放商去做什么测试的。。
goofool
2019-07-08 15:25:32 +08:00
到处 pcap 文件才好看
wang48ql
2019-07-08 15:58:51 +08:00
@goofool pcap 文件放在网盘上了
链接: https://pan.baidu.com/s/18umfIq_HCvxGBoz0UFPQ4g
提取码: dyx3
loveour
2019-07-08 16:00:30 +08:00
@wang48ql #9 按理说,苹果不会屏蔽访问什么端口的,不然的话,那些游戏服务器什么的一般端口号都比较大,早就完蛋了。以前我们的 1W 多也没事。或者,你可以试试用一个 5 位数的端口?
wang48ql
2019-07-08 17:54:27 +08:00
@loveour 这招是可以试一下,但是感觉应该不是这个原因
loveour
2019-07-08 17:58:26 +08:00
@wang48ql #13 是的,我很难理解苹果会屏蔽某些端口,没理由的。但是,实在不行的话,什么手段都要试试吧,换端口,换服务器,总之都要试试的,有什么办法呢。
wang48ql
2019-07-10 13:43:35 +08:00
@loveour 换 5 位数端口也试了,没用。接下来准备试试反向代理,换成 443 端口,这个总不该封了。
loveour
2019-07-10 13:51:44 +08:00
@wang48ql #15 感觉某些端口不能访问这个猜测可能就不太对。。不如在 App 里添加一些日志,上传到网站?比如客户端检测到连接断开,有异常,就向网站发个消息,看看什么原因断开的。因为不是可以访问网站么?
wang48ql
2019-07-24 10:16:39 +08:00
@loveour 报告一下目前的进展,换成 443 端口就正常了。
从实验结果来看,对方的防火墙确实是阻止了其他端口的包进入,虽然觉得很不可思议。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/580919

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX