Reliable vs. Best-Effort Transport可靠傳輸與盡力而為傳輸

The terms reliable and best effort are terms that describe two types of connections between computers. TCP is a connection-oriented protocol designed to help ensure reliable transport, flow control, and guaranteed delivery of IP packets. For this reason, it is labeled a "reliable" protocol. UDP is a connectionless protocol that relies on the application layer for sequencing and detection of dropped packets and is considered "best effort." Each protocol has strengths that make them useful for particular applications.

可靠（reliable）與盡力而為（best effort）這兩個詞，用來描述電腦之間兩種類型的連線。TCP 是一種連線導向協定，設計用來協助確保可靠的傳輸、流量控制，以及 IP 封包的保證送達，因此被稱為「可靠」協定。UDP 則是一種無連線協定，依賴應用層來進行排序及偵測遺失的封包，因此被視為「盡力而為」。每種協定各有其優勢，使其適用於特定應用程式。

Some types of applications require a guarantee that packets arrive safely and in order. Any missing packets could cause the data stream to be corrupted. Consider the example of using your web browser to download an application. Every piece of that application must be assembled on the receiver in the proper binary order, or it will not execute. FTP is an application where the use of a connection-oriented protocol like TCP is indicated.

某些應用程式需要保證封包能安全且依序送達，任何遺失的封包都可能導致資料串流損毀。以使用網頁瀏覽器下載應用程式為例，該應用程式的每個部分都必須在接收端以正確的二進位順序組裝，否則就無法執行。FTP 就是一種適合使用 TCP 這類連線導向協定的應用程式。

TCP uses a three-way handshake when setting up a connection. You can think of it as being similar to a phone call. The phone rings, the called party says "hello," and the caller says "hello." Here are the actual steps:

TCP 在建立連線時使用三向交握。你可以把它想像成打電話：電話響了，被叫方說「哈囉」，撥號方也說「哈囉」。實際步驟如下：

To support reliability, a connection is established between the IP source and destination to ensure that the application is ready to receive data. During the initial connection establishment process, information is exchanged about the receiver's capabilities, and starting parameters are negotiated. These parameters are then used for tracking data transfer during the connection.

為了支援可靠性，IP 來源端與目的端之間會建立連線，以確保應用程式已準備好接收資料。在初始連線建立過程中，雙方會交換有關接收端能力的資訊，並協商起始參數。這些參數之後會用於追蹤該連線的資料傳輸。

When the sending computer transmits data, it assigns a sequence number to each packet. The receiver then responds with an acknowledgment number that is equal to the next expected sequence number. This exchange of sequence and acknowledgment numbers allows the protocol to recognize when data has been lost, duplicated, or arrived out of order.

當傳送端電腦傳輸資料時，會為每個封包指派一個序號。接收端接著會以等於下一個預期序號的確認號來回應。這種序號與確認號的交換，讓協定能夠識別資料是否遺失、重複或順序錯誤。

The following example might help to better understand the importance of sequence numbers. TCP keeps track of sent data by assigning a 32-bit sequence number to every transmitted byte. Also, TCP uses related acknowledgment numbers to help ensure that all the necessary data were transmitted and not lost.

以下範例有助於進一步理解序號的重要性。TCP 會為每個傳輸的位元組指派一個 32 位元序號，藉此追蹤已傳送的資料。此外，TCP 也使用相對應的確認號，協助確保所有必要資料都已傳輸且未遺失。

If the transmission is related to the initial TCP window opening (SYN-SYNACK-ACK), as shown in the example, it is an initial sequence number and in that case, the acknowledgment number is equal to the sequence number plus 1.

如範例所示，若該次傳輸與初始 TCP 視窗開啟（SYN-SYNACK-ACK）有關，則它是一個初始序號，此時確認號等於序號加 1。

In case the transmission is not related to the initial TCP window, it is an accumulated sequence number, with regard to the first data byte of that ongoing TCP session.

若該次傳輸與初始 TCP 視窗無關，則它是一個累加序號，相對於該持續進行中 TCP 工作階段的第一個資料位元組而言。

The example shows that after the first 3 packets, the TCP window transmits application data, therefore, Packet 4 contains a GET message, where Host A requires 200 Bytes from Host B, starting with sequence number 1. This means that the next expected sequence number will be 201.

範例顯示，在前 3 個封包之後，TCP 視窗開始傳輸應用程式資料，因此封包 4 包含一則 GET 訊息，其中主機 A 向主機 B 要求 200 位元組的資料，從序號 1 開始。這表示下一個預期序號將會是 201。

Packet 5 shows that Host B responds with the sequence number equal to 1 since Host B has not yet sent any data while being engaged with a redirecting task. At the same time Host B acknowledges the receipt of 200 Bytes from Host A, by sending the acknowledgment number 201. This packet contains 300 Bytes of useful payload. The next sequence number that Host B should use will later be 301.

封包 5 顯示主機 B 以等於 1 的序號回應，因為主機 B 在處理重新導向工作期間尚未傳送任何資料。同時，主機 B 藉由傳送確認號 201，確認已收到主機 A 的 200 位元組資料。此封包包含 300 位元組的有效承載資料。主機 B 之後應使用的下一個序號將是 301。

Packet 6 is sent as another GET request from Host A, with a length of 400 Bytes. The accumulated sequence number is 601 1+400. This packet acknowledges 300 Bytes, sent by Host B, by sending an Ack value of 301.

封包 6 是主機 A 傳送的另一個 GET 請求，長度為 400 位元組。累加序號為 601（1+400）。此封包確認收到主機 B 傳送的 300 位元組，方式是傳送確認值 301。

Finally, in Packet 7, Host B requests 800 Bytes of data, with the starting sequence number of 301. Therefore, the following sequence number would be 1101. It received 400 Bytes from Host A and it acknowledges 601.

最後，在封包 7 中，主機 B 要求 800 位元組的資料，起始序號為 301，因此下一個序號將會是 1101。主機 B 收到主機 A 的 400 位元組並確認 601。

It is relevant to say, that both Hosts A and B maintain their sequence numbers.

值得一提的是，主機 A 與主機 B 都各自維護自己的序號。

The benefit of using the sequence number is to be able to recognize the gap of lost data.

使用序號的好處在於能夠識別遺失資料的缺口。

Reliability (guaranteed delivery) is not always necessary, or even desirable. For example, if one or two segments of a VoIP stream fail to arrive, it would only create a momentary disruption in the stream. This disruption might appear as a momentary distortion of the voice quality, but the user may not even notice. In real-time applications, such as voice streaming, dropped packets can be tolerated as long as the overall percentage of dropped packets is low.

可靠性（保證送達）並非總是必要，甚至有時並不理想。例如，若 VoIP 串流中有一兩個區段未能送達，只會在串流中造成短暫中斷。這種中斷可能表現為語音品質的短暫失真，但使用者甚至可能不會察覺。在即時應用程式（例如語音串流）中，只要遺失封包的整體比例不高，封包遺失是可以容忍的。

UDP provides applications with best-effort delivery and does not need to maintain state information about previously sent data. Also, UDP does not need to establish any connection with the receiver and is termed connectionless. There are many situations in which best-effort delivery is more desirable than reliable delivery. A connectionless protocol is desirable for applications that require faster communication without verification of receipt.

UDP 為應用程式提供盡力而為的傳遞，且不需要維護先前傳送資料的狀態資訊。此外，UDP 不需要與接收端建立任何連線，因此稱為無連線。在許多情況下，盡力而為的傳遞比可靠傳遞更為理想。對於需要更快速通訊、且不需驗證收訖的應用程式來說，無連線協定是較理想的選擇。

UDP is also better for transaction type services, such as DNS or DHCP. In transaction type services, there is only a simple query and response. If the client does not receive a response, it simply sends another query, which is more efficient and consumes fewer resources than TCP.

UDP 也更適合交易型服務，例如 DNS 或 DHCP。在交易型服務中，只有簡單的查詢與回應。如果用戶端沒有收到回應，只需再送出一次查詢即可，這比 TCP 更有效率，也消耗較少資源。

The postal service can be used as an analogy to illustrate the differences between connection-oriented TCP and connectionless services that UDP provides.

可以用郵政服務來類比說明連線導向的 TCP 與 UDP 提供的無連線服務之間的差異。

Imagine that you are a popular author in Seattle. Your editor in Indianapolis is very anxious to publish your next novel and demands that you mail her each page as you finish one. You print each page of the book as you write them and put each page in a separate envelope. To ensure that your editor reassembles the book correctly, you put a page number on each envelope (a sequence number). You address the envelope and send the first one as certified mail. The postal service delivers it by any truck and any route. Still, because it is certified, the carrier who delivers it must get a signature from your editor and return a delivery certificate to you.

想像你是一位住在西雅圖的暢銷作家，你在印第安納波利斯的編輯迫不及待想出版你的下一本小說，並要求你每完成一頁就寄給她。你邊寫邊列印每一頁，並將每頁裝進不同的信封。為了確保編輯能正確重新組裝這本書，你在每個信封上都標了頁碼（也就是序號）。你寫上地址並以掛號信寄出第一封信，郵政服務可經由任何卡車、任何路線送達；但因為是掛號信，負責投遞的郵差必須取得編輯的簽收，並將送達證明交還給你。

Your contract with the publisher specifies that each page must be in a separate envelope. But having to go to the post office to send each letter individually is too time-consuming, so you send several envelopes together. The postal service again delivers each envelope by any truck and any route. Your editor signs a separate receipt for each envelope in the batch as she receives them. If one envelope is lost in transit, you will not receive a certificate of delivery for that numbered envelope, and you will need to resend that page. As your editor receives your envelopes, she uses the sequence numbers to assemble the book in the proper order.

你與出版社的合約規定每頁必須裝在不同的信封中。但每次都要跑一趟郵局分別寄送太耗時，因此你把好幾個信封一起寄出，郵政服務同樣經由任何卡車、任何路線遞送。編輯在收到批次中的每個信封時，會分別簽收。如果有一個信封在途中遺失，你就不會收到那個編號信封的送達證明，你就需要重新寄送那一頁。編輯在收到你的信封後，會根據序號將這本書依正確順序組裝起來。

Like certified mail, TCP offers sequencing, acknowledgments, and retransmission.

就像掛號信一樣，TCP 提供排序、確認與重傳功能。

UDP services can be compared to using the postal service to pay your bills. You address each bill payment to a specific company address, stamp the envelope, and include your return address. The postal service guarantees its best effort to deliver each payment. The postal service does not guarantee delivery, and it is not responsible for telling you that delivery was successful or unsuccessful.

UDP 服務可以類比為使用郵政服務繳交帳單。你在每筆帳單付款上寫上特定公司的地址、貼上郵票，並附上你的回郵地址。郵政服務保證會盡力遞送每筆付款，但不保證一定送達，也不負責告知你送達成功或失敗。

Like standard mail, UDP is a simple process that provides basic data transfer services.

就像普通信件一樣，UDP 是一個提供基本資料傳輸服務的簡單流程。