Head First HTTP

一、HTTP简介

1.HTTP

• HTTP: 超文本传输协议，是一种通信协议；允许超文本标记文档从Web服务器传送到客户端的浏览器中。

• 简单：传输html文件的协议。

• Web: 是一种基于超文本和HTML的、全球性的、动态交互的、跨平台的分布式图形信息系统。

• http是无状态协议，这保证了它的高效。Cookie和Section的出现使http在保持高效的情况下，能够记住状态；

2.URI与URL

• URI可分为URL，URN或同时具备locators 和 names特性的东西；

• URN的作用就好像一个人的名字，URL就像这个人的地址；

• 换句话说：URN确定了东西的身份，URL提供了找到它的方式；

URL是URI的一种，不是所有的URI都是URL；URI唯一地标识了身份，URL给出了访问机制（http/ftp/telnet等）

二、状态码

1xx：接收的请求正在处理

2xx：请求正常处理完毕

3xx：重定向

4xx：客户端错误

5xx：服务器错误

三、HTTP首部

1.HTTP请求和响应报文

1.1.HTTP请求报文

1.2.HTTP响应报文

可见HTTP报文一共有四种首部字段（请求头）：请求首部字段、响应首部字段、通用首部字段、实体首部字段

2.请求首部字段

2.1.Accept

• 作用：浏览器端可以接受的媒体类型；
• 若想要给显示的媒体类型增加优先级， 则使用 q来额外表示权重值，用分号（;）进行分隔。权重值 q 的范围是 0~1（可精确到小数点后 3 位） ，且1为最大值。不指定权重 q 值时，默认权重为 q=1.0。
• 当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。

2.2.Accept-Charset

• 作用：用来通知服务器用户代理（浏览器）支持的字符集及字符集的相对优先顺序。

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

• unicode-1-1;q=0.8是一个整体，表示unicode编码优先级为0.8，小于默认的iso编码优先级（默认q=1）；不要以为分号（;）为分割符，其实逗号（,）才是分割符

2.3.Accept-Encoding

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

Accept-Encoding: gzip, deflate

• 常见的编码方式有：gzip、compress、deflate、identity。

2.4.Accept-Language

• 作用：用来告知服务器浏览器能够接收的语言 ，以及相对优先级。

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

• 上述值表示：优先请求中文版，其次是英文版；

2.5.Host

Host: www.imzye.com

• 若服务器未设定主机名，Host为空值即可。

2.6.If-Match

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

• 上图表示：只有当If-Match的字段值跟Etag值匹配一致时，服务器才会接收请求。

2.7.If-Modified-Since

• 如果在If-Modified-Since字段指定的日期时间后，资源发生了更新，服务器会接收请求，此时返回状态码200；否则会拒绝接收请求返回304（因为资源都没更新过，不需要重新请求），与响应头Last-Modified是一对

2.8.If-None-Match

• 只有在 If-None-Match 的字段值与 ETag 值不一致时， 可处理该请求。 与 If-Match 首部字段的作用相反；

2.9.If-Range

• 首部字段 If-Range 属于附带条件之一。 它告知服务器若指定的 If-Range 字段值（ETag 值或者时间） 和请求资源的 ETag 值或时间相一致时， 则作为范围请求处理。 反之， 则返回全体资源。

2.10.Referrer

• 作用：告诉服务器我是从哪个页面的链接过来的，服务器籍此可以获得一些信息用于处理；

Referer: http://www.imzye.com/index.html

2.11.User-Agent

• 作用：告诉HTTP服务器，客户端使用的操作系统和浏览器的名称和版本；

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/2010010

• 很多时候我们会通过该字段来判断浏览器类型，从而进行不同的兼容性设计。

3.响应首部字段

3.1.Age

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

3.2.ETag

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

• 另外， 当资源更新时，ETag 值也需要更新。生成 ETag 值时，并没有统一的算法规则，而仅仅是由服务器来分配。与响应头If-None-Match是一对。

3.3.Location

使用首部字段 Location 可以将响应接收方引导至某个与请求 URI 位置不同的资源。 基本上，该字段会配合 3xx ： Redirection 的响应， 提供重定向的URI。

4.通用首部字段

4.1.Cache-Control

a.请求首部中Cache-Control的指令：

b.响应首部中Cache-Control的指令：

Cache-Control各指令详解：

• public指令：客户端和代理服务器（CDN）可以缓存
• Private指令：只有客户端可以缓存
• no-store指令：真正意义上的所有内容都不缓存
• no-cache指令：正确来说该指令还是会使用缓存，只不过使用前要确认其新鲜程度（协商缓存）

s-maxage = x: 指令代理服务器请求源站缓存后的X秒内不再发出请求，只对CDN缓存（CDN指的是拥有源服务器资源的多个分布式服务器）有效

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

此外，当使用 s-maxage 指令后，则直接忽略对 Expires 首部字段及 max-age 指令的处理。 即优先级为：S-maxage > Max-age > Expires

Max-age = x: 指令请求缓存后的X秒内不再发起请求。

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

• 当客户端发送的请求中包含 max-age 指令时： 如果判定指定的时间比缓存资源的缓存时间数值更大，那么客户端就接收缓存的资源。另外，当指定 max-age 值为 0（指定时间更小），那么缓存服务器通常需要将请求转发给源服务器。
• 当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源的有效性再作确认，而直接把 max-age 数值作为保存为缓存的资源的最长时效。
• 应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的情况时，会优先处理 max-age 指令，而忽略掉 Expires 首部字段。

4.2.Connection

有两个作用：

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

a.当 Connection:close 时：

代表一个 Request 完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接会关闭（四次挥手）。当客户端再次发送 Request，需要重新建立 TCP 连接（三次握手）。

b.当 Connection:Keep-Alive 时：

此时，当一个网页打开完成后（已经建立 TCP 连接），客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，如果客户端再次访问这个服务器，会继续使用这条已经建立的连接。

4.3.Via

使用首部字段 Via 是为了追踪客户端与服务器之间的请求和响应报文的传输路径：

5.实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

5.1.Content-Type

作用：说明报文内对象的媒体类型

Content-Type: text/html; charset=UTF-8

5.2.Expires

首部字段 Expires 会将资源失效的日期告知客户端。缓存服务器（代理服务器）在接收到含有首部字段 Expires 的响应后，会以缓存来应答请求，在 Expires 字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。

源服务器不希望缓存服务器对资源缓存时， 最好在 Expires 字段内写入与首部字段 Date 相同的时间值。

但是，当首部字段 Cache-Control 有指定 max-age 指令时，比起首部字段 Expires，会优先处理 max-age 指令。

5.3.Last-Modified

首部字段 Last-Modified 指明资源最终修改的时间。 与请求头If-Modified-Since是一对

Last-Modeified: Wed, 23 May 2012 09:59:55 GMT

6.为 Cookie 服务的首部字段

Cookie 的工作机制是用户识别及状态管理。Web 网站为了管理用户的状态会通过 Web 浏览器，把一些数据临时写入用户的计算机内。接着当用户访问该 Web 网站时，可通过通信方式取回之前发放的 Cookie;

调用 Cookie 时，由于可校验 Cookie 的有效期，以及发送方的域、路径、协议等信息，所以正规发布的 Cookie 内的数据不会因来自其他 Web 站点和攻击者的攻击而泄露。

为 Cookie 服务的首部字段：

6.1.Set-Cookie字段

当服务器准备开始管理客户端的状态时，会事先告知各种信息。

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path

• expires 属性：

Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session）时间段内。 这通常限于浏览器应用程序被关闭之前。

另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可以显式删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对客户端 Cookie 的实质性删除操作。

• domain 属性：

通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。 比如，当指定 example.com 后，除 example.com 以外， www.example.com 或 www2.example.com 等都可以发送 Cookie。

因此， 除了针对具体指定的多个域名发送 Cookie 之 外，不指定 domain 属性显得更安全。

• secure 属性：

Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie。

发送 Cookie 时，指定 secure 属性的方法如下所示：

Set-Cookie: name=value; secure

以上例子仅当在 https://www.example.com/（HTTPS） 安全连接的情况下才会进行 Cookie 的回收。也就是说， 即使域名相同，http://www.example.com/（HTTP） 也不会发生 Cookie 回收行为。

当省略 secure 属性时，不论 HTTP 还是 HTTPS，都会对 Cookie 进行回收。

• HttpOnly 属性：

Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本无法获得 Cookie。 其主要目的为防止跨站脚本攻击（Cross-sitescripting， XSS） 对 Cookie 的信息窃取。

发送指定 HttpOnly 属性的 Cookie 的方法如下所示。

Set-Cookie: name=value; HttpOnly

通过上述设置，通常从 Web 页面内还可以对 Cookie 进行读取操作。但使用 JavaScript 的 document.cookie 就无法读取附加 HttpOnly 属性后的 Cookie 的内容了。 因此，也就无法在 XSS 中利用 JavaScript 劫 Cookie 了。

6.2.Cookie字段

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

Cookie: status=enable

四、HTTP请求方法

HTTP/1.1 的常用方法

1.GET

• GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。

• GET 方法也可以用来提交表单和其他数据：

http://localhost/login.php?username=aa&password=1234

• 从上面的请求URL中，很容易就能辨认出表单提交的内容。HTTP0.9的时候只有GET方法，所以GET方法既能获取数据，也能提交数据，只不过提交的数据是拼接在 URL 后的不能提交太多且不安全；提交大量数据时使用POST方法。

2.POST

• POST方法功能与GET方法类似，是GET方法的延伸，主要用于向服务器提交数据量较大的用户表单数据；

• 提交的数据放在请求报文的主体中，保证了提交数据的安全；这样就克服了GET方法提交的数据量太小和不能保密的缺点。

• POST方法的主要目的并不是获取响应主体的内容；

3.PUT

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

• PUT 方法和 POST 很相似，最大的不同是：PUT 是幂等的，POST 是不幂等的。 即创建文件使用 POST 更新文件使用 PUT；

• 幂等：幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同；

• 但是， 鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制， 任何人都可以上传文件 , 存在安全性问题， 因此一般的 Web 网站不使用该方法。

4.HEAD

• HEAD 方法只获取响应报文首部，不返回报文主体部分。 用于确认 URI （超链接）的有效性及资源更新的日期时间等。 例如：

5.DELETE

• DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。

• 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机制，所以一般的 Web 网站也不使用 DELETE 方法。

6.OPTIONS

• OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。

7.TRACE

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

但是， TRACE 方法本来就不怎么常用， 再加上它容易引发 XST（Cross-Site Tracing， 跨站追踪） 攻击， 通常就更不会用到了。

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

//请求
TRACE / HTTP/1.1
Host: imzye.com
Max-Forwards: 2

响应：
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 1024

TRACE / HTTP/1.1
Host: imzye.com
Max-Forwards: 2（返回响应包含请求内容）

8.CONNECT

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

五、HTTP状态管理

Cookie 和 Session，实现了 HTTP 的状态管理，Cookie 是在客户端的，Session 是在服务器的。

1.Cookie

HTTP 是无状态协议（高效率，不记仇），它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。

假设要求登录认证的 Web 页面本身无法进行状态的管理（不记录已登录的状态） ，那么每次跳转新页面不是要再次登录，就是要在每次请求报文中附加参数来管理登录状态。

保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了Cookie技术。Cookie 技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

• Cookie实际上是一小段文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就向客户端浏览器颁发一个Cookie；

• 客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。

• Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息， 通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时， 客户端会自动在请求报文中加入 Cookie 值后发送出去。

• 服务器端发现客户端发送过来的 Cookie 后， 会去检查究竟是从哪一个客户端发来的连接请求， 然后对比服务器上的记录， 最后得到之前的状态信息。

2.Session

• Session 是另一种记录客户状态的机制，保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上；

• 客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了；

Cookie 和 Session 非常相似，Cookie 相当于客户端持有的通行证，Session 相当于服务器上的通行名册。

保存 Session ID 的方式

• Cookie
• URL重写
• 隐藏表单

Session 的有效期

• Session 超时失效:被动失效，如果超过规定时间没有再次访问服务器，Session 将失效；
• 程序调用 HttpSession.invalidate() 主动失效；
• 服务器进程被停止；

3.Token

3.1.Token的引入

Token 是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token 便应运而生。

3.2.Token的定义

Token 是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个 Token 便将此 Token 返回给客户端，以后客户端只需带上这个 Token 前来请求数据即可，无需再次带上用户名和密码。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。

3.3.使用Token的目的

• Token 的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。

3.4.Session管理及Cookie应用

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

• 步骤 2：服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证， 然后把用户的认证状态与 Session ID 绑定后记录在服务器端。

• 向客户端返回响应时，会在首部字段 Set-Cookie 内写入 SessionID（如 PHPSESSID=028a8c…）。
• 为防止 Session ID 被第三方盗走，服务器端需要对其进行有效性管理；并且为减轻跨站脚本攻击（XSS） 造成的损失，建议事先在 Cookie 内加上 httponly 属性。

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

4.Cookie与Session的区别

• 存放位置不同：Cookie 存放在客户端，Session 保存在服务器端；
• 安全性（隐私策略）不同：Cookie 存储在浏览器中，对客户端是可见的，客户端的一些程序可能会窥探或修改 Cookie 的内容；而 Session 存储在服务器端，对客户端来说是透明的；如果想要使用 Cookie 需要对其进行加密；
• 有效期上的不同：设置 Cookie 很大的过期时间，Cookie 就能被浏览器保存很长时间；而服务器会定期清理超时的 Session ID 避免出现过大压力；但是Session 依赖于类似 Session ID 这样的 Cookie，而 Cookie 对 Session ID 过期时间默许为 -1。所以只要关闭了浏览器，即一次会话结束后，该 Session 就失效了；
• 对服务器造成的压力不同：Session 是保存在服务器端的，每个用户都产生一个 Session ，假如并发访问的用户十分多，会产生十分多的 Session，耗费大量的内存；而 Cookie 保存在客户端，不太占用服务器的资源；

六、HTTP协议的身份认证

• BASIC认证（基本认证）
• DIGEST（摘要认证）
• SSL客户端认证
• FormBase认证（基于表单认证）

1.BASIC认证

BASIC 认证的认证步骤

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

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

• 假设用户 ID 为 guest，密码是 guest，连接起来就会形成 guest:guest 这样的字符串。 然后经过 Base64 编码，最后的结果即是Z3Vlc3Q6Z3Vlc3Q=。 把这串字符串写入首部字段 Authorization 后， 发送请求。

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

• BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。换言之，由于明文解码后就是用户 ID 和密码，在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程中，如果被人窃听，被盗的可能性极高。 因此并不常用。

2.DIGEST 认证

为弥补·BASIC认证存在的弱点， 从 HTTP/1.1 起就有了 DIGEST 认证。 DIGEST 认证同样使用质询/响应的方式 （challenge/response），但不会像 BASIC 认证那样直接发送明文密码。

所谓质询响应方式是指， 一开始一方会先发送认证要求给另一方， 接着使用从另一方那接收到的质询码计算生成响应码。 最后将响应码返回给对方进行认证的方式。

因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起 BASIC 认证，密码泄露的可能性就降低了。

DIGEST 认证的认证步骤

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

• 首部字段 WWW-Authenticate 内必须包含 realm 和 nonce 这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。
• nonce 是一种每次随返回的 401 响应生成的任意随机字符串。该字符串通常推荐由 Base64 编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现。

• 步骤 2：接收到 401 状态码的客户端，返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息。

• 首部字段 Authorization 内必须包含 username、 realm、 nonce、 uri 和 response 的字段信息。其中，realm 和 nonce 就是之前从服务器接收到的响应中的字段。

• 步骤 3：接收到包含首部字段 Authorization 请求的服务器，会确认认证信息的正确性。 认证通过后则返回包含 Request-URI 资源的响应。并且这时会在首部字段 Authentication-Info 写入一些认证成功的相关信息。

• DIGEST 认证提供了高于 BASIC 认证的安全等级，但是和 HTTPS 的客户端认证相比仍旧很弱。 DIGEST 认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制 。因此使用范围不大。

3.SSL 客户端认证

从使用用户ID和密码的认证方式方面来讲，只要二者的内容正确即可认证是本人的行为。但如果用户 ID 和密码被盗，就很有可能第三者冒充。利用 SSL 客户端认证则可以避免该情况的发生。

SSL 客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。

SSL 客户端认证的认证步骤：

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

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

• 步骤 2：用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。

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

SSL 客户端认证采用双因素认证

• 在多数情况下，SSL 客户端认证不会仅依靠证书完成认证，一般会和基于表单认证组合形成一种双因素认证（Two-factorauthentication） 来使用。

• 换言之，第一个认证因素的 SSL 客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。

• 使用 SSL 客户端认证需要用到客户端证书。而客户端证书需要支付一定费用才能使用。

4.基于表单认证

• 基于表单的认证方法并不是在HTTP协议中定义的；
• 使用由Web应用程序各自实现基于表单的认证方式；
• 通过Cookie和Session的方式来保持用户的状态；

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

七、HTTP的长连接与短连接

HTTP 协议是基于请求/响应模式的，因此只要服务端给了响应，本次 HTTP 请求就结束了；HTTP 的长连接和短连接本质上是 TCP 的长连接和短连接

1.短连接

完成一次通信之后，客户端主动断开 TCP 连接；

HTTP/1.0 中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次 HTTP 操作，就建立一次连接（三次握手），结束就中断（四次挥手）；

2.长连接

完成一次通信之后，客户端不主动断开 TCP 连接，而是复用该 TCP 连接；

HTTP/1.1 起，默认使用长连接，用以保持连接特性。此时通用首部字段中的 Connection 字段值为：Keep-Alive；

长连接适用于频繁地传输数据的客户端和服务器，为了防止过多的 TCP 连接影响服务器性能，需要对长时间不用的连接进行释放；

八、代理、网关与隧道

HTTP 通信时，除客户端和服务器以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。它们可以配合服务器工作。

这些应用程序和服务器可以将请求转发给通信线路上的下一站服务器，并且能接收从那台服务器发送的响应再转发给客户端。

1.代理

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

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

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

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

使用代理服务器的理由

利用缓存技术（稍后讲解）减少网络带宽的流量，组织内部针对特定网站的访问控制（墙），以获取访问日志为主要目的，等等。

代理使用方法

代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另一种是是否会修改报文。

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

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

2.网关

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

网关的工作机制和代理十分相似。但是Web网关在一侧使用HTTP协议，在另一侧使用另一种协议（比如FTP、SMTP）

• （HTTP）服务器端网关：通过HTTP协议与客户端对话，通过其他协议与服务器通信；
• （HTTP）客户端网关：通过其他协议与客户端对话，通过HTTP协议与服务器通信；

常见的网关类型：

• （HTTP/*）服务器端Web网关；
• （HTTP/HTTPS）服务器端安全网关：即客户端用HTTP与网关通信，网关用HTTPS与服务器通信；
• （HTTPs/HTTP）客户端安全加速器网关：即客户端用HTTPs与网关通信，网关用HTTP与服务器通信；
• 也就是安全网关，将通过网关的不安全的HTTP转换为安全的HTTPS;
• 资源网关：客户端通过HTTP连接到应用程序的服务器，服务器并不回送文件，而是将请求通过网关API发送给运行在服务器上的应用程序，应用程序将请求资源会送给客户端。这样的客户端可能是一些网络摄像头，电子识别系统等；

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

3.隧道

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

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

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