t-io网络编程基础知识介绍

157 阅读4分钟

一、 应用层和传输层****

以http协议为例,我们在访问一个网站时,浏览器会通过TCP协议发送如下字符串到服务器的应用层:

Host: 127.0.0.1

Connection: keep-alive

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate, br

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Cookie: PHPSESSID=970260278652571648

程序调试截图(tio的HttpRequest.toString())

image.png 这些字符串就是应用层数据,应用层数据是按照一定格式来组织的,这个格式就是应用层协议,譬如http协议。

传输层在往应用层传递数据时,并不保证每次传递的数据是一个完整的应用层数据包(以http协议为例,就是并不保证应用层收到的数据刚好可以组成一个http包),这就是我们经常提到的半包和粘包。传输层只负责传递byte[]数据,应用层需要自己对byte[]数据进行解码,以http协议为例,就是把byte[]解码成http协议格式的字符串。

具体请参考:https://www.tiocloud.com/doc/tio/80

二、 ByteBuffer

引言

ByteBuffer是nio/aio编程所必须掌握的一个数据结构,也是掌握tio所必须要学会的基础知识。

设想你不懂Map,不懂List,不懂Set,那么你在编程领域将会一事无成,同样的道理,如果你不懂ByteBuffer,你无法在nio/aio编程领域立足

初识ByteBuffer

我们可以把bytebuffer理解成如下几个属性组成的一个数据结构

byte[] bytes: 用来存储数据

int capacity: 用来表示bytes的容量,那么可以想像capacity就等于bytes.size(),此值在初始化bytes后,是不可变的。

int limit: 用来表示bytes实际装了多少数据,可以容易想像得到limit <= capacity,此值是可灵活变动的

int position: 用来表示在哪个位置开始往bytes写数据或是读数据,此值是可灵活变动的

一图感知一下ByteBuffer

image.png 具体请参考:https://www.tiocloud.com/doc/tio/83

创建ByteBuffer****

ByteBuffer.allocate(int cap)即可创建一个指定容器大小的ByteBuffer,见图

image.png

往ByteBuffer中写入数据

调用ByteBuffer.put(byte b)即可ByteBuffer中写入一个字节,见图

image.png

从ByteBuffer读取数据

对于刚刚写好的bytebuffer,我们要读取它的内容,需要先设置一下position和limit,否则读的位置就不对

image.png 接下来调用ByteBuffer.get()即可读取一个字节,在读取数据的同时,ByteBuffer的position也会跟关位移,见图

image.png

三、 半包和粘包:正确断句才能沟通

半包

顾名思义,就是收到了半个包,这个时候不足以组成一个应用层的包。就像你要对你喜欢的人说“我喜欢你”,但是因为喝水咽着了,第一次只说了“我”字,第二次说了个“喜”字,第三个次了个“欢你”,那么就发生了半包问题,对方只有等待你说完这4个字后才知道你是想说“我喜欢你”!

用http协议为例,展示半包场景

image.png 粘包

粘包与半包相反,就是把多个想说的话,一口气说完了,对方反应不过来,得把你的话拆开一条一条地理解

用http协议为例,展示粘包场景

image.png 说明:http协议是一来一回的,所以正常场景是不会有粘包的,但pipeline模式下是允许一方连续发多个请求的,所以会有粘包产生

为何坑人无数

初涉网络编程的同学,往往认为每次收到的数据刚好是一个完整的数据包

于是当网络不好,或是消息包过大时,半包的情况就发生了,而程序并没有考虑到半包的情况,结果就是解码失败,导致消息丢失

当通信的对方把多条业务数据包放在一个TCP包中发过来时,粘包就产生了,而程序没有考虑到一次TCP收包会收到多个业务包,从而解析到第一个业务包后把后面的业务包丢弃了

百度一下半包粘包,一定会搜到很多记录,这也证明这俩货确实坑人无数,所以看完本节内容,你还会继续犯半包粘包的错吗?

具体请参考:https://www.tiocloud.com/doc/tio/84