计算机网络6——应用层3万维网1

一、概述

万维网 www (World Wide Web)是一个大规模的、联机式的信息储藏所，英文简称为Web，而不是什么特殊的计算机网络。万维网用链接的方法能非常方便地从互联网上的一个站点访问另一个站点(也就是所谓的“链接到另一个站点”)，从而主动地按需获取丰富的信息。下图说明了万维网提供分布式服务的特点。

上图画出了四个万维网上的站点，它们可以相隔数千公里，但都必须连接在互联网上。每个万维网站点都存放了许多文档。在这些文档中有一些地方的文字是用特殊方式显示的(例如用不同的颜色，或添加了下划线)，而当我们将鼠标移动到这些地方时，鼠标的箭头就变成了一只手的形状。这就表明这些地方有一个链接(link)(这种链接有时也称为超链hyperlink)，如果我们在这些地方点击鼠标左键，就可从这个文档链接到可能相隔很远的另一个文档。经过一定的时延(几秒钟、几分钟甚至更长，取决于所链接的文档的大小和网络的拥塞情况)，在我们的屏幕上就能将远方传送过来的文档显示出来。

正是由于万维网的出现，使计算机的操作发生了革命性的变化。不必在键盘上输入复杂而难以记忆的命令，而改用鼠标点击一下屏幕上的链接，这就使互联网从仅由少数计算机专家使用变为普通百姓也能利用的信息资源。万维网的出现使网站数按指数规律增长，因而成为互联网发展中的一个非常重要的里程碑。

万维网是欧洲粒子物理实验室的Tim Berners-Lee最初于1989年3月提出的。1993年2月，第一个图形界面的浏览器(browser)开发成功，名字叫作Mosaic。1995年著名的Netscape Navigator 浏览器上市。目前流行的浏览器很多，如微软公司的 Intemmet Explorer(简称 IE)，谷歌公司的 Chrome 浏览器，腾讯公司的 QQ 浏览器，苹果公司的 Safari 浏览器，等等。

万维网是一个分布式的超媒体(hypermedia)系统，它是超文本(hypertext)系统的扩充。所谓超文本是指包含指向其他文档的链接的文本(text)。也就是说，一个超文本由多个信息源链接成，而这些信息源可以分布在世界各地，并且数目也是不受限制的。利用一个链接可使用户找到远在异地的另一个文档，而这又可链接到其他的文档(依此类推)。这些文档可以位于世界上任何一个接在互联网上的超文本系统中。超文本是万维网的基础。

超媒体与超文本的区别是文档内容不同。超文本文档仅包含文本信息，而超媒体文档还包含其他表示方式的信息，如图形、图像、声音、动画以及视频图像等。

分布式的和非分布式的超媒体系统有很大区别。在非分布式系统中，各种信息都驻留在单个计算机的磁盘中。由于各种文档都可从本地获得，因此这些文档之间的链接可进行一致性检查。所以，一个非分布式超媒体系统能够保证所有的链接都是有效的和一致的。

万维网把大量信息分布在整个互联网上。每台主机上的文档都独立进行管理。对这些文档的增加、修改、删除或重新命名都不需要(实际上也不可能)通知到互联网上成千上万的节点。这样，万维网文档之间的链接就经常会不一致。例如，主机A上的文档X本来包含了一个指向主机B上的文档Y的链接。若主机B的管理员在某日删除了文档Y，那么主机A的上述链接显然就失效了(但是B并没有责任必须通知A)。

万维网以客户服务器方式工作。上面所说的浏览器就是在用户主机上的万维网客户程序。万维网文档所驻留的主机则运行服务器程序，因此这台主机也称为万维网服务器。客户程序向服务器程序发出请求，服务器程序向客户程序送回客户所要的万维网文档。在一个客户程序主窗口上显示出的万维网文档称为页面(page)。

从以上所述可以看出，万维网必须解决以下几个问题:

1. 怎样标志分布在整个互联网上的万维网文档?
2. 用什么样的协议来实现万维网上的各种链接?
3. 怎样使不同作者创作的不同风格的万维网文档，都能在互联网上的各种主机上显示出来，同时使用户清楚地知道在什么地方存在着链接?
4. 怎样使用户能够很方便地找到所需的信息?

为了解决第一个问题，万维网使用统一资源定位符 URL(Uniform Resource Locator)来标志万维网上的各种文档，并使每一个文档在整个互联网的范围内具有唯一的标识符URL。为了解决上述的第二个问题，就要使万维网客户程序与万维网服务器程序之间的交互遵守严格的协议，这就是超文本传送协议 HTTP(HyperText Transfer Protocol)。HTTP 是一个应用层协议，它使用 TCP连接进行可靠的传送。为了解决上述的第三个问题，万维网使用超文本标记语言 HTML (HyperText Markup Language)，使得万维网页面的设计者可以很方便地用链接从本页面的某处链接到互联网上的任何一个万维网页面，并且能够在自己的主机屏幕上将这些页面显示出来。最后，用户可使用搜索工具在万维网上方便地查找所需的信息。下面我们将进一步讨论上述重要概念。

二、统一资源定位符URL

1、URL的格式

统一资源定位符 URL是用来表示从互联网上得到的资源位置和访问这些资源的方法。URL 给资源的位置提供一种抽象的识别方法，并用这种方法给资源定位。只要能够对资源定位，系统就可以对资源进行各种操作，如存取、更新、替换和查找其属性。由此可见，URL 实际上就是在互联网上的资源的地址。只有知道了这个资源在互联网上的什么地方,才能对它进行操作。显然，互联网上的所有资源，都有一个唯一确定的URL。

这里所说的“资源”是指在互联网上可以被访问的任何对象，包括文件目录、文件、文档、图像、声音等，以及与互联网相连的任何形式的数据。

URL相当于一个文件名在网络范围的扩展。因此，URL是与互联网相连的机器上的任何可访问对象的一个指针。由于访问不同对象所使用的协议不同，所以URL还指出读取某个对象时所使用的协议。URL的一般形式由以下四个部分组成:

URL 最左边的协议指出使用何种协议来获取该万维网文档。现在最常用的协议就是http(超文本传送协议 HTTP)，其次是p(文件传送协议FTP)。在协议后面的“😕/”是规定的格式，必须写上。

主机名是万维网文档所存放的主机的域名，通常以www 开头，但这并不是硬性规定。主机名用点分十进制的IP地址代替也是可以的。

主机名后面的“:端口”就是端口号，但经常被省略掉。这是因为这个端口号通常就是协议的默认端口号(例如，协议HTTP的默认端口号为80)，因此就可以省略。但如不使用默认端口号，那么就必须写明现在所使用的端口号。

最后的路径可能是较长的字符串(其中还可包括若干斜线)，但有时也不需要使用。在路径后面可能还有一些选项，这里不进行介绍了。

现在有些浏览器为了方便用户，在输入URL时，可以把最前面的“http://”甚至把主机名最前面的“www”省略，然后浏览器替用户把省略的字符添上。例如，用户只要键入ctrip.com，浏览器就自动把未键入的字符补齐，变成http://www.ctrip.com。
下面我们简单介绍使用得最多的一种 URL，即协议 HTTP。

三、超文本传输协议HTTP

1、介绍

使用协议 HTTP 的 URL 最常用的形式是把“:端口”省略:

若再将 URL 中的路径省略，则 URL就指明互联网上的某个主页(home page)。主页是个很重要的概念，它可以是以下几种情况之一：

1. 一个 WWW 服务器的最高级别的页面。
2. 某一个组织或部门的一个定制的页面或目录。从这样的页面可链接到互联网上的与本组织或部门有关的其他站点。
3. 由某一个人自己设计的描述他本人情况的 WWW 页面。

例如，要查有关清华大学的信息，就可先进入到清华大学的主页，清华地址

这里省略了默认的端口号80。我们从清华大学的主页入手，就可以通过许多不同的链接找到所要查找的各种有关清华大学各个部门的信息。

更复杂一些的路径是指向层次结构的从属页面。例如:

是清华大学的“院系设置”页面的 URL。注意：上面的 URL 中使用了指向文件的路径，而文件名就是最后的 index.htm。后缀 htm(有时可写为 html)表示这是一个用超文本标记语言 HTML 写出的文件。
URL 的“协议”和“主机名”部分，字母不区分大小写。但“路径”中的字符有时要区分大小写。

用户使用 URL 并非仅仅能够访问万维网的页面，而且还能够通过 URL 使用其他的互联网应用程序，如 FTP或 USENET 新闻组等。更重要的是，用户在使用这些应用程序时，只使用一个程序，即浏览器。这显然是非常方便的。

2、HTTP 的操作过程

协议 HTTP定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。从层次的角度看，HTTP是面向事务的(transaction-oriented)"应用层协议，它是万维网上能够可靠地交换文件(包括文本、声音、图像等各种多媒体文件)的重要基础。请注意，协议HTTP不仅传送完成超文本跳转所必需的信息，而且也传送任何可从互联网上得到的信息，如文本、超文本、声音和图像等

万维网的大致工作过程如下图所示。

每个万维网网点都有一个服务器进程，它不断地监听TCP的端口80，以便发现是否有浏览器(即万维网客户。请注意，浏览器和万维网客户是同义词)向它发出连接建立请求。一旦监听到连接建立请求并建立了TCP连接之后，浏览器就向万维网服务器发出浏览某个页面的请求，服务器接着就返回所请求的页面作为响应。服务器在完成任务后，TCP连接就被释放了。在浏览器和服务器之间的请求和响应的交互，必须按照规定的格式和遵循一定的规则。这些格式和规则就是超文本传送协议HTTP。

HTTP规定在HTTP客户与 HTTP服务器之间的每次交互，都由一个ASCI 码串构成的请求和一个类似的通用互联网扩充，即“类MIME(MIME-like)”的响应组成。HTTP 报文通常都使用 TCP 连接传送。

用户浏览页面的方法有两种。一种方法是在浏览器的地址窗口中键入所要找的页面的URL。另一种方法是在某一个页面中用鼠标点击一个可选部分，这时浏览器会自动在互联网
上找到所要链接的页面。

HTTP使用了面向连接的TCP作为运输层协议，保证了数据的可靠传输。HTTP不必考虑数据在传输过程中被丢弃后又怎样被重传。但是，协议HTTP本身是无连接的。这就是说虽然 HTTP使用了 TCP连接，但通信的双方在交换 HTTP 报文之前不需要先建立 HTTP 连接。在1997年以前使用的是协议HTTP/1.0TRFC1945]。现在普遍使用的升级版本是建议标准 HTTP/1.1[RFC 7231]。2015 年以后，又有了新的建议标准 HTTP/2「RFC 7540]，以及压缩 HTTP 报文首部的建议标准TRFC 75411。

协议 HTTP是无状态的(stateless)。也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时的相同(假定现在服务器还没有把该页面更新)因为服务器并不记得曾经访问过的这个客户，也不记得为该客户曾经服务过多少次。HTTP的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。

下面我们粗略估算一下，从浏览器请求一个万维网文档到收到整个文档所需的时间(如下图所示)。用户在点击鼠标链接某个万维网文档时，协议HTTP首先要和服务器建立TCP连接。这需要使用三报文握手。当建立TCP 连接的三报文握手的前两个报文完成后(即经过了一个RTT 时间后)，万维网客户就把HTTP请求报文，作为建立TCP连接的三报文握手中的第三个报文的数据，发送给万维网服务器。服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。

从上图可看出，请求一个万维网文档所需的时间是该文档的传输时间(与文档大小成正比)加上两倍往返时间RTT(一个RTT用于连接TCP连接，另一个RTT用于请求和接收万维网文档。TCP建立连接的三报文握手的第三个报文段中的数据，就是客户对万维网文档的请求报文)。

协议 HTTP/1.0的主要缺点，就是每请求一个文档就要有两倍RTT的开销。若一个主页上有很多链接的对象(如图片等)需要依次进行链接，那么每一次链接下载都导致2xRTT的开销。另一种开销就是万维网客户和服务器每一次建立新的TCP连接都要分配缓存和变量。特别是万维网服务器往往要同时服务于大量客户的请求，所以这种非持续连接会使万维网服务器的负担很重。好在浏览器都能够打开5~10个并行的TCP连接，而每一个TCP连接处理客户的一个请求。因此，使用并行TCP连接可以缩短响应时间。

协议 HTTP/1.1较好地解决了这个问题，它使用了持续连接(persistent connection)。所谓持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这并不局限于传送同一个页面上链接的文档，而是只要这些文档都在同一个服务器上就行。协议HTTP/1.1 的持续连接有两种工作方式，即非流水线方式(without pipelining)和流水线方式
(with pipelining).

• 非流水线方式的特点，是客户在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个往返时间RTT。这比非持续连接要用去两倍 RTT 的开销，节省了建立 TCP连接所需的一个 RTT 时间。但非流水线方式还是有缺点的因为服务器在发送完一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。
• 流水线方式的特点，是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后，服务器就可连续发回响应报文。因此，使用流水线方式时，客户访问所有的对象只需花费一个RTT时间。流水线工作方式使TCP连接中的空闲时间减少，提高了下载文档效率。

最初网页是以文本为主，但很快发展到使用大量的图片、音频和视频，并且对页面的实时性要求也越来越高(如视频聊天或直播)，这样就使得协议HTTP/1.1已无法跟上互联网的发展了。于是谷歌公司在 2009年开发了软件SPDY，用来提高协议HTTP/1.1的工作效率。IETF在此基础上与谷歌合作完成了协议HTTP/2，而谷歌也停止了对SPDY的继续完善工作。

协议HTTP/2是协议HTTP/1.1的升级版本，其 HTTP 方法/状态码/语义等都没有改变其主要特点如下:

• 我们知道，HTTP/1.1具有流水线的工作方式。这就是在 TCP连接建立后，客户可以连续向服务器发出许多个请求，而不必等到收到一个响应后再发送下一个请求。但服务器发回响应时必须按先后顺序排队，逐个地发送给客户。有时遇到某个响应迟迟不能发回，那么排在后面的一些响应就必须等待很长的时间。HTTP/2 把服务器发回的响应变成可以并行地发回(使用同一个 TCP 连接)，这就大大缩短了服务器的响应时间。
• 使用HTTP/1.1时，当客户收到服务器发回的响应后，原来建立的TCP连接就释放了。如果客户还要继续向该服务器发送新的请求，就必须重新建立TCP连接。HTTP/2允许客户复用TCP连接进行多个请求，这样就节省了TCP连续多次建立和释放连接所花费的时间。
• HTTP/1.1的请求和响应报文是面向文本的(text-oriented)。当客户连续发送请求并受到响应时，在TCP连接上传送的 HTTP 报文首部成为不小的开销。在这些首部中有很多字段是重复的。为此，HTTP/2把所有的报文都划分为许多较小的二进制编码的帧，并采用了新的压缩算法，不发送重复的首部字段，大大减小了首部的开销，提高了传输效率。

因此，现在主流的浏览器都支持HTTP/2。但是，有的服务器还未来得及更新，仍然只支持 HTTP/1.1。但 HTTP/2 是向后兼容的。当使用 HTTP/2 的客户向服务器发出请求时，如果服务器仍然使用HTTP/1.1，那么服务器仍然可以收到请求报文。在发回响应后，客户就改用HTTP/1.1与服务器进行交互。

3、代理服务器

代理服务器(proxy server)是一种网络实体，它又称为万维网高速缓存(Web cache)。代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时，若代理服务器发现这个请求与暂时存放的请求相同，就返回暂存的响应，而不需要按URL的地址再次去互联网访问该资源。代理服务器可在客户端或服务器端工作，也可在中间系统上工作。下面我们用例子说明它的作用。

设图(a)是校园网不使用代理服务器的情况。这时，校园网中所有的计算机都通过 2Mbit/s专线链路(R-R,)与互联网上的源点服务器建立 TCP连接。因而校园网各计算机访问互联网的通信量往往会使这条2Mbits的链路过载，使得时延大大增加。
图0(b)是校园网使用代理服务器的情况。这时，访问互联网的过程是这样的:

• 校园网的计算机中的浏览器向互联网的服务器请求服务时，就先和校园网的代理服务器建立 TCP连接，并向代理服务器发出HTTP请求报文(见图6-10(b)中的1)。
• 若代理服务器已经存放了所请求的对象，代理服务器就把这个对象放入HTTP 响应报文中返回给计算机的浏览器。
• 否则，代理服务器就代表发出请求的用户浏览器，与互联网上的源点服务器(originserver)建立TCP连接(如图6-10(b)中的2所示)，并发送 HTTP 请求报文。
• 源点服务器把所请求的对象放在 HTTP 响应报文中返回给校园网的代理服务器。
• 代理服务器收到这个对象后，先复制在自己的本地存储器中(留待以后用)，然后再把这个对象放在 HTTP 响应报文中，通过已建立的TCP连接(见图(b)中的1)，返回给请求该对象的浏览器。

我们注意到，代理服务器有时是作为服务器(当接受浏览器的HTTP请求时)，但有时却作为客户(当向互联网上的源点服务器发送HTTP请求时)。

在使用代理服务器的情况下，由于有相当大一部分通信量局限在校园网的内部，因此
2 Mbit/s专线链路(R-R,)上的通信量大大减少，因而减小了访问互联网的时延。

以代理服务器方式构成的内容分发网络CDN(Content Distribution Network)在互联网应用中起到了很大的作用。最先使用CDN 技术的是美国的Akamai(阿卡迈)公司。Akamai公司现在是全球最大的CDN平台，是全球能够提供最大规模分发在线视频的服务商。目前Akamai 公司拥有 24万台服务器，3900个位置节点，使全球的用户可以就近下载视频、音频节目，或进行其他业务联系，而用户甚至根本不知道已经使用了Akamai提供的服务。现在 Akamai与全球多家电信运营商建立了深度合作关系，所提供的通信流量高达每秒 40 TB,业务遍及137个国家和地区。

4、HTTP 的报文结构

HTTP 有两类报文:

• 请求报文–从客户向服务器发送请求报文，如图(a)所示。
• 响应报文–从服务器到客户的回答，如图(b)所示。

由于HTTP是面向文本的，因此在报文中的每一个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。

HTTP请求报文和响应报文都是由三个部分组成的。可以看出，这两种报文格式的区别就是开始行不同。

• 开始行，用于区分是请求报文还是响应报文。在请求报文中的开始行叫作请求行(Request-Line)，而在响应报文中的开始行叫作状态行(Status-Line)。在开始行的三个字段之间都以空格分隔开，最后的“CR”和“LF”分别代表“回车”和“换行”。
• 首部行，用来说明浏览器、服务器或报文主体的一些信息。首部可以有好几行，但也可以不使用。在每一个首部行中都有首部字段名和它的值，每一行在结束的地方都要有“回车”和“换行”。整个首部行结束时，还有一空行将首部行和后面的实体主体分开。
• 实体主体(entity body)，在请求报文中一般都不用这个字段，而在响应报文中也可能没有这个字段。

请求报文

下面先介绍HTTP请求报文的一些主要特点。

请求报文的第一行“请求行”只有三个内容，即方法、请求资源的URL，以及HTTP的版本。

请注意:这里的名词“方法”(method)是面向对象技术中使用的专门名词。所谓“方法就是对所请求的对象进行的操作，这些方法实际上也就是一些命令。因此，请求报文的类型是由它所采用的方法决定的。下表给出了请求报文中常用的几种方法。

下面是HTTP的请求报文的开始行(即请求行)的格式。请注意，在GET后面有一个空格，接着是某个完整的URL，其后面又有一个空格，最后是HTTP/1.1。

在请求行使用了相对URL(即省略了主机的域名)是因为下面的首部行(第2行)给出了主机的域名。第3行是告诉服务器不使用持续连接，表示浏览器希望服务器在传送完所请求的对象后即关闭TCP连接。这个请求报文没有实体主体。

响应报文

每一个请求报文发出后，都能收到一个响应报文。响应报文的第一行就是状态行

状态行包括三项内容，即 HTTP的版本、状态码，以及解释状态码的简单短语。

状态码(Status-Code)都是三位数字的，分为5大类，原先有 33 种[RFC 2616]，后来又增加了几种[RFC 6585，建议标准1。这5大类的状态码都是以不同的数字开头的。

• 1xx表示通知信息，如请求收到了或正在进行处理，
• 2xx 表示成功，如接受或知道了。
• 3xx表示重定向，如要完成请求还必须采取进一步的行动。
• 4xx 表示客户的差错，如请求中有错误的语法或不能完成。
• 5xx 表示服务器的差错，如服务器失效无法完成请求。

下面三种状态行在响应报文中是经常见到的。

若请求的网页从 htp://www.ee.xyz.edu/index.html 转移到了一个新的地址，则响应报文的状态行和一个首部行就是下面的形式:

5、在服务器上存放用户的信息

在本节(6.4.3节)第1小节“HTTP 的操作过程”中已经讲过，HTTP是无状态的。这样做虽然简化了服务器的设计，但在实际工作中，一些万维网站点却常常希望能够识别用户例如，在网上购物时，一个顾客要购买多种物品。当他把选好的一件物品放入“购物车”后,他还要继续浏览和选购其他物品。因此，服务器需要记住用户的身份，使他接着选购的一些物品能够放入同一个“购物车”中，这样就便于集中结账。有时某些万维网站点也可能想限制某些用户的访问。

要做到这点，可以在HTTP中使用Cookie。在RFC6265中对Cookie进行了定义，规定万维网站点可以使用Cookie 来跟踪用户。Cookie 原意是“小甜饼”(广东人用方言音译为“曲奇”)，目前尚无标准译名，在这里Cookie表示在HTTP服务器和客户之间传递的状态信息。现在很多网站都已广泛使用Cookie。

Cookie是这样工作的:当用户A浏览某个使用Cookie的网站时，该网站的服务器就头A产生一个唯一的识别码，并以此作为索引在服务器的后端数据库中产生一个项目。接着在给A的HTTP响应报文中添加一个叫作Set-cookie 的首部行。这里的“首部字段名”就是“Set-cookie”，而后面的“值”就是赋予该用户的“识别码”。例如这个首部行是这样的:

当A收到这个响应时，其浏览器就在它管理的特定Cookie文件中添加一行，其中包括这个服务器的主机名和 Set-cookie 后面给出的识别码。当A继续浏览这个网站时，每发送一个HTTP请求报文，其浏览器就会从其Cookie文件中取出这个网站的识别码，并放到HTTP请求报文的Cookie 首部行中:

于是，这个网站就能够跟踪用户31d4d96e407aad42(用户A)在该网站的活动。需要注意的是，服务器并不需要知道这个用户的真实姓名以及其他的信息。但服务器能够知道用户 31d4d96e407aad42在什么时间访问了哪些页面，以及访问这些页面的顺序。如果A是在网上购物，那么这个服务器可以为A维护一个所购物品的列表，使A在结束这次购物时可以一起付费。

如果A在几天后再次访问这个网站，那么他的浏览器会在其HTTP请求报文中继续使用首部行 Cookie:31d4d96e407aad42，而这个网站服务器根据A过去的访问记录可以向他推荐商品。如果A已经在该网站登记过和使用过信用卡付费，那么这个网站就已经保存了 A的姓名、电子邮件地址、信用卡号码等信息。这样，当A继续在该网站购物时，只要还使用同一个计算机上网，由于浏览器产生的HTTP请求报文中都携带了同样的Cookie首部行，服务器就可利用Cookie来验证出这是用户A，因此以后A在这个网站购物时就不必重新在键盘上输入姓名、信用卡号码等信息。这对顾客显然是很方便的。

尽管 Cookie 能够简化用户网上购物的过程，但 Cookie 的使用一直引起很多争议。有人认为 Cookie 会把计算机病毒带到用户的计算机中。其实这是对 Cookie 的误解。Cookie 只是一个小小的文本文件，不是计算机的可执行程序，因此不可能传播计算机病毒，也不可能用来获取用户计算机硬盘中的信息。

对于Cookie的另一个争议，是关于用户隐私的保护问题例如，网站服务器知道了 A的一些信息，就有可能把这些信息出卖给第三方。Cookie 还可用来收集用户在万维网网站上的行为。这些都属于用户个人的隐私。有些网站为了使顾客放心，就公开声明他们会保护顾客的隐私，绝对不会把顾客的识别码或个人信息出售或转移给其他厂商。

为了让用户有拒绝接受 Cookie 的自由，在浏览器中用户可自行设置接受 Cookie 的条件例如在浏览器 IE 11.0中，选择工具栏中的“工具”→“Intemet选项”一“隐私”命令，就可以看见菜单中的左边有一个可上下滑动的标尺，它有六个位置。最高的位置是阻止所有Cookie，而最低的位置是接受所有Cookie。中间的位置则是在不同条件下可以接受Cookie用户可根据自己的情况对E浏览器进行必要的设置。