Unity Shader Graph基础包200+节点及术语解释-CFANZ编程社区

在客户-服务器体系结构（client-server architecture）中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。一个典型的例子是 Web 应用程序，其中总是打开的 web 服务器服务于来自浏览器（运行在客户主机上）的请求。当 Web 服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为响应。

值得注意的是利用客户-服务器体系结构，客户相互之间不直接通信。客户-服务器体系结构的另一个特征是该服务器具有固定的、周知的地址，该地址称为 IP 地址。

因为该服务器具有固定的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的 IP 地址发送分组来与其联系。

（2） P2P 体系结构（P2P architecture）

在一个 P2P 体系结构（P2P architecture）中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。这些对等方并不为服务提供商所有，相反却为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。

因为这种对等方通信不必通过专门的服务器，该体系结构被称对等方到对等方的。需要提及的是，某些应用具有混合的体系结构，它结合了客户-服务器和 P2P 的元素。

3. 进程间通讯

用操作系统的术语来说，进行通信的实际上是进程（process）而不是程序。一个进程可以被认为是运行在端系统中的一个程序。

在两个不同端系统上的进程，通过跨越计算机网络交换 报文（message）而相互通信。发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过回送报文进行响应。

（1）客户和服务器进程

网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。

例如，在 Web 应用程序中，一个客户浏览器进程与一台 Web 服务器进程交换报文。在一个 P2P 文件共享系统中，文件从一个对等方中的进程传输到另一个对等方中的进程。

对每对通信进程，我们通常将这两个进程之一标识为 客户（client），而另一个进程标识为 服务器（server）。

对于 Web 而言，浏览器是一个客户进程，Web 服务器是一台服务器进程。对于 P2P 文件共享，下载文件的对等方标识客户，上载文件的对等方标识为服务器。

（2）进程与计算机网络之间的接口

多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。

如上图所示，套接字是同一台主机内应用层与运输层之间的接口。

由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为 应用程序和网络之间的应用程序编程接口（Application Programming Interface, API）。应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。

一旦应用程序开发者选择了一个运输层协议（如果可供选择的话），则应用程序就建立在由该协议提供的运输层服务之上。

（3）进程寻址

为了向特定目的地发送邮政邮件，目的地需要有一个地址。类似地，在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。

在因特网中，主机由其 IP 地址（IP address）标识，IP 地址是一个 32 比特的量且它能够唯一地标识该主机。

二、Web 和 HTTP

20 世纪 90 年代初期，一个主要的新型应用即万维网（World Wide Web）登上了舞台。Web 是一个引起公众注意的因特网应用，它极大地改变了人们与工作环境内外交流的方式。它将因特网从只是很多数据网之一的地位提升为仅有的一个数据网。

1. 初识HTTP

Web 的应用层协议是 超文本传输协议（HyperText Transfer Protocol, HTTP），它是 Web 的核心，在［RFC 1945］和［RFC 2616］中进行了定义。

HTTP 由两个程序实现：一个客户程序和一个服务器程序。

客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP 报文进行会话。HTTP 定义了这些报文的结构以及客户和服务器进行报文交换的方式。

HTML 基本文件通过对象的 URL 地址引用 页面中的其他对象。每个 URL 地址由两部分组成：存放对象的服务器主机名和对象的路径名。

因 Web 浏览器（Web browser）实现了 HTTP 的客户端，所以在 Web 环境中我们经常交替使用 “ 浏览器 ” 和 “ 客户 ” 这两个术语。

Web 服务器（Web server）实现了 HTTP 的服务器端，它用于存储 Web 对象，每个对象由 URI 寻址。HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送 Web 页面的方式。

上图中，当用户请求一个 Web 页面（如点击一个超链接）时，浏览器向服务器发出对该页面中所包含对象的 HTTP 请求报文，服务器接收到请求并用包含这些对象的 HTTP 响应报文进行响应。

HTTP 使用 TCP 作为它的支撑运输协议（而不是在 UDP 上运行）。

HTTP 客户首先发起一个与服务器的 TCP 连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP。

TCP 为 HTTP 提供可靠数据传输服务。这意味着，一个客户进程发出的每个 HTTP 请求报文最终能完整地到达服务器；类似地，服务器进程发出的每个 HTTP 响应报文最终能完整地到达客户。

这里分层体系结构最大的优点，即 HTTP 协议不用担心数据丢失，也不关注 TCP 从网络的数据丢失和乱序故障中恢复的细节。那是 TCP 以及协议栈较低层协议的工作。

2. 非持续连接和持续连接

在许多因特网应用程序中，客户和服务器在一个相当长的时间范围内通信，其中客户发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该应用程序的使用方式，这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。当这种客户-服务器的交互是经 TCP 进行的，应用程序的研制者就需要做一个重要决定，即 每个请求/响应对是经一个单独的 TCP 连接发送，还是所有的请求及其响应经相同的 TCP 连接发送。

采用前一种方法，该应用程序被称为使用非持续连接（non-persistent connection）；采用后一种方法，该应用程序被称为使用持续连接（persistent connection）。

（1）采用非持续连接的 HTTP

在非持续连接情况下，从服务器向客户传送一个 Web 页面的步骤。

① HTTP 客户进程在端口号 80 发起一个到服务器 www.someSchool.edu 的 TCP 连接，该端口号是 HTTP 的默认端口。在客户和服务器上分别有一个套接字与该连接相关联。

② HTTP 客户经它的套接字向该服务器发送一个 HTTP 请求报文。请求报文中包含了路径名 /someDepartment/home.index。

③ HTTP 服务器进程经它的套接字接收该请求报文，从其存储器（RAM 或磁盘）中检索出对象 www.someSchool.edu/someDepartment/home.index，在一个 HTTP 响应报文中封装对象，并通过其套接字向客户发送响应报文。

④ HTTP 服务器进程通知 TCP 断开该 TCP 连接。（但是直到 TCP 确认客户已经完整地收到响应报文为止，它才会实际中断连接）

⑤ HTTP 客户接收响应报文，TCP 连接关闭。该报文指出封装的对象是一个 HTML 文件，客户从响应报文中提取出该文件，检查该 HTML 文件，得到对 10 个 JPEG 图形的引用。

⑥ 对每个引用的 JPEG 图形对象重复前 4 个步骤。

上述步骤中，每个 TCP 连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。每个 TCP 连接只传输一个请求报文和一个响应报文。因此这里，当用户请求该 Web 页面时，要产生 11 个 TCP 连接。

其他的，用户能够配置现代浏览器来控制连接的并行度。

在默认方式下，大部分浏览器打开 5~10 个并行的 TCP 连接，而每条连接处理一个请求响应事务。如果用户愿意，最大并行连接数可以设置 1，这样 10 条连接就会串行建立。使用并行连接可以缩短响应时间。

这里来简单估算一下从客户请求 HTML 基本文件起到该客户收到整个文件止所花费的时间。为此给出 往返时间（Round-Trip Time，RTT）的定义，该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。

RTT 包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延。

当用户点击超链接时，这引起浏览器在它和 Web 服务器之间发起一个 TCP 连接；这涉及一次 “ 三次握手 ” 过程，即客户向服务器发送一个小 TCP 报文段，服务器用一个小 TCP 报文段做出确认和响应，最后客户向服务器返回确认。三次握手中前两个部分所耗费的时间占用了一个 RTT。

完成了三次握手的前两个部分后，客户结合三次握手的第三部分（确认）向该 TCP 连接发送一个 HTTP 请求报文。一旦该请求报文到达服务器，服务器就在该 TCP 连接上发送 HTML 文件。该 HTTP 请求/响应用去了另一个 RTT。

（2）采用持续连接的 HTTP

非持续连接有一些缺点。

在采用 HTTP 1.1 持续连接的情况下，服务器在发送响应后保持该 TCP 连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。特别是一个完整的 Web 页面可以用单个持续 TCP 连接进行传送。

对对象的这些请求可以一个接一个地发出，而不必等待对未决请求（流水线）的回答。一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP 服务器就关闭该连接。HTTP 的默认模式是使用带流水线的持续连接。

3. 用户与服务器的交互（cookie）

cookie 在［RFC 6265］中定义，它 允许站点对用户进行跟踪。目前大多数商务 Web 站点都使用了 cookie。

下面通过一个典型的例子看看 cookie 的工作过程。

假设 Susan 总是从家中 PC 使用 InternetExplorer 上网，她首次与 Amazon.com 联系。我们假定过去她已经访问过 eBay 站点。

当请求报文到达该 Amazon Web 服务器时，该 Web 站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。

接下来 Amazon Web 服务器用一个包含 Set-cookie 首部的 HTTP 响应报文对 Susan 的浏览器进行响应，其中 Set-cookie 首部含有该识别码。例如，该首部行可能是 Set-cookie：1678。

当 Susan 的浏览器收到了该 HTTP 响应报文时，它会看到该 Set-cookie 首部。该浏览器在它管理的特定 cookie 文件中添加一行，该行 包含服务器的主机名和在 Set-cookie 首部中的识别码。

值得注意的是该 cookie 文件已经有了用于 eBay 的表项，因为 Susan 过去访问过该站点。当 Susan 继续浏览 Amazon 网站时，每请求一个 web 页面，其浏览器就会查询该 cookie 文件并抽取她对这个网站的识别码，并放到 HTTP 请求报文中包括识别码的 cookie 首部行中。

4. Web 缓存

Web 缓存器（Web cache）也叫 代理服务器（proxy server），它是能够代表初始 Web 服务器来满足 HTTP 请求的网络实体。

Web 缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。可以配置用户的浏览器，使得用户的所有 HTTP 请求首先指向 Web 缓存器。一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该 Web 缓存器。

举例来说，假设浏览器正在请求对象 http://www.someschool.edu/campus.gif，将会发生如下情况：

① 浏览器创建一个到 Web 缓存器的 TCP 连接，并向 Web 缓存器中的对象发送一个 HTTP 请求。

② Web 缓存器进行检查，看看本地是否存储了该对象副本。如果有，Web 缓存器就向客户浏览器用 HTTP 响应报文返回该对象。

③ 如果 Web 缓存器中没有该对象，它就打开一个与该对象的初始服务器（即www.someschool.edu）的 TCP 连接。Web 缓存器则在这个缓存器到服务器的 TCP 连接上发送一个对该对象的 HTTP 请求。在收到该请求后，初始服务器向该 Web 缓存器发送具有该对象的 HTTP 响应。

④ 当 web 缓存器接收到该对象时，它在本地存储空间存储一份副本，并向客户的浏览器用 HTTP 响应报文发送该副本（通过现有的客户浏览器和 Web 缓存器之间的 TCP 连接）。

三、因特网的目录服务（DNS）

1. 初识 DNS

识别主机有两种方式，通过主机名或者 IP 地址。人们喜欢便于记忆的主机名标识方式，而路由器则喜欢定长的、有着层次结构的 IP 地址。

为了折中这些不同的偏好，我们需要一种能进行主机名到 IP 地址转换的目录服务。这就是 域名系统（Domain Name System，DNS）的主要任务。

DNS 通常是由其他应用层协议所使用的，包括 HTTP、SMTP 和 FTP，将用户提供的主机名解析为 IP 地址。

举个例子，考虑运行在某用户主机上的一个浏览器（即一个 HTTP 客户）请求 URL www.someschool.edu/index.html 页面时会发生什么现象。为了使用户的主机能够将一个 HTTP 请求报文发送到 Web 服务器 www.someschool.edu，该用户主机必须获得 www.someschool.edu 的IP 地址。做法如下：

① 同一台用户主机上运行着 DNS 应用的客户端。

② 浏览器从上述 URL 中抽取出主机名 www.someschool.edu，并将这台主机名传给 DNS 应用的客户端。

③ DNS 客户向 DNS 服务器发送一个包含主机名的请求。

④ DNS 客户最终会收到一份回答报文，其中含有对应于该主机名的 IP 地址。

⑤ 一旦浏览器接收到来自 DNS 的该 IP 地址，它能够向位于该 IP 地址 80 端口的 HTTP 服务器进程发起一个 TCP 连接。

2. DNS 工作机理

DNS 的一种简单设计是在因特网上只使用一个 DNS 服务器，该服务器包含所有的映射。在这种集中式设计中，客户直接将所有查询直接发往单一的 DNS 服务器，同时该 DNS 服务器直接对所有的查询客户做出响应。

尽管这种设计的简单性非常具有吸引力，但它不适用于当今的因特网，因为因特网有着数量巨大（并持续增长）的主机。总的来说，在单一 DNS 服务器上运行集中式数据库完全没有可扩展能力。因此，DNS 采用了分布式的设计方案。

（1）分布式、层次数据库

为了处理扩展性问题，DNS 使用了大量的 DNS 服务器，它们以层次方式组织，并且分布在全世界范围内。没有一台 DNS 服务器拥有因特网上所有主机的映射。相反，这些映射分布在所有的 DNS 服务器上。

大致说来，有 3 种类型的 DNS服务器：根 DNS服务器、顶级域（Top-Level Domain，TLD）DNS 服务器和权威 DNS 服务器。

举个例子，假定一个 DNS 客户要决定主机名 www.amazon.com 的 IP 地址。粗略说来，将发生下列事件：

客户首先与根服务器之一联系，它将返回顶级域名 com 的 TLD 服务器的 IP 地址。该客户则与这些 TLD 服务器之一联系，它将为 amazon.com 返回权威服务器的 IP 地址。最后，该客户与 amazon.com 权威服务器之一联系，它为主机名 www.amazon.com 返回其 IP 地址。

还有另一类重要的 DNS 服务器，称为 本地 DNS 服务器（local DNS server）。严格说来，一个本地 DNS 服务器并不属于上述服务器的层次结构，但它对 DNS 层次结构是至关重要的。

每个 ISP（如一个居民区的 ISP 或一个机构的 ISP）都有一台本地 DNS 服务器（也叫默认名字服务器）。

来看一个简单的例子，假设主机 cse. nyu.edu 想知道主机 gaia.cs.umass.edu 的 IP 地址。同时假设纽约大学（NYU）的 cse.nyu.edu 主机的本地 DNS 服务器 dns.nyu.edu，并且 gaia.cs.umass.edu 的权威 DNS 服务器为 dns.umass.edu。

如上图所示，主机 cse.nyu.edu 首先向它的本地 DNS 服务器 dns.nyu.edu 发送一个 DNS 查询报文。该查询报文含有被转换的主机名 gaia.cs.umass.edu。

本地 DNS 服务器将该报文转发到根 DNS 服务器。该根 DNS服务器注意到其 edu 前缀并向本地 DNS 服务器返回负责 edu 的 TLD 的 IP 地址列表。

该本地 DNS 服务器则再次向这些 TLD 服务器之一发送查询报文。该 TLD 服务器注意到umass.edu 前缀，并用权威 DNS服务器的 IP 地址进行响应，该权威 DNS 服务器是负责马萨诸塞大学的 dns.umass.edu。

最后，本地 DNS 服务器直接向 dns.umass.edu 重发查询报文，dns.umass.edu 用 gaia.cs.umass.edu的 IP 地址进行响应。

在本例中，为了获得一台主机名的映射，共发送了 8 份 DNS 报文：4 份查询报文和 4 份回答报文。

（2）DNS 缓存

为了改善时延性能并减少在因特网上到处传输的 DNS 报文数量，DNS 广泛使用了缓存技术。

DNS 缓存的原理非常简单。在一个请求链中，当某 DNS 服务器接收一个 DNS 回答（例如，包含某主机名到 IP 地址的映射）时，它能将映射缓存在本地存储器中。

每当本地 DNS 服务器 dns.nyu.edu 从某个 DNS 服务器接收到一个回答，它能够缓存包含在该回答中的任何信息。

如果在 DNS 服务器中缓存了一台主机名/IP 地址对，另一个对相同主机名的查询到达该DNS 服务器时，该 DNS 服务器就能够提供所要求的 IP 地址，即使它不是该主机名的权威服务器。

由于主机和主机名与 IP 地址间的映射并不是永久的，DNS 服务器在一段时间后（通常设置两天）将丢弃缓存的信息。

四、内容分发网

1. 初识内容分发网

今天，许多因特网视频公司日复一日地向数以百万计的用户按需分发每秒数兆比特的流。对于一个因特网视频公司，或许提供流式视频服务最为直接的方法是建立单一的大规模数据中心，在数据中心中存储其所有视频，并直接从该数据中心向世界范围的客户传输流式视频。

为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用内容分发网（Content Distribution Network, CDN）。CDN 管理分布在多个地理位置上的服务器，在它的服务器中存储视频（和其他类型的 Web 内容，包括文档、图片和音频）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的 CDN 位置。CDN 可以是专用 CDN （private CDN），即它由内容提供商自己所拥有。

2. CDN 的服务安置原则

（1）深入

该原则是通过在遍及全球的接入 ISP 中部署服务器集群来深入到 ISP 的接人网中。Akamai 在大约 1700 个位置采用这种方法部署集群。其目标是靠近端用户，通过减少端用户和 CDN 集群之间（内容从这里收到）链路和路由器的数量，从而改善了用户感受的时延和吞吐量。因为这种高度分布式设计，维护和管理集群的任务成为挑战。

（2）邀请做客

该原则是通过在少量（例如10个）关键位置建造大集群来邀请到 ISP 做客。不是将集群放在接人 ISP 中，这些 CDN 通常将它们的集群放置在因特网交换点（IXP）。与深人设计原则相比，邀请做客设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价。

3. CDN 的操作

当用户主机中的一个浏览器指令检索一个特定的视频（由 URL 标识）时，CDN 必须截获该请求，以便能够：① 确定此时适合用于该客户的 CDN 服务器集群：② 将客户的请求重定向到该集群的某台服务器。

现在考虑用一个简单的例子来说明通常是怎样涉及 DNS 的：

假定一个内容提供商 NetCinema，雇佣了第三方 CDN 公司 KingCDN 来向其客户分发视频。在 NetCinema 的 Web 网页上，它的每个视频都被指派了一个 URL，该 URL 包括了字符串 “ video ” 以及该视频本身的独特标识符；例如，转换器 7 可以指派力 http://video.netcinema.com/6Y7B23V。接下来出现上图步骤：

① 用户访问位于 NetCinema 的 Web 网页。

② 当用户点击链接 http://video.netcinema.com/6Y7B23V 时，该用户主机发送了一个对于 video.netcinema.com 的 DNS 请求。

③ 用户的本地 DNS服务器（LDNS）将该 DNS 请求中继到一台用于 NetCinema 的权威 DNS 服务器，该服务器观察到主机名 video.netcinema.com 中的字符串 “video”。为了将该 DNS 请求移交给 KingCDN，NetCinema 权威 DNS 服务器并不返回一个 IP 地址，而是向 LDNS 返回一个 KingCDN 域的主机名，如 a1105.kingcdn.com。

④ 从这时起，DNS 请求进入了 KingCDN 专用 DNS基础设施。用户的 LDNS 则发送第二个请求，此时是对 a1105.kingcdn.com 的 DNS 请求，KingCDN 的 DNS 系统最终向 LDNS 返回 KingCDN 内容服务器的 IP 地址。所以正是在这里，在 KingCDN 的 DNS 系统中，指定了 CDN 服务器，客户将能够从这台服务器接收到它的内容。

⑤ LDNS 向用户主机转发内容服务 CDN 节点的IP地址。

⑥ 一旦客户收到 KingCDN 内容服务器的 IP 地址，它与具有该 IP 地址的服务器创建了一条直接的 TCP 连接，并且发出对该视频的 HTTP GET 请求。如果使用了 DASH，服务器将首先向客户发送具有 URL 列表的告示文件，每个 URL 对应视频的每个版本，并且客户将动态地选择来自不同版本的块。