TCP还是UDP？

到个人博客阅读 »

在读《ETIP》(Effective TCP/IP Programming)Tip7时收获的一些心得，记录下来。

在开发网络程序时，我们经常需要面对的一个问题是：选择TCP还是UDP？我们的一般印象是TCP是面向连接的、可靠有序的、基于字节流的协议，而UDP是无连接的、不可靠的、面向消息的协议。通常粗略的认为在需要可靠性时，选择TCP，需要高效率时选择UDP。然而，在做出选择时，我们需要考虑的更多些。

TCP和UDP位于IP上一层，IP层本身提供了一个很好的高效、不可靠、无连接的服务。TCP在基本的IP服务上增加了校验位、序列号、确认和重传以及流量控制机制，以保证可靠性，UDP则仅增加了可选的校验和来获得可接受的性能。TCP相对复杂，这似乎看起来UDP就比TCP更快。在有些情况下，确实如此。但是在通常的网络编程中，任何协议的性能都依赖于网络、应用程序、负载及其他因素，这些因素也包括具体实现的性能。所以在某些时候，TCP的性能实质上比UDP还要快。

现在先来考虑一下为什么在某些情况下以及在哪些情况下UDP的性能大大高于TCP。

首先，因为TCP是一个更复杂的协议，所以它比UDP需要做更多的处理。从CPU来看，在处理两个协议时的主要操作是拷贝数据和数据校验，这方面两者没有太大差异。对于提供可靠性，接收端TCP必须发送ACK给发送端TCP，这就增加了双方必须做的处理工作，不过接收方可以在任何必须发送给对等方的数据中捎带ACK消息，许多TCP的具体实现就是延迟几毫秒来发送ACK消息，而且TCP并不需要为每个段都返回一个ACK消息。

其次，TCP和UDP主要的差异体现在TCP是一个面向连接的协议，因此必须处理连接的建立和撤销。通常情况下建立连接需要交换3个段，撤销连接需要交换4个段，假设撤销连接都被数据传输“吸收”了，我们集中讨论建立连接时发生的事情。

fig.1

如图1所示，client发送一个SYN段给server开始建立连接，这个段其中包含的连接参数有将要接受的最大段大小（MMS）和初始接收窗口的大小，另外还有客户端将要发送数据使用的第一个序列号。server在响应时，发送自己的SYN段和对客户端SYN消息的确认ACK。最后，client确认服务器的SYN，建立连接就结束了。

从图中看出，在连接建立的整个过程中，共计消耗了1.5个RTT时间。如果client-server使用长连接交互，比如要进行大量数据传输，1.5个RTT时间显然微不足道，不会很大的影响性能，这时可能TCP比UDP的性能要好。然而，如果client-server只涉及到短的请求/应答会话，那么连接的时间就占去了整个通信事务的很大部分，这时，UDP的性能相比TCP好很多。《ETIP》中通过一个极简单普通的例子来测试进行大量数据传输时，TCP和UDP的相对性能情况。这里总结一下：

发送数据报的大小对性能的影响：由于TCP是基于字节流的协议，使用Nagle算法，合并多个包一起发送，也即发送次数减少了，同时意味着处理量减少了，而UDP按数据报的大小发送。所以在选择接近网络接口的最大传输单元MTU大小（如以太网的MTU是1500Bytes）发送数据时，TCP具有性能优势。（可以通过分别在本机和局域网内测试验证）

另外，即使client-server在同一台机器上传输数据，UDP也不能保证任何特定的数据报能够安全的到达。

鉴于TCP/UDP各自的表现，可以在应用层改造UDP（即可靠UDP，可以参考开源库UDT/Enet），提供超时重传（对每个发送请求设置一个定时器），保证有序，进行流量控制（防止缓冲区塞满）。（这些TCP都是在内核环境中进行的，具有“先天优势”）

参考：《Effective TCP/IP Programming》