服务化基石之远程通信系列二：通信协议之应用层
通信协议之应用层
应用层包含所有的高层协议，例如FTP (File Transfer Protocol的简写，中文名称是文件传输协议)、SMTP (Simple Mail Transfer Protocol的简写，中文名称是简单电子邮件传输协议)、DNS (Domain Name Service的简写，中文名称是域名服务)和HTTP（HyperText Transfer Protocol的简写，中文名称是超文本传送协议等。HTTP是当今互联网应用中使用最广泛的应用层协议，也是应用程序间远程通信所采用比较多的协议。
HTTP是HyperText Transfer Protocol的简写，中文名称是超文本传输协议。它是互联网中应用最为广泛的协议，基于浏览器的HTML、XML、JSON等格式的文本都是通过HTTP进行传输的。它非常便捷，客户端向服务端请求服务时，只需发送路径、参数以及请求方法即可。请求方法常用的有GET、POST、UPDATE、DELETE等，它们组成RESTful架构风格的不可或缺的一部分。
HTTP/1.1
HTTP/1.1是自1999年正式标准化，到目前为止采用广泛。
HTTP/1.1是无连接且无状态的，无连接是指每次连接只处理一个请求，服务端处理完该请求并收到应答后，即断开连接。无状态是指协议对于业务事务处理并没有记忆能力，如果后续处理需要之前的信息，则本次请求必须一次性的包含之前的信息。
在HTTP/1.1时代，由于无法在同一个连接上并发请求，浏览器需要花费大量的时间等待每一个资源被响应。因此，浏览器通常需要开启多个连接来加速请求资源的过程。但过多连接开启的代价是十分昂贵的，所以，现代浏览器通常都有最多开启 6至8 个 HTTP/1.1 连接的限制。因此才会产生各种CSS，JavaScript以及图片合并技术，用于将众多小文件和并未一个完整的大文件来降低文件的个数，来提升浏览器加载的性能的效果。但不幸的是，单一的大文件会阻塞后续的请求，极度影响用户体验。总之，连接的限制逐渐成为了整个WEB 系统的性能瓶颈。
HTTP/2
直到2015年，HTTP才进行了首次重大的升级，这就是HTTP/2。HTTP/2 的目标是在与 HTTP/1.1语义完全兼容的前提下，进一步减少网络延迟。也就是说，HTTP/2 是在不改变原有 WEB 体系的同时，使性能进行提升。HTTP/2通过多路复用机制，来提升HTTP/1.1的性能。
HTTP/2 的多路复用机制，允许通过单一的连接同时发起多个的请求和响应的消息，这极大地提升了网络传输的性能 。通过下图可以清晰的看到HTTP/1.1和HTTP/2的差别。
HTTP/1.1和HTTP/2的差别
在HTTP/1.1协议中，展现一个包含CSS和JavaScript的HTML页面，需要以下9个步骤：
1. 浏览器和服务器创建连接。
2. 客户端通过GET方法请求index.html来获取页面内容。
3. 服务器返回index.html的内容。
4. 客户端通过GET方法请求style.css来获取页面样式表。
5. 服务器返回style.css的内容。
6. 客户端通过GET方法请求script.js来获取JavaScript脚本渲染页面。
7. 服务器返回script.js的内容。
8. 浏览器加载完毕，开始渲染页面。
9. 关闭连接。
可以看到，对于渲染每个页面，都需要加载一个页面的HMTL、CSS和JavaScript文件，它们是同步等待的过程，虽然可以通过开启多个连接来加速加载，但会增加服务器端的负荷。并且每次请求结束之后，浏览器和服务器之间的连接即关闭，下次请求还需要经过握手并建立连接的过程。
HTTP/2协议将展现一个页面的过程进行了很大的优化，它只包含7个步骤：
1. 浏览器和服务器创建连接。由于HTTP/2协议支持长连接，因此如果上次的连接仍然存在，则此步骤可以省略。
2. 客户端通过GET方法请求index.html来获取页面内容。因为必须先获取了HTML的内容，才能知道该页面中还包含哪些资源需要加载，因此获取页面内容是同步的。
3. 服务器返回index.html的内容。
4. 客户端通过GET方法请求style.css和script.js来获取页面样式表和JavaScript脚本。通过一个连接的多路复用可以同时请求多个文件。
5. 服务器通过连接的多路复用返回style.css和script.js的内容。
6. 浏览器加载完毕，开始渲染页面。
7. 保留连接，以便下次请求时使用。可以通过设置连接保留时间和最大连接限制以避免用户离开网站以及服务端持有的连接过多的问题。
关于HTTP/2比HTTP/1.1的性能对比，感兴趣的读者不妨访问一下https://http2.akamai.com/demo。
这是Akamai公司建立的一个官方演示，这个演示同时请求379张图片，用于展示HTTP/1.1和HTTP/2的性能差距。不同的电脑配置、网络情况以及服务器负载等情况不同，得到的结果肯定也不同，下图是笔者使用自己的电脑加载时间截图。
HTTP/2 通过数据流（stream）的方式支持连接的多路复用。一个连接可以包含多个数据流，多个 流发送的数据互相不影响，将请求和响应在同一个连接中分成不同的数据流可以进一步的提升交互的性能。HTTP/2将每次请求和响应以帧（frame）为单位进行了更细粒度的划分，所有的帧都在数据流上进行传输，数据流会确定好帧的发送顺序，另一端会按照接收的顺序来处理。除了多路复用，HTTP/2还提供服务器推送和请求头压缩等功能。
长连接 VS 短连接
长连接和短连接是指客户端连接服务端的方式。长连接指客户端与服务端长期保持连接，连接不会在一次业务操作结束后断开，连接一旦创建成功，将进行最大限度的复用以节省资源开销和性能的提升。长连接的维护成本较高，需要实时的监控检查用以保持连接的连通性。短连接指客户端和服务端在处理完一次请求之后即断开连接，下次请求的处理则需要重新建立连接。虽然每次建立连接的消耗较大，但短连接无需维护连接的状态，实现复杂度大幅降低。
对于长连接和短连接的认识，有几个常见的误区。第一个误区认为区分TCP和HTTP的关键在于TCP是长连接，HTTP是短连接。通过前面章节的阐述，读者可以理解到TCP与HTTP处于不同的网络分层，而HTTP是基于TCP的，因此TCP和HTTP的区别并不是长连接和短连接。第二个误区认为HTTP只能使用短连接。前面的章节也阐述过，HTTP自HTTP/2以来，已经全面支持长连接，而TCP也可以实现为短连接，这仅仅取决于客户端是否在完成一次请求之后即断开连接。那么，对于长连接还是短连接，应该如何选择呢？
长连接更加适合于端对端的频繁通信。每个基于TCP的连接都需要经过三次握手，高频度的通信如果将时间都浪费在连接的建立上，就很不划算了。但是，由于维护连接所带来的消耗，连接的数量则无法无限制的增长。综上所述，长连接更加适合于面向后端的系统之间的交互。例如：应用系统之间交互，数据库访问服务与数据库交互等。它们的共同特点是交互频度高且连接个数有限。
对于基于B/S的浏览器与服务器交互的情况，更加合适使用短连接。由于HTTP是无状态的，浏览器和服务器每进行一次交互，则建立一次连接，任务结束后直接关闭连接。面向互联网海量用户的网站，为每一个用户维持一个连接，是无法承受的成本，而且相对于服务之间的交互，人为操作的频度并不是一个数量级。除了面向用户的连接外，面向服务的后端场景也是有可能使用短连接的，由于基于HTTP的短连接实现非常便捷，因此如果服务间交互的性能不是系统瓶颈的话，使用短连接也是合适的。
总之，选择长连接还是短连接不能一言以蔽之，而是应该视情况而定。
以上内容节选自
《 Java云原生新一代分布式中间件架构》
内容简介
【互联网架构不断演化，经历了从集中式架构到分布式架构，再到云原生架构的过程。云原生因能解决传统应用升级缓慢、架构臃肿、不能快速迭代等问题而成为未来云端应用的目标。本书首先介绍了架构演化及云原生的概念，让读者对基础概念有一个准确的了解。接着阐述容器调度、服务化、分布式等体系的原理，讲解分布式中间件设计方法。最后辅以实战，以中心化和平台化角度切入，深度揭秘两大开源项目Elastic-Job和Sharding-JDBC的实现】
尽请期待
《Java云原生 新一代分布式中间件架构》
2018年将与您见面
书名尚未完全确定，欢迎您宝贵建议。
感谢大家关注“点亮架构”，欢迎对公众号文章的内容批评指正，如果有其他想要了解的技术问题，也可以留言提出。
‘点亮架构’的火炬，燃烧云原生‘
- 发表于:
- 原文链接：http://kuaibao.qq.com/s/20171226G08YIF00?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
