服务化的基石：聊聊通信协议那些事儿

• 在实现服务化以前，应用以本地 API在同一进程内调用为主，本地方法的调用使得性能损耗可以忽略不计。
• 实现服务化以后，服务提供者与服务消费者之间采用远程通信，网络使得服务间调用的延时增大，带来了额外的性能损耗。并且，由于网络的不稳定性与不确定性，分布式之间的调用失败风险也随之增加。

高效、安全、便利地实现远程通信是服务化的重要组成部分。另外，由于服务多由异构语言组成，因此如何能将跨语言调用的成本降至最低也成为大家关注的重点。远程通信的技术重点是通信方式和序列化协议。

网络是由物理层、数据链路层、网络层、传输层、会话层、表示层和应用层组成的OSI七层模型。由于复杂度过高，技术人员又定制了全新的 TCP/IP协议四层栈，并获得了更为广泛的应用。

如下图所示，TCP/IP协议四层栈将原OSI七层网络模型中的物理层和数据链路层对应为网络接口层，网络层和传输层仍然保留，会话层、表示层和应用层则合并为统一的应用层。

通信协议

传输层的通信协议由 TCP与UDP 组成，它们是截然不同的两种协议，分别适用于不同的场景。HTTP是另一个常见的协议，与传输层的协议不同，HTTP协议是应用层的协议，它是基于TCP协议的。

1.TCP协议

TCP协议的全称为传输控制协议，是一种面向连接的协议，提供可靠的双向字节流。它通过三次握手机制确保连接的可靠性。一个简明的三次握手流程如下。

• SYN：客户端发送包含同步序列号的SYN报文，并且同时传递一个随机数作为顺序号。为方便描述，我们将该顺序号设为x。
• SYN-ACK：服务端在接收到请求之后，返回SYN-ACK报文作为应答。并且同时传递一个值为x+1的应答号以及另一个随机数作为服务端的序列号。同样，为了方便描述，我们将应答号设为 x+1，服务端序列号设为y。
• ACK：客户端接收到服务端的应答后，分别将y+1与x+1作为应答号和序列号再次发送至客户端。

三次握手的流程以及序列号与应答号都校验无误后，才会完成连接的创建并发送数据。因此TCP的连接创建过程是较为昂贵的。通过下图可以看到使用TCP协议建立连接和发送数据的全过程。

TCP协议属于面向连接的协议。由于通信时必须创建连接的开销，因此TCP协议的开销高于UDP协议，性能却低于UDP协议。但TCP协议可以保证数据的正确性、顺序性和不可重复性。对于业务应用间的通信，TCP协议是更合适的选择。

2.UDP协议

UDP协议的全称为用户数据报文协议，是一种无连接的面向数据报文的协议。它不要求通信时保持连接，也没有接收方确认收到的报文传输而带来的开销。下图就是UDP协议传输数据的全过程，通过与TCP协议的流程图的对比，可以看到，UDP协议没有复杂的建立连接的过程，它关注的仅是数据报文本身。

虽然UDP协议可能产生网络丢包，且无法保证传输的原有顺序，但在性能方面更占优势。它更适于允许丢失的业务场景，如传输调用统计日志等趋势分析需求。

3.HTTP协议

HTTP协议的全称为超文本传输协议，是互联网中应用最为广泛的协议，基于浏览器的HTML、XML、JSON等格式的文本都是通过HTTP协议进行传输的。

HTTP协议非常便捷，客户端向服务端请求服务时，只需要发送路径、参数以及请求方法即可。常用的请求方法有 GET、POST、UPDATE、DELETE等，Restful API不可或缺的一部分由它们来组成。

HTTP协议是无连接且无状态的，无连接是指每次连接只处理一个请求，服务端处理完该请求并收到应答后，即断开连接。无状态则是指协议对于业务事务处理并没有记忆能力，如果后续处理需要之前的信息，则本次请求必须一次性地包含之前的信息。

随着技术的发展，HTTP协议不仅仅用于前端，也越来越多地用于后端应用的交互。与微服务配套使用的HTTP + Restful API方式已经非常成熟。

与HTTP协议同在应用层的常见协议包括FTP、Telnet、SMTP、DNS等。

Socket

Socket（常译为套接字）是用于连通应用层与传输层之间的抽象层接口。它采用IP地址和端口的方式确定一个网络环境中唯一的通信句柄，应用通过句柄向网络中的其他服务发送请求或应答处理所接收的请求。

Socket可以基于TCP协议和UDP协议。

1.长连接 & 短连接

长连接和短连接是指客户端连接服务端的方式。

长连接指客户端与服务端长期保持连接，连接不会在一次业务操作结束后断开，连接一旦创建成功，将进行最大限度的复用以节省资源开销和提升性能。长连接维护成本较高，需实时监控检查以保持连接的连通性。

短连接指客户端和服务端在处理完一次请求之后即断开连接，下次请求处理时则需要重新建立连接。虽然每次建立连接的消耗较大，但短连接无须维护连接的状态，实现复杂度大幅降低。

2.常见认识误区

对于长连接和短连接的认识，有两个常见的误区。

• 第一个误区：区分 TCP 协议和 HTTP协议的关键在于，TCP协议是长连接，HTTP协议是短连接。通过前面的阐述，大家可以理解TCP协议与HTTP协议处于不同的分层，HTTP是基于TCP的，因此区分它们并不取决于所谓的长连接和短连接。
• 第二个误区：HTTP协议只能使用短连接。从HTTP 1.1之后它已经可以支持长连接，而TCP协议也可以实现为短连接，这仅仅取决于客户端是否在完成一次请求之后便断开连接。但HTTP协议确实有一点与 TCP 协议不同，HTTP 协议是请求/响应模式，即只有客户端发起请求后服务端才会响应，服务端无法主动向客户端发起请求。而在基于 TCP 的Socket连接中，通信双方发送消息并没有先后的限制，通信双方中的任何一方都可以随时向另一方发送消息。

3.如何正确选择

长连接更加适合用于点对点的频繁通信。每个基于TCP协议的连接都需要经过三次握手，高频率的通信如果将时间都浪费在创建连接上就很不值得了。但是，由于维护连接所带来的消耗，连接的数量无法无限制增长。综上所述，长连接更加适合用于面向后端的系统之间的交互。例如，应用系统之间交互、数据库访问服务与数据库交互等。它们的共同特点是，交互频率高且连接个数有限。

短连接适用于基于B/S的浏览器与服务器交互的场景。由于HTTP协议是无状态的，浏览器和服务器每进行一次交互，便建立一次连接，任务结束后直接关闭连接。面向互联网海量用户的网站为每一个用户维持一个连接，这是无法承受的成本，而且相对于服务之间的交互，人为操作的频率根本不是一个数量级。

除面向用户的连接外，面向服务的后端场景也有可能使用短连接，由于基于HTTP协议的短连接实现起来非常便捷，因此如果服务间交互的性能不是系统瓶颈的话，使用短连接也是合适的。

总之，选择长连接还是短连接不能一言以蔽之，应该视情况而定。

本文摘自博文视点2018年开年大戏——张亮作品：《云原生分布式中间件架构》，深度揭秘开源产品Elastic-Job&Sharding-JDBC！