HTTP协议

Palate

已于 2022-10-16 16:51:15 修改

阅读量1.5k

点赞数 1

分类专栏：网络基础文章标签： http 网络

于 2022-10-16 16:01:09 首次发布

本文链接：https://blog.csdn.net/weixin_51670675/article/details/127348869

版权

网络基础专栏收录该内容

6 篇文章 1 订阅

订阅专栏

一、什么是http协议

1. 概念

HTTP 应用层协议，它定义了客户端和服务器之间（对象）交换报文的格式和方式（作用）。
HTTP是超文本传输协议，所谓超文本，就是超越了普通文本的文本，它是文字、图片、视频等的混合体，最关键有超链接，能从一个超文本跳转到另外一个超文本。
HTML 就是最常见的超文本。它本身只是纯文字文件，但内部用很多标签定义了图片、视频等的链接，再经过浏览器的解释，呈现给我们的就是一个文字、有画面的网页了。
HTTP协议广泛应用于TCP/IP协议之上，但并非必须使用TCP/IP协议。

2. 优缺点（http1.0）

优点

使用简单：客户向服务器请求服务时，只需传送请求方法和路径。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
无连接：无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。（http1.1 之后默认长连接）
数据类型灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。

缺点

明文传输：协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。
不验证身份：不验证通信方的身份，因此有可能遭遇伪装；
无状态：每次请求都是相互独立的，不会对请求或响应做持久化处理。

（针对业务需要，可引入了Cookie（HTTP 1.1）和Session技术，用于管理状态。）

3. HTTP请求组成

HTTP 请求由三部分构成，分别为：请求行、请求头和请求体。

请求行

请求行大概长这样 GET /images/logo.gif HTTP/1.1 基本由请求方法、URL、协议版本组成
请求方法分为很多种，最常用的也就是 Get 和 Post 了。虽然请求方法有很多，但是更多的是传达一个语义，而不是说 Post 能做的事情 Get 就不能做了。

URL

协议版本://服务器IP:[端口]/路径/[？查询]

超文本传输协议（HTTP）的统一资源定位符地址构成：

传送协议。
层级URL标记符号(为[//],固定不变)
访问资源需要的凭证信息（可省略）
服务器。（通常为域名，或IP地址）
端口号。（以数字方式表示，若为HTTP的默认值“:80”可省略）
路径。（以“/”字符区别路径中的每一个目录名称）
查询。（GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题）

请求头

首部分为请求头部和响应头部，并且部分头部两种通用

二、http请求方法

1. 四个常用

get：获取数据

post：提交数据

put：更新数据

deleted：删除数据

2. 四个不常用

head：获取报文首部，与get相比，不返回报文主体部分。

options：预检请求，询问支持的请求方式。

connect：要求在与代理服务器通信时建立隧道，使用隧道进行TCP通信

trace：回显服务器收到的请求，主要用于测试或诊断。

3. options请求

作用

获取某个请求在对应的服务器中都支持哪种请求方法

使用场景

在跨域的情况下，在浏览器发起"复杂请求"时主动发起的。
跨域共享标准规范要求，那些可能对服务器数据产生副作用的 HTTP 请求方法，浏览器必须首先使用 OPTIONS 方法发起一个预检请求，从而获知服务端是否允许该跨域请求。
服务器确认允许之后，才发起实际的 HTTP 请求。

4. get和post的区别

对服务端资源的影响

对服务器资源的影响，get不影响，post可能影响
GET 请求是一个幂等的请求，一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。

是否缓存

浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。

地址栏限制

浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度和类型。

三、常见状态码

状态码		状态码		状态码
200	成功
301	永久重定向	302	临时重定向	304	使用缓存
403	没有权限	404	资源未找到
500	服务端错误	503	超负荷或停机维护	504	网关超时

四、请求头和响应头

常见的请求头：

Accept:浏览器能够处理的内容类型
Accept-Charset:浏览器能够显示的字符集
Accept-Encoding：浏览器能够处理的压缩编码
Accept-Language：浏览器当前设置的语言
Connection：浏览器与服务器之间连接的类型
Cookie：当前页面设置的任何Cookie
Host：发出请求的页面所在的域
Referer：发出请求的页面的URL
User-Agent：浏览器的用户代理字符串

常见的响应头：

Date：表示消息发送的时间，时间的描述格式由rfc822定义
server:服务器名称
Connection：浏览器与服务器之间连接的类型
Cache-Control：控制HTTP缓存
content-type:表示后面的文档属于什么MIME类型

常见的 Content-Type 属性值有以下四种：

（1）application/x-www-form-urlencoded：浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。该种方式提交的数据放在 body 里面，数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL转码。

（2）multipart/form-data：该种方式也是一个常见的 POST 提交方式，通常表单上传文件时使用该种方式。

（3）application/json：服务器消息主体是序列化后的 JSON 字符串。

（4）text/xml：该种方式主要用来提交 XML 格式的数据。

五、HTTPS是如何保证安全的？（TLS）

HTTPS 还是通过了 HTTP 来传输信息，但是信息通过 TLS 协议进行了加密。
在 TLS 中使用了两种加密技术，分别为：对称加密和非对称加密。
HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。

1. 基本思路

TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

3. 对称加密

对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。
这种加密方式固然很好，但是问题就在于如何让双方知道秘钥。因为传输数据都是走的网络，如果将秘钥通过网络的方式传递的话，一旦秘钥被截获就没有加密的意义的。

4. 非对称加密

有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。
这种加密方式计算量大，但是可以完美解决对称加密存在的问题。假设现在两端需要使用对称加密，那么在这之前，可以先使用非对称加密交换秘钥。

5. 解决身份问题

证明身份——数字证书

如果此时在客户端和服务器之间存在⼀个中间⼈,这个中间⼈只需要把原本双⽅通信互发的公钥,换成⾃⼰的公钥,这样中间⼈就可以轻松解密通信双⽅所发送的所有数据。
将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

（证书中包括：签发者、证书⽤途、使⽤者公钥、使⽤者私钥、使⽤者的HASH算法、证书到期时间等。）

篡改证书——数字签名

如果中间⼈篡改了证书，那么身份证明是不是就⽆效了？这个证明就⽩买了，这个时候需要⼀个新的技术，数字签名。
数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要，再⽤CA的私钥加密，最终组成数字签名。当别⼈把他的证书发过来的时候,我再⽤同样的Hash算法,再次⽣成消息摘要，然后⽤CA的公钥对数字签名解密,得到CA创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。

6. 握手过程

如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。

第一次

首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。

第二次

服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。

第三次

客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。

第四次

服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。

完成

这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。

重要：三个随机数（密钥）、公钥、数字证书

7. 应用场景

https不止在登录页面使用，登录页使用https可以保护用户密码
cookie 是在HTTPS环境下建立的，但是却在HTTP环境下传输。如果有人劫持到这些cookie，那他就能以你的身份在Twitter上发言了。

六、HTTP1.1与HTTP1.0的区别

HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。

1. 长连接

HTTP1.1增加Connection字段，对于同一个host，通过设置Keep-Alive保持HTTP连接不断。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。

2. 管道传输

多个请求可以同时发送，但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。

3. 断点续传

**从下载断开的位置，继续下载。**通过使用请求头中的 Range 来实现。

七、HTTP 1.1 和 HTTP 2.0 的区别

（多路复用，二进制协议和数据流概念服务于多路复用）

1. 多路复用

HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 连接。
但是在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。

2. 二进制协议

在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。
HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧和数据帧。
帧的概念是它实现多路复用的基础。

3. 数据流

（数据流，属于同个请求；数据包，一个请求有多个数据包）

HTTP/2 使用了数据流的概念，因为 HTTP/2 的数据包是不按顺序发送的。一个请求有多个数据包，一次TCP连接有多个请求，这些数据包没有按顺序发送。
同一个连接里面连续的数据包，可能属于不同的请求。因此，必须要对数据包做标记，指出它属于哪个请求。
HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送时，都必须标记数据流 ID ，用来区分它属于哪个数据流。

4. 头信息压缩

由于 HTTP 1.1 协议不带状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent ，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。
HTTP/2 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。