http请求解析
NettyHttpServerTransport 监听http请求。在其他版本中这个类在源码内，可直接找到。但在5.6中这个类被封装在netty插件中。因此从监听到http请求到请求转发到restController这部分我没看到。以下是从网络上找到的。http://blog.csdn.net/xgjianstart/article/details/70143365
首先，NettyHttpServerTransport 会负责进行监听Http请求。通过配置http.netty.http.blocking_server 你可以选择是Nio还是传统的阻塞式服务。默认是NIO。该类在配置pipeline的时候，最后添加了HttpRequestHandler，所以具体的接受到请求后的处理逻辑就由该类来完成了。
pipeline.addLast("handler", requestHandler);
HttpRequestHandler 实现了标准的 messageReceived(ChannelHandlerContext
ctx, MessageEvent e) 方法，在该方法中，HttpRequestHandler 会回调NettyHttpServerTransport.dispatchRequest方法，而该方法会调用HttpServerAdapter.dispatchRequest,接着又会调用HttpServer.internalDispatchRequest方法(额，好吧，我承认嵌套挺深有点深)：
public void internalDispatchRequest(final HttpRequest request, final HttpChannel channel) {
String rawPath = request.rawPath();
if (rawPath.startsWith("/_plugin/")) {
RestFilterChain filterChain = restController.filterChain(pluginSiteFilter);
filterChain.continueProcessing(request, channel);
return;
} else if (rawPath.equals("/favicon.ico")) {
handleFavicon(request, channel);
return;
}
restController.dispatchRequest(request, channel);
}
这个方法里我们看到了plugin等被有限处理。最后请求又被转发给 RestController。
从上面可以看出，请求被分发到RestController，然后调用dispatchRequest方法。在dispatchRequest方法中首先获取到根据请求的类型获取handler：
final RestHandler handler = getHandler(request);
这个handler是在创建具体的请求实例时写入restController中的。
public RestSearchAction(Settings settings, RestController controller) {
super(settings);
controller.registerHandler(GET, "/_search", this);
controller.registerHandler(POST, "/_search", this);
controller.registerHandler(GET, "/{index}/_search", this);
controller.registerHandler(POST, "/{index}/_search", this);
controller.registerHandler(GET, "/{index}/{type}/_search", this);
controller.registerHandler(POST, "/{index}/{type}/_search", this);
}
以search请求为例，此处的handler是RestSearchAction类型的。
最后调用的是handler的handlerequest方法。
wrappedHandler.handleRequest(request, channel, client);
RestSearchAction继承了 BaseRestHandler。因此这个地方调用的是BaseRestHandler的handleRequest，在handleRequest中准备请求：
final RestChannelConsumer action = prepareRequest(request, client);
这个prepareRequest方法是RestSearchAction的prepareRequest，根据RestRequest生成一个SearchRequest，交给NodeClient执行。
channel -> client.search(searchRequest, new RestStatusToXContentListener<>(channel))
NodeClient执行doExecute方法，将之前的SearchAction.INSTANCE（GenericAction）转化为对应的TransportSearchAction：
transportAction(action).execute(request, listener);
上述TransportSearchAction的execute方法最终执行的是自身的doExecute方法
this.action.doExecute(task, request, listener);
在doExecute中执行真正的查找流程。
Tcp请求解析
Tcp请求是由Netty4Transport来接收解析的。和上述一样，Netty4Transport被封装在netty插件中，因此没看到tcp接收的过程。
后面请求被转发至TCPtransport的messageReceived方法。而在该方法中调用handleRequest处理请求。
handleRequest(channel, profileName, streamIn, requestId, messageLengthBytes, version, remoteAddress, status);
在handleRequest中读取出action，跟不同的action生成具体的TransportRequest子类和一个RequestHandler，并执行该RequestHandler。
final String action = stream.readString();
.....
final TransportRequest request = reg.newRequest();
.....
threadPool.executor(reg.getExecutor()).execute(new RequestHandler(reg, request, transportChannel));
RequestHandler是一个可运行的AbstractRunnable，最后执行的dorun方法：
protected void doRun() throws Exception {
reg.processMessageReceived(request, transportChannel);
}
processMessageReceived中则是通过handler调用其messageReceived方法
handler.messageReceived(request, channel);
以search请求为例，这个handler不是上述生成的RequestHandler而是RequestHandlerRegistry中的handler，是一个TransportRequestHandler。而这个TransportRequestHandler是handledTransportAction中的一个变量，而handledTransportAction继承于transportAction,且是所有transport*action的父类，比如说transportBulkAction，transportSearchAction等等。
因此上述的handler.messageReceived(request, channel)调用的是handledTransportAction的子类transportSearchAction的messageReceived。至此总算找到了执行该请求的最终方法，即ransportSearchAction的messageReceived方法。但是还有个问题，reg（RequestHandlerRegistry ）是从哪来的？
这个RequestHandlerRegistry 则在TCPtransport的messageReceived方法中通过transportServiceAdapter获取的：
final RequestHandlerRegistry reg = transportServiceAdapter.getRequestHandler(action);
而这个RequestHandlerRegistry是transportSearchAction构建的时候调用父类HandledTransportAction的构造方法注册的：
protected HandledTransportAction(Settings settings, String actionName, boolean canTripCircuitBreaker, ThreadPool threadPool,TransportService transportService, ActionFilters actionFilters,IndexNameExpressionResolver indexNameExpressionResolver, Supplier request) {
super(settings, actionName, threadPool, actionFilters, indexNameExpressionResolver, transportService.getTaskManager());
transportService.registerRequestHandler(actionName, request, ThreadPool.Names.SAME, false, canTripCircuitBreaker,
new TransportHandler());
}
找到了RequestHandlerRegistry（TransportService中），获取reg的transportServiceAdapter（TCPtransport），二者是怎么联系起来的？
TransportService中有一个adapter，实现了TransportServiceAdapter方法。在dostart方法中设置了transport的adpter：
transport.transportServiceAdapter(adapter);
即设置了TCPtransport的adapter。那么TCPtransport调用的RequestHandlerRegistry reg = transportServiceAdapter.getRequestHandler(action)，就是调用transportService中的adapter，从而获取到注册的RequestHandlerRegistry。
此处我们还是没回答TransportService和TCPtransport二者的关系。
networkModule中的提供了注册transport的方法，但是一直没找到TcpTransport的注册方法，后来发现tcptransport是通过netty插件注册进去的。
在Node类构造TransportService时传入：
Transport transport = networkModule.getTransportSupplier().get();
final TransportService transportService = newTransportService(settings, transport, threadPool,networkModule.getTransportInterceptor(), localNodeFactory, settingsModule.getClusterSettings());
终于找到源头了。。真的好乱。其类依赖关系如下：
