HTTP 一、基础知识

一、概述

        1、概述  

• HTTP（Hyper Text Transfer Protocol）： 全称超文本传输协议，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
• HTTP 是一种应用层协议，是基于 TCP/IP 通信协议来传递数据的，其中 HTTP1.0、HTTP1.1、HTTP2.0 均为 TCP 实现，HTTP3.0 基于 UDP 实现。现主流使用 HTTP1.0 和 HTTP3.0
• 协议： 为了使数据在网络上从源头到达目的，网络通信的参与方必须遵循相同的规则，这套规则称为协议，它最终体现为在网络上传输的数据包的格式。

通俗点讲，协议就是要保证网络通信的双方，能够互相对接上号。就像是两个人传递纸条通过互相指定的暗号，如果发送天亮了，表示可以打游戏了等等

        2、历史

     （1）HTTP诞生：
​         1989 年，任职于欧洲核子研究中心（CERN）的蒂姆·伯纳斯 - 李（Tim Berners-Lee）发表了一篇论文，提出了在互联网上构建超链接文档系统的构想。这篇论文中他确立了三项关键技术。

• URI：即统一资源标识符，作为互联网上资源的唯一身份；
• HTML：即超文本标记语言，描述超文本文档；
• HTTP：即超文本传输协议，用来传输超文本。

       （2）HTTP/0.9
        ​ 最早版本是1991年发布的0.9版。该版本极其简单，只有一个命令GET。        
         TCP 连接（connection）建立后，客户端向服务器请求（request）网页，协议规定，服务器只能回应HTML格式的字符串，不能回应别的格式。服务器发送完毕，就关闭TCP连接。

        

      （3）HTTP/1.0
        ​ 1996年5月，HTTP/1.0 版本发布，内容大大增加。但 HTTP/1.0 并不是一个“标准”，只是记录已有实践和模式的一份参考文档，不具有实际的约束力，相当于一个“备忘录”。
        增加了 HEAD、POST 等新方法；
        增加了响应状态码，标记可能的错误原因；
        引入了协议版本号概念；
        引入了 HTTP Header（头部）的概念，让 HTTP 处理请求和响应更加灵活；
        传输的数据不再仅限于文本。

        

      （4）HTTP/1.1
​         1997年1月，HTTP/1.1 版本发布，只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议，一直用到了20年后的今天，直到现在还是最流行的版本。HTTP/1.1 是对 HTTP/1.0 的小幅度修正，但它是一个“正式的标准”，而不是一份可有可无的“参考文档”。
        增加了 PUT、DELETE 等新的方法；
        增加了缓存管理和控制；
        明确了连接管理，允许持久连接；
        允许响应数据分块（chunked），利于传输大文件；
        强制要求 Host 头，让互联网主机托管成为可能。

     （5）SPDY 协议
        ​2009年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。
        这个协议在Chrome浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。

        

     （6）HTTP/2
​         2015年，HTTP/2 发布。它不叫 HTTP/2.0，是因为标准委员会不打算再发布子版本了，下一个新版本将是 HTTP/3。HTTP/2 的制定充分考虑了现今互联网的现状：宽带、移动、不安全，在高度兼容HTTP/1.1 的同时在性能改善方面做了很大努力，主要的特点有：
        二进制协议，不再是纯文本；
        可发起多个请求，废弃了 1.1 里的管道；
        使用专用算法压缩头部，减少数据传输量；
        允许服务器主动向客户端推送数据；
        增强了安全性，“事实上”要求加密通信。
​         虽然 HTTP/2 已经发布好几年，也衍生出了 gRPC 等新协议，但由于 HTTP/1.1 实在是太过经典和强势，目前它的普及率还比较低，大多数网站使用的仍然还是 20 年前的HTTP/1.1。

        

        （7）HTTP/3
​         2022年6月6日，IETF （互联网工程任务小组） 正式发布了 HTTP/3 的 RFC。
        ​ 在 HTTP/2 还处于草案之时，Google 又发明了一个新的协议，叫做 QUIC，而且还是相同的“套路”，继续在 Chrome 和自家服务器里试验着“玩”，依托它的庞大用户量和数据量，持续地推动 QUIC 协议成为互联网上的“既成事实”。
        也就是 2018 年，互联网标准化组织 IETF 提议将“HTTP over QUIC”更名 为“HTTP/3”并获得批准，HTTP/3 正式进入了标准化制订阶段。

        

        （8）总结
        HTTP 协议始于三十年前蒂姆·伯纳斯 - 李的一篇论文；
        HTTP/0.9 是个简单的文本协议，只能获取文本资源；
        HTTP/1.0 确立了大部分现在使用的技术，但它不是正式标准；
        HTTP/1.1 是目前互联网上使用最广泛的协议，功能也非常完善；
        HTTP/2 基于 Google 的 SPDY 协议，注重性能改善，但还未普及；
        HTTP/3 基于 Google 的 QUIC 协议，是将来的发展方向。

        3、关联概念

     （1）网络世界
​         互联网的正式名称是 Internet，里面存储着无穷无尽的信息资源，我们通常所说的“上 网”实际上访问的只是互联网的一个子集“万维网”（World Wide Web），它基于 HTTP 协议，传输 HTML 等超文本资源，能力也就被限制在 HTTP 协议之内。现在的互联网 90% 以上的部分都被万维网，也就是 HTTP 所覆盖。

        

        （2）浏览器
        ​ 浏览器的正式名字叫“Web Browser”，顾名思义，就是检索、查看互联网上网页资源的 应用程序，名字里的 Web，实际上指的就是“World Wide Web”，也就是万维网。
        浏览器本质上是一个 HTTP 协议中的请求方，使用 HTTP 协议获取网络上的各种资源。

        

        （3）Web 服务器
         Web 服务器是一个很大也很重要的概念，它是 HTTP 协议里响应请求的主体，通常有软件和硬件两层含义，硬件就是提供web服务的硬件机器，软件就是提供 Web 服务的应用程序，常用的有Apache和Nginx。

        

        （4）CDN
​         CDN，全称是“Content Delivery Network”，翻译过来就是“内容分发网络”。它应用 了 HTTP 协议里的缓存和代理技术，代替源站响应客户端的请求。它可以缓存源站的数据，大幅度缩短响应时间。
         除了基本的网络加速外，还提供负载均衡、 安全防护、边缘计算、跨运营商网络等功能，能够成倍地“放大”源站服务器的服务能力。

        

        （5）爬虫
​         爬虫实际上是一种可以自动访问Web资源的应用程序。绝大多数是由各大搜索引擎“放”出来的，抓取网页存入庞大的数据库，再建立关键字索 引，这样我们才能够在搜索引擎中快速地搜索到互联网角落里的页面。

         爬虫也有不好的一面，它会过度消耗网络资源，占用服务器和带宽，影响网站对真实数据的 分析，甚至导致敏感信息泄漏。所以，又出现了“反爬虫”技术，通过各种手段来限制爬 虫。其中一项就是“君子协定”robots.txt，约定哪些该爬，哪些不该爬。

        

        （6）DNS
        ​ 在 TCP/IP 协议中使用 IP 地址来标识计算机，数字形式的地址对于计算机来说是方便了， 但对于人类来说却既难以记忆又难以输入。 于是“域名系统”（Domain Name System）出现了，用有意义的名字来作为 IP 地址的 等价替代。
        ​ 域名用“.”分隔成多个单词，级别从左到右逐级升高，最右边的被称为“顶级域名”。
        但想要使用 TCP/IP 协议来通信仍然要使用 IP 地址，所以需要把域名做一个转换，“映 射”到它的真实 IP，这就是所谓的“域名解析”。
          

        

       （7）URI/URL
​         URI（Uniform Resource Identifier），中文名称是统一资源标识符，使用它就能够唯一地标记互联网上资源。
        URI 另一个更常用的表现形式是 URL（Uniform Resource Locator）， 统一资源定位符，也就是我们俗称的“网址”，它实际上是 URI 的一个子集，不过因为这两者几乎是相同的，差异不大，所以通常不会做严格的区分。

​         URN：Uniform Resource Name，统一资源名称，也是URI的一个子集。

​         URI 主要有三个基本的部分构成：协议名，即访问该资源应当使用的协议；主机名，即互联网上主机的标记，可以是域名或 IP 地址；路径，即资源在主机上的位置，使用“/”分隔多级目录。

        

        （8）HTTPS
        ​ HTTPS全称是“HTTP over SSL/TLS”，也就是 运行在 SSL/TLS 协议上的 HTTP，它是一个负责加密通信的安全协议，建 立在 TCP/IP 之上，所以也是个可靠的传输协议，可以被用作 HTTP 的下层。
        ​ SSL 的全称是“Secure Socket Layer”，由网景公司发明，当发展到 3.0 时被标准化，改 名为 TLS，即“Transport Layer Security”，但由于历史的原因还是有很多人称之为 SSL/TLS，或者直接简称为 SSL。
        SSL 使用了许多密码学最先进的研究成果，综合了对称加密、非对称加密、摘要算法、数字 签名、数字证书等技术，能够在不安全的环境中为通信的双方创建出一个秘密的、安全的传输通道。

        （9）代理
​         代理（Proxy）是 HTTP 协议中请求方和应答方中间的一个环节，作为“中转站”，既可以 转发客户端的请求，也可以转发服务器的应答。

        ​ 代理有很多的种类，常见的有：
        匿名代理：完全“隐匿”了被代理的机器，外界看到的只是代理服务器；
        透明代理：顾名思义，它在传输过程中是“透明开放”的，外界既知道代理，也知道客 户端；
        正向代理：靠近客户端，代表客户端向服务器发送请求；
        反向代理：靠近服务器端，代表服务器响应客户端的请求；
​
        由于代理在传输过程中插入了一个“中间层”，所以可以在这个环节做很多有意思的事情， 比如：
        负载均衡：把访问请求均匀分散到多台机器，实现访问集群化；
        内容缓存：暂存上下行的数据，减轻后端的压力；
        安全防护：隐匿 IP, 使用 WAF 等工具抵御网络攻击，保护被代理的机器；
        数据处理：提供压缩、加密等额外的功能。

        4、访问Web服务器

        （1）IP地址访问Web服务器

        

        简要叙述最简单的浏览器 HTTP 请求过程：

1. 浏览器从地址栏的输入中获得服务器的 IP 地址和端口号；

2. 浏览器用 TCP 的三次握手与服务器建立连接；

3. 浏览器向服务器发送拼好的报文；

4. 服务器收到报文后处理请求，同样拼好报文再发给浏览器；

5. 浏览器解析报文，渲染输出页面。

         （2）使用域名访问Web服务器

        在浏览器地址栏里直接输入 IP 地址可以访问服务器，但绝大多数情况下，我们是不知道服务器IP 地址的，使用的是域名。浏览器看到了网址里的域名，发起域名解析动作，把这个域名翻译成 TCP/IP 协议里的 IP 地址。

        ​ 不过因为域名解析的全过程实在是太复杂了，如果每一个域名都要大费周折地去网上查一下，那我们上网肯定会慢得受不了。所以，在域名解析的过程中会有多级的缓存，浏览器首先看一下自己的缓存里有没有，如果没有就向操作系统的缓存要，还没有就检查本机域名解析文件 hosts，也就是上一讲中我们修改的“C:\WINDOWS\system32\drivers\etc\hosts”。

​         刚好，里面有一行映射关系“127.0.0.1 www.chrono.com”，于是浏览器就知道了域名对应的 IP 地址，就可以愉快地建立 TCP 连接发送 HTTP 请求了。

        

        （3）真实的网络世界

         如果你用的是电脑台式机，那么你可能会使用带水晶头的双绞线连上网口，由交换机接入固定网络。如果你用的是手机、平板电脑，那么你可能会通过蜂窝网络、WiFi，由电信基站、无线热点接入移动网络。接入网络的同时，网络运行商会给你的设备分配一个 IP 地址，这个地址可能是静态分配的，也可能是动态分配的。静态 IP 就始终不变，而动态 IP 可能你下次上网就变了。

        ​ 假设你要访问的是 Apple 网站，显然你是不知道它的真实 IP 地址的，在浏览器里只能使用域名“www.apple.com”访问，那么接下来要做的必然是域名解析。这就要用 DNS 协议开始从操作系统、本地 DNS、根 DNS、顶级 DNS、权威 DNS 的层层解析，当然这中间有缓存，可能不会费太多时间就能拿到结果。

​         DNS 解析可能会给出 CDN 服务器的 IP 地址，这样你拿到的就会是 CDN 服务器而不是目标网站的实际地址。因为 CDN 会缓存网站的大部分资源，比如图片、CSS 样式表，所以有的 HTTP 请求就不需要再发到 Apple，CDN 就可以直接响应你的请求，把数据发给你。

​         由 PHP、Java 等后台服务动态生成的页面属于“动态资源”，CDN 无法缓存，只能从目标网站获取。于是你发出的 HTTP 请求就要开始在互联网上的“漫长跋涉”，经过无数的路由器、网关、代理，最后到达目的地。

​         目标网站的服务器对外表现的是一个 IP 地址，但为了能够扛住高并发，在内部也是一套复杂的架构。通常在入口是负载均衡设备，例如四层的 LVS 或者七层的 Nginx，在后面是许多的服务器，构成一个更强更稳定的集群。

​         负载均衡设备会先访问系统里的缓存服务器，通常有 memory 级缓存 Redis 和 disk 级缓存 Varnish，它们的作用与 CDN 类似，不过是工作在内部网络里，把最频繁访问的数据缓存几秒钟或几分钟，减轻后端应用服务器的压力。

​         如果缓存服务器里也没有，那么负载均衡设备就要把请求转发给应用服务器了。这里就是各种开发框架大显神通的地方了，例如 Java 的 Tomcat/Netty/Jetty，Python 的 Django，还有 PHP、Node.js、Golang 等等。它们又会再访问后面的 MySQL、PostgreSQL、MongoDB 等数据库服务，实现用户登录、商品查询、购物下单、扣款支付等业务操作，然后把执行的结果返回给负载均衡设备，同时也可能给缓存服务器里也放一份。

​         应用服务器的输出到了负载均衡设备这里，请求的处理就算是完成了，就要按照原路再走回去，还是要经过许多的路由器、网关、代理。如果这个资源允许缓存，那么经过 CDN 的时候它也会做缓存，这样下次同样的请求就不会到达源站了。

​         最后网站的响应数据回到了你的设备，它可能是 HTML、JSON、图片或者其他格式的数据，需要由浏览器解析处理才能显示出来，如果数据里面还有超链接，指向别的资源，那么就又要重走一遍整个流程，直到所有的资源都下载完。

二、基本概念

        1、报文结构

        HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

• 起始行（start line）：描述请求或响应的基本信息；
• 头部字段集合（header）：使用 key-value 形式更详细地说明报文；
• 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

​         这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”。

​         HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。

        

        如下是一个http报文实例

        

​         在这个浏览器发出的请求报文里，第一行“GET /HTTP/1.1”就是请求行，而后面的“Host”“Connection”等等都属于 header，报文的最后是一个空白行结束，没有 body。很多时候，特别是浏览器发送 GET 请求的时候都是这样，HTTP 报文经常是只有 header 而没 body。

        完整的Http请求：

        完整的 HTTP 响应：

        2、请求行

        请求行，也就是请求报文里的起始行，它简要地描述了客户端想要如何操作服务器端的资源。请求行由三部分构成：

• 请求方法：是一个动词，如 GET/POST，表示对资源的操作；
• 请求目标：通常是一个 URI，标记了请求方法要操作的资源；
• 版本号：表示报文使用的 HTTP 协议版本。

​ 这三个部分通常使用空格（space）来分隔，最后要用CRLF 换行表示结束。

        在如下的请求行里，“GET”是请求方法，“/”是请求目标，“HTTP/1.1”是版本号。

GET / HTTP/1.1

        

        3、状态行

        状态行，也就是响应报文里的起始行，意思是服务器响应的状态。状态行也有三部分构成：

• 版本号：表示报文使用的 HTTP 协议版本；
• 状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
• 原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。

        在如下的状态行里，这个报文使用的协议版本号是 1.1，状态码是 200，一切OK。

HTTP/1.1 200 OK

        4、头部字段

         请求行或状态行再加上头部字段集合就构成了 HTTP 报文里完整的请求头或响应头，如下：

        头部字段是 key-value 的形式，key 和 value 之间 用“:”分隔，最后用 CRLF 换行表示字段结束。HTTP 头字段非常灵活，不仅可以使用标准里的 Host、 Connection 等已有头，也可以任意添加自定义头，这就给 HTTP 协议带来了无限的扩展可能。不过使用头字段需要注意下面几点：

• 字段名不区分大小写，例如“Host”也可以写 成“host”，但首字母大写的可读性更好；
• 字段名里不允许出现空格，可以使用连字符“-”，但不 能使用下划线“_”。例如，“test-name”是合法的字 段名，而“test name”“test_name”是不正确的字段 名；
• 字段名后面必须紧接着“:”，不能有空格，而“:”后的 字段值前可以有多个空格；
• 字段的顺序是没有意义的，可以任意排列不影响语义；
• 字段原则上不能重复，除非这个字段本身的语义允许，例 如 Set-Cookie。

        5、常用头字段

        HTTP 协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类：

• 通用字段：在请求头和响应头里都可以出现；
• 请求字段：仅