乐趣区

关于http:HTTP协议概述

jiezi

HTTP 历史

起源

蒂姆·伯纳斯·李（Tim Berners-Lee）爵士（1955 年出生于英国）是万维网的发明者，互联网之父。

1989 年，欧洲核子钻研组织（CERN）的蒂姆·博纳斯 - 李（Tim Berners-Lee）博士提出一个构想：借助多文档之间互相关联造成的超文本（HyperText），连成可参阅的 WWW（World Wide Web，万维网），以帮忙远隔两地的研究者们共享常识。在这个构想中，他提出了 3 项 WWW 构建的关键技术：HTML, URI, HTTP.

互联网之父：蒂姆·伯纳斯·李（Tim Berners-Lee）、温顿·瑟夫 (Vint Cerf 原名：Vinton Gray “Vint” Cerf）、罗伯特·卡恩（Robert Elliot Kahn）等。


@Tim Berners-Lee

HTTP 0.9

1989 年 Tim Berners-Lee 蒂姆·伯纳斯 - 李在其论文中确立了：

1. URI：对立资源标识符
2. HTML：超文本标记语言
3. HTTP：超文本传输协定

这个版本的 HTTP 只容许 Get 办法。

HTTP 1.0

1996 年正式公布

  1. 减少 HEAD、POST 等新办法；
  2. 减少响应状态码（status code），标记可能的谬误起因；
  3. 引入了协定版本号概念；
  4. 引入了 HTTP Header 的概念，让 HTTP 解决申请和响应更加灵便；
  5. 传输的数据不再限于文本；

此时的 HTTP/1.0 还只是一份参考文档，不是正式规范

HTTP 1.1

1999 年 HTTP/1.1 公布 RFC 文档 2616，前面拆分成了 RFC7230

  1. 减少了 PUT、DELETE、OPTIONS 等新的办法；
  2. 减少了缓存治理和管制；
  3. 明确了连贯放弃（keep-alive），容许继续连贯；
  4. 容许响应数据分块（chunked），利于传输大文件；
  5. 强制要求 Host 头，让互联网主机托管成为可能；

HTTP/1.1 优缺点

  1. HTTP 最大的长处是简略、灵便和易于扩大；
  2. HTTP 领有成熟的软硬件环境，利用的十分宽泛，是互联网的基础设施；
  3. HTTP 是无状态的，能够轻松实现集群化，扩大性能，但有时也须要用 Cookie 技术来实现“有状态”；
  4. HTTP 是明文传输，数据齐全肉眼可见，可能不便地钻研剖析，但也容易被窃听；
  5. HTTP 是不平安的，无奈验证通信单方的身份，也不能判断报文是否被篡改；
  6. HTTP 的性能不算差，但不齐全适应当初的互联网，还有很大的晋升空间。

HTTP 2

2015 年 RFC-7540，起初叫做 SPDY 协定

  1. 二进制协定，不再是纯文本；
  2. 可发动多个申请，废除了 1.1 里的管道；
  3. 应用专用算法压缩头部，缩小数据传输量；
  4. 容许服务器被动想客户端推送数据；
  5. 加强了安全性，事实上要求加密通信。

HTTP 2.0 通过头压缩、分帧、二进制编码、多路复用等技术晋升性能；
面临的问题：次要市场还是在 1.1 的时代，普及率比拟低。
应用 TCP 存在的问题：建设连贯耗时 (1.5RTT); 进行 TLS 连贯耗时 (1-2RTT); TCP 的队头阻塞并没有彻底解决 (丢包重传)

HTTP 3

目前还没正式公布，是有 Google 发动的心协定，叫做 QUIC 协定，在 2018 年，互联网标准化组织 IETF 将 HTTP over QUIC 改名为 HTTP 3.
QUIC 协定通过基于 UDP 自定义的相似 TCP 的连贯、重试、多路复用、流量控制技术，进一步晋升性能。

从古至今实时数据传输（音频、视频、游戏等）都面临卡顿、提早等问题，而 QUIC 基于 UDP 的架构和改良的重传等个性，可能无效的晋升用户体验。
目前 B 站 也曾经接入 QUIC。

HTTPS

HTTPS 协定（HyperText Transfer Protocol over Secure Socket Layer）：个别了解为 HTTP+SSL/TLS，通过 SSL 证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。

由网景公司（Netscape）在 1994 年首次提出，随后扩大到互联网上。
在 2000 年代末至 2010 年代初，HTTPS 开始宽泛应用，以确保各类型的网页实在，爱护账户和放弃用户通信，身份和网络浏览的私密性。

那么 SSL 又是什么？

SSL（Secure Socket Layer，安全套接字层）：1994 年为 Netscape 所研发，SSL 协定位于 TCP/IP 协定与各种应用层协定之间，为数据通讯提供平安反对。

TLS（Transport Layer Security，传输层平安）：其前身是 SSL，它最后的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999 年从 3.1 开始被 IETF 标准化并改名，倒退至今曾经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。

SSL3.0 和 TLS1.0 因为存在安全漏洞，曾经很少被应用到。TLS 1.3 改变会比拟大，目前还在草案阶段，目前应用最宽泛的是 TLS 1.1、TLS 1.2。

SSL 发展史（互联网加密通信）

  1. 1994 年 NetSpace 公司设计 SSL 协定（Secure Sockets Layout）1.0 版本，但未公布。
  2. 1995 年 NetSpace 公布 SSL/2.0 版本，很快发现有重大破绽
  3. 1996 年公布 SSL/3.0 版本，失去大规模利用
  4. 1999 年，公布了 SSL 升级版 TLS/1.0 版本，目前利用最宽泛的版本
  5. 2006 年和 2008 年，公布了 TLS/1.1 版本和 TLS/1.2 版本

HTTP 是什么？

在 HTTP/1.1 最新规范 RFC7230 中，是这么定义 HTTP 的：

The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible integration with network-based hypertext information systems.

HTTP 协定是一种无状态的、处于应用层的、以申请 / 应答形式运行的协定，应用可扩大的语义和自描述的信息格式，与基于网络的超文本信息系统灵便的相互作用。

关键词：无状态、援用层、申请 / 应答、可扩大的语义、自描述、超文本

网络分层到底是什么？

OSI 概念模型

OSI（Open System Interconnection Reference Model），开放式系统互联通信参考模型，也就是咱们常说的 7 层模型。从它的名称就可以看进去，OSI 只是一个供参考的概念模型，它从未被真正的实现。

TCP/IP 模型

OSI 只是一个概念模型，而平时工作咱们最罕用的还是 TCP/IP 模型。TCP/IP 模型其实就是 OSI 模型的简化版本，也就是咱们平时所说的 4 层模型。


@ TCP/IP 四层模型

其实 TCP/IP 模型与 OSI 模型十分相似，次要是省略了表示层、会话层与物理层的实现。
上面是一张 OSI 模型与 TCP/IP 模型的层级对照图，大家能够通过对照图来总结 TCP/IP 模型中各层的职责。


@ OSI 七层模型与 TCP/IP 四层模型比照图

Http 报文

申请报文 

GET / HTTP/1.1
Host: 127.0.0.1:9090
Connection: keep-alive
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8


@ HTTP 申请报文

响应报文 

HTTP/1.1 200 ok
Connection: keep-alive
Content-Length: 164
Content-Type: text/html
Date: Sat, 06 Jun 2020 01:53:57 GMT

<html>
...


@ HTTP 响应报文

HTTP 协定的无状态与长久连贯

通常，为了保留状态，服务器发送的响应报文中会有一个 Set-Cookie 的首部字段，客户端获取到该报文后，就能够保留 Cookie。下一次申请时，客户端会将保留的 Cookie 携带在申请报文中发送给服务器，服务器拿到 Cookie 后进行比对，就能够晓得是从哪个客户端发来的申请了。


@ 携带 Cookie 的 HTTP 传输过程

常见 HTTP 头

HTTP 的实体数据 - 内容协商

“多用途互联网邮件扩大”（Multipurpose Internet Mail Extensions），简称为 MIME。

Accept <=> Content-Type

Accept 是客户端可承受的 MIME type，对应的是响应报文里 Content-Type。

Content-type：

  1. text：文本格式的可读数据，text/html、text/plain、text/css
  2. image：图像文件，image/gif、image/jpeg、image/png
  3. audio/video：音频和视频数据，audio/mpeg、video/mp4
  4. application：数据格式不固定，必须由下层应用程序来解释。application/json、application/javascript、application/pdf；application/octet-stream 即不通明的二进制数据。

Accept-Encoding <=> Content-Encoding

Accept-Encoding: 该字段标记的是客户端反对的压缩格局

Content-Encoding:

  1. gzip：GNU zip 压缩格局，也是互联网上最风行的压缩格局；
  2. deflate：zlib（deflate）压缩格局，风行水平仅次于 gzip；
  3. br：一种专门为 HTTP 优化的新压缩算法（Brotli）。

Accept-Language <=> Content-Language

对应客户端反对的语言和响应的语言类型：

type-subtype：en-US 美式英语、en-GB 英式英语、zh-CN 汉语 

1. 数据类型示意实体数据的内容是什么，应用的是 MIME type，相干的头字段是 Accept 和 Content-Type；2. 数据编码示意实体数据的压缩形式，相干的头字段是 Accept-Encoding 和 Content-Encoding；3. 语言类型示意实体数据的自然语言，相干的头字段是 Accept-Language 和 Content-Language；4. 字符集示意实体数据的编码方式，相干的头字段是 Accept-Charset 和 Content-Type；5. 客户端须要在申请头里应用 Accept 等头字段与服务器进行“内容协商”，要求服务器返回最合适的数据；6. Accept 等头字段能够用“,”程序列出多个可能的选项，还能够用“;q=”参数来准确指定权重。

Range <=> Acceot-Range

bytes & Content-Range: bytes 0-31/96

Transfer-Encoding: chunked 分块传输的编码规定:

“Transfer-Encoding: chunked”和“Content-Length”这两个字段是互斥的，也就是说响应报文里这两个字段不能同时呈现，一个响应报文的传输要么是长度已知，要么是长度未知（chunked）。

Cookie <=> Set-Cookie

Cookie 属性 

HTTP/1.1 200
Set-Cookie: key=value, Max-Age=10; Expires=Fri, 08-Jun-22 08:19:00 GMT; Domain=www.example.com; Path=/; HttpOnly; SameSite=Strict;

Expires 和 Max-Age 都能管制 Cookie 的有效期，然而浏览器会优先采纳 Max-Age 计算有效期；

HttpOnly => 防备 XSS（跨站脚本）攻打 

 在 JS 脚本里能够用 document.cookie 来读写 Cookie 数据，这就带来了安全隐患，有可能会导致“跨站脚本”（XSS）攻打窃取数据。属性“HttpOnly”会通知浏览器，此 Cookie 只能通过浏览器 HTTP 协定传输，禁止其余形式拜访，浏览器的 JS 引擎就会禁用 document.cookie 等所有相干的 API，脚本攻打也就无从谈起了。

SameSite => 防备 XSRF（跨站申请伪造）攻打

  1. SameSite=Strict：严格限度 Cookie 不能随着跳转链接跨站发送
  2. SameSite=Lax：容许 GET/HEAD 等平安办法，然而禁止 POST 跨站发送

Cache-Control

缓存管制头 

HTTP/1.1 200
Cache-Control: max-age=30, no-store, no-cache, must-revalidate, proxy-revalidate, public
  1. max-age：用于管制 HTTP 缓存，绝对于服务器的响应工夫；
  2. public/private：public 在代理服务器和两头节点都能缓存，然而 private 只有在指标客户端能够缓存；
  3. no-store：<u> 不容许缓存 </u>，用于变动十分频繁的数据，例如秒杀页面；
  4. no-cache：<u> 能够缓存 </u>，但在应用之前要去服务器验证是否过期，是否有最新的版本；
  5. must-revalidate：如果缓存不过期就能够持续应用，但过期了还想应用须要找服务器验证；
  6. proxy-revalidate：与 must-revalidate 相似，然而只有公共资源能够在代理服务器缓存，仅限 public 的配置的资源；

条件申请 

If-Modified-Since: Mon, 27 Jul 2020 10:53:40 GMT
If-None-Match: W/"5f1eb234-b7e"

条件申请的两个字段须要配合 ETag 和 Last-modified 能力起效，在第一次申请的时候，服务器返回下面两个字段；再次申请资源的时候，浏览器会带上这两个资源，应用 If-modified-since 和 If-none-Match 来验证资源是否过期。如果服务器返回 304 则读取浏览器的缓存文件。

参考

[1] 极客工夫 –《趣谈网络协议》

[2] 极客工夫 –《透视 HTTP 协定》

退出移动版