探索HTTP/2系列的第四篇文章，解读了HTTP/2流的状态，以及状态之间的转化。(2016.10.09最后更新)

1. 概述
    HTTP/2的流(Stream)是有状态的。当客户端或服务器端在使用某个流去发送或接收特定帧(Frame)或包含特定标签(Flag)的帧时，会引起流的状态的转化。HTTP 2协议定义的流状态，如下所示：
    总的说，HTTP/2为流的整个生命周期定义了7种状态：idle，reserved (local)，reserved (remote)，open，half closed (local)，half closed (remote)和closed。当一端发送或接收头部块(由一个HEADERS/PUSH_PROMISE帧和紧随它的零到多个CONTINUATION帧组成的集合)或RST_STREAM帧，或包含有END_STREAM标签的帧(HEADERS和DATA)之后，将改变流的状态。
    流的状态基于各端自己的视角。由于帧的传输会有网络延迟，在同一时刻，不同端认为的流的状态可能是不同的。比如，当发送端使用一个处于idle状态的流发送一个不包含END_STREAM标签的HEADERS帧之后会立即认为该流处于open状态，但此时接收端尚未得到该HEADERS帧，所以在那一时刻，接收端依然认为该流的状态是idle。

2. idle
    所有的流在创建之初都处于idle状态。处于idle状态的流，只允许被用于发送HEADERS帧，但可以被用于接收HEADERS和PRIORITY帧。在一端使用该状态的流发送或接收HEADERS帧之后，该端会认为此流的状态转变为open。接收PRIORITY帧不会改变流的状态。
    一个idle状态的流可被另一个流通过发送/接收PUSH_PROMISE帧保留着，使其在将来被用于服务器端推送。被保留的流的状态则从idle变为reserved (local/remote)。

3. open
    处于open状态的流可被用于发送任何类型的帧。使用该状态的流去发送/接收包含有END_STREAM标签的帧(HEADERS和DATA)之后，会使该流的状态变成half closed (local/remote)。使用open状态的流发送或接收RST_STREAM帧之后，则会使它的状态转变为closed。

4. half closed (local/remote)
    状态half closed (local)与half closed (remote)中的local与remote的区别，完全是基于各端自己的视角。对于同一个流的两端，如果一端认为这个流的状态是half closed (local)，那么另一端只能认为这个流的状态是half closed (remote)。
    处于half closed (local)状态的流只能被用于发送WINDOW_UPDATE，PRIORITY和RST_STREAM帧，但可以被用于接收任何类型的帧。相对应地，处于half closed (remote)状态的流只能被用于接收WINDOW_UPDATE，PRIORITY和RST_STREAM帧，但可以被用于发送任何类型的帧。

5. reserved (local/remote)
    与half closed (local/remote)状态相似，reserved (local/remote)状态中的local与remote也是基于流两端各自的视角。更具体的是，服务器端发送PUSH_PROMISE将一个idle状态的流保留着以用于未来的推送，并视这个被保留的流的状态为reserved (local)，而客户端则视这个流的状态为reserved (remote)。
    服务器端使用reserved (local)状态的流向客户端发送HEADERS帧。该HEADERS帧就是服务器端推送(Server Push)中被推送的响应的头部。当发送了HEADERS帧之后，服务器端将视该流的状态为half closed (remote)。
相应地，客户端通过reserved (remote)状态的流接收到服务器端推送的响应的头部，然后会视该流的状态为half closed (local)。
    扩展一下，服务器端推送中被保留的流的状态在变为half closed(local/remote)之后才可能被用于接收/发送被推送的响应的体部，也就是DATA帧。

6. closed
    当一端使用一个流发送或接收到RST_STREAM帧，或通过状态为half closed (local/remote)的流接收/发送包含有END_STREAM标签的帧之后，都会视这个流的状态为closed。
    closed状态预示着流的终结，处于该状态的流将只能发送或接收PRIORITY帧。但有一个特例。即，如果通过使用half closed (local/remote)状态的流去接收或发送包含有END_STREAM标签的帧(HEADERS或DATA)，以使该流的状态变为closed，那么在此之后的较短时间内，仍然可以接收WINDOW_UPDATE或RST_STREAM帧。

John Jiang 2016-10-08 21:17 发表评论

John Jiang 2016-09-24 20:29 发表评论

目前支持HTTP/2的服务器端与客户端实现已有不少，探索HTTP/2系列的第二篇就分别以Jetty和curl作为服务器端和客户端，描述了HTTP/2测试环境的搭建过程。本文还将使用这个测试环境去展示Jetty在实现HTTP/2时的一个局限和一个Bug。(2016.09.22最后更新)

1. HTTP/2的实现
    目前已经有众多的服务器端和客户端实现了对HTTP/2的支持。在服务器端，著名的Apache httpd从2.4.17版，Nginx从1.9.5版，开始支持HTTP/2。在客户端，主流的浏览器，如Chrome，FireFox和IE，的最新版均支持HTTP/2，但它们都只支持运行在TLS上的HTTP/2(即h2)。使用Java语言实现的，则有Jetty和Netty，它们都实现了服务器端和客户端。此处有一份HTTP/2实现的列表：https://github.com/http2/http2-spec/wiki/Implementations
    另外，还有一些工具支持对HTTP/2的分析与调试，如curl和WireShark。这里也有一份此类工具的列表：https://github.com/http2/http2-spec/wiki/Tools

2. 服务器端
    作为Java程序员，选用一款使用Java语言编写的开源HTTP/2服务器端实现似乎是很自然的结果。实际上，在日后的研究中，我们也需要查看服务器端的源代码。这对于深入地理解HTTP/2，并发现实现中可能的问题，具有现实意义。
    本文选择Jetty的最新版本9.3.11作为服务器端。Jetty是一个成熟的Servlet容器，这为开发Web应用程序提供了极大便利。而本文第1节中提到的Netty是一个传输层框架，它专注于网络程序。可以使用Netty去开发一个Servlet容器，但这显然不如直接使用Jetty方便。
    安装和配置Jetty是一件很容易的事情，具体过程如下所示。
    假设此时已经下载并解压好了Jetty 9.3.11的压缩文件，目录名为jetty-9.3.11。在其中创建一个test-base子目录，作为将要创建的Jetty Base的目录。
在创建Base时，加入支持http，https，http2(h2)，http2c(h2c)和deploy的模块。
    注意，在上述过程中，会根据当前环境变量中使用的Java版本(此处为1.8.0_60)去下载一个对应的TLS-ALPN实现jar文件(此处为alpn-boot-8.1.5.v20150921.jar)，该jar会用于对h2的支持。当启动Jetty时，该jar会被Java的Bootstrap class loader加载到类路径中。
    创建一个最简单的Web应用，使它在根目录下包含一个文本文件index，内容为"HTTP/2 Test"。再包含一个简单的Servlet，代码如下：
web.xml主要是定义了一个Servlet，具体内容如下：
该应用的部署路径为jetty-9.3.11/test-base/webapps/test.war。在该WAR文件所在的目录下，创建一个test.xml，其内容如下所示：
启动Jetty服务器，使用默认的HTTP和HTTPS端口，分别为8080和8443。
    根据上述日志可知，Jetty启用了Web应用test.war，还启动了两个ServerConnector，一个支持h2c，另一个支持h2。值得注意的是，这两个ServerConnector还分别支持h2c-17, h2c-16, h2c-15, h2c-14和h2-17, h2-16, h2-15, h2-14。这是因为，HTTP/2在正式发布之前，先后发布了18个草案，其编号为00-17。所以，这里的h2c-XX和h2-XX指的就是第XX号草案。

3. 客户端
    其实最方便的客户端就是浏览器了。只要使用的FireFox或Chrome版本不是太老，肯定都已经支持了HTTP/2，而且这一功能是默认打开的。也就是说，当使用FireFox去访问前面所部署的Web应用时，就是在使用HTTP/2，但你不会感觉到这种变化。使用FireFox提供的Developer Tools中的Network工具查看服务器端的响应，会发现HTTP版本为HTTP/2.0。但此处希望这个客户端能够提供更为丰富的与服务器端进行交互的功能，那么浏览器就并不合适了。
    Jetty也实现了支持HTTP/2的客户端，但这个客户端是一个API，需要编写程序去访问HTTP/2服务器端。而且，目前该API的设计抽象层次较低，需要应用程序员对HTTP/2协议，比如各种帧，有较深入的了解。这对于初涉HTTP/2的开发者来说，显然很不合适。本文选择使用C语言编写的一个工具，其实也是HTTP/2的客户端实现之一，curl。
    curl在支持HTTP/2时，实际上是使用了nghttp2的C库，所以需要先安装nghttp2。另外，为了让curl支持h2，就必须要有TLS-ALPN的支持。那么，一般地还需要安装OpenSSL 1.0.2+。
    网络上关于在Linux下安装支持HTTP/2的curl的资源有很多，过程并不难，但有点儿繁，要安装的依赖比较多，本文就不赘述了。如果是使用Windows，笔者比较推荐通过Cygwin来安装和使用curl。在Windows中安装Cygwin非常简单，在Cygwin中执行各种命令时，感觉上就如同在使用Linux，尽管它并不是一个虚拟机。通过Cygwin安装curl，它会自动地安装所需的各种依赖程序和库。
    在笔者的机器上，通过查看curl的版本会出现如下信息：
由上可知，笔者使用的curl版本是7.50.2，nghttp2版本是1.14.0，而OpenSSL版本是1.0.2h。

4. 第一次尝试
    在第一次尝试中，只需要简单地访问第2节中部署的Web应用中的静态文本文件index，以感受下h2c，完整命令如下：
在输出中包含有如下的内容：
">"是客户端发送的请求，"<"是服务器端发送的响应，而"*"是curl对当前过程的说明。结合本系列第一篇文章中所简述的HTTP 2协议，可以有以下的基本理解。
[1]客户端发起了一个HTTP/1.1的请求，其中携带有Upgrade头部，要求服务器端升级到HTTP/2(h2c)。
[2]服务器端同意升级，返回响应"101 Switching Protocols"，然后客户端收到了101响应，HTTP/2连接进行确认。
[3]服务器端响应最终结果。状态行中出现的HTTP版本为HTTP/2，状态代码为200，且后面没有跟着"OK"。最后输出了index文件的内容"HTTP/2 Test"。

5. 一个局限
    这次，在发起的请求中包含体部，命令如下：
在输出中包含有如下的内容：
    和第4节中的输出进行比较，会发现缺少了"101 Switching Protocols"那一段，而且最终响应状态行中出现的HTTP版本是HTTP/1.1。这就说明服务器端不同意升级，后面继续使用HTTP/1.1。刚刚部署的Jetty未做任何改变怎么会突然不支持HTTP/2了呢？或者这是curl的问题？其实，这是因为Jetty服务器端在实现h2c时不支持请求中包含体部。另外，Apache httpd也有同样的问题。如果是使用h2，则没有这个限制。这背后的原因超出了本文的范畴，不作表述。

6. 一个Bug
    在这次尝试中，测试一下两端对100-continue的支持。如果请求中使用了头部"Expect: 100-continue"，那么正常地该请求要有体部。但由于在第5节中介绍的问题，此时不能再使用h2c，而只能使用h2。另外，这次不访问静态文件，而是访问Servlet(此处为/test)。完整命令如下：
在输出的最后出现了如下信息：
这其实是Jetty的一个Bug，正在开发中的9.3.12已经修复了它。

7. 小结
    HTTP/2依然算是新潮的技术，对各家的实现，无论是服务器端，客户端，还是分析工具，都要持有一份怀疑态度。这些实现和工具都是程序，都有可能存在bug。而且协议对许多细节没有作出规定，各家都会发挥自己的想像力。比如，Apache httpd和Jetty在实现服务器端推送时，其方式就不尽相同。
    在开发自己的HTTP/2实现或应用的时候，需要同时使用已有的不同服务器端和客户端去部署多套测试环境进行对比分析。

John Jiang 2016-09-20 16:42 发表评论

HTTP/2的协议包含着两个RFC：Hypertext Transfer Protocol Version 2 (RFC7540)，即HTTP/2；HPACK: Header Compression for HTTP/2 (RFC7541)，即HPACK。RFC7540描述了HTTP/2的语义，RFC7541则描述了用于HTTP/2的头部压缩的格式。本文只涉及HTTP/2协议，本系列的后续文章将会涉及HPACK协议。(2016.10.13最后更新)

1. HTTP/2要解决的问题
     HTTP/1.0只允许在一个TCP连接中出现一个请求。后来的HTTP/1.1虽然引入了请求流水线，以允许在一个连接中发送多个请求，但这只是部分地解决了请求并发的问题。服务器端在返回响应时，还是必须要按照它接收到的请求的顺序进行返回。如果排在前面的响应要消耗较长的时间，那依然会对后面的响应的造成阻塞，亦即线头阻塞(Head-of-line blocking)。所以，客户端必须要使用多条连接去发起多个的请求以实现并发，并进而减小延迟。更大的并发会增大服务器的负载，也会占用更大的网络带宽。另外，头部通常会包含有大量的信息，如cookie，而这也会增加网络传输的开销。
     HTTP/2允许在同一个TCP连接中交错地出现多个请求与响应，亦即多工(Multiplex)。同时，它使用了一个高效的编码方法对头部进行压缩。HTTP/2还允许对请求进行优先级排序，以便让更为重要的请求得以更快的完成，这会进一步提高性能。HTTP/2还改变了服务器端只能被动地向客户端返回响应的定式，允许服务器端主动地向客户端推送数据，这就可以减少客户端发起请求的数量。
     总之，HTTP/2主要是解决性能问题。

2. 发起HTTP/2
     HTTP/2会使用与HTTP/1相同的URI scheme，即http和https。而且实现HTTP/2的服务器端也不会使用不同的端口去分别支持HTTP/1和HTTP/2。这样有利于平滑地从HTTP/1升级到HTTP/2。毕竟目前已部署的绝大部分网络服务都只支持HTTP/1，当未来它们升级到HTTP/2时，如果换用了不同URI scheme或端口，那么肯定会对客户端产生极大的影响。但是HTTP/2协议为运行在http和https上的HTTP/2分别定义了两个不同的标识符：h2c和h2。h2c中的"c"指的是cleartext，即明文。本文后面会使用h2c指代运行在http2上(直接使用TCP)的HTTP/2，而用h2指代运行在https上(使用TLS)的HTTP/2。
     那么，支持HTTP/2的客户端如何知道它所连接的服务器端是否也支持HTTP/2呢？
     对于h2c，支持HTTP/2的客户端可以在发起的请求中使用HTTP/1.1的Upgrade头部去尝试要求服务器升级到HTTP/2。该请求的格式如下：
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
HTTP2-Settings是一个经由BASE64编码过的字符串，其原始内容是客户端将要发送的SETTINGS帧的载荷，即一些配置参数。
     如果服务器端支持HTTP/2，它就响应"101 Switching Protocols"，表示可以进行升级。该响应的格式如下：
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
     如果服务器端不支持HTTP/2，则会忽略Upgrade请求头部，后续依然使用HTTP/1.1。
     对于h2，会使用到协议Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension (RFC7301)，即TLS-ALPN。该协议允许客户端和服务器端就使用何种版本的HTTP进行协商。如果TLS-ALPN在现实中运行良好的话，也许某天还会使用该方法去协商使用别的协议。
     当客户端与服务器端都同意使用HTTP/2时，双方都需要各自发出一个连接序言(Connection Preface)以进行最后的确认。
     客户端在接收到服务器端的"101 Switching Protocols"响应(针对h2c)或TLS连接的第一个应用数据字节(针对h2)之后会立即发出连接序言。该序言的开头是"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"(其十六进制形式为"0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a")⁽¹⁾，后面必须再跟一个SETTINGS帧，哪怕这个帧是空的。
     服务器端的连接序言则由一个SETTINGS帧构成，该帧必须是服务器端在HTTP/2连接中发送的第一个帧。这个SETTINGS帧可以为空，也可以包含一些希望客户端如何与自己进行通信的必要配置信息。

3. 帧(Frame)
     HTTP/2消息使用二进制格式(实际编码时使用十六进制书写)，相比于文本格式，这样可以提高消息处理的效率。HTTP/2消息的最小单元为帧，它由头部与载荷(Payload)组成。每个帧的长度必须是一个或多个8比特位字节(octet，下文将其简写为"字节")。
     帧头部依次包含有如下的5个字段：
     长度(Length)：该字段占用24个比特位，代表帧载荷的长度。该长度是一个24位的无符号整数。
     类型(Type)：该字段占用8个比特位，代表帧的类型。
     标志(Flags)：该字段占用8个比特位，代表帧所定义的一个或多个标志。并不是所有的帧都定义了标志。
     保留位(R)：该字段占用1个比特位，其语义尚未被定义。在读取帧时，该位需要被忽略；但在发送帧时，该位需要保持为0(0x0)。
     流标识符(Stream Identifier)：该字段占用31个比特位，代表该帧所在流的标识符。
     在头部之后，紧接着的就是载荷。载荷的结构与内容完全由帧的类型决定，它的长度也是不定的。

     HTTP/2定义了如下10种不同类型的帧。
     DATA：用于携带一组长度不定的字节。一个或多个DATA可作为请求或响应的载荷。
     HEADERS：用于开启一个流，并可携带一个头部块片断。头部块指由一个HEADERS/PUSH_PROMISE帧和紧随它的零到多个CONTINUATION帧组成的集合，因为只有它们才可能携带头部信息。这个集合可被分割成一个或一组字节，这样的字节被称为头部块片断。头部块中各个特定类型的帧必须紧紧相邻，不能出现其它类型的帧。
     PRIORITY：用于指定发送端建议的流优先级。
     RST_STREAM：用于立即终止流。当希望取消一个流或发生错误时，就可发送RST_STREAM帧。
     SETTINGS：用于携带可以影响两端之间通信方式的配置参数。SETTINGS帧定义了一个ACK标志，用于指示该帧所设置的参数是否已被接收端获知。当收到一个SETTINGS且其中的ACK标志为0时，接收端必须尽可能快的应用其中已被更新的参数。
     PUSH_PROMISE：用于向接收端通知发送端将要创建的流。当接收端接收到该帧时，新的流尚未被发送端创建，但发送端承诺会创建该流。该帧用于实现HTTP/2的重要特性"服务器端推送(Server Push)"。
     PING：用于测量发送端与接收端之间的最小往返时间。这与使用众所周知的ping命令的目的相似，是为了测试某个空闲的连接是否还可用。
     GOAWAY：用于发起对连接的关闭，或触发严重的错误条件。该帧允许一端，在完成对之前已创建的流的处理的同时，优雅地停止接收新的流。一端在创建新的流，另一端在发送GOAWAY，这两者之间天然存在着竞争关系。为了就对这种情况，发送端在发送GOAWAY时会让它携带上(该发送端所知晓的)接收端最后创建的流的标识符，当该GOAWAY被发送之后，发送端将会忽视由接收端创建的任何一个标识符比该标识符大的流。
     WINDOW_UPDATE：用于流量控制。该帧的载荷由一个单比特保留位和一个31比特位的无符号整数组成。该整数向该帧的接收端指示了其向当前流量控制窗口所能增加传输量的值。
     CONTINUATION：用于继续发送头部块片断。只要同一个流中前面的帧是HEADERS，PUSH_PROMISE或CONTINUATION，并且该帧没有设置END_HEADERS标志，那么可无限量地发送CONTINUATION帧。
     部分帧，DATA，HEADERS和PUSH_PROMISE，的载荷中可能包含填白(Padding)。填白在业务上没有实际的用处，它的出现是基于安全目的。比如，可以用它来扰乱实际数据的长度，以减轻特定的HTTP攻击。

     发送端发送的帧的最大长度要尊重接收端设定的SETTINGS_MAX_FRAME_SIZE的值。但该值的范围要介于2^14至2^24-1个字节之间。

4. 流(Stream)
     流是用于在客户端与服务器端之间进行帧传送的通道，同一个TCP连接中可以同时有多个流，如下图所示，
服务器端和客户端可以交错地向同一个连接中的不同流中传送帧。可以把一个流看作HTTP/1中的一个连接。客户端与服务器端在同一个流中的交互依然遵循发送请求-等待响应模式。两端都可以创建新的流，共享对方创建的流，也可以关闭对方创建的流。帧在流中的顺序是有意义的，接收端会以接收到的顺序去处理帧。
     每个流都有一个标识符，是一个31比特位的无符合整数。在同一个连接中，流标识符是唯一的。由客户端创建的流的标识符为奇数，由服务器创建的流的标识符为偶数。但标识符为0的流可看作连接，用于连接控制信息，创建新的流时不可使用该标识符。同一个连接中的任何一个流的标识符都不可重用，即便这个流已被关闭了。对于长时间没有中断的连接，可能会出现标识符不够用的情况，那时就必须强制创建一个新的连接。
     HTTP/2协议为流的生命周期定义了7种状态⁽²⁾：idle，reserved(local)，reserved(remote)，open，half closed(local)，half closed(remote)和closed。当一端接收或发送头部块或(帧DATA和HEADERS的)标志RST_STREAM后可使流的状态发生转变。
     使用流来实现多工就会引起对TCP连接使用的竞争，这会造成流的阻塞。基于帧WINDOW_UPDATE的流量控制方案可以确保相同连接中的流相互之间不会产生破坏性干扰。流量控制可以作用于两个层面，即单个流或整个连接。只有帧DATA需要遵守流量控制，所有其它的帧所有消耗的空间均不会占用流量控制窗口。HTTP/2协议只是定义了WINDOW_UPDATE帧的结构和语义，协议的实现可以选择任何适用自己的流量控制算法。
     流可以有优先级。客户端在创建一个新的流时，可在HEADERS中指定优先级权重。在后续任何时间，通过PRIORITY可以改变流的优先级权重。在并发能力有限的情况下，高权重流的帧会被优先传送。权重的值必须介于1至256之间，默认权重为16。流与流之间还可以有依赖关系，这种关系会组成一棵依赖关系树。一个流能够指定自己成为另一个流的子流。这一过程，可以是非排他的，也可以是排他的。非排他性依赖，是指一个流在将自己变成另一个流的子流的过程中，允许另一个流还有别的子流，即允许有自己的兄弟流存在。排他性依赖，指在前述过程中，不允许另一个流还有别的子流。如果另一个流已经有子流了，那么该流会把所有潜在的兄弟流先变成自己的子流，然后再使自己成为另一个流的唯一子流。其实，排他性依赖的作用就是为了能够打破已有的关系树，在既成的父子节点中插入新的节点。否则，只能为已有节点添加子节点，那么关系树将不可能进行重构。所有的流在被创建时，默认成为标识符为0x0的流的子流。在"服务器端推送"中生成的"推送"流将自动地成为生成该推送流的流的子流，其默认权重也为16。

5. 消息交换
5.1 请求/响应交换
     HTTP/2沿袭了HTTP/1的语义，即所有的请求与响应语义均得到了保留，尽管传递这些语义的语法已经改变了。
     一个HTTP/2消息由如下几个部分组成：
     [1]仅对于响应消息，可以包含一个携带有1xx响应头部的头部块。该头部块由一个HEADERS帧和紧随它的零到多个CONTINUATION帧组成。
     [2]一个头部块。该头部块由一个HEADERS帧和紧随它的零到多个CONTINUATION帧组成。
     [3]零到多个携带有体部(Body)消息的DATA帧。HTTP/1中使用的"分块(chunked)"体部将不适用于HTTP/2。因为一个体部可由多个DATA帧组成，所以HTTP/2的体部天然就是可分块的。
     [4]一个可能存在的包含着尾部消息的头部块。该头部块由一个HEADERS帧和紧随它的零到多个CONTINUATION帧组成。

     HTTP/2仍然沿用HTTP/1中的头部字段，但字段名称中的字母必须全部为小写。另外，还将HTTP/1消息开始行(请求中的请求行与响应中的状态行)中的消息，分解成了若干伪头部字段，此类字段均以冒号(:)开头。
     HTTP/1请求行格式为"method request-target HTTP-version"，对应的HTTP/2伪头部字段有:method=method和:path=request-target，但HTTP-version无对应字段，默认为HTTP/2。
     HTTP/1状态行格式为"HTTP-version status-code reason-phrase"，对应的HTTP/2伪头部字段有:status=status-code。但HTTP-version无对应字段，默认为HTTP/2；reason-phrase也无对应字段，因为可以通过状态代码查找到其对应的reason-phrase。HTTP/2协议是在尽量减少冗余消息。
     HTTP/2协议还为请求头部定义了另外两个伪字段：
     :scheme：URI中的scheme部分。它可以不仅仅是http或https，因为有时候可能会与非HTTP服务进行交互。
     :authority：URI中的授权部分。即，scheme://user:password@host:port/path?query#fragment中的"user:password@host:port"。
     HTTP/2协议8.1.3节中给出一些简单示例，展示了如何将HTTP/1消息对应到HTTP/2消息。
5.2 服务器端推送
     HTTP/2的服务器端推送是传统的请求/响应模式的一种特殊形式。服务器端在收到客户端的请求(主请求)之后，为了主动向客户端推送更多的内容，会自动地生成若干新的请求(推送请求)。服务器向客户端发送的响应中，不仅包含对主请求的响应(主响应)，还包含对推送请求的响应(推送响应)。
     客户端可以通过发送包含有SETTINGS_MAX_CONCURRENT_STREAMS参数的SETTINGS帧去禁用服务器端推送，也可以通过发送RST_STREAM帧去取消已经发起的服务器端推送，但不能发送包含有END_STREAM标志的帧。

(1)"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"中的"PRI"与"SM"合起来就是"RRISM(棱镜)"。呵呵，HTTPbis工作组这是想表达什么意思呢 ;-)
(2)本系列的后续文章解读了流的状态。

John Jiang 2016-09-19 11:36 发表评论

3. 覆盖Java核心API？
开发者们在使用主流IDE时会发现，如果工程有多个jar文件或源文件目录中包含相同的类，这些IDE会根据用户指定的优先级顺序来加载这些类。比如，在Eclipse中，右键点击某个Java工程-->属性-->Java Build Path-->Order and Export，在这里调整各个类库或源文件目录的位置，即可指定加载类的优先级。
当开发者在使用某个开源类库(jar文件)时，想对其中某个类进行修改，那么就可以将该类的源代码复制出来，并在Java工程中创建一个同名类，然后指定Eclipse优先加息自己创建的类。即，在编译时与运行时用自己创建的类去覆盖类库中的同名类。那么，是否可以如法炮制去覆盖Java核心API中的类呢？
考虑去覆盖类java.util.HashMap，只是简单在它的put()方法添加一条打印语。那么就需要将src.zip中的java/util/HashMap.java复制出来，并在当前Java工程中创建一个同名类java.util.HashMap，并修改put()方法，如下所示：
此时，在Eclipse环境中，SynchronizedHashMap使用的java.util.HashMap被认为是上述新创建的HashMap类。那么运行应用程序SyncMapTest后的期望输出应该如下所示：
但运行SyncMapTest后的实际输出却为如下：
看起来，新创建的java.util.HashMap并没有被使用上。这是为什么呢？能够"想像"到的原因还是类加载器。关于Java类加载器的讨论超出了本文的范围，而且关于该主题的文章已是汗牛充栋，但本文仍会简述其要点。
Java类加载器由下至上分为三个层次：引导类加载器(Bootstrap Class Loader)，扩展类加载器(Extension Class Loader)和应用程序类加载器(Application Class Loader)。其中引导类加载器用于加载rt.jar这样的核心类库。并且引导类加载器为扩展类加载器的父加载器，而扩展类加载器又为应用程序类加载器的父加载器。同时JVM在加载类时实行委托模式。即，当前类加载器在加载类时，会首先委托自己的父加载器去进行加载。如果父加载器已经加载了某个类，那么子加载器将不会再次加载。
由上可知，当应用程序试图加载java.util.Map时，它会首先逐级向上委托父加载器去加载该类，直到引导类加载器加载到rt.jar中的java.util.HashMap。由于该类已经被加载了，我们自己创建的java.util.HashMap就不会被重复加载。
使用java命令运行SyncMapTest程序时加上VM参数-verbose:class，会在窗口中打印出形式如下的语句：
从中可以看出，类java.util.HashMap确实是从rt.jar中加载到的。但理论上，可以通过自定义类加载器去打破委托模式，然而这就是另一个话题了。

John Jiang 2015-11-01 20:06 发表评论

John Jiang 2015-10-30 23:17 发表评论

John Jiang 2013-12-29 20:19 发表评论

John Jiang 2013-10-23 23:27 发表评论

相应地修改应用程序的代码，如代码清单9所示，

John Jiang 2013-10-07 16:55 发表评论

John Jiang 2013-09-21 19:11 发表评论

John Jiang 2013-08-02 11:50 发表评论

John Jiang 2013-07-14 11:15 发表评论

John Jiang 2012-02-13 23:22 发表评论

John Jiang 2012-01-04 00:13 发表评论

John Jiang 2011-12-24 23:26 发表评论

John Jiang 2011-12-14 00:01 发表评论

John Jiang 2011-11-20 20:57 发表评论

1. 创建正常窗体
先创建一个简单的界面，它使用BorderLayout，在其中安放5个JButton，如下代码所示，

执行上述程序的效果如下图所示，


2. 创建不规则窗体
基于上述程序创建不规则窗体，使整个窗体正好缺失掉RIGHT JButton所在的区域，如下代码所示，

执行上述程序后，会有如下图所示的效果，

John Jiang 2011-05-31 20:46 发表评论

JavaOne and Oracle Develop 2010(Beijing)--Day 2

John Jiang 2010-12-16 20:52 发表评论

John Jiang 2010-12-12 20:55 发表评论

setVisible(false);
setOpaque(false);

John Jiang 2009-11-29 20:33 发表评论

John Jiang 2009-10-22 12:20 发表评论

 1 public class FadingCardDemo extends JFrame {
 2 
 3     private static final long serialVersionUID = 8005909309849021746L;
 4 
 5     private String CARD_A = "CARD_A";
 6     private String CARD_B = "CARD_B";
 7 
 8     private JPanel cardPanel = null;
 9     private JXPanel panelA = null;
10     private JXPanel panelB = null;
11     private JButton buttonA = null;
12     private JButton buttonB = null;
13 
14     public FadingCardDemo() {
15         super("FadingButton Demo");
16         setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
17         initUI();
18     }
19 
20     private void initUI() {
21         cardPanel = new JPanel(new CardLayout());
22 
23         buttonA = new JButton("Button A");
24         buttonA.addActionListener(actionHandler);
25         panelA = new JXPanel(new BorderLayout());
26         panelA.add(buttonA, BorderLayout.CENTER);
27         cardPanel.add(panelA, CARD_A);
28 
29         buttonB = new JButton("Button B");
30         buttonB.addActionListener(actionHandler);
31         panelB = new JXPanel(new BorderLayout());
32         panelB.add(buttonB, BorderLayout.CENTER);
33         cardPanel.add(panelB, CARD_B);
34 
35         Container container = getContentPane();
36         container.setLayout(new BorderLayout());
37         container.add(cardPanel, BorderLayout.CENTER);
38     }
39 
40     private ActionListener actionHandler = new ActionListener() {
41 
42         private Animator animator = null;
43 
44         public void actionPerformed(ActionEvent e) {
45             if (animator == null) {
46                 animator = new Animator(2000);
47                 animator.setDeceleration(0.2F);
48                 animator.setAcceleration(0.4F);
49             } else if (animator.isRunning()) {
50                 animator.stop();
51             }
52 
53             JButton button = (JButton) e.getSource();
54             if (button == buttonA) {
55                 animator.addTarget(new PropertySetter(panelB, "alpha", 1.0F));
56                 panelB.setAlpha(0.1F);
57                 ((CardLayout) cardPanel.getLayout()).show(cardPanel, CARD_B);
58             } else if (button == buttonB) {
59                 animator.addTarget(new PropertySetter(panelA, "alpha", 1.0F));
60                 panelA.setAlpha(0.1F);
61                 ((CardLayout) cardPanel.getLayout()).show(cardPanel, CARD_A);
62             }
63             animator.start();
64         }
65     };
66 
67     public static void main(String[] args) {
68         SwingUtilities.invokeLater(new Runnable() {
69             public void run() {
70                 FadingCardDemo demo = new FadingCardDemo();
71                 demo.setSize(new Dimension(400, 300));
72                 demo.setVisible(true);
73             }
74         });
75     }
76 }

John Jiang 2009-09-28 09:46 发表评论

John Jiang 2009-08-05 21:10 发表评论