并发编程网 - ifeve.com

原文地址

如果设计一个客户端到服务器的系统，那么同时也需要设计客户端和服务器之间的通信协议。当然，有时候协议已经为你决定好了，比如HTTP、XML_RPC（http response 的 body 使用xml）、或者SOAP(也是http response 的 body 使用xml)。设计客户端到服务端协议的时候，一旦协议决定开启一会儿，来看一些你必须考虑的地方：

1. 客户端到服务端的往返通讯

2.区分请求结束和响应结束。

3.防火墙穿透

客户端-服务端往返

当客户端和服务端通信，执行操作时，他们在交换信息。比如，客户端执行一个服务请求，服务端尝试完成这个请求，发回响应告诉客户端结果。这种客户端和服务端的信息交换就叫做往返。示意图如下：

当一个计算机（客户端或者服务端）在网络中发送数据到另一个计算机时，从数据发送到另一端接收数据完会花费一定时间。这就是数据在网络间的传送的时间花费。这个时间叫做延迟。

协议中含有越多的往返，协议变得越慢，延迟特别高。HTTP协议只包含一个单独的响应来执行服务。换句话说就是一个单独的往返。另一方面，在一封邮件发送前，SMTP协议包含了几个客户端和服务端的往返。

在协议中有多个往返的原因是：有大量的数据从客户端发送到服务端。这种情况下你有2个选择：

1.在分开往返中发送头信息；

2.将消息分成更小的数据块。

如果服务端能完成头信息的一些初始验证 ，那么分开发送头信息是很明智的。如果头信息是空白的，发送大量数据本身就是浪费资源。

在传输大量数据时，如果网络连接失败了，得从头开始重新发送数据。数据分割发送时，只需要在网络连接失败处重新发送数据块。已经发送成功的数据块不需要重新发送。

区分请求结束和响应结束

如果协议容许在同一个连接中发送多个请求，需要一个让服务端知道当前请求何时结束、下一个请求何时开始。客户端也需要知道一个响应何时结束了，下一个响应何时开始。

对于请求有2个方法区分结束：

1.在请求的开始处发送请求的字长

2.在请求数据的最后发送一个结束标记。

HTTP用第一个机制。在请求头中 发送了“Content-Length”。请求头会告诉服务端在头文件后有多少字节是属于请求的。

这个模型的优势在于没有请求结束标志的开销。为了避免数据看上去像请求结束标志，也不需要对数据体进行编码。

第一个方法的劣势：在数据传输前，发送者必须知道多少字节数将被传输。如果数据时动态生成的，在发送前，首先你得缓存所有的数据，这样才能计算出数据的字节数。

运用请求结束标志时，不需要知道发送了多少字节数。只需要知道请求结束标志在数据的末尾。当然，必须确认已发送的数据中不包含会导致请求结束标志错误的数据。可以这样做：

可以说请求结束标志是字节值255。当然数据可能包含值255。因此，对数据中包含值255的每一个字节添加一个额外的字节，还有值255。结束请求标志被从字节值255到255之后的值为0。如下编码：

255 in data –>255， 255

end-of-request –> 255, 0

这种255，0的序列永远不会出现在数据中，因为你把所有的值255变成了255,255。同时，255,255,0也不会被错认为255,0。255,255被理解成在一起的，0是单独的。

防火墙穿透

比起HTTP协议，大多数防火墙会拦截所有的其他通信。因此把协议放在HTTP的上层是个好方法，像XML-RPC,SOAP和REST也可以这样做。

协议置于HTTP的上层，在客户端和服务端的HTTP请求和响应中可以来回发送数据。记住，HTTP请求和响应不止包含text或者HTML。也可以在里面发送二进制数据。

将请求放置在HTTP协议上，唯一有点奇怪的是：HTTP请求必须包含一个“主机”头字段。如果你在HTTP协议上设计P2P协议，同样的人最可能不会运行多个“主机”。在这种情况下需要头字段是不必要的开销（但是个小开销）。