1.2  同步及异步消息交换

在很多网络应用程序中，客户向服务器发送一个请求，后者处理这个请求，然后返回一个应答。这种请求/应答协议既可以在无连接协议上实现，也可以在面向连接协议上实现。管理请求/应答协议交换的可选策略有两种：同步（synchronous）和异步（asynchronous），如图1.2所示。是选择同步还是异步消息交换策略，要考虑以下两个因素：

图1.2  同步及异步消息交换策略

1.        请求之间的关联性（interrelatedness）；

2.        底层协议或传输介质的延迟。

以下，我们来看看这些因素如何影响到策略的选择。

同步请求/应答协议。这是最容易实现的形式。在这种协议中，请求（request）和应答（response）是以锁步（lock-step）次序交换的。每一个请求必须同步地接收到一个应答，然后才能发送下一个请求，如图1.2(1)所示。同步请求/应答协议适用于以下场合。

l  请求的结果决定后续的请求。例如，某一应用程序需要交换验证信息，那么，在安全认证信息成功交换之前，它不会发送机密信息请求。

l  应用程序中交换的信息需要在低延迟（low-latency）网络中执行短期处理，如高速LAN中的NFS read()和write()操作。

l  较之后文介绍的异步请求/应答协议有可能获得的“性能上的提高”，“实现（implementation）的简易性”或“协议交换的少量性”更为重要。

异步请求/应答协议。它将请求从客户连续发送至服务器，无需同步地等待应答^[AOS+00]。多个客户请求可以在服务器应答到达之前发送，如图1.2(2)所示。因此，异步请求/应答协议往往需要一种策略，用来检查请求的丢失或失败，然后重新发送。异步请求/应答协议适用于以下场合：

l  无需应答就可以决定后续请求。例如，Web浏览器可以使用异步策略，用于从同一服务器获取多个嵌入图像。因为每一个请求都是独立的，它们全都可以异步发送，不必等待应答。浏览器利用每一个应答中包含的信息，将应答匹配至相应的请求——即使应答的顺序不同于请求的发送顺序。

l  “通信的延迟”和“请求所需的处理时间”密切相关。异步请求策略有助于有效地利用网络，减少高延迟带来的影响。较之将“应答”和“请求”关联起来并实现“重试”策略所带来的额外复杂度，它在性能上的提高更为重要。

日志服务程序 => 在网络日志服务器中，我们使用的是异步请求/应答协议的单向形式（one-way variant），所以不需要应用程序级（application-level）响应。日志记录只是从客户应用程序传给日志服务器，也就是说，不需要服务器在应用程序级做出应答。日志服务器在接收到每一条日志记录后，都会将记录立即写入磁盘，并假设每一条发送出来的日志记录都被可靠地记录了下来。只要客户程序不需要网络日志服务程序采取“强烈”手段来确保所有日志记录都被永久存储——即使有灾难性的故障发生——这个设计就已经足够了。如果真的有那样的需求，我们就得开发“基于事务（transaction-based）”的日志服务；那将会更复杂，还会带来显著的时间/空间开销。