HTTP协议详解

文章目录

• HTTP协议详解
• HTTP协议的特点：
• HTTP协议详解之URL
• HTTP协议详解之请求方法
• HTTP协议详解之请求报文
• 请求行
• 请求首部字段
• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Authorization
• Expect
• From
• Host
• If-xxxx
• Max-Forwards
• Proxy-Authorization
• Range
• Referer
• TE
• User-Agent

HTTP协议详解

HTTP协议的特点：

1. 支持客户/服务器模式。
2. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. 单请求：每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP协议详解之URL

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：
http://host[":"port][abs_path]

• http表示要通过HTTP协议来定位网络资源；
• host表示合法的Internet主机域名或者IP地址；
• port指定一个端口号，为空则使用缺省端口80；
• abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

例如：

1. 输入：www.guet.edu.cn
   浏览器自动转换成：http://www.guet.edu.cn/
2. 最终的URL：http:192.168.0.116:8080/index.jsp

HTTP协议详解之请求方法

HTTP协议详解之请求报文

下图是HTTP请求报文的结构.

请求行

以一个方法符号开头，以空格或斜杠分开，后面跟着请求的URI和协议的版本。
格式如下：Method Request-URI HTTP-Version CRLF

• Method表示请求方法；
• Request-URI是一个统一资源标识符；
• HTTP-Version表示请求的HTTP协议版本；
• CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

例如：GET / 123.jpg / HTTP1.1

请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

Accept

Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用 type/subtype 这种形式，一次指定多种媒体类型。

常见accept媒体类型有：
- 文本文件
text/html, text/plain, text/css …
application/xhtml+xml, application/xml …
- 图片文件
image/jpeg, image/gif, image/png …
- 视频文件
video/mpeg, video/quicktime …
- 应用程序使用的二进制文件
application/octet-stream, application/zip …

Accept-Charset

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字段 Accept 相同的是可用权重 q 值来表示相对优先级。
如：Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Accept-Encoding

Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。采用权重 q 值来表示相对优先级，这点与首部字段 Accept 相同。另外，也可使用星号（*）作为通配符，指定任意的编码格式。
如：Accept-Encoding: gzip, deflate
试举几个内容编码的例子：
- gzip
由文件压缩程序 gzip（GNU zip）生成的编码格式（RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循环冗余校验（Cyclic Redundancy Check，通称 CRC）。
- compress
由 UNIX 文件压缩程序 compress 生成的编码格式，采用 Lempel-Ziv-Welch 算法（LZW）。
- deflate
组合使用 zlib 格式（RFC1950）及由 deflate 压缩算法（RFC1951）生成的编码格式。
- identity
不执行压缩或不会变化的默认编码格式

Accept-Language

首部字段 Accept-Language 用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级。可一次指定多种自然语言集。和 Accept 首部字段一样，按权重值 q 来表示相对优先级。
如：Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3

Authorization

首部字段 Authorization 是用来告知服务器，用户代理的认证信息（证书值）。通常，想要通过服务器认证的用户代理会在接收到返回的401 状态码响应后，把首部字段 Authorization 加入请求中。共用缓存在接收到含有 Authorization 首部字段的请求时的操作处理会略有差异。

Expect

客户端使用首部字段 Expect 来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出回应而发生错误时，会返回
状态码 417 Expectation Failed。
客户端可以利用该首部字段，写明所期望的扩展。虽然 HTTP/1.1 规范只定义了 100-continue。
如：Expect: 100-continue
100-continue：
　　1、http 100-continue用于客户端在发送POST数据给服务器前，征询服务器情况，看服务器是否处理POST的数据，如果不处理，客户
　　 端则不上传POST数据，如果处理，则POST上传数据。在现实应用中，通过在POST大数据时，才会使用100-continue协议。
　　2、客户端策略。
　　　　1）如果客户端有POST数据要上传，可以考虑使用100-continue协议。加入头{“Expect”:“100-continue”}
　　　　2）如果没有POST数据，不能使用100-continue协议，因为这会让服务端造成误解。
　　　　3）并不是所有的Server都会正确实现100-continue协议，如果Client发送Expect:100-continue消息后，在timeout时间内无响应，
　　　　Client需要立马上传POST数据。
　　　　4）有些Server会错误实现100-continue协议，在不需要此协议时返回100，此时客户端应该忽略。
　　3、服务端策略。
　　　　1）正确情况下，收到请求后，返回100或错误码。
　　　　2）如果在发送100-continue前收到了POST数据（客户端提前发送POST数据），则不发送100响应码(略去)。

From

首部字段 From 用来告知服务器使用用户代理的用户的电子邮件地址。通常，其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。使用代理时，应尽可能包含 From 首部字段（但可能会因代理不同，将电子邮件地址记录在 User-Agent 首部字段内）。

Host

首部字段 Host 会告知服务器，请求的资源所处的互联网主机名和端口号。Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请
求内的首部字段。

首部字段 Host 和以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联，这是首部字段 Host 必须存在的意义。请求被发送至服务器时，请求中的主机名会用 IP 地址直接替换解决。但如果这时，相同的 IP 地址下部署运行着多个域名，那么服务器就会无法理解究竟是哪个域名对应的请求。因此，就需要使用首部字段 Host 来明确指出请求的主机名。
若服务器未设定主机名，那直接发送一个空值即可。如下所示。

If-xxxx

形如 If-xxx 这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

• If-Match:只有当 If-Match 的字段值跟 ETag 值匹配一致时，服务器才会接受请求反之，则返回状态码 412 Precondition Failed 的响
  应。
• If-Modified-Since:如果在 If-Modified-Since 字段指定的日期时间后，资源发生了更新，服务器会接受请求,而在指定 If-Modified-Since 字段值的日期时间之后，如果请求的资源都没有过更新，则返回状态码 304 Not Modified 的响应。
• If-None-Match:只有在 If-None-Match 的字段值与 ETag 值不一致时，可处理该请求。与 If-Match 首部字段的作用相反
• If-Range:它告知服务器若指定的 If-Range 字段值（ETag 值或者时间）和请求资源的 ETag 值或时间相一致时，则作为范围请求处理。反之，则返回全体资源。
• If-Unmodified-Since:首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相反。它的作用的是告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。如果在指定日期时间后发生了更新，则以状态码 412 Precondition Failed 作为响应返回。

Max-Forwards

通过 TRACE 方法或 OPTIONS 方法，发送包含首部字段 Max-Forwards 的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，Max-Forwards 的值减 1 后重新赋值。当服务器接收到 Max-Forwards 值为 0 的请求时，则不再进行转发，而是直接返回响应。
使用 HTTP 协议通信时，请求可能会经过代理等多台服务器。途中，如果代理服务器由于某些原因导致请求转发失败，客户端也就等不到服务器返回的响应了。对此，我们无从可知。
因此可以灵活使用首部字段 Max-Forwards，针对以上问题产生的原因展开调查。由于当 Max-Forwards 字段值为 0 时，服务器就会立即返回响应，由此我们至少可以对以那台服务器为终点的传输路径的通信状况有所把握。

Proxy-Authorization

接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段Proxy-Authorization 的请求，以告知服务器认证所需要的信息。这个行为是与客户端和服务器之间的 HTTP 访问认证相类似的，不同之处在于，认证行为发生在客户端与代理之间。客户端与服务器之间的认证，使用首部字段 Authorization 可起到相同作用。
如：Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

Range

例子：Range: bytes=5001-10000
对于只需获取部分资源的范围请求，包含首部字段 Range 即可告知服务器资源的指定范围。上面的示例表示请求获取从第 5001 字节至第10000 字节的资源。
接收到附带 Range 首部字段请求的服务器，会在处理请求之后返回状态码为 206 Partial Content 的响应。无法处理该范围请求时，则会返回状态码 200 OK 的响应及全部资源。

Referer

首部字段 Referer 会告知服务器请求的原始资源的 URI。（应该是指从哪个页面跳转过来的）
比如：在https://blog.csdn.net/shenqueying/article/details/79426884网页中有一个https://www.sojson.com/blog/58.html链接，如下图所示：

点击这个https://www.sojson.com/blog/58.html，在该http请求中的header信息里就有：
Referer=https://blog.csdn.net/shenqueying/article/details/79426884

TE

首部字段 TE 会告知服务器客户端能够处理响应的传输编码方式及相对优先级。它和首部字段 Accept-Encoding 的功能很相像，但是用于传输编码。
如：TE: gzip, deflate;q=0.5
首部字段 TE 除指定传输编码之外，还可以指定伴随 trailer 字段的分块传输编码的方式。应用后者时，只需把 trailers 赋值给该字段值。
如：TE: trailers

User-Agent

首部字段 User-Agent 会将创建请求的浏览器和用户代理名称等信息传达给服务器。
例如QQ浏览器访问网页时，就会带上QQ浏览器的信息.

来源：CSDN

作者：年轻态程序猿

链接：https://blog.csdn.net/weixin_38537730/article/details/104144572