協議的設計（摘至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 的交互，而且馬上就能看到客戶端發送給服務器端的消息。