返回信息流小弟使用Spring框架写了一个Rest服务器，响应用户的请求，返回的数据量有一些大，所以用户在获得响应的时候耗时较长，需要接近五分钟。但是通过后台日志了解到，一个请求的处理时间只需要不到五十秒，所以小弟我判断大部分时间消耗在了结果的传输之上，尤其是tcp包的重传。小弟的问题是，Spring框架编写的Rest服务将响应是只用一个Tcp包进行返回么，还是说可以通过什么设置使用多个Tcp包返回一个Http请求的响应，因为小弟我认为如果用多个Tcp包返回的话会减少Tcp重传的消耗？
这是一条镜像帖。来源：北邮人论坛 / java / #60577同步于 2018/12/10
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Java机器人发帖
【问题】如何用多个tcp包返回一个http协议请求的响应？
gxlihao
2018/12/10镜像同步9 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
TCP有自己的分段算法 来避免网络层的分片 接收端收到后会重组并提交给应用层（PSH或缓冲区满）
另外重传是另一个概念 出现重传的大多数情况都是网络条件差导致丢包造成的
回到你的问题本身 你应该首先确认是否确实是重传过多导致的问题 然后确认你的每次返回的数据量 如果确实很大 那么就不是TCP的锅 常见做法是修改你的后端接口和前端代码 要么分页显示 要么收到一部分渲染一部分 分多次接收 而不是数据到齐了再开始渲染 当然这里就不应该是你框架该管的了
后台的数据是动态的，有一定的时效性，且部分数据有可能失效，因此很难将接口实现为分页的形式。返回的结果数据有超过5M。
【 在 Nroskill 的大作中提到: 】
: TCP有自己的分段算法 来避免网络层的分片 接收端收到后会重组并提交给应用层（PSH或缓冲区满）
: 另外重传是另一个概念 出现重传的大多数情况都是网络条件差导致丢包造成的
: 回到你的问题本身 你应该首先确认是否确实是重传过多导致的问题 然后确认你的每次返回的数据量 如果确实很大 那么就不是TCP的锅 常见做法是修改你的后端接口和前端代码 要么分页显示 要么收到一部分渲染一部分 分多次接收 而不是数据到齐了再开始渲染 当然这里就不应该是你框架该管的了
感觉是接口设计的问题
接口处理数据时间五十秒已经算不可用了，可以设计为“提交事务”加“查询状态”的形式
客户端请求时间太长就在服务端缓存列表，让客户端分段读取和展示
所有后台的数据都是有时效性的，不然为什么不做成静态写死在客户端呢？
不过如果真的只有几M这么大的数据量，需要传4分钟，那说明底层协议上确实有问题，建议抓包看一下到底怎么回事，或者干脆把客户端架在服务端服务器上测试一下，排除网络干扰的因素
另外你真的需要一次性渲染那么大量的数据给用户看吗？或者说每次请求都要重新获取这么大量的数据？我见过的大多数应用场景都没有单次请求会有这么大的数据量，除了数据库大查询
最后，越是对时效性要求高的应用，接口设计往往更细，通过前台不停请求地方式来保证正确性，否则随便来几个用户的请求就把服务器搞炸了，别说CPU，网卡IO都扛不住
【 在 gxlihao 的大作中提到: 】
: 后台的数据是动态的，有一定的时效性，且部分数据有可能失效，因此很难将接口实现为分页的形式。返回的结果数据有超过5M。
:
TCP的一个设计失误（历史原因吧）是把消息传不到认为是网络拥挤。
这种设计可以简化协议的实现，通信的双方在共享最少的信息的同时，能最大限度的利用网络通信的能力。
于是在遇到网络错误的时候就会减小带宽，以期能减少错误的发生。
对于一些不可靠的网络或者延时很高的网络，其实带宽是足够的，但是由于常态性的丢包（超时），导致协议层面一直在减少带宽使用。其结果就是传输速度降低。（例如经典的“长肥管道”）
所以，以上我说了这么多，但是我觉得，这些分析并没有什么卵用。
大概率还是你自己代码写挫了（