企业网站建设需要什么,divi wordpress,wordpress gettheid,wordpress如何备份文章目录1 粘包问题1.1 什么是粘包问题1.2 如何解决粘包问题2 异常情况TCP 的十个特性#xff1a;确认应答机制
超时重传机制
连接管理机制
滑动窗口
流量控制与拥塞控制
延迟应答与捎带应答
1 粘包问题
1.1 什么是粘包问题 面向字节流引入了一个比较麻烦的粘包问题。 …
文章目录1 粘包问题1.1 什么是粘包问题1.2 如何解决粘包问题2 异常情况TCP 的十个特性确认应答机制
超时重传机制
连接管理机制
滑动窗口
流量控制与拥塞控制
延迟应答与捎带应答
1 粘包问题
1.1 什么是粘包问题 面向字节流引入了一个比较麻烦的粘包问题。 这里张三和小红进行了多次的交互张三的接收缓冲区其实是把刚才这里收到的多个数据都放到一起了。 如果应用程序调用 read 方法读取的时候该读到那里才算是一个完整的应用层数据报呢 由于 TCP 是字节流的一次读一个字节或是读多个字节都是可以的。 这就导致一次读到数据有可能是半个应用层数据报可能是一个应用层数据报也有可能是多个应用层数据报。 就好比过年吃饺子的时候碗里如果没放饺子汤。过了一会儿一碗饺子就会粘到一起了。 这个时候夹一筷子就有可能夹到半个饺子有可能夹到一个饺子也有可能夹到多个饺子。 这个现象就叫做 粘包问题。 应用程序调用 read 方法此处的 read 方法就是InputStream 里的 read 方法。
如果读的是 6 个字节此时就正好读到了 aaaaaa这是一个完整的应用层数据报。 如果读的是 10 个字节此时读到的是 aaaaaabbbb此时读到的是 “一个半” 的应用层数据报。 如果读的是 4 个字节此时读到的 aaaa 此时读到的就是 半个应用层数据报。 在 TCP 层次中没有 socket api 中告诉我们应该读几个字节和具体怎么读这完全是程序猿自己决定的。
1.2 如何解决粘包问题 我们期望的当然是读到一个完整的应用层数据报因为这样后续才好处理。
既然是应用层约定好应用层协议即可尤其是明确好应用层数据报个应用层数据报之间的边界就好了。
有两个方案
1、约定好分隔符
2、约定好每个包的长度
这两种方法二者取一即可。
采取分隔符的方法就是在一个完整的数据报末尾加上一个例如 \n 这样的符号来进行分割。 设计分割符的时候不能是要发送的数据报包含的吗这样会造成误读。 约定长度就是提前算好每个数据报的长度。
2 异常情况 异常情况也就是传输过程中出现了不可抗力。
这里分为四个情况
1、进程崩溃了 如果是进程没了对应的 PCB 就没了对应的文件描述符表就释放了相当于是 socket.close()。 此时内核会继续完成四次挥手此时其实仍然是一个正常断开的流程。 2、主机关机按照正常情况关机 主机关机要先杀进程然后才正式关机。杀死进程的过程中也是和上面一样触发四次挥手 3、主机掉电 假设是接收方掉电了发送方仍然在继续发数据发完数据要等待 ACK 不过肯定是等不到的。 这个时候引发超时重传不过肯定再怎么重传也是收不到 ACK 的重传几次后还没有应答此时尝试 重置 tcp 连接。 显然这个重置也会失败此时就会放弃连接了。单方面放弃了
假设是发送方掉电了接收方发现没数据了。 此时站在接收方的角度看待没发数据是发送方挂了还是发送方要组织下语言稍等会再发 接收方是不知道的此时会先等会儿。接收方会周期性的给发送方发送一个消息确认下对方是否还是工作正常的。 给发送方周期性的发送一条消息的这个操作叫做 保活机制发送的消息形象的称为心跳包因为心跳也是周期性的 如果心跳无了说明就寄了。
心跳包来确认通信双方是处于正常的工作状态中。 4、网线断开 这个和主机掉电是一样的只不过一个主机是接收方掉电了作为发送方的主机会尝试超时重传最后放弃连接。 另一个主机是发送方掉电了会尝试心跳包的方式来确认对方是否还是正常工作的。
