测验：半关闭与响应保留

客户端发送完稿件后只调用了 SHUT_WR。服务器收到 EOF 后应该怎么做？

• 立即关闭服务器套接字，同时回收双向资源
• 取消读事件关注，并继续发送已经准备好的响应
• 保持读事件关注，直到 EOF 消失
• 接受新连接，并把旧套接字的响应队列转移过去

请求恰好填满上限。如果把下一次 recv 的长度计算为 0，会出现什么问题？

• 内核会把读就绪通知改为写就绪通知
• TCP 会自动把请求上限增加一个字节
• 即使没有收到对端 FIN，也会把空返回误认为 EOF
• 发送队列内容会自动连接到接收缓冲区末尾

4 字节响应中，send 返回 2，而下一次调用抛出 BlockingIOError。正确状态是什么？

• 保留剩余 2 字节并维持 WRITE 事件关注
• 把全部 4 字节重新加入，以防响应缺失
• 删除剩余 2 字节并以 complete 结束
• 解除接收 EOF，并重新接收稿件

客户端在时限将至前每次发送一个字节。创建连接时固定的总寿命截止时间会产生什么效果？

• 即使没有连接数限制，也能保证总体内存使用量
• 只更新空闲计时器，保证可以无限期等待响应完成
• 仅在 EOF 之前适用，之后仍可继续等待发送
• 即使一直有活动，也会在预定时刻终止该连接

在终止处理中，finish 不直接关闭套接字，而是交由循环回收，原因是什么？

• 因为选择器会代替已关闭套接字清空发送缓冲区
• 为了分离终止原因标记与注销、close 的执行顺序
• 为了省略套接字 close，以便为下一个请求保留同一个 FD
• 因为收到 EOF 后必须永久保留 READ 事件关注

以下哪一项最准确地说明服务器 complete 原因所代表的范围？

• 客户端业务处理和数据持久化都已完成
• 整个 TCP 发送路径今后都会保持无错误
• 本地输出队列已清空，但对端是否处理需另行确认
• 表示客户端已经读取服务器最后发送的 FIN