opensips/ch7/big-udp-msg/

[giscus[bot]]

opensips/ch7/big-udp-msg/

现象 有了开源的框架，我们可以很方便的运行一个VOIP系统。但是维护一个VOIP系统并非那么简单。特别是如果经常出现一些偶发的问题，需要用经验丰富的运维人员来从不同层面分析。
其中UDP分片，也可能是原因之一。
简介 以太网的最大MTU一般是1500字节，减去20字节的IP首部，8字节的UDP首部，UDP能承载的数据最大是1472字节。
如果一个SIP消息的报文超过1472就会分片。（实际上，如果网络的MTU比1500更小，那么达到分片的尺寸也会变小）
如下图，发送方通过以太网发送了4个报文，ABCD。其中D报文太了，而被分割成了三个报文。在传输过程中，D的一个分片丢失，接收方由于无法重新组装D报文，所以就将D报文的所有分片都丢弃。
这将会导致一下问题
发送方因接收不到响应，所以产生了重传 丢弃的分片导致其他的分片浪费了带宽 IP分片是对发送者来说是简单的，但是对于接收者来说，分片的组装将会占用更多的资源 RFC 3261中给出建议，某些情况下可以使用TCP来传输。
当MTU是未知的情况下，如果消息超过1300字节，则选择使用TCP传输 当MTU是已知情况下，SIP的消息的大小如果大于MTU-200, 则需要使用TCP传输。留下200字节的余量，是因为SIP消息的响应可能大于SIP消息的请求，为了避免响应消息超过MTU，所以要留下200字节的余量。 If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP. If this causes a change in the transport protocol from the

https://wdd.js.org/opensips/ch7/big-udp-msg/