HTTP 2.0 详细介绍
本文将带你深入了解HTTP 2.0的知识。作为互联网世界中最广泛使用的网络协议之一，HTTP协议的发展历程不断推动着互联网技术的进步。HTTP 2.0的诞生，无疑是近年来互联网技术圈最受关注的焦点之一。
HTTP 2.0的前世今生与http1.0和http1.1密切相关。虽然这两个版本所包含的协议规范庞大复杂，但它们为HTTP 2.0奠定了基础。HTTP 2.0是在http1.x的基础上演化而来，其诞生背后是用户体验和对网络速度不断追求的结果。
HTTP是建立在TCP协议之上的应用层协议。理解HTTP协议之前，对TCP协议有一定了解是非常必要的。HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性。例如，TCP建立连接时的三次握手会引入一定的延迟，为了避免这种延迟，应用层会选择不同的HTTP长链接方案。
随着互联网的不断发展，HTTP的应用场景也越来越广泛。从最初的简单内容获取，到现在的丰富内容展示、复杂交互，HTTP扮演着越来越重要的角色。随着内容量的增加和请求数量的增多，HTTP1.x的一些问题逐渐显现出来，如连接无法复用和head of line blocking等。
连接无法复用导致每次请求都需要建立新的连接，这不仅增加了延迟，也浪费了带宽。而head of line blocking则会导致带宽无法被充分利用，后续健康请求被阻塞。这些问题在网络状况不佳的情况下尤为突出。
为了解决这些问题，HTTP 2.0应运而生。HTTP 2.0通过引入一系列优化措施，如连接复用、流控制等，大大提高了网络请求的响应速度。在HTTP 2.0中，连接可以被复用，无需每次请求都建立新的连接，这大大减少了延迟。通过流控制机制，HTTP 2.0能够更有效地利用带宽，减少head of line blocking问题。
HTTP 2.0是互联网发展的一大进步。它通过优化网络连接和传输机制，提高了网络请求的响应速度，提升了用户体验。作为互联网开发者，深入了解HTTP 2.0的知识是非常必要的。这不仅有助于我们更好地优化网站和应用程序的性能，也有助于我们跟上互联网发展的步伐。随着网络技术的不断进步，HTTP协议也在不断演变。在HTTP 1.1时代，连接默认采用Keep-Alive模式，这使得一段时间内请求复用成为可能，极大地提升了PC端浏览器的用户体验。对于移动应用而言，由于请求的分散性和时间跨度的较大特点，连接复用的效果并不显著。移动应用通常需要在应用层寻求其他解决方案，如长连接或伪长连接方案。
针对移动端的需求，目前存在多种连接策略。其中，基于TCP的长连接是一种广泛采用的方法。越来越多的移动应用通过建立自己的长连接通道来实现信息的及时上报和推送。这种通道的实现基于TCP协议，虽然相较于HTTP的socket编程技术难度更高，需要自行制定协议，但其回报也是显著的。在请求量激增时，长连接模式能有效减轻服务器的压力。
除了基于TCP的长连接，HTTP long-polling是另一种常用的策略。在这种策略下，客户端发送一个polling请求到服务器后，服务器会等待新的业务数据产生后再返回。这样，连接会一直保持，一旦结束会立即发起新的polling请求。这种方式虽然能维持一个持续的连接，但在复杂移动网络环境下，如WiFi和4G网络切换、临时网络断开等场景，重建健康的连接通道是一大挑战。long-polling还需要解决数据可靠性的问题，如重发和ack机制。polling的response可能会被中间代理缓存，因此需要处理好业务数据的过期机制。
HTTP streaming是另一种策略，它与long-polling不同的一点是，服务器会持续通过初始的streaming请求返回的业务数据。这种方式的缺点在于数据通道是单向的，并且某些代理服务器会在收到完整响应后才推送结果给客户端，这可能导致客户端长时间等待。业务数据无法按照请求分割，客户端需要对收到的每块数据进行协议。尽管如此，streaming不会产生重复的header数据。
WebSocket作为一种较新的技术，提供了双向数据通道和message的概念。它基于TCP协议，使用相对简单，并提供了传统HTTP所缺少的长连接功能。由于WebSocket相对较新，并非所有浏览器都提供支持。尽管如此，各大浏览器厂商版本都已经提供了WebSocket的支持。
在解决Head of Line Blocking（HOLB）问题上，这是HTTP 2.0之前网络体验的主要瓶颈之一。为了解决这个问题，协议设计者引入了新的pipelining机制。这种机制能够显著提高网络性能并改善用户体验。通过允许请求被立即发送而无需等待前一个请求的响应，pipelining机制有效地减少了由于HOLB导致的延迟和性能问题。随着技术的不断进步，网络性能的优化将持续推动移动应用的发展。开发者需要根据具体的应用场景和网络环境选择合适的解决方案，以实现最佳的用户体验。HTTP Pipelining：一种提升网络性能的技术
HTTP Pipelining作为一种新型的请求处理机制，以其独特的优势在现代网络环境中崭露头角。它的核心思想在于，不必等待前一个请求的响应返回，即可发送后续请求，从而极大地减少了等待时间，降低了整体延迟。
流程图中清晰地展示了这种新机制的运作方式。与传统的HTTP请求不同，请求2、3、4、5等并不是等待请求1的响应返回后再发出，而是在几乎同一时间内，将请求发向服务器。这无疑大大提高了网络请求的并发性，优化了网络资源的利用。
HTTP Pipelining并非完美无缺。它存在诸多限制和缺陷，需要我们审慎对待。这项技术仅适用于HTTP 1.1，并且需要服务器端也支持此机制。只有幂等请求（如GET、HEAD）能够使用Pipelining，非幂等请求如POST则无法使用。这是因为非幂等请求可能存在前后依赖关系，无法并行处理。
尽管Pipelining能够在一定程度上解决延迟问题，但它并未完全解决head of line blocking的问题。也就是说，如果请求1的响应没有回来，那么请求2、3、4、5的响应也不会被送回来。这意味着在某些情况下，Pipelining可能无法充分发挥其优势。绝大部分的HTTP代理服务器并不支持Pipelining，这也限制了其在实际网络环境中的广泛应用。对于那些不支持Pipelining的老服务器，实施起来也会存在问题。甚至可能出现新的Front of queue blocking问题。
由于存在这些问题和挑战，各大浏览器厂商对Pipelining的支持并不统一。要么是根本不支持，要么是默认关闭此机制，启用条件十分苛刻。尽管如此，仍然有许多聪明的者不断寻找新的捷径来解决延迟问题。例如Spriting（图片合并）、Inlining（内容内嵌）、Concatenation（文件合并）和Domain Sharding（域名分片）等技术，都在一定程度上有助于提升网络性能。每种技术都有其优点和局限性，需要根据实际情况进行选择和应用。
Domain Sharding作为一种增加连接数、提高请求并发性的技术，被广泛应用于现代网页中。通过建立更多的子域名来创建更多的连接，从而突破浏览器对并发连接的限制。虽然这会增加系统资源的消耗，但随着硬件资源的不断升级，这种消耗已经变得微不足道。Domain Sharding还有助于减小请求的size，因为对于静态资源文件来说，分散在不同的域名服务器上可以消除cookie的传输。
HTTP Pipelining是一种具有潜力的技术，能够在一定程度上提高网络性能。由于其存在的局限性和挑战，需要我们在实际应用中审慎对待，并结合其他技术来共同优化网络性能。在网络优化领域中，我们面对的挑战在于如何有效地处理大量的请求，特别是在高并发场景下。对于domain sharding的应用，它确实可以减少请求数，但这并非越多越好。资源的消耗和TCP协议的slow start机制导致每个请求的初始阶段都存在时间损耗。找到可靠的连接数中间值并对其进行优化就显得尤为重要。这需要通过反复的测试来确定，而移动端浏览器场景则建议谨慎使用。
当我们谈论网络协议的革新时，不得不提及SPDY和HTTP/2.0。在HTTP 1.0和1.1的时代，尽管有许多优化手段，但它们都无法彻底解决协议本身的缺陷。直到Google在2012年提出了SPDY方案，人们开始从正面解决老版本HTTP协议的问题，这也加速了HTTP 2.0的诞生。实际上，HTTP 2.0是以SPDY为原型进行标准化讨论的。虽然Google已经决定不再支持SPDY的开发，但在HTTP 2.0出现之前，SPDY已经得到了广泛应用，并将继续存在一段时间作为过渡方案。许多应用程序和服务器都已经使用SPDY来提升用户体验。由于HTTP 2.0在某些老设备和系统上无法使用，因此预计未来几年SPDY和HTTP 2.0将共同服务于网络优化领域。
SPDY的目标是解决HTTP 1.x的两个主要问题：延迟和安全性。在讨论延迟时，我们需要注意到客户端的单连接单请求以及服务器的FIFO响应队列都是造成延迟的主要原因。而HTTP的明文特性使其安全性一直受到质疑。SPDY主要聚焦于HTTP层面来降低延迟。
为了实现这一目标，SPDY提供了多种功能。它位于HTTP之下、TCP和SSL之上，可以轻松地与旧版本的HTTP协议兼容。SPDY的功能可以分为基础功能和高级功能两部分。其中基础功能包括多路复用、请求优先级和header压缩。这些功能通过优化请求处理流程、提高带宽利用率和减小数据包大小来降低延迟。
具体来说，多路复用解决了HTTP 1.x中的HOLB（Head Of Line Blocking）问题，提高了带宽利用率并降低了延迟。请求优先级允许为每个请求设置优先级，确保关键请求优先得到响应。而header压缩则通过选择合适的压缩算法来减小数据包的大小和数量，进一步提高传输效率。
除了基础功能外，SPDY还提供了高级功能，如server推送。这是HTTP 1.x中无法实现的功能，服务器可以主动向客户端推送内容，从而进一步提高传输效率和用户体验。这些高级功能使得SPDY在网络优化领域具有更大的潜力。
SPDY的出现为网络优化领域带来了新的思路和方法。通过优化HTTP协议层面的设计，SPDY解决了老版本HTTP协议存在的问题，并提高了网络传输效率和用户体验。虽然HTTP 2.0已经逐渐普及，但预计未来几年内SPDY和HTTP 2.0将共同存在并服务于网络优化领域。开启Server Push的新时代
当服务器通过X-Associated-Content header（那些以X-开头的header，属于非标准的自定义header）启动Server Push功能时，它实际上是在告知客户端：新的内容即将推送。这在用户首次访问网站首页时，能极大地提升用户体验，使服务器能主动推送资源。这是一种服务器暗示（Server Hint）的进阶操作。
不同于Server Push的主动推送，Server Hint只是告诉客户端有新内容产生，但不主动推送。内容的下载仍需客户端发起请求。这一功能主要通过X-Subresources header来通知。在实际应用中，它常用于客户端先查询服务器状态，再下载资源的场景，从而节约一次查询请求。
2.2 SPDY的辉煌成就
让我们引用Google官方数据来说明：页面加载时间相较于http1.x减少了64%。在SPDY诞生后的短短一年多里，各大浏览器厂商纷纷支持这一协议。许多大型应用与服务器框架已将其部署到线上产品中。Google的官网分享了一份针对25个高流量网站首页的测试结果，在家用网络环境下，丢包率为1%。测试数据显示，不开启SSL时，页面加载时间提升27%-60%，开启SSL后，提升幅度为39%-55%。测试结果中有两个关键点值得注意：
连接数的选择：是关于连接是基于域名建立，还是所有子域名共享一个连接的问题。Google的测试结果显示单一连接性能可能高于多域名连接方式。这是因为网页的所有资源请求并非同时发出，后续子域名的请求如果能复用之前的TCP连接，性能会更优。实际应用中，单连接的共享模式表现更佳。
带宽的影响：测试在两种带宽环境下进行，一种是高速，一种是低速。在高速环境下，延迟的降低更为显著，在单连接模式下，提升幅度可达60%。这是因为带宽越大，复用连接的请求完成得越快，三次握手和慢启动导致的延迟损失就更加明显。除此之外，丢包率和RTT也是关键参数。SPDY对header的压缩率高达80%以上，整体包大小能减少约40%。在丢包率较高的环境下，SPDY更能提升用户体验。
3. 救星HTTP2.0
从2012年诞生到2016年停止维护，尽管时间相对较短，但SPDY已经完成了它的使命。它的出现和表现实际上说明了两个问题：一是在现有的互联网基础设施和广泛使用的HTTP协议的基础上，可以通过修改协议层来优化http1.x；二是对http1.x的修改确实效果显著并且得到了业界的积极反馈。正是这两点促使IETF开始正式考虑制定HTTP2.0的计划。HTTP2.0将基于SPD3为蓝图进行起草，部分参与SPD3设计的人员也参与了HTTP2.0的设计工作。对于HTTP2.0来说需要考虑的问题众多且角度广泛。其核心设计原则之一是保持客户端向服务器发送request的基本模型不变；同时老的scheme也不会改变这意味着使用 1.x平稳过渡到HTTP 2.0，得益于代理服务器的灵活支持。对于那些暂时还不支持HTTP 2.0的代理服务器，它们能够智能地将请求降级到更早期的HTTP版本，确保通信的顺畅无阻。这种过渡背后隐藏着一种微妙的协商过程。
在客户端和服务器之间，为了确保使用HTTP 1.x还是HTTP 2.0，首先需要确认对方是否支持新版本协议。这一过程不可避免地涉及到一问一答的协商，增加了往返时间（RTT）。显然，这对于追求性能优化的HTTP来说是一个不小的挑战。当Google设计SPD协议时，也遇到了同样的问题。他们的创新解决方案是强制SPD协议通过HTTPS进行协商，这一环节发生在SSL层，即在HTTP协议通信之前。为此，Google扩展了TLS协议，引入了NPN（Next Protocol Negotiation）。尽管HTTP 2.0也采用了类似的方法，但最终并没有强制要求所有HTTP 2.0连接都必须通过SSL层进行协商。大部分浏览器厂商（除IE外）只实现了基于HTTPS的HTTP 2.0协议。他们采用的是另一个TLS拓展，叫做ALPN（Application Layer Protocol Negotiation）。无论是NPN还是ALPN，其核心目的都是为了确保协议的顺利协商。
浏览器倾向于使用基于SSL的HTTP 2.0的原因在于，SSL封装的请求更安全、成功率更高。在网络传输过程中，通过SSL封装的request不易被监听和修改，这大大降低了中间网络设备干涉修改request的风险。如果HTTP 2.0的request被意外修改，请求的成功率自然会下降。虽然HTTP 2.0协议并没有强制使用SSL，但出于安全和性能的考虑，许多浏览器厂商选择只支持基于HTTPS的HTTP 2.0协议。这也使得开发者面临一个权衡问题：坚持使用非SSL的HTTP 2.0可能会面临额外的RTT延迟和请求被破坏的风险，或是采用基于HTTPS的协议以享受更高的安全性和相对稳定的性能。因此开发者在开发应用时必须考虑这一点。除此之外HTTP2.0协议的二进制格式也是一大亮点它摒弃了http协议的文本格式采用了更加高效和健壮的二进制格式这一改动让协议的变得更加方便并大大提高了传输效率此外还解决了多路复用的问题允许客户端同时进行多个请求极大地提高了传输效率也便于调试对于开发者来说更易于实现高效的网页服务让用户体验得到提升总的来说HTTP 2.0协议的改进不仅提高了传输效率也增强了网络的安全性使得网络应用更加高效便捷地服务于用户。对于HTTP/2协议的深入理解与运用：stream id、优先级与依赖、header压缩等核心特性分析
在现代网络通信中，HTTP/2协议已成为众多应用的标配，它通过一系列的创新特性，提升了网络传输的效率与用户体验。下面，我们将对stream id、优先级与依赖、header压缩等HTTP/2的核心特性进行深入。
一、stream id的与应用
在HTTP/2中，stream id是用于连接共享机制的关键标识。每一个request对应一个stream，并分配一个独特的id。一个连接上可以有多个stream，它们的frame可以随机混杂在一起。接收方可根据stream id将frame正确归属到各自的request中。这种设计确保了即使在复杂的网络环境下，数据也能准确无误地传输。
二、优先级与依赖机制的重要性
在共享连接模式下，为了有效解决关键请求被阻塞的问题，HTTP/2引入了优先级和依赖机制。每个stream都可以设置优先级（Priority）和依赖（Dependency）。优先级高的stream会被服务器优先处理并返回给客户端。stream还可以依赖其他的sub streams，这种依赖关系可以动态调整。
想象一下，当用户在使用app浏览商品时，快速滑动到商品列表底部，如果前面的请求拥有更高的优先级，那么用户当前浏览的图片就能够更快地下载完成，这就是优先级设置的妙处。同样，依赖机制也在某些场景下发挥了重要作用。
三、header压缩技术的应用与优势
在HTTP/TCP通信中，header信息由于cookie和user agent的存在很容易发生膨胀，且每次都需要重复发送。而HTTP/2使用encoder来减少需要传输的header大小。通讯双方各自缓存一份header fields表，避免了重复header的传输，也减小了需要传输的大小。高效的压缩算法能大大压缩header，减少发送包的数量，从而有效降低延迟。考虑到TCP的slow start特性以及可能的header膨胀超过initial tcp window值的情况，header压缩的重要性更加凸显。
四、压缩算法的选择与优化
HTTP/2最初使用gZIP压缩算法，但后来出现的BREACH和CRIME漏洞使得该算法受到攻击。综合考虑之下，HTTP/2采用了HPACK压缩算法。这种算法能够更好地保护内容的安全。关于这些漏洞和相关算法的具体细节，可以通过相关链接进行深入了解。值得注意的是，这些漏洞主要存在于浏览器端。
五、连接重置的改进与优势
在HTTP/1.x中，取消图片下载等功能场景往往通过重置连接来实现。这种方式会导致下次请求时必须重新建立连接。而HTTP/2通过引入RST_STREAM类型的frame，可以在不断开连接的前提下取消某个request的stream，表现更为优秀。这种设计改进了用户体验，提高了网络传输的效率。
六、Server Push功能的与应用场景
HTTP/2中的Server Push功能允许服务器通过推送方式将客户端需要的内容预先传递过去，也称为“cache push”。当客户端退出某个业务场景或由于流量等因素需要取消server push时，也可以通过发送RST_STREAM类型的frame来实现。这一特性显著提升了网络传输的效率和用户体验。
七、流量控制（Flow Control）的重要性与实现方式
HTTP/2通过类似TCP协议的流量控制机制来管理数据传输。数据的接收方通过告知对方自己的flow window大小表明自己还能接收多少数据。如果接收方在flow window为零的情况下依然接收更多的frame，则会返回block类型的frame。对于flow control的实现与管理是确保HTTP/2协议稳定运行的关键之一。
HTTP/2协议通过引入stream id、优先级与依赖、header压缩等核心特性，显著提升了网络传输效率和用户体验。对这些特性的深入理解和有效运用，对于开发和优化基于HTTP/2的应用至关重要。关于HTTP2.0与Nagle算法和TCP Delayed Ack的对比
HTTP协议优化的领域中，Nagle算法与Berkeley的delayed ack算法一直存在对立关系。在http2.0中，这种对立引发的高延迟问题依然存在。对此，有两种解决方案：要么通过TCP_NODELAY禁用Nagle算法，要么通过TCP_QUICKACK禁用delayed ack算法。据http2.0官方建议，通常设置TCP_NODELAY以优化性能。
关于更安全的SSL
HTTP2.0利用tls的拓展ALPN实现协议升级，并且在加密方面做了进一步的强化。通过黑名单机制，HTTP2.0禁用了数百种被认为不安全的加密算法。如果在SSL协商过程中，客户端与服务器无法就cipher suite达成一致，那么协商将失败，导致请求失败。在部署http2.0时，对这一点需要特别注意。
关于HTTP2.0的争议与现状
HTTP2.0与SPD之间的微妙关系以及Google作为SPD创造者身份，使得一些人怀疑Google是否会成为协议的最终受益方。但实际上，新协议的诞生主要是为了解决业界现存的问题，Google在其中扮演的角色更多的是推动和引领。HTTP2.0的最大亮点在于多路复用，但并非仅适用于大型站点。除此之外，请求压缩、优先级控制以及server push等功能也是HTTP2.0的亮点。对于内容型移动端应用如淘宝APP来说，由于其大量的HTTP请求，多路复用能够带来明显的体验提升。
尽管HTTP2.0对SSL有依赖，使得一些开发者对其有所畏惧。但实际上，SSL与HTTP结合对性能的影响已经优化到可以忽略的程度。HTTP2.0也可以不依赖SSL，在某些特定场景如通过代理服务器缓存优化体验时，可以使用非https的HTTP2.0。
至于HTTP2.0的现状，作为新版本的网络协议，它的普及需要一段时间。但由于HTTP2.0离底层协议较远，对网络基础设施的影响较小，因此普及速度可能会超出很多人的预期。Firefox和Chrome等浏览器已经开始支持HTTP2.0，并且有一部分流量已经在使用HTTP2.0。对于普通用户来说，可能无法察觉到是否使用了HTTP2.0，但对于开发者来说，可以通过一些工具来查看协议细节。
关于移动端的HTTP现状
在iOS系统中，从iOS8开始才通过NSURLSession支持SPD协议（SPDY是HTTP2.0的前身），而iOS9及以上版本则开始自动支持HTTP2.0。这意味着随着操作系统版本的升级，iOS系统对HTTP协议的支持也在逐步增强。可以预见的是随着技术的不断发展和普及，HTTP2.0将在移动端得到更广泛的应用，为用户带来更好的网络体验。随着科技的飞速发展，网络传输技术也在不断进步。HTTP协议作为信息传输的核心组成部分，经历了从HTTP 1.x到HTTP 2.0的重大变革。在这个过程中，Apple等科技公司大力推动新技术的发展，引领着行业的前进方向。
Apple对HTTP 2.0充满信心，并在其产品中大力推广。新版ATS机制默认使用HTTPS进行网络传输，确保了数据的安全性和传输速度。在iOS 9上，Apple Push Notification（APN）已经全面采用HTTP 2.0技术，使得推送通知更加快速和可靠。iOS 9 SDK中的NSURLSession也默认支持HTTP 2.0，对开发者来说，这一切都是透明的，无需额外配置。
对于开发者而言，如何配置最佳的HTTP使用方案至关重要。这主要取决于两方面因素：应用本身的HTTP流量大小和开发团队的技术条件。HTTP 2.0的部署相对简单，客户端开发者几乎无需改动，只需使用iOS 9的SDK编译即可。HTTP 2.0只能适用于iOS 9的设备，对于其他版本的系统，开发者可能需要考虑使用SPDY等过渡方案。
值得一提的是，由于苹果的TLS实现不支持NPN，通过NPN协商使用SPDY无法通过默认443端口实现。为此，有两种解决方案：一是客户端和服务器约定使用另一个端口号进行NPN协商；二是服务器通过请求头智能判断客户端是否支持SPDY而跳过NPN协商过程。Twitter的官方网站采用的是第二种方法。
随着iOS系统的不断更新和技术的进步，浏览器端和服务器端都在逐步放弃对SPDY的支持。作为过渡方案，SPD会随着iOS 9的普及逐步淡出舞台。但这并不意味着开发团队可以忽视这部分技术投入，毕竟在某些场景下，SPD仍然有其存在的必要性。
在Android系统中，HTTP 2.0的支持情况与iOS类似。对于使用WebView的App来说，需要基于Chrome内核的WebView才能支持SPDY和HTTP 2.0。而对于使用native API进行HTTP请求的App来说，OKHttp是支持SPDY和HTTP 2.0的可行方案之一。使用不同的技术路线对Android系统版本有不同的要求。
从HTTP 1.x到SPDY再到HTTP 2.0的技术变迁是一个不断演进的过程。作为工程师，我们需要深入了解这些协议背后的技术细节，才能构建高性能的网络框架，提升产品的用户体验。HTTP 2.0正处于逐步应用到线上产品和服务的阶段，未来会有更多新的挑战和机遇等待我们去和应对。