HTTP协议概述

头像
落日楼台H
    阅读 6 分钟

    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）等。

    v2_3d104486596041fa8f76865e83a1fde6_img_000
    @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 只是一个供参考的概念模型，它从未被真正的实现。

    786279743fc8a92a9f9e19310350f7bd

    TCP/IP 模型

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

    ae5f9d5f4d15cb209d3260b8848f80ef
    @ TCP/IP 四层模型

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

    8b78d97dbadaf2cbf5243b48ebec8332
    @ 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

    1d50925993cb03cb5388f7a9ad2582e2
    @ 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>
...

    9c1043faba50c472f173e376e83be475
    @ HTTP 响应报文

    HTTP 协议的无状态与持久连接

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

    37903d2dc04fb6843eb789205d43eac3
    @ 携带 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 汉语

    b2118315a977969ddfcc7ab9d26cb358

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

    httphttpshttp首部协议
    落日楼台H
    1 声望0 粉丝
    « 上一篇
    Java-Mock简化单元测试
    下一篇 »
    Java 中 HashSet 的 removeAll 性能分析

    引用和评论

    推荐阅读
    头像
    Java进程CPU100%打满分析

    落日楼台H阅读 528

    头像
    IP地址证书需要验证吗？

    JoySSL230907赞 2阅读 332评论 1

    头像
    局域网/内网IP地址配置https证书教程

    帅崽赞 2阅读 653

    头像
    手把手教你如何免费申请知名品牌的SSL证书，保护网站数据安全！

    才高八斗的扁豆赞 1阅读 542

    头像
    SSL证书概述、类型、价格、作用及应用等10大常见问题解答

    锐成信息Racent阅读 3.7k

    头像
    TLSv1.3 Support：主流 Web 客户端和服务端对 TLSv1.3 的支持情况

    sysin阅读 2.7k

    头像
    如何设置Fiddler来拦截Java代码发送的HTTP请求，进行各种问题排查

    注销阅读 2.6k

    0 条评论
    得票最新