篇首语：本文由小编为大家整理，主要介绍了客户机/服务器模式都有哪些？相关的知识，希望对你有一定的参考价值。
如电子邮件交换，Web访问和数据库访问功能，是建立在客户服务器模式。用户访问银行服务，从他们的电脑使用Web浏览器客户端发送请求到Web服务器在银行。该方案可能反过来请求转发给它自己的数据库客户端程序，在另一家银行的计算机发送一个请求到数据库服务器检索帐户信息。该余额返回到银行的数据库客户端，这反过来又服务于它的回Web浏览器客户端显示结果给用户。客户机服务器模式已成为网络计算的核心思想之一。许多商业应用程序被写入今天使用客户服务器模型。所以，做互联网的主要应用协议，如的HTTP，SMTP，Telnet和DNS的。客户端和服务器之间的交互是经常使用序列图描述。序列图是在统一建模语言规范。
特定类型的客户包括Web浏览器，电子邮件客户端和在线聊天的客户。
特定类型的服务器包括Web服务器，FTP服务器，应用服务器，数据库服务器，域名服务器，邮件服务器，文件服务器，打印服务器和终端服务器。大多数Web服务也是服务器类型。 参考技术A
客户机/服务器模式 Client/server model) 简称C/S系统。是一类按新的应用模式运行的分布式计算机系统。
在这个应用模式中，用户只关心完整地解决自己的应用问题，而不关心这些应用问题由系统中哪台或哪几台计算机来完成。在C/S系统中，能为应用提供服务（如文件服务，打印服务，拷贝服务，图象服务，通信管理服务等）的计算机或处理器，当其被请求服务时就成为服务器。
与服务器相对，提出服务请求的计算机或处理器在当时就是客户机。从客户应用角度看，这个应用的一部分工作在客户机上完成，其他部分的工作则在（一个或多个）服务器上完成。
扩展资料
客户机/服务器模式的特点：
可快速进行信息处理。由于在 C/S 结构中是一种基于点对点的运行环境，当一项任务提出请求处理时，可以在所有可能的服务器间均衡地分布该项任务的负载。这样，在客户端发出的请求可由多个服务器来并行进行处理，为每一项请求提供了极快的响应速度和较高的事务吞吐量。
可实现资源共享。C/L结构中的资源是分布的，客户机与服务器具有一对多的关系和运行环境。用户不仅可存取在服务器和本地工作站上的资源，还可以享用其他工作站上的资源，实现了资源共享。
参考资料来源：百度百科-客户服务器模式
参考技术B1、客户服务器模式(Client–server model)简称C/S结构，是一种网络架构，它把客户端 (Client) 与服务器 (Server) 区分开来。每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。
2、客户服务器模式通过不同的途径应用于很多不同类型的应用程序，最常见就是目前在因特网上用的网页。例如，当你在维基百科阅读文章时，你的电脑和网页浏览器就被当做一个客户端，同时，组成维基百科的电脑、数据库和应用程序就被当做服务器。当你的网页浏览器向维基百科请求一个指定的文章时，维基百科服务器从维基百科的数据库中找出所有该文章需要的信息，结合成一个网页，再发送回你的浏览器。
3、C/S模式是一个逻辑概念，而不是指计算机设备。在C/S模式中，请求一方为客户，响应请求一方称为服务器，如果一个服务器在响应客户请求时不能单独完成任务，还可能向其他服务器发出请求，这时，发出请求的服务器就成为另一个服务器的客户。从双方建立联系的方式来看，主动启动通信的应用叫客户，被动等待通信的应用叫服务器。
4、在计算客户端服务器模型是分布式应用程序结构，分区之间的一个任务或资源或服务，称为服务器供应商的工作量和服务请求者，称为客户端。常常在客户和服务器通信网络上的另一台计算机硬件，但客户端和服务器可以驻留在同一个系统。一个服务器计算机是一台正在运行一个或多个服务器计划，与客户分享他们的资源。一个客户端不共享任何资源，但要求服务器的内容或服务功能。因此，启动客户端与服务器等待着传入请求的通信会话。
参考技术C 在网络连接模式中,除对等网外,还有另一种形式的网络，即客户机/服务器网，Client/Server。在客户机/服务器网络中，服务器是网络的核心，而客户机是网络的基础，客户机依靠服务器获得所需要的网络资源，而服务器为客户机提供网络必须的资源。这里客户和服务器都是指通信中所涉及的两个应用进程（软件）。使用计算机的人是计算机的“用户”（user）而不是“客户”（client）。但在许多国外文献中，也经常把运行客户程序的机器称为client（这种情况下也可把client译为“客户机”），把运行服务器程序的机器称为server。所以有时要根据上下文判断client与server是指软件还是硬件。
它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到 Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
一、C/S结构的优点
C/S结构的优点是能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器。对应的优点就是客户端响应速度快。缺点主要有以下几个：
而随着互联网的飞速发展，移动办公和分布式办公越来越普及，这需要我们的系统具有扩展性。这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。
客户端需要安装专用的客户端软件。首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。还有，系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。(知不知道可以自动升级？)
对客户端的操作系统一般也会有限制。可能适应于Windows 98，但不能用于Windows 2000或Windows XP。或者不适用于微软新的操作系统等等，更不用说Linux、Unix等。(中国绝大多数用户都使用Windows操作系统)
二、C/S架构软件的优势与劣势
（1）、应用服务器运行数据负荷较轻。最简单的C/S体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器，也称为应用服务器。一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户应用程序运行在用户自己的电脑上，对应于数据库服务器，可称为客户电脑，当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则作出应答，送回结果，应用服务器运行数据负荷较轻。
（2）、数据的储存管理功能较为透明。在数据库应用中，数据的储存管理功能，是由服务器程序和客户应用程序分别独立进行的，前台应用可以违反的规则，并且通常把那些不同的（不管是已知还是未知的）运行数据，在服务器程序中不集中实现，例如访问者的权限，编号可以重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）背后的过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序不是非常“瘦小”，麻烦的事情都交给了服务器和网络。在C/S体系的下，数据库不能真正成为公共、专业化的仓库，它受到独立的专门管理。
（3）、C/S架构的劣势是高昂的维护成本且投资大。首先，采用C/S架构，要选择适当的数据库平台来实现数据库数据的真正“统一”，使分布于两地的数据同步完全交由数据库系统去管理，但逻辑上两地的操作者要直接访问同一个数据库才能有效实现，有这样一些问题，如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，网络管理工作人员既要对服务器维护管理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，维护成本很高，维护任务量大。(B/S就不用数据库了？)
其次，传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，由于产品的更新换代十分快，代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后，B/S架构更是猛烈冲击C/S，并对其形成威胁和挑战。
（没用JAVA语言写过C/S的？） 参考技术D 客户机/服务器模式是把网络应用程序分为两部分，称为前端和后端。前端程序装载在客户机上，它负责执行客户要求服务的可执行程序，并将服务器返回的内容反馈给客户；后端程序装载在服务器上，在服务器上运行着繁重的数据处理程序，为多个客户并发地提供各种服务，因此它还具有并发控制、保证数据完整性等功能。
优点：在文件服务器的应用中，应用程序和数据都集中在共享文件服务器上，当用户需要服务时，相应的应用程序和数据文件就整个地从文件服务器下载到用户计算机上，这样如果大量用户要求类似服务，将会灾难性地增加网络的通信量。现在由于服务器能集中处理用户要求的服务，从而使得具有慢速计算机的用户可利用共享服务器提供高速运算能力
使用 Websockets 代替 RESTful HTTP 都有哪些陷阱？
【中文标题】使用 Websockets 代替 RESTful HTTP 都有哪些陷阱？【英文标题】：What are the pitfalls of using Websockets in place of RESTful HTTP?使用 Websockets 代替 RESTful HTTP 有哪些陷阱？ 【发布时间】：2015-07-07 16:32:58 【问题描述】：我目前正在做一个项目，该项目需要客户端请求一项大工作并将其发送到服务器。然后服务器划分作业并以一组 url 响应客户端，以进行 GET 调用并流回数据。我是该项目的新手，我目前正在使用 Spring websockets 来提高效率。与客户端不断 ping 服务器以查看是否有准备好返回的结果不同，websocket 现在将直接联系客户端万岁！
让 websockets 从头到尾管理整个过程是不是一个坏主意？我正在将 STOMP 与 Spring websockets 一起使用，放弃 REST 还会存在重大问题吗？
【问题讨论】：
【参考方案1】：这真的取决于您的要求。与 Websockets 相比，REST 服务更透明，更易于开发人员使用。
使用 Websocket，您消除了 RESTful Web 服务提供的大部分优势，例如通过 URI 引用资源的能力。你真正应该做的是弄清楚 REST 和超媒体的优势是什么，并据此决定这些优势对你是否重要。
当然，完全可以创建一个 RESTful web 服务，并使用基于 websocket 的 API 来增强它以实现实时响应。
但是，如果您正在创建一个只有您将在受控环境中使用的服务，唯一的缺点可能是并非每个客户端都支持 websocket，而几乎任何类型的环境都可以进行简单的 http 调用。
【讨论】：
使用 Spring-websockets 和 Spring-messaging 我可以使用 /@MessageMapping 来获得 URI。我也可以进行 Spring-mvc /@RequestMapping 调用！似乎 Spring-websockets 可以允许类似 RESTful 的抽象？这就是我迷路的地方，可能是因为我很天真，但它让 websocket 开发看起来很有吸引力，但我没有听到太多关于它的嗡嗡声。【参考方案2】：使用 RESTful HTTP，您有一个无状态请求/响应系统，客户端发送请求，服务器返回响应。
使用 webSockets，您有一个有状态（或可能有状态）的消息传递系统，其中消息可以通过任一方式发送，并且发送消息的开销低于使用 RESTful HTTP 请求/响应。 p>
两者是完全不同的结构，具有不同的强度。
连接的 webSocket 的主要优点是：
双向通信。因此，服务器可以随时通知客户端任何事情。因此，客户端可以建立一个 webSocket 并监听来自服务器的任何消息，而不是定期轮询服务器以查看是否有新内容。从服务器的角度来看，当客户端感兴趣的事件发生时，服务器只是向客户端发送一条消息。服务器无法使用纯 HTTP 执行此操作。
每条消息的开销更低。如果您预计客户端和服务器之间会出现大量流量，那么使用 webSocket 时每条消息的开销会更低。这是因为 TCP 连接已经建立，您只需在已经打开的套接字上发送消息。对于 HTTP REST 请求，您必须首先建立一个 TCP 连接，该连接在客户端和服务器之间来回多次。然后，您发送 HTTP 请求，接收响应并关闭 TCP 连接。 HTTP 请求必然会包含一些开销，例如与该服务器对齐的所有 cookie，即使它们与特定请求无关。如果客户端和服务器都在使用 HTTP/2（最新的 HTTP 规范），那么它在这方面允许一些额外的效率，因为单个 TCP 连接可以用于多个请求/响应。如果您将 TCP 级别的所有请求/响应绘制成图表，只是为了发出 https REST 请求/响应，那么与仅通过已建立的 webSocket 发送消息相比，您会感到惊讶。
在某些情况下可扩展性更高。每条消息的开销较低，并且无需客户端轮询来确定是否有新内容，这可以提高可扩展性（给定服务器可以服务的客户端数量更多） . webSocket 的可扩展性也有缺点（见下文）。
有状态连接。无需借助 cookie 和会话 ID，您可以直接在程序中为给定连接存储状态。虽然已经对无状态连接进行了大量开发来解决大多数问题，但有时使用有状态连接会更简单。
RESTful HTTP 请求/响应的主要优点是：
普遍支持。很难获得比 HTTP 更普遍的支持。虽然 webSockets 现在享有相对较好的支持，但仍有一些情况下 webSocket 支持不定期可用。
兼容更多服务器环境。有些服务器环境不允许长时间运行服务器进程（某些共享托管情况）。这些环境可以支持 HTTP 请求，但不支持长时间运行的 webSocket 连接。
在某些情况下更高的规模。持续连接的 TCP 套接字的 webSocket 要求为服务器基础结构增加了一些 HTTP 请求不需要的新规模要求。因此，这最终成为一个权衡空间。如果 webSockets 的优势不是真正需要或被大量使用，那么 HTTP 请求实际上可能会更好地扩展。这绝对取决于具体的使用情况。
对于一次性请求/响应，单个 HTTP 请求比建立 webSocket、使用它然后关闭它更有效。这是因为打开一个 webSocket 是从一个 HTTP 请求/响应开始，然后双方同意升级到一个 webSocket 连接后，才能发送真正的 webSocket 消息。
无状态。如果您的工作没有因拥有无状态基础设施而变得更加复杂，那么无状态世界可以使扩展或故障转移变得更加容易（只需在负载均衡器后面添加或删除服务器进程)。
可自动缓存。通过正确的服务器设置，浏览器或代理可以缓存 http 响应。对于通过 webSockets 发送的请求，没有这样的内置机制。
所以，为了解决您提出问题的方式：
使用 websocket 代替 RESTful HTTP 有哪些陷阱？
在大规模（数十万客户端）中，您可能需要做一些特殊的服务器工作才能支持大量同时连接的 webSocket。
所有可能的客户端或工具集都不支持 webSocket 或通过它们发出的请求与支持 HTTP 请求的级别相同。
一些较便宜的服务器环境不支持支持 webSockets 所需的长时间运行的服务器进程。
如果将进度通知返回给客户端对您的应用程序很重要，您可以使用长时间运行的 http 连接并发送持续的进度，或者您可以使用 webSocket。 webSocket 可能更容易。如果您真的只在此特定活动的相对较短的持续时间内需要 webSocket，那么您可能会发现最好的整体权衡是仅在您需要能够将数据推送到客户端的持续时间内使用 webSocket，并且然后使用 http 请求进行正常的请求/响应活动。
【讨论】：
感谢您的详细回答。我仍在等待使 websockets 成为构建 web 应用程序的事实上的方式的神奇框架。我真的很喜欢 Spring 对 Websockets 所做的事情。也许它会演变成未来的大事。 为什么没有人提到 REST 响应是可缓存的，并且没有简单/自动的方法来缓存 Websocket 的结果？ @metamaker - 这是一个合理的观点，我会添加它。但是 webSocket 连接通常不用于与缓存相关的请求/响应类型的活动，事实上，http 通常是纯请求/响应的推荐选择。 @jfriend00 没错，但这是一个明确的用例，与 WebSockets 相比，REST 更胜一筹。 在支持方面，我们几乎 100% 支持浏览器：caniuse.com/#feat=websockets以上是关于客户机/服务器模式都有哪些？的主要内容，如果未能解决你的问题，请参考以下文章
