HTTP报文详解

HTTP有两种报文:请求报文和响应报文,具体介绍如下

一、HTTP请求报文

先上个图,细细分析


HTTP请求报文主要包括请求行、请求头部以及请求的数据(实体)三部分

请求行(HTTP请求报文的第一行)

请求行由方法字段、URL字段和HTTP协议版本字段。其中,方法字段严格区分大小写,当前HTTP协议中的方法都是大写,方法字段如下介绍如下:

方法字段

①GET:请求获取Request-URI(URI:通用资源标识符,URL是其子集,URI注重的是标识,而URL强调的是位置,可以将URL看成原始的URI),所标识的资源

②POST:在Request-URI所标识的资源后附加新的数据;支持HTML表单提交,表单中有用户添入的数据,这些数据会发送到服务器端,由服务器存储至某位置(例如发送处理程序)

③HEAD:请求Request-URI所标识的资源响应消息报头,HEAD方法可以在响应时不返回消息体。

④PUT:与GET相反,请求服务器存储一个资源,并用Request-URI做为其标识;例如发布系统。

⑤DELETE:请求删除URL指向的资源

⑥OPTIONS:请求查询服务器的性能,或者查询与资源相关的选项

⑦TRACE:跟踪请求要经过的防火墙、代理或网关等,主要用于测试或诊断

⑧CONNECT保留将来使用

URL

一个完整的包括类型、主机名和可选路径名的统一资源引用名,如:http://www.example.com/path/to/file.html

请求头部:位于请求行的下面

请求报文中常见的标头有:

Connetion标头(连接管理)、Host标头(指定请求资源的主机)、Range标头(请求实体的字节范围)、User-Agent标头(包含发出请求的用户信息)、Accept标头(首选的媒体类型)、Accept-Language(首选的自然语言)

HTTP首部:

通用首部:请求和响应都可以使用的;

Connection:定义C/S之间关于请求/响应的有关选项
对于http/1.0, Connection: keep-alive
Via: 显示了报文经过的中间节点

Cache-Control: 缓存指示

实体首部:用于指定实体属性

实体主体用于POST方法中。用户向Web服务器提交表单数据的时候,需要使用POST方法,此时主体中包含用户添写在表单的各个属性字段的值,当Web服务器收到POST方法的HTTP请求报文后,可以从实体中取出需要的属性字段的值。

也就是说,当用户通过Web浏览器向Web服务器发送请求时,Web浏览器会根据用户的具体请求来选择不同的HTTP请求方法,再将相应的URL和HTTP协议版本及相关的标头填入头部行中,若是POST方法,还会将相关的表单数据填入实体主体中,产生一个HTTP请求报文,然后将这个报文发送给Web服务器。

Location: 资源的新位置
Allow: 允许对此资源使用的请求方法
1、内容首部:
Content-Encoding:支持的编码
Content-Language:支持的自然语言
Content-Length:文本长度
Content-Location:资源所在位置
Content-Range:在整个资源中此实体表示的字节范围

Content-Type:主体的对象类型

2、缓存首部:
ETag: 实体标签
Expires: 过期期限
Last-Modified: 上一次的修改时间

请求首部:

Host: 请求的主机名和端口号,虚拟主机环境下用于不同的虚拟主机
Referer:指明了请求当前资源的原始资源的URL

User-Agent: 用户代理,使用什么工具发出的请求

1、Accept首部:用户标明客户自己更倾向于支持的能力
Accept: 指明服务器能发送的媒体类型
Accept-Charset: 支持使用的字符集
Accept-Encoding: 支持使用的编码方式

Accept-Language: 支持使用语言

2、条件请求首部:
Expect: 告诉服务器能够发送来哪些媒体类型
If-Modified-Since: 是否在指定时间以来修改过此资源
If-None-Match:如果提供的实体标记与当前文档的实体标记不符,就获取此文档
跟安全相关的请求首部:
Authorization: 客户端提交给服务端的认证数据,如帐号和密码

Cookie: 客户端发送给服务器端身份标识


上图展示一般请求所带有的属性

=====================================================================================

二、响应报文

上图分析


HTTP响应报文同样也分为三部分,有状态行、首部行、实体

状态行:HTTP响应报文的第一行

状态行包括三个字段:协议版本、状态码与原因短语。

状态码:

1xx:

这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。

2xx:

这一类型的状态码,代表请求已成功被服务器接收、理解、并接受。

3xx:

这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的Location域中指明。

4xx:

这类的状态码代表客户端类的错误

5xx:

服务器类的错误

常遇到的状态码说明

状态码 状态描述 简要说明
200
OK 客户端请求成功
201
Created 
请求已经被实现,而且有一个新的资源已经依据请求的需要而创建,且其URI已经随Location头信息返回。
301 Moved Permanently 被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一
302 Found
在响应报文中使用首部“Location: URL”指定临时资源位置
304 Not Modified 条件式请求中使用
403
Forbidden 请求被服务器拒绝
404 Not Found 服务器无法找到请求的URL
405 Method Not Allowed 不允许使用此方法请求相应的URL
500
Internal Server Error 服务器内部错误
502 Bad Gateway 代理服务器从上游收到了一条伪响应
503 Service Unavailable 服务器此时无法提供服务,但将来可能可用
505 HTTP Version Not Supported 服务器不支持,或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

响应首部(首部行):位于响应报文状态行之后

Date标头:消息产生的时间

Age标头:(从最初创建开始)响应持续时间

Server标头: 向客户端标明服务器程序名称和版本

ETage标头:不透明验证者

Location标头:URL备用的位置

Content-Length标头:实体的长度

Content-Tyep标头:实体的媒体类型

协商首部:
Accept-Ranges: 对当前资源来讲,服务器所能够接受的范围类型
Vary: 首部列表,服务器会根据列表中的内容挑选出最适合的版本发送给客户端
跟安全相关的响应首部:
Set-Cookie: 服务器端在某客户端第一次请求时发给令牌

WWW-Authentication: 质询,即要求客户提供帐号和密码

响应首部一般包含如下内容:


实体:位于首部行之后

实体包含了Web客户端请求的对象。Content-Length标头及Content-Type标头用于计算实体的位置、数据类型和数据长度。当Web服务器接收到Web客户端的请求报文后,对HTTP请求报文进行解析,并将Web客户端的请求的对象取出打包,通过HTTP响应报文将数据传回给Web客户端,如果出现错误则返回包含对应错误的错误代码和错误原因的HTTP响应报文。

本文出自 “和风细雨” 博客,请务必保留此出处http://essun.blog.51cto.com/721033/1379932

HTTP协议本身并不具备安全性,它是一种明文传输协议,所有数据在传输过程中都是未加密的。这种特性使得HTTP在早期互联网环境中存在诸多安全隐患,例如数据可能被中间人攻击(MITM)窃取或篡改。因此,为了保障数据传输的安全性,HTTPS协议应运而生。 HTTPS(HyperText Transfer Protocol Secure)是在HTTP协议的基础上加入了SSL/TLS协议,通过加密技术保障数据传输的安全性。HTTPS主要从以下几个方面提升安全性: 1. **加密传输**:HTTPS通过SSL/TLS协议对传输的数据进行加密,确保客户端与服务器之间的通信内容不会被第三方窃取。这种加密机制主要采用对称加密和非对称加密相结合的方式[^1]。 - 非对称加密用于建立安全连接时的密钥交换。 - 对称加密用于实际数据的加密传输,以提高效率。 2. **身份验证**:HTTPS通过数字证书验证服务器身份,防止连接到假冒的网站。服务器会提供由可信证书颁发机构(CA)签发的数字证书,客户端在连接时会验证该证书的有效性,确保通信对方的身份真实性[^1]。 3. **数据完整性**:SSL/TLS协议还提供了消息认证码(MAC),用于确保传输的数据在途中未被篡改。如果数据在传输过程中被修改,接收方可以检测到这一变化并拒绝接受该数据。 相比之下,HTTP协议缺乏这些安全机制,其数据传输过程完全暴露在公共网络中。例如,HTTP的请求和响应报文在传输时都是以明文形式发送的,攻击者可以轻易截获并读取其中的内容,甚至修改后再转发给目标服务器或客户端[^1]。 此外,HTTP协议的请求报文和响应报文结构本身并不提供任何安全防护。例如,请求行、请求头、响应行、响应头等部分都以明文形式传输,攻击者可以通过监听网络流量获取敏感信息,如Cookie、会话令牌等,从而实施会话劫持、跨站请求伪造(CSRF)等攻击[^2]。 因此,现代Web应用广泛采用HTTPS来保护用户隐私和数据完整性,尤其是在涉及敏感信息(如登录凭证、支付信息)的场景中,HTTPS已成为标准配置。 ### HTTPS的握手过程 HTTPS的安全机制主要依赖于SSL/TLS握手过程,以下是其基本流程: 1. 客户端向服务器发送“ClientHello”消息,包含支持的SSL/TLS版本、加密套件等信息。 2. 服务器回应“ServerHello”消息,选择客户端支持的加密套件,并发送自己的数字证书。 3. 客户端验证服务器证书的有效性,并生成一个随机的预主密钥(Pre-Master Secret),使用服务器的公钥加密后发送给服务器。 4. 服务器使用私钥解密预主密钥,并与客户端使用相同的算法生成会话密钥(用于对称加密)。 5. 双方交换“Finished”消息,确认握手完成,后续通信将使用会话密钥进行加密。 ### 示例代码:使用Python发起HTTPS请求 以下是一个使用Python的`requests`库发起HTTPS请求的示例: ```python import requests # 发起HTTPS GET请求 response = requests.get('https://example.com') # 输出响应状态码和内容 print(f"Status Code: {response.status_code}") print(f"Response Body: {response.text}") ``` 这段代码展示了如何通过HTTPS协议访问一个安全网站,并获取响应内容。由于使用了HTTPS,整个请求和响应过程都是加密的,确保了数据的安全性。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值