capwap学习笔记——初识capwap（四）

2.5.7 CAPWAP传输机制

WTP和AC之间使用标准的UDP客户端/服务器模式来建立通讯。

CAPWAP协议支持UDP和UDP-Lite [RFC3828]。

¢ 在IPv4上，CAPWAP控制和数据通道使用UDP。此时CAPWAP报文中的UDP校验和必须设置为0。AC上的CAPWAP控制报文端口为UDP众所周知端口5246，数据报文端口为UDP众所周知端口5247 ，WTP可以随意选择CAPWAP控制和数据端口。

¢ 在IPv6上，CAPWAP控制通道一般使用UDP，而数据通道可以使用UDP或者UDP-Lite。UDP-Lite为默认的数据通道传输协议。当使用UDP-Lite协议的时候，校验和必须为8. UDP-Lite使用的端口与UDP一致。

2.5.8 分片、重组、MTU发现

CAPWAP协议在应用层上提供IP报文的分配和重组服务，由于使用隧道机制，报文分片中间的传输媒介来说是透明的。因此可以在任何网络架构（防火墙，NAT等）上使用CAPWAP协议。

CAPWAP实现的分片机制也有局限和不足，协议RFC4963中详细描述。

CAPWAP执行MTU发现来避免分片。

一旦WTP发现AC，且想要与这个AC建立一个CAPWAP会话，它必须执行一个Path MTU (PMTU)发现。IPv4的PMTU发现过程在RFC1191中详细描述。IPv6使用RFC4821。

2.5.9 报文格式

CAPWAP协议可靠机制要求消息必须成对，由请求和响应组成。所有的请求消息的消息类型值都为奇数，所有的响应消息类型值都为偶数。

如果WTP或者AC接收到了一个不认识的消息，消息类型是奇数，那么会将消息类型值加一，然后响应给发送者，并且在响应中带有“不认识的消息类型”元素。如果不认识的消息类型为偶数，那么这个消息将会被忽略。

2.5.9.1 UDP-Lite协议的简单介绍

UDP-Lite协议更加适应于网络的差错率比较大，但是应用对轻微差错不敏感的情况，例如实时视频的播放等。

那么它与传统的UDP协议有什么不同呢？

传统的UDP协议是对其载荷（Payload）进行完整的校验的，如果其中的一些位（哪怕只有一位）发生了变化，那么整个数据包都有可能被丢弃，在某些情况下，丢掉这个包的代价是非常大的，尤其当包比较大的时候。

在UDP-Lite协议中，一个数据包到底需不需要对其载荷进行校验，或者是校验多少位都是由用户控制的，并且UDP-Lite协议就是用UDP协议的Length字段来表示其Checksum Coverage的，所以当UDP-Lite协议的Checksum Coverage字段等于整个UDP数据包（包括UDP头和载荷）的长度时，UDP-Lite产生的包也将和传统的UDP包一模一样。事实上，Linux对UDP-Lite协议的支持也是通过在原来的UDP协议的基础上添加了一个setsockopt选项来实现控制发送和接受的checksum coverage的。

2.5.9.2 CAPWAP报文的简单介绍

CAPWAP控制协议包括两个永远不会被DTLS保护的消息：Discovery Request和Discovery Response。

报文格式如下：

其余的CAPWAP控制协议报文必须被DTLS协议加密，因此包括一个CAPWAP DTLS Header。

CAPWAP协议对数据报文的DTLS加密是可选的。