上万socket的连接用的方案和技术？netty？分布式？越详细越好。

Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。 也就是说，Netty 是一个基于NIO的客户，服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。

Netty是一个基于NIO的服务器端（简化TCP/UDP的socket开发）。

java 写道Web Services是由企业发布的完成其特定商务需求的在线应用服务,其他公司或应用软件能够通过Internet来访问并使用这项在线服务。实际上，WebService的主要目标是跨平台的可互操作性。为了达到这一目标，WebService完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。

即提供第三方可使用服务（可以基于http/tcp等）。

servlet：是服务器端执行的小应用程序，是一个服务器组件，比如HttpServlet 用于实现对Http请求的处理，接受请求 处理、动态产生响应。

三者关注点不同：

netty 提供一套基于NIO的服务器的框架（简化TCP/UDP的socket开发），类似的还有mina。 比如实现一个web服务器。

web service 重点是web服务，建立一套规则，使得跨平台/跨应用可可访问。比如天气预报接口、google Map接口等。

netty实现多个handler顺序调用在netty中，一次数据交互，可以由多个handler去处理，例如handler1和handler2，那么，在前面那个handler的messageReceived的最后要加上ctxsendUpstream(e);理论请见：AChannelEventcanbehandledbyeitheraChannelUpstreamHandleroraChannelDownstreamHandlerandbeforwardedtotheclosesthandlerbycallingChannelHandlerContextsendUpstream(ChannelEvent)orChannelHandlerContextsendDownstream(ChannelEvent)代码：复制代码publicclassHandler1extendsSimpleChannelUpstreamHandler{@OverridepublicvoidmessageReceived(ChannelHandlerContextctx,MessageEvente){Systemoutprintln("1messagereceived");Stringa="11";Objecto=a;ctxgetChannel()write(a);ctxsendUpstream(e);}@OverridepublicvoidexceptionCaught(ChannelHandlerContextctx,ExceptionEvente)throwsException{egetChannel()close();}}复制代码复制代码publicclassHandler2extendsSimpleChannelUpstreamHandler{@OverridepublicvoidmessageReceived(ChannelHandlerContextctx,MessageEvente){Systemoutprintln("2messagereceived");egetChannel()close();}@OverridepublicvoidexceptionCaught(ChannelHandlerContextctx,ExceptionEvente)throwsException{egetChannel()close();}}复制代码复制代码publicclassTcpServer{publicstaticvoidmain(String[]args){Systemoutprintln("startingatcpserver");ServerBootstrapsb=newServerBootstrap(newNioServerSocketChannelFactory(ExecutorsnewCachedThreadPool(),ExecutorsnewCachedThreadPool()));sbsetPipelineFactory(newPKServerPipelineFactory());sbsetOption("childtcpNoDelay",true);sbsetOption("childkeepAlive",true);sbbind(newInetSocketAddress(9999));}}

在网速快速提升的时代，浏览器已经成为我们访问各种服务的入口，很难想象如果离开了浏览器，我们的网络世界应该如何运作。现在恨不得把操作系统都搬上浏览器。但是并不是所有的应用都需要浏览器来执行，比如服务器和服务器之间的通信，就需要使用到自建客户端来和服务器进行交互。

本文将会介绍使用netty客户端连接websocket的原理和具体实现。

在介绍netty客户端之前，我们先看一个简单的浏览器客户端连接websocket的例子：

这里使用了浏览器最通用的语言javascript，并使用了浏览器提供的websocket API进行操作，非常的简单。

那么用netty客户端实现websocket的连接是否和javascript使用一样呢？我们一起来 探索 。

先看看netty对websocket的支持类都有哪些，接着我们看下怎么具体去使用这些工具类。

和websocket server一样，client中最核心的类也是handshaker，这里叫做WebSocketClientHandshaker。这个类有什么作用呢？一起来看看。

这个类主要实现的就是client和server端之间的握手。

我们看一下它的最长参数的构造类：

参数中有websocket连接的URI，像是：”ws://flydeancom/mypath”。

有请求子协议的类型subprotocol，有自定义的HTTP headers：customHeaders，有最大的frame payload的长度：maxFramePayloadLength，有强制timeout关闭的时间，有使用HTTP协议进行升级的URI地址。

怎么创建handshaker呢？同样的，netty提供了一个WebSocketClientHandshakerFactory方法。

WebSocketClientHandshakerFactory提供了一个newHandshaker方法，可以方便的创建各种不同版本的handshaker:

可以看到，根据传入协议版本的不同，可以分为WebSocketClientHandshaker13、WebSocketClientHandshaker08、WebSocketClientHandshaker07、WebSocketClientHandshaker00这几种。

通常来说，对于webSocket协议，为了提升传输的性能和速度，降低网络带宽占用量，在使用过程中通常会带上额外的压缩扩展。为了处理这样的压缩扩展，netty同时提供了服务器端和客户端的支持。

对于服务器端来说对应的handler叫做WebSocketServerCompressionHandler，对于客户端来说对应的handler叫做WebSocketClientCompressionHandler。

通过将这两个handler加入对应pipline中，可以实现对websocket中压缩协议扩展的支持。

对于协议的扩展有两个级别分别是permessage-deflate和perframe-deflate，分别对应PerMessageDeflateClientExtensionHandshaker和DeflateFrameClientExtensionHandshaker。

至于具体怎么压缩的，这里就不详细进行讲解了， 感兴趣的小伙伴可以自行了解。

前面讲解了netty对websocket客户端的支持之后，本节将会讲解netty到底是如何使用这些工具进行消息处理的。

首先是按照正常的逻辑创建客户端的Bootstrap，并添加handler。这里的handler就是专门为websocket定制的client端handler。

除了上面提到的WebSocketClientCompressionHandler，就是自定义的handler了。

在自定义handler中，我们需要处理两件事情，一件事情就是在channel ready的时候创建handshaker。另外一件事情就是具体websocket消息的处理了。

首先使用WebSocketClientHandshakerFactory创建handler：

然后在channel active的时候使用handshaker进行握手连接：

然后在进行消息接收处理的时候还需要判断handshaker的状态是否完成，如果未完成则调用handshakerfinishHandshake方法进行手动完成：

当handshake完成之后，就可以进行正常的websocket消息读写操作了。

websocket的消息处理比较简单，将接收到的消息转换成为WebSocketFrame进行处理即可。

本文讲解了netty提供的websocket客户端的支持和具体的对接流程，大家可以再次基础上进行扩展，以实现自己的业务逻辑。

本文的例子可以参考：learn-netty4

最近项目中运用 WebSocket 的场景越来越多，自然而然。踩到的坑也就越来越多，例如最经常遇到的拆包，粘包问题。而当发现这个问题的时候，起初我认为与我之前通过 mina  实现自定义协议头，解决 socket 进行数据传输时遇到拆包问题的场景是一样的。而当我慢慢深入了解 WebSocket的时候才发现，实际上，WebSocket 的出现，就是为了解决拆包，粘包的问题的。因为这些事情，本身就是应该由运用层去解决，而不是在TCP/IP层解决。

通过网络搜索，我们可以知道 WebSocket 协议是根据 RFC6455 规范实现的，而最新版本是13（距离现今也接近10年了）。

以下是 WebScoket 定义的协议帧片段。

通过以上的帧定义片段。我也就明白了，为什么说 WebSocket 是为了解决拆包，粘包问题等一系列应用层问题而诞生的。从 RCF6455 规范定义第 53 章节中可以发现，每次发送或者接收的帧报文中，都会有定义协议的一些信息，例如头部大小，数据大小，以及帧类型，标识位等信息。

看完协议定义，那么开始查看  Netty  源码。

以下是  Netty  定义的相关帧类型以供开发者使用。

当服务端接收到协议由 HTTP 握手升级协议 WebSocket 时，我们需要通过  WebSocketServerHandshakerFactory 类新建 WebSocketHandshaker ，此时会判断 WebSocket 协议版本以及相关信息进行校验。

而  WebSocketServerHandshaker 中，分别定义了  WebSocketFrameDecoder ， WebSocketFrameEncoder 进行解码，编码调用。

那么从现实开始，大概也就清楚了， Netty  中  WebSocket  和  Socket  实现，实际上都是一样的，都是一个解码器（负责接收数据，处理成需要的类型，例如文本，二进制），一个编码器（负责根据协议版本，进行帧封装）的结构。

从  WebSocket13FrameDecoder  我们可以得知，实际上  WebSocket13FrameDecoder 是继承自  WebSocket08FrameDecoder （由于实现细节一致），而  WebSocket08FrameDecoder 是继承自  ByteToMessageDecoder  ，实际上都是通过二进制数据进行解码处理的。

查看  WebSocket08FrameDecoder  我们可以了解到具体的实现细节，就是每次解码的时候，都会读取首部信息，然后依次对数据进行处理。而拆包等操作，都是已经进行的相应处理和封装。

看完 Netty 的源码实现，那么就可以进行实际的编码解决问题了。

当服务端/客户端发现包文过大时，会进行拆包。而为每个包定义一系列的定义。

例如：当接收一个 Text 消息时， Netty 首先会实例化一个 TextWebSocketFrame 对象并传递给调用方，而通过  isFinalFragment 我们可以判断出，这个帧对象是否已经传输完毕，如果传输完毕，那么进行业务处理。如果没有传输完毕，那么继续等待余下信息，进行拼接处理。

以上为服务端接收拆包信息的处理方式，反之亦然，客户端接收消息也可以进行相应操作。而根据 WebSocket 13 版本实现的组件，也都根据 RFC6455  规范进行相应实现，可以实现无缝对接。

参考： Netty做webSocket客户端，服务端拆包发送客户端接收处理