HTTP 结构简介
一、请求方法
- HTTP的请求方法有哪些？
GET POST HEAD PUT TRACE DELETE OPTIONS
下表描述了7种这样的方法。注意，有些方法的请求报文中有主体，有些则是无主题的请求。
| 方法 | 描述 | 是否包含主体 |
|---|---|---|
| GET | 从服务器获取一份文档 | 否 |
| HEAD | 只从服务器获取文档的首部 | 否 |
| POST | 向服务器发送需要处理的数据 | 是 |
| PUT | 将请求的主体部分存储在服务器上 | 是 |
| TRACE | 对可能经过代理服务器传动到服务器上去的报文进行追踪 | 否 |
| OPTIONS | 决定可以在服务器上执行那些方法 | 否 |
| DELETE | 从服务器上删除一份文档 | 否 |
并不是所有服务器都实现表中列出的所有7种方法。而且，由于HTTP涉及得易于扩展，所以除了这些方法之外，其他服务器可能还会实现一些自己的请求方法。这些附加的方法是对HTTP规范的扩展，因此被称为扩展发发。
HEAC 和GET 基本一致，只是不会返回内容。
- 请求报文的格式
<method> <request-URL><version>
<headers>
<edtitu-body>
- 这是响应报文的格式（注意，只有起始行的语法有所不同）；
<version><status><reason-phrase>
<hesders>
<entity-bodu>
HTTP请求和响应结构
| 请求行（请求方法 路径 协议） | 响应行(协议 状态码 状态文字) |
|---|---|
| 头信息（格式为 key：value | 响应头信息（格式为 key:value) |
| 空行 | 空行 |
| 主体信息（可选）（发送内容） | 主体信息（也可能没有） |
- 请求起始行:主要是 介绍了 请求方法、请求资源、http的版本
- 响应起始行：主要是 返回了 http 版本，以及响应的状态码
- 请求首部：connection：保持帮连接
connection-type： 连接 类型
user-agent 请求客户端信息（浏览器版本，系统版本等等）
host：域名
accept：接受文件类型 文档，图片等
accept-language：（接受文档语言类型）
cookie： 请求的时候回自动 带上该页面的 cookie - 响应首部：data：格林威治时间
server： 服务端信息（服务器版本等等）
last-modifie： 最后一次链接时间
content-lenth：响应内容长度
content-type：响应内容的 文件类型 - 请求主体：如果该请求包含了请求字段：那么请求主体均为 parameters
- 响应主体：根据请求的 文档类型进行对应的返回，比如 text/html 则返回 html 的 文档
我们常见的可能是 返回的一个 数据对象。等等
下面是对各部分的简要描述：
-
方法（method）
客户端希望服务器对资源执行的动作。是一个单独的词，比如GET、HEAD或POST
-
请求URL（repuwst-URL）
命名了所有请求资源，或者URL路径组件的完整URL。如果直接与服务器进行对话，只要URL的路径组件是资源的绝对路径，通常就不会有什么问题-服务器可以假定自己是URL的主机\端口。
-
版本（version)
报文所使用的HTTP版本，其格式看起来是这样的：
HTTP/.
其中主要版本号（major）和次要版本号（minor)都是整数。
-
状态码（status-code)
这三位数字描述了请求过程中所发生的的情况。每个状态码的第一位数字都用于描述状态的一般类别（“成功”、”出错“等）
-
原因短语（reason-phrase)
数字状态码的可读版本，包括行终止序列之前的所有文本。原因短语支队人类有意义，因此，比如说，尽管响应行HTTP\1.0 200 OK中原因短语的含义不同，但同样都会被当做成功指示处理。
-
首部（header)
可以是零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号（：），然后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是有一个空行（CRLF)）结束的，表示了首部列表的结束和实体主体部分的开始。有些HTTPb版本，比如HTTP\1.1，要求有效的请求或响应报文中必须包含特定的首部。
-
实体的主体（entity-body)
实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分，有时，报文只是以一个CELF结束。
注意：一组HTTP首部总是应该以一个空行（单个CELF）结束，甚至即使没有首部和实体的主体部分也应如此。但是由于历史原因，很多客户端和服务器都在没有实体和主体部分时，（错误地）省略了最后的CRLF。为了与这些流行但你不符合规则的实现进行互通，客户端和服务器都应该接受那些没有最后那个CRLF的报文。 SSH命令.md
二、http能够现实的原理
| HTTP | 应用层 |
|---|---|
| tcp | 传输层 |
| ip | 网络层 |
| 网络特有的链路接口 | 数据链路层 |
| 物理网络硬件 | 物理层 |
HTTP 处于 这五层中 应用层，也就是说 http这一层其实是不涉及到 数据通信通能的，他只是在 为通信之前做了一系列的 准备工作而已。那么接下来就简单了，http 不需要关心 网络通信的具体细节，这些细节都交给了可靠的tcp/ip也就是传输层 和 网络层。
Intelnet 自身就是 基于 TCP/IP，TCP/IP是全世界计算机和网络设备常用的层析话分组交互网络协议集合。只要建立了TCP/IP连接，客户端 和 服务器之间的 报文交换就不会丢失，不会被破坏，也不会再接受时出现错误的顺序等问题，总之TCP/IP 就是很靠谱，HTTP 把数据通信 交给 它，剩下的就 交给网速。
三、TCP流是分段的、有ip分组传送
tcp的数据是通过名为ip分组（或ip数据报）的小数据块来发送的。这样的话，HTTP就是“HTTP over tcp over ip ”这个“协议栈”中的最顶层了。其安全版本HTTPS就是在HTTP和tcp之间插入了一个（称为TLS或SSL的）密码加密层。
| HTTP | 应用层 | HTTP | 应用层 |
|---|---|---|---|
| TCP | 传输层 | TSL or SSL | 加密层 |
| IP | 网络层 | TCP | 传输层 |
| 网络接口 | 数据链路层 | IP | 网络层 |
| 网络接口 | 数据链路层 | ||
| http | https |
四、起始行介绍
所有的HTTP报文都以一个起始行作为开始。请求报文的起始行说明了要做些什么。响应报文的起始行说明发生了什么、
- 请求行
请求报文请求服务器对资源进行一些操作。请求报文的起始行，或称为请求行，包含了一个方法和一个请求URL，这个方法描述了服务器应该执行的操作，请求URL描述了要对那个资源执行这个方法。请求行中还包含HTTP的版本，用来告知服务器，客户端使用的是那种HTTP。
所有的这些字段都由空格符分隔。在上列表中，请求方法为GET，请求URL为/test/hi-there.text,版本为HTTP/1.0.在HTTP/1.0之前，并不要求请求行中包含HTTP版本号。
- 响应行
响应报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。响应报文的起始行，或称为响应行，包含了响应报文使用的HTTP版本、数字状态码，以及描述操作状态的文本形式的原因短语。
所有这些字段都是有空格符进行分隔，HTTP版本为HTTP/1.0，状态码为200（表示成功），原因短语为OK，表示文档已经被成功返回了。在HTTP/1.0之前，并不要求在响应中包含应行。
- 方法
请求的起始行以方法作为开始，方法用来告知服务器要做些什么。比如，在行“GET/specials/saw-blade.gif HTTP/1.0”中，方法就是GET.
HTTP规范中定义了一组常用的请求方法。比如，GET方法负责从服务器获取一个文档，POST方法会向服务器发送需要处理的数据，OPTIONS方法用于确定WEB服务器的一般功能，或者Web服务器处理特定资源的能力。
五、常见错误的状态码
方法是用来告诉服务器做什么事情的，状态码则用来告诉客户端，发生了什么事情。
状态码位于响应的起始行中。比如，在行HTTP/1.0 200 OK中，状态码就是200。
客户端向一个HTTP服务器发送请求报文时，会发生很多事情。幸运的话，请求会成功完成。但你不会总是那么幸运的。服务器可能会告诉你无法找到所请求的资源，你没有访问资源的权限，或者资源被移到了其他地方。
状态码是在每条响应报文的起始行中返回的，会返回一个数字状态和一个可读的状态。数字码便于程序进行差错处理，而原因短语则更便于人们理解。
可以通过三位数字代码对不同状态码进行分类。200到299之间的状态码表示成功。300到399之间的代码表示资源已经被移走了。400到499之间的代码表示客户端的请求出错了。500到599之间的代码表示服务器出错了。
状态码分类
| 整体范围 | 已定义范围 | 分类 |
|---|---|---|
| 100~199 | 100~101 | 信息提示 |
| 200~299 | 200~206 | 成功 |
| 300~399 | 300~305 | 重定向 |
| 400~499 | 400~415 | 客户端错误 |
| 500~599 | 500~505 | 服务器错误 |
常见状态码
| 状态码 | 原因短语 | 含义 |
|---|---|---|
| 200 | OK | 成功。请求的所有数据都在响应主体中 |
| 401 | Unauthorized（未授权） | 需要输入用户名和密码 |
| 404 | Not Found(未找到) | 服务器无法找到所请求URL对应的资源 |
400~499——客户端错误状态码
有时客户端会发送一些服务器无法处理的东西，比如格式错误的请求报文，或者最常见的是，请求一个不存在的URL.
浏览网页时，我们都看到过臭名昭著的404 Not Found错误码——这只是服务器再告诉我们，他对我们的请求的资源一无所知。
很多客户端错误都是由浏览器来处理的，甚至不会打扰到你。只有少量错误，比如404，还是会穿过浏览器来到用户面前。
下表为客户端错误状态码及原因短语
| 状态码 | 原因短语 | 含义 |
|---|---|---|
| 400 | bad request | 用于告知客户端它发送了一个错误的请求 |
| 401 | unauthorized | 与适当的首部一同返回，在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证。 |
| 402 | payment required | 现在这个状态码还未使用，但已经被保留，以作未来只用 |
| 403 | forbidden | 用于说明请求被服务器拒绝了。但如果服务器想说明为什么拒绝请求，可以包含实体的主体部分来对原因进行描述。但这个状态码通常是在服务器不想说明拒绝原因的时候使用的 |
| 404 | not found | 用于说明服务器无法找到所请求的URL。通常会包含一个实体，以便客户端应用程序显示给用户看 |
| 405 | method not allowud | 发起的请求带有所请求的URL支持的方法时，使用此状态码。应该在响应中包含ALLOW首部，以告知客户端对所请求的资源可以使用那些方法 |
| 406 | not acceptable | 客户端可以指定参数来说明他们愿意接受什么类型的实体。服务器没有与客户端可接受的URL想匹配的资源时，使用此代码。通常，服务器会包含一些首部，以便客户端弄清楚为什么请求无法满足。 |
| 407 | Proxy authentication required | 与401状态码类似，但要用于要求对资源进行认证的代理服务器 |
| 408 | Request timeout | 如果客户端完成请求所花的时间太长，服务器可以回送此状态码，并关闭连接。超时时长随服务器的不同有所不同，但通常对所有的合法请求来说，都是够长的。 |
| 409 | conflict | 用于说明请求可能在资源上引发的一些冲突。服务器担心请求会引发冲突时，可以发送此状态码。响应中应该包含描述冲突的主体。 |
| 410 | gone | 与404类似，只是服务器曾经拥有过此资源。主要用于web站点的维护，这样服务器的管理者就可以在资源被移除的情况下通知客户端了 |
| 411 | Length required | 服务器要求在请求报文中包含content-length首部时使用。 |
| 412 | Precondition failed | 客户端发起了条件请求，且其中一个条件失败了的时候使用。客户端包含了expect首部时发起的就是条件请求 |
| 413 | Request entity too large | 客户端发送的实体主体部分比服务器能够活着希望处理的要大时，使用此状态码 |
| 414 | request URI too large | 客户端所发请求 |
来源：CSDN
作者：Green Hill
链接：https://blog.csdn.net/weixin_45807072/article/details/103783453