使用HTTP/2提升性能的7个建议(2)
|
SPDY是HTTP/2的上一代，总体性能相同。因为它已经出现好几年了，所以有很多浏览器支持SPDY却不支持HTTP/2。不过，在本文写作时，这个支持上的差距正在缩小。具体来说，有三分之二的浏览器支持HTTP/2，而有五分之四的浏览器支持SPDY。 如果你着急采用新的Web传输协议，又想尽可能覆盖更多用户，可以先从SPDY开始。然后到2016年初，即谷歌不再支持SPDY的时候，再切换到HTTP/2，很简单，至少在NGINX中如此。那时候，更多用户会拥有支持HTTP/2的浏览器，而你已经为其中大部分用户提供了很好的性能。 建议四：找出为HTTP/1.x优化的代码在决定采用HTTP/2之前，首先得知道你的代码有哪些是针对HTTP/1.x优化过的。大概有四方面的优化。
后面三种优化都涉及把小文件塞进一个较大的文件里，目的是减少新建连接的初始化和握手，这些操作对TLS而言非常费时间。 第一种优化即分域存储恰恰相反，强制打开多个连接，目的是并行地从不同的域获取文件。这两种看似矛盾的技术对于HTTP/1.x下的站点却十分有效。然而，要用好这两种技术，必须投入大量时间、精力和资源，用于实现、管理和运维。 在采用HTTP/2之前，需要找出应用了这些优化的代码，分析一下它们会不会影响你的应用设计和工作流程。这样在迁移到HTTP/2之后，就可以着手改造它们，甚至撤销某些优化。 建议五：部署HTTP/2或SPDY事实上，部署HTTP/2或SPDY并不难。如果你使用NGINX，只要在配置文件中启动相应的协议就可以了，参见这里了解如何启用HTTP/2（PDF）。浏览器和服务器会协商采用什么协议，如果浏览器支持HTTP/2（而且也在使用TLS），就会使用HTTP/2。 配置完服务器后，使用支持HTTP/2浏览器的用户就会基于HTTP/2运行你的应用，而使用旧版本浏览器的用户则会继续使用HTTP/1.x运行你的应用，如下图所示。如果你的网站流量非常大，那么应该监测改变前后的性能，对于性能降低的情况，可能就得撤销更改。
注意：使用HTTP/2及其单连接之后，NGINX某些配置的重要性会很明显，特别要注意的是output_buffers、proxy_buffers和ssl_buffer_size等指令，多测试一下。参见general configuration notes，特定的SSL建议（在这里 and here），以及NGINX关于SSL性能的白皮书（PDF）。 注意：使用HTTP/2传输密文要格外注意。HTTP/2的RFC中有一个长长的列表，列出了要避免的加密套件。建议你自己也搞一个表格，启用ssl_buffer_size，然后在所有常用的浏览器版本下测试你想用的加密套件。 建议六：再谈HTTP/1.x优化你说奇怪不，撤销和修改针对HTTP/1.x优化的代码居然是实现HTTP/2最有创意的部分。这里面有几个问题要注意，因为很多事怎么做都是可以的。 在开始运作之前，必须考虑旧版本浏览器用户是否好过。之后，可以采取三个策略撤销和修改HTTP/1.x的优化。
缓存还是普适的。理论上，缓存操作非常适合小文件特别多的情况。但是，小文件多也意味着文件I/O多。因此一些相近文件的合并还是必要的，一方面要考虑工作流程，另一方面要考虑应用性能。建议多关注一下其他人在过渡到HTTP/2过程中的一些经验。 建议七：实现智能分域分域存储可能是最极端但也最成功的HTTP/1.x优化策略。它能够提升HTTP/1.x下的应用性能，但在HTTP/2之下，其性能提升可以忽略不讲（因为只有一个连接。) 对HTTP/2友好的分域，要保证以下两点。
具体细节，请参考这里。 有了这些保障，分域还会继续对HTTP/1.x有效，即域名仍然可以触发浏览器创建更多连接，但对HTTP/2则无效，因为这些域名会被看成同一个域，一个连接就可以访问所有域名了。 小结HTTP/2和TLS组合可以提升你的站点性能，并且让用户觉得你的网站很安全。无论你是率先在自己的应用里实现HTTP/2，还是要赶超竞争对手，都可以又快又好地实现对HTTP/2的支持。 （编辑：ASP站长网） |
Redis未授权检测漏洞G
严峻Web对抗环境下的W
遭黑客盗走AMD GPU 部
企业级信息防泄漏大方