UDP的误区
来源:互联网 发布:博雅软件 南京 编辑:程序博客网 时间:2024/06/06 18:09
我发现很多人不太爱用UDP,对UDP存有偏见,爱憎分明的我不得不为它吐吐槽。
比起TCP来,UDP的优势在于速度快,而且不需要维护数据流,还能防止意想不到的欺骗。我遇到这么一个项目,在nginx上设计一个add-on模块做局域网转发。由于最终实现的服务部署在本机或局域网中,我建议通过UDP方式实现服务的调用。当时就有人跳起来跟我争论,反对使用 UDP。理由是UDP是无连接的,容易丢包,有时序问题,不可靠。
首先在本地或局域网中不存在时序问题。时序问题的产生是因为数据包可能走过不同路由。局域网内不存在这种情况,也就不用理会它。另外我可以负责任地说,虽然UDP 是无连接,它在局域网中传输丢包的概率是微乎其微的。局域网使用的交换机对数据有很强的恢复功能。如果在局域网中你的程序出现丢包的现象,你还是先检查一下自己程序写得是否合理。一般的丢包都是应用写的不合理造成的,比如接收不及时导致接收缓冲区满了,后面的包覆盖了前面的包,从而导致“丢包”。接收 UDP 数据包的函数尽量不要和处理UDP数据包的函数在一个线程,否则就可能导致收包不及时的问题发生。收包线程的全部工作就是不停地读,把接收完的数据放在队列中。
还有人提出峰值数据量过大会引起计算机忙而丢包。我做过24路1080p 30mbps码流的视频直播服务,画面清晰不丢帧,没有马赛克。运算设计得简单,如果是CBR的视频流,使用720mbps带宽,在千兆网环境下是没有任何问题的。到目前为止我做的转发服务还没有超过这个峰值数据量。有人使用tcpdump验证我的说法,向我反映即便是局域网也有“x packets dropped by kernel”。但是造成这种丢包的原因是由于libcap抓到包后,tcpdump上层没有及时地取出,导致libcap缓冲区溢出,从而覆盖了未处理包。虽然tcpdump工具显示被kernel丢弃,但是并不是说真正是被Linux内核抛弃的,而是被其所使用的动态库libcap抛弃。这时候如果是你写的服务,还是可以正常获取数据的。当然我们是有办法来改善tcpdump上层的处理效率减少丢包。例如抓包时最小化抓取过滤范围,即通过指定网卡、端口、包流向、包大小来减少处理包的数量;添加-n参数,禁止反向域名解析;调节/proc/sys/net/core/rmem_default和/proc/sys/net/core/rmem_max 参数改变sk_rcvbuf的大小等。
可能还有人会问:“很多教科书上都说 UDP 容易丢包呀。”这要看在什么应用场景下。不能生搬硬套。在经过路由器的情况有时是会出现丢包的。依我的实际经验,在过二三级路由以后,由于数据流量繁忙和TTL等原因可能会出现丢包的现象。
所以凡涉及到本机或局域网内通讯的案例,都可以考虑使用UDP。因为这个东西无连接,处理起来相当简单,性能极高。这种情况下使用TCP很浪费CPU资源。因为根本都不丢包,每次TCP的流控还要评估网络环境。
- UDP的误区
- 建模的误区
- 学习.Net的误区
- auto_ptr的使用误区
- Linux教学的误区
- 建模的误区
- 软件测试的误区
- 销售的误区
- 人格魅力管理的误区
- 走出基金净值的误区
- 喝汤的误区
- 建模的误区
- sf 的误区
- 程序鲁棒性的误区
- (转)建模的误区
- 泡妞的误区
- SMART原则的误区
- 建模的误区
- Android之解析Android Map地图返回的Json数据
- 自己对于private关键字的认识误区
- Merge Two Sorted Lists
- VisualSVN Server的配置和使用方法
- 企业公益不能“打小算盘”,“一条龙服务”才有未来
- UDP的误区
- select的使用解析
- 关于把解析SQL文件和把解析的结果导入Excel中
- Sicily1154(快排)
- 正则表达式基础
- java socket 之 Stream Socket(TCP/IP)
- java嵌套类(Nested Classes)总结
- 自拍达人
- qq的Tencent://Message/协议