再谈tcp流式传输和udp数据报传输------大家顺便来做做这两个题目!

版权声明:本文为博主原创文章,转载时请务必注明本文地址, 禁止用于任何商业用途, 否则会用法律维权。 https://blog.csdn.net/stpeace/article/details/73699603

         我的书算是白读了,  这个问题居然是我在工作后才明白的。 我不能怪老师没有讲清楚, 我只能认为自己没有好好学习。

         计算机网络这门课, 真是个枯燥无比的东西, 至少我是这么觉得的。 当年在大学时, 貌似是选修课, 全部靠背诵一些无聊又无耻的东西, 最后何老师给我打了60分, 算是一辈子的人情吧。 寝室四个人, 两个人没及格, 我60分, 另外一个60多一点点, 呵呵哒。  

         学什么计算机网络啊, 课程应该直接从网络编程搞起, 然后逐步编程实践、抓包并分析, 然后深层次地理解协议栈的设计原理和实现, 如果能了解到协议设计和实现的历史(比如为什么变化, 是为了解决什么问题), 那就更好了。我有点后悔了, 不该上大学读书的, 但是不读这书, 就没有后来的路。 现实就是这么悖论和矛盾。  有点扯。


         继续说tcp和udp.

         所有的书上都说, tcp是流式传输, 这是什么意思? 假设A给B通过TCP发了200字节, 然后又发了300字节, 此时B调用recv(设置预期接受1000个字节), 那么请问B实际接受到多少字节?  根据我们之前讲得tcp粘包特性,可知, B端调用一次recv, 接受到的是500字节。

         所谓流式传输, 说白了, 就是管道中的水, 第一次给你发了200斤的水, 第二次给你发了300斤的水, 然后你在对端取的时候, 这200斤和300斤的水, 已经粘在一起了, 无法直接分割, 没有界限了。

         

         所有的书上都说, udp是数据报传输, 我看了晕晕乎, 什么意思?  假设A给B通过udp发了200字节, 然后又发了300字节, 此时B调用recvfrom(设置预期接受1000个字节), 那么请问B实际接受到多少字节?   写了个程序测了一下, 发现B调用recvfrom接收到的是200自己, 另外的300字节必须再次调用recvfrom来接收。

         所谓的数据报传输, 说白了, 就有消息和消息之间有天然的分割, 对端接收的时候, 不会出现粘包。 发10次, 就需要10次来接收。


         我写tcp程序测了一下, 果然如此。 又写udp程序测试一下, 果然如此。  我的博客中, 有很多tcp/udp程序, 有兴趣的朋友, 可以玩玩这些程序, 实际验证一下, 加深理解。

         在实际工作中, 我发现udp没有你想像的那么不靠谱, 也没有书上乱讲的那样不靠谱, 而且, 很多实际存在的大系统, IM服务器, 部分场景用的就是udp.

         我发现, 我开始有点喜欢udp了。




阅读更多
换一批

没有更多推荐了,返回首页