透视http协议 (二)

Created2021-07-04Updated2021-07-08

键入网址再按下回车，发生了什么？

使用 IP 地址访问 Web 服务器

  1. 浏览器从地址栏的输入中获得服务器的IP 地址和端口号；
  2. 浏览器用 TCP 的三次握手与服务器建立连接；
  3. 浏览器向服务器发送拼好的报文；
  4. 服务器收到报文后处理请求，同样拼好报文再发给浏览器；
  5. 浏览器解析报文，渲染输出页面。

使用域名访问 Web 服务器

首先会经过DNS解析，浏览器首先看一下自己的缓存里有没有，如果没有就向操作系统的缓存要，还没有就检查本机域名解析文件 hosts，也就是 hosts 文件，windows为“C:\WINDOWS\system32\drivers\etc\hosts”。

DNS解析流程：

先查浏览器缓存，然后是系统缓存-＞hosts文件-＞局域网域名服务器-＞广域网域名服务器-＞顶级域名服务器-＞根域名服务器。

http 报文

HTTP 协议在规范文档里详细定义了报文的格式，规定了组成部分，解析规则，还有处理策略，所以可以在 TCP/IP 层之上实现更灵活丰富的功能，例如连接控制，缓存管理、数据编码、内容协商等等。

报文结构

TCP 报文来看，它在实际要传输的数据之前附加了一个 20 字节的头部数据，存储 TCP 协议必须的额外信息，例如发送方的端口号、接收方的端口号、包序号、标志位等等。

有了这个附加的 TCP 头，数据包才能够正确传输，到了目的地后把头部去掉，就可以拿到真正的数据。

HTTP 协议也是与 TCP/UDP 类似，同样也需要在实际传输的数据前附加一些头数据，不过与 TCP/UDP 不同的是，它是一个“纯文本”的协议，所以头数据都是 ASCII 码的文本，可以很容易地用肉眼阅读，不用借助程序解析也能够看懂。

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

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

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

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

所以，一个完整的 HTTP 报文就像是下图的这个样子，注意在 header 和 body 之间有一个“空行”。

http header头

第一行“GET / HTTP/1.1”就是请求行，而后面的“Host”“Connection”等等都属于 header，报文的最后是一个空白行结束，没有 body。

请求行

请求行由三部分构成：

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

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

1
GET / HTTP/1.1

在这个请求行里，“GET”是请求方法，“/”是请求目标，“HTTP/1.1”是版本号，把这三部分连起来，意思就是“服务器你好，我想获取网站根目录下的默认文件，我用的协议版本号是 1.1，请不要用 1.0 或者 2.0 回复我。”

状态行

意思是服务器响应的状态。

状态行也是由三部分构成:

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

意思就是：“请求完成，这个报文使用的协议版本号是 1.1，状态码是 200，一切 OK。”

头部字段

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

如图：

请求头和响应头的结构是基本一样的，唯一的区别是起始行，所以我把请求头和响应头里的字段放在一起介绍。

头部字段是 key-value 的形式，key 和 value 之间用“:”分隔，最后用 CRLF 换行表示字段结束。比如在“Host: 127.0.0.1”这一行里 key 就是“Host”，value 就是“127.0.0.1”。

HTTP 头字段非常灵活，不仅可以使用标准里的 Host、Connection 等已有头，也可以任意添加自定义头，这就给 HTTP 协议带来了无限的扩展可能。

不过使用头字段需要注意下面几点：

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

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

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

首先要说的是 Host 字段，它属于请求字段，只能出现在请求头里，它同时也是唯一一个 HTTP/1.1 规范里要求必须出现的字段，也就是说，如果请求头里没有 Host，那这就是一个错误的报文。

Host

Host 字段告诉服务器这个请求应该由哪个主机来处理，当一台计算机上托管了多个虚拟主机的时候，服务器端就需要用 Host 字段来选择，有点像是一个简单的“路由重定向”。

例如在 127.0.0.1 上有三个虚拟主机：“www.chrono.com”“www.metroid.net”和“origin.io”。那么当使用域名的方式访问时，就必须要用 Host 字段来区分这三个 IP 相同但域名不同的网站，否则服务器就会找不到合适的虚拟主机，无法处理。

User-Agent

User-Agent 是请求字段，只出现在请求头里。它使用一个字符串来描述发起 HTTP 请求的客户端，服务器可以依据它来返回最合适此浏览器显示的页面。

但由于历史的原因，User-Agent 非常混乱，每个浏览器都自称是“Mozilla”“Chrome”“Safari”，企图使用这个字段来互相“伪装”，导致 User-Agent 变得越来越长，最终变得毫无意义。

Date

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

Server 字段是响应字段，只能出现在响应头里。它告诉客户端当前正在提供 Web 服务的软件名称和版本号，例如在我们的实验环境里它就是“Server: openresty/1.15.8.1”，即使用的是 OpenResty 1.15.8.1。

Server

Server 字段也不是必须要出现的，因为这会把服务器的一部分信息暴露给外界，如果这个版本恰好存在 bug，那么黑客就有可能利用 bug 攻陷服务器。所以，有的网站响应头里要么没有这个字段，要么就给出一个完全无关的描述信息。

比如 GitHub，它的 Server 字段里就看不出是使用了 Apache 还是 Nginx，只是显示为“GitHub.com”。

Content-Length

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

小结

  1. HTTP 报文结构由“起始行 + 头部 + 空行 + 实体”组成，简单地说就是“header+body”；2. HTTP 报文可以没有 body，但必须要有 header，而且 header 后也必须要有空行；
  2. 请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成；
  3. 请求行有三部分：请求方法，请求目标和版本号；
  4. 状态行也有三部分：版本号，状态码和原因字符串；
  5. 头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；
  6. HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。

应该如何理解请求方法？

标准请求方法

目前 HTTP/1.1 规定了八种方法，单词都必须是大写的形式：

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

GET/HEAD

GET 方法应该是 HTTP 协议里最知名的请求方法了，也应该是用的最多的

它的含义是请求从服务器获取资源，这个资源既可以是静态的文本、页面、图片、视频，也可以是由 PHP、Java 动态生成的页面或者其他格式的数据。

GET 方法虽然基本动作比较简单，但搭配 URI 和其他头字段就能实现对资源更精细的操作。

例如，在 URI 后使用“#”，就可以在获取页面后直接定位到某个标签所在的位置；使用 If-Modified-Since 字段就变成了“有条件的请求”，仅当资源被修改时才会执行获取动作；使用 Range 字段就是“范围请求”，只获取资源的一部分数据。

HEAD 方法与 GET 方法类似，也是请求从服务器获取资源，服务器的处理机制也是一样的，但服务器不会返回请求的实体数据，只会传回响应头，也就是资源的“元信息”。

HEAD 方法可以看做是 GET 方法的一个“简化版”或者“轻量版”。因为它的响应头与 GET 完全相同，所以可以用在很多并不真正需要资源的场合，避免传输 body 数据的浪费。

POST/PUT

GET 和 HEAD 方法是从服务器获取数据，而 POST 和 PUT 方法则是相反操作，向 URI 指定的资源提交数据，数据就放在报文的 body 里。

POST 也是一个经常用到的请求方法，使用频率应该是仅次于 GET，应用的场景也非常多，只要向服务器发送数据，用的大多数都是 POST。

PUT 的作用与 POST 类似，也可以向服务器提交数据，但与 POST 存在微妙的不同，通常 POST 表示的是“新建”“create”的含义，而 PUT 则是“修改”“update”的含义。

在实际应用中，PUT 用到的比较少。而且，因为它与 POST 的语义、功能太过近似，有的服务器甚至就直接禁止使用 PUT 方法，只用 POST 方法上传数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
➜  ~ telnet www.baidu.com 80
Trying 180.101.49.12...
Connected to www.a.shifen.com.
Escape character is '^]'.
POST /10-2 HTTP/1.1
Host: www.chrono.com
Content-Length: 17

POST DATA IS HERE

PUT /10-2 HTTP/1.1
Host: www.chrono.com
Content-Length: 16

PUT DATA IS HERE

其他方法

  • DELETE 方法指示服务器删除资源，因为这个动作危险性太大，所以通常服务器不会执行真正的删除操作，而是对资源做一个删除标记。当然，更多的时候服务器就直接不处理 DELETE 请求。
  • CONNECT 是一个比较特殊的方法，要求服务器为客户端和另一台远程服务器建立一条特殊的连接隧道，这时 Web 服务器在中间充当了代理的角色。
  • OPTIONS 方法要求服务器列出可对资源实行的操作方法，在响应头的 Allow 字段里返回。它的功能很有限，用处也不大，有的服务器（例如 Nginx）干脆就没有实现对它的支持。
  • TRACE 方法多用于对 HTTP 链路的测试或诊断，可以显示出请求 - 响应的传输路径。它的本意是好的，但存在漏洞，会泄漏网站的信息，所以 Web 服务器通常也是禁止使用。

扩展方法

虽然 HTTP/1.1 里规定了八种请求方法，但它并没有限制我们只能用这八种方法，这也体现了 HTTP 协议良好的扩展性，我们可以任意添加请求动作，只要请求方和响应方都能理解就行。

此外，还有一些得到了实际应用的请求方法（WebDAV），例如 MKCOL、COPY、MOVE、LOCK、UNLOCK、PATCH 等。

安全与幂等

安全与幂等。

在 HTTP 协议里，所谓的“安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。

按照这个定义，只有 GET 和 HEAD 方法是“安全”的，因为它们是“只读”操作，只要服务器不故意曲解请求方法的处理方式，无论 GET 和 HEAD 操作多少次，服务器上的数据都是“安全的”。

而 POST/PUT/DELETE 操作会修改服务器上的资源，增加或删除数据，所以是“不安全”的。

所谓的“幂等”实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。

很显然，GET 和 HEAD 既是安全的也是幂等的，DELETE 可以多次删除同一个资源，效果都是“资源不存在”，所以也是幂等的。

POST 和 PUT 的幂等性质就略费解一点。

按照 RFC 里的语义，POST 是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；而 PUT 是“替换或更新数据”，多次更新一个资源，资源还是会第一次更新的状态，所以是幂等的。

小结

  1. 请求方法是客户端发出的、要求服务器执行的、对资源的一种操作；
  2. 请求方法是对服务器的“指示”，真正应如何处理由服务器来决定；
  3. 最常用的请求方法是 GET 和 POST，分别是获取数据和发送数据；
  4. HEAD 方法是轻量级的 GET，用来获取资源的元信息；
  5. PUT 基本上是 POST 的同义词，多用于更新数据；
  6. “安全”与“幂等”是描述请求方法的两个重要属性，具有理论指导意义，可以帮助我们设计系统。

你能写出正确的网址吗？

URI: 统一资源标识符（Uniform Resource Identifier）

URI 不完全等同于网址，它包含有 URL 和 URN 两个部分，在 HTTP 世界里用的网址实际上是 URL——统一资源定位符（Uniform Resource Locator）。

URI 的格式

URI 本质上是一个字符串，这个字符串的作用是唯一地标记资源的位置或者名字。

下面的这张图显示了 URI 最常用的形式，由 scheme、host:port、path 和 query 四个部分组成，但有的部分可以视情况省略。

URI 第一个组成部分叫 scheme，翻译成中文叫“方案名”或者“协议名”，表示资源应该使用哪种协议来访问。

最常见的当然就是“http”了，表示使用 HTTP 协议。另外还有“https”，表示使用经过加密、安全的 HTTPS 协议。此外还有其他不是很常见的 scheme，例如 ftp、ldap、file、news 等。

在 scheme 之后，必须是三个特定的字符“://”，它把 scheme 和后面的部分分离开。

在“://”之后，是被称为“authority”的部分，表示资源所在的主机名，通常的形式是“host:port”，即主机名加端口号。

主机名可以是 IP 地址或者域名的形式，必须要有，否则浏览器就会找不到服务器。但端口号有时可以省略，浏览器等客户端会依据 scheme 使用默认的端口号，例如 HTTP 的默认端口号是 80，HTTPS 的默认端口号是 443。

有了协议名和主机地址、端口号，再加上后面标记资源所在位置的 path，浏览器就可以连接服务器访问资源了。

URI 里 path 采用了类似文件系统“目录”“路径”的表示方式，因为早期互联网上的计算机多是 UNIX 系统，所以采用了 UNIX 的“/”风格。其实也比较好理解，它与 scheme 后面的“://”是一致的。

URI 的 path 部分必须以“/”开始，也就是必须包含“/”，不要把“/”误认为属于前面 authority。

1
2
3
4
http://nginx.org
http://www.chrono.com:8080/11-1
https://tools.ietf.org/html/rfc7230
file:///D:/http_study/www/

URI 的查询参数

使用“协议名 + 主机名 + 路径”的方式，已经可以精确定位网络上的任何资源了。但这还不够，很多时候我们还想在操作资源的时候附加一些额外的修饰参数。

如获取商品图片，但想要一个 32×32 的缩略图版本；获取商品列表，但要按某种规则做分页和排序；跳转页面，但想要标记跳转前的原始页面。

仅用“协议名 + 主机名 + 路径”的方式是无法适应这些场景的，所以 URI 后面还有一个“query”部分，它在 path 之后，用一个“?”开始，但不包含“?”，表示对资源附加的额外要求。这是个很形象的符号，比“://”要好的多，很明显地表示了“查询”的含义。

查询参数 query 有一套自己的格式，是多个“key=value”的字符串，这些 KV 值用字符“&”连接，浏览器和服务器都可以按照这个格式把长串的查询参数解析成可理解的字典或关联数组形式。

URI 的完整格式

URI 还有一个“真正”的完整形态，如下图所示。

这个“真正”形态比基本形态多了两部分。

第一个多出的部分是协议名之后、主机名之前的身份信息“user:passwd@”，表示登录主机时的用户名和密码，但现在已经不推荐使用这种形式了（RFC7230），因为它把敏感信息以明文形式暴露出来，存在严重的安全隐患。

第二个多出的部分是查询参数后的片段标识符“#fragment”，它是 URI 所定位的资源内部的一个“锚点”或者说是“标签”，浏览器可以在获取资源后直接跳转到它指示的位置。

但片段标识符仅能由浏览器这样的客户端使用，服务器是看不到的。也就是说，浏览器永远不会把带“#fragment”的 URI 发送给服务器，服务器也永远不会用这种方式去处理资源的片段。

URI 的编码

URI 引入了编码机制，对于 ASCII 码以外的字符集和特殊字符做一个特殊的操作，把它们转换成与 URI 语义不冲突的形式。这在 RFC 规范里称为“escape”和“unescape”，俗称“转义”。

URI 转义的规则有点“简单粗暴”，直接把非 ASCII 码或特殊字符转换成十六进制字节值，然后前面再加上一个“%”。

例如，空格被转义成“%20”，“?”被转义成“%3F”。而中文、日文等则通常使用 UTF-8 编码后再转义，例如“银河”会被转义成“%E9%93%B6%E6%B2%B3”。

小结

  1. URI 是用来唯一标记服务器上资源的一个字符串，通常也称为 URL；
  2. URI 通常由 scheme、host:port、path 和 query 四个部分组成，有的可以省略；
  3. scheme 叫“方案名”或者“协议名”，表示资源应该使用哪种协议来访问；
  4. “host:port”表示资源所在的主机名和端口号；
  5. path 标记资源所在的位置；
  6. query 表示对资源附加的额外要求；
  7. 在 URI 里对“@&/”等特殊字符和汉字必须要做编码，否则服务器收到 HTTP 报文后会无法正确处理。

响应状态码

状态行里有用的是中间的状态码（Status Code）了。它是一个十进制数字，以代码的形式表示服务器对请求的处理结果，就像我们通常编写程序时函数返回的错误码一样。

状态码

RFC 标准把状态码分成了五类，用数字的第一位表示分类，而 099 不用，这样状态码的实际可用范围就大大缩小了，由 000999 变成了 100~599。

这五类的具体含义是：

  • 1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；
  • 2××：成功，报文已经收到并被正确处理；
  • 3××：重定向，资源位置发生变动，需要客户端重新发送请求；
  • 4××：客户端错误，请求报文有误，服务器无法处理；
  • 5××：服务器错误，服务器在处理请求时内部发生了错误。

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

1××

1××类状态码属于提示信息，是协议处理的中间状态，实际能够用到的时候很少。

101 Switching Protocols 它的意思是客户端使用 Upgrade 头字段，要求在 HTTP 协议的基础上改成其他的协议继续通信，比如 WebSocket。而如果服务器也同意变更协议，就会发送状态码 101，但这之后的数据传输就不会再使用 HTTP 了。

2××

2××类状态码表示服务器收到并成功处理了客户端的请求

“200 OK”是最常见的成功状态码，表示一切正常，服务器如客户端所期望的那样返回了处理结果，如果是非 HEAD 请求，通常在响应头后都会有 body 数据。

“204 No Content”是另一个很常见的成功状态码，它的含义与“200 OK”基本相同，但响应头后没有 body 数据。

“206 Partial Content”是 HTTP 分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与 200 一样，也是服务器成功处理了请求，但 body 里的数据不是资源的全部，而是其中的一部分。

状态码 206 通常还会伴随着头字段“Content-Range”，表示响应报文里 body 数据的具体范围，供客户端确认，例如“Content-Range: bytes 0-99/2000”，意思是此次获取的是总计 2000 个字节的前 100 个字节。

3××

3××类状态码表示客户端请求的资源发生了变动，客户端必须用新的 URI 重新发送请求获取资源，也就是通常所说的“重定向”，包括著名的 301、302 跳转。

“301 Moved Permanently”俗称“永久重定向”，含义是此次请求的资源已经不存在了，需要改用新的 URI 再次访问。

与它类似的是“302 Found”，曾经的描述短语是“Moved Temporarily”，俗称“临时重定向”，意思是请求的资源还在，但需要暂时用另一个 URI 来访问。

301 和 302 都会在响应头里使用字段 Location 指明后续要跳转的 URI，最终的效果很相似，浏览器都会重定向到新的 URI。两者的根本区别在于语义，一个是“永久”，一个是“临时”

“304 Not Modified”是一个比较有意思的状态码，它用于 If-Modified-Since 等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义，但可以理解成“重定向已到缓存的文件”（即“缓存重定向”）。

4××

4××类状态码表示客户端发送的请求报文有误，服务器无法处理，它就是真正的“错误码”含义了。

“400 Bad Request”是一个通用的错误码，表示请求报文有错误

“403 Forbidden”实际上不是客户端的请求出错，而是表示服务器禁止访问资源。

“404 Not Found”它的原意是资源在本服务器上未找到，所以无法提供给客户端。

4××里还有一些开发中其他常用的：

  • 405 Method Not Allowed：不允许使用某些方法操作资源，例如不允许 POST 只能 GET
  • 406 Not Acceptable：资源无法满足客户端请求的条件，例如请求中文但只有英文
  • 408 Request Timeout：请求超时，服务器等待了过长的时间
  • 409 Conflict：多个请求发生了冲突，可以理解为多线程并发时的竞态
  • 413 Request Entity Too Large：请求报文里的 body 太大
  • 414 Request-URI Too Long：请求行里的 URI 太大
  • 429 Too Many Requests：客户端发送了太多的请求，通常是由于服务器的限连策略
  • 431 Request Header Fields Too Large：请求头某个字段或总体太大

5××

5××类状态码表示客户端请求报文正确，但服务器在处理时内部发生了错误，无法返回应有的响应数据，是服务器端的“错误码”。

“500 Internal Server Error”与 400 类似，也是一个通用的错误码

“501 Not Implemented”表示客户端请求的功能还不支持

“502 Bad Gateway”通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误

“503 Service Unavailable”表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503。

503 是一个“临时”的状态，很可能过几秒钟后服务器就不那么忙了，可以继续提供服务，所以 503 响应报文里通常还会有一个“Retry-After”字段，指示客户端可以在多久以后再次尝试发送请求。

小结

  1. 状态码在响应报文里表示了服务器对请求的处理结果；
  2. 状态码后的原因短语是简单的文字描述，可以自定义；
  3. 状态码是十进制的三位数，分为五类，从 100 到 599；2××类状态码表示成功，常用的有 200、204、206；
  4. 3××类状态码表示重定向，常用的有 301、302、304；
  5. 4××类状态码表示客户端错误，常用的有 400、403、404；
  6. 5××类状态码表示服务器错误，常用的有 500、501、502、503。

HTTP有哪些特点？

灵活可扩展

HTTP 协议是一个“灵活可扩展”的传输协议。

可靠传输

HTTP 协议是一个“可靠”的传输协议

应用层协议

HTTP 协议是一个应用层的协议

请求 - 应答

HTTP 协议使用的是请求 - 应答通信模式

无状态

HTTP 协议是无状态的

其他特点除了以上的五大特点，其实 HTTP 协议还可以列出非常多的特点，例如传输的实体数据可缓存可压缩、可分段获取数据、支持身份认证、支持国际化语言等。但这些并不能算是 HTTP 的基本特点，因为这都是由第一个“灵活可扩展”的特点所衍生出来的。

http缺点

明文

HTTP 协议里还有一把优缺点一体的“双刃剑”，就是明文传输。

“明文”意思就是协议里的报文（准确地说是 header 部分）不使用二进制数据，而是用简单可阅读的文本形式。

不安全

与“明文”缺点相关但不完全等同的另一个缺点是“不安全”。

安全有很多的方面，明文只是“机密”方面的一个缺点，在“身份认证”和“完整性校验”这两方面 HTTP 也是欠缺的。

性能

不算差，不够好

小结

  1. HTTP 是灵活可扩展的，可以任意添加头字段实现任意功能；
  2. HTTP 是可靠传输协议，基于 TCP/IP 协议“尽量”保证数据的送达；
  3. HTTP 是应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据；
  4. HTTP 使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求；
  5. HTTP 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。
  6. HTTP 是无状态的，可以轻松实现集群化，扩展性能，但有时也需要用 Cookie 技术来实现“有状态”；
  7. HTTP 是明文传输，数据完全肉眼可见，能够方便地研究分析，但也容易被窃听；HTTP 是不安全的，无法验证通信双方的身份，也不能判断报文是否被窜改；
  8. HTTP 的性能不算差，但不完全适应现在的互联网，还有很大的提升空间。

课程来源

https://time.geekbang.org/column/intro/100029001

欢迎大家订购，一块儿学习，共同进步。

Search by:GoogleBingBaidu