第 7 章 常用协议简介
本章主要介绍常用的协议 OSI、TCP／IP、HTTP 和 HTTPS。
学习目标：
■ 掌握 OSI 参考模型
■ 掌握 TCP／IP 协议
■ 掌握 HTTP、HTTPS 协议
7.1 OSI 参考模型
OSI（Open System Interconnection）参考模型是 1979 年由国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，一般称为 OSI 参考模型或七层模型，如图 7-1 所示。它是一个七层的、抽象的模型，不仅包括一系列抽象的术语或概念，也包括具体的协议。
图 7-1 OSI 参考模型
在这里简单介绍一下 OSI 的七层模型：
1.物理层（physical layer）
物理层是 OSI 参考模型的第一层，处于最底层，是 OSI 分层结构体系中最重要的一层。它是建立在传输媒介基础上，主要负责两台设备之间真正的数据传输工作，通过比特（bit）进行传输物理接口信息、电气特性等。其主要功能是为数据端设备提供传送数据通路和传输数据。
常见的物理层设备有：网卡、网线、光纤、集线器、中继器、串口等，其典型的协议有 RS232C、RS449／422／423
2.数据链路层（data link layer）
数据链路层是 OSI 参考模型的第二层。数据链路层主要是在不可靠的物理介质上提供可靠的传输。该层主要的作用是对物理地址 mac 寻址，将网络层传输的数据封装为可被物理层接受的帧 frame，流量控制以及负责数据进行检错、重发和修正工作等。
数据链路层的典型设备有：二层交换机、网桥，其典型的协议有：SDLC、HDLC、PPP、STP、帧中继等。
3.网络层（network layer）
网络层是 OSI 参考模型的第三层。其主要任务就是将网络地址 IP 翻译成物理地址，并决定通过哪些路径来实现数据传输。
网络层的主要设备就是路由器或普通交换机，其典型的协议包括：IP、IPX、IGP 等。
4.传输层（transport layer）
传输层是 OSI 参考模型的第四层，也是 OSI 模型中最核心的。主要功能是从会话层接收数据，并把数据传送给网络层。在传输前要确定传输协议，以及对数据进行错误检测，传输中进行流量监控，最终为会话提供可靠的、无误的数据传输。
传输层典型的协议包括：TCP、UDP、SPX 等。
5.会话层（session layer）
传输层是 OSI 参考模型的第五层，它的数据传送单位统称为报文。主要功能是建立应用之间的通信链接，确定是否需要传输。除此之外，它还进行维持会话，并使会话获得同步以及对会话连接的管理、恢复与释放。
6.表示层（presentation layer）
表示层是 OSI 参考模型的第六层，是数据的表现形式（如 ASCII、GB2312、JPG 等）。其主要功能是对数据进行加密、解密以及数据的压缩、解压。除此之外，还对不同的图片和文件格式进行编码和解码。
7.应用层（application layer）
应用层是 OSI 参考模型的第七层，也是 OSI 模型中的最高层。主要功能为应用程序提供服务，来实现用户之间的信息交换。其典型的协议包括：用于 Web 的 HTTP 协议、HTTPS 协议，用于传输文件的 FTP 协议，用于 Email 的 IMAP 以及网络协议 Telnet、SNMP 等。
7.2 TCP／IP 协议
传输控制协议／互联网协议（Transmission Control Protocol／Internet Protocol，简称 TCP／IP）是一个真正的开放系统，它被称作为 Internet 的基础，主要由传输层的 TCP 协议和网络层的 IP 协议组成。TCP／IP 起源于 20 世纪 60 年代末美国政府资助的研究项目，到 20 世纪 90 年代已发展成为计算机之间最常用的组网形式。
TCP／IP 是一组不同层次上的多个协议的组合，它采用了四层协议进行分层，每一层分别负责不同的通信功能，如图 7-2 所示。
1.链路层
链路层，有时也称作数据链路层或网络接口层，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。常见的协议有以太网、IEEE802.2／802.3、SLIP（Serial Line Internet Protocol）串行线路网际协议、HDLC（High-level Data Link Control）点到多点的通用协议、PPP（Point-to-Point Protocol）点到点协议等。
在 TCP／IP 协议族中，链路层主要完成以下 3 个目的：
1）为 IP 模块发送和接收 IP 数据报；
2）为 ARP 模块发送 ARP 请求和接收 ARP 应答；
3）为 RARP 发送 RARP 请求和接收 RARP 应答。
2.网络层
网络层，有时也称作互联网层，它主要处理分组在网络中的活动。在 TCP／IP 协议族中，该层协议包括 IP（Internet Protocol）网际协议、ICMP（Internet Control Message Protocol）控制报文协议、IGMP（Internet Group Management Protocol）组管理协议、ARP（Address Resolution Protocol）地址转换协议、RARP（Reverse ARP）反向地址转换协议。
IP 地址，在互联网上每一个接口必须有一个唯一的 IP 地址，IP 地址长 32bit，这些 32 位的地址通常写成四个十进制的数，其中每个整数对应一个字节。这种表示方法称作「点分十进制表示法（Dotted decimal notation）」。IP 地址具有一定的结构，五类不同的互联网地址格式，如图 7-3 所示。
图 7-3 五类 IP 地址
IP 地址层主要负责接收由链路层发来的数据包，再将数据包发送到传输层；反之也可以把从传输层接收来的数据包传送到链路层。IP 层的数据包是最不可靠的。
3.传输层
传输层主要为两台终端上的应用程序提供端到端的通信。在 TCP／IP 协议族中，有两个互不相同的传输协议：TCP（Transmission Control Protocol）传输控制协议和 UDP（User Dat-agram protocol）用户数据报协议。
1）TCP：是一种端对端的、面向连接的、可靠的、基于字节流的传输层协议。每一次 TCP 在连接建立时需要经过三次握手（three-way handshake）。
TCP 主要用来确认数据包的发送并添加序号机制，对发送的数据包进行校验，从而保证数据包在传输过程中的可靠性；同时还可以测试所接受数据包的完整性，保证数据包不出现丢失或者是次序错乱。
接下来看一下建立连接时三次握手的过程，如图 7-4 所示。
图 7-4 建立连接-三次握手
第一次握手：客户端发送一个 SYN 指明客户端打算连接的服务器的端口，以及初始序号（ISN 随时间而变化）。服务器由 SYN 得知客户端要求建立连接。
第二次握手：服务器在收到建立连接的请求后，给客户端发回包含服务器的初始序号作为应答，同时将客户端的 ISN 加 1 以对 SYN 进行确认请求 ack。
第三次握手：客户端必须进行确认序号，为服务器的 ISN 加 1 以对服务器进行确认。若正确，再次发送确认后的 ISN 与 ack 加 1，服务器收到再次确认后，连接建立成功。
当数据传送完成后，进行释放连接，此时需要经过四次挥手，如图 7-5 所示。
第一次挥手：客户端发送 FIN 和序列，用来关闭从客户端到服务器的数据传送，此时客户端进入等待关闭状态。
第二次挥手：服务器收到客户端发送的 FIN 后，设置客户端序列加 1，用来确认序号，此时服务器进入半关闭状态（服务器需要时间准备）。
第三次挥手：服务器发送 FIN，用来关闭从服务器到客户端的数据传送，此时服务器进入最后的关闭状态（未完全释放，只是关闭了应用程序）。
图 7-5 释放连接-四次挥手
第四次挥手：客户端收到服务器发送的 FIN 后，设置服务器序号加 1，用来确认序号，此时客户端进入等待中断时间，服务器收到确认信息后，完成 TCP 的连接释放。
2）UDP：传输方式与 IP 类似，同样都是以数据包的方式传输。与之不同的是，IP 协议是通过 IP 地址进行传输，没有端口，而 UDP 协议实现了端口。UDP 是一种一对一（一对多的）、无连接的、不可靠的、基于数据包的传输层协议。
由于它是无连接的，所以传输速度很快，如果一方数据包丢失，另一方只能无限等待。通常应用程序使用广播和多播时只能用 UDP 协议。
4.应用层
应用层负责处理特定的应用程序细节，包括的高层协议有：HTTP（Hyper Text Transfer Protocol）超文本传输协议、Telnet（TELecommunications NETwork）虚拟终端协议、FTP（File Transfer Protocol）文件传输协议、SMTP（Simple Mail Transfer Protocol）电子邮件传输协议、DNS（Domain Name Service）域名服务等。
应用层包含了 OSI 参考模拟中应用层、表示层和会话层三层，在 TCP／IP 协议族中，该层将所有与应用层相关的功能整合在一起，通过相关的应用协议，为用户的应用程序提供通信服务。
下面通过应用程序的实例，来进一步了解 TCP／IP 协议的传输过程，如图 7-6 所示。
OSI 参考模型与 TCP／IP 模型的关系，见表 7-1。
表 7-1 OSI 参考模型与 TCP／IP 模型的关系
图 7-6 TCP／IP 传输过程
7.3 HTTP 协议
超文本传输协议（Hyper Text Transfer Protocol，简称 HTTP）是互联网上应用最广泛的一种网络协议，是一种属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。
HTTP 的原型是在 1990 年提出，经过几年的使用和发展，在功能和性能得到了不断的完善和改进，目前在 WWW 中使用最多的是由 RFC2616 定义的 HTTP1.1 版本，HTTP2.0 的建议已经提出，它将成为下一代协议。
7.3.1 HTTP 协议特点
Web 系统的基础就是 HTTP 协议，它是一个基于请求与响应模式的、无状态的、应用层的协议。由于 HTTP 只定义传输的内容是什么，不定义如何传输，所以理解 HTTP，只需理解协议的数据结构及所代表的意义即可。
HTTP 协议的主要特点有以下几点：
1.支持客户／服务器模式
HTTP 最初的设计目标就是通过网络来支持 Client 和 Server 之间的事务处理。简单来讲就是由 HTTP 客户端发起一个请求，建立一个到服务器指定端口（默认是 80 端口）的 TCP 连接。HTTP 服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器将向客户端做出应答。
2.简单快速
客户向服务器请求服务时，只需传送请求方法和路径即可。请求方法常用的有 GET、POST、PUT、DELETE 等，而每种请求方法都规定了不同的类型进行联系，其中 GET 请求的应用最为广泛。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
3.灵活
HTTP 允许传输任意类型的数据对象（ASCII 文本、二进制流等），传输数据的具体类型在 Content-type 域中加以标记。
4.无连接
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后立即断开连接。采用这种方式可以节省传输时间。
5.无记忆状态
无状态是指协议对于事务处理没有记忆能力。一方面，缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，由于服务不需要利用先前信息，从而实现较快应答。
7.3.2 HTTP 连接方式
HTTP 是基于 TCP 的连接方式，建立连接的方式有非持久连接和持久连接，绝大多数的 Web 开发，都是构建在 HTTP 协议之上的 Web 应用。在 HTTP1.0 中使用非持久连接，HTTP1.1 默认使用了持久连接。
1.非持久连接
非持久连接就是每次连接只处理一个请求消息和一个响应消息。具体步骤如下：
1）首先 HTTP 客户端与服务器中的 HTTP 服务器建立一个 TCP 连接。HTTP 服务器通过默认端口号 80 监听来自 HTTP 客户的连接建立请求。
2）HTTP 客户经由与 TCP 连接相关联的本地套接字发出一个 HTTP 请求消息。
3）HTTP 服务器经由与 TCP 连接相关联的本地套接字接收这个请求消息，再从服务器主机的内存或硬盘中取出对象，经由同一个套接字向客户端发出包含该对象的响应消息。
4）HTTP 服务器告知 TCP 关闭这个 TCP 连接（TCP 要等客户收到这个响应消息后，才会真正终止这个连接）。
5）HTTP 客户经由同一个套接字接收这个响应消息，TCP 连接随后终止。
6）给每一个引用的对象，重复上述 1～5 步骤。
客户端和服务器之间每完成一个 HTTP 事务，需要建立一个 TCP 连接来传输报文。也就是说，每次服务器发出一个对象后，相应的 TCP 连接就被关闭，每个连接都不能持续传输其他对象。由于 TCP 的连接具有慢启动的特性，换言之就是使用过的连接会比新建立的连接速度快一些。如果同时处理不同客户发送的请求时，对 web 服务器来说，无疑是严重增加了负担，同样也会造成网络使用效率的降低，这也是非持久连接最大的缺点。
2.持久连接
持久连接是指每个连接可以处理多个请求和响应事务。具体操作如下：
早期的 HTTP 都是持久连接，在 HTTP1.1 版本中持久连接设置为默认行为。也就是说，除非有其他的标识，否则服务器发出响应后 TCP 会连接持续打开，后续的请求和响应都可以通过这个连接进行发送。
HTTP1.1 采用持久连接结合新连接的方式，这种方式尽可能地减少了新建连接的浪费，同时当现有连接没有办法满足需求的时候，可以建立新连接满足需求，比较灵活。
7.3.3 HTTP 报文结构
HTTP 报文有请求报文和响应报文两种，它们都有五个成员组成。
1.请求报文
请求报文是指从客户端到服务器端发送请求，报文结构如下：
● 第一个成员：请求行（Request-Line）；
● 第二个成员：通用头（General-Header）；
● 第三个成员：请求头（Request-Header）；
● 第四个成员：实体头（Entity-Header）；
● 第五个成员：实体主体（Entity-Body）。
请求行以方法字段开始，后面分别是 URL 字段和 HTTP 协议版本字段，并必须以 CRLF 结尾（也就是回车换行），SP 是分隔符（空行）。
2.响应报文
响应报文是指服务器端到客户端的做出应答，报文结构如下：
● 第一个成员：状态行（Status-Line）；
● 第二个成员：通用头（General-Header）；
● 第三个成员：请求头（Request-Header）；
● 第四个成员：实体头（Entity-Header）；
● 第五个成员：实体主体（Entity-Body）。
状态码由 3 位数字组成，表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述，状态码用来支持自动操作，而原因分析用来供用户使用。客户机无须用来检查或显示语法。常见的 HTTP 状态码见表 7-2。
表 7-2 常见的 HTTP 状态码
7.3.4 HTTP 请求
HTTP 请求主要由以下 3 个部分构成：方法-URL-协议／版本、请求头、请求正文。
HTTP1.1 支持 7 种请求方法：GET、POST、HEAD、PUT、DELETE、OPTIONS 和 TRACE。
●GET：请求获取 Request-URI 所标识的资源；
●POST：在 Request-URI 所标识的资源后附加新的数据；
●HEAD：请求获取由 Request-URI 所标识的资源的响应消息报头；
●PUT：请求服务器存储一个资源，并用 Request-URI 作为其标识；
●DELETE：请求服务器删除 Request-URI 所标识的资源；
●OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项和需求；
●TRACE：请求服务器回送收到的请求信息，主要用于测试或诊断。
在互联网应用中，最常用的请求方法是 GET 和 POST。下面主要介绍 GET 和 POST 方法。
1.GET 请求方法，语法如下：
GET 请求就是是从服务器上获取数据，仅获取服务器资源，不对其进行修改。
第一行：GET／HTTP／1.1
其中 GET 就是请求方法；／表示请求的 URI（根目录）；HTTP1.1 是协议和具体版本。URI 完整地指定了要访问的网络资源，URL 实际上是 URI 的一种特殊类型。
第二行：Accept：text／html，application／xaml+xml，image／gif，*／*
Accept 请求头包含许多有关客户端环境和请求正文的有用信息。应具体说明所能接受的内容类型，也就是能在客户浏览器中直接打开的格式。
第三行：Accept-Encoding：gzip，deflate
Accept-Encoding 是指客户端支持服务器返回的 gaip 压缩数据，这样处理可有效地减少网络传输所浪费的时间。比如服务器在传输过程中，会将 HTML、JS、CSS 等类型的资源经过压缩后再传给客户端，客户端收到响应数据后解压缩后进行展示。
第四行：Accept-Language：zh-CN
Accept-Language 是指客户端能接受和处理的语言，此处 zh-CN 显示语言为中文。这也是为什么用户访问 google.com 会自动指派到 google.cn 页面上的原因。如果使用中文的操作系统，一般这个属性值都是 zh-CN。
第五行：Connection：Keep-Alive
该行是 HTTP1.1 预设的功能，当完成本次请求后，它使客户端到服务器端的 TCP 连接仍属于可连接状态，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。
第六行：Host：www.lingting.club
Host 是指请求的主机地址。
第七行：User-Agent：Mozilla／4.0（compatible；MSIE 8.0；Windows NT 6.1；WOW64；Trident／4.0；SLCC2；.NET CLR 2.0.50727；.NET CLR 3.5.30729；.NET CLR 3.0.30729；InfoPath.2；.NET4.0C；.NET4.0E）
User-Agent 表示客户端的信息，对于服务器来说如果没有这个信息它就不知道客户处于什么环境来访问 WWW 服务，所以相关的日志信息记录的就是客户浏览器发送的内容。
第八行：空行
该行非常重要，是只有 CRLF 符号的行，它表示请求头已经结束。
2.POST 请求方法，语法如下：
第一行：POST／login HTTP／1.1
与 GET 请求不同的是，POST 请求可向服务器提交较大的数据，这就涉及了数据的更新，也就是可以更改服务器的数据。POST 请求传递数据无限制，在传递过程中数据存放在 Header 头内，用户看不到这个过程，因此相对 GRT 请求，它的传输过程是安全的。
第二行到第七行的意思可参考 GET 请求，这里就不讲解了。
第八行：Content-Type：application／x-www-form-urlencoded
Content-Type 是指请求的与实体对应的 MIME 信息，属于内容头部，主要是用来向服务器指明报文主体部分内容属于何种类型，以及接收的数据类型。
第九行：Content-Length：120
Content-Length 是指请求发送内容的长度。
第十行：Cache-Control：no-cache
Cache-Control 是指定请求和响应遵循的缓存机制，在请求消息或响应消息中设置 Cache-Control 并不会修改另一个消息处理过程中的缓存处理过程。常见的取值有 Public、Private、no-cache、max-age、no-store 等，默认为 Private。
第十一行：空行
该行非常重要，它表示请求头已经结束。必须也用 CRLF 分隔。
第十二行：username=admin&password=123456
此处表示 POST 请求的正文部分。
7.3.5 HTTP 应答
HTTP 的应答与请求类似，主要由以下 3 个部分构成：协议-状态码-描述、应答头、应答正文。对应上述请求的服务器 HTTP 应答如下：
第一行：HTTP／1.1200 OK
HTTP／1.1 表示当前通信使用的协议及其版本，200 OK 是 HTTP 响应的状态码，表示服务器已经成功处理了客户端发出的请求。
第二行：Server：Apache-tomcat／7.0.63
显示服务器上 Web 服务的名称。
第三行：Content-length：528
Content-Length 是指应答数据的正文部分的长度为 528 字节。
第四行：Content-Type：text／html；charset=utf-8
显示此连接的内容类型为 text／html，字符集是中文。
第五行：Connection：keep-alive
参考 HTTP 请求中的 Connection 内容。
第六行：Expires：0
Expires 用来控制缓存的失效日期，缓存何时过期。
第七行：Cache-control：no-cache
参考 HTTP 请求中的 Cache-control。
第八行：Content-Encoding：gzip
Content-Encoding 是指应答数据采用的压缩格式为 gzip
第九行：Date：Mon，20 May 201813：14：00 GMT
显示当前服务器上的 GMT 格林尼治时间。
第十行：Vary：Accept-Encoding
Vary 是指缓存代理服务器（压缩和非压缩），现在的浏览器都支持压缩了，如果网站启用了 gzip，可以无须指定标头 Vary。
第十一行：空行
该行非常重要，应答头和正文必须也用 CRLF 分隔。
第十二行：正文部分
服务器应答的正文部分（此处略），也就是服务器返回的 HTML 页面，这里返回的内容为动态压缩内容。
7.3.6 HTTP 通信机制
HTTP 通信机制是指完整的一次 HTTP 通信过程（Web 为例），主要经过以下 7 个步骤：
1.建立 TCP 连接
Web 浏览器首先要通过网络与 Web 服务器建立连接，该连接是通过 TCP 来完成的，该协议与 IP 协议共同构建 Internet。HTTP 是比 TCP 更高层次的应用层协议，根据协议规则，通常只有低层协议建立之后，才能进行更高层协议的连接。因此，首先要建立 TCP 连接，一般 TCP 连接的端口号默认是 80。
2.发送请求
一旦建立了 TCP 连接，Web 浏览器就会向 Web 服务器发送请求命令。
3.请求头信息
Web 浏览器发送其请求命令之后，还要以头信息的形式向 Web 服务器发送其他信息，之后浏览器发送空白行来通知服务器，它已经结束了该头信息的发送。
4.服务器应答
客户端向服务器发出请求后，服务器向客户端回送应答，如 HTTP／1.1200 OK。
5.应答头信息
服务器也会跟客户端一样，随同应答向用户发送关于它自身的数据以及被请求的文档。
6.发送应答数据
Web 服务器向 Web 浏览器发送头信息后，也会发送空白行来表示头信息发送结束，接下来，它以 Content-Type 应答头信息所描述的格式发送用户所请求的实际数据。
7.关闭 TCP 连接
一般情况下，一旦 Web 服务器向浏览器发送了请求数据，它就要关闭 TCP 连接。
由于在 HTTP1.1 中预设了「Connection：keep-alive」功能，TCP 连接在发送后将仍然保持打开状态。于是，浏览器可以继续通过相同的连接发送请求。
7.3.7 HTTP 缓存机制
HTTP 缓存是 Web 性能优化的重要手段，使用 HTTP 缓存到底有什么好处呢？
在 HTTP1.1 中缓存的目的是为了减少发送请求，同时可以不需要发送完整响应。前者减少了网络回路的数量，HTTP 利用一个「过期（Expires）」机制来为此目的。后者减少了网络应用的带宽，HTTP 用「验证（Validation）」机制来为此目的。
1.缓存流程
首先我们来看一下 HTTP 的缓存流程，如图 7-7 所示。
图 7-7 HTTP 缓存流程
2.缓存策略
在 HTTP 中缓存的策略主要有缓存存储策略、缓存过期策略和缓存对比测试 3 种。
1）缓存存储策略，用来确定 HTTP 应答内容是否可以被客户端缓存，以及可以被哪些客户端缓存。这个策略的作用只有一个，用于决定 HTTP 应答内容是否可缓存到客户端。
对于 Cache-Control 头里的 Public、Private、no-cache、max-age、no-store 等。它们都是用来指明应答内容是否可以被客户端存储，其中前 4 个都会缓存文件数据。no-store 则不会在客户端缓存任何响应数据。HTTP1.1 中缓存机制默认是 Private，其中 no-cache 和 max-age 比较特殊，它们既包含缓存存储策略也包含缓存过期策略。
2）缓存过期策略，客户端用来确认存储在本地的缓存数据是否已过期，进而决定是否要发请求到服务端获取数据。这个策略的作用也只有一个，那就是决定客户端是否可直接从本地缓存数据中加载数据并展示（否则就发请求到服务端获取）。
Expires 标记告诉浏览器该页面何时过期，并且此过期前不需要再访问 web 服务器，同 max-age 的效果。Cache-Control 中指定的缓存过期策略优先级高于 Expires，当它们同时存在的时候，Expires 会被覆盖掉。
需注意的是缓存数据标记为已过期只是告诉客户端不能再直接从本地读取缓存了，需要再发一次请求到服务器去确认，并不等同于本地缓存数据从此就没用了，有些情况下即使过期了还是会被再次用到。
3）缓存对比策略，它将缓存在客户端的数据标识发往服务端，服务端通过标识来判断客户端缓存数据是否仍有效，进而决定是否要重发数据。客户端检测到数据过期或浏览器刷新后，往往会重新发起 HTTP 请求到服务器，服务器此时并不急于返回数据，而是看请求头有没有带标识（If-Modified-Since、If-None-Match）过来，如果判断标识仍然有效，则返回 304 告诉客户端取本地缓存数据使用即可。
常见 HTTP 缓存头，见表 7-3。
表 7-3 常见 HTTP 缓存头
3.浏览器缓存
缓存就是为了提高访问网页的速度，浏览器会采用累积加速的方法，将历史访问的网页内容（包括图片以及 cookie 文件等）存放在本地，这个存放空间，就称为浏览器缓存，以后我们每次访问网站时，浏览器会首先搜索这个目录，如果其中已经有访问过的内容，那浏览器就不必从网上下载，而直接从缓存中调出来，从而提高了访问网站的速度。
如何生成缓存内容（由服务器生成）在本地？我们需要建立一种机制（web 服务器和缓存之间的一种沟通机制），即为 HTTP 中的「缓存协商」。常见的协商有以下几种：
（1）Last-Modified 和 If-Modified-Since 协商
Last-Modified 和 If-Modified-Since 分别位于响应头信息的请求头信息中，都是记录请求的页面最后的修改时间。在客户端第一次访问 Web 服务器会返回 200 状态，并在浏览器的响应头 Last-Modified 中，记录此页面最后访问的时间，当再次访问时，浏览器会把第一次返回 last-Modified 的时间记录到 If-Modified since，并作为请求头信息发送到服务器，此时 web 服务器会通过 If-Modified-since 上的时间，来判断用户的页面是否是最新的。如果不是最新，则返回新的页面并修改响应头 Last-Modified 时间给用户；如果判断是最新，则返回 304 状态并告诉浏览器本地的 cache 页面是最新的，浏览器可以直接加载本地页面，这样可以减少网络上传输的数据，并且也减少服务器的负担。
（2）ETag 协商
如果把一个文件放在多台 web 服务器上，用户的请求在这些服务器上之间轮询，实现负载均衡，那么这个文件在各台 web 服务器的最后修改时间很可能是不一样，这样用户每次请求到的 web 服务器都可能不同，Last-Modified 和 If-Modified-since 则无法对应，导致每次都需要重新获取内容，这时候采用直接标记内容的 ETag（HASH）算法，就可以避免出现上述的问题。
（3）Expires 缓存过期前不会再发送请求
Expires 标记告诉浏览器该页面何时过期，并且此过期前不需要再访问 web 服务器，直接使用本地的缓存文件即可，这样请求响应头都不需要了，确实节省了带宽和服务器的开销，但是即便页面在 web 服务器上更新后，在 Expires 过期前也不会出现在用户面前。
Expires 表示存在时间，允许客户端在这个时间之前不去检查（发请求），等同 max-age 的效果。但是如果同时存在，则被 Cache-Control 的 max-age 覆盖。
（4）Last-Modified、ETag、Expires 混合
通常 Last-Modified、ETag、Expires 是混合使用的，特别是 Last-Modified 和 Expires 经常一起使用，因为 Expire 可以让浏览器完全不发起 HTTP 请求，而当浏览器强制刷新的时候又有 Last-Modified，这样就很好地达到了浏览器段缓存的效果。
Etag 和 Expires 一起使用时，先判断 Expires，如果已经过期，再发起 HTTP 请求，如果 Etag 也过期，则返回 200 响应。如果 ETag 没有过期则返回 304 响应。
Last-Modified、ETag、Expires 三个同时使用时。先判断 Expires，然后发送 HTTP 请求，服务器先判断 Last-Modified，再判断 ETag 必须都没有过期，才能返回 304 响应。
7.4 HTTPS 协议
由于 HTTP 本身不具备加密的功能，即 HTTP 报文使用明文方式发送；又由于 HTTP 本身对通信方的身份也没有进行验证，这样会导致即便加密了，信息仍然可能会在传输中被窃听。为了弥补 HTTP 的这些缺点，在 1994 年，创建了安全超文本传输协议（Hyper Text Transfer Protocol over Secure Socket Layer，简称 HTTPS），它是由 Netscape 开发并内置于其浏览器中，用于对数据进行加密和解密操作，简单讲就是 HTTP 的安全版。
它是通过 HTTP 和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Se-curity，安全传输层）的组合使用，对 HTTP 通信内容进行加密。它的主要作用可以分为两方面，一方面是建立一个信息安全通道，利用加密和验证身份来保证数据传输的安全；另一方面就是确认网站的真实性，可以通过 CA 机构颁发的安全签章来查询网站认证之后的真实信息。HTTPS 默认端口为 443。
7.4.1 HTTPS 的特点
在目前的技术背景下，HTTPS 是现行架构下最安全的解决方案。它主要体现在可以对客户端和服务器进行认证，确保数据发送到正确的客户机和服务器；同时通过 SSL 协议进行加密传输，确保数据在传输过程中不被窃听、篡改，确保数据的完整性。
HTTPS 在安全方面表现较为突出，它在技术与成本方面表现不是很好。技术方面体现在相同网络环境下，HTTPS 协议会使页面的加载时间延长近 50％；此外还会影响缓存。成本方面体现在，由于 SSL 证书需要购买，还需要绑定固定 IP，所以增加了一定的费用；同时 HTTPS 连接服务器资源占用比较高，这样又增加企业对服务器配置的费用。
7.4.2 工作原理
1）客户端发送报文开始 SSL 通信，报文包含 SSL 的指定版本、加密算法列表和一个用作产生密钥的随机数发送给服务器。
2）服务器进行 SSL 通信时，首先从客户端发送的算法列表中选择一种加密算法，并和一份包含服务器公用密钥的证书，发送给客户端。
3）服务器给客户端在发送一个服务器用作产生密钥的随机数。
4）服务器和客户端建立 SSL 握手协商。
5）客户端对服务器的证书进行验证，再产生一种被称作 pre master secret 的随机密码串，并抽取服务器的公用密钥进行加密，再将加密后的报文发送给服务器。
6）客户端与服务器根据 pre master secret 以及客户端与服务器的随机数值，独立计算出加密和 MAC 密钥。
7）客户端将所有报文消息的 MAC（Message Authentication Code）发送给服务器。
8）服务器将所有报文消息的 MAC 发送给客户端。
9）服务器和客户端的报文交换完毕后，SSL 连接才算建立完成。
10）开始进行应用协议的通信，客户端发送 HTTP 请求，服务器返回 HTTP 响应。
11）最后，由客户端断开连接。
7.4.3 SSL 协议
SSL（Secure Sockets Layer）安全套接层是 Netscape 公司提出的基于 WEB 应用的安全协议。主要用来保障在 Internet 上数据传输之安全，利用数据加密（Encryption）技术，确保数据在网络传输过程中不会被截取及窃听。一般通用规格为 40 bit 安全标准，美国则已推出 128 bit 更高的安全标准，但限制出境。只要 3.0 版本以上之 IE 或 Netscape 浏览器即可支持 SSL。
SSL 协议位于 TCP／IP 协议与各种应用层协议（如 HTTP、Telenet、FTP 等）之间，主要是提供数据安全性分层的机制。
SSL 协议可分为两层：一层是 SSL 记录协议（SSL Record Protocol），它是建立在可靠的传输协议（如 TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。另一层是 SSL 握手协议（SSL Handshake Protocol），它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通信双方进行身份认证、协商加密算法、交换加密密钥等。
（1）SSL 记录协议
SSL 记录协议是通过将数据流分割成一系列的片段，并加以传输，其中的每个片段都单独进行保护和传输。
在传输数据片段之前，需要计算数据的 MAC 以保证数据的完整性，再将数据片段和 MAC 一起被加密并与头信息组成记录（实际传输的内容）。
SSL 记录协议为每一个 SSL 连接提供以下两种服务。
● 机密性：SSL 记录协议会协助双方产生一把共享密钥，利用这把密钥来对 SSL 所传送的数据做传统式加密。
● 完整性：SSL 记录协议会协助双方产生另一把共享 MAC 密钥，利用这把密钥来计算出消息的鉴别码。
（2）SSL 握手协议
SSL 握手协议是指在 SSL 协议中，首先客户端和服务器通过握手过程来获得密钥，随后在记录协议中，使用该密钥来加密客户端和服务器间的通信信息。
握手过程首先采用非对称加密的方法来交换信息，使得服务器获得客户端提供的对称加密的密钥（pre master secret），然后服务器和客户端通过密钥产生会话密钥。
SSL 握手协议为每一个 SSL 连接提供以下两种服务。
● 安全性：SSL 握手协议通过证书对客户端和服务器进行认证。
● 正确性：SSL 握手协议再通过交换密钥来确保数据发送到正确的客户端和服务器。
7.4.4 TLS 协议
TLS（Transport Layer Security）安全传输层是 IETF（The Internet Engineering Task Force，国际互联网工程任务组）在 1999 年把 SSL 标准化后，将 SSL 名称改为 TLS。该协议继承了 SSL 协议的功能，主要用于两个通信应用程序之间提供保密性和数据完整性。该协议也是由两层组成，分别是 TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（如 TCP）上面，与具体的应用无关。所以，通常把 TLS 协议归为传输层安全协议。
TLS 的最大优势是独立于应用协议。高层协议可以明确地分布在 TLS 协议上面。然而，TLS 标准并没有规定应用程序如何在 TLS 上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。
TLS 包含三个基本阶段：
1）对等协商支援的密钥算法。
2）基于私钥加密交换公钥、基于 PKI 证书的身份认证。
3）基于公钥加密的数据传输保密。