org.apache.coyote.http11.Http11BaseProtocol 详解

转载于：http://hi.baidu.com/chenhj_brenda/item/4f0aa637b13bb8c72f8ec2f0


这个包支持http1.1协议，内部分为三类：ARP、NIO、普通http，这里只对最基本的普通http（使用java的IO流，而非NIO流）作简单研究
根据上一篇提到的coyote的接口，这个包主要有以下几个类：
Http11Protocol，实现了ProtocolHandler接口 
Http11Processor，实现了ActionHook接口 
InternalInputBuffer，实现了InputBuffer接口 
InternalOutputBuffer，实现了OutputBuffer接口 
InputFilter和OutputFilter接口，具体的实现类在 org.apache.coyote.http11.filters 中 
下面是这几个类之间的关系，随便画了一幅图，凑合着看看^_^


大致过程如下：
JIOEndpoint起到一个连接池的作用，可以启动多个socket监听，一旦收到浏览器发来的请求后，把对应的socket对象通过process方法，传递给Http11ConnectionHandler，再交给Http11Processor 
Http11Processor内部有个InternalInputBuffer（图上未画出），InternalInputBuffer是真正对socket中包含的字节流进行处理的，它将字节转换为Request 
Request流经过滤器filters，最后到达实现了Adapter接口的容器，coyote的工作就到此为止，回头继续处理下一个socket 
下面是几个主要类的功能介绍
Http11Protocol
http1.1协议的ProtocolHandler实现
主要包含 
Http11ConnectionHandler(内部类) 
JIoEndpoint 
ServerSocketFactory（J2SE）
大致过程如下：
在init方法中，将ServerSocketFactory、Http11ConnectionHandler传递给JIoEndpoint进行初始化
然后，在start、pause等方法中，同样也会调用JIoEndpoint的start、pause
JIoEndpoint可以设置最大线程数、优先级、端口等属性，根据这些属性，JIoEndpoint生成对应数量的ServerSocketFactory，用于监听相应的端口，一旦收到http请求，JIoEndpoint则将对应的Socket实例传递给Http11ConnectionHandler.process方法进行处理；而Http11ConnectionHandler里头会有一个processor实例，这个实例真正处理socket并将其中的数据转换为Request对象
因此，ProtocolHandler的作用就是把所有这些和连接有关的组件包装起来，统一设置它们的属性，并负责控制它们的生命周期
Http11Processor
这个类的作用就是生成Request（当然本质上还是InternalInputBuffer完成的），交给实现了Adapter接口的容器
这个类有adapter、request、response、inputbuffer、outputbuffer等几个关键字段，其余就是和http协议有关的字段了，还有很多方法是关于http协议的，水平有限实在看不懂，估计要先详细学习一遍http协议才能读懂，这里就略过，直接看最关键的process(Socket socket) 方法
该方法依次做如下的工作：
把socket的inputstream和outputstream分别与inputbuffer和outputbuffer关联起来 
通过inputBuffer.parseRequestLine() 和 inputBuffer.parseHeaders() 方法，解析socket字节流中的头字段，写到request中 
通过prepareRequest方法组装filter，用于处理http消息体 
adapter.service(request, response) 把生成的request和response交给容器处理 
如果一切顺利，开始处理socket中的下一个请求（因为http1.1是支持持续连接的，所以一个socket中可能包含多个请求），循环回到第一步 
如果出错，则设置response的响应码，并终止循环 
prepareRequest方法，用于准备inputbuffer的filter，这里简单写一下。关于filter的机理，请看：
根据之前对http头字段的解析，分别检查protocol、method、expect、user-agent和MIMEheaders，此外还检查URI的格式（是否符合：protocol://host:port/ 的格式） 
准备加载filter 
如果有transfer-encoding这个头字段（貌似是编码格式，可以有多个，逗号分割），则分别设置不同编码的filter 
校验content-length头字段 
InternalInputBuffer
研究这个类可以从Http11Processor的process方法入手
这个类的主要功能是：从socket中获取字节流，将字节读入一个缓冲区buf，然后从缓冲区逐个解析http请求头以及内容
主要的字段：
request：Request对象，从缓冲区中解析出的信息会写入request中 
buf：缓冲区，从socket的inputstream读取的字节放入此缓冲区中 
headers : MimeHeaders，保存以键值对出现的报头，也就是除去请求报文第一行之后的所有头部 
具体的http请求报头的规范，可以参考W3C，或者 
http://www.yuanma.org/data/2008/0827/article_3143.htm
parseRequestLine()
解析请求报头的第一行，形如：GET http://class/download.microtool.de:80/somedata.exe，包括请求方法（GET or POST）、协议（http）、URI。解析后，放入request中
parseHeader（）
解析刚才parseRequestLine()之后的报头，由于RequestLine之后的报头都是以“：”分隔的键值对，因此每执行一次本方法，则在headers 中加入一个键值对，如果格式错误则返回false
endRequest()
结束一个request的处理，把多余的字节清空
nextRequest()
准备下一个request的处理，这个方法主要用来对所有的标记位和指针进行复位
fill()
从socket的inputstream中读出一定数量的字节，填充buf，在很多方法中都有用到。例如解析报头时，当发现buf已经读取完了，就调用fill重新填充buf，如果inputstream已经读完了，fill返回false
InternalOutputBuffer的一些疑问
根据inputbuffer的理解，可以大致猜到，这个类是用来从response中读取信息，然后写入socket的outputstream中，返回给客户端的
类里面的方法许多也和inputbuffer一样，但令人纳闷的是居然还有nextRequest()、endRequest()方法，而里面做的事情却是针对response的（OutputBuffer本来就只有response），看不出任何与request有关的东西。难道是作者拷代码过来的时候忘了改方法名称？
最后，觉得这个类和InternalInputBuffer实在有太多相似之处，为什么不抽象出一个父类呢？
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wangchengsi/archive/2008/09/29/2995536.aspx