<接上文>
網際網路架構和實現之間還有一個問題，那就是效能。網際網路架構設計的是點到點或者點到多點的網路，以及他們之間如何通訊，至於這種通訊的效能，因為不同網路可能差距巨大，因此沒有對效能有明確的定義，比如達到每秒鐘傳送1000個報文。這種實現所導致的效能問題，最終是留給實現者來考慮。基於此，有兩種傳輸模式。

1. 資料包傳輸

資料包傳輸模式，也就是類似於IP層的盡力轉發模式，之所以重要，作者認為有如下幾種原因。
1）減少中間裝置的連線狀態，這樣當故障發生後可以快速重建。（像前文所說，狀態主要在終端上維護，中間裝置其實沒有什麼狀態）
2）資料包傳輸提供了一種基本的傳輸模式，用以向高層應用提供基本的構建塊。相對來說，虛電路方式（也就是TCP方式）只提供固定型別的服務。
3）資料包傳輸代表了最小限度的網路服務假設，即網際網路可以承載在很多型別的鏈路上，也就是適應性強。
以上3點導致採用資料包傳輸模式取得了很大的成功，

作者說很多人對於資料包模式有個誤解，那就是認為是由於有些服務需要資料包傳輸模式，才設計出它。作者認為，事實上，只有時間查詢或者名字查詢需要此種資料包模式，也就是不可靠模式，其他很多應用需要的是更復雜的傳輸服務，而這比資料包模式要複雜很多。比如有些服務需要高可靠性，有些需要比較穩定的時延，有快取機制，總之都比資料包傳輸模式複雜。重要的是認識到資料包模式是一種服務構建塊，而不是服務本身。

補充：這種模式為上層提供了一些操作網路層的介面，使得應用層可以設計出自己的傳輸方法，甚至是協議型別，比如QUIC, VXLAN等。

2. TCP

TCP協議在真正能夠使用之前，其實經歷了很多設計上的抉擇。作者不打算討論這些歷史抉擇的原因，而只想討論為什麼要這麼做。關於TCP的完整歷史回顧需要別的長文章完成。

TCP在設計之初採用來基於位元組的和基於報文的流控，這顯然是很複雜的。設計者認為最終只需要一種型別的流控就夠了，而最後選擇基於位元組的流控。所以我們現在在TCP實現中看到的流控和確認都是基於位元組的，而不是報文的。作者認為最重要的是因為設計者考慮到，如果報文需要重傳，允許將多個小包組合成一個大包重傳會更高效，而這就需要基於位元組的重傳，因為基於報文的重傳會嚴格要求報文原樣重傳，而基於位元組的重傳不關心報文數量的多少。

另一方面，對於位元組的確認在第一次就會觸發這個問題。如果是基於資料包的確認而不是位元組的確認，這種洪泛就不會發生。但是資料包級別的控制會導致嚴重的吞吐限制問題，如果是基於小包的傳送。如果接受者通知可以接受報文，但是對於傳送報文的長度一無所知，事實上的報文資料量最多會有1000倍的差距，取決於資料包是1個位元組還是1000個位元組。

當然，如果TCP最開始被要求滿足各種服務要求，可能基於位元組的流控和基於資料包的流控都會被保留下來。如果真的這樣，複雜的TCP/IP協議可能不會這麼快流行起來，當然問題也會存在很多。

後記：
由於這篇論文寫作於1988年，而那個時候TCP/IP的發展還處於初期，因此早期的一些設計現在被廢棄了，而其他的一些設計由於適應網路的快速發展而保留了下來。當我們回顧歷史的時候，可能看不清那些設計或者決定是如何做出的，但是從中找出一些蛛絲馬跡，對於我們現在理解網際網路絡也會有一些幫助的。

<完>