Unix/Linux编程：客户-服务器模型与软件设计

r囧r小猫 2022-10-05 10:48 134阅读 0赞

# 动机 #

客户端-服务器模型要求在任何一对进行通信的应用进程中，有一方必须在启动执行后(无限期的)等待对方与其联系。

# 术语和概念 #

客户-服务器范围根据通信的方向进行分类：

*  发起通信的叫做客户端。
 *  接收请求的叫做服务端。

为完成计算和返回结果，服务器软件经常需要访问受操作系统保护的对象(比如文件、数据库、设备、断开等)。因此，服务器软件的执行通常带有一些系统特权。注意，服务器应该含有处理下面安全问题代码

*  鉴别：验证客户的身份
 *  授权：判断客户是否被允许访问服务器所提供的服务
 *  数据安全：确保数据不会被泄露或者损坏
 *  保密：防止未经授权访问信息
 *  保护：确保网络应用程序不能滥用系统资源

## 面向连接和面向无连接的服务 ##

通常，应用程序只在下面情况下使用UDP：

*  应用程序指明必须使用UDP
 *  应用程序协议要用硬件进行广播或者组播
 *  应用程序不需要额外的可靠性处理，只在可靠的本地环境中运行

## 无状态和有状态的服务器 ##

服务器所维护的与客户交互活动的信息被称为状态信息。不存在任何状态信息的服务器称为无状态服务器，反之叫做有状态服务器。

获得高效率的愿望使得设计者在服务器中保存状态信息。这可以减少客户和服务器间交换数据的大小，还能允许服务器快速的响应请求。

*  从本质上来讲，状态信息让服务器记住了客户以前有过哪些请求，并在每个新请求到达时计算新新响应  
    \+如果报文丢失、重复或者交付失序，或者客户端崩溃等，则一个服务器中的状态会变得不正确，从而导致响应也不正确。因此，引入了 无状态服务器

### 无状态服务的例子 ###

考虑一个文件服务器，它允许客户远程访问保存在本地的文件。服务器作为一个应用程序运行，等待网络中的某个客户与它联系。客户发送的请求有两种类型，一是请求从指定文件中获取数据，或者请求在指定文件中存储数据。服务器指向所请求的操作并向客户发回响应

如果文件服务器是无状态的，它不维护有关事务处理的信息。客户发出的每个报文都必须指定完整的信息。如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

### 无状态服务的例子 ###

另一方面，考虑文件服务器维护状态信息时所用的报文内容。由于服务器能区分每个客户，并且保留者客户以前的请求，因此，请求报文中就不必包含所有字段信息。具体来讲：

*  在某个客户开始访问一个文件后，服务器中保留着被访问的文件名、当前位置、客户以前的操作。
 *  那么， 在客户发出第一个读文件的请求后，后继的请求报文中只需要包含一个字段：读取字节数。
 *  同样的，在客户发出第一个写文件的请求后，后继的请求报文中只需要包含两个字段：写入数据的字节数和写入数据本身。

一个有状态的文件服务器如何管理状态呢？服务器维护这一张表，该表中含有每个客户的信息和当前正在被访问文件的信息，如下：  
![在这里插入图片描述][20210608165617489.png]

## 标识客户 ##

有状态服务器标识客户有两种基本方法：端点和句柄。

使用端点标识符的优点是能自动进行标识，因为此机制只与下层传输协议有关，不依赖上层协议。确定是端点信息可能变化。比如一个网络故障会使得客户打开一个新的TCP连接。这个新连接不能和此客户以前的状态信息管理起来。

而句柄标识符能够将多个连接与一个固定客户联系起来。在客户发出第一个请求时，客户必须提供完整的信息，服务器收到请求后，将在状态表中增加一个条目，并为此条目生成一个称为句柄的标识符(通常是一个整数)。服务器将此句柄发回给客户以便后继使用。值得注意的是，由于此机制与下层传输协议无关，传输连接的变化不会使得此句柄无效。

有状态服务器不可能永远维持状态。当一个客户开始访问时，服务器为该客户分配一小部分本地资源(比如存储器)。如果服务器从不释放这些资源，那么资源最终将被耗尽。因此，有状态服务器需要终止。在文件服务器例子中，客户使用完某个文件后，必须发送一个报文通知服务器它不再用该文件了。而服务器接收到报文后，将删除存储的状态信息，然后使该表项可被其他客户使用

理想情况下，只有网络能够可靠的交付所有信息，并且计算机从不崩溃，则这种情况下，使服务器为每个进行这的交互保持少量状态信息，就可以使得交互的报文小写，并且使分布式应用更像非分布式应用

而实际中，机器可能崩溃或者重启，报文可能丢失、重复、交付失序。采用有状态的设计会导致复杂的应用协议，而这种协议难以设计、理解和实现

## 无状态是一个协议问题 ##

一个服务器到底是无状态还是有状态的-----这一问题的答案更多的取决于应用协议而不是实现。如果应用协议规定了某个报文的含义在某种情况下依赖于之前的一些报文，那么它就不可能提供无状态的交互

从本质上说，无状态问题的重点是应用协议是否承担着可靠交付的责任。要实现可靠就必须保证一个报文不能依赖于被按序交付或者依赖与前面的报文已经被交付。而且无论一个请求何时达到或者到达多少次，服务器都应给出同样的响应(幂等)。

如果一个互联网的下层网络可能使报文重复、延迟或者不按序交付，或者运行客户应用程序的计算机可能会意外崩溃，那么在这样的网络中服务器应该是无状态的。

只有当应用协议被设计成对操作是幂等的，服务才是无状态的。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221005/66024ebc507a4a82b4c9ca64e77b6c09.png
[20210608165617489.png]: /images/20221005/6edef607f0d14214971f60b87c02c746.png