何谓”透传“？ UART串口WIFI模块做”透传“的目的及其局限性

前言

本文从UART串口型WIFI模组的”透传“概念的本质入手，解释了”透传“的实际机理，点出了UART串口型模组的“透传”，其目的是为了避免低波特率的UART接口的低效通信，但同时“透传”恰恰又是其“通信可靠性不高、通信不灵活-做服务器无法支持多客户端、也不利于大块数据传输"等局限性的根源。

何谓“透传”

”透传“是一些UART串口型WIFI模组等部件上常见的概念。单片机等主机通过串口向模组发送的任何数据，都会被模组直接转化无线TCPIP协议包的数据内容，直接发送出去，而不必重新包装；而通过WIFI/TCPIP所接受到的数据内容，也直接通过串口发送给主机，而不必再进行协议的解析。看起来好像串口的数据完全直接对接TCPIP协议的payload数据域，所以称之为“透传”。在透传方式下，不再能使用任何查询或控制指令，一切与主机UART接口所交互的，都被当成是“有效载荷”的“数据”。

UART串口型WIFI为何一般都要支持所谓的“透传”

UART串口型WIFI模组需要支持所谓的透传的目的，是为了确保串口通信的效率，这对于本身波特率较低的UART串口型WIFI模组来说，显得尤其重要。我们对照一下非透传方式下的UART串口的串口通信，就比较容易理解了（其实，UART串口型WIFI模组的通信，不仅仅包括所谓的“透传”模式进行通信，也包括非透传模式进行通信）。

比如，假设我们希望通过串口发送一个数据，通过非透传模式，则可能需要如下方式通过串口发送字节串：

AT+CIPSEND=<link>, <len>, <data>\r\n

可以看到，我们的实际目的只是发送其中的<data>部分，但是每次发送前，都需要额外地向串口额外传送一大串字符串 ”AT+CIPSEND=<link>, <len>“。对于串口这类慢速的设备来说，这种字符串的写入，是比较浪费和低效的。

设想一下，假设我们只需要多次发送5个字节，对应的AT命令可能是

AT+CIPSEND=0,5,12345\r\n

可以看到，总共需要向串口传送22个字节（包含\r\n），但从串口通信的角度来看，效率就降低到了串口通信速度的 5/22！这对于本身波特率不高的UART串口通信来说，这一点对于有效吞吐速度的负面影响越发显得相当严重。如果我们每次都需要多次发送数据，固定字节串“AT+CIPSEND=0,5,”都需要被重复发送，这种低效率的浪费，将导致UART串口型WIFI模组的有效吞吐速率，在本身因为UART波特率受限而不快的基础上，再打一个很大的折扣。

既然每次发送的“AT+CIPSEND=0,5,"都是重复一样的，那为何不能采取一种策略，就是只要向串口输入一次，以后由模组自动”加上“或”理解“成带有这些重复的固定串，这样，以后只需要输入数据部分，之前的固定串部分不用重复输入，于是就可以大大节省慢速串口的浪费而提高效率了。

这就是所谓的透传的含义，即，只需要输入一次那些固定字节串（对应的是我们”进入串口透传“模式之前做执行的AT指令），以后再写入串口的数据，就自动都当成解析<data>了，从而确保了通信的高效。因此，“透传”是慢速的UART串口型WIFI模组，确保速度不会因为低效而进一步降低的一个手段。

UART串口型WIFI采用“透传”方式的弊端局限性 -- 导致通信的可靠性降低和功能受限

从上面的分析可以发现，一旦进入透传模式，以后所有串口交互的数据，都会自动转化为TCPIP协议包的”数据“域，也就意味着，所有的控制查询等”指令“将不再有效。因此，当我们在做”透传“时，如果想执行某些查询（比如查询当前的网络连接状态、或者通信的成功与否）或控制（比如选择另外某个客户端上进行发送），就必须先退出透传模式，进入非透传模式，来执行这些查询或控制。这也就是我们所知道的，透传模式和非透传模式的切换。

即，透传方式下的数据通信和非透传方式查询控制，不能同时并存，这导致了在收发数据的同时，无法通过查询或控制状态，来确保通信的可靠性，并影响通信包的长度，最终限制可靠通信的速度。比如，正在透传通信的过程中，如果出现网络中断或者阻塞，就无法通过相关的指令（只有在非透传模式下才可以执行的命令）查询得到，而必须先中止当前的传输来查询得到。这对于网络通信来说，会大大降低或限制其通信的可靠性、对长包的兼容性、以及有效的通信速度。这也是为何UART串口型WIFI模组很难做到较高速度下的可靠通信。

又有，当透传模式下的WIFI模组作为TCP服务器来使用时，就无法支持多个客户端通信了，因为TCP服务器一般需要区分所接收到的数据，来自哪个客户端，以及切换指定向哪个客户端发送数据，这些，都需要在数据通信的同时，进行必要的查询和控制，这是透传模式下，所无法实现的。

对于这个问题的处理，采用ESP8266芯片的串口型WIFI模组，在透传模式下，基本上都直接禁止了对TCP服务器的支持，以避免逻辑混乱；而采用TI CC3200方案的某些知名厂家的串口型WIFI模组，则采用不加区分的客户端方式，也就是说，做TCP服务器时，实际只支持一个客户端。

总结之，UART串口型WIFI模组进行串口透传具备以下局限性：

1、通信可靠性受限，因为无法及时获取当前的通信状态，并进行相应的处理

2、通信包的长度和速度受限，因为可靠性降低了，单个包的长度和速度就无法太快

3、通信的功能受限，例如透传模式下，无法支持多客户端

因此，UART串口型WIFI模组做透传，一般多用在非多客户端、对速度、包长、可靠性要求不高的IoT控制场合，可靠性通过上层应用层的握手和重发发包来进行补偿。

USB、SDIO、SPI等接口的高速WIFI模组为何一般不推荐用“透传”？

通过上面对UART串口型WIFI模组的透传分析，很容易就知道了这个问题的答案：

（1） USB/SDIO/SPI等接口本身的波特率速率，一般都远远高于UART，所以，不存在UART串口本身因为速率太慢成为瓶颈而需要确保效率的问题。这些接口的WIFI模组的短板，一般不在于这些主机接口的波特率，而往往在于现有WIFI 射频技术本身在环境下的实际吞吐局限，或者模组本身内部的处理效率，所以，在主机接口这里进行类似UART那样的效率提升优化的相对价值不大。

（2）不采用透传方式，还可以规避因为透传而导致的上述局限，从而可以自由地一边进行长数据通信的高速进行，一边又可以自由地进行查询控制确保通信的可靠性和灵活性。

（3）USB、SDIO、SPI接口的高速型WIFI模组可以自由的进行长包发送和同时支持多个链接以及多个客户端。

所以，在这些接口类型的模组上，询问是否支持”透传“，类比询问驾驶飞机是否支持手动挂档。在手动挡汽车上，可能需要挂档换挡以及踩离合等严格的顺序或配合流程，但对于飞机驾驶，则不存在这类话题。