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 协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类：

• 通用字段：在请求头和响应头里都可以出现；
• 请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
• 响应字段：仅能出现在响应头里，补充说明响应报文的信 息；
• 实体字段：它实际上属于通用字段，但专门描述 body 的 额外信息。

        （1）Host（请求字段）（必填字段）
​         请求字段，只能出现在请求头里，它同时也是唯一一个 HTTP/1.1 规范里要求必须出现的字段，也就是说，如果请求头里没有 Host，那这就是 一个错误的报文。
        Host 字段告诉服务器这个请求应该由哪个主机来处理，当 一台计算机上托管了多个虚拟主机的时候，服务器端就需要 用 Host 字段来选择，有点像是一个简单的“路由重定 向”。
        例如在 127.0.0.1 上有三个虚拟主机，那么当使用域名的方式访问时，就必须要用 Host 字段来区分这三个 IP 相同但域名不同的网站，否则服务器 就会找不到合适的虚拟主机，无法处理。

       （2）User-Agent（请求字段）
​         请求字段，只出现在请求头里。它使用一个字符串来描述发起 HTTP 请求的客户端，服务器可以依据它来返回最合适此浏览器显示的页面。
        ​ 由于历史的原因，User-Agent 非常混乱，每个浏览器都自称是“Mozilla”“Chrome”“Safari”，企图使用这个 字段来互相“伪装”，导致 User-Agent变得越来越长，最终变得毫无意义。
        不过有的比较“诚实”的爬虫会在 User-Agent 里用“spider”标明自己是爬虫，所以可以利用这个字段实现简单的反爬虫策略。

        （3）Date（通用字段）
​         通用字段，但通常出现在响应头里，表示 HTTP 报文创建的时间，客户端可以使用这个时间再搭配其 他字段决定缓存策略。

        （4）Server（响应字段）
​         响应字段，只能出现在响应头里。它告诉客户 端当前正在提供 Web 服务的软件名称和版本号，例如“Server: openresty/1.15.8.1”， 即使用的是 OpenResty 1.15.8.1。
        Server 字段也不是必须要出现的，因为这会暴露服务器信息，如果这个版本恰好存在bug，那么黑客就有可能利用bug攻陷服务器。所以，有的网站响应头里要么没有这个字段，要么就给出一个完全无关的描述信息。比如 GitHub，它的 Server 字段里只是显示为“GitHub.com”。

        （5）Content-Length（实体字段）
​         它表示报文里body 的长度，也就是请求头或响应头空行后面数据的长度。服务器看到这个字段，就知道了后续有多少数据，可以直接接收。如果没有这个字段，那么 body 就是不定长的，需要使用 chunked 方式分段传输。

        6、请求方法

        （1）标准请求方法
​         URI只能定位资源，但是怎么操作资源，需要有某种动作指令，所以，就这么出现了“请求方法”。它的实际含义就 是客户端发出了一个“动作指令”，要求服务器端对 URI 定 位的资源执行这个动作。
        目前 HTTP/1.1 规定了八种方法，单词都必须是大写的形 式，我先简单地列把它们列出来，后面再详细讲解。

1. GET：获取资源，可以理解为读取或者下载数据；
2. HEAD：获取资源的元信息；
3. POST：向资源提交数据，相当于写入或上传数据；
4. PUT：类似 POST；
5. DELETE：删除资源；
6. CONNECT：建立特殊的连接隧道；
7. OPTIONS：列出可对资源实行的方法；
8. TRACE：追踪请求 - 响应的传输路径。

​         虽然客户端发出了这些明确的操作指令，但是执行的最终还是服务器，服务器不一定按照客户端的要求进行操作资源，比如，DELETE不一定删除资源，也可以提交数据。

        （2）常用–Get（从服务器获取资源）
        ​ 它的含义是请求从服务器获取资源，这个资源既可以是静态 的文本、页面、图片、视频，也可以是由 PHP、Java 动态 生成的页面或者其他格式的数据。
        GET 方法虽然基本动作比较简单，但搭配 URI 和其他头字 段就能实现对资源更精细的操作。例如，在 URI 后使用“#”，就可以在获取页面后直接定位 到某个标签所在的位置；使用 If-Modified-Since 字段就变 成了“有条件的请求”，仅当资源被修改时才会执行获取动作；使用 Range 字段就是“范围请求”，只获取资源的一 部分数据。

        （3）常用–HEAD（从服务器获取资源）
        ​ HEAD方法与 GET 方法类似，也是请求从服务器获取资源，服务器的处理机制也是一样的，但服务器不会返回请求 的实体数据，只会传回响应头，也就是资源的“元信息”。
        ​ HEAD 方法可以看做是 GET 方法的一个“简化版”或 者“轻量版”。因为它的响应头与 GET 完全相同，所以可以用在很多并不真正需要资源的场合，避免传输body数据的浪费。
        比如，想要检查一个文件是否存在，只要发个 HEAD 请求 就可以了，没有必要用 GET 把整个文件都取下来。再比 如，要检查文件是否有最新版本，同样也应该用 HEAD，服 务器会在响应头里把文件的修改时间传回来。
        

        （4）常用–POST（以向服务器提交数据）
​         向 URI 指定的资源提交数据，数据就放在报文的 body 里。POST应用的场景也非常多，只要向服务器发送数据，用的大多数都是 POST。
        ​ 比如，你上论坛灌水，敲了一堆字后点击“发帖”按钮，浏览器就执行了一次 POST 请求，把你的文字放进报文的 body 里，然后拼好 POST 请求头，通过 TCP 协议发给服 务器。

        （5）常用–PUT（以向服务器提交数据）
​         PUT 的作用与 POST 类似，也可以向服务器提交数据，但 与 POST 存在微妙的不同，通常 POST 表示的是“新建”“create”的含义，而 PUT 则是“修 改”“update”的含义。
        在实际应用中，PUT 用到的比较少。而且，因为它与 POST 的语义、功能太过近似，有的服务器甚至就直接禁止使用 PUT 方法，只用 POST 方法上传数据。

        （6）非常用–DELETE（删除资源）
​         DELETE方法指示服务器删除资源，因为这个动作危险性太 大，所以通常服务器不会执行真正的删除操作，而是对资源 做一个删除标记。当然，更多的时候服务器就直接不处理 DELETE 请求。

        （7）非常用–CONNECT（建立特殊的连接隧道）
​         CONNECT是一个比较特殊的方法，要求服务器为客户端和 另一台远程服务器建立一条特殊的连接隧道，这时 Web 服 务器在中间充当了代理的角色。

        （8）非常用–OPTIONS（列出可对资源实行的方法）
        ​ OPTIONS方法要求服务器列出可对资源实行的操作方法， 在响应头的 Allow 字段里返回。它的功能很有限，用处也不 大，有的服务器（例如 Nginx）干脆就没有实现对它的支持。

        （9）非常用–TRACE（追踪请求 - 响应的传输路径）
​         TRACE方法多用于对 HTTP 链路的测试或诊断，可以显示 出请求 - 响应的传输路径。它的本意是好的，但存在漏洞， 会泄漏网站的信息，所以 Web 服务器通常也是禁止使用。

        （10）扩展方法
​         虽然 HTTP/1.1 里规定了八种请求方法，但它并没有限制我 们只能用这八种方法，这也体现了 HTTP 协议良好的扩展 性，我们可以任意添加请求动作，只要请求方和响应方都能 理解就行。        
        有一些得到了实际应用的请求方法 （WebDAV），例如 MKCOL、COPY、MOVE、LOCK、 UNLOCK、PATCH 等。如果有合适的场景，你也可以把它 们应用到自己的系统里，比如用 LOCK 方法锁定资源暂时不 允许修改，或者使用 PATCH 方法给资源打个小补丁，部分更新数据。但因为这些方法是非标准的，所以需要为客户端 和服务器编写额外的代码才能添加支持。你也完全可以根据实际需求，自己发明新的方法。

        （11）安全与幂等
​         所谓的“安全”是指请求方法不会“破 坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。按照这个定义，只有 GET 和 HEAD 方法是“安全”的， POST/PUT/DELETE 操作会修改服务器上的资源，增加 或删除数据，所以是“不安全”的。
        ​ 所谓的“幂等”实际上是一个数学用语，意思是多次执行相同的操作，结果也都是相同的， 即多次“幂”后结果“相等”。GET 和 HEAD 既是安全的也是幂等的，DELETE 可以多次删除同一个资源，效果都是“资源不存在”，所以 也是幂等的。POST 是“新增或提交数据”，多次 提交数据会创建多个资源，所以不是幂等的；而 PUT 是“替换或更新数据”，多次更新一个资源，资源还是会第 一次更新的状态，所以是幂等的。

        7、URI

     （1）URI的格式
        URI 本质上是一个字符串，这个字符串的作用是唯一地标记资源的位置或者名字。
        ​ 下面的这张图显示了 URI 最常用的形式，由 scheme、 host:port、path 和 query 四个部分组成，但有的部分可以 视情况省略。

        
     （2）URI的基本组成

• scheme：翻译成中文叫“方案名”或者“协议名”，表示资源应该使用哪种协议来访问。最常见是“http”，另外还有“https”，表示经过加密、安全的 HTTPS协议。 此外还有其他的，例如 ftp、ldap、 file、news 等。如果一个 URI 没有提供 scheme，是无法处理的。
• “ :// ”：在 scheme 之后，必须是三个特定的字符“ :// ”，它把 scheme 和后面的部分分离开。
• authority：表示资源 所在的主机名，通常的形式是“host:port”，即主机名加端口号。主机名可以是 IP 地址或者域名的形式，必须要有，否则浏览器就会找不到服务器。但端口号有时可以省略，浏览器等客户端会依据 scheme 使用默认的端口号，例如 HTTP 的 默认端口号是 80，HTTPS 的默认端口号是 443。
• path：标记资源所在位置，有了协议名和主机地址、端口号再加上path，浏览器就可以连接服务器访问资源了。URI 里 path 采用了类似文件系统“目录”“路径”的表示 方式，因为早期互联网上的计算机多是 UNIX 系统，所以采用了 UNIX 的“/”风格。
• query：表示对资源附加的额外要求，它在 path 之后，用一个“?”开始，但不包含“?”。查询参数 query 有一套自己的格式，是多 个“key=value”的字符串，这些 KV 值用字符“&”连接，浏览器和客户端都可以按照这个格式把长串的查询参数 解析成可理解的字典或关联数组形式。

    ​ 如下是几个实例：

http://nginx.org

http://www.chrono.com:8080/11-1

https://tools.ietf.org/html/rfc7230

file:///D:/http_study/www/

        ​ 最后一个 URI 要注意了，它的协议名不是“http”，而是“file”，表示这是本地文件，而后面居然有三个斜杠，三个斜杠里的前两个属于 URI 特殊分隔符“😕/”，然后后面的“/D:/http_study/www/”是路径，而中间的主机名被“省略”了。这实际上是 file 类型 URI 的“特例”，它允许省略主机名，默认是本机 localhost。

    （3）URI 的完整格式

         URI 还有一个“真正”的完整形态，如下图所示，这个“真正”形态比基本形态多了两部分。

        ​user:passwd@：表示登录主机时的用户名和密码， 但现在已经不推荐使用这种形式了（RFC7230），因为它把 敏感信息以明文形式暴露出来，存在严重的安全隐患。

        #fragment：它是 URI 所定位的资源内部的一 个“锚点”或者说是“标签”，浏览器可以在获取资源后直接跳转到它指示的位置。 

     （4）URI 的编码
        ​ 在 URI 里只能使用 ASCII 码，为了在URI中表示ASCII 码以外的字符集和“@&/”等特殊字符，URI 引入了编码机制，把它们转换成与 URI 语义不冲 突的形式。这在 RFC 规范里称 为“escape”和“unescape”，俗称“转义”。
        ​ URI 转义的规则有点“简单粗暴”，直接把非 ASCII 码或特殊字符转换成十六进制字节值，然后前面再加上一 个“%”。
        例如，空格被转义成“%20”，“?”被转义成“%3F”。 而中文、日文等则通常使用 UTF-8 编码后再转义，例如“银河”会被转义成“%E9%93%B6%E6%B2%B3”。 有了这个编码规则后，URI 就更加完美了，可以支持任意的 字符集用任何语言来标记资源。

        8、响应状态码       

     （1）状态码的位置

​         服务器收到请求报文，解析后需要进行处理，具体的业务逻辑多种多样，但最后必定是拼出一个响应报文发回客户端。响应报文由响应头加响应体数据组成，响应头又由状态行和头字段构成。状态行的结构如下：

• Version：是 HTTP 协议的版本号，通常是HTTP/1.1，用处不是很大。
• Reason：是原因短语，是状态码的简短文字描述，例如“OK”“Not Found”等等，也可以自定义。但它只是为了兼容早期的文本客户端而存在，提供的信息很有限，目前的大多数客户端都会忽略它。
• Status Code：状态码，它是一个十进制数字，以代码的形式表示服务器对请求的处理结果，就像我们通常编写程序时函数返回的错误码一样。意义在于表达HTTP 数据处理的“状态”，客户端可以依据代码适时转换处理状态，例如继续发送请求、切换协议，重定向跳转等。

    （2）状态码
​         目前 RFC 标准里规定的状态码是三位数，所以取值范围就是从 000 到 999。RFC 标准把状态码分成了五类，用数字的第一位表示分类，而 0~99 不用，这样状态码的实际可用范围就大大缩小了，由000~999 变成了 100~599。这五类的具体含义是：

• 1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；偶尔能够见到的是101；
• 2××：成功，报文已经收到并被正确处理，常用的有 200、204、206；
• 3××：重定向，资源位置发生变动，需要客户端重新发送请求，常用的有 301、302、304；
• 4××：客户端错误，请求报文有误，服务器无法处理，常用的有 400、403、 404；
• 5××：服务器错误，服务器在处理请求时内部发生了错误，常用的有 500、501、 502、503；

        目前 RFC 标准里总共有 41 个状态码，但状态码的定义是开放的，允许自行扩展。所以 Apache、Nginx 等 Web 服务器都定义了一些专有的状态码。如果你自己开发 Web 应用，也完全可以在不冲突的前提下定义新的代码。

        9、特点总结

• HTTP 是灵活可扩展的，可以任意添加头字段实现任意功能；
• HTTP 是可靠传输协议，基于 TCP/IP 协议“尽量”保证数据的送达；
• HTTP 是应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据；
• HTTP 使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求；
• HTTP 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或 服务器记录请求相关的信息。

三、进阶

        1、实体数据

        （1）数据类型MIME type
​         HTTP是应用层的协议，数据到达客户端之后，必须要告诉上层应用是什么类型数据才能处理。
        早在 HTTP 协议诞生之前就已经有了针对这种问题的解决方案，不过它是用在电子邮件系统里的，让电子邮件可以发送 ASCII 码以外的任意数据，方案的名字叫做“多用途互联网邮件扩展”（Multipurpose Internet Mail Extensions），简称为 MIME。
        MIME 是一个很大的标准规范，但 HTTP 只取了其中一部分，用来标记 body 的数据类型，这就是我们平常总能听到的“MIME type”。
        MIME 把数据分成了八大类，每个大类下再细分出多个子 类，形式是“type/subtype”的字符串。这里简单列举一下在 HTTP 里经常遇到的几个类别：

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，即不透明的二进制数据。

        （2）编码Encoding type
​         仅有 MIME type 还不够，因为 HTTP 在传输时为了节约带宽，有时候还会压缩数据，还需要有一个“Encoding type”，告诉数据是用的什么编码格式，这样对方才能正确解压缩，还原出原始的数据。常用的Encoding type只有下面三种：

• gzip：GNU zip 压缩格式，也是互联网上最流行的压缩 格式；
• deflate：zlib（deflate）压缩格式，流行程度仅次于 gzip；
• br：一种专门为 HTTP 优化的新压缩算法（Brotli）。

        （3）数据类型的头字段Accept&Content
        ​ HTTP 协议定义了两个 Accept 请求头字段和两个 Content 实体头字段，用于客户端和服务器进行“内容协商”。客户端用 Accept 头告诉服务器希望接收什么样的数据，而服务器用 Content 头告诉客户端实际发送了什么样的数据。

         Accept：标记的是客户端可理解的 MIME type，可以用“,”做分隔符列出多个类型，让服务器有更多的选择余地，例如下面的这个头。

Accept: text/html,application/xml,image/webp,image/png

​         Content-Type：告诉实体数据的真实类型，浏览器看到类型是“text/html”就知道是 HTML 文件，会调用排版引擎渲染出页面，看到“image/png”就知道是一个 PNG 文件，就会在页面上显示出图像。

Content-Type: text/html
Content-Type: image/png

        （4）编码的头字段Accept-Encoding&Content-Encoding
          Accept-Encoding：是客户端支持的压缩格式， 例如上面说的 gzip、deflate 等，同样也可以用“,”列出多 个。
         ​ Content-Encoding：服务器可以选择其中一种来压缩数据，实际使用的压缩格式放在响应头字段Content-Encoding里。

   Accept-Encoding: gzip, deflate, br

   Content-Encoding: gzip     

        这两个字段是可以省略的，如果请求报文里没有 Accept-Encoding 字段，就表示客户端不支持压缩数据； 如果响应报文里没有 Content-Encoding 字段，就表示响应数据没有被压缩。

        （5）语言类型
​         互联网遍布全球，不同国家不同地区的人使用了很多不同的语言，虽然都是 text/html，如何让浏览器显示出每个人都可理解可阅读的语言文字，就是国际化问题，HTTP 又引入了两个概念：语言类型与字符集。
         语言类型就是人类使用的自然语言，例如英语、 汉语、日语等，而这些自然语言可能还有下属的地区性方言，所以在需要明确区分的时候也要使用“type-subtype”的形式，不过这里的格式与数据类型不同，分隔符不是“/”，而是“-”。
​         举几个例子：en 表示任意的英语，en-US 表示美式英语， en-GB 表示英式英语，而 zh-CN 就表示我们最常使用的汉语。

        （6）字符集
         在计算机发展的早期，各个国家和地区的人们“各自为政”，发明了许多字符编码方式来处理文字，比如英语世界用的 ASCII、汉语世界用的 GBK、BIG5，日语世界用的Shift_JIS 等。同样的一段文字，用一种编码显示正常，换另一种编码后可能就会变得一团糟。
        ​ 所以后来就出现了 Unicode 和 UTF-8，把世界上所有的语言都容纳在一种编码方案里，UTF-8 也成为了互联网上的标准字符集。

        （7）语言类型的头字段Accept-Language&Content-Language
        ​ Accept-Language：标记了客户端可理解的自然语言，也允许用“,”做分隔符列出多个类型，如下，这个请求头会告诉服务器：“最好给我 zh-CN 的汉语文字，如果没有就用其他的汉语方言，如果还没有就给英文”。

Accept-Language: zh-CN, zh, en

​         Content-Language：服务器在响应报文里用头字段Content-Language告诉客户端实体数据使用的实际语言类型：     

Content-Language: zh-CN    

        （8）字符集的头字段Accept-Charset&Content-Type 

        Accept-Charset：标记了字符集在HTTP里使用的请求头字段。
        Content-Type：响应头里却没有对应的 Content-Charset，而是在Content-Type字段用“charset=xxx”来表示，这点需要特别注意

Accept-Charset: gbk, utf-8 Content-Type: text/html; charset=utf-8

        不过现在的浏览器都支持多种字符集，通常不会发送Accept-Charset，而服务器也不会发送 Content-Language，因为使用的语言完全可以由字符集推断出来，所以在请求头里一般只会有 Accept-Language 字段，响应头里只会有 Content-Type 字段。

        （9）内容协商的质量值q
        ​ 在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等请求头字段进行内容协商的时候，还可以用一种特殊的“q”参数表示权重来设定优先级，这里的“q”是“quality factor”的意思。
        ​ 权重的最大值是 1，最小值是 0.01，默认值是 1，如果值是0 就表示拒绝。具体的形式是在数据类型或语言代码后面加一个“;”，然后是“q=value”。
        这里要提醒的是“;”的用法，在大多数编程语言里“;”的断句语气要强于“,”，而在 HTTP 的内容协商里却恰好反了过来，“;”的意义是小于“,”的。
        例如下面的 Accept 字段，它表示浏览器最希望使用的是 HTML 文件，权重是 1，其次是 XML 文件，权重是 0.9，最后是任意数据类型，权重是 0.8。服务器收到请求头后，就会计算权重，再根据自己的实际情况优先输出 HTML 或者 XML。

Accept: text/html,application/xml;q=0.9,*/*;q=0.8

        （10）内容协商的结果Vary
        ​ Vary：内容协商的过程是不透明的，每个 Web 服务器使用的算法都不一样。但有的时候，服务器会在响应头里多加一个Vary字段，记录服务器在内容协商时参考的请求头字段。
        如下，这个 Vary 字段表示服务器依据了 Accept-Encoding、User-Agent 和 Accept 这三个头字段，然后决定了发回的响应报文。

Vary: Accept-Encoding,User-Agent,Accept

 ​       Vary 字段可以认为是响应报文的一个特殊的“版本标记”。每当 Accept 等请求头变化时，Vary 也会随着响应报文一起变化。也就是说，同一个 URI 可能会有多个不同的“版本”，主要用在传输链路中间的代理服务器实现缓存服务。