引言

网络应用是计算机网络存在的理由，如果我们不能构想出任何有用的应用，也就没有任何必要去设计支持它们的网络协议了。自因特网发明以来，的确已开发出众多有用的、有趣的网络应用。这些应用程序已经成为因特网成功的驱动力，激励人们在家庭、学校、政府和商业中利用网络，使因特网成为他们日常活动的密不可分的一部分。

6.1 应用层协议原理

6.1.1 网络应用程序体系结构

当进行软件编码之前，应当对应用程序有一个宽泛的体系结构计划。记住应用程序的体系结构明显不同于网络的体系结构。

从应用程序研发者的角度看，网络体系结构是固定的，并为应用程序提供了特定的服务集合。在另一方面，应用程序体系结构（application architecture）由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，应用程序研发者很可能利用现代网络应用程序中所使用的两种主流体系结构之一：客户—服务器体系结构或对等（P2P）体系结构。

客户—服务器体系结构（client-server architecture）

在客户—服务器体系结构中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。一个经典的例子是Web应用程序，其中总是打开的Web服务器服务于来自浏览器（运行在客户主机上）的请求。当Web服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为响应。值得注意的是利用客户—服务器体系结构，客户相互之间不直接通信；例如，在Web应用中两个浏览器并不直接通信。客户—服务器体系结构的另一个特征是该服务器具有固定的、周知的地址，该地址称为IP地址（我们将很快讨论它）。因为该服务器具有固定的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的IP地址发送分组来与其联系。具有客户—服务器体系结构的非常著名的应用程序包括Web、FTP、Telnet和电子邮件。下图显示了这种客户—服务器体系结构。

在一个客户—服务器应用中，常常会出现一台单独的服务器主机跟不上它所有客户请求的情况。例如，一个流行的社交网络站点如果仅有一台服务器来处理所有请求，将很快变得不堪重负。为此，配备大量主机的数据中心常被用于创建强大的虚拟服务器。最为流行的因特网服务——如搜索引擎、因特网商务、基于Web的电子邮件、社交网络，就应用了一个或多个数据中心。

P2P体系结构（P2P architecture）

在一个P2P体系结构中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。这些对等方并不为服务提供商所有，相反却为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。许多目前流行的、流量密集型应用都是P2P体系结构的。这些应用包括文件共享（例如BitTorent）、对等方协助下载加速器（例如迅雷）、因特网电话（例如Skype）和IPTV（例如“迅雷看看”和PPstream）。

下图显示了P2P的体系结构。

需要提及的是，某些应用具有混合的体系结构，它结合了客户—服务器和P2P的元素。例如，对于许多即时讯息应用而言，服务器被用于跟踪用户的IP地址，但用户到用户的报文在用户主机之间（无需通过中间服务器）直接发送。

P2P体系结构的最引人入胜的特性之一是它们的自扩展性（self-scalability）。例如，在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作量，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。P2P体系结构也是成本有效的，因为它们通常不需要庞大的服务器基础设施和服务器带宽（这与具有数据中心的客户—服务器设计形成反差）。

未来P2P应用面临三个主要挑战：

ISP友好。大多数住宅ISP（包括DSL和电缆ISP）已经受制于“非对称的”带宽应用，也就是说，下载比上载要多得多。但是P2P视频流和文件分发应用改变了从服务器到住宅ISP的上载流量，因而给ISP带来了巨大压力。未来P2P应用需要设计对ISP友好的模式。

安全性。因为它们的高度分布和开放特性，P2P应用给安全带来挑战。

激励。未来P2P应用的成功也取决于说服用户自愿向应用提供带宽、存储和计算资源，这对激励设计带来挑战。

6.2 Web和HTTP

20世纪90年代以前，因特网的主要使用者还是研究人员、学者和大学生，他们登录远程主机，在本地主机和远程主机之间传输文件，收发新闻，收发电子邮件。尽管这些应用非常有用（并且继续如此），但是因特网基本上不为学术界和研究界之外所知。

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

也许对大多数用户来说，最具有吸引力的就是Web的按需操作。当用户需要时，就能得到所想要的内容。这不同于无线电广播和电视，迫使用户只能收听、收看内容提供者提供的节目。除了可以按需操作以外，Web还有很多让人们喜欢和珍爱的特性。任何人使信息在Web上可用都非常简单，即只需要极低的费用就能成为出版人。超链接和搜索引擎帮助我们在Web站点的海洋里导航。图形化的界面刺激着我们的感官。表单、Java小程序和很多其他的装置，使我们可以与Web页面和站点进行交互。并且Web为许多在2003年以后出现的招人喜爱的应用提供了平台，这些应用包括YouTube、 Gmail 和Facebook。

6.2.1 HTTP概况

Web的应用层协议是超文本传输协议（HyperText Transfer Protocol，HTTP），它是Web的核心。HTTP由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。在详细解释HTTP之前，应当回顾某些Web术语。

Web页面（Web page）（也叫文档）是由对象组成的。一个对象（object）只是一个文件，诸如一个HTML文件、一个JPEG图形、一个Java小程序或一个视频片段这样的文件，且它们可通过一个URL地址寻址。

多数Web页面含有一个HTML基本文件（base HTML file）以及几个引用对象。例如，如果一个Web页面包含HTML文本和5个JPEG图形，那么这个Web页面有6个对象。HTML基本文件通过对象的URL地址引用页面中的其他对象。

每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。

例如，URL地址http://www.somneSchool.edu/someDepartment/picture.gif，其中的www.someSchool.edu就是主机名，/someDepartment/picture.gif就是路径名。

因为Web浏览器（Web browser）（例如Internet Explorer和Firefox）实现了HTTP的客户端，所以在Web环境中我们经常交替使用“浏览器”和“客户”这两个术语。Web服务器（Web server）实现了HTTP的服务器端，它用于存储Web对象，每个对象由URL寻址。流行的Web服务器有Apache和Microsoft Internet Information Server（微软互联网信息服务器）。

HTTP

HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。

我们稍后详细讨论客户和服务器的交互过程，而其基本思想在下图进行了图示。当用户请求一个Web页面（如点击一个超链接）时，浏览器向服务器发出对该页面中所包含对象的HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP响应报文进行响应。

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

HTTP客户首先发起一个与服务器的TCP连接。

一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。

客户端的套接字接口是客户进程与TCP连接之间的门，在服务器端的套接字接口则是服务器进程与TCP连接之间的门。客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文。类似地，服务器从它的套接字接口接收HTTP请求报文和向它的套接字接口发送HTTP响应报文。

客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入TCP的控制。

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

服务器进程发出的每个HTTP响应报文最终能完整地到达客户。

这里我们看到了分层体系结构最大的优点，

即HTTP协议不用担心数据丢失，

也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。

那些是TCP以及协议栈较低层协议的工作。

总结一下

Client side processing

Plugins/Extensions——集成的软件模块，在浏览器内执行。在浏览器内执行。

——直接访问在线环境

Helper——独立的程序，可以被浏览器实例化，但只能访问本地缓存的内容。

——浏览器实例化，但只能访问本地缓存的文件内容。

Server side processing – static page

接受来自客户端（浏览器）的TCP连接

识别要求的文件

从本地存储器（磁盘、RAM...）中获取指定文件

发送文件给客户端

释放TCP连接

注意到下列现象很重要：服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。假如某个特定的客户在短短的几秒钟内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。因为HTTP服务器并不保存关于客户的任何信息，所以我们说HTTP是一个无状态协议（stateless protocol）。我们同时也注意到Web使用了客户—服务器应用程序体系结构。Web服务器总是打开的，具有一个固定的IP地址，且它服务于可能来自数以百万计的不同浏览器的请求。

HTTP 1.0	single use connection
HTTP 1.1	persistent connections, additional headers
HTTP/2	Further speed improvements (origins in SPDY)
HTTP/3	Allow more parallelism in data loading (QUIC)

6.2.2 非持续连接和持续连接

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

即每个请求/响应对是经一个单独的TCP连接发送，还是所有的请求及其响应经相同的TCP连接发送呢？

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

采用后一种方法，该应用程序被称为使用持续连接（persistent conction）。

为了深入地理解该设计问题，我们研究在特定的应用程序即HTTP的情况下持续连接的优点和缺点，HTTP既能够使用非持续连接，也能够使用持续连接。尽管HTTP在其默认方式下使用持续连接，HTTP客户和服务器也能配置成使用非持续连接。

6.2.2.1 采用非持续连接的HTTP

我们看看在非持续连接情况下，从服务器向客户传送一个Web页面的步骤。假设该页面含有一个HTML基本文件和10个JPEG图形，并且这11个对象位于同一台服务器上。该HTML文件的URL为：http://www.someSchool.edu/someDepartment/home.index。

我们看看发生了什么情况：

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

HTTP客户经它的套接字向该服务器发送一个HTTP请求报文。请求报文中包含了路径名 /someDepartment/home.index（后面我们会详细讨论HTTP报文）。

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

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

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

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

当浏览器收到Web页面后，显示给用户。两个不同的浏览器也许会以不同的方式解释（即向用户显示）该页面。HTTP与客户如何解释一个 Web页面毫无关系。HTTP 规范仅定义了在HTTP客户程序与HTTP服务器程序之间的通信协议。

上面的步骤举例说明了非持续连接的使用，其中每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。用户能够配置现代浏览器以控制并行度。在默认方式下，大部分浏览器打开5~10个并行的TCP连接，而每条连接处理一个请求响应事务。如果用户愿意，最大并行连接数可以设置为1，这样10条连接就会串行建立。使用并行连接可以缩短响应时间。

在继续讨论之前，我们来简单估算一下从客户请求HTML基本文件起到该客户收到整个文件止所花费的时间。为此，我们给出往返时间的定义。

往返时间（Round-Trip Time，RTT）

该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。

RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延。现在考虑当用户点击超链接时会发生什么现象。如下图所示，

这引起浏览器在它和Web服务器之间发起一个TCP连接；这涉及一次“三次握手”过程，即客户向服务器发送一个小TCP报文段，服务器用一个小TCP报文段做出确认和响应，最后，客户向服务器返回确认。三次握手中前两个部分所耗费的时间占用了一个RTT。完成了三次握手的前两个部分后，客户结合三次握手的第三部分（确认）向该TCP连接发送一个HTTP请求报文。一旦该请求报文到达服务器，服务器就在该TCP连接上发送HTML文件。该HTTP请求/响应用去了另一个RTT。因此，粗略地讲，

总的响应时间就是两个RTT加上服务器传输HTML文件的时间。

6.2.2.2 采用持续连接的HTTP

非持续连接有一些缺点：

首先，必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这给Web服务器带来了严重的负担，因为一台Web服务器可能同时服务于数以百计不同的客户的请求。

第二，就像我们刚描述的那样，每一个对象经受两倍RTT的交付时延，即一个RTT用于创建TCP，另一个RTT用于请求和接收一个对象。

在采用持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。特别是，一个完整的Web页面（上例中的HTML基本文件加上10个图形）可以用单个持续TCP连接进行传送。更有甚者，位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行。可以一个接一个地发出对对象的这些请求，而不必等待对未决请求（流水线）的回答。一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。HTTP的默认模式是使用带流水线的持续连接。

6.2.3 HTTP报文格式

HTTP规范包含了对HTTP报文格式的定义。HTTP报文有两种：请求报文和响应报文。下面讨论这两种报文。

6.2.3.1 HTTP请求报文

下面提供了一个典型的HTTP请求报文：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

通过仔细观察这个简单的请求报文，我们就能知道很多东西。首先，我们看到该报文是用普通的ASCII文本书写的，这样有一定计算机知识的人都能够阅读它。其次，我们看到该报文由5行组成，每行由一个回车和换行符结束。最后一行后再附加一个回车换行符。虽然这个特定的报文仅有5行，但一个请求报文能够具有更多的行或者至少为一行。

HTTP请求报文的第一行叫做请求行（request line），其后继的行叫做首部行（header line）。请求行有3个字段：方法字段、URL字段和HTTP版本字段。方法字段可以取几种不同的值，包括GET、POST、HEAD、PUT和DELETE。绝大部分的HTTP请求报文使用GET方法。当浏览器请求一个对象时，使用GET方法，在URL字段带有请求对象的标识。

在本例中，该浏览器正在请求对象

/somedir/page.html

其版本字段是自解释的；在本例中，浏览器实现的是

HTTP/1.1

现在我们看看本例的首部行。首部行

Host: www.someschool.edu

指明了对象所在的主机。你也许认为该首部行是不必要的，因为在该主机中已经有一条TCP连接存在了。但是，该首部行提供的信息是Web代理高速缓存所要求的。

通过包含

Connection: close

首部行，该浏览器告诉服务器不希望麻烦地使用持续连接，它要求服务器在发送完被请求的对象后就关闭这条连接。

User-agent: Mozilla/5.0

首部行用来指明用户代理，即向服务器发送请求的浏览器的类型。这里浏览器类型是Moilla/5.0，即Firefox浏览器。这个首部行是有用的，因为服务器可以有效地为不同类型的用户代理实际发送相同对象的不同版本（每个版本都由相同的URL寻址）。

Accept-language: fr

最后的首部行表示用户想得到该对象的法语版本（如果服务器中有这样的对象的话）；否则，服务器应当发送它的默认版本。Accept-language：首部行仅是HTTP中可用的众多内容协商首部之一。

看过一个例子之后，我们再来看看下图所示的一个请求报文的通用格式。

我们看到该通用格式与我们前面的例子密切对应。然而，你可能已经注意到了在首部行（和附加
的回车和换行）后有一个“实体体”（entity body）。使用GET方法时实体体为空，而使用POST方法时才使用该实体体。

POST方法

当用户提交表单时，HTTP客户常常使用POST方法，例如当用户向搜索引擎提供搜索关键词时。使用POST报文时，用户仍可以向服务器请求一个Web页面，但Web页面的特定内容依赖于用户在表单字段中输入的内容。如果方法字段的值为POST时，则实体体中包含的就是用户在表单字段中的输入值。

当然，如果不提“用表单生成的请求报文不是必须使用POST方法”这一点，那将是失职。HTML表单经常使用GET方法，并在（表单字段中）所请求的URL中包括输入的数据。例如，一个表单使用GET方法，它有两个字段，分别填写的是“monkeys"和“bananas"，这样，该URL结构为www.somesite.com/animalsearch?monkeys&bananas。在日复一日的网上冲浪中，你也许已经留意到了这种扩展的URL。

HEAD方法

HEAD方法类似于GET方法。当服务器收到使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行调试跟踪。

PUT方法

PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径（目录）。PUT方法也被那些需要向Web服务器上传对象的应用程序使用。

DELETE方法

DELETE方法允许用户或者应用程序删除Web服务器上的对象。

6.2.3.2 HTTP响应报文

下面我们提供了一条典型的HTTP响应报文。该响应报文可以是对刚刚讨论的例子中请求报文的响应。

HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue，09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html(data data data data data ... )

我们仔细看一下这个响应报文。它有三个部分：一个初始状态行（status line），6个首部行（header line），然后是实体体（entity body）。实体体部分是报文的主要部分，即它包含了所请求的对象本身（表示为data data data data...）。

HTTP/1.1 200 OK

状态行有3个字段：协议版本字段、状态码和相应状态信息。在这个例子中，状态行指示服务器正在使用HTTP/1.1，并且一切正常（即服务器已经找到并正在发送所请求的对象）。

我们现在来看看首部行。服务器用

Connection: close

首部行告诉客户，发送完报文后将关闭该TCP连接。

Date: Tue, 09 Aug 2011 15:44:04 GMT

Date：首部行指示服务器产生并发送该响应报文的日期和时间。值得一提的是，这个时间不是指对象创建或者最后修改的时间；而是服务器从它的文件系统中检索到该对象，插入到响应报文，并发送该响应报文的时间。

Server: Apache/2.2.3 (CentOS)

Server：首部行指示该报文是由一台ApacheWeb服务器产生的，它类似于HTTP请求报文中的User-agent：首部行。

Last-Modified: Tue，09 Aug 2011 15:11:03 GMT

Last-Modified：首部行指示了对象创建或者最后修改的日期和时间。Last-Modifed：首部行对既可能在本地客户也可能在网络缓存服务器上的对象缓存来说非常重要。我们将很快详细地讨论缓存服务器（也叫代理服务器）。

Content-Length: 6821

Content-Length:首部行指示了被发送对象中的字节数。

Content-Type: text/html

Content-Type：首部行指示了实体体中的对象是HTML文本。（该对象类型应该正式地由Content-Type：首部行而不是用文件扩展名来指示。）

看过一个例子后，我们再来查看响应报文的通用格式，如下图所示：

该通用格式能够与前面例子中的响应报文对应起来。我们补充说明一下状态码和它们对应的短语。状态码及其相应的短语指示了请求的结果。一些常见的状态码和相关的短语包括：

200 OK：	请求成功，信息在返回的响应报文中
301 Moved Permanently：	请求的对象已经被永久转移了，新的URL定义在响应报文的Location：首部行中。客户软件将自动获取新的URL
400 BadRequest：	一个通用差错代码，指示该请求不能被服务器理解
404 Not Found：	被请求的文档不在服务器上
505 HTTP Version Not Supported：	服务器不支持请求报文使用的HTTP协议版本

上面，我们讨论了HTTP请求报文和响应报文中的一些首部行。HTTP规范中定义了很多可以被浏览器、Web服务器和Web缓存服务器插入的首部行。我们只提到了全部首部行中的少数几个。

浏览器是如何决定在一个请求报文中包含哪些首部行的呢？Web服务器又是如何决定在一个响应报文中包含哪些首部行呢？浏览器产生的首部行与很多因素有关，包括浏览器的类型和协议版本（例如，HTTP/1.0浏览器将不会产生任何1.1版本的首部行）、浏览器的用户配置（喜好的语言）、浏览器当前是否有一个缓存的但是可能超期的对象版本。Web服务器的表现也类似：在产品、版本和配置上都有差异，所有这些都会影响响应报文中包含的首部行。

6.2.3.3 HTTP Headers

6.2.4 用户与服务器的交互：cookie

我们前面提到了HTTP服务器是无状态的。这简化了服务器的设计，并且允许工程师们去开发可以同时处理数以千计的TCP连接的高性能Web服务器。然而一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。为此，HTTP使用了cookie。cookie在中定义，它允许站点对用户进行跟踪。目前大多数商务Web站点都使用了cookie。

如图所示，cookie 技术有4个组件：

①在HTTP响应报文中的一个cookie首部行；

②在HTTP请求报文中的一个cookie首部行；

③在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理；

④位于Web站点的一个后端数据库。

使用上图，我们通过一个典型的例子看看cookie的工作过程。假设Susan总是从家中PC使用InternetExplorer上网，她首次与Amazon.com联系。我们假定过去她已经访问过eBay站点。当请
求报文到达该AmazonWeb服务器时，该Web站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。接下来AmazonWeb服务器用一个包含Set-cookie：首部的HTTP响应报文对Susan的浏览器进行响应，其中Set-cookie：首部含有该识别码。

例如，该首部行可能是

Set-cookie: 1678

当Susan的浏览器收到了该HTTP响应报文时，它会看到该Set-cookie：首部行。该浏览器在它管理的特定cookie文件中添加一行，该行包含服务器的主机名和在Sel-cookie：首部中的识别码。值得注意的是该cookie文件已经有了用于eBay的表项，因为Susan过去访问过该站点。当Susan继续浏览Amazon网站时，每请求一个Web页面，其浏览器就会从该cookie文件中获取她对这个网站的识别码，并放到HTTP请求报文中包括识别码的cookie首部行中。特别是，发往该Amazon服务器的每个HTTP请求报文都包括以下首部行：

Cookie: 1678

在这种方式下，Amazon 服务器可以跟踪Susan在Amazon站点的活动。尽管Amazon Web站点不必知道Susan的名字，但它确切地知道用户1678按照什么顺序、在什么时间、访问了哪些页面!Amazon使用cookie来提供它的购物车服务，即Amazon能够维护Susan希望购买的物品列表，这样在Susan结束会话时可以一起为它们付费。

如果Susan再次访问Amazon站点，比如说一个星期后，她的浏览器会在其请求报文中继续放入首部行cookie：1678。Amazon将根据Susan过去在Amazon访问的网页向她推荐产品。如果Susan也在Amazon注册过，即提供了她的全名、电子邮件地址、邮政地址和信用卡账号，则Amazon能在其数据库中包括这些信息，将她的全名与识别码相关联（以及她在过去访问过的所有页面）。这就解释了Amazon和其他一些电子商务网站实现“点击购物”（one-elick shopping）的道理，即当Susan在后继的访问中选择购买某个物品时，她不必重新输入姓名、信用卡账号或者地址等信息了。

从上述讨论中我们看到，cookie 可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识（可能是名字）。在后继会话中，浏览器向服务器传递一个cookie首部，从而向该服务器标识了用户。因此cookie可以在无状态的HTTP之上建立一个用户会话层。例如，当用户向一个基于Web的电子邮件系统（如Hotmail）注册时，浏览器向服务器发送cookie 信息，允许该服务器在用户与应用程序会话的过程中标识该用户。

尽管cookie常常能简化用户的因特网购物活动，但是它的使用仍具有争议，因为它们被认为是对用户隐私的一种侵害。如我们刚才所见，结合cookie 和用户提供的账户信息，Web站点可以知道许多有关用户的信息，并可能将这些信息卖给第三方。

6.2.5 Web 代理

用于缓存、安全和IP地址共享
浏览器将所有的HTTP请求发送给代理。代理机构返回其缓存中的对象，或者代理从原服务器请求对象，然后再将对象返回给客户端。
注意：代理服务器既是客户又是服务器。

6.2.6 静态 Web 文件

HTML——超文本标记语言

一种简单的语言，旨在对内容和展示信息进行编码

纯文本编码，以浏览器为基础进行渲染

限于ISO-8859 Latin-1字符集（在XHTML与UTF编码之前，没有引入国际化）。

Web Page Components——网页组件

结构划分。

头部 <head> ... </head>

主体 <body> ... </body>

语法上受限制的标签集

属性和值 <img src="pic1.gif" alt="pic1.gif">

6.2.6.1 Beyond HTML

HTML最初是SGML（标准通用标记语言）的一个实例。人们想要一种类似HTML的语言来描述非超文本的数据，但SGML太过笼统/"沉重"。

XML（可扩展标记语言）和XSL（可扩展样式表语言）

主要特点：内容和展示性标记的分离

——严格的验证要求

XHTML

——本质上是HTML4.0作为有效的XML的表达。

——与HTML4.0的主要区别是对一致性的要求，大小写折叠。格式良好、属性规范、嵌套和嵌入，以及包含一个文档类型标识符

6.2.6.2 动态内容

6.2.6.3 Scripting

制作交互式网络应用程序的技术包括。
——JavaScript
——Java Applets：编译的Java代码（与平台无关）
——ActiveX：用于Windows的编译代码
——AJAX：
                HTML和CSS：以页面形式呈现信息。
                DOM：在浏览时改变页面的部分内容。
                XML：让程序与服务器交换数据。
                发送和检索XML数据的异步方式。
                JavaScript作为一种语言，将所有这些结合在一起

计算机系统（六）：应用层（上篇）相关推荐

电商项目——商品服务-API-属性分组——第十一章——上篇
电商项目--初识电商--第一章--上篇电商项目--分布式基础概念和电商项目微服务架构图,划分图的详解--第二章--上篇电商项目--电商项目的虚拟机环境搭建_VirtualBox,Vagrant-- ...
【408】计算机网络第一轮强化笔记
计算机网络第一轮强化笔记根据天勤高分笔记所做 Ping使用ICMP请求报文分片片偏移单位 8 B 首部字段单位 4 B 总字段长度单位 1 B DHCP: 客户机发送 discover 服务器发送 ...
黑客完全修炼手册（收藏）
第一节.黑客的种类和行为以我的理解,"黑客"大体上应该分为"正"."邪"两类,正派黑客依靠自己掌握的知识帮助系统管理员找出系统中的漏洞并加 ...
上海交通大学考研复试模块小结——防火墙技术
既然上次开了这个系列,索性就把这个信息安全这一块的主流技术都介绍一遍好了.上篇博客讲了密码学,今天就来说说防火墙技术. 防火墙技术防火墙技术是位于两个新人程度不同的网络之间的软件或者硬件设备的组合, ...
当中台遇上DDD，我们该如何设计微服务？
微服务架构有哪些模型?中台.领域驱动设计及微服务之间有着什么样的关系?微服务的边界设计怎么做?怎么做设计和拆分?且看作者为你娓娓道来. 借用当下最流行的段子做个开场白. "设计原则千万条,高 ...
计算机网络原理课程描述,计算机网络原理
<计算机网络原理>教学大纲课程编号:135034 课程名称:<计算机网络原理> 学时/学分:64学时/3.5学分先修课程:先修课程<计算机导论>.<数据结 ...
952计算机网络是那本书,952计算机网络复习参考提纲.doc
952"计算机网络"复习参考提纲考察目标 1.掌握计算机网络的基本概念.基本原理和基本方法: 2.掌握计算机网络的体系结构和典型网络协议,了解典型网络设备的组成和特点,理解典型网 ...
如何使用ABP框架（2）三层架构与领域驱动设计的对比
本文来自长沙.NET技术社区,原创:邹溪源.全文共有8500字,读完需耗时10分钟. 题图来自@pixabay 简述上一篇简述了ABP框架中的一些基础理论,包括ABP前后端项目的分层结构,以及后端项 ...
领域驱动设计，让程序员心中有码（四）
#领域驱动设计,让程序员心中有码(四) ----------------------追忆有关分层的古老往事我一直认为,程序员也是艺术家,他们撰写的每一行代码,是献给这大好世界的优美诗篇.不同的人,写 ...
c/s三层结构信息系统的三个层次_如何使用ABP框架（2）三层架构与领域驱动设计的对比...
本文来自长沙.NET技术社区,原创:邹溪源.全文共有8500字,读完需耗时10分钟. 题图来自@pixabay 简述上一篇简述了ABP框架中的一些基础理论,包括ABP前后端项目的分层结构,以及后端项 ...

计算机系统（六）：应用层（上篇）

引言