为什么 p2p 模式的 tunnel 底层通常用 udp 而不是 tcp？

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [www.zhihu.com](https://www.zhihu.com/question/39382183)

![](https://pic1.zhimg.com/85fa1149f2d02e930498508dc71e6790_xs.jpg?source=1940ef5c)

车小胖

为了更好地解释这个问题，先来科普一下什么是**隧道 (Tunnel)。**

当打开一个没有加密的网页时，客户端与服务器端交互报文的封装格式通常为：

IP/TCP/http

加密的网页的封装格式为：

IP/TCP/TLS/http

通过 FTP 下载文件时的封装格式为：

IP/TCP/ftp

当域名 / IP 地址解析时，封装格式为：

IP/UDP/dns

上述的应用，同学们每天都在自己的电脑上操作过，这些封装格式为 **“非隧道” 模式**。

**“非隧道” 模式**

无论采用 IP/TCP 组合传输，还是使用 IP/UDP 组合传输，被传输的货物本身不包含任何 IP 头。

比如 “http”、 “tls/http”、 “ftp” 、“dns” 作为货物，自身都没有包含 IP 封装。这是识别是否隧道模式的关键要素。

但上文的 “非隧道” 模式，用于访问 Internet 上的资源是非常合适的。但往往**不便于访问私有资源。**

**举个例子**

一公司在服务器 (10.0.0.8/24) 上提供文件共享服务，员工可以公司内部自由地访问，但 Internet 上的用户无法访问 10.0.0.8。

员工希望在外出差或在家办公也可以访问 10.0.0.8 这台文件服务器，如何能够做到？

这个技术就是隧道！

员工在公司内部的封装格式为：

IP/TCP/SMB

隧道的核心思想，就是希望在 “IP/TCP/SMB” 外层添加必要的外层 (outside)IP 头信息，把用户的“IP/TCP/SMB” 当作货物来运输。

既然这些货物需要在 Internet 上运输，自然需要使用 Internet 上可路由的公网 IP 才可以对吗？

假定公司的公网 IP = 2.2.2.2，用户的公网 IP =3.3.3.3

那么就使用这两个 IP 来在用户 (3.3.3.3) 与公司 (2.2.2.2) 之间运输货物，先来看看是怎么运输的：

Outside IP / IP /TCP/SMB

其中 outside IP 的源、目的 IP 分别是 3.3.3.3、2.2.2.2。

这种隧道模式即为 “**IPIP**” 类型。

**有这种隧道类型吗？**

有的，但是这种类型非常不便于穿越 NAT，因为在用户与公司之间的 NAT 总是存在的，而不同 NAT 设备的 NAT 实现也各不相同。最最最乐观的情况下，一台 NAT 设备后只能有一个用户可以隧道连接公司。

为了避免由于 NAT 的差异而造成通信故障，一般不使用 IPIP 隧道。

通常会使用 UDP 隧道，封装格式为：

Outside IP /UDP / IP /TCP/SMB

使用 UDP 封装的最大的好处是，可以使用不同的 UDP 端口来区分不同的用户隧道，那么一个 NAT 设备后理论上可以支持 65K 个用户隧道连接。

**接下来的问题是，用户的 inside IP 是多少？是谁给分配的？**

另外，用户的 “IP /TCP/SMB” 数据在 Internet 上裸奔，没有安全加密，也是无法接受的，需要有安全加密的保护。

写到这里，不得不非常痛苦地介绍一下控制协议，之所以痛苦是因为一切来的太突然。。。

这个控制协议的名字叫 **IKE (Internet Key Exchange)**

Outside IP /UDP/IKE 做了很多工作，主要可以概括为：

协商加密、校验、认证算法

交换密钥

认证双方

分配 IP 参数

假定用户被分配的 IP = 10.0.0.100

做完以上工作，用户的 “IP /TCP/SMB” 就可以这样来传输了。

Outside IP /UDP /ESP/ IP /TCP/SMB

用户 IP = 10.0.0.100，服务器的 IP = 10.0.0.8，分别为 inside IP 的源、目的 IP。

通常称 “Outside IP /UDP/IKE” 为**控制连接**， 称 “Outside IP /UDP /ESP/ IP /TCP/SMB” **用户数据连接**。

上文的 outside IP 源、目的 IP，用于在 Internet 上路由。

Inside IP 源、目的 IP，用于在公司内部路由。

**为何 TCP 隧道不好？**

让我们再来近距离地观赏一下 “Outside IP /UDP /ESP/ IP /TCP/SMB”，所有的底层传输协议，只有一个状态点 / 控制点，它就是 TCP，虽然只有一个控制点，但依然可以保证双方通信的可靠传输。其它的封装头部都是无状态的 (Stateless)。

假设外层使用 TCP 封装，那么就变成 “Outside IP / TCP /ESP/ IP /TCP/SMB”，这里就出现了两个[控制点](https://www.zhihu.com/search?q=%E6%8E%A7%E5%88%B6%E7%82%B9&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A404245930%7D) / 状态点，两个 TCP 头都会对网络行为进行控制，多了一层控制，增大了数据传输的延迟（多了一次 TCP 连接），同时 20 字节的 TCP 报文头，相比 8 字节的 UDP 头，相当于用户的数据少传输 12 个字节。

**一山难容二虎，除非一男与一女!**

UDP 隧道，所有底层封装都不对用户的数据进行控制，所有的控制都留给用户控制，这样可以给用户最大的灵活空间。

用户用 UDP 隧道来传输 UDP 报文，呈现的是 UDP 特征。

用户用 UDP 隧道来传输 TCP 报文，呈现的是 TCP 特征。

TCP 隧道，底层的 TCP 封装会对用户数据进行控制，用户将失去了灵活的空间。

**用户用 TCP 隧道来传输 UDP 报文，呈现的是 TCP 特征。**

**用户用 TCP 隧道来传输 TCP 报文，呈现的还是 TCP 特征。**

更详细内容，请参考文章：[https://mp.weixin.qq.com/s/dknMBfvdiNEc7mD_eQtqfg](https://mp.weixin.qq.com/s/dknMBfvdiNEc7mD_eQtqfg)

![](https://picx.zhimg.com/v2-abed1a8c04700ba7d72b45195223e0ff_xs.jpg?source=1940ef5c)

知乎用户

都没答到正点。包括那谁的强答。。

为什么用 udp 而不是 tcp，不是因为 udp“更好”，而是因为 tcp 根本就不能用！

也许有人抬杠说 tcp 也可以，那是因为没有遇到两层 tcp 超时带来的传输崩溃，算是走运了！

![](https://pic4.zhimg.com/v2-648ba654ed2c1b8ac61f54dbf4726f76_xs.jpg?source=1940ef5c)

plantegg

tcp 是可靠的，over tcp 后还是可靠的； 如果是 over udp 也是可靠的。所以本质上没带来任何好处

缺点：

一旦发生丢包，因为上层 tcp 不知道下层 tcp 丢包了（下层 tcp 丢包了 -- 真正丢包，会通过重传搞定），上层 tcp 能感知到的只是他的 rtt 暴增，进而影响上层 tcp 剧烈降速（这是错误的降速），tcp 流控依赖 rtt，用了错误的 rtt 那么就导致了错误的流控，明明带宽很多、网络也稳定，非要用远超出实际的 rtt 来再次慢启动

综上，tcp over tcp 没有任何优点，反而会导致网络不稳定

![](https://pica.zhimg.com/v2-abed1a8c04700ba7d72b45195223e0ff_xs.jpg?source=1940ef5c)

知乎用户

因为底层用 tcp 会雪崩，根本用不了。

假设底层是 tcp 协议。如果上层协议也是保证送达的协议，如 tcp/kcp/rudp 等协议。

那么一但发生丢包，底层 tcp 和上层协议都会重传，并且上层协议的所有重传包在下层 tcp 这里都要 [保证送达]。从而迅速导致大量[无需保证送达] 的上层协议包在底层 tcp 中堆积，导致雪崩，造成后续正常传输的堵塞。

这告诉我们，看上去做二层保证送达很棒，但是在实际使用中，画蛇添足矣。

![](https://picx.zhimg.com/v2-cf205e741b9509fe1a56c09724310029_xs.jpg?source=1940ef5c)

仕明

既然是 tunnel，重点就是在通道本身，也就是说本意就是 overlay 给另一个逻辑网络的，所以在另一个逻辑网络里会有该逻辑系统里自己的可靠性机制。那么 tunnel 本身就越简单越好。而且 UDP header 比 tcp 更短，可以更少的占用 mtu 的空间。

![](https://pic3.zhimg.com/v2-abed1a8c04700ba7d72b45195223e0ff_xs.jpg?source=1940ef5c)

知乎用户

来个特别通俗易懂的，中越边境上住着两兄弟，一个住中国，一个住越南, 一天住中国的要给住越南的一个东西，UDP：自己拿着送过去。TCP：发货 - 南宁 - 北京 - 河内 - 收货。

![](https://pic4.zhimg.com/v2-abed1a8c04700ba7d72b45195223e0ff_xs.jpg?source=1940ef5c)

胖子

TCP 也可以打洞，只是实现起来更困难。

打洞的洞，其实就是 socket 套接字。所以用 UDP 打洞成功后，得到的就是 UDP 连接，使用 UDP 协议进行数据传输。

![](https://pic1.zhimg.com/v2-abed1a8c04700ba7d72b45195223e0ff_xs.jpg?source=1940ef5c)

知乎用户

个人见解，其实没那么复杂，原因无非以下几个：

1、损耗问题。UDP 比 TCP 损耗小，不但是网速损耗，还有控制损耗（即额外一次三次握手，两次窗口控制等）。

2、网络设备支持度。虽然新的 nat 设备一般都支持 “tcp 同时打开” 方式建立连接，但是网络上很多旧的网络设备（个人测试时，同样两个终端，还有随机失败问题！）；UDP 由于是无连接协议，对打洞有天生优势，几乎所有 nat 设备都支持。

3、关于数据完整性问题，上层的 tcp 协议会自己处理的。

如说的不对，欢迎指正，谢谢。

![](https://pic1.zhimg.com/v2-0ce40dfe78ae5e7566d85be4953515a9_xs.jpg?source=1940ef5c)

Martin

p2p 本来就是不稳定的