关于http:HTTP协议概述

50次阅读

共计 5612 个字符,预计需要花费 15 分钟才能阅读完成。

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 协定》

正文完
 0