制定 HTTP/2 的商业案例

HTTP/2 的开发充分考虑了性能。

话虽如此，基于性能为王的现实来制定商业案例似乎很简单，特别是涉及移动应用程序时。 无论成本是以生产力还是利润来衡量，性能不佳始终是消费者在购买、参与和使用移动应用时提出的一个重大问题。

但这只是简单的例子。 任何人只要简单地研究一下有关这一主题的一系列调查就能做出这一判断。 我们都知道，如果应用程序在 5 秒或更短的时间内没有响应，消费者和员工都会变得焦躁不安。 鉴于除了迁移到 HTTP/2 之外，还有各种各样的与性能相关的服务可供组织使用来解决该问题，因此在组织决定迁移到 HTTP/2 之前，可能需要提供更多的动力，以明确他们已确定自己是“云优先”企业。

那么，请考虑一下，HTTP/2 中的许多功能都源于对开发人员在 HTTP/1.1 中经常处理的问题的理解，以至于它成为了标准做法。 内联、连接和域分片等实践。 虽然这些都有助于提高性能，但不幸的是，每一个都产生了技术债务，至今仍在拖累开发人员和运营人员。 迁移到 HTTP/2 可以消除这些做法作为未来技术债务的来源，并提供“偿还”现有债务的途径。

技术（和架构）债务是由选择引起的。 选择采用哪种技术、购买哪种产品、实施哪种架构。 它还可以来自基于应用架构中特定解决方案的实现位置的决策。

例如，开发人员通过内联小图像和连接小文件来规避 HTTP/1.1 的一些限制。 事实上，这确实提高了性能，但代价是消除了（在网络中）额外的应用程序缓存选项。 它还需要在应用程序生命周期内引起注意，因为对这些内联图像或组成单个连接文件的文件的任何更改都需要反映在每个应用中。  缺乏模块化是技术债务的根源，只要应用仍在使用，这种技术债务就会持续存在。

技术债务与实际债务一样，需要偿还。 它是有代价的——利息。 随着每一次变化和每次更新，兴趣都会增加。 它需要开发人员的时间和注意力。 它需要测试资源。 它需要网络和计算资源。 这使得组织花费更多的时间来偿还“债务”，而不是用于创新或扩张，并且难以利用提供竞争优势的新技术、方法和架构概念。

这笔债务需要得到解决。 事实上，这个问题已经被消除，但至少需要得到解决。

对于 HTTP/1.1，结束 HTTP/1.1 债务循环的方法是采用 HTTP/2。 通过解决各种技术和协议限制，HTTP/2 为开发人员提供了一种摆脱过去的解决方法并在未来做出不同选择的方法。 不会带来技术债务的选择。 现有的应用确实保留了这些债务，但可以被使用 HTTP/2 的应用移动或替换，从而将开发和操作从旧 HTTP/1.1 对他们施加的限制中解放出来。

HTTP/2 不仅仅涉及更快的协议和应用程序。 它还可以消除开发和运营的限制，使他们摆脱技术债务，并为组织提供利用其他方式来提高性能的机会。 这种方法不太可能产生阻碍企业在应用竞赛中获胜的技术或架构债务。