网络协议 | 您所在的位置:网站首页 › UDP报文结构有哪几部分组成功能是 › 网络协议 |
HTTP 报文简介
用于 HTTP 协议交互的信息被称为 HTTP 报文,请求端(客户端)发起的 HTTP 报文叫做请求报文,响应端(服务器端)发出的 HTTP 报文叫做响应报文。请求报文会向 Web 服务器请求一个动作,响应报文会将请求的处理结果返回给客户端。 HTTP 报文本身是由多行(用CR+LF作换行符,即\r\n)数据构成的字符串文本,这些文本信息描述了报文的内容及含义,后面跟着可选的数据部分。 HTTP 报文大致可分为报文首部和报文主体两块,两者由首次出现的空行来分隔,通常,并不一定要有报文主体,比如 GET 请求就没有:
了解了 HTTP 报文的基本概念后,下面我们具体分析 HTTP 报文的组成结构。 HTTP 报文是简单的格式化数据块:
我们以 http://laravel58.test/ 为例,其请求报文的组成结构如下:
请求报文可以抽象为如下格式: (请求行)响应报文可以抽象如下格式: (响应行)下面是对各部分的简单描述: 方法(method):客户端希望服务器对资源执行的动作,比如 GET、POST、PUT、DELETE 等; 请求 URL(request-URL):命名了所请求资源,或者 URL 路径组成的完整 URL,比如 http://laravel58.test/ 这个示例中是 /; 版本(version):HTTP 版本,目前主流版本是 1.1; 状态码(status-code):三个数字,描述了请求过程所发生的情况,例如 200、404、500 等; 原因短语(reason-phrase):数字状态码的可读版本; 首部字段(headers):可以有零个或多个首部,每个首部都包含一个名字,后面跟着一个冒号,然后是一个可选的空格,接着是一个值,最后是一个 CR+LF(即\r\n),报文首部是由一个空行结束的,表示了首部列表的结束和实体主体部分的开始; 主体(entity-body):包含一个由任意数据组成的数据块,并不是所有报文都包含实体的主体部分。 HTTP 请求方法在请求报文的第一行第一个元素就是 HTTP 方法,HTTP 协议主要支持的方法包括以下这些:
GET 方法用于从服务器上获取指定的 URL 资源:
HEAD 方法和 GET 方法类似,但只返回 HTTP 首部,不返回报文主体部分,通常用于确认 URL 的有效性及资源更新的日期时间等:
POST 方法用来向服务器发送数据,通常用它来支持 HTML 的表单,POST 请求会对服务器资源进行变更(这一点需要开发者保证,HTTP 协议本身没有强制要求这么做,你完全可以通过 GET 请求发送数据,但是从安全角度说,强烈建议这么做,即用 POST 方法发送变更资源的请求),是不安全的 HTTP 方法。 我们以 Laravel 框架自带的注册页面为例:
PUT 方法设计的初衷是用来传输文件,就像 FTP 协议的文件上传一样,要求在报文的主体中包含文件内容,然后保存到请求 URI 指定的位置。但是,由于 PUT 方法自身不带验证机制,任何人都可以上传文件,存在安全性问题,因此一般 Web 网站不会通过该方法来上传文件。若配合 Web 应用程序的验证机制,则可能会开放使用 PUT 方法。 PUT 方法的语义就是让服务器用请求主体部分来创建一个由所请求的 URL 命令的新文档,或者,如果那个 URL 已经存在的话,就用这个主体来替代它,因此,我们会看到在 RESTful 架构中,我们一般使用 PUT 方法来更新资源,Laravel 框架中的资源控制器就是这么做的。 与 PUT 方法类似的还有一个 PATCH 方法,用于对指定资源进行部分修改(PUT 方法用于整体覆盖),但是日常开发中,我们不会分的这么细,通常,可以用 PATCH 的地方,往往就可以用 PUT 方法替代。 和 POST 方法一样,PUT 方法也是不安全的 HTTP 方法。具体请求和响应报文格式和 POST 类似,这里不再重复演示了。 需要注意的是,在 Nginx 中,默认只支持对静态资源进行 GET、POST、HEAD 请求,其他 HTTP 方法都会返回 405 Method Not Allowed,要支持的其他 HTTP 方法的话需要配置。所以你会看到在 Laravel 框架中都是通过方法伪造来实现 PUT、DELETE 请求。 DELETEDELETE 方法设计的初衷是用来删除文件,是与 PUT 请求相对的方法,DELETE 方法按请求 URI 删除指定的资源。但是,HTTP/1.1 的 DELETE 方法和 PUT 方法一样不带验证机制,所以一般 Web 网站也不使用 DELETE 方法进行文件删除,当配合 Web 应用程序的验证机制,或遵守 REST 标准时还是有可能会开放使用的。 目前我们会在 RESTful 架构中,通过 DELETE 方法来删除资源(不一定是文件),Laravel 框架中的资源控制器就是这么做的。DELETE 请求报文中不需要报文实体,只需要通过 URL 来定位资源即可。和 PUT 方法一样,我们需要在 HTML 表单中伪造 DELETE 方法才能让 Nginx 支持 DELETE 请求。 和 POST 方法一样,DELETE 方法也是不安全的 HTTP 方法。 OPTIONSOPTIONS 方法用来查询针对请求 URL 指定的资源支持的所有 HTTP 方法。Nginx 默认也不支持对资源发起 OPTIONS 请求,我们可以通过在 Laravel 项目中 PHP 内置的 Web 服务器来模拟 OPTIONS 请求,首先通过 php artisan serve 启动内置服务器,然后通过 TELNET 进行模拟通信:
客户端发起一个请求时,这个请求可能要穿过防火墙、代理、网关或其他一些应用程序,每个中间节点都可能会修改原始的 HTTP 请求,TRACE 方法允许客户端在最终请求发送给服务器时,看看它变成了什么样子。该命令主要用于 HTTP 通信的诊断和调试。 TRACE 请求会在目标服务器端发起一个「环回」诊断,行程最后一站的服务器会返回一条 TRACE 响应,并在响应主体中携带它收到的原始请求报文,这样,客户端就可以查看在所有中间 HTTP 应用程序组成的请求/响应链上,原始报文是否以及如何被修改过。 发送 TRACE 请求时,可以在 Max-Forwards 首部字段中填入数值,每经过一个服务器/中间节点该数值就会减1,当数值刚好减到0时,就停止继续传输,最后接收到请求的服务器/节点则返回状态码 200 OK 的响应(不管是否到达最终目标服务器都会返回,不会再继续传递请求)。 但是,TRACE 方法并不怎么常用,再加上容易引发 XST(Cross-Site Tracing,跨站追踪)攻击,就更不会用到了。 HTTP 响应状态码当目前为止,我们已经介绍完了 HTTP 请求报文起始行的所有元素,第一个是请求方法,第二个是标识请求资源的 URL(一般来说是相对于域名的相对 URL,Web 服务器会将其和请求首部里的 Host 字段组合拼接成完整 URL),第三个是客户端 HTTP 协议的版本,关于报文首部我们放到下一篇统一介绍,现在我们跳到响应报文的起始行,前面学院君已经简单介绍过,响应报文的起始行也由三部分组成,分别是服务器 HTTP 协议的版本,响应状态码以及原因短语,HTTP 协议的版本我们已经讨论过,响应短语主要是响应状态码的可读版本,所以我们重点关注响应状态码。 状态码的职责是当客户端向服务器端发送请求时,描述返回的处理结果,借助状态码,用户可以知道服务器端是正常处理了请求还是出现了错误。
信息性状态码日常很少见,主要有如下两个:
2XX 的响应结果表明请求被服务器正常处理了。常见的 2XX 状态码如下所示:
3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求,比如对请求进行重定向,常见的 3XX 状态码如下所示:
注:当 301、302、303 响应状态码返回时,几乎所有浏览器都会把 POST 改成 GET,并删除请求报文内的主体,之后请求会自动再次发送。 4XX:客户端错误状态码4XX 的响应结果表示客户端是发生错误的原因所在,常见的 4XX 状态码列举如下:
5XX 的响应结果表明服务器本身发生错误,常见的 5XX 状态码如下所示:
|
CopyRight 2018-2019 实验室设备网 版权所有 |