【计算机网络12】应用层之HTTP

HTTP（Hyper Text Transfer Protocol），译为超文本传输协议，是互联网中应用最广泛的应用层协议之一。

设计 HTTP 最初的目的是：提供一种发布和接收 HTML 页面的方法，由 URI 来标识具体的资源。

后面用 HTTP 来传递的数据格式不仅仅是 HTML，应用非常广泛。

HTML（Hyper Text Markup Language）：超文本标记语言，用以编写网页。

1.HTTP版本

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

2.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的实现标准。

1996年3月，清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过为RFC 1922，成为中国大陆第一个被认可为RFC文件的提交协议。

3.HTTP报文格式

GET 请求

POST 请求

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（新）

URL的编码

URL中一旦出现了一些特殊字符（比如中文、空格），需要进行编码。

在浏览器地址栏输入URL时，是采用UTF-8进行编码。

比如：

• 编码前：https://www.baidu.com/s?wd=百度
• 编码后：https://www.baidu.com/s?wd=%E5%8D%8E%E4%B8%BA

4.请求方法

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：用于获取目的资源所支持的通信选项，比如服务器支持的请求方法。

PUT：用于对已存在的资源进行整体覆盖。

PATCH：用于对资源进行部分修改（资源不存在，会创建新的资源）。

DELETE：用于删除指定的资源。

TRACE：请求服务器回显其收到的请求信息，主要用于HTTP请求的测试或诊断。

CONNECT：可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道（tunnel）。可以用来访问采用了 SSL (HTTPS) 协议的站点。

5.头部字段（Header Field）

头部字段可以分为 4 种类型：

请求头字段（Request Header Fields）：有关要获取的资源或客户端本身信息的消息头。

响应头字段（Response Header Fields）：有关响应的补充信息，比如服务器本身（名称和版本等）的消息头。

实体头字段（Entity Header Fields）：有关实体主体的更多信息，比如主体长度（Content-Length）或其MIME类型。

通用头字段（General Header Fields）：同时适用于请求和响应消息，但与消息主体无关的消息头。

5.1 请求头字段

5.2 响应头字段

6.状态码（Status Code）

在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：服务器尚未处于可以接受请求的状态，通常造成这种情况的原因是由于服务器停机维护或者已超载。

7.form提交

action：请求的URI

method：请求方法（GET、POST）

enctype：POST请求时，请求体的编码方式

• application/x-www-form-urlencoded（默认值）：用&分隔参数，用=分隔键和值，字符用URL编码方式进行编码。
  

• multipart/form-data：文件上传时必须使用这种编码方式。
  

8.Cookie和Session

Cookie：在客户端（浏览器）存储一些数据，存储到本地磁盘（硬盘），服务器可以返回 Cookie 交给客户端去存储。

Session：在服务器存储一些数据，存储到内存中。

Cookie和Session是一种会话跟踪技术，判断多个请求之间是不是同一个会话。