目录
面向字节流
引入
对于udp来说,它是面向数据报的
- 一旦要发送数据,因为没有发送缓冲区,且不需要维护连接,直接封装完报头就发出去了
- 依靠报头中的udp长度字段,可以拆分出报文然后交付给上层
- 一个报文里就是一次响应/请求的全部数据
但是对于tcp协议来说
- 它需要维护一个持续的连接,数据也就得是连续的
- 并且他有两个缓冲区,所以读写操作不需要一一匹配
- 比如,一次写了100字节,然后分10次读 / 分10次写完100字节,一次读出,这都是可以的
- 它可以根据需要,写入/读取任意长度的数据,tcp会负责将这些数据分割成合适大小的报文段进行传输
介绍
对于tcp来说,假设我们发送了4个请求给对方:
- 从应用层看来,是4个请求报文
- 但从传输层看来,这些只是若干个字节数据,它只保证如何安全地可靠地将这些数据发送给对方,并且发送的数量不定,由对方的接收能力决定
- 当对方的传输层接收到后,也同样只认识字节,它不管,它只管往上交付若干字节
所以,实际上只有用户层有报文的概念
在传输层看来:
- 就是有若干字节数据进缓冲区->出缓冲区->进缓冲区->出缓冲区
- 于是就有了字节流动的概念,这就叫面向字节流
比喻
其实面向字节流很像水流
- 传输层是一条水管,它不管水是哪来的,只管运输
- 另一方无论是用杯子接,用盆接都行,接多少都行,只要还有水
处理数据
但交付的这些字节并不能保证就是一份报文
- 所以需要在应用层定义一个缓冲区一直读,边读边对数据进行解析(要么不读,要么就读上来一份完整的数据)
- 解析成功后就拿走,剩下的继续重复上述步骤
我们在网络计算器里也正是这样做的
- 这些处理属于我们之前的encode/decode范畴,和序列化/反序列化有上下层关系
但是边读边解析效率比较低
- 我们已经介绍过tcp的传输控制机制,能知道 -- 如果自己的接收窗口更大,对方就会动态调整自己的滑动窗口大小,可以传过来更多的数据,可以提高传输效率
- 所以,我们最好是一有数据就全部读到用户层,再慢慢处理
粘包问题
引入
如果它没有制定协议,没有任何的处理,直接读
- 读上来的就是未知字节数的数据,可能是半个报文/一个半/多个
- 总之它处理不了,只能丢弃,但丢弃了就很大概率会影响之后的处理(因为数据不完整了)
- 而这样的情况,就叫做数据报粘包问题
就像:
- 蒸包子/馒头,蒸好后去拿,你本来只想拿一个,但拿起来了一个多/多个/半个
介绍
粘包只是针对用户层的概念
- 因为传输层面向字节流,对它来说没有报文的概念,自然也就不存在粘包问题
而解决粘包的方法就是制定协议
- 在之前的网络计算器里就有体现,我们封装了数据长度和特殊字符,使用encode/decode函数做封装和解包
其实不仅只有应用层要解决,下层也需要
- 因为他们处理数据也得先分出一份完整报文,才能进行封装报头/其他处理
- 而传递的数据还是以字节为单位
解决的本质
总结一下,解决粘包问题的本质是 -- 在应用层通过协议,明确报文之间的边界
- 定长报文
- 使用特殊字符
- 自描述字段+定长报文 (udp)
- 自描述字段+特殊字符 (网络计算器,http -- 报头里记录了有效载荷的长度,但报头长度不固定,所以添加特殊字符(空行)作为报头结束的标志)
分离报文后,才进入序列化/反序列化的逻辑
1778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
