Netty也研究了一段时间,实践是对知识掌握的试金石。有些东西只是看了面儿上的东西我觉得懂了,如不去深入,一旦要用它去做点什么东西却又觉得无从下手。学车的时候,学员问教练我怎么算是学会开车了,教练告诉他当你倒着开和向前开一样自如的时候就算学会了。怎么算掌握了一项技术呢?我的观点,多阅读源码,然后去实践,如此反复,读源码就像倒车。
为啥用Netty去实现呢?首先提供了Http Codec,支持Http1.0/Http1.1。我们不用再花很大的力气去除encode和decode request和response。和Netty提供的HttpServer相反,我们只需要HttpResponseDecoder和HttpRequestEncoder。我们知道Http协议都是Header-Body。Http1.0通过Content-Length的header来控制body的长度,Http1.1做了一些改进使用chunk的方式编码chunk,通过一个0长度的chunk来标识body的结束。request和response的协议都是Header-body方式的。Netty使用HttpMessageEncoder和HttpMessageDecoder来编码和解码。response和request不同的只是第一行的内容。
都知道Netty是异步的,这样也带了一个问题,假如我同时在一个channel发送多个request,server也会有多个response过来。如果是同步的,一个请求发送到服务端然后等待response,处理完毕以后接着发送下一个request,如此反复。但是异步就不一样,他同时发送多个request到server而等待服务端的response,那这样我们怎么知道那个request和哪个response是一一对应的呢?针对每一个channel维持一个已发送队列,当发送一个request的时候同时加入到这个队列中,在收到服务端的response从队头中取出一个request即是与之对应的。这样方式看起来是合理的,但还是有潜在的隐患。这种模式和现实浏览器由很大不同,一般是一个connection一次只能用来发送一个request,而不是多个request。假设多个请求的话,服务端是多线程模型,很可能response返回的顺序和request的请求顺序是不一样的。(我的设想没有证明,也许是多虑了,各位看官觉得不对,欢迎指正)
解决了上面说的问题,一个HttpClient没有多少代码就实现了,同时我用NettyHttpClient抓取新浪的股票数据,再用上次的Comet实现了一个股票实时推送的例子
![](http://dl.iteye.com/upload/attachment/0079/1786/8260933b-7954-315c-a2dd-7954f1f5fc00.jpg)
我把代码放在了google
code上,有兴趣的可以看看讨论一下http://code.google.com/p/netty-rpc/source/browse/的com.zhh.httpclient.NettyHttpClient.