协议的设计（摘至GO 网络编程）

-摘自GO 网络编程(Network programming with Go)，翻译者不详

Protocol Design协议设计

There are many possibilities and issues to be decided on when designing a protocol. Some of the
issues include:
当设计协议的时候，有许多许多的状况和问题须要考虑，好比：

· Is it to be broadcast or point to point?
Broadcast must be UDP, local multicast or the more experimental MBONE. Point to point
could be either TCP or UDP.

· 是广播仍是单播？
广播必须使用UDP，本地组播或者是更成熟的组播骨干网（MBONE）。单播就可
以使用TCP 或者UDP。

· Is it to be stateful vs stateless?
Is it reasonable for one side to maintain state about the other side? It is often simpler to do
so, but what happens if something crashes?

· 消息应该是有状态仍是无状态的？
任意一边是否有必要维持另一边的状态消息？虽然这个彷佛很好实现，可是若是
发生异常的时候又应该怎么作呢？

· Is the transport protocol reliable or unreliable?
Reliable is often slower, but then you don't have to worry so much about lost messages.

· 协议是可靠服务仍是不可靠服务？
通常来讲，提供可靠服务就会更慢些，但好处是不须要考虑丢失消息的状况。

· Are replies needed?
If a reply is needed, how do you handle a lost reply? Timeouts may be used.

· 是否须要响应？
若是是须要响应的话，如何处理没有响应回复的状况？或许能够设置超时时间。

· What data format do you want?
Two common possibilities are MIME or byte encoding.

· 你想要使用什么数据格式？
通常使用两种格式：MIME 和字节流

· Is your communication bursty or steady stream?
Ethernet and the Internet are best at bursty traffic. Steady stream is needed for video streams
and particularly for voice. If required, how do you manage Quality of Service (QoS)?

· 消息流是使用突发性的仍是稳定性的？
Ethernet 和Internet 最好使用突发性消息流。稳定性的消息流一般是用在视频和声频
流传输上。若是要求的话，你如何保证你的服务质量（QoS）？

· Are there multiple streams with synchronisation required?
Does the data need to be synchronised with anything? e.g. video and voice.

· 有多流同步的需求吗？
是否有多种数据流须要进行同步？好比视频流和声频流。

· Are you building a standalone application or a library to be used by others?
The standards of documentation required might vary.

· 创建的是单独的应用仍是须要给别人使用的库？
可能须要花很大的精力编写标准文档。

Version control 版本控制

A protocol used in a client/server system will evolve over time, changing as the system expands. This
raises compatability problems: a version 2 client will make requests that a version 1 server doesn't
understand, whereas a version 2 server will send replies that a version 1 client won't understand.

随着时间变化和系统的升级，客户端/服务器之间的协议也会升级。这可能会引发兼容性的问题：版本2 的客户端发出的请求可能版本1 的服务器没法解析，反之也同样，版本2 的服务器回复的消息版本1 的客户端没法解析。

Each side should ideally be able to understand messages for its own version and all earlier ones. It
should be able to write replies to old style queries in old style response format.

理想状况下，不管是哪一端，都应该既能知足本身当前版本的消息规范，也能知足早期版本的消息规范。任意一端对于旧版本的请求应该返回旧版本的响应。

The ability to talk earlier version formats may be lost if the protocol changes too much. In this case,
you need to be able to ensure that no copies of the earlier version still exist - and that is generally
imposible.

可是若是协议变化太大的话，可能就很难保持与早期版本的兼容了。在这种状况下，你就需要保证已经不存在早期的版本了 -- 固然这个几乎是不可能的。

Part of the protocol setup should involve version information.

因此，协议应该包含有版本消息。

The Web Web协议

The Web is a good example of a system that is messed up by different versions. The protocol has
been through three versions, and most servers/browsers now use the latest version. The version is
given in each request

Web 协议就是一个因为有不一样协议版本同时存在而出现混乱的例子。Web 协议已经有三个版本了，一般服务器和浏览器都是使用最新的版本，版本消息包含在请求中：

request	version
GET /	pre 1.0
GET / HTTP/1.0	HTTP 1.0
GET / HTTP/1.1	HTTP 1.1

But the content of the messages has been through a large number of versions:
可是消息体的内容已经被大量版本制定修改过：
· HTML versions 1-4 (all different), with version 5 on the horizon;

· HTML 版本1-4（每一个版本都不同），还有即将到来的HTML5;

· non-standard tags recognised by different browsers;

· 不一样浏览器各自支持非标准化的标签;

· non-HTML documents often require content handlers that may or may not be present - does your browser have a handler for Flash?

· HTML 文档以外的内容也一般须要不同的内容处理器 -- 好比你的浏览器支持Flash播放器吗？

· inconsistent treatment of document content (e.g. some stylesheet content will crash some browsers)

· 文档内容的不一致的处理方法（例如，在一些浏览器上，有的css 会冲突）

· Different support for JavaScript (and different versions of JavaScript)

· 浏览器对JavaScript 的不一样支持程度（固然JavaScript 也同时存在不一样的版本）

· Different runtime engines for Java

· 不一样的Java 运行引擎

· Many pages do not conform to any HTML versions (e.g. with syntax errors)

· 有的页面并无遵照任何HTML 版本规范（好比HTML 格式错误的页面）

Message Format 消息格式

In the last chapter we discussed some possibilities for representing data to be sent across the wire.
Now we look one level up, to the messages which may contain such data.
上一章咱们讨论了数据传输的几种可能的表现形式。如今咱们进一步研究包含数据的消息。

· The client and server will exchange messages with different meanings. e.g.
         o Login request,
         o get record request,
         o login reply,
         o record data reply.

· 客户端和服务器会交换不一样含义的消息，好比：
         o 登录请求
         o 获取某些记录的请求
         o 登录请求的回复
         o 获取某些记录请求的回复

· The client will prepare a request which must be understood by the server.

· 客户端必须发送能被服务器解析的请求。

· The server will prepare a reply which must be understood by the client.

· 服务器必须回复能被客户端解析的响应。

Commonly, the first part of the message will be a message type.
一般来讲，消息的头部必须包含消息类型。

The message types can be strings or integers. e.g. HTTP uses integers such as 404 to mean "not
found" (although these integers are written as strings). The messages from client to server and vice
versa are disjoint: "LOGIN" from client to server is different to "LOGIN" from server to client.

消息类型应该设置为字符型或者整型。好比，HTTP 使用整数404 来表示“未找到资源”（尽管这个整型是被当作字符串使用）。客户端到服务器的消息和服务器到客户端的消息是不同的：好比从客户端到服务器的“LOGIN”消息就不一样于服务器到客户端的“LOGIN”消息。

Data Format 数据格式

There are two main format choices for messages: byte encoded or character encoded.

对于消息来讲，有两种主要的数据格式可供选择：字节编码和字符编码。

Byte format 字节编码

In the byte format

对于字节编码

· the first part of the message is typically a byte to distinguish between message types.

· 消息的头部一般使用一个字节来标示消息的类型。

· The message handler would examine this first byte to distinguish message type and then
perform a switch to select the appropriate handler for that type.

· 消息处理者应该根据消息头部的类型字节来选择合适的方法来处理这个类型的消息。

· Further bytes in the message would contain message content according to a pre-defined
format (as discussed in the previous chapter).

· 消息后面的字节应该是根据事先定义的格式（上一章节讨论的）来包含消息具体内
容。

The advantages are compactness and hence speed. The disadvantages are caused by the opaqueness
of the data: it may be harder to spot errors, harder to debug, require special purpose decoding
functions. There are many examples of byte-encoded formats, including major protocols such as
DNS and NFS , upto recent ones such as Skype. Of course, if your protocol is not publicly specified,
then a byte format can also make it harder for others to reverse-engineer it!

字节编码的优点就是紧凑小巧，传输速度快。劣势就是数据的不透明性：字节编码很难定位错误，也很难调试。每每是要求写一些额外的解码函数。有许多字节编码格式的例子，大部分协议都是使用字节编码，例如DNS 和NFS 协议，还有最近出现的Skype 协议。固然，若是你的协议没有公开说明结构，使用字节编码可让其余人使用反向工程手段很难破解!

Character Format 字符编码

In this mode, everything is sent as characters if possible. For example, an integer 234 would be sent as,say, the three characters '2', '3' and '4' instead of the one byte 234. Data that is inherently binary may be base64 encoded to change it into a 7-bit format and then sent as ASCII characters, as discussed in the previous chapter.

在这个编码模式下，全部消息都尽量以字符的形式发送。例如，整型数字234 会被处理成三个字符‘2’，‘3’，‘4’，而不会被处理成234 的字节码。二进制数据将会使用base64编码变成为7-bit 的格式，而后当作ASCII 码传递，就和咱们上一章讨论的同样。

In character format,

对于字符编码,
· A message is a sequence of one or more lines

· 一条消息会是一行或者不少行内容

· The start of the first line of the message is typically a word that represents the message type.

· 消息的第一行一般使用一个单词来讲明消息的类型。

· String handling functions may be used to decode the message type and data.

· 使用字符处理函数来解码消息类型和消息内容。

· The rest of the first line and successive lines contain the data.

· 第一行以后的信息和其余行包含消息数据。

· Line-oriented functions and line-oriented conventions are used to manage this.

· 使用行处理函数和行处理规范来处理消息。

Character formats are easier to setup and easier to debug. For example, you can use telnet to connect to a server on any port, and send client requests to that server. It isn't so easy the other way, but you can use tools like tcpdump to snoop on TCP traffic and see immediately what clients are sending to servers. 很容易进行组装，也很容易调试。例如，你能够telnet链接到一台服务器的端口上，而后发送客户的请求到服务器。其余的编码方式没法轻易地监听请求。可是对于字符编码，你可使用tcpdump 这样的工具监听TCP 的交互，而且马上就能看到客户端发送给服务器端的消息。