一、网络报错背景

近期公司线上APP（iOS端）出现网络连接中断，用户使用WiFi没有问题，使用4G偶尔会出现“网络连接中断。”提示语，连机检查，发现使用AFNetworking报错code=-1005，网络连接中断。由于之前没有出现过这种问题，是在APP运营一段时间之后，出现的，所以排除了APP代码问题，但是我还是想看一下客户端应该如何解决这个问题。

二、解决方案选择

出现这种情况后，公司成立了应急小组，在网上找了好几个帖子，进行测试。使用方案如下：

1.由于公司项目中使用的AFNetworking是2.x版本，然后进行AFNetworking框架升级，升级到3.2.1版本，使用4G频繁调用接口，还是会出现这种情况。此方案不能解决我们本次问题。

2.在网上看了帖子，有的说是模拟器会出现这种情况，重启模拟器，会解决。而我们是在真机上出现的问题，就重启手机。然后进行测试，依然没有解决这个问题。此方案不能解决我们本次问题。

3.有的帖子说是需要修改请求的header，设置Keep-Alive，于是进行了如下的配置并测试：

a>.运维同事在服务器设置：1.“Connection”：“Keep-Alive”，2.“Keep-Alive”：“timeout60000”；（参考文章）此配置的详细说明，大家可以自行查找，下面截图是查看的帖子说明，此方案不能解决我们本次问题。

参考文章

b>.关闭“Keep-Alive”，由客户端设置header里面Connection: close。此方案不能解决我们本次问题。

3.客户端实现，出现code=-1005的情况时，自动重新发起请求一次。此方案比较繁琐，而且不能解决线上APP的问题。

三、我们使用的解决方案

经过了两天的方案查找以及测试，并没有找到合适的解决方案，于是进行HTTP底层连接解读，然后根据APP调用网络请求出现丢包的问题。发现可能和服务端时间戳认证有一定的关系，于是我们对Nginx上面的tcp_timestamps=1进行关闭，设置成tcp_timestamps=0。然后进行上线使用，发现能解决本次问题，但是服务器会出现time_wait激增的情况（在可接受范围内）。但是线上APP的“网络连接中断。”不再出现，为了优化这个配置，我们进行设置tcp_tw_recycle = 0 ;发现无论tcp_tw_recycle和tcp_timestamps 任何一个只要设置为0，都能解决我们的问题，但是都会导致time_wait上涨。目前我们正在进行相关的优化，有知道的同学可以私信我。谢谢