@[toc]
# 1. IP协议、TCP协议和DNS服务在使用HTTP协议通信过程中各自发挥作用@[toc]
客户端任务：hei！我想浏览http://hackr.jp/xss/ Web页面
首先他就访问DNS服务器，客户端表示：ei，DNS，我想知道hackr.jp的地址，告诉我呗~
DNS服务器回答：ummm，hackr.jp对应的IP地址是20X.189.105.112撒~
客户端我有了IP地址了嘿！那我就用HTTP协议问吧~我用HTTP协议生成对应的HTTP请求报文，然后把这个把这个报文交给TCP，TCP就把我的HTTP报文分段了害，毕竟我的报文有点长，还给我加了点头部保证我的可靠性。
之后就把TCP报文交给IP层，根据IP协议，路由选择，转发我的报文到对方目的地址，到对方的TCP以后，就把收到的报文在组合成原来的嘿，我又恢复了~~，然后捏，HTTP协议就把我的请求告诉服务器，服务器就知道我是想要/xss/欸。
2. 绝对URI@[toc]
格式：http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1
http:协议方案名（诶哟，就是用什么协议）
user:pass:登录信息（认证撒）
www.example.jp：服务器的地址，使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似 hackr.jp 这种 DNS 可解析的名称，或是 192.168.1.1 这类 IPv4 地址 名，还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的 IPv6 地址名。
80：服务器端口号
/dir/index.htm：带层次的文件路径
uid=1：查询字符串
ch1：片段标识符
@[3. 请求报文格式]
报文首部：请求行、请求首部字段、普通首部字段、实体首部字段、其他
空行
报文主体
| 方法 | URI | 协议版本 |
| POST | /from/entry | HTTP 1.1 |
| 请求首部字段 | ||
| Host：hackr.jp Connection：keep-alive Content-Type：application/... Content-Length：16 | ||
| 空行 | ||
| 内容实体 | ||
| name=ueno&age=37 | ||
@[4. 响应报文格式]
报文首部：响应状态、响应首部字段、普通首部字段、实体首部字段
空行
报文主体
| 协议版本 | 状态码 | 状态码的原因短语 |
| HTTP/1.1 | 200 | OK |
| 响应首部字段 | ||
| Date：Tue，10 Jul 2013 Content-Length：362 Content-Type：text/html | ||
| 空行 | ||
| 主体 | ||
| <html> ... | ||
5. HTTP是不保存状态的协议
艾玛，其实就是说，HTTP不保存已经发送过的请求和响应，就比如说我上次发了，但是我不记得上次你给我发了啥。使用 HTTP 协议，每当有新的请求发送时，就会有对应的新响应产 生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了 更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设 计成如此简单的。
6. 方法
GET ：获取资源
GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器 端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保 持原样返回；如果是像 CGI（Common Gateway Interface，通用网关接 口）那样的程序，则返回经过执行后的输出结果。
POST：传输实体主体
POST 方法用来传输实体的主体。 虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行 传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。
PUT：传输文件
PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请 求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以 上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。
HEAD：获得报文首部
HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。
DELETE：删除文件
DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按 请求 URI 删除指定的资源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机 制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用 程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。
OPTIONS：询问支持的方法
OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。
TRACE：追踪路径
TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方 法。 发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服 务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最 后接收到请求的服务器端则返回状态码 200 OK 的响应。 客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改 / 篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理 中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。 但是，TRACE 方法本来就不怎么常用，再加上它容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。
CONNECT：要求用隧道协议连接代理
CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协 议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容 加 密后经网络隧道传输。
CONNECT 方法的格式如下所示。
CONNECT 代理服务器名:端口号 HTTP版本
6. 短连接
HTTP1.0协议使用短链接，也就是说每一次HTTP请求响应都要进行一次TCP连接和释放。
7. 长连接
HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是，只要任意一端 没有明确提出断开连接，则保持 TCP 连接状态。
持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额 外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使 HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相 应提高了。
在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内并 未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接， 但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客 户端也需要支持持久连接。
8. 管线化
HTTP1.0的时候，是短连接，所以我每次进行HTTP请求都要请求响应全结束之后才能进行下一次的请求。持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从 前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术 出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待 响应了。
9. Cookie
HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管 理。也就是说，无法根据之前的状态进行本次的请求处理。
假设要求登录认证的 Web 页面本身无法进行状态的管理（不记录已 登录的状态），那么每次跳转新页面不是要再次登录，就是要在每次 请求报文中附加参数来管理登录状态。
不可否认，无状态协议当然也有它的优点。由于不必保存状态，自然 可减少服务器的 CPU 及内存资源的消耗。从另一侧面来说，也正是 因为 HTTP 协议本身是非常简单的，所以才会被应用在各种场景里。
保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入 了 Cookie 技术。Cookie 技术通过在请求和响应报文中写入 Cookie 信 息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的 首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出 去。
服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一 个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前 的状态信息。
HTTP 请求报文和响应报文的内 容如下。
1. 请求报文（没有 Cookie 信息的状态）
GET /reader/ HTTP/1.1
Host: hackr.jp *首部字段内没有Cookie的相关信息
2. 响应报文（服务器端生成 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
3. 请求报文（自动发送保存着的 Cookie 信息）
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
10. 压缩传输的内容编码
向待发送邮件内增加附件时，为了使邮件容量变小，我们会先用 ZIP 压缩文件之后再添加附件发送。HTTP 协议中有一种被称为内容编码 的功能也能进行类似的操作。
内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。
常用的内容编码：
gzip（GNU zip）
compress（UNIX 系统的标准压缩）
deflate（zlib）
identity（不进行编码）
11. 分割发送的分块传输编码
在 HTTP 通信过程中，请求的编码实体资源尚未全部传输完成之前， 浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成 多块，能够让浏览器逐步显示页面。 这种把实体主体分块的功能称为分块传输编码。
分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六 进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标 记。
使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编 码前的实体主体。 HTTP/1.1 中存在一种称为传输编码（Transfer Coding）的机制，它可 以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。
12. 发送多种数据的多部份对象集合
HTTP 协议中采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。
多部分对象集合包含的对象如下。
multipart/form-data ：在 Web 表单文件上传时使用。
multipart/byteranges：状态码 206（Partial Content，部分内容）响应报文包含了多个范 围的内容时使用。
multipart/form-data
multipart/byteranges
在 HTTP 报文中使用多部分对象集合时，需要在首部字段里加上 Content-type。
使用 boundary 字符串来划分多部分对象集合指明的各类实体。在 boundary 字符串指定的各个实体的起始行之前插入“--”标记（例如：- -AaB03x、--THIS_STRING_SEPARATES），而在多部分对象集合对 应的字符串的最后插入“--”标记（例如：--AaB03x--、-- THIS_STRING_SEPARAT ES--）作为结束。
13. 获取部分内容的范围请求
执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围。
5001~10 000 字节 Range: bytes=5001-10000
从 5001 字节之后全部的 Range: bytes=5001-
从一开始到 3000 字节和 5000~7000 字节的多重范围 Range: bytes=-3000, 5000-7000
针对范围请求，响应会返回状态码为 206 Partial Content 的响应报 文。另外，对于多重范围的范围请求，响应会在首部字段 Content-Type 标明 multipart/byteranges 后返回响应报文。如果服务器端无法响应范围请求，则会返回状态码 200 OK 和完整的 实体内容。
14. 内容协商返回最合适的内容
当浏览器的默认语言为英语或中文，访问相同 URI 的 Web 页面时， 则会显示对应的英语版或中文版的 Web 页面。这样的机制称为内容 协商（Content Negotiation）。
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然 后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字 符集、编码方式等作为判断的基准。
内容协商技术有以下 3 种类型。
服务器驱动协商（Server-driven Negotiation） 由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自 动处理。但对用户来说，以浏览器发送的信息作为判定的依据，并不 一定能筛选出最优内容。
客户端驱动协商（Agent-driven Negotiation） 由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手 动选择。还可以利用 JavaScript 脚本在 Web 页面上自动进行上述选 择。比如按 OS 的类型或浏览器类型，自行切换成 PC 版页面或手机 版页面。 透明协商（Transparent Negotiation） 是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进 行内容协商的一种方法。
15. 状态码类别
| 类别 | 原因短语 | |
| 1xx | Infomational（信息性状态码） | 接收的请求正在处理 |
| 2xx | Success（成功状态码） | 请求正常处理完毕 |
| 3xx | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4xx | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5xx | Server Error（服务器错误状态码） | 服务器请求出错 |
16. 主要状态码
204 No Content（没有内容可返回）
206 Partial Content（对部分资源返回）
301 Moved Permantently（永久性重定向）
302 Found（资源临时移动）
303 See Other（由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。）
304 Not Modified（客户端发送附带条件的请求时，服务器端允许请求访 问资源，但未满足条件的情况）
307 Temporary Redirect（临时重定向）
400 Bad Request（该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求 的内容后再次发送请求。）
401 Unauthorized
403 Forbidden（该状态码表明对请求资源的访问被服务器拒绝了）
404 Not Found（该状态码表明服务器上无法找到请求的资源）
500 Internal Server Error（该状态码表明服务器端在执行请求时发生了错误）
503 Service Unavailable（该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法 处理请求）
17. 代理
代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务 器。代理不改变请求 URI，会直接发送给前方持有资源的目标服务 器。
持有资源实体的服务器被称为源服务器。从源服务器返回的响应经过 代理服务器后再传给客户端。
每次通过代理服务器转发请求或响应时，会追加写入Via 首部信息。
在 HTTP 通信过程中，可级联多台代理服务器。请求和响应的转发会 经过数台类似锁链一样连接起来的代理服务器。转发时，需要附加 Via 首部字段以标记出经过的主机信息。
使用代理服务器的理由有：利用缓存技术（稍后讲解）减少网络带宽 的流量，组织内部针对特定网站的访问控制，以获取访问日志为主要 目的，等等。
代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另一 种是是否会修改报文
缓存代理 代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本 （缓存）保存在代理服务器上。 当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获 取资源，而是将之前缓存的资源作为响应返回。
透明代理 转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理 （Transparent Proxy）。反之，对报文内容进行加工的代理被称为非 透明代理。
18. 网关
利用网关可以由 HTTP 请求转化为其他协议通信
网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提 供非 HTTP 协议服务。
利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信 线路上加密以确保连接的安全。比如，网关可以连接数据库，使用 SQL语句查询数据。另外，在 Web 购物网站上进行信用卡结算时， 网关可以和信用卡结算系统联动。
19. 隧道
隧道可按要求建立起一条与其他服务器的通信线路，届时使用 SSL等 加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的 通信。
隧道本身不会去解析 HTTP 请求。也就是说，请求保持原样中转给之 后的服务器。隧道会在通信双方断开连接时结束。
20. 缓存的有效性
即便缓存服务器内有缓存，也不能保证每次都会返回对同资源的请 求。因为这关系到被缓存资源的有效性问题。
当遇上源服务器上的资源更新时，如果还是使用不变的缓存，那就会 演变成返回更新前的“旧”资源了。
即使存在缓存，也会因为客户端的要求、缓存的有效期等因素，向源 服务器确认资源的有效性。若判断缓存失效，缓存服务器将会再次从 源服务器上获取“新”资源。
21. 客户端的缓存
缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中。以 Internet Explorer 程序为例，把客户端缓存称为临时网络文件 （Temporary Internet File）。
浏览器缓存如果有效，就不必再向服务器请求相同的资源了，可以直 接从本地磁盘内读取。
另外，和缓存服务器相同的一点是，当判定缓存过期后，会向源服务 器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新 资源。
22. HTTP首部字段结构
HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“:” 分 隔。
首部字段名: 字段值
23. 若 HTTP 首部字段重复了会如何
当 HTTP 报文首部中出现了两个或两个以上具有相同首部字段名时 会怎么样？这种情况在规范内尚未明确，根据浏览器内部处理逻辑 的不同，结果可能并不一致。有些浏览器会优先处理第一次出现的 首部字段，而有些则会优先处理最后出现的首部字段。
24. 4 种 HTTP 首部字段类型
通用首部字段（General Header Fields） 请求报文和响应报文两方都会使用的首部。
请求首部字段（Request Header Fields） 从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加 内容、客户端信息、响应内容相关优先级等信息。
响应首部字段（Response Header Fields） 从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加 内容，也会要求客户端附加额外的内容信息。
实体首部字段（Entity Header Fields） 针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更 新时间等与实体有关的信息。
25. 常见首部字段
26. HTTP缺点
通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法证明报文的完整性，所以有可能已遭篡改
26. 加密处理防止被窃听
通信的加密 一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用， 加密 HTTP 的通信内容。与 SSL组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。
内容的加密 还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中 没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP 报文里所含的内容进行加密处理。诚然，为了做到有效的内容加密，前提是要求客户端和服务器同 时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意，由于该方式不同于 SSL或 TLS 将整个通信线路加密 处理，所以内容仍有被篡改的风险。
27. 不验证通信方的身份就可能遭遇伪装
任何人都可发起请求 在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何 人都可以发起请求。另外，服务器只要接收到请求，不管对方是 谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没 有被 Web 服务器设定限制访问的前提下）。
查明对手的证书 虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL则可以。 SSL不仅提供加密处理，而且还使用了一种被称为证书的手段， 可用于确定方。 证书由值得信任的第三方机构颁发，用以证明服务器和客户端是 实际存在的。另外，伪造证书从技术角度来说是异常困难的一件 事。所以只要能够确认通信方（服务器或客户端）持有的证书， 即可判断通信方的真实意图。
28. 无法证明报文完整性，可能已遭篡改
所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味 着无法判断信息是否准确。
接收到的内容可能有误 由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响 应送出之后直到对方接收之前的这段时间内，即使请求或响应的 内容遭到篡改，也没有办法获悉。 换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请 求 / 响应是前后相同的。
如何防止篡改 虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便 捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法， 以及用来确认文件的数字签名方法。
提供文件下载服务的 Web 网站也会提供相应的以 PGP（Pretty Good Privacy，完美隐私）创建的数字签名及 MD5 算法生成的散 列值。PGP 是用来证明创建文件的数字签名，MD5 是由单向函 数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用 户本人亲自检查验证下载的文件是否就是原来服务器上的文件。 浏览器无法自动帮用户检查。
可惜的是，用这些方法也依然无法百分百保证确认结果正确。因 为 PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。
为了有效防止这些弊端，有必要使用 HTTPS。SSL提供认证和加 密处理及摘要功能。仅靠 HTTP 确保完整性是非常困难的，因此 通过和其他协议组合使用来实现这个目标。下节我们介绍 HTTPS 的相关内容。
29. HTTP+ 加密 + 认证 + 完整性保护 =HTTPS
经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信。使用 HTTPS 通信时，不再用 http://，而是改用 https://。另外，当浏览器访 问 HTTPS 通信有效的 Web 网站时，浏览器的地址栏内会出现一个带 锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。
30. HTTPS 是身披 SSL 外壳的 HTTP
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代 替而已。
通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通 信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL协议这层外壳的 HTTP。
31. 相互交换密钥的公开密钥加密技术
在对 SSL进行讲解之前，我们先来了解一下加密方法。SSL采用一种 叫做公开密钥加密（Public-key cryptography）的加密处理方式。
近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种 方式得以保持加密方法的安全性。
加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说， 任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也 就失去了意义。
共享密钥加密的困境 加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。
使用两把密钥的公开密钥加密 公开密钥加密方式很好地解决了共享密钥加密的困难。 公开密钥加密使用一对非对称的密钥。一把叫做私有密钥 （private key），另一把叫做公开密钥（public key）。顾名思 义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发 布，任何人都可以获得。 使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进 行加密处理，对方收到被加密的信息后，再使用自己的私有密钥 进行解密。利用这种方式，不需要发送用来解密的私有密钥，也 不必担心密钥被攻击者窃听而盗走。 另外，要想根据密文和公开密钥，恢复到信息原文是异常困难 的，因为解密过程就是在对离散对数进行求值，这并非轻而易举 就能办到。退一步讲，如果能对一个非常大的整数做到快速地因 式分解，那么密码破解还是存在希望的。但就目前的技术来看是 不太现实的。
32. HTTPS 采用混合加密机制
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密 机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开 密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处 理速度要慢。
所以应充分利用两者各自的优势，将多种方法组合起来用于通 信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交 换报文阶段则使用共享密钥加密方式。
33. HTTPS 的安全通信机制
步骤 1： 客户端通过发送 Client Hello 报文开始 SSL通信。报文中包 含客户端支持的 SSL的指定版本、加密组件（Cipher Suite）列表（所 使用的加密算法及密钥长度等）。
步骤 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连接 就算建立完成。当然，通信会受到 SSL的保护。从此处开始进行应用 层协议的通信，即发送 HTTP 请求。
步骤 11： 应用层协议通信，即发送 HTTP 响应。
步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报 文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。
34. 为什么不一直使用 HTTPS
其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的 CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平 摊到一台计算机上时，能够处理的请求数量必定也会随之减少。
因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息 等敏感数据时，才利用 HTTPS 加密通信。
特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们 所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都 进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资 源。
要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认 证机构（CA）购买。证书价格可能会根据不同的认证机构略有不 同。通常，一年的授权需要数万日元（现在一万日元大约折合 600 人民币）。
那些购买证书并不合算的服务以及一些个人网站，可能只会选择采 用 HTTP 的通信方式。
HTTP攻击
DoS攻击是指故意的攻击网络协议实现的缺陷或直接通过野蛮手段残忍地耗尽被攻击对象的资源，目的是让目标计算机或网络无法提供正常的服务或资源访问，使目标系统服务系统停止响应甚至崩溃，而在此攻击中并不包括侵入目标服务器或目标网络设备。
中间人攻击（Man-in-the-Middle attack，MITM）是一种“间接”的入侵 攻击 ，这种 攻击 模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“ 中间人 ”。
针对 Web 的攻击技术
在客户端即可篡改请求 在 Web 应用中，从浏览器那接收到的 HTTP 请求的全部内容，都可 以在客户端自由地变更、篡改。所以 Web 应用可能会接收到与预期 数据不相同的内容。 在 HTTP 请求报文内加载攻击代码，就能发起对 Web 应用的攻击。 通过 URL查询字段或表单、HTTP 首部、Cookie 等途径把攻击代码传 入，若这时 Web 应用存在安全漏洞，那内部信息就会遭到窃取，或 被攻击者拿到管理权限。
主动攻击 是指攻击者通过直接访问 Web 应用， 把攻击代码传入的攻击模式。由于该模式是直接针对服务器上的 资源进行攻击，因此攻击者需要能够访问到那些资源。主动攻击模式里具有代表性的攻击是 SQL注入攻击和 OS 命令注 入攻击。
被动攻击 被动攻击（passive attack）是指利用圈套策略执行攻击代码的攻 击模式。在被动攻击过程中，攻击者不直接对目标 Web 应用访 问发起攻击。步骤 1： 攻击者诱使用户触发已设置好的陷阱，而陷阱会启动发 送已嵌入攻击代码的 HTTP 请求。 步骤 2： 当用户不知不觉中招之后，用户的浏览器或邮件客户端 就会触发这个陷阱。 步骤 3： 中招后的用户浏览器会把含有攻击代码的 HTTP 请求发 送给作为攻击目标的 Web 应用，运行攻击代码。 步骤 4： 执行完攻击代码，存在安全漏洞的 Web 应用会成为攻 击者的跳板，可能导致用户所持的 Cookie 等个人信息被窃取， 登录状态中的用户权限遭恶意滥用等后果。 被动攻击模式中具有代表性的攻击是跨站脚本攻击和跨站点请求 伪造。
因输出值转义不完全引发的安全漏洞 实施 Web 应用的安全对策可大致分为以下两部分。 客户端的验证Web
应用端（服务器端）的验证 ：输入值验证和输出值转义
HTTP首部注入攻击
邮件首部注入攻击
目录遍历攻击
远程文件包含漏洞
因设置或设计上的缺陷引发的安全漏 洞
强制浏览
强制浏览导致安全漏洞的案例
不正确的错误消息处理
开放重定向
因会话管理疏忽引发的安全漏洞
会话劫持
会话固定攻击
跨站点请求伪造
其他安全漏洞
密码破解
通过网络进行密码试错
对已加密密码进行破解
点击劫持
后门程序
DoS攻击
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
