HTTPS Batch request的幂等性研究和实践

名词解释：

HTTPS/GET/POST 略过；
幂等性：可以使用相同参数重复发送相同的请求，能获得相同结果；
Batch：任意个数个GET+POST组成的请求集合。

背景：

F是一款老项目，有着近20年的历史，服务器端几经改造后，采用了HTTPS协议+长链接+Batch形式。

问题的发现与梳理：

经常有客户抱怨在APP中出现网络错误的弹窗后退出，需要重新登录。
对此问题进行梳理后发现，大概有18%的用户在一天之中会遇到此问题，平均下来大概在使用APP 35分钟后会产生这个弹窗；多数用户每天遇到一次（跟用户粘度有关），也有少部分用户每天遇到多次。

问题的判断：

1）根据经验判断上述问题大多数情况是由于网络闪断引起的，APP底层对于网络闪断的兼容性不好，TCP层的重传机制并不能良好的解决此问题。
2）上层逻辑采用Batch，很难有效重传。

问题的解决：

1）增加了新的Batch Retry机制，每次登录时，前后端握手协商Retry序列号，客户端每次发送Batch序列号+1，服务器端按UID+序列号记住之前的Response；
2）当网络闪断（或者高延时）发生后，客户端没有收到Response后，可以无脑再次发送刚才的Batch，而服务器端总是返回相同的结果。

实践效果：

经历过测试、压测、封测后正式上线，取得数据如下：
大概有18%的用户遇到了Batch Fail（前面提到过）；
这些Batch可以Retry率在80+%；
Retry的成功率在80+%；
大概有0.8*0.8*18%=10+%的用户不会遇到弹窗退出到登录了。

总结：

1）此次优化针对于自家项目，采用了独创的技术，使得用户遇到网络错误弹窗率从以前的18%，下降到大概8%左右，取得了巨大成功；
2）网络闪断发生在用户最后一公里的概率占绝大多数，并且这些闪断大多数可以通过幂等性设计来进行重试；
3）后续可以调整Batch Retry的参数和机制、或者增加Connect Retry等方式来进一步优化用户体验。