Netty进阶和实战

实现UDP单播和广播

UDP 这样的无链接协议中，并无持久化链接这样的概念，而且每一个消息（一个UDP 数据报）都是一个单独的传输单元。此外，UDP 也没有TCP 的纠错机制。

经过类比，TCP 链接就像打电话，其中一系列的有序消息将会在两个方向上流动。相反，UDP 则相似于往邮箱中投入一叠明信片。你没法知道它们将以何种顺序到达它们的目的地，或者它们是否全部的都可以到达它们的目的地。

UDP的这些方面可能会让你感受到严重的局限性，可是它们也解释了为什么它会比TCP快那么多：全部的握手以及消息管理机制的开销都已经被消除了。显然，UDP很适合那些可以处理或者容忍消息丢失的应用程序，但可能不适合那些处理金融交易的应用程序。

自己做为无链接的不可靠的传输协议（适合频繁发送较小的数据包），他不会对数据包进行合并发送（也就没有Nagle算法之说了），他直接是一端发送什么数据，直接就发出去了，既然他不会对数据合并，每个数据包都是完整的（数据+UDP头+IP头等等发一次数据封装一次）也就没有粘包一说了。

单播的传输模式，定义为发送消息给一个由惟一的地址所标识的单一的网络目的地。面向链接的协议和无链接协议都支持这种模式。

广播——传输到网络（或者子网）上的全部主机。

Netty 的UDP 相关类

interface AddressedEnvelope<M, A extends SocketAddress>extends ReferenceCounted

定义一个消息，其包装了另外一个消息并带有发送者和接收者地址。其中M 是消息类型；A 是

地址类型

class DefaultAddressedEnvelope<M, A extends SocketAddress>implements AddressedEnvelope<M,A>提供了interface AddressedEnvelope的默认实现

class DatagramPacket extends DefaultAddressedEnvelope<ByteBuf, InetSocketAddress> implements ByteBufHolder

扩展了DefaultAddressedEnvelope 以使用ByteBuf 做为消息数据容器。DatagramPacket是final类不能被继承，只能被使用。

经过content()来获取消息内容

经过sender();来获取发送者的消息

经过recipient();来获取接收者的消息。

interface DatagramChannel extends Channel

扩展了Netty 的Channel 抽象以支持UDP 的多播组管理

class NioDatagramChannnel extends AbstractNioMessageChannel implements DatagramChannel

定义了一个可以发送和接收Addressed-Envelope 消息的Channel 类型

Netty 的DatagramPacket 是一个简单的消息容器，DatagramChannel 实现用它来和远程节点通讯。相似于在咱们先前的类比中的明信片，它包含了接收者（和可选的发送者）的地址以及消息的有效负载自己。

UDP单播

参见模块udp下的包cn.enjoyedu.udp.unicast

UDP广播

参见模块udp下的包cn.enjoyedu.udp.broadcast

服务器推送技术-短轮询和Comet

服务器推送技术干吗用？就是让用户在使用网络应用的时候，不须要一遍又一遍的去手动刷新就能够及时得到更新的信息。你们平时在上各类视频网站时，对视频节目进行欢乐的吐槽和评论，会看到各类弹幕，固然，他们是用flash技术实现的，对于咱们没有用flash的应用，同样能够实现弹幕。又好比在股票网站，每每能够看到，各类股票信息的实时刷新，上面的这些都是基于服务器推送技术。

具体代码参见模块comet

Ajax短轮询

就是用一个定时器不停的去网站上请求数据。

Comet

“服务器推”是一种很早就存在的技术，之前在实现上主要是经过客户端的套接口，或是服务器端的远程调用。由于浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。，由于 AJAX 技术的普及，gmail等等在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在不少需求。称这种基于 HTTP长链接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。

基于 AJAX 的长轮询

DeferredResult:

Spring mvc的控制层接收用户的请求以后，若是要采用异步处理，那么就要返回DeferedResult<>泛型对象。在调用完控制层以后，当即回返回DeferedResult对象，此时驱动控制层的容器主线程，能够处理更多的请求。

能够将DeferedResult对象做为真实响应数据的代理，而真实的数据是该对象的成员变量result，它能够是String类型，或者ModelAndView类型等。

业务处理完毕以后，要执行setResult方法，将真实的响应数据赋值到DeferedResult对象中。此时，容器主线程会继续执行getResult方法，将真实数据响应到客户端。

SSE

严格地说，HTTP 协议没法作到服务器主动推送信息。可是，有一种变通方法，就是服务器向客户端声明，接下来要发送的是流信息（streaming）。

也就是说，发送的不是一次性的数据包，而是一个数据流，会接二连三地发送过来。这时，客户端不会关闭链接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。本质上，这种通讯就是以流信息的方式，完成一次用时很长的下载。

SSE 就是利用这种机制，使用流信息向浏览器推送信息。它基于 HTTP 协议，目前除了 IE/Edge，其余浏览器都支持。

SSE 与 WebSocket 做用类似，都是创建浏览器与服务器之间的通讯渠道，而后服务器向浏览器推送信息。

整体来讲，WebSocket 更强大和灵活。由于它是全双工通道，能够双向通讯；SSE 是单向通道，只能服务器向浏览器发送，由于流信息本质上就是下载。若是浏览器向服务器发送信息，就变成了另外一次 HTTP 请求。

SSE 也有本身的优势。

SSE 使用 HTTP 协议，现有的服务器软件都支持。WebSocket 是一个独立协议。

SSE 属于轻量级，使用简单；WebSocket 协议相对复杂。

SSE 默认支持断线重连，WebSocket 须要本身实现。

SSE 通常只用来传送文本，二进制数据须要编码后传送，WebSocket 默认支持传送二进制数据。

SSE 支持自定义发送的消息类型。

HTTP 头信息

服务器向浏览器发送的 SSE 数据，必须是 UTF-8 编码的文本，具备以下的 HTTP 头信息。

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

上面三行之中，第一行的Content-Type必须指定 MIME 类型为event-steam。

信息格式

每一次发送的信息，由若干个message组成，每一个message之间用\n\n分隔。每一个message内部由若干行组成，每一行都是以下格式。

[field]: value\n

上面的field能够取四个值。

data

event

id

retry

此外，还能够有冒号开头的行，表示注释。一般，服务器每隔一段时间就会向浏览器发送一个注释，保持链接不中断。例子 : this is a test stream\n\n

data 字段

数据内容用data字段表示。

data:  message\n\n

若是数据很长，能够分红多行，最后一行用\n\n结尾，前面行都用\n结尾。

data: begin message\n

data: continue message\n\n

下面是一个发送 JSON 数据的例子。

data: {\n

data: "foo": "bar",\n

data: "baz", 555\n

data: }\n\n

id 字段

数据标识符用id字段表示，至关于每一条数据的编号。

id: msg1\n

data: message\n\n

浏览器用lastEventId属性读取这个值。一旦链接断线，浏览器会发送一个 HTTP 头，里面包含一个特殊的Last-Event-ID头信息，将这个值发送回来，用来帮助服务器端重建链接。所以，这个头信息能够被视为一种同步机制。

event 字段

event字段表示自定义的事件类型，默认是message事件。浏览器能够用addEventListener()监听该事件。

event: foo\n

data: a foo event\n\n

data: an unnamed event\n\n

event: bar\n

data: a bar event\n\n

上面的代码创造了三条信息。第一条的名字是foo，触发浏览器的foo事件；第二条未取名，表示默认类型，触发浏览器的message事件；第三条是bar，触发浏览器的bar事件。

retry 字段

服务器能够用retry字段，指定浏览器从新发起链接的时间间隔。

retry: 10000\n

两种状况会致使浏览器从新发起链接：一种是时间间隔到期，二是因为网络错误等缘由，致使链接出错。

技术比较

京东用的什么？Ajax短轮询，这说明什么？这些技术并无什么优劣之分，只有合不合适业务的问题。京东的痛点是什么？要用有限的资源来为千万级甚至上亿的用户提供服务，若是是用长链接，对于接入的服务器，好比说Nginx，是很大的压力，光是为用户维持这个长链接都须要成百上千的Nginx的服务器，这是很划不来的。由于对于京东这类购物网站来讲，用户的浏览查询量是远远大于用户下单量的，京东须要注重的是服务更多的用户，并且相对于用户浏览页面的图片等等的流量而言，这点带宽浪费占比是很小的。因此咱们看京东的付款后的实现，是用的短轮询机制，并且时长放大到了5秒。

 

 

SSE和WebSocket相比的优点。最大的优点就是便利：不须要添加任何新组件，用任何你习惯的后端语言和框架就能继续使用。你不用为新建虚拟机、弄一个新的IP或新的端口号而劳神，就像在现有网站中新增一个页面那样简单。能够称为既存基础设施优点。

SSE的第二个优点是服务端的简洁。相对而言，WebSocket则很复杂，不借助辅助类库基本搞不定。WebSocket能作的，SSE也能作，反之亦然，但在完成某些任务方面，它们各有千秋。WebSocket是一种更为复杂的服务端实现技术，但它是真正的双向传输技术，既能从服务端向客户端推送数据，也能从客户端向服务端推送数据。