HTTP
HTTP(Hyper Text Transfer Protocol),译为超文本传输协议- 是互联网中应用最广泛的应用层协议之一
- 设计
HTTP最初的目的是:提供一种发布和接收HTML页面的方法,由URI来标识具体的资源 - 后面用
HTTP来传递的数据格式不仅仅是HTML,应用非常广泛
HTML( Hyper Text Markup Language):超文本标记语言- 用以编写网页
版本
- 1991年,
HTTP/0.9- 只支持
GET请求方法获取文本数据(比如HTML文档),且不支持请求头、响应头等,无法向服务器传递太多信息
- 只支持
- 1996年,
HTTP/1.0- 支持
POST、HEAD等请求方法,支持请求头、响应头等,支持更多种数据类型(不再局限于文本数据) - 浏览器的每次请求都需要与服务器建立一个
TCP连接,请求处理完成后立即断开TCP连接
- 支持
- 1997年,
HTTP/1.1(最经典、使用最广泛的版本)- 支持
PUT、DELETE等请求方法 - 采用持久连接(
Connection: keep-alive),多个请求可以共用同一个TCP连接
- 支持
- 2015年,HTTP/2.0
- 2018年,HTTP/3.0
标准
HTTP的标准- 由万维网协会(
W3C)、互联网工程任务组(IETF)协调制定,最终发布了一系列的RFC
- 由万维网协会(
RFC(Request For Comments,可以译为:请求意见稿) *HTTP/1.1最早是在1997年的RFC 2068中记录的- 该规范在
1999年的RFC 2616中已作废 2014年又由RFC 7230系列的RFC取代HTTP/2标准于2015年5月以RFC 7540正式发表,取代HTTP/1.1成为HTTP的实现标准
- 该规范在
- 中国的
RFC1996年3月,清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过为RFC 1922- 成为中国大陆第一个被认可的
RFC文件的提交协议
报文格式
请求报文
响应报文
ABNF
ABNF(Augmented BNF)- 是
BNF(Backus-Naur Form,译为:巴科斯-瑙尔范式)的修改、增强版 - 在
RFC 5234中表明:ABNF用作internet中通信协议的定义语言 ABNF是最严谨的HTTP报文格式描述形式,脱离ABNF谈论HTTP报文格式,往往都是片面、不严谨的
- 是
- 关于
HTTP报文格式的定义RFC 2616 4.HTTP Message(旧)RFC 7230 3.Message Format(新)
整体格式
规范
requset-line
status-line
header-filed
message-body
URL的编码
URL中一旦出现了一些特殊字符(比如中文、空格),需要进行编码- 在浏览器地址栏输入
URL时,是采用UTF-8进行编码
- 在浏览器地址栏输入
- 比如
- 编码前:
https://www.baidu.com/s?wd=百度 - 编码后:
https://www.baidu.com/s?wd=%E5%8D%8E%E4%B8%BA
- 编码前:
请求方法
RFC 7231, section 4: Request methods:描述了8种请求方法GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE
RFC 5789, section 2:Patch method:描述了PATCH方法GET:常用于读取的操作,请求参数直接拼接在URL的后面(浏览器对URL是有长度限制的)POST:常用于添加、修改、删除的操作,请求参数可以放到请求体中(没有大小限制)HEAD:请求得到与GET请求相同的响应,但没有响应体- 使用场景举例:在下载一个大文件前,先获取其大小,再决定是否要下载。以此可以节约带宽资源
OPTIONS:用于获取目的资源所支持的通信选项,比如服务器支持的请求方法OPTIONS * HTTP/1.1
PUT:用于对已存在的资源进行整体覆盖PATCH:用于对资源进行部分修改(资源不存在,会创建新的资源)DELETE:用于删除指定的资源TRACE:请求服务器回显其收到的请求信息,主要用于HTTP请求的测试或诊断CONNECT:可以开启一个客户端与所请求资源之间的双向沟通的通道,它可以用来创建隧道(tunnel) * 可以用来访问采用了SSL (HTTPS)协议的站点
头部字段
- 头部字段可以分为
4种类型- 请求头字段
(Request Header Fields)- 有关要获取的资源或客户端本身信息的消息头
- 响应头字段
(Response Header Fields)- 有关响应的补充信息,比如服务器本身(名称和版本等)的消息头
- 实体头字段
(Entity Header Fields)- 有关实体主体的更多信息,比如主体长度
(Content-Length)或其MIME类型
- 有关实体主体的更多信息,比如主体长度
- 通用头字段
(General Header Fields)- 同时适用于请求和响应消息,但与消息主体无关的消息头
- 请求头字段
请求头字段
响应头字段
同源策略
跨域资源共享
session & cookie
- Cookie
- 在客户端存储一些数据
- 服务器可以返回
Cookie交给客户端去存储 - Cookie中存在
domain、path字段记录路径,用于判断哪些路径下使用Cookie
- Session
- 在服务器存储一些数据
- 登录成功
- 登录失败
- 在服务器存储一些数据
状态码
- 在
RFC 2616 10.Status Code Definitions规范中定义- 状态码指示
HTTP请求是否已成功完成
- 状态码指示
- 状态码可以分为
5类- 信息响应:
100~199 - 成功响应:
200~299 - 重定向:
300~399 - 客户端错误:
400~499 - 服务器错误:
500~599
- 信息响应:
常见状态码
100 Continue- 请求的初始部分已经被服务器收到,并且没有被服务器拒绝。客户端应该继续发送剩余的请求,如果请求已经完成,就忽略这个响应
- 允许客户端发送带请求体的请求前,判断服务器是否愿意接收请求(服务器通过请求头判断)
- 在某些情况下,如果服务器在不看请求体就拒绝请求时,客户端就发送请求体是不恰当的或低效的
200 OK:请求成功302 Found:请求的资源被暂时的移动到了由Location头部指定的URL上304 Not Modified:说明无需再次传输请求的内容,也就是说可以使用缓存的内容400 Bad Request:由于语法无效,服务器无法理解该请求401 Unauthorized:由于缺乏目标资源要求的身份验证凭证403 Forbidden:服务器端有能力处理该请求,但是拒绝授权访问404 Not Found:服务器端无法找到所请求的资源405 Method Not Allowed:服务器禁止了使用当前HTTP方法的请求406 Not Acceptable:服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应408 Request Timeout:服务器想要将没有在使用的连接关闭- 一些服务器会在空闲连接上发送此信息,即便是在客户端没有发送任何请求的情况下
500 Internal Server Error:所请求的服务器遇到意外的情况并阻止其执行请求501 Not Implemented:请求的方法不被服务器支持,因此无法被处理- 服务器必须支持的方法(即不会返回这个状态码的方法)只有
GET和HEAD
- 服务器必须支持的方法(即不会返回这个状态码的方法)只有
502 Bad Gateway:作为网关或代理角色的服务器,从上游服务器(如tomcat)中接收到的响应是无效的503 Service Unavailable:服务器尚未处于可以接受请求的状态- 通常造成这种情况的原因是由于服务器停机维护或者已超载
form提交
常用属性
action:请求的URImethod:请求方法(GET、POST)enctype:POST请求时,请求体的编码方式application/x-www-form-urlencoded(默认值)- 用
&分隔参数,用=分隔键和值,字符用URL编码方式进行编码
- 用
multipart/form-data- 文件上传时必须使用这种编码方式
multipart/form-data