消息长度和连接管理是两个不同的东西，彼此之间没有任何关系（除了在消息长度完全未知的情况下，关闭连接是表示EOF的唯一可能方法，但这种情况很少发生，也不是你的情况）。

分块仅适用于消息长度，其中0长度的块表示EOF。如果连接在到达EOF之前过早关闭，则消息不完整，接收者可以决定是否保留/处理它。

客户端使用Connection标头来指定它希望服务器在发送响应后关闭连接还是保持连接打开。服务器使用相同的标头来指定连接在发送响应后是实际关闭还是保持打开。

"Connection"标头不应该被添加（或者设置为保持活动状态，这与我们讨论的HTTP1.1相同），或者这是授权设置它连接：关闭

这与分块无关。无论Message的格式如何，客户端和服务器都应该始终表明他们对当前连接的意图，是关闭还是保持打开。这是通过是否存在Connection标头来完成的，具体取决于HTTP版本：

如果使用HTTP1.0，则默认行为是关闭，除非显式发送连接：保持活动状态。

如果使用HTTP1.1，则默认行为是保持活动，除非显式发送连接：关闭。

如果客户端请求保活，服务器决定是否遵守它。服务器可以保持连接打开，也可以关闭连接。

如果客户端请求关闭，服务器必须尊重它并关闭连接。

发送一个空的chunk，意味着传输的结束，但这是否意味着连接的结束？

不可以。只有Connection标头可以做到这一点。尤其是在保活场景中，因此连接保持打开状态，以便客户端可以在先前响应的传输完成后重用现有连接发送新请求。

我认为我需要添加Connection： close当我的意图是在发送一个空块后关闭连接时

正确，尤其是在HTTP1.1中，保持活动是默认行为。

如果我不添加Connection标头，它将保持打开状态

省略的Connection标头的含义取决于所使用的HTTP版本，如上所述。

允许服务器在使用分块传输编码时发送Connection： close，这不应该导致客户端在响应完成之前断开连接。

根据RFC2616https://www.rfc-editor.org/rfc/rfc2616#section-14.10

例如，

   Connection: close

在请求或响应标头中，字段指示在当前请求/响应完成后不应将连接视为“持久”（第8.1节）。

由于发送块时响应不完整，因此不禁止连接持久化。