<接上文>
互联网架构和实现之间还有一个问题，那就是性能。互联网架构设计的是点到点或者点到多点的网络，以及他们之间如何通信，至于这种通信的性能，因为不同网络可能差距巨大，因此没有对性能有明确的定义，比如达到每秒钟传送1000个报文。这种实现所导致的性能问题，最终是留给实现者来考虑。基于此，有两种传输模式。
- 数据包传输
数据包传输模式，也就是类似于IP层的尽力转发模式，之所以重要，作者认为有如下几种原因。
1）减少中间设备的连接状态，这样当故障发生后可以快速重建。（像前文所说，状态主要在终端上维护，中间设备其实没有什么状态）
2）数据包传输提供了一种基本的传输模式，用以向高层应用提供基本的构建块。相对来说，虚电路方式（也就是TCP方式）只提供固定类型的服务。
3）数据包传输代表了最小限度的网络服务假设，即互联网可以承载在很多类型的链路上，也就是适应性强。
以上3点导致采用数据包传输模式取得了很大的成功，
作者说很多人对于数据包模式有个误解，那就是认为是由于有些服务需要数据包传输模式，才设计出它。作者认为，事实上，只有时间查询或者名字查询需要此种数据包模式，也就是不可靠模式，其他很多应用需要的是更复杂的传输服务，而这比数据包模式要复杂很多。比如有些服务需要高可靠性，有些需要比较稳定的时延，有缓存机制，总之都比数据包传输模式复杂。重要的是认识到数据包模式是一种服务构建块，而不是服务本身。
补充：这种模式为上层提供了一些操作网络层的接口，使得应用层可以设计出自己的传输方法，甚至是协议类型，比如QUIC, VXLAN等。
- TCP
TCP协议在真正能够使用之前，其实经历了很多设计上的抉择。作者不打算讨论这些历史抉择的原因，而只想讨论为什么要这么做。关于TCP的完整历史回顾需要别的长文章完成。
TCP在设计之初采用来基于字节的和基于报文的流控，这显然是很复杂的。设计者认为最终只需要一种类型的流控就够了，而最后选择基于字节的流控。所以我们现在在TCP实现中看到的流控和确认都是基于字节的，而不是报文的。作者认为最重要的是因为设计者考虑到，如果报文需要重传，允许将多个小包组合成一个大包重传会更高效，而这就需要基于字节的重传，因为基于报文的重传会严格要求报文原样重传，而基于字节的重传不关心报文数量的多少。
另一方面，对于字节的确认在第一次就会触发这个问题。如果是基于数据包的确认而不是字节的确认，这种洪泛就不会发生。但是数据包级别的控制会导致严重的吞吐限制问题，如果是基于小包的发送。如果接受者通知可以接受报文，但是对于发送报文的长度一无所知，事实上的报文数据量最多会有1000倍的差距，取决于数据包是1个字节还是1000个字节。
当然，如果TCP最开始被要求满足各种服务要求，可能基于字节的流控和基于数据包的流控都会被保留下来。如果真的这样，复杂的TCP/IP协议可能不会这么快流行起来，当然问题也会存在很多。
后记：
由于这篇论文写作于1988年，而那个时候TCP/IP的发展还处于初期，因此早期的一些设计现在被废弃了，而其他的一些设计由于适应网络的快速发展而保留了下来。当我们回顾历史的时候，可能看不清那些设计或者决定是如何做出的，但是从中找出一些蛛丝马迹，对于我们现在理解互联网络也会有一些帮助的。
<完>