关于客户端与服务端通信的一点感悟

一、引言

一直以来在公司从事于桌面客户端的开发，从事已有一年有余，却直到今天才领悟了客户端是如何与服务端进行通信的。这一方面大大得益于“Web Scraping with Python”作者对于 API 相关内容的描述，这不是我第一次接触 API，却是我第一次系统的了解 API。

那么这篇博客也是我的一点感悟，围绕以下几个问题开展：

1. 客户端如何与服务端一直保持联系？

2. 客户端如何与数据库进行通信？

二、服务端的两个部分

这里，对于大部分客户端来说，其实打交道的服务端有两个子模块：

1. 即时服务端：只在客户端在线的时候进行临时管理的逻辑，用于即时实时的连接控制。

2. 长时服务端：即使客户端下线，也要一直存在的管理逻辑，用于处理大量的数据，封装控制 API 等等。

二、客户端与即时服务端的通信

我们随便打开一个桌面软件，比如说 QQ。当我们登录之后，服务端会控制我们客户端的一些行为，比如显示新闻、显示未读信息等等。这些数据是怎么来的呢？客户端是如何得知的呢？

显然是通过即时服务端获取的。

也就是说，当我们客户端运行之后，第一件事情就是与即时服务端进行通信，建立可靠的 TCP 连接，使得我们的客户端与服务端可以即时通信。当我们客户端想要从服务端获取信息了，我们就发送信息给服务端，然后监听服务端的返回数据；当服务端想要控制客户端的行为时，就发送信息给客户端，客户端就做出相应的响应操作。

也就是说，客户端与即时服务端是实时即时通信的。

三、客户端与长时服务端的通信

而客户端总会有需要请求数据库数据的时候。这个时候，与即时服务端通信也无法满足要求了，我们该怎么办呢？

很简单，调用长时服务端的 API。

当我们用户登录之后，即时服务端会发送一个独属于这个用户的用于认证的 ticket，这个 ticket 可以看做是 API 调用时的凭证信息。

当我们客户端想要从数据库中获取信息时，我们就使用 HTTP 的 GET 方法调用 API 函数。然后监听返回的 Response 数据。

当我们客户端想要往数据库中存储信息时，我们就使用 HTTP 的 POST 方法调用 API 函数，从而达到往数据库中存储信息的方法。

至于 HTTP 的 PUT 和 DELETE 方法，用的比较少。

四、总结

这是我的一点感悟，用词不准确之处也敬请谅解。

即时服务端准确的说，应该是即时控制客户端的逻辑；长时服务端准确的说，应该是存储数据的数据库的逻辑（其中封装了大量 API）。客户端在与这两方进行通信时，显然采取了两种方式，前者即时通信，而后者采用了 API 的方式，Request-Response 的方式进行通信。

很多客户端软件都是这样的设计架构，也得益于这样的设计架构，才让我们的客户端脱身于复杂的数据库逻辑，在服务端的控制下更加灵活轻巧。