Google负载均衡器在慢客户端场景下的行为及Tomcat线程问题

嘿，这个问题问到点子上了，刚好涉及Servlet容器处理慢客户端的核心逻辑，以及GCP负载均衡的具体表现，我来给你详细拆解：

一、Tomcat工作线程的具体状态 #

当你直接通过机器IP访问，且客户端下载速度只有2KB/s时，Tomcat的工作线程会长时间处于阻塞状态，直到整个200KB的JSON响应完全发送给客户端为止，具体过程是这样的：

• 线程执行到sysout("request IN")后，开始处理响应写入操作：res.getWriter().println(VERY_LONG_JSON_200KB)。
• 最初数据会写入Tomcat的输出缓冲区（默认大小一般是8KB或16KB），当缓冲区被填满后，Tomcat会尝试将数据通过TCP发送给客户端。
• 由于客户端接收速度极慢，TCP滑动窗口会被压缩（对方未确认接收的字节数达到上限），此时操作系统会阻塞Tomcat线程的发送操作——线程会卡在写数据的步骤，无法继续执行后续的sysout("request OUT")。
• 只有当所有200KB数据都被客户端接收完毕，TCP连接的发送缓冲区被清空，线程才会解除阻塞，完成doGet方法的执行，最终回到线程池等待新请求。
• 风险提示：如果存在大量这类慢客户端，Tomcat的工作线程会被快速占满，导致无法处理新的正常请求，这就是典型的慢客户端攻击场景。

二、Google负载均衡器面对慢客户端的行为 #

如果你的Tomcat实例放在GCP负载均衡器之后，情况会完全不同，LB会帮后端Tomcat隔离慢客户端的影响：

• 反向代理缓冲：GCP LB会作为反向代理，先和Tomcat建立连接，快速接收Tomcat返回的200KB响应（LB的接收速度远快于慢客户端），Tomcat的工作线程会在极短时间内完成响应发送，立刻释放回到线程池。
• 慢速转发给客户端：LB接收到完整响应后，会自己暂存数据，然后以客户端能接受的2KB/s速度慢慢转发，此时是LB和客户端保持长连接，后端Tomcat已经不再参与这个过程。
• 超时控制：GCP LB默认有300秒的客户端超时时间（可自定义配置），如果客户端在超时时间内仍未接收完数据，LB会主动断开与客户端的连接，避免自身资源被长期占用。
• 连接复用：LB会与后端Tomcat保持长连接池，复用已有连接处理后续请求，不会因为大量慢客户端而导致后端Tomcat的连接数暴涨。

简单总结：没有LB时，慢客户端会直接拖垮Tomcat的工作线程；有了GCP LB后，后端Tomcat的压力被大幅降低，LB承担了与慢客户端的交互成本。

内容的提问来源于stack exchange，提问作者Bhuvan