Coyote for Http11: org.apache.coyote.http11

kaywang

概述
　　这个包支持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()
　　解析请求报头的第一行，形如：GEThttp://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实在有太多相似之处，为什么不抽象出一个父类呢？