【前五篇】系列文章传送门：
网络协议 15 - P2P 协议：小种子大学问
网络协议 16 - DNS 协议：网络世界的地址簿
网络协议 17 - HTTPDNS：私人定制的 DNS 服务
网络协议 18 - CDN：家门口的小卖铺
网络协议 19 - RPC 协议综述：远在天边，近在眼前
上一节我们了解 RPC 的经典模型和设计要点，并用最早期的 ONC RPC 为例子，详述了具体的实现。而时代在进步，ONC RPC 逐渐因为各种问题被替代，SOAP 协议就是替代者之一。
ONC RPC 存在的问题ONC RPC 将客户端要发送的参数，以及服务端要发送的回复，都压缩为一个二进制串，这样固然能够解决双方的协议约定问题，但是存在一定的不方便。
首先，需要双方的压缩格式完全一致，一点都不能差。一旦有少许的差错，多一位，少一位或者错一位，都可能造成无法解压缩。当然，我们可以用传输层的可靠性以及加入校验值等方式，来减少传输过程中的差错。
其次，协议修改不灵活。如果不是传输过程中造成的差错，而是客户端因为业务逻辑的改变，添加或者删除了字段，或者服务端添加或者删除了字段，而双方没有及时通知，或者线上系统没有及时升级，就会造成解压缩不成功。
因而，当业务发生改变，需要多传输一些参数或者少传输一些参数的时候，都需要及时通知对方，并且根据约定好的协议文件重新生成双方的 Stub 程序。自然，这样灵活性比较差。
如果仅仅是沟通的问题也还好解决，其实更难弄的还有版本的问题。比如在服务端提供一个服务，参数的格式是版本一的，已经有 50 个客户端在线上调用了。现在有一个客户端有个需求，要加一个字段，怎么办呢？这可是一个大工程，所有的客户端都要适配这个，需要重新写程序，加上这个字段，但是传输值是 0，不需要这个字段的客户端很“冤”，本来没我啥事儿，为啥让我也忙活？
最后，ONC RPC 的设计明显是面向函数的，而非面向对象。而当前面向对象的业务逻辑设计与实现方式已经成为主流。
这一切的根源就在于压缩。这就像平时我们爱用缩略语。如果是篮球爱好者，你直接说 NBA，他马上就知道什么意思，但是如果你给一个大妈说 NBA，她可能就不知所云。
所以，这种 RPC 框架只能用于客户端和服务端全由一拨人开发的场景，或者至少客户端和服务端的开发人员要密切沟通，相互合作，有大量的共同语言，才能按照既定的协议顺畅地进行工作。
XML 与 SOAP但是，一般情况下，我们做一个服务，都是要提供给陌生人用的，你和客户不会经常沟通，也没有什么共同语言。就像你给别人介绍 NBA，你要说美国职业篮球赛，这样不管他是干啥的，都能听得懂。
放到我们的场景中，对应的就是用文本类的方式进行传输。无论哪个客户端获得这个文本，都能够知道它的意义。
一种常见的文本类格式是 XML。我们这里举个例子来看。
<?xml version="1.0" encoding="UTF-8"?> <cnblog:purchaseOrder xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cnblog="http://www.example.com"> <order> <date>2019-01-08</date> <className> 板栗焖鸡 </className> <price>58</price> </order> </cnblog:purchaseOrder>我这里不准备详细讲述 XML 的语法规则，但是你相信我，看完下面的内容，即便你没有学过 XML，也能一看就懂，这段 XML 描述的是什么，不像全面的二进制，你看到的都是 010101，不知所云。
有了这个，刚才我们说的那几个问题就都不是问题了。
首先，格式没必要完全一致。比如如果我们把 price 和 author 换个位置，并不影响客户端和服务端解析这个文本，也根本不会误会，说这个作者的名字叫 68。
如果有的客户端想增加一个字段，例如添加一个推荐人字段，只需要在上面的文件中加一行：
<recommended> Gary </recommended>对于不需要这个字段的客户端，只要不解析这一行就是了。只要用简单的处理，就不会出现错误。
另外，这种表述方式显然是描述一个订单对象的，是一种面向对象的、更加接近用户场景的表示方式。
既然 XML 这么好，接下来我们来看看怎么把它用在 RPC 中。
传输协议问题我们先解决第一个，传输协议的问题。