SSH客户端慢消费时服务端输出丢失问题及相关技术咨询

我正在开发一款应用，通过命令ssh -p29418 xx@gerrit.host gerrit stream-events -s comment-added消费Gerrit输出的事件，该命令每行输出一个JSON格式事件，示例如下：

{"type":"comment-added",change:{"project":"tools/gerrit", ...}, ...}

应用采用JSch库实现SSH客户端，示例代码如下：

// A ssh client library
Jsch client = new JSch();
Session session = client.getSession("username", "host", 22);
session.setPassword("password");
session.connect();

ChannelExec channelExec = (ChannelExec) session.openChannel("channelExec");
channelExec.setCommand("gerrit stream-events -s comment-added");
channelExec.connect();

InputStreamReader reader = new InputStreamReader(channelExec.getInputStream());
BufferedReader bufferedReader = new BufferedReader(reader);

String event;
while ((event = bufferedReader.readLine()) != null) {
    handleEvent(event);
}

核心问题：慢消费实例是否会随机丢失事件？ #

不会随机丢失事件。整个SSH传输链路基于TCP协议，TCP会保证数据的可靠传输，当消费速度慢于生产速度时，数据会在链路的各个缓冲区中暂存，直到消费者读取，不会出现随机丢包情况。

1. 当消费者（慢应用）消费速度慢于生产者（Gerrit stream-events）时，生产者会出现什么情况？ #

当消费速度跟不上生产速度时，数据会在从Gerrit到客户端的各层缓冲区堆积：

• 首先Gerrit进程的标准输出缓冲区会被填满，此时Gerrit向stdout写入数据的操作会被阻塞，直到缓冲区释放出空闲空间；
• 如果消费者持续慢消费，Gerrit会暂停事件输出，等待之前的事件被消费后再继续生成，不会主动丢弃事件。

2. 套接字发送方需等待接收方recv_buf有足够空间才能继续发送，该限制是否会阻塞进程向stdout输出消息？ #

会阻塞。当套接字发送缓冲区（send_buf）已满，且接收方的recv_buf也无空闲空间时，TCP触发流量控制，发送方的写入操作会被阻塞。若进程的stdout直接关联到该套接字（比如SSH会话中命令的stdout被重定向到SSH连接套接字），进程向stdout写数据的操作会一直阻塞，直到缓冲区有可用空间。

3. socket write_buf与Java程序System.out的write_buf有何区别？若Java程序stdout重定向到socket输出且发送方write_buf和接收方recv_buf均满时会发生什么？ #

• 区别：
  • Socket的write_buf是操作系统内核层面的缓冲区，由TCP协议栈管理，用于暂存待网络发送的数据，负责处理流量控制、重传等网络传输逻辑；
  • Java的System.out的write_buf是JVM用户态的应用层缓冲区，目的是减少系统调用次数，当缓冲区满或调用flush()时，才会将数据写入底层文件描述符（如关联的套接字）。
• 均满时的情况：Java程序的System.out缓冲区写满后，会尝试将数据写入底层socket write_buf；若此时socket write_buf和接收方recv_buf都已满，Java的写入操作会被阻塞，直到链路中有缓冲区空闲，数据才能继续写入。

4. SSH服务端如何将gerrit stream-events命令的stdout重定向并传输到客户端？ #

SSH服务端处理流程如下：

1. 接收到客户端的命令执行请求后，在服务器上启动gerrit stream-events进程；
2. 通过创建管道（pipe）关联到该进程的stdout，实时读取进程输出的每一行数据；
3. 将读取到的数据封装成SSH协议数据包，经过加密后通过TCP连接发送到客户端；
4. 客户端的JSch库解析SSH数据包，还原出原始的stdout输出，供应用读取处理。

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