超文本传输协议(英语:HyperText Transfer Protocol,缩写:HTTP)是一种用于分布式、协作式和超媒体信息系统的应用层协议[1]。HTTP是万维网的数据通信的基础。

HTTP 报文组成

HTTP 报文又可以分为请求报文和响应报文,它们的结构都都由三个部分组成。请求报文由请求行、报文首部和主体组成;而响应报文则由状态行、报文首部和主体组成。

请求报文

请求报文的组成部分有请求行、报文首部和主体。


HTTP 协议请求报文示例代码:

GET / HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

主体

代码1

请求行

请求行是位于请求报文的最开头部分,它也是由另外三个更小的部分组成的,分别是请求方法、请求 URL 和协议版本。


如上代码 1 的第一行便是请求行的信息:

GET / HTTP/1.1

请求方法


请求行的最开头部分是请求方法,HTTP/1.1协议中共定义了八种方法(也叫“动作”)来以不同方式操作指定的资源:

  • GET
向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据,而不应当被用于产生“副作用”的操作中
  • HEAD
与GET方法一样,都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。
  • POST
向指定资源提交数据,请求服务器进行处理(例如提交表单或者上传文件)
  • PUT
向指定资源位置上传其最新内容
  • DELETE
请求服务器删除Request-URI所标识的资源
  • TRACE
回显服务器收到的请求,主要用于测试或诊断
  • OPTIONS
这个方法可使服务器传回该资源所支持的所有HTTP请求方法
  • CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接


方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候,服务器应当返回状态码405(Method Not Allowed),当服务器不认识或者不支持对应的请求方法的时候,应当返回状态码501(Not Implemented)。

请求 URL


URL就是因特网资源的标准化名称。URL指向每一条电子信息,告诉你它们位于何处,以及如何与之进行交互。


大多数URL方案的URL语法都建立在这个由9部分构成的通用格式上:

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>


各个通用组件的含义如下:

  • 方案(scheme)
访问服务器资源的指定的具体的协议,如:HTTP、FTP、SMB 等
  • 用户(user)
某些方案访问资源时需要的用户名
  • 密码(password)
用户名后面可能需要密码,中间需要用 : 隔开
  • 主机(host)
资源宿主服务器的主机名或者点分 IP 地址
  • 端口(port)
资源宿主服务器正在监听的端口号,很多协议都会有默认端口号,如:HTTP:80、HTTPS:443、SSH:22 等
  • 路径(path)
服务器资源的本地名称
  • 参数(params)
某些协议会使用这个组件来指定输入的参数 
  • 查询(query)
某些协议会使用这个组件来指定输入的参数 ,如 HTTP
  • 片段(frag)
一小片或一小部分的资源名字,在客户端内部使用,不会传给服务器

协议版本


超文本传输协议已经演化出了很多版本,它们中的大部分都是向下兼容的。客户端在请求的开始告诉服务器它采用的协议版本号,而后者则在响应中采用相同或者更早的协议版本。


可用的协议版本有一下这些

  • HTTP/1.0
这是第一个在通讯中指定版本号的HTTP协议版本,至今仍被广泛采用,特别是在代理服务器中
  • HTTP/1.1
持久连接被默认采用,并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求,以便降低线路负载,提高传输速度。
  • HTTP/2
HTTP/2 更高效、强大.它在传输层解决了以前我们HTTP1.x中一直存在的问题。但是目前为止还没有广泛地被使用

报文首部


报文首部就是请求行后面和空白行前面的部分内容,它们定义了一个超文本传输协议事务中的操作参数。HTTP头部字段可以自己根据需要定义,因此可能在 Web 服务器和浏览器上发现非标准的头字段。


如上代码 1 的第二到第五行便是报文首部的信息:

GET...
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache


从示例代码可用看出,报文首部的字段是以明文的字符串格式传输,是以冒号分隔的键名与键值对,以回车(CR)加换行(LF)符号序列结尾。


HTTP 头字段根据实际用途被分为以下 4 种类型:

  • 通用头字段(英语:General Header Fields)
  • 请求头字段(英语:Request Header Fields)
  • 响应头字段(英语:Response Header Fields)
  • 实体头字段(英语:Entity Header Fields)


一些常用的请求报文首部定义如下:

协议头字段名 说明 示例
Accept 能够接受的回应内容类型(Content-Types) Accept: text/plain
Accept-Charset 能够接受的字符集 Accept-Charset: utf-8
Accept-Encoding 能够接受的编码方式列表。 Accept-Encoding: gzip, deflate
Accept-Language 能够接受的回应内容的自然语言列表。 Accept-Language: en-US
Accept-Datetime 能够接受的按照时间来表示的版本 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
Authorization 用于超文本传输协议的认证的认证信息 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control 用来指定在这次的请求/响应链中的所有缓存机制 都必须 遵守的指令 Cache-Control: no-cache
Connection 该浏览器想要优先使用的连接类型
Connection: keep-alive Connection: Upgrade
Cookie 之前由服务器通过 Set- Cookie (下文详述)发送的一个 超文本传输协议Cookie Cookie: $Version=1; Skin=new;
Content-Length 以 八位字节数组 (8位的字节)表示的请求体的长度 Content-Length: 348
Content-MD5 请求体的内容的二进制 MD5 散列值,以 Base64 编码的结果 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type 请求体的 多媒体类型 (用于POST和PUT请求中) Content-Type: application/x-www-form-urlencoded
Date 发送该消息的日期和时间(按照 RFC 7231 中定义的"超文本传输协议日期"格式来发送) Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect 表明客户端要求服务器做出特定的行为 Expect: 100-continue
From 发起此请求的用户的邮件地址 From: user@example.com
Host 服务器的域名(用于虚拟主机 ),以及服务器所监听的传输控制协议端口号。如果所请求的端口是对应的服务的标准端口,则端口号可被省略。 Host: en.wikipedia.org:80 Host: en.wikipedia.org
If-Match 仅当客户端提供的实体与服务器上对应的实体相匹配时,才进行对应的操作。主要作用时,用作像 PUT 这样的方法中,仅当从用户上次更新某个资源以来,该资源未被修改的情况下,才更新该资源。 If-Match: "737060cd8c284d8af7ad3082f209582d"
If-Modified-Since 允许在对应的内容未被修改的情况下返回304未修改( 304 Not Modified ) If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match 允许在对应的内容未被修改的情况下返回304未修改( 304 Not Modified ),参考 超文本传输协议 的实体标记 If-None-Match: "737060cd8c284d8af7ad3082f209582d"
If-Range 如果该实体未被修改过,则向我发送我所缺少的那一个或多个部分;否则,发送整个新的实体 If-Range: "737060cd8c284d8af7ad3082f209582d"
If-Unmodified-Since 仅当该实体自某个特定时间已来未被修改的情况下,才发送回应。 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Forwards 限制该消息可被代理及网关转发的次数。 Max-Forwards: 10
Origin 发起一个针对 跨来源资源共享 的请求(要求服务器在回应中加入一个‘访问控制-允许来源’('Access-Control-Allow-Origin')字段)。 Origin: http://www.example-social-network.com
Pragma 与具体的实现相关,这些字段可能在请求/回应链中的任何时候产生多种效果。 Pragma: no-cache
Proxy-Authorization 用来向代理进行认证的认证信息。 Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range 仅请求某个实体的一部分。字节偏移以0开始。 Range: bytes=500-999
Referer 表示浏览器所访问的前一个页面,正是那个页面上的某个链接将浏览器带到了当前所请求的这个页面。 Referer: http://en.wikipedia.org/wiki/Main_Page
TE 浏览器预期接受的传输编码方式:可使用回应协议头 Transfer-Encoding 字段中的值;另外还可用"trailers"(与"分块 "传输方式相关)这个值来表明浏览器希望在最后一个尺寸为0的块之后还接收到一些额外的字段。 TE: trailers, deflat
User-Agent 浏览器的浏览器身份标识字符串 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
Upgrade 要求服务器升级到另一个协议。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Via 向服务器告知,这个请求是由哪些代理发出的。 Via: 1.0 fred, 1.1 example.com (Apache/1.1)
Warning 一个一般性的警告,告知,在实体内容体中可能存在错误。 Warning: 199 Miscellaneous warning


一些常用的响应报文首部定义如下:

字段名 说明 例子
Server 服务器的名字 Server: Apache/2.4.1 (Unix)
Access-Control-Allow-Origin 指定哪些网站可参与到跨来源资源共享过程中 Access-Control-Allow-Origin: *
Accept-Patch 指定服务器支持的文件格式类型。 Accept-Patch: text/example;charset=utf-8
Accept-Ranges 这个服务器支持哪些种类的部分内容范围 Accept-Ranges: bytes
Age 这个对象在代理缓存中存在的时间,以秒为单位 Age: 12
Allow 对于特定资源有效的动作。针对HTTP/405这一错误代码而使用 Allow: GET, HEAD
Cache-Control 向从服务器直到客户端在内的所有缓存机制告知,它们是否可以缓存这个对象。其单位为秒 Cache-Control: max-age=3600
Connection 针对该连接所预期的选项
Connection: close
Content-Disposition 一个可以让客户端下载文件并建议文件名的头部。文件名需要用双引号包裹。 Content-Disposition: attachment; filename="fname.ext"
Content-Encoding 在数据上使用的编码类型。参考 超文本传输协议压缩 。 Content-Encoding: gzip
Content-Language 内容所使用的语言
Content-Language: da
Content-Length 回应消息体的长度,以 字节 (8位为一字节)为单位 Content-Length: 348
Content-Location 所返回的数据的一个候选位置 Content-Location: /index.htm
Content-MD5 回应内容的二进制 MD5 散列,以 Base64 方式编码 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range 这条部分消息是属于某条完整消息的哪个部分 Content-Range: bytes 21010-47021/47022
Content-Type 当前内容的MIME类型 Content-Type: text/html; charset=utf-8
Date 此条消息被发送时的日期和时间(按照 RFC 7231 中定义的“超文本传输协议日期”格式来表示) Date: Tue, 15 Nov 1994 08:12:31 GMT
ETag 对于某个资源的某个特定版本的一个标识符,通常是一个 消息散列 ETag: "737060cd8c284d8af7ad3082f209582d"
Expires 指定一个日期/时间,超过该时间则认为此回应已经过期 Expires: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified 所请求的对象的最后修改日期(按照 RFC 7231 中定义的“超文本传输协议日期”格式来表示) Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Link 用来表达与另一个资源之间的类型关系,此处所说的类型关系是在 RFC 5988 中定义的 Link: </feed>; rel="alternate"
Location 用来 进行重定向,或者在创建了某个新资源时使用。 Location: http://www.w3.org/pub/WWW/People.html
P3P 用于支持设置P3P策略,标准格式为“P3P:CP="your_compact_policy"”。然而P3P规范并不成功,大部分现代浏览器没有完整实现该功能,而大量网站也将该值设为假值,从而足以用来欺骗浏览器的P3P插件功能并授权给第三方Cookies。 P3P: CP="This is not a P3P policy! 
Pragma 与具体的实现相关,这些字段可能在请求/回应链中的任何时候产生多种效果。 Pragma: no-cache
Proxy-Authenticate 要求在访问代理时提供身份认证信息。 Proxy-Authenticate: Basic
Public-Key-Pins 用于缓解中间人攻击,声明网站认证使用的传输层安全协议证书的散列值 Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
Refresh 用于设定可定时的重定向跳转。右边例子设定了5秒后跳转至“http://www.w3.org/pub/WWW/People.html”。 Refresh: 5; url=http://www.w3.org/pub/WWW/People.html
Retry-After 如果某个实体临时不可用,则,此协议头用来告知客户端日后重试。其值可以是一个特定的时间段(以秒为单位)或一个超文本传输协议日期。 Retry-After: 120
Retry-After: Fri, 07 Nov 2014 23:59:59 GMT
Set-Cookie HTTP cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Status 通用网关接口 协议头字段,用来说明当前这个超文本传输协议回应的 状态 。普通的超文本传输协议回应,会使用单独的“状态行”("Status-Line")作为替代,这一点是在 RFC 7230 中定义的。 Status: 200 OK
Strict-Transport-Security HTTP 严格传输安全这一头部告知客户端缓存这一强制 HTTPS 策略的时间,以及这一策略是否适用于其子域名。 Strict-Transport-Security: max-age=16070400; includeSubDomains
Trailer 这个头部数值指示了在这一系列头部信息由由分块传输编码编码。 Trailer: Max-Forwards
Transfer-Encoding 用来将实体安全地传输给用户的编码形式。当前定义的方法包括:分块(chunked)、compress、deflate、gzip和identity。 Transfer-Encoding: chunked
Upgrade 要求客户端升级到另一个协议。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Vary 告知下游的代理服务器,应当如何对未来的请求协议头进行匹配,以决定是否可使用已缓存的回应内容而不是重新从原始服务器请求新的内容。 Vary: *
Via 告知代理服务器的客户端,当前回应是通过什么途径发送的。 Via: 1.0 fred, 1.1 example.com (Apache/1.1)
Warning 一般性的警告,告知在实体内容体中可能存在错误。 Warning: 199 Miscellaneous warning
WWW-Authenticate 表明在请求获取这个实体时应当使用的认证模式。 WWW-Authenticate: Basic

主体


HTTP报文的第三部分是可选的实体主体部分。实体的主体是HTTP报文的负荷。

响应报文


响应报文是由服务器发送的,用来作为请求报文的回应。


响应报文和请求报文的格式差不多,也是由三部分组成,它们分别是状态行、报文首部和主体


HTTP 协议请求报文示例代码:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html
Date: Mon, 06 Apr 2020 04:13:51 GMT
Server: BWS/1.1
Set-Cookie: delPer=0; path=/; domain=.baidu.com
Set-Cookie: BD_CK_SAM=1;path=/

主体

代码 2

状态行


状态行在响应报文的第一行,它包含三部分内容,协议版本、状态码和原因短语。


协议部分在前面已经说过了,这里说一下状态码和短语。

状态码
  • 1xx消息
请求已被服务器接收,继续处理
  • 2xx成功
请求已成功被服务器接收、理解、并接受

200 OK 请求没问题

  • 3xx重定向
需要后续操作才能完成这一请求

301 Move Permantly 永久重定向资源
302 Found 临时重定向资源

  • 4xx请求错误
请求含有词法错误或者无法被执行

400 Bad Request 错误的请求
403 Forbidden 请求被服务器拒绝
404 Not Found 服务器找不到资源

  • 5xx服务器错误
服务器在处理某个正确请求时发生错误

502 Bad Gateway 网关错误
503 Service Un-available 服务不可用
504 GatewayTimeout 网关超时

报文首部


前面已经提过了。

主体


HTTP报文的第三部分是可选的实体主体部分。实体的主体是HTTP报文的负荷。就是HTTP要传输的内容。HTTP报文可以承载很多类型的数字数据:图片、视频、HTML文档、软件应用程序、信用卡事务、电子邮件等。



chenishr
238 声望11 粉丝

淡泊以明志,宁静以致远