HTTP笔记

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

HTTP协议

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

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

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

一、客户端与服务器须要创建链接。（好比某个超级连接，HTTP就开始了。）
二、创建链接后，发送请求。
三、服务器接到请求后，响应其响应信息。
四、客户端接收服务器所返回的信息经过浏览器显示在用户的显示屏上，而后客户机与服务器断开链接。

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

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的方式保存用户信息。