E012Web学习笔记-HTTP请求协议

桃扇骨 2024-04-18 11:15 76阅读 0赞

> 第一次复习时间：2022年3月27日11点05分

# 一、概述 #

## 1、概念 ##

Hyper Text Transfer Protocol **超文本传输协议**；

## 2、传输协议 ##

定义了客户端和服务器端**发送数据的格式**；

## 3、特点 ##

①基于TCP/IP的高级协议；

②默认端口号为：80；

③基于请求/响应模型的**一次请求对应一次响应**；

④无状态的协议：**每次请求之间相互独立**；

## 4、历史版本 ##

0.9版本：1991年，定义了协议最核心的内容，比如，确定了客户端、服务端的这种基本结构，使用域名 /IP 加端口号来确定目标地址的方式，还有换行回车作为基本的分隔符。

它非常简单，不支持请求正文，不支持除了 GET 以外的其它方法，不支持头部，甚至没有版本号的显式指定，而且整个请求只有一行，因而也被称为“The One-line Protocol”。（目前www.google.com支持这个版本！）

1.0版本：1996年，每次请求响应都会建立新的连接，数据传输完毕后会断开；1.0版本如今浏览器广泛支持的最低版本HTTP 协议。引入了返回码，引入了 header，引入了多字符集，也终于支持多行请求了。这是第一个**具备广泛实际应用价值**的协议版本。

1.1版本：1999 年，著名的 RFC2616，在 1.0 的基础上，大量帮助传输效率提升的特性被加入。在 HTTP 1.0 版本时，每一组请求和响应的交互，都要完成一次 TCP 的连接和关闭操作，这在曾经的互联网资源比较贫瘠的时候并没有暴露出多大的问题，但随着互联网的迅速发展，这种通讯模式显然过于低效了。于是这个问题的解决方案——HTTP 的长连接，就自然而然地出现了，它指的是打开一次TCP 连接，可以被连续几次报文传输重用，这样一来，我们就不需要给每次请求和响应都创建专门的连接了。如果协议头中存在 chunked 头，表示将采用分块传输编码，响应的消息将由若干个块分次传输，而不是一次传回。分块传输编码大大地提高了 HTTP 交互的灵活性！

2.0版本：2015年，在保持兼容性的基础上，包含了这样几个重要改进：

设计了一种机制，允许客户端来选择使用的 HTTP 版本，这个机制被命名为 ALPN；

HTTP 头的压缩，在 HTTP/2 以前，HTTP 正文支持多种方式的压缩，但是 HTTP 头部却不能；

多路复用，允许客户端同时在一个连接中同时传输多组请求响应的方法；服务端的 push 机制，比方说客户端去获取一个网页的时候，下载网页，分析网页内容，得知还需要一个 js 文件和一个 css 文件，于是再分别下载，而服务端的 push 机制可以提前就把这些资源推送到客户端，而不需要客户端来索取，从而节约网页加载总时间。

3.0版本：尚未发布，依旧围绕传输效率这个协议核心来做进一步改进，其承载协议将从 TCP 转移到基于 UDP 的 QUIC 上面来。

**HTTP 协议的进化史，恰恰是互联网进化史的一个绝佳缩影！**

# 二、请求消息数据格式 #

## 1、请求行 ##

浏览器告诉服务器一些信息；
    
    格式：
    请求方式 请求url 请求协议/版本
    示例：
    GET /login.html HTTP/1.1
    
    请求方式：
    一共有七种，常用的有两种get和post；
    GET：
    1、请求参数在请求行中，在url后；
    2、请求的url有限制；
    3、不太安全；
    POST：
    1、请求参数在请求体中；
    2、请求的url没有限制；
    3、相对安全；

## 2、请求头 ##

格式：
    请求头名称：请求头的值
    
    常见的请求头：
    1、User-Agent：告诉服务器浏览器的版本信息；
    服务器获取浏览器信息，以解决浏览器的兼容性问题；
    2、Accept：告诉服务器浏览器可以解析的文件信息；
    3、Referer：告诉服务器我（当前请求）从哪里来：
    作用：
    防盗链：盗链就是盗取超链接，A网站超链接指向B网站，就是A盗取B的超链接；
    统计：统计来源；
    4、Connection：连接是否保持存活；

## 3、请求空行 ##

就是空行，做分割作用

## 4、请求体 ##

封装POST请求消息的请求参数，GET没有请求体