HTTP协议解析

HTTP（超文本传输协议）是万维网的基础协议，自1991年诞生以来，已成为最广泛使用的应用层协议。本文将深入解析HTTP协议的核心概念、工作原理及实际应用。

HTTP协议基础 

什么是HTTP？

HTTP (全称为 "超文本传输协议") 是一种应用非常广泛的 应用层协议

HTTP 是互联网上最基础、最重要的沟通规则之一。简单来说，它定义了你的电脑（比如你用的浏览器）和存放网站内容的服务器（就是远方的另一台电脑）之间如何“说话”。每当你打开一个网页、点击一个链接、或者提交一个表单，背后都是你的浏览器按照 HTTP 的规则在向服务器发送请求。

服务器收到这个请求后，会根据请求的内容，也按照 HTTP 的规则进行回应。这个回应通常包含了你想要的东西，比如网页的文本、图片、视频等文件，或者告诉你操作是成功了还是失败了（比如 404 错误就是服务器告诉你没找到你要的东西）。你可以把整个上网浏览的过程想象成你的浏览器不断向不同的服务器发出“给我这个页面”、“给我那张图片”之类的请求，然后服务器用 HTTP 回应“好的，东西在这”或者“抱歉，没找到”。

HTTP 的核心作用就是让千差万别的浏览器和服务器能够互相理解对方的意思，完成信息的交换。它规定了请求和回应应该长什么样子、包含哪些必要的信息（比如请求哪个网址、用什么方法获取数据、服务器返回的状态是成功还是失败等）。正是有了这个大家都遵守的规则，你才能顺畅地在不同的网站之间跳转，看到各种各样的内容。它就像互联网世界通用的一种基础语言，虽然你看不见它，但你每次上网都在使用它。你在浏览器地址栏看到的 http:// 或 https:// 开头的网址，就明确地告诉你，这次连接使用的是 HTTP（或其更安全的版本 HTTPS）这个协议。

HTTP 往往是基于传输层的 TCP 协议实现的. (HTTP1.0, HTTP1.1, HTTP2.0 均为TCP, HTTP3 基于 UDP 实现)目前我们主要使用的还是 HTTP1.1 和 HTTP2.0 . 这篇文章讨论的 HTTP 以 1.1 版本为主.

 理解应用层协议

应用层协议可以理解为运行在电脑、手机等设备上的各种软件之间沟通的专用语言规则。想象一下，不同的软件有不同的任务，比如浏览器要浏览网页，邮件软件要收发邮件，文件传输工具要传文件。为了让这些软件能准确完成它们的任务，它们需要和网络另一端的对应软件（比如网页服务器、邮件服务器、文件服务器）进行交流。应用层协议就是为这些​​特定类型​​的软件交流制定的详细规则手册。

这些规则手册详细规定了：当软件A想从软件B那里获取某种服务或信息时，它应该发送什么样的请求消息（消息的格式、包含哪些必要信息）；软件B收到请求后，应该如何解读这个请求，并根据请求做出什么样的回应（回应的格式、包含成功或失败的状态、以及具体的数据内容）。简单说，它定义了​​谁（什么软件）​​ 在​​什么情况下​​可以说​​什么话（消息格式）​​，以及对方应该​​怎么回应（响应格式）​​。

应用层协议是建立在更基础的网络通信规则（像TCP/IP协议）之上的。底层协议负责把数据包从一台电脑可靠地搬运到另一台电脑，就像负责运输的卡车。而应用层协议则负责定义卡车里装的“货物”（也就是数据）具体代表什么含义、应该怎么拆封和使用这些货物，才能让两端的软件真正理解对方的意思并完成特定的任务。比如，HTTP协议定义了浏览器和服务器如何交换网页内容，SMTP协议定义了邮件客户端和服务器如何发送邮件。每个应用层协议都是为了解决某个特定的网络应用问题而设计的。

HTTP工作过程

当我们在浏览器中输入一个 "网址", 此时浏览器就会给对应的服务器发送一个 HTTP 请求. 对方服务器收到这个请求之后, 经过计算处理, 就会返回一个 HTTP 响应.

当在浏览器输入URL时：

1. 浏览器向服务器发送HTTP请求
2. 服务器处理请求并返回HTTP响应
3. 浏览器解析响应并渲染页面
4. 页面可能触发多个HTTP请求（CSS、JS、图片等资源）

HTTP协议格式

HTTP 是一个文本格式的协议. 可以通过 Chrome 开发者工具或者抓包工具抓包, 分析 HTTP 请求/响应的细节.

抓包工具使用wireshark或者Fiddler都行,本篇文章使用Fiddler来进行演示,关于抓包工具的详细内容这里就不做过多介绍了,因为内容不是一篇博客能写完的,感兴趣可以自己去B站搜索相关视频

抓包工具的原理 

Fiddler 相当于一个 "代理". 浏览器访问 sogou.com 时, 就会把 HTTP 请求先发给 Fiddler, Fiddler 再把请求转发给 sogou 的服务器. 当 sogou 服务器返回数据时, Fiddler 拿到返回数据, 再把数据交给浏览器. 因此 Fiddler 对于浏览器和 sogou 服务器之间交互的数据细节, 都是非常清楚的.

抓包结果 

以下是一个 HTTP请求/响应 的抓包结果

HTTP请求

• 首行: [方法] + [url] + [版本] Header:
• 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
• Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有 一个Content-Length属性来标识Body的长度; 

HTTP响应

• 首行: [版本号] + [状态码] + [状态码解释]
• Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
• Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有 一个Content-Length属性来标识Body的长度; 如果服务器返回了一个html页面, 那么html页 面内容就是在body中.

协议格式总结

协议格式本质上就是一套非常明确的“写作规范”，规定了一条信息（无论是请求还是回应）必须长什么样子。它详细说明了这条信息从开头到结尾，每一个部分应该放什么内容、按照什么顺序排列、甚至用什么符号分隔开来。这样，参与通信的双方（比如客户端软件和服务器软件）都按照同一个规范来“写”消息和“读”消息，才能互相明白对方的意思。

通常，一个协议格式会把一条完整的信息划分为几个关键区域。最开头往往是一些控制信息，这部分可以看作是信息的“元数据”，或者叫消息头（Header）。它包含了告诉对方如何处理这条消息的核心指令和说明，比如这条消息是干嘛用的（是获取数据还是提交数据？），消息有多长，使用的协议版本是多少，还可能需要携带授权信息、内容类型（是文本还是图片？）等等关键控制细节。

在消息头之后，通常是一个分隔符号（比如一个空行），然后就是消息的主体部分，或者叫消息体（Body）。这部分放置的是实际要传输的核心内容。具体内容是什么完全取决于这条消息的目的：可能是一段你想上传的文字，一张图片的二进制数据，也可能是一个网页的内容（HTML代码）。有些消息可能没有主体部分，特别是像单纯请求数据这种操作，主体部分就可能是空的。

理解协议格式的核心就是意识到它通过这种严格的结构化（固定的区域、固定的信息位置、特定的标识符），确保了不同开发者编写、不同系统运行的软件之间，能够准确无误地交换信息。接收方总是知道哪里找指令（Header），哪里找具体数据（Body），而发送方也知道把这些信息该放在哪里。这种预先设定好的“写作模板”是各种软件能够在网络上协作的基础。

HTTP 请求 (Request) 

 认识 URL 

URL（也就是我们常说的“网址”）的核心作用就是告诉浏览器互联网上一个资源（比如网页、图片）的具体位置以及如何访问它。你可以把它看作一个结构化的地址。

一个典型的URL从左到右主要由几个部分组成。首先是​​协议​​，比如开头的“http”或“https”，它告诉浏览器该用什么规则去和服务器沟通。紧接着是​​服务器地址​​，通常是像“v.bitedu.vip”这样的域名（域名会被系统自动翻译成实际的数字IP地址，这就是DNS的作用）。域名后面有时会跟一个冒号和​​端口号​​（比如:443），用来指定服务器上的特定入口点，但这个端口号经常会被省略，因为浏览器会默认根据协议类型（如http用80，https用443）自动补全。

域名之后跟着的是​​路径​​，比如“/personInf/student”，这部分指明了你要访问的服务器上具体的文件或资源的位置，可以想象成文件夹的层次结构。在路径后面，有时你会看到一个问号“?”开头的部分，叫做​​查询字符串​​（或URL参数），它由多个“键=值”对组成（例如“userId=10000”），多个键值对之间用“&”符号连接，用来向服务器传递一些额外的、特定的请求信息。最后，URL末尾可能还有一个井号“#”开头的​​片段标识符​​，它主要是用来定位同一个页面内不同的特定位置的（比如跳到文章中的某个章节）。这两部分（查询字符串和片段标识符）在某些URL中也可以没有。

示例:

https://v.bitedu.vip/personInf/student?userId=10000&classId=100

协议 (Protocol)：​​

https:// 告诉浏览器（或你的应用程序）使用​​HTTPS协议​​来与服务器通信。HTTPS是HTTP的安全版本，在浏览器和服务器之间传输的数据是加密的，安全性更好。因为是HTTPS，默认使用​​443端口​​（图片中提到省略时会自动使用协议的默认端口）。

​​服务器地址 (Server Address)：​​

v.bitedu.vip 是​​域名​​。当你的设备访问这个域名时，会通过​​DNS系统​​查询，将其转换成真实的​​IP地址​​（如图片中举例，可能是类似 118.24.113.28 的数字地址）。它指明了你要连接的服务器在哪里。

​​路径 (Path)：​​

/personInf/student 是服务器上​​资源的路径​​。你可以把它想象成服务器硬盘上某个特定文件或服务的地址层级。这里路径表明你想访问的是与 personInf（个人信息系统）相关的 student（学生相关）部分的功能或数据。

​​查询字符串 (Query String)：​​

?userId=10000&classId=100 （问号?后面的部分）。这是一个​​键值对​​结构，用来向服务器传递​​额外的、具体的请求信息​​。多个键值对用 & 符号连接。具体传递了userId=10000: 请求与 用户ID 为 10000 相关的信息（很可能是指学号）。classId=100: 请求与 班级ID 为 100 相关的信息。服务器会根据这些参数返回针对ID是10000的这位学生在100班的特定信息。

​​省略/不存在部分：​​

• ​​登陆信息：​​ URL中没有类似 username:password@ 的部分（在://之后域名之前），因为现代网站通常不会把登录信息直接写在URL里（非常不安全），而是通过登录表单或其他安全方式验证身份。
• ​​片段标识符：​​ URL末尾没有 #开头的部分（如#section-name）。片段标识符主要用于同一个页面内部的导航（比如跳转到页面内的某个章节），这个URL不需要它。

 关于 query string

Query String，就是网址里那个问号 ? 后面跟着的那一串东西。它的主要作用是在你向服务器请求某个资源（比如一个网页）时，能够附带传送一些额外的、具体的参数信息给服务器。简单说，它就是你向服务器提出的“具体问题”或者“具体要求”的细节描述部分。

通常，Query String 是由一个或多个“键值对”组成，格式一般是 键=值。如果你有多个要求，就用 & 符号把它们连起来，像这样 键1=值1&键2=值2。比如，你想看用户 ID 是 10000 的信息，同时限定在班级 ID 是 100 的范围内，那么就可能写成 ?userId=10000&classId=100。

服务器拿到这个网址后，会先根据域名和路径找到对应的资源（也就是问号 ? 前面的部分），然后专门去解析问号后面的 Query String。服务器程序会识别出里面的键（比如 userId）和对应的值（比如 10000），然后它就可以理解“哦，用户不仅想看这个页面，还想看 ID 是 10000 的同学在班级 100 的特定信息啊”。服务器就会根据这些参数值，去数据库查找、过滤或者筛选出最符合你这些特定要求的数据，然后把这些“定制化”的结果组织好，发回给你的浏览器。它让同一个路径下的资源（比如同一个页面或服务）可以根据不同的参数返回不同的具体内容。

URL 中的可省略部分

• 协议名: 可以省略, 省略后默认为 http:// ip 地址 /
• 域名: 在 HTML 中可以省略(比如 img, link, script, a 标签的 src 或者 href 属性). 省略后表示服务器的 ip / 域名与当前 HTML 所属的 ip / 域名一致.
• 端口号: 可以省略. 省略后如果是 http 协议, 端口号自动设为 80; 如果是 https 协议, 端口号自 动设为 443.
• 带层次的文件路径: 可以省略. 省略后相当于 / . 有些服务器会在发现 / 路径的时候自动访问 /index.html
• 查询字符串: 可以省略 片段标识: 可以省略

认识 "方法" (method) 

方法	基本作用（通俗说）	主要支持的 HTTP 版本
​​GET​​	最常用！向服务器“拿东西”，比如请求打开一个网页、获取图片或数据。	1.0, 1.1
​​POST​​	向服务器“提交东西”。通常用于发送表单信息、上传文件，或者在服务器上创建新东西（比如注册新账号时）。	1.0, 1.1
​​PUT​​	把一份新文件或数据“放上去”服务器指定的位置，替换掉原来的（如果有的话）。	1.0, 1.1
​​HEAD​​	只请求“拿个头儿”。服务器会像处理GET一样回应，但只给响应信息的头部，不会给实际内容（比如网页正文或文件数据）。用来快速检查一个链接是否有效或资源是否被修改过，省流量。	1.0, 1.1
​​DELETE​​	让服务器删除指定位置的文件或资源。	1.0, 1.1
​​OPTIONS​​	问问服务器“你这里都支持啥方法”？比如一个网址允不允许 POST 或 DELETE。	1.1 (主要)
​​TRACE​​	类似于网络诊断的“回显”。主要用于开发和调试网络问题，看看请求在发送到服务器的路径上有没有被修改过。	1.1 (主要)
​​CONNECT​​	建立一条特殊“隧道”，主要用于需要通过代理建立安全连接的情况（比如 HTTPS）。代理服务器能按指示连接到目标地址。	1.1 (主要)
​​LINK​​	这是一个比较老的方法，用于在两个资源之间建立联系。​​注意：这个方法在现代网络开发和 RESTful API 中已经基本不用了，被废弃了。​​	1.0 (过时)
​​UNLINK​​	这个和 LINK 成对出现，用于断开 LINK 方法建立的连接关系。​​注意：和 LINK 一样，这个方法也已废弃，现代开发中非常罕见。​​	1.0 (过时)

GET 方法 (最常用的)：​​

​​GET:​​ 就像你跟服务员说“我要菜单”或者“给我一杯水”。它就是用来​​拿​​信息的。直接在地址栏输入网址访问，用的就是这个 GET。

GET 请求的特点

• 首行的第一部分为 GET
• URL 的 query string 可以为空, 也可以不为空.
• header 部分有若干个键值对结构.
• body 部分为空.

​​POST 方法 (另一个顶流)：​​

​​POST:​​ 当你填写完网页上的表单点“提交”，基本就是它在工作。它是用来​​发送​​信息给服务器的。比如留言、登录账号、上传文件内容通常都用 POST 来“送”。

POST 请求的特点

• 首行的第一部分为 POST
• URL 的 query string 一般为空 (也可以不为空)
• header 部分有若干个键值对结构.
• body 部分一般不为空. body 内的数据格式通过 header 中的 Content-Type 指定. body 的长度由 header 中的 Content-Length 指定.

 谈 GET 和 POST 的区别

• 语义不同: GET 一般用于获取数据, POST 一般用于提交数据. GET 的 body 一般为空, 需要传递的数据通过 query string 传递, POST 的 query string 一般 为空, 需要传递的数据通过 body 传递
• GET 请求一般是幂等的, POST 请求一般是不幂等的. (如果多次请求得到的结果一样, 就视为 请求是幂等的).
• GET 可以被缓存, POST 不能被缓存. (这一点也是承接幂等性).

补充说明:

• 关于语义: GET 完全可以用于提交数据, POST 也完全可以用于获取数据.
• 关于幂等性: 标准建议 GET 实现为幂等的. 实际开发中 GET 也不必完全遵守这个规则(主流网 站都有 "猜你喜欢" 功能, 会根据用户的历史行为实时更新现有的结果.
• 关于安全性: 有些资料上说 "POST 比 GET 请安全". 这样的说法是不科学的. 是否安全取决于 前端在传输密码等敏感信息时是否进行加密, 和 GET POST 无关.
• 关于传输数据量: 有的资料上说 "GET 传输的数据量小, POST 传输数据量大". 这个也是不科 学的, 标准没有规定 GET 的 URL 的长度, 也没有规定 POST 的 body 的长度. 传输数据量多少, 完全取决于不同浏览器和不同服务器之间的实现区别.
• 关于传输数据类型: 有的资料上说 "GET 只能传输文本数据, POST 可以传输二进制数据". 这 个也是不科学的. GET 的 query string 虽然无法直接传输二进制数据, 但是可以针对二进制数 据进行 url encode.

认识请求 "报头" (header) 

header 的整体的格式也是 "键值对" 结构. 每个键值对占一行.键和值之间使用分号分割.

报头的种类有很多, 此处仅介绍几个常见的

​​Host​​
这个报头告诉服务器，客户端想要访问的是哪个具体的网站域名或主机名。在一个服务器托管多个网站时（虚拟主机），它就特别重要了。服务器靠这个信息才知道该把请求发给哪个具体的网站来处理。

​​Content-Length​​
当你的请求里带有数据（比如提交表单或上传文件）时，这个报头就会用上。它非常直白地告诉服务器，你发送的这个数据包总共有多少个字节长。服务器好根据这个长度准确地读完你的数据。

​​Content-Type​​
和 Content-Length 一起用，主要是针对带有数据体的请求（如 POST、PUT）。它告诉服务器：“我发过来的数据是什么格式的”。常见的有普通的网页表单数据、用来上传文件的格式、或者 JSON 数据包等等。服务器知道了格式才能正确地理解和处理这些数据。

​​Referer​​
这个报头（注意拼写，少一个 r）告诉服务器，用户是从哪个网页或哪个网址链接跳转到现在这个请求的。比方说，你从百度搜索结果页点了一个链接进到某个网站，百度那个页面的网址就会出现在这里的 Referer 报头里。网站可能会用它来分析流量来源。

​​User-Agent​​
这个报头向服务器表明你（客户端）的身份。它会描述你用的浏览器是什么（比如 Chrome, Firefox, Safari）及其版本，还有你的操作系统信息（比如 Windows, macOS, Android）。服务器能看到“哦，是 Windows 上的 Chrome 125 发来的请求”，从而可能返回优化过的页面内容，或者用于统计访客设备情况。

Cookie​​

这个报头是浏览器在发送请求时，​​自动​​携带上之前访问该网站时，服务器通过 Set-Cookie 响应报头要求它存储的信息。这些信息通常是像用户登录状态（会话ID）、用户偏好设置等小的键值对数据块。服务器收到 Cookie 报头后，就能识别出当前用户是谁（比如是否已登录），或者知道用户的偏好设置是什么，从而提供个性化的内容和服务。简单说，它就是浏览器帮用户“记住”一些东西，并在后续访问时“告诉”服务器的一种方式，主要用于保持用户会话的状态。

认识请求 "正文" (body)

请求的“正文”（Body）可以理解为客户端（比如你的浏览器或者APP）发送给服务器的、除了基本请求指令（在请求头Header里）之外的实际数据内容。它就像是你在寄信时，信封外面写了地址和寄件人信息（相当于Header），而信封里面装着的信纸内容就是Body。

当你进行一些需要向服务器“提交”信息的操作时，就会用到请求Body。最常见的例子就是填写表单：比如你登录网站时输入的用户名和密码，或者在购物网站填写收货地址和商品数量，这些你输入的具体信息，通常就会被浏览器打包放在请求的Body里发送给服务器。它和写在网址（URL）里的查询参数（Query String）不同，Body里的内容不会直接显示在浏览器的地址栏上，相对更隐蔽一些，也适合传输更大量或更复杂的数据。

请求Body里具体装什么格式的数据，是由请求头（Header）中的一个特定字段（通常是 Content-Type）来明确告诉服务器的。常见的数据格式有：

• ​​表单数据 (application/x-www-form-urlencoded 或 multipart/form-data)​​： 就像网页表单提交的那些键值对信息（如 username=zhangsan&password=123456），或者包含文件上传的表单。
• ​​JSON (application/json)​​： 这是现在非常流行的格式，用于传输结构化的数据，比如 {"name": "张三", "age": 25, "email": "zhangsan@example.com"}。
• ​​XML (application/xml)​​： 另一种结构化数据格式，现在用的相对少一些了。
• ​​纯文本 (text/plain)​​： 就是普通的文字内容。
• ​​二进制数据​​： 比如上传的图片、视频文件本身。

服务器收到请求后，会先看请求头（Header）了解基本信息（比如请求方法、目标资源、数据格式等），然后根据 Content-Type 的指示，去正确解析请求Body里的数据内容，获取你真正想提交的信息，并据此进行相应的处理（比如验证登录、保存信息、处理订单等）。简单说，Body承载了客户端想让服务器知道或处理的“实质内容”。

HTTP 响应 

认识 "状态码" (status code)

状态码是服务器在响应请求时，返回的第一个简短数字信息。它就像一份快递单上的备注一样告诉你，你的这个请求处理结果是“已送达”、“无人接收”、“寄错地址了”还是“运输车坏了”。前两位数字表明了​​大类​​（是成功、重定向还是出错），后面细分具体原因。理解常见状态码能让你快速判断问题是出在地址不对、没权限、参数错了，还是服务器本身抽风了。

大类	状态码范围	基本含义	常见例子
​​1xx (信息类)​​	100-199	​​临时响应。​​请求已收到，请继续或等待。服务器说“知道了，正在处理第一步。”	100 Continue
​​2xx (成功类)​​	200-299	​​成功！​​请求已被服务器成功接收、理解并接受处理。目的达成。	​​200 OK​​
​​3xx (重定向类)​​	300-399	​​需要进一步操作。​​为了完成请求，需要客户端采取额外的步骤（比如跳转到另一个地址）。	​​301 永久移动​​, ​​302 临时移动​​, 304 未修改
​​4xx (客户端错误)​​	400-499	​​问题出在客户端。​​服务器理解请求本身，但​​无法​​处理它，原因是客户端发的东西不对（比如地址错了、权限不够、格式错误）。	​​400 错误请求​​, ​​401 未授权​​, ​​403 禁止​​, ​​404 未找到​​
​​5xx (服务器错误)​​	500-599	​​问题出在服务器端。​​服务器在处理一个有效的请求时自己出错了（服务器代码或配置问题、资源不足等）。	​​500 内部服务器错误​​, ​​503 服务不可用​

常见状态码: 

200 OK：​​

最理想的结果！你想看的东西（或者请求的操作），服务器成功收到、明白并正确处理好了，你要的数据/页面/结果已经打包在响应的Body里了。

​​301 Moved Permanently：​​

• ​​“你找的那个东西，永久搬到新地址了。”​​ 服务器告诉你，你请求的资源（比如网页）已经永远不在这里了，并且告诉了你新的地址。浏览器（或搜索引擎）记住新地址后，下次应该​​直接用新地址访问​​。

​​302 Found (或 307 Temporary Redirect)：​​

• ​​“你找的东西暂时挪个地方，先去那边看看。”​​ 和301很像，但这是​​临时​​搬家。浏览器收到这个响应，会按照服务器提供的临时新地址再发一次请求去拿资源。你浏览器的地址栏通常会变成这个临时新地址。下次访问原地址时，可能还得问一遍服务器。

​​400 Bad Request：​​

• ​​“你说什么？我没听懂。”​​ 服务器觉得客户端（浏览器/APP）发过来的请求格式很糟糕（比如语法错误、参数格式不对、数据包不完整等），根本无法理解你想干嘛。需要客户端检查并修改请求内容。

​​401 Unauthorized：​​

• ​​“请证明你是你，再说你要干啥。”​​ 你要访问的资源是受保护的，需要登录或者提供身份凭证（比如用户名密码）。你​​还没登录​​或者登录信息​​过期/不对​​，所以服务器拒绝你访问。通常需要你打开登录页面。

​​403 Forbidden：​​

• ​​“我知道你是谁了，但这事不归你管。”​​ 你登录成功了（有身份），但这个账号​​没有权限​​访问/操作你请求的这个资源。你登录张三的账号去改李四的个人信息，就可能遇到这个错误。告诉你有资源存在，但你无权访问。

​​404 Not Found：​​

• ​​“你要找的东西，我们这没有。”​​ 服务器理解你的请求是什么，但是​​找不到​​你请求的资源（那个路径、那个文件、那个用户ID）。可能输错了网址，也可能资源真的被删除了。这是最常见的错误状态码之一。

​​500 Internal Server Error：​​

• ​​“是我不对，我出问题了。”​​ 服务器在处理你的请求时，自己那边发生了意外错误（程序崩溃、配置出错、数据库连不上等）。责任完全在服务器端，客户端（你这边）是没问题的。需要管理员检查服务器日志修复问题。

​​503 Service Unavailable：​​

• ​​“我这会儿太忙（或者维护中），你晚点再来试试？”​​ 服务器现在​​无法处理​​你的请求。原因可能是服务器实在太忙了（比如访问量爆满），或者正在停机维护。这通常是个临时状态，过会儿再试可能就好了。

认识响应 "报头" (header) 

响应报头的基本格式和请求报头的格式基本一致. 类似于Content-Type , Content-Length 等属性的含义也和请求中的含义一致.

Content-Type

响应中的 Content-Type 常见取值有以下几种: t

• ext/html : body 数据格式是 HTML
• text/css : body 数据格式是 CSS
• application/javascript : body 数据格式是 JavaScript
• application/json : body 数据格式是 JSON

 认识响应 "正文" (body)

响应的“正文”（Body）就是服务器处理完你的请求后，真正想发给你的主要数据内容。它是服务器给你的“实质回复”，跟在响应状态码和响应头（Header）后面发送过来。简单说，就是你看网页时最终看到的文字、图片、视频，或者应用程序从API接口接收到的具体数据。

这个Body里面装什么，完全取决于你之前请求了什么以及服务器处理的结果。比如，你请求一个网页（比如首页），服务器响应的Body里通常就是浏览器能解读并渲染出漂亮页面的HTML代码。如果你请求的是一张图片或一个视频文件，那响应的Body就是那个图片或视频文件本身的二进制数据流。如果你用的是APP，调用了一个数据接口，服务器响应Body里装的可能是结构化的JSON或XML数据，里面包含了你要的用户信息、商品列表等等具体数据。

和请求头（Header）描述请求本身的信息不同，响应头（Header）里的一个重要字段 Content-Type 会明确告诉你这个响应Body里装的是啥格式的数据（比如 text/html 表示是HTML网页，application/json 表示是JSON数据，image/png 表示是PNG图片），这样你的浏览器或APP才能用正确的方式去处理和显示或使用它。另一个字段 Content-Length 通常会告诉你Body有多大（字节数），方便接收方处理。服务器通过响应的Body来传递你想要的信息，完成你想要的操作结果。浏览器会根据Content-Type来解析Body，例如，识别到是HTML就渲染成页面，识别到是JSON就交给前端JavaScript处理数据，识别到是图片就显示图片。没有这个Body，只有状态码和响应头，通常意味着服务器没给你返回实质性内容（比如一些简单的成功确认）。