第一章 了解web级网络基础
1.1 TCP/IP协议族
我们通常使用的网络是基于TCP/IP协议族（计算机相互通信的规则集）的，HTTP属于它内部的一个子集。
TCP/IP协议的分层管理
附：五层协议
1.2 URI - URL - URN
URI --- ---统一资源标识符，标识某一互联网资源。就是在某一规则下能把一个资源独一无二地标识出来。在现实生活中URI就是身份证号码。而家庭住址也能将人标识出来，所以家庭住址也是URI。
URL---统一资源定位符，表示资源的地址（互联网上所处的位置）也就是网址。就像家庭住址可以标识一个人，起到了URI的作用，是URI的子集。
URN---统一资源名称。就像一个人的身份证号码，起到了URI的作用，是URI的子集。
因为URN没能流行起来，所以在互联网中URI几乎可以认定为URL。
第二章 简单的http协议
2.1 请求报文和响应报文
请求报文是由请求方法、请求URI（统一资源标识符，URL：统一资源定位符）、协议版本、可选的请求首部字段和内容实体构成。
2.2 HTTP是无状态的
HTTP是一种不保存状态，即无状态协议。HTTP协议自身不对请求和响应之间的通信状态进行保存，不做持久化处理。所以为了保存状态引入了cookie技术，后面细讲。
2.3 HTTP使用URI定位互联网上的资源
HTTP协议使用URI定位互联网上的资源。正是因为URI的特定功能，在互联网上任意位置的资源都能访问到。
2.4 告知服务器意图的HTTP方法
2.5持久连接以使请求管线化发送
持久连接( HTTP Persistent Connections，也称为HTTP keep-alive或HTTP connection reuse)的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。在HTTP/1.1中，所有的连接默认都是持久连接。
持久连接使得多数请求以管线化(pipelining)方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。
2.6 使用Cookie的状态管理
Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。
Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。
当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
第三章 http报文内的http信息
3.1 http报文的结构
3.2 内容协商
当浏览器的默认语言为英语或中文，访问相同URI的Web页面时,则会显示对应的英语版或中文版的Web页面。这样的机制称为内容协商( Content Negotiation )。
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
第四章 返回的http状态码
第六章 报文首部字段
6.1 HTTP报文首部
HTTP 协议的请求和响应报文中必定包含 HTTP 首部，首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。
HTTP 请求报文
在请求中，HTTP 报文由方法、URI、HTTP 版本、HTTP 首部字段等部分构成。
下面的示例是访问hackr.jp时，请求报文的首部信息
HTTP 响应报文
在响应中，HTTP 报文由 HTTP 版本、状态码（数字和原因短语）、HTTP 首部字段 3 部分构成。
以下示例是之前请求访问 hackr.jp/ 时，返回的响应报文的首部信息。
在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信息。
6.2 HTTP首部字段
6.2.1 HTTP首部字段传递重要信息
HTTP 首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之间以 HTTP 协议进行通信的过程中，无论是请求还是响应都会使用首
部字段，它能起到传递额外重要信息的作用。使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。
6.2.2 HTTP首部字段结构
HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“:” 分隔。
首部字段名: 字段值
复制代码
例如，在 HTTP 首部中以 Content-Type 这个字段来表示报文主体的对象类型。
Content-Type: text/html
复制代码
就以上述示例来看，首部字段名为 Content-Type，字符串 text/html 是字段值。
6.2.3 4种HTTP首部字段类型
HTTP 首部字段根据实际用途被分为以下 4 种类型。
- 通用首部字段（General Header Fields）： 请求报文和响应报文两方都会使用的首部。
- 请求首部字段（Request Header Fields）：从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信信息、响应内容相关优先级等信息。
- 响应首部字段（Response Header Fields）：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
- 实体首部字段（Entity Header Fields）：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。
6.2.4 HTTP/1.1 首部字段一览
1. 通用首部字段
2. 请求首部字段
3. 响应首部字段
- 实体首部字段
6.7 为Cookie服务的首部字段
6.7.1 Set-Cookie
Set-Cookie: status=enable; expires=Tue, 05 Jul 2020 07:26:31
复制代码
当服务器准备开始管理客户端的状态时，会事先告知各种信息。
Set-Cookie字段值
6.7.2 Cookie
Cookie: status=enable
复制代码
首部字段 Cookie 会告知服务器，当客户端想获得 HTTP 状态管理支持时，就会在请求中包含从服务器接收到的 Cookie。接收到多个
Cookie 时，同样可以以多个 Cookie 形式发送。
8. 确认访问用户身份的认证
某些 Web 页面只想让特定的人浏。为达到这个目标，必不可少的就是认证功能。下面我们一起来学习一下认证 机制。
HTTP 使用的认证方式
- BASIC认证【基本认证】
- DIGEST认证【摘要认证】
- SSL客户端认证
- FormBase认证【基于表单认证】
8.1 BASIC认证（较早、不安全不常用）
BASIC 认证（基本认证）是从 HTTP/1.0 就定义的认证方式。即便是现在仍有一部分的网站会使用这种认证方式。是 Web 服务器与通信客户端之间进行的认证方式。 客户端之间进行的认证方式。
步骤 1： 当请求的资源需要 BASIC 认证时，服务器会随状态码 401Authorization Required，返回带 WWW-Authenticate 首部字段的响应。该字段内包含认证的方式（BASIC） 及 Request-URI 安全域字符串（realm）。
步骤 2： 接收到状态码 401 的客户端为了通过 BASIC 认证，需要将用户 ID 及密码发送给服务器。发送的字符串内容是由用户 ID 和密码构成，两者中间以冒号（:）连接后，再经过 Base64 编码处理。
步骤 3： 接收到包含首部字段 Authorization 请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含 Request-URI资源的响应。
BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。换言之，由于明文解码后就是用户 ID和密码，在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程中，如果被人窃听，被盗的可能性极高。
BASIC 认证使用上不够便捷灵活，且达不到多数 Web 网站期望的安全性等级，因此它并不常用。
8.2 DIGEST 认证
为弥补 BASIC 认证存在的弱点，从 HTTP/1.1 起就有了 DIGEST 认证。 DIGEST 认证同样使用质询 / 响应的方（challenge/response），但不会像 BASIC 认证那样直接发送明文密码。
所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。
步骤 1： 请求需认证的资源时，服务器会随着状态码 401Authorization Required，返 回带 WWW-Authenticate 首部字段的响应。
该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）。
步骤 2： 接收到 401 状态码的客户端，返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息。
步骤 3： 接收到包含首部字段 Authorization 请求的服务器，会确认认证信息的正确性。认证通过后则返回包含 Request-URI 资源的响应。
并且这时会在首部字段 Authentication-Info 写入一些认证成功的相关信息。
DIGEST 认证提供了高于 BASIC 认证的安全等级，但是和 HTTPS 的客户端认证相比仍旧很弱。DIGEST 认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。
DIGEST 认证和 BASIC 认证一样，使用上不那么便捷灵活，且仍达不到多数 Web 网站对高度安全等级的追求标准。因此它的适用范围也有所受限。
8.3 SSL客户端认证（收费）
SSL客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书（在 HTTPS 一章已讲解）认证，服务器可确认访问是否
来自已登录的客户端。
8.3.1 SSL客户端认证的认证步骤
为达到 SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
步骤 1： 接收到需要认证资源的请求，服务器会发送 CertificateRequest 报文，要求客户端提供客户端证书。
步骤 2： 用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。
步骤 3： 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。
8.3.2 SSL 客户端认证采用双因素认证
在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和基于表单认证（稍后讲解）组合形成一种双因素认证（Two-factor authentication）来使用。所谓双因素认证就是指，认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为
另一个因素，与其组合使用的认证方式。
换言之，第一个认证因素的 SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。
8.4 基于表单认证（常用）
基于表单的认证方法并不是在 HTTP 协议中定义的。客户端会向服务器上的 Web 应用程序发送登录信息（Credential），按登录信息的验证结果认证。 这个不做深讲。
使用Cookie管理Session
使用Cookie管理Session，可以弥补http不存在的状态管理功能。
