t-io 学习笔记（一）

基础介绍理解篇

序：本文也是在t-io官网学习的基础上写的理解学习笔记；1.什么是t-io?

t-io是基于JVM的网络编程框架，和netty属同类，所以netty能做的t-io都能做，考虑到t-io是从项目抽象出来的框架，所以t-io提供了更多的和业务相关的API，大体上t-io具有如下特点和能力.

内置完备的监控和流控能力
内置半包粘包处理
一骑绝尘的资源管理能力
内置心跳检查和心跳发送能力
内置IP拉黑
一流性能和稳定性（第三方权威平台TFB提供性能测试和稳定性服务）
极其稳定的表现(很多用户还是停在t-io 1.x版本，就是因为太过稳定，不想变动)
内置慢攻击防御
唯一一个内置异步发送、阻塞发送、同步发送的网络框架
唯一内置集群分发消息的能力
独创的多端口资源共享能力（譬如一个端口是websocket协议，一个端口是私有的im协议，这两个端口的资源可以共享，这对协议适配极其有用）
独创协议适配转换能力（让基于websocket和基于socket的应用看起来像是同一个协议）
独一档的资源和业务绑定能力：绑定group、绑定userid、绑定token、绑定bsId，这些绑定几乎囊括了所有业务需求

1. tio-utils

tio-utils是他的作者在项目开发中积累的部分工具类
里面有少部分代码是在开源许可范围内摘自第三方开源项目代码的，还有部分代码是其它开源作者提供的，譬如hutool的作者路神就提供了许多类，在此也是表示感谢！笔者这么做，仅仅是因为广大用户强力要求tio减少第三方依赖！
当然笔者更愿意使第三方工具类，譬如hutool，毕竟和hutool的作者是基友
在tio-utils中目前鄙人用得最多的Cache
- 首先这个Cache是个门面——把市面上的各路Cache统一成了ICache，操作方法统一了，
- 其次它内置了一级cache，两级cache，并且性能极好、操作省心、稳定性也在大量项目中得到了考验
- 哦，这么说，其实就是想挑战J2cache，不过tio-utils也把J2cache门面化了^_^

2. tio-core

大家口中的t-io或tio指的就是tio-core，这个一定要记住，要不然会混掉
tio-core是依赖tio-utils的
tio-core是基于java aio的网络编程框架（很多人说t-io是基于netty，大家不要听信这样不负责任的言论）
如果你知道netty是啥，那理解tio-core就很容易了，因为tio-core是和netty类似的框架

3. tio-http-common

一个给tio-http-server和tio-http-client共用的工程，大家可以略过

4. tio-http-server

基于tio-core（为啥不说是基于tio-http-common？怎么说都可以）实现的http服务器
内置了极易使用的MVC框架
内置了流控、拉黑、forward、拦截器等常用能力
性能优秀，前面已经有地方描述了它在TFB上的性能表现，在TFB上tio-mvc的性能远超使用人群最多的springmvc，当然这不是说springmvc不优秀，而是说性能到这份上了，再说性能没啥意义！

5. tio-websocket-common

一个给tio-websocket-server和tio-websocket-client共用的工程，大家可以略过

6. tio-webpack-core

笔者在tio-http-server的基础之上依赖freemarker实现的类似nodejs webpack的功能，现在还没完全封装到位，就笔者一人在用
你现在正在浏览的网页就是基于tio-webpack-core的，不信你用右键点击查看源代码，全TM压缩或加密的^_^

API设计易懂，尽量避免引入自创概念——最大限度降低学习成本

t-io的最大优势

内置了丰富的易用的API，开发人员一个方法就能搞定很多业务事情
提供了生产级别的showcase示范工程
- 有经验的开发人员稍事修改即可用在生产环境
- 没经验的开发人员可以当作入门的示范代码
文档集中在官网，用户不需要到处学习无用的、错误的文档——进一步降低学习成本和试错成本

netty的最大优势

大量公有协议的实现
大量基于netty的高层框架

官网提供了大量的，netty 和t-io的比较，这里不再描述；

基础知识：

　　TCP/IP协议分层模型：

以下是TCP协议模型：分为7层，t-io官网上说是可以理解四层，这个知识点知道就行了，记了很多次，都没记住；

应用层是啥？

你想用java写一个网络程序，你写的这个程序就是应用层
所以QQ、微信、以及你正在使用的浏览器，都是应用层

传输层是啥

传输层要么走TCP协议，要么走UDP协议，没有第三种协议
TCP协议的通信双方，需要知道彼此都在家呆着，且由客户端主动发起连接
UDP协议，客户端知道服务器家住在哪，但并不知道服务器在不在家，扔条消息去服务器家，如果服务器不在家这条消息就被丢了
应用层把数据丢给传输层后，传输层把数据进行一下包装，包装纸上面写着“源端口、目的端口、序号、确认序号、检验和等TCP自身的数据”
传输层把数据给应用层时，会拆开对方的包装纸，应用层只看得到对方应用层发的数据

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

ByteBuffer是nio/aio编程所必须掌握的一个数据结构，也是掌握tio所必须要学会的基础知识。
设想你不懂Map，不懂List，不懂Set，那么你在编程领域将会一事无成，同样的道理，如果你不懂ByteBuffer，你无法在nio/aio编程领域立足

ByteBuffer的理解：

　　ByteBuffer的属性

　 byte[] buff //buff即内部用于缓存的数组。

　　　　position //当前读取的位置。

      mark //为某一读过的位置做标记，便于某些时候回退到该位置。

      capacity //初始化时候的容量。

      limit //当写数据到buffer中时，limit一般和capacity相等，当读数据时，limit代表buffer中有效数据的长度。

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

byte[] bytes: 用来存储数据
int capacity: 用来表示bytes的容量，那么可以想像capacity就等于bytes.size()，此值在初始化bytes后，是不可变的。
int limit: 用来表示bytes实际装了多少数据，可以容易想像得到limit <= capacity，此值是可灵活变动的
int position: 用来表示在哪个位置开始往bytes写数据或是读数据，此值是可灵活变动的

这里不再过多描述这个了，可以baidu去查查；

半包和粘包：

1.半包：

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

2.粘包

粘包与半包相反，就是把多个想说的话，一口气说完了，对方反应不过来，得把你的话拆开一条一条地理解
用http协议为例，展示粘包场景

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

为何坑人无数

初涉网络编程的同学，往往认为每次收到的数据刚好是一个完整的数据包
于是当网络不好，或是消息包过大时，半包的情况就发生了，而程序并没有考虑到半包的情况，结果就是解码失败，导致消息丢失
当通信的对方把多条业务数据包放在一个TCP包中发过来时，粘包就产生了，而程序没有考虑到一次TCP收包会收到多个业务包，从而解析到第一个业务包后把后面的业务包丢弃了
百度一下半包粘包，一定会搜到很多记录，这也证明这俩货确实坑人无数，所以看完本节内容，你还会继续犯半包粘包的错吗

半包、粘包所以在通讯的时候，可能会出现，有时候出错，或数据丢失的时候，要考虑到；