关于Http你至少需要知道这些内容

本文包含内容

Http特点
一次完整的网络访问流程
URI和URL的区别
Http报文结构，首部字段说明
Http的请求方法
Http状态码
Cookie和Session分别干嘛的
Http和Https的关系
Https建立SSL全过程
Http1.0、1.1、SPDY、2.0的区别
Http Post传输数据几种格式

Http特点

1. 支持c/s模式

Http用于客户端和服务端之间通信

HTTP 协议规定，请求从客户端发出，最后服务器端响应该请求并返回。换句话说，肯定是先从客户端开始建立通信的，服务器端在没有接收到请求之前不会发送响应。

2. 无状态

HTTP 是一种不保存状态，即无状态（stateless）协议。

HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。

3. 灵活

HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

4. 持久连接

在Http1.1使用了持久连接

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

持久连接旨在建立1次TCP连接后进行多次请求和响应的交互。

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

在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内并未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客户端也需要支持持久连接。

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

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

5. 使用Cookie的状态管理

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

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

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

用户在浏览器输入地址后发生的网络访问事件

浏览器分析链接指向页面URL
浏览器向DNS请求解析www.baidu.com的IP地址
域名系统DNS解析出百度服务器地址IP为192.168.22.11
浏览器与服务器建立TCP连接（服务端的地址为192.168.22.11：80）
浏览器发出Get请求： Get/chn/yxsz/index.html
服务器给出响应，把文件index.html发送给浏览器
释放TCP连接
浏览器解析内容，显示请求到的内容

URI和URL的关系

URI ：统一资源标识符，是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。采用 HTTP 协议时，协议方案就是 http。除此之外，还有 ftp、mailto、telnet、file 等。标准的 URI 协议方案有 30 种左右，由隶属于国际互联网资源管理的非营利社团 ICANN（Internet Corporation for Assigned Names and Numbers，互联网名称与数字地址分配机构）的 IANA（Internet Assigned Numbers Authority，互联网号码分配局）管理颁布。

URL：统一资源定位符。URI用字符串标识某一互联网资源，而 URL表示资源的地点（互联网上所处的位置）。可见URL是URI的子集。

Http报文结构，首部字段说明

请求报文

响应报文

报文结构

报头

通用报头

Date ：时间
Connection ：
Cache-Control：

请求报头

Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

User-Agent：发送请求的浏览器类型、操作系统等信息。

Accept：客户端可识别的内容类型列表，用于指定客户端接收哪些类型的信息。

Accept-Encoding：客户端可识别的数据编码。

Accept-Language：表示浏览器所支持的语言类型。

Connection：允许客户端和服务器指定与请求/响应连接有关的选项。例如，这时为Keep-Alive则表示保持连接。

Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。

响应报头

用于服务器传递自身信息的响应。常见的响应报头如下所示。

Location：用于重定向接收者到一个新的位置，常用在更换域名的时候。

Server：包含服务器用来处理请求的系统信息，与User-Agent请求报头是相对应的。

实体报头

实体报头用来定义被传送资源的信息，其既可用于请求也可用于响应。请求和响应消息都可以传送一个实体。常见的实体报头如下所示。

Content-Type：发送给接收者的实体正文的媒体类型。

Content-Lenght：实体正文的长度。、Content-Language：描述资源所用的自然语言。

Content-Encoding：实体报头被用作媒体类型的修饰符。它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。

Last-Modified：实体报头用于指示资源的最后修改日期和时间。

Expires：实体报头给出响应过期的日期和时间。

Http请求方法

Get：获取资源。GET 方法用来请求访问已被 URI 识别的资源。
POST：传输实体主体。POST 方法用来传输实体的主体。
PUT：传输文件。PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。
HEAD：获得报文首部，HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。
DELETE：删除文件。DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。
OPTIONS：询问支持的方法。OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。
TRACE：追踪路径。TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。

Http状态码

1xx 通知

2xx 请求成功

3xx 重定向

4xx 客户端错误

5xx 服务器错误

编码提升传输速率

HTTP 在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中通过编码提升传输速率。通过在传输时编码，能有效地处理大量的访问请求。但是，编码的操作需要计算机来完成，因此会消耗更多的 CPU 等资源。
压缩传输的内容编码

向待发送邮件内增加附件时，为了使邮件容量变小，我们会先用 ZIP 压缩文件之后再添加附件发送。HTTP 协议中有一种被称为内容编码的功能也能进行类似的操作。

内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。

常用的内容编码有以下几种。

gzip（GNU zip） compress（UNIX 系统的标准压缩） deflate（zlib） identity（不进行编码）
分割发送的分块传输编码

在 HTTP 通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。

这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。

分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标记。

使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。

HTTP/1.1 中存在一种称为传输编码（Transfer Coding）的机制，它可以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。
获取部分内容的范围请求

指定范围发送的请求叫做范围请求（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
```

Http和Https的关系

HTTP+ 加密 + 认证 + 完整性保护 = HTTPS
HTTPS 是身披 SSL 外壳的 HTTP

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

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

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。

所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。
证明公开密钥正确性的证书

使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
HTTPS 比 HTTP 要慢 2 到 100 倍

SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗 CPU 及内存等资源，导致处理速度变慢。

和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和 TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL通信，因此整体上处理通信量不可避免会增加。

另一点是 SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。

针对速度变慢这一问题，并没有根本性的解决方案，我们会使用 SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为 SSL通信专用硬件，相对软件来讲，能够提高数倍 SSL的计算速度。仅在 SSL处理时发挥 SSL加速器的功效，以分担负载。

Https建立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 能够查知报文是否遭到篡改，从而保护报文的完整性。

Cookie和Session分别干嘛的，有什么区别

一般会使用 Cookie 来管理 Session（会话）。

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

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

向客户端返回响应时，会在首部字段 Set-Cookie 内写入 Session ID（如 PHPSESSID=028a8c…）。

你可以把 Session ID 想象成一种用以区分不同用户的等位号。

然而，如果 Session ID 被第三方盗走，对方就可以伪装成你的身份进行恶意操作了。因此必须防止 Session ID 被盗，或被猜出。为了做到这点，Session ID 应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。

另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie 内加上 httponly 属性。

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

总结：cookie用于存储用户数据，行为，比如存储用户上次登录输入的内容。可以存储在内存中，也可以序列化到本地，根据超时时间进行销毁，或者被服务端新set-cookie来覆盖。

session是一种抽象的会话，比如，只有登录了才能查看我的订单，这时候有一个sessionId来标识是否登录了，这个sessionID可以由cookie来管理。

Http1.0、1.1、2.0区别

Http1.0/1.1：

一条连接上只可发送一个请求。
请求只能从客户端开始。客户端不可以接收除响应以外的指令。
请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。
发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
可任意选择数据压缩格式。非强制压缩发送。

Http SPDY

SPDY 没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY 规定通信中使用 SSL。

SPDY 以会话层的形式加入，控制对数据的流动，但还是采用 HTTP 建立通信连接。因此，可照常使用 HTTP 的 GET 和 POST 等方法、 Cookie 以及 HTTP 报文等。

多路复用流

通过单一的 TCP 连接，可以无限制处理多个 HTTP 请求。所有请求的处理都在一条 TCP 连接上完成，因此 TCP 的处理效率得到提高。
赋予请求优先级

SPDY 不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
压缩 HTTP 首部

压缩 HTTP 请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。
推送功能

支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
服务器提示功能

服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

这个小哥说的挺好

Http Post传输数据几种格式

application/x-www-form-urlencoded

这应该是最常见的 POST 提交数据的方式了。浏览器的原生表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

首先，Content-Type 被指定为 application/x-www-form-urlencoded
其次，提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。
大部分服务端语言都对这种方式有很好的支持。

application/json

Content-Type 被指定为application/json
可以方便的提交复杂的结构化数据，特别适合 RESTful 的接口
各大抓包工具如 Chrome 自带的开发者工具、Firebug、Fiddler，都会以树形结构展示 JSON 数据，非常友好

POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8

{“title”:“test”,“sub”:[1,2,3]}

text/xml

Content-Type: text/xml

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

multipart/form-data

使用表单上传文件时，必须让表单的 enctype 等于 multipart/form-data
首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。
然后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容
消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始
紧接着是内容描述信息
然后是回车
最后是字段具体内容（文本或二进制）

如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。

  POST http://www.example.com HTTP/1.1
  Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
  
  ------WebKitFormBoundaryrGKCBY7qhFd3TrwA
  Content-Disposition: form-data; name="text"
  
  title
  ------WebKitFormBoundaryrGKCBY7qhFd3TrwA
  Content-Disposition: form-data; name="file"; filename="chrome.png"
  Content-Type: image/png
  
  PNG ... content of chrome.png ...
  ------WebKitFormBoundaryrGKCBY7qhFd3TrwA--