写点什么

HTTP 协议概述

用户头像
落日楼台H
关注
发布于: 2020 年 12 月 04 日
HTTP协议概述

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 技术来实现“有状态”;


  1. HTTP 是明文传输,数据完全肉眼可见,能够方便地研究分析,但也容易被窃听;

  2. HTTP 是不安全的,无法验证通信双方的身份,也不能判断报文是否被窜改;

  3. 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.1Host: 127.0.0.1:9090Connection: keep-aliveAccept-Language: zh-CN,zh;q=0.9,en;q=0.8
复制代码


@ HTTP 请求报文


响应报文


HTTP/1.1 200 okConnection: keep-aliveContent-Length: 164Content-Type: text/htmlDate: 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 200Set-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 200Cache-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 GMTIf-None-Match: W/"5f1eb234-b7e"
复制代码


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




参考


[1] 极客时间 - 《趣谈网络协议》

[2] 极客时间 - 《透视 HTTP 协议》


发布于: 2020 年 12 月 04 日阅读数: 582
用户头像

落日楼台H

关注

还未添加个人签名 2019.03.05 加入

还未添加个人简介

评论

发布
暂无评论
HTTP协议概述