4.6 消息大小

为了提高实现的质量，应该尽量使CoAP消息小到可以在一个链路层数据包中传输（见第1章）。CoAP文档本身只限制了消息大小的上限。大于IP数据包大小的CoAP消息会造成分片。一个CoAP消息应该尽量包含在一个IP数据包之内（即避免IP分片）并且在UDP包的payload之中。如果目的地址的MTU大小是未知的，那么应该假定IP包的MTU大小为1280字节。如果无法从头部获知消息大小，那么应该设置消息最大为1152字节，payload最大为1024字节。

实现注意：CoAP消息大小的选择适用于IPv6和目前的大部分IPv4地址。（然而，对于IPv4，很难保障绝对不发生IP分片。如果需要支持运行在受限网络上的IPv4，那么协议的实现应该使用更为保守的IPv4数据报大小，例如576字节。按照[RFC0791]中所述，IPv4网络的MTU可以小到68字节，减去用于安全开销的字节数，可用于UDP payload的就只剩下40字节。如果要解决这个问题，也许应该设置IPv4的DF标志位，并且执行一些路径MTU探测算法[RFC4821]。然而在使用CoAP的一般场景中，没有必要采用这些策略） 在许多受限网络中，一个重要的数据分片发生在适配层（例如6LoWPAN L2数据包最大只有127字节，还包括了各种开销在内）。这使得协议的实现应该尽可能减少数据包大小，当消息大小达到3位数的时候，应该使用块传输(block-wise transfer)。

在受限节点上，消息的大小很重要。许多实现都需要为接收消息创建缓冲区。如果一个实现由于资源过于受限而无法分配足够的缓冲区，那么对于不使用DTLS的消息，它可以使用以下策略：如果接收到一个数据报，但缓冲区太小不足以存储整个数据报，接收端通常能够判断出数据报的尾部是否被丢弃，并且能获得数据报的开头。一般来说，CoAP的头部和option部分很可能在缓冲区中。因此服务端可以正确理解这个请求，如果payload部分被截断了，可以返回一个4.13(请求数据过长，见第5.9.2.9节)的响应。当某个端发送一个幂等的请求，但接收到的响应大于它缓冲区大小，那么它可以为Block Option设置一个恰当的值，重复发送这个请求(见Bormann, C.和Z. Shelby著”Blockwise transfer in CoAP”)。