🔗 另一个客户端侧？

或者说，“一个新的 HTTP 服务器侧”，因为事实就是如此。

一个 HTTP 服务器侧应该实现以下功能

• 网络连接管理
• 解析网络上传入的请求；构建 HTTP 服务器请求
• 实现 HTTP 服务器数据 API，用于发送请求+请求体，并接收来自 HTTP 请求的回复消息
• 可能需要实现 SSL

它可能实现的功能

• HTTP 认证？或者可以将其实现为 HTTP 网络服务器和 HTTP 请求队列之间的交互？
• SSL。这是一个连接属性。

它不会实现的功能

• ACL 检查：这应该作为 HTTP 请求队列的一部分来完成
• URL 重写：这应该作为 HTTP 请求队列的一部分来完成
• 传输/内容编码（deflate/gzip）；这应该作为数据管道的一部分来完成。

🔗 它是如何组成的

• 连接管理器 - 处理文件描述符 (FD) 的方面，包括缓冲等。
• 单个请求 - 这些是 HTTP 请求的服务器端终结点，与对等方交换 HTTP 消息。
• 请求将获得对 FD 的串行访问权限，因此多个请求可以同时存在（流水线），而单个回复可以按正确的顺序写入。

🔗 通用流程图将是什么样的

• 请求将传入；创建连接管理器 + 初始请求
• 解析请求并排队一个 HTTP 请求
• 如果请求包含 HTTP 请求体，则连接将进入“bodyreader”模式，直到所有请求体数据都被读取完毕；否则重置并解析下一个请求，将请求流水线式地输入 HTTP 请求队列。
• 请求将从 HTTP 请求（嗯，我真的应该在这里使用更清晰的术语）得到通知，并开始接收 HTTP 消息或生成自己的内容以处理错误情况。
• 当请求完成向连接发送数据后，它将决定是将控制权传递给下一个请求（以便它可以将数据写入 FD），还是关闭连接。这里也需要考虑请求体。

🔗 如何处理错误？

在单进程非线程设置中处理错误相对容易 - 只需中止所有未完成的请求并立即删除该对象。这在多线程设置中可能行不通，所以

• 连接关闭不应强制对象立即消失 - 它应该进入 CLOSED 状态。
• 它应该保留，直到当前待处理的请求完成或被中止 - 因此它应该在请求上设置一个中止标志，并等待其返回。它可能几乎立即返回；也可能需要稍长一些时间，因为其他线程中排队的事件将被通知请求正在被取消。
• 一旦所有待处理的请求都被取消或已返回 - 然后 - 该对象就可以进入 DEAD 状态并被释放。

🔗 关于多线程呢？

理论上，服务器连接应该是自包含的；因此，多个线程可以运行多路复用的服务器连接，而无需任何线程间锁定。对于某些“事物”（例如共享的 HTTP 认证缓存、DNS 请求等）来说，情况可能并非如此，但这些可以作为单独的消息队列。

诀窍是让服务器侧足够长地存在，以接收它拥有的所有排队消息，或者能够取消它们。

分类: WantedFeature

导航：网站搜索，网站页面，分类，🔼 向上