http讲解

http起源

  1. http 全程 超级文本传输协议 诞生于 1989 年 3月 CERN(欧洲核子研究组织) 的 蒂姆 • 伯纳斯 - 李 提出了一种能让远隔两地的研究者们共享知识的设想。

  2. 1990 年 大家针对 HTML 1.0 草案进行了讨论， 因 HTML 1.0 中存在多处模糊不清的部分， 草案被直接废弃了。

  3. HTTP 正式作为标准被公布是在 1996 年的 5 月， 版本被命名为 HTTP/1.0， 并记载于 RFC1945。 虽说是初期标准， 但该协议标准至今仍被广泛使用在服务器端。

  4. 1996 年发布了http 1.1 版本，增加了持久连接等内容

理解 HTTP， 我们有必要事先了解一下 TCP/IP 协议族

TCP/IP 协议族 按照层次分别分为 一下4 层：应用层，传输层，网络层和数据链路层。

为什分要把TCP/IP 层次化，这样做有什么好处？

如果 互联网只由一个协议统筹，某个地方需要改变设计时，就必须把所有部分整体换掉。 而分层之后只需把变动的层替换掉即可。 把各层之间的接口部分规划好之后， 每个层次内部的设计就能够自由改动了。层次化之后， 设计也变得相对简单了。 处于应用层上的应用可以只考虑分派给自己的任务， 而不需要弄清对方在地球上哪个地方、 对方的传输路线是怎样的、 是否能确保传输送达等问题。
应用层：决定了向用户提供应用服务时通信的活动 比如：FTP/ dns(域名系统) 服务

传输层：对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。在传输层中包含两种性质不同的协议: TCP（ 传输控制协议）和 UDP（用户数据协议）

网络层：（又名网络互联层）网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（也就是传输路线）到达对方计算机，并把数据包传送给对方。

链路层：（又名数据链路层，网络接口层），用来处理网络的硬件部分。包括控制操作系统，硬件的设备驱动，网卡等，硬件上的范畴均在链路层的作用范围之内

HTTP报文

用于HTTP 报文交换的信息 被称为 http报文；请求端（客户端） 的
HTTP 报文叫做请求报文， 响应端（服务器端） 的叫做响应报文。

首部一般分为 通用首部 请求首部 响应首部 实体首部

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

gzip（GNU zip）
compress（UNIX 系统的标准压缩）
deflate（zlib）
identity（不进行编码）

HTTP 状态码

http 状态码负责表示客户端HTTP请求的返回结果，标记服务端的处理是否正常，通知出现的错误等工作.

  1. 1XX Informational（信息性状态码） 接收的请求正在处理
  2. 2XX Success（成功状态码） 请求正常处理完毕
  3. 3XX Redirection（重定向状态码） 需要进行附加操作以完成请求
  4. 4XX Client Error（客户端错误状态码） 服务器无法处理请求
  5. 5XX Server Error（服务器错误状态码） 服务器处理请求出错
    总共有 60 多种状态，但经常使用的 有 14中

2XX 的响应结果表明请求被正常处理了

  1. 200 从客户端发来的请求在服务器端被正常处理了。
  2. 204 No Content 该状态码代表服务器接收的请求已成功处理， 但在返回的响应报文中不含实体的主体部分。 另外， 也不允许返回任何实体的主体。 比如，当从浏览器发出请求处理后， 返回 204 响应， 那么浏览器显示的页面不发生更新。
  3. 206 Partial Content 该状态码表示客户端进行了范围请求， 而服务器成功执行了这部分的GET 请求。 响应报文中包含由 Content-Range 指定范围的实体内容。
    http1.1 断点续传 功能 请求头包含 Ranges 属性：

3XX 重定向 表明浏览器需要执行某些特殊的处理以正确处理请求。

301 永久性重定向。 该状态码表示请求的资源已被分配了新的 URI， 以后应使用资源现在所指的 URI， 如果已经把资源对应的 URI保存为书签了， 这时应该按 

Location 首部字段提示的 URI 重新保存

302 临时性重定向。 该状态码表示请求的资源已被分配了新的 URI， 希望用户（本次） 能使用新的 URI 访问。和 301 Moved Permanently 状态码相似， 但 302 状态

码代表的资源不是被永久移动， 只是临时性质的。

304 缓存 协商缓存 该状态码表示客户端发送附带条件的请求 时， 服务器端允许请求访问资源， 但未满足条件的情况。 304 状态码返回时， 不包含任何响应

的主体部分。 304 虽然被划分在 3XX 类别中， 但是和重定向没有关系。

4XX 的响应结果表明客户端是发生错误的原因所在

  1. 400 Bad Request 该状态码表示请求报文中存在语法错误。（参数错误，参数格式错误） 当错误发生时， 需修改请求的内容后再次发送请求。 另外， 浏览器会像 200 OK

一样对待该状态码。

  1. 403 Forbidden 该状态码表明对请求资源的访问被服务器拒绝了 未获得文件系统的访问授权， 访问权限出现某些问题都有可能出现403

  2. 404 Not Found 该状态码表明服务器上无法找到请求的资源

5XX 的响应结果表明服务器本身发生错误

  1. 500 Internal Server Error 该状态码表明服务器端在执行请求时发生了错误

  2. 503 Service Unavailable 该状态码表明服务器暂时处于超负载或正在进行停机维护， 现在无法处理请求。

  3. 504 网关超时

HTTP首部

http协议的请求和响应报文中必定包含http首部

http报文首部一般包含 报文首部 空行 报文体
请求报文首部：一般由 方法 uri http版本 http首部字段等部分构成
响应报文首部：一般由 http版本 状态码（数字和原因短语） http首部字段三部分构成

4种HTTP首部字段类型

HTTP首部字段根据实际用途被分为以下4种类型

  1. 通用首部字段 请求和响应报文两方都会使用的首部

  2. 请求首部字段 从客户端向服务器端发送请求报文时使用的首部。 补充了请求的附加内容、 客户端信息、 响应内容相关优先级等信息。

  3. 响应首部字段 从服务器端向客户端返回响应报文时使用的首部。 补充了响应的附加内容， 也会要求客户端附加额外的内容信息

  4. 实体首部字段 针对请求报文和响应报文的实体部分使用的首部。 补充了资源内容更新时间等与实体有关的信息

通用首部字段

  1. Cache-Control 通过指定首部字段 Cache-Control 的指令， 就能操作缓存的工作机制。参数一般 no-cache，no-store

  2. Connection 1 控制不再转发给代理的首部字段 2 管理持久连接

  3. Date 表明创建 HTTP 报文的日期和时间。

请求首部字段

  1. Accept 首部字段可通知服务器， 用户代理能够处理的媒体类型及媒体类型的相对优先级。 可使用 type/subtype 这种形式， 一次指定多种媒体类型。

  2. Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序

    gzip由文件压缩程序 gzip（GNU zip） 生成的编码格式

    deflate组合使用 zlib 格式（RFC1950） 及由 deflate 压缩算法（RFC1951） 生成的编码格式。

  3. Accept-Language 用来告知服务器用户代理能够处理的自然语言集（指中文或英文等） ， 以及自然语言集的相对优先级。 可一次指定多种自然语言集。

    例如 Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3 按权重值 q 来表示相对优先级

  4. Host 会告知服务器， 请求的资源所处的互联网主机名和端口号。 Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请求内的首部字段 Host: www.hackr.jp

  5. Referer 会告知服务器请求的原始资源的 URI。

  6. User-Agent 会将创建请求的浏览器和用户代理名称等信息传达给服务器

响应首部字段

  1. Accept-Ranges 是用来告知客户端服务器是否能处理范围请求， 以指定获取服务器端某个部分的资源。 bytes / none

  2. Age 能告知客户端， 源服务器在多久前创建了响应。 字段值的单位为秒。若创建该响应的服务器是缓存服务器， Age 值是指缓存后的响应再次发起认证到认证完成的时间

值。 代理创建响应时必须加上首部字段Age。

  1. 首部字段 Location 可以将响应接收方引导至某个与请求 URI 位置不同的资源。 基本上， 该字段会配合 3xx ： Redirection 的响应， 提供重定向的URI。几乎所有的浏览器在接收到包含首部字段 Location 的响应后， 都会强制性地尝试对已提示的重定向资源的访问

  2. Retry-After 告知客户端应该在多久之后再次发送请求。 主要配合状态码 503 Service Unavailable 响应， 或 3xx Redirect 响应一起使用。

  3. 首部字段 Server 告知客户端当前服务器上安装的 HTTP 服务器应用程序的信息

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

  1. Allow 用于通知客户端能够支持 Request-URI 指定资源的所有 HTTP 方法。 当服务器接收到不支持的 HTTP 方法时， 会以状态码405 Method Not Allowed 作为响应返回。 与此同时， 还会把所有能支持的 HTTP 方法写入首部字段 Allow 后返回

  2. Content-Encoding 会告知客户端服务器对实体的主体部分选用的内容编码方式。 内容编码是指在不丢失实体信息的前提下所进行的压缩。

  3. 部字段 Content-Language 会告知客户端， 实体主体使用的自然语言（指中文或英文等语言）。

  4. Content-Location 给出与报文主体部分相对应的 URI。 和首部字段 Location 不同， Content-Location 表示的是报文主体返回资源对应的 URI

  5. Content-Range， 能告知客户端作为响应返回的实体的哪个部分符合范围请求。 字段值以字节为单位， 表示当前发送部分及整个实体大小

  6. Content-Type 说明了实体主体内对象的媒体类型。 和首部字段 Accept 一样，

  7. Expires 会将资源失效的日期告知客户端。

  8. Last-Modified 指明资源最终修改的时间。 一般来说， 这个值就是 Request-URI 指定资源被修改的时间。

Cookie 服务的首部字段

  1. Cookie 的工作机制是用户识别及状态管理

    Set-Cookie 开始状态管理所使用的Cookie信息 响应首部字段

    Cookie 服务器接收到的Cookie信息 请求首部字段

    Set-Cookie 字段的属性

    NAME=VALUE 赋予 Cookie 的名称和其值（必需项）

    expires=DATE Cookie 的有效期（若不明确指定则默认为浏览器关闭前为止）

    path=PATH 将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录）cookie 的存放路径

    domain=域名 作为 Cookie 适用对象的域名 （若不指定则默认为创建 Cookie的服务器的域名） 通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。 比
    如， 当指定 example.com 后， 除 example.com 以外， www.example.com或 www2.example.com 等都可以发送 Cookie

    Secure 仅在 HTTPS 安全通信时才会发送 Cookie

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

确保Web 安全的HTTPS

#### HTTP 的缺点

1. 通信使用明文（不加密） ， 内容可能会被窃听

2. HTTP 协议中的请求和响应不会对通信方进行确认 即（服务器是不是真的请求中的 uri指定的主机，返回的响应是不是真的返回到请求的客户端）

3. 无法证明报文完整性， 可能已遭篡改 由于 HTTP 协议无法证明通信的报文完整性， 因此， 在请求或响应送出之后直到对方接收之前的这段时间内， 即使请求或响应的

内容遭到篡改， 也没有办法获悉。换句话说， 没有任何办法确认， 发出的请求 / 响应和接收到的请求 / 响应是前后相同的

什么是HTTPS

 HTTPS = HTTP+ 加密 + 认证 + 完整性保护 (http + 通信加密 + 证书 + 完整性保护)  HTTPS 并不是一种新的协议，只是http 通信部分接口用SSL 协议代替而已；
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容