HTTP笔记

“你知道当我们在网页浏览器（Web browser）的地址栏中输入 URL 时，Web 页面是如何呈现的吗？”

HTTP协议

HTTP协议（HyperText Transfer Protocol）即超文本传输协议是用于服务器传输到客户端浏览器的传输协议。Web上，服务器和客户端利用HTTP协议进行通信会话。

在Web上，HTTP协议使用TCP协议而不是UDP协议的原因在于一个网页必须传送很多数据，而且保证其完整性。TCP协议提供传输控制，按顺序组织数据和错误纠正的一系列功能。

一次HTTP操作称为一个事务，其工作过程可分为四步：

1、客户端与服务器需要建立连接。（比如某个超级链接，HTTP就开始了。）
2、建立连接后，发送请求。
3、服务器接到请求后，响应其响应信息。
4、客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

忽略掉连接过程是这样的:

URI、URL与RFC

先看看官方的解释：
URI：uniform resource identifier 统一资源标识符
URL：uniform resource location 统一资源定位符

URI用字符串标识某一互联网资源，而URL表示资源的地点。可见URL是URI的子集。

URI要使用涵盖全部必要信息的URI、绝对URL以及相对URL。相对URL是指从浏览器中基本URI处理的URL，来先看下URI的格式:

RFC：reqeust for comments 征求修正意见书
RFC素有网络知识圣经之称，规定了网络中协议的基本内容。因此许多的不同系统的应用程序才可以互相访问。

HTTP请求方式

请求行-请求方法

• GET 获取资源
• POST 传输实体主体
• PUT 传输文件
• HEAD 获取报文首部
• DELETE 删除文件
• OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
• TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
• CONNECT 要求用隧道协议连接代理(SSL：Secure Sockets Layer安全套接层，TLS：Transport Layer Security传输层安全)

get和post区别

看别人总结的吧
还有这篇

状态码

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

常见的状态码

200 OK
请求成功（其后是对GET和POST请求的应答文档。）

304 Not Modified
未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。

404 Not Found
服务器无法找到被请求的页面。
 
500 Internal Server Error
请求未完成。服务器遇到不可预知的情况。

HTTP报文

HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应构成。

请求我博客园首页时发送的报文内容:

　其中最常使用的属性是：

• URL, 即http访问的地址
• request method, 报文的请求方式
• Remote Address,远程地址
• status code, 状态码以及状态短语
• Connection, 连接方式
• Content-Type头：便是接收方实体的介质类型。
• Accept Encoding, 内容编码
• Date头域：时间描述
• Referer头域：允许客户端指定请求URL的资源地址。
• Cookie, 添加的cookie内容
• Host, 目标主机
• User-Agent, 客户端浏览器的相关信息
• Set-Cookie, 指定想要在Cookie中保存的内容

持久连接

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

“为解决上述 TCP 连接的问题，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。”

持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使 HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相应提高了。
在 HTTP/1.1 中，所有的连接默认都是持久连接

管线化

“持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。

这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。”

比如，当请求一个包含 10 张图片的 HTML Web 页面，与挨个连接相比，用持久连接可以让请求更快结束。而管线化技术则比持久连接还要快。请求数越多，时间差就越明显。

内容编码

由于某些报文的内容过大，因此在传输时，为了减少传输的时间，会采取一些压缩的措施。

例如上面的报文信息中，Accept-Encoding就定义了内容编码的格式：gzip,deflate

有下面几种方式：

• gzip：GNU压缩格式
• compress：UNIX系统的标准压缩格式
• deflate：是一种同时使用了LZ77和哈弗曼编码的无损压缩格式
• identity：不进行压缩

范围请求

以前，用户不能使用现在这种高速的带宽访问互联网，当时，下载一个尺寸稍大的图片或文件就已经很吃力了。如果下载过程中遇到网络中断的情况，那就必须重头开始。为了解决上述问题，需要一种可恢复的机制。所谓恢复是指能从之前下载中断处恢复下载。

要实现该功能需要指定下载的实体范围。像这样，指定范围发送的请求叫做范围请求（Range Request）。

对一份 10 000 字节大小的资源，如果使用范围请求，可以只请求 5001~10 000 字节内的资源。

执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围。

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 和完整的实体内容。”

Cookie

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

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

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

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

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

HTTPS

HTTP 主要有这些不足，例举如下。

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改”

这些问题不仅在 HTTP 上出现，其他未加密的协议中也会存在这类问题。

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。

通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。

在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术。

步骤 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 的通信。

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

HTTP认证

　　有一些网址或者服务需要用户的身份信息，因此需要随时知道这些消息，但是肯定不能每次都让用户输入用户密码，因此关于认证就有下面几种方式：

其中BASIC认证是最简单的认证，大致过程如下：
1 、客户端访问某URL。
2 、服务器端返回401状态码，提示用户输入用户名密码。
3 、用户输入用户名密码，通过BASE64编码传输。
4 、服务器通过认证，返回状态码200

通过上面的过程，就可以发现BASIC的问题：

• 仅仅通过BASE64编码，其实还是属于明文传输，安全性不高
• 有的浏览器不支持注销

鉴于上面BASIC的问题，DIGEST做了补充，它的过程与上面类似：
1 、客户端访问
2 、服务器端返回质询码
3 、客户端发送响应码

这里通过随机的生成质询码来作为计算的一种方式，客户端依据这个质询码生成响应码，进行验证。
这样就弥补了明文传输用户密码的风险。

SSL客户端验证，这个比较普遍了！

像支付宝啊，邮政网银啊之类的，在登录时，都需要下载一个数字认证的东西，这个东西就属于一种SSL客户端的验证。

很显然它的缺点就是需要客户去手动的安装，这个对于一般的用户来说，代价有点高。

最后一种是应用最普遍的，通过表单记录用户的身份信息，可以使用cookie或者session的方式保存用户信息。