我正在构建一个 Web 服务器应用程序，它使用 HTTP 1.1 协议(protocol)和分块传输编码根据请求将不同大小的文件从服务器发送到客户端。
我正在使用 Java Sockets/ServerSockets 来处理连接。我使用从 socket.getOutputStream() 获得的输出流向客户端发送数据。注意:我没有将套接字的输出流包装在BufferedOutputStream中。
(我正在使用 chrome 调试器来分析资源时序)
我看到的问题是，一个大小为 1285 字节(加上 header 和 block 编码)的文件需要 50 多毫秒才能让 chrome 接收到请求的第一个字节。 (Chrome 报告 TTFB 约为 50 毫秒)，然后是传输的快速剩余部分(1-2 毫秒)(总传输时间约为 52 毫秒)
但是如果我将文件的大小增加到 1286 字节，TTFB 会急剧下降到 ~1ms。 (总传输时间~3ms)
我尝试在整个过程中的不同点强制 flushing OutputStream，包括在请求 header 之后、 block 之后，甚至尝试多次 flush 在每个点调用只是为了好玩。
我的问题:与大于或等于 1286 字节的任何文件相比，为什么小文件的传输时间要长得多？我可以做些什么来解决这个性能问题？
我的理论:尽管 Java 调用了 flush( )。
最佳答案
禁用 Nagle 算法可以解决此问题。
http://www.boundary.com/blog/2012/05/know-a-delay-nagles-algorithm-and-you/
关于java - 通过 Java 套接字发送小文件时的性能问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29002267/