我们有个应用需要用户连续上传很多图片到服务器，前一段时间有用户反馈由于上传的图片越来越多，耗时也越来越长至无法接受，甚至可能一晚上都无法完成图片的上传过程。于是图片上传性能的优化提上了日程。
耗时分析
图片从用户手机传入服务器大致经过互联网、服务接入层、应用服务器、应用程序这些环节，如下图所示
每个环节都有可能成为卡点，用户所处的网络环境、地域等都很有可能影响上传的速度，这些往往是我们难以把控的。而且如果大量用户出现此类问题，即使用户侧的网络环境恶劣、地域偏远导致延迟较高也是我们的应用所必须克服的。
程序性能分析
首先，从我们最有掌握权的地方入手，也就是处理程序，怀疑是否程序处理过慢、接口响应时间过长导致？由于在实际服务前面都使用了 Nginx 做了层反向代理，所以通过 Nginx 的接入日志很容易可以看到服务的响应时间。
可以看到程序处理的耗时不稳定，但基本在几十~两百 ms 间。与之前统计的用户上传耗时：2s/张，差距巨大，可以肯定不是因为程序性能问题导致。
网络延迟分析
不是程序性能问题，那么就怀疑是否用户距离服务器地域过远导致的网络延迟？于是找了两台不同地域的服务器，网络延迟大概 30ms 相当于上海到北京的距离。
然后用 SpringBoot 简单起了一个图片上传服务，来模拟用户上传过程，这里不得不说 SpringBoot 真是简单快捷。程序代码如下。
spring.servlet.multipart.max-file-size = 1024MB
spring.servlet.multipart.max-request-size = 1024MB
@Slf4j
@SpringBootApplication
@RestController
public class PicApplication {
public static void main(String[] args) {
SpringApplication.run(PicApplication.class, args);
}
@PostMapping("upload")
public String upload(@RequestParam(value="pic") MultipartFile image) throws IOException {
byte[] imageBytes = image.getBytes();
String fileName = UUID.randomUUID().toString().replaceAll("-", "") + ".jpg";
File dir = new File("/home/admin/data/");
if (!dir.exists()) {
dir.mkdirs();
}
try (FileOutputStream fo = new FileOutputStream(new File(dir, fileName))) {
fo.write(imageBytes);
}
log.info("上传文件:{}", fileName);
return fileName;
}
}
然后写了一段 Shell 脚本用来多次进行图片上传并进行即时。04.jpeg 是一个 0.4M 大小的图片，也是我们让用户上传图片的平均大小。
#!/bin/bash
for ((i=1; i<=10; i++))
do
start=$[$(date +%s%N)/1000000]
curl -X POST -F "pic=@/home/admin/data/04.jpeg" http://101.183.234.42:8080/upload
echo time $i cost `expr $[$(date +%s%N)/1000000] - $start`
done
执行上面这段代码后，统计结果如下：
耗时情况与用户实际耗时差距还是很大，而且如果是因为网络延迟原因导致耗时的话，理论上增大传输的图片大小耗时也会相应的增加，于是将上面的 0.4M 的图片替换成一个 4.7M 的图片再次进行测试。
结果图片上传耗时的确有增加，但是与图片大小的增长（10倍）很不成比例。于是基本可以排除因为存在网络延迟导致图片上传速度较慢。到这里有点陷入困境，因为排除这两个原因，网络数据到达处理程序经过的环节特别多，没有太好的定位方式。中间也想过是否 https 跟 http 之间的差距等。
问题定位
后来考虑是否可能是接入层进行了限流导致，毕竟接入层承接了公司所有的请求流量，对非特殊的请求进行限制流量也是很正常的。于是将测试脚本改了下，请求服务地址直接改为线上的服务地址，发现请求耗时的确飙升了很多。这里由于没找到合适的机器，所找的机器与线上接入层的延迟为 60ms，比之前测试的多了一倍，但是耗时飙升依然可以说明问题。
于是找接入层的同学进行咨询，是否有限制，得到了肯定的答复，接入层对 TCP 的接收缓冲区大小及发送缓冲区大小都有限制，如下所示。
于是调整之前部署图片服务的服务器参数与上图一致，可以通过 sudo sysctl -a |grep mem 查看，通过 vim /etc/sysctl.conf 修改，使用 sudo sysctl -p 生效。然后再分别执行之前的两段脚本，结果如下。
发现 0.4M 的图片跟 4.7M 的图片处理耗时都大幅增加，0.4M 的图片如果加上原始服务的处理耗时与之前统计用户耗时相近。而 4.7M 的图片耗时为 0.4M 的图片耗时的 10 倍。这是为什么呢？
这里就要分析下图片上传的过程了，才能准确的分析出来时间都耗在哪里了。首先图片上传是基于 HTTP 协议，而 HTTP 协议则基于 TCP 协议。在 TCP 协议中开始通信时候必须先经历三次握手过程，这中间的耗时无法避免。中间传输过程中会使用滑动窗口协议来提升传输效率，但窗口的大小是有限的，如上文中配置的 net.ipv4.tcp_rmem 就是 TCP 接收缓冲区的大小也是接收窗口的最大值。TCP 使用滑动窗口协议提升了数据传输的并行度，但是其实每批之间的网络延迟是无法忽略的，毕竟 TCP 为了可靠传输是需要 ACK 的。当数据传输完毕之后将进行四次挥手。
所以整个图片上传的网络耗时基本可以描述为：三次握手+(文件大小/滑动窗口大小)*网络延迟+四次挥手，实际过程远比这复杂。由于三次握手、四次挥手在大文件的传输中基本可以忽略所以，最终主要看(文件大小/滑动窗口大小)*网络延迟。拿 4.7M 的图片来计算：（4.7 * 1024 / 32）* 30 ≈ 4500 ms，考虑到 TCP 的慢启动、窗口不一定跑满、TCP 首部空间浪费等，而且很难做到完全的并行，整体*2 之后与实际耗时近似。
解决办法
知道了问题的根源也就可以对症进行解决了，无非是优化两个变量，主要思路有如下。
- 接入层修改 TCP 配置参数，增大缓存大小，其实就是提高单 TCP 连接并行度，但是肯定会导致服务器整体并发度的降低，这种方案需要仔细评估后执行。
- 全国多地域服务部署，将服务延迟降到最小。如果服务量较小，必然造成很多不必要的浪费。
