【原创】关于TCP程序很容易让人误解的一个细节
玩socket貌似很简单，socket常用的函数不超过20个。但是一些细节如果没理解，那么开发的程序很可能会在你意想不到的情况下崩溃，而且很难在本地测试中出现。一个最简单的send调用如下：send(s,b,100,0);意思很简单，发送100个字节。按理说，接收只要这么写就行了：recv(s,b,100,0);本质上说，这段代码非常正确，而且会在本地环境、局域网环境甚至在优良的公网环境下正确运行。但是在网络差的时候，就有点悲剧了。因为：你很有可能无法一次性接收完毕这100个字节！
下面就要说重点了：关于对TCP可靠性理解的误区。
很多人包括我以前在内，对TCP可靠性的理解就是：一次性成功发送多少字节，就能一次性成功接收多少字节。这个理解是大错特错的。
TCP“可靠”的意思是，你一次（或多次）发送了N字节，对方就能收到N字节。但是不能保证对方调用一次recv就能接受完毕（即使缓冲区足够大）！
因此，要想完整地接收到100字节，最SB的办法就是循环调用100次recv(s,b,1,0)，也可以根据RECV的返回值（接收了多少字节），动态叠加。
此外需要注意的是send和recv的返回值类型是int，因此可能出现三种情况：正数、0、负数。它们的含义分别是：
返回正数：发送/接收了多少字节。
返回0：对方断开了。
返回负数：调用失败。
最后是干货：一个传输文件的程序源码（在糟糕网络环境下运行无误）。**** Hidden Message ***** 确实不少人对socket都存在着各种各样的误解，而且还有人自己在tcp的基础之上封装所谓的“更可靠的协议”的。
一次性成功发送多少字节，就能一次性成功接收多少字节
有关这句话：其实这是UDP的特性。你要么接不到包裹，要么接到的包裹是100%正确并且不会出现包裹粘连和拆分的情况。
此外，TCP不需要考虑包裹顺序的问题，它自己就能实现排序过程，毕竟它是在模拟文件流。这也是为什么很多人问我怎么解决“粘包”的问题。因为他们以为TCP会自动处理所谓的“分包”。然而文件流就是像读文件那样一点点读取和分析的过程。
作为对比，UDP不用考虑分包的问题，因为超过MTU的包会被丢弃。以及，UDP无法保证包裹能够按照发送的顺序来接收。你按顺序发出A, B, C, D四个包，接收方甚至能以D, C, B, A这样的顺序来接收。 0xAA55 发表于 2017-8-21 21:18
确实不少人对socket都存在着各种各样的误解，而且还有人自己在tcp的基础之上封装所谓的“更可靠的协议”的 ...
除了顺序这个坑，UDP最大的缺点在于每次只能发出去8192字节，实际情况还要再小一些。
当然，这个缺点带来了一个意外的“好处”：既然每次只能最多发出去8192字节，那么你接收的时候，只要准备好一个8KB的缓冲区，就不用担心“缓冲区小于包”的问题了。
至于顺序问题，包的头8字节定义一个UINT64作为序号，基本够发到天荒地老了。 有时候处理了拆分问题 却又忘记处理合并问题! 在糟糕网络环境下运行无误 有时候确实不会考虑这么多，还是要从一开始养成好习惯 学习了。 这个是不是要看看呢 学习了一下 虽然是个比较基础的问题, 但确实有些人不知道. 支持. 学习学习 学习到了 学习了，干货满满谢谢 还行,挺不错 支持一下，学习 刚好看了一个传输协议程序，来这学习下 学习下 來學習socket 看看 啥也不说了，帖子就是带劲！
页:
[1]
2