全部标签
写点什么
开源云计算行业资讯玩转写作平台算法Python人工智能区块链Linux前端个人成长面试架构师编程企业动态新基建敏捷安全读书笔记高效工作团队管理创业活动专区生涯规划知识管理运维产品经理 查看更多

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

版权声明: 本文为 InfoQ 作者【落日楼台H】的原创文章。

原文链接:【http://xie.infoq.cn/article/c164d2f74dc10d6a21d126ea4】。文章转载请联系作者。

httpsHTTP协议HTTP2.0HTTP3.0
用户头像

落日楼台H

关注

还未添加个人签名 2019.03.05 加入

还未添加个人简介

评论

发布
暂无评论
Copyright © 2021, Geekbang Technology Ltd. All rights reserved. 极客邦控股（北京）有限公司 | 京 ICP 备 16027448 号 - 5京公网安备京公网安备 11010502039052号
HTTP协议概述