0
点赞
收藏
分享

微信扫一扫

粘包问题(TCP面向字节流批量发送数据导致)

醉东枫 2023-08-22 阅读 59

TCP协议段格式:

 如图,

端口号:

保留(6位):

TCP特点:



可靠传输实现机制

确认应答(保证"可靠性"最核心的机制)

工作原理:

后发先至

如何解决呢?

对数据进行编号

 

 确认序号的数值,就是收到的最后一个字节的编号再加一.

注意:TCP是面向字节流的,不是按照“条”为单位来传输.

 只要知道这一串字节的开始编号,以及数据的长度每个字节的编号自然也就知道了
只需要在 tcp 报头中,把这-串字节第一个字节的编号,表示出来再结合报文长度,此时每个字节的编号就确定了

 ACK 为 0 表示这是一个普通的报文,此时只有 32 位序号是有效的.ACK为 1,表示这是一个应答报文,这个报文的 序号 和 确认序号 都是有效的

如此就有办法能区分出,当前这个报文是普通报文,还是一个确认应答报文

超时重传:

确认应答,是 TCP 保证可靠性的最核心机制
超时重传,也是 TCP 可靠性机制的有效补充

丢包有两种情况如图:

 发送方无法区分哪种情况,既然无法区分,那就全都重传

丢包本质上是一个“概率性”问题
假设丢包的概率是 10%,传输成功的概率是 90%

连续两次传输,都丢包的概率是多少?
10%*10% =>1%
随着你重传次数的增加,总体能够传输成功的概率,是更大的
是否会存在,连续重传多次,仍然丢包呢?当然存在!! 如果当前的丢包概率已经极高了,达到 100%(比如网线断了),不管咋传,都是丢的

连接管理:

1.建立连接(三次握手)

2.断开连接(四次握手)

A和 B 完成建立连接的过程,就需要
文样的打招呼的数据交互

 

 为什么要合并呢?封装和分用
合并之后,节省了封装和分用的过程降低了成本,提高了效率原则,能合并就合并

 六个标志位说明总结:

 

举报

相关推荐

0 条评论