关于tcp协议可靠性的个人理解
1、首先,因为tcp协议是可靠的,所以不存在丢包问题,也不存在包顺序错乱问题(udp会存在这个问题,这个时候需要自己使用序号之类的机制保证了,这里只讨论tcp)。
2、tcp传输会有粘包的问题,一般的做法是先收取一个固定大小的包头信息,接着根据包头里面指定的包体大小来收取包体大小(这里“收取”既可以从socket上收取,也可以在已经收取的数据缓冲区里面拿取)。
3、丢包/粘包/拆包问题
如果TCP通信中发现缺少数据或者丢包,那么,最大的可能在于程序发送的过程或者接收的过程出现问题。
例如服务器给客户端发大量数据,Send的频率很高,那么就有可能在Send时发生错误(原因可能是又多种,可能是程序处理逻辑问题,多线程同步问题,缓冲区溢出问题等等),如果没有对Send失败做处理重发数据,那么客户端收到的数据就会比理论应该收到的少,就会造成丢数据,丢包的现象。
这种现象,其实本质上来说不是丢包,也不是丢数据,只是因为程序处理有错误,导致有些数据没有成功地被socket发送出去。
常用的解决方法如下:拆包、加包头、发送,组合包,如果客户端、服务端掉线,常采用心跳测试。
tcp是一个“流”的协议,一个完整的包可能会被TCP拆分成多个包进行发送,也可能把小的封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。
粘包、拆包问题说明
假设客户端分别发送数据包D1和D2给服务端,由于服务端一次性读取到的字节数是不确定的,所以可能存在以下4种情况。
(1)服务端分2次读取到了两个独立的包,分别是D1,D2,没有粘包和拆包;
(2)服务端一次性接收了两个包,D1和D2粘在一起了,被成为TCP粘包;
(3)服务端分2次读取到了两个数据包,第一次读取到了完整的D1和D2包的部分内容,第二次读取到了D2包的剩余内容,这被称为拆包;
(4)服务端分2次读取到了两个数据包,第一次读取到了部分D1,第二次读取D1剩余的部分和完整的D2包;
如果此时服务端TCP接收滑动窗非常小,而数据包D1和D2都很大,很有可能发送第五种可能,即服务端多次才能把D1和D2接收完全,期间多次发生拆包情况。(TCP接收滑动窗:是接收端的大小,随着流量大小而变化,如果我的解释还不明确,请读者自行百度,或者查阅《计算机网络》、《TCP/IP》中TCP的内容)
粘包问题的解决策略
由于底层的TCP无法理解上层的业务逻辑,所以在底层是无法确保数据包不被拆分和重组的,这个问题只能通过上层的应用协议栈设计来解决,根据业界的主流协议的解决方案,归纳如下:
(1)消息定长,例如每个报文的大小为固定长度200字节,如果不够,空位补空格;
(2)在包尾增加回车换行符进行分割,例如FTP协议;
(3)将消息分为消息头和消息体,消息头中包含表示消息总长度(或者消息体长度)的字段,通常设计思路是消息头的第一个字段用int来表示消息的总长度;(我之前linux C开发,就用的这种)。
(4)更复杂的应用层协议;
4、tcp只要发送成功,就能推出接收成功吗?即调用tcp的send函数,返回如果不是socket_error,就证明发送成功?这样我不用观察接收端,就能推理出接收成功了吗?
先来看看原理:
发送方:调用send函数的时候,做的操作实际上是把你给出的数据拷贝的系统的缓存中,然后等待系统发送,send函数的返回值就是实际拷贝进入系统缓存中的数据的大小,这个大小有可能小于你给定的数据大小,所以可能需要多次调用。
接收方:调用recv函数的时候,和send很类似,是把系统缓存中已经接收到的数据,拷贝到你给出的缓存中,recv的返回值就是实际从系统缓存中拷贝出来的数据的大小。在实际的网络传输中,会有一些数据不能及时到达,导致你recv的时候读出来的数据大小和send的时候的大小不一致,所以一般也需要多次调用。
注意事项:socket里面还可以使用MSG_WAITALL标志来等待所有数据到达。
当应用程序调用Send之后怎么判断对方是否成功接收?
TCP 的 ACK 表示对方的协议栈已经收到了你发的数据,不代表对方的应用程序收到了你发的消息。对方的应用程序可能死锁或者阻塞,不会去调用 recv(),那么你发的数据就堆积在对方协议栈的接收缓冲区里了。
于是乎,我们的答案是no.因为这个只是放到发送缓冲区成功了而已~~
(1)send成功,只是代表数据已经发到发送缓存中,并不代表发送到目的地,发送缓存的数据由网络层协议来保证发送到目的端,tcp是面向连接的,全双工模式。一般来说,都会成功。
(2)网络层协议把数据成功发送到目的地址,只是把数据放到接收端的接收缓存中,接收端没有recv的话,数据还是没有成功被接收。不停是send,接收缓存会用完。
(3)接收缓存满后,网络层就不会再发送数据过来。这样当你再次send的时候,就只是把数据放到发送缓存而已,发送缓存满后,则send函数会失败。
(4)如果缓冲区大,放到缓冲区,如果是0,那么在路上,但一般都不是0。
(5)放到缓冲区和路上不代表对方收到了
(6)如果网络一切正常,网线没有掉、到对方的路由没有问题,TCP会确保数据在某个时候到达对方,即使丢失了,它也会重传,这是TCP必须保证的。
(7)TCP的ACK是在协议栈实现的,应用层不知道。
(8)如果这个时候程序退出,对方不一定收到数据。
5、Linux多线程服务端编程:使用muduo C++网络库
![关于tcp协议可靠性的个人理解 关于tcp协议可靠性的个人理解](/default/index/img?u=aHR0cHM6Ly9waWFuc2hlbi5jb20vaW1hZ2VzLzU2MS83YjljYzg4YWIwNDM0YWQxZTRiYWMxYzJkNGQwNjcwOS5wbmc=)
(1)send成功,只是代表数据已经发到发送缓存中,并不代表发送到目的地,发送缓存的数据由网络层协议来保证发送到目的端,tcp是面向连接的,全双工模式。一般来说,都会成功。
(2)网络层协议把数据成功发送到目的地址,只是把数据放到接收端的接收缓存中,接收端没有recv的话,数据还是没有成功被接收。不停是send,接收缓存会用完。
(3)接收缓存满后,网络层就不会再发送数据过来。这样当你再次send的时候,就只是把数据放到发送缓存而已,发送缓存满后,则send函数会失败。
(4)如果缓冲区大,放到缓冲区,如果是0,那么在路上,但一般都不是0。
(5)放到缓冲区和路上不代表对方收到了
(6)如果网络一切正常,网线没有掉、到对方的路由没有问题,TCP会确保数据在某个时候到达对方,即使丢失了,它也会重传,这是TCP必须保证的。
(7)TCP的ACK是在协议栈实现的,应用层不知道。
(8)如果这个时候程序退出,对方不一定收到数据。
5、Linux多线程服务端编程:使用muduo C++网络库
6、如果客户端tcp连接服务器,突然把网线拔掉,然后再插回去,这时的socket连接的仍旧存在的。当前前提是时间足够短,1~2秒内网线插回去。时间长了就不行,socket会断开。