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

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

         计算机网络这门课， 真是个枯燥无比的东西， 至少我是这么觉得的。 当年在大学时， 貌似是选修课， 全部靠背诵一些无聊又无耻的东西， 最后何老师给我打了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了。