计算机网络应用层HTTP协议相关知识点总结

chenz1hao

已于 2022-07-12 00:43:41 修改

阅读量987

点赞数

文章标签：网络 http 网络协议网络安全

于 2022-07-10 17:09:29 首次发布

本文链接：https://blog.csdn.net/qq_29941979/article/details/125704468

版权

1、什么是HTTP协议？

HTTP协议（超文本传输协议），首先协议代表着至少有两个及以上的参与者，是对参与者的行为约定和规范，超文本包括了传输文字、图像、音频、视频等一些超文本信息，传输说明了HTTP是双向的协议；一句话来说，HTTP是在计算机世界中专门在两点之间传输文字、图像、音频、视频等超文本信息的约定和规范集合。

2、HTTP状态码

HTTP状态码是一定要熟悉的，

1XX 提示信息，表示目前是协议处理的中间状态，还需要后续操作；

2XX 成功，报文已经收到并被正确处理；具体地，200成功且有Body数据，204成功但是没有响应体，206 HTTP分块下载或者叫断点续传；

3XX 重定向，资源位置发生变动，需要客户端重新发送请求；301 永久重定向，302 临时重定向，304表示资源未修改用于缓存控制服务端返回不含有包体的304时即为告诉客户端缓存依然有效就可以减少响应数据体资源在网络中传输；

4XX 客户端错误，请求报文有误，服务端无法处理，400 请求的报文有错，401 客户端身份未授权，403 服务器禁止访问的资源， 404 请求的资源在服务端未找到；

5XX 服务端错误，服务器在处理请求时内部发生了错误，500 笼统的错误码，501 客户端请求的功能不支持，502 BadGateway 服务器工作正常但访问后端服务发生错误，503 服务器很忙过载了。

状态码	含义	含义
100	继续	初始的请求已经接受，请客户端继续发送剩余部分
101	切换协议	请求服务器切换协议，服务器确定切换
200	成功	服务器成功处理了请求，有响应体
204	无内容	成功但是没有响应体
206	部分内容	服务器成功处理了部分GET请求
301	永久移动	永久重定向跳转到新的URL
302	临时移动	服务器目前从不同位置的网页响应请求，但请求仍继续使用原有位置来进行以后的请求
304	未修改	自从上次请求后，请求的网络未修改，告诉客户端其缓存依然有效
400	错误请求	服务器不理解请求的语法
401	未授权	请求进行用户的身份验证
403	禁止	服务器拒绝请求
404	未找到	请求的资源在服务端未找到
500	服务器错误	服务器内部错误，无法完成请求
501	未实现	请求的服务端功能还尚不支持，未实现
502	错误网关	服务器作为网关或者代理出现错误
503	服务不可用	一般因为过载原因，服务器暂不可用

3、HTTP请求头常见字段

字段	含义
Host	指定服务器的地址
Content-Length	服务器在返回数据时表明本次回应的数据长度
Connection	是否要求使用TCP长连接，以便其他请求复用，HTTP1.1默认都是长连接，但是为了兼容老版本的HTTP，需要指定Connection字段为Keep-Alive
Content-Type	告诉客户端本次数据的格式是什么，比如:text/html; charset:utf-8
Content-Encoding	数据的压缩方式，表示服务器返回的数据使用了什么压缩格式

4、GET和POST

最常见的问题就是GET和POST的区别，

GET方法一般用于请求服务器的资源，可以是静态文本、页面、图片、视频等；

GET请求不会破坏服务器上的资源，因此具有幂等性，多次执行GET请求，结果都是相同的；

同时由于GET请求的参数明文包含在URL中，而一些用户代理浏览器对URL有长度限制，因此GET请求的参数是有长度限制的，而POST请求的信息在HTTP请求体中，不存在长度的限制，而且安全性相对于GET来说也要好很多（但是POST的请求体如果要抓取还是能看到的，所以说只是相对GET安全性好些）

5、HTTP协议不同版本的区别？演变？

HTTP协议经历了0.9、1.0、1.1、2到现在推广的3，下面分别来介绍各版本的演变：

HTTP/0.9：HTTP最早诞生于1991年，极其简单，没有HTTP头、状态码、版本号，后来才被定为0.9版本，和其他版本作区分，只支持GET请求方法，TCP建立连接之后服务器向客户端返回HTML格式的字符串，发送完毕后关闭TCP连接。

HTTP/1.0：1996年，HTTP/1.0发布，丰富了HTTP的传输内容，HTTP报文从此包括了请求行、请求头和请求体；增加了状态码、添加了POST、HEAD等方法，支持传输HTML文件以外的其他内容。

HTTP/1.1：HTTP/1.1在1.0之后几个月发布，在HTTP/1.0中一个请求基于一个TCP连接，请求结束TCP连接关闭，然而TCP连接需要经历三次握手，因此效率很低，在HTTP/1.1中采用了长连接机制，即多个HTTP请求复用一个TCP连接，同时提出了管道化技术（pipeline），即在发送报文的时候，不等第一个报文的响应到达就发送第二个、第三个，但是响应是必须按照顺序来响应的，因此有队头阻塞现象，即如果第一个报文的响应需要处理很久的话，也会影响到第二个报文的响应效率；目前HTTP/1.1也是常用的。

HTTP/2：

a. 用Stream解决HTTP队头阻塞，但是因为基于TCP依然存在队头阻塞：针对HTTP/1.1的队头阻塞问题，HTTP/2中提出了Stream流的概念，Stream可以认为就是一条HTTP请求，Stream ID唯一标识一个流，客户端发出的用奇数表示服务端发出的用偶数表示。不同流之间的发送顺序可以不同（一个Stream中的发送顺序必须严格有序），解决了HTTP层的队头阻塞，但是因为HTTP/2仍然基于TCP，TCP是可靠的协议，它需要保证其向上交付的报文是无差错、不丢失、不重复、不乱序的，因此如果一个Stream中的报文丢失或者延迟了，TCP也不会把报文上交给应用层的HTTP，对于HTTP的角度来看也是发生了队头阻塞，不过这个队头阻塞是TCP队头阻塞不是HTTP队头阻塞了，要区分；

b. 压缩头部算法HPACK：HTTP的头部字段大量的字段都是重复的，在之前的版本中不会对其压缩，在HTTP/2中采用了HPACK算法对头部字段进行了压缩，HPACK主要包括了静态表、动态表和哈夫曼编码，静态表存放61个常用的头部字段，动态表是动态编码发送的头部字段，在报文交换过程中，就按照两张表直接发送对应的编码而不用发送原字段值。

c.二进制格式报文：之前的版本中HTTP报文的格式都是基于ascii编码的，对用户阅读来说是友好的，但是对计算机识别来说需要经过一个编解码的过程效率较低，因此在HTTP/2中以二进制的格式来组织HTTP报文。

d. 服务器主动推送：之前只能由客户端主动向服务端发起请求，服务端被动响应请求，但是有时候如果客户端请求了一个HTML页面，里面包含一些图片URL、音频URL或者其他的链接，那么这时候服务端可以主动将其他的信息推送给客户端，不用等客户端请求，提高了效率。

e. 基于HTTPS：之前的HTTP协议都是明文传输的，存在偷听、篡改、冒充伪装的安全问题，HTTP/2是基于HTTPs的，也就是在传输层TCP和应用层HTTP之间加入了TLS/SSL层（默认TLS1.2版本），先以非对称加密的方式协商会话秘钥，通信过程中使用会话秘钥以对称加密的方式进行加密的报文交换，同时引入了CA机构来保障客户端不会被攻击者冒充伪装，引入摘要算法来保证发送数据和接收数据是完全相同的没有被篡改。

HTTP/3：

HTTP/3协议是谷歌最近在推的，覆盖率还很低，但是也是以后的方向值得了解；

a. 传输层基于UDP协议：由于之前的HTTP协议基于TCP协议，TCP协议因为其需要保障可靠，即HTTP报文不出错、不丢失、不乱序、不重复，因此直接采用UDP作为传输层协议，抛弃TCP的包袱，同时在应用层实现了QUIC协议去保证报文的可靠传输。

b. 彻底解决队头阻塞问题：在HTTP/2中我们知道虽然有Stream的概念，但是基于TCP协议，TCP需要保障数据完整后才向上交付，因此在HTTP的角度而言依然存在队头阻塞，那么在HTTP/3中基于UDP，所以所有的用户数据报只要收到了都会交付给应用层的QUIC协议，QUIC是有序号来唯一标识数据包的，通过QUIC协议来保障可靠性，选择是否交付给HTTP，一个QUIC包丢失了只会影响这一个包（也就是一个Stream），这样一个Stream中发生了丢包，只会影响该流，不会影响其他Stream的传输，真正解决了队头阻塞问题。

c. 新头部压缩算法QPACK：HTTP/2中的头部压缩算法存在问题，即客户端第一次发送给服务端的HTTP报文，如果这个字段不在静态表中，会在双方建立动态表，之后双方会用编码后的数值来压缩头部，但是关键问题在于如果这个请求丢失了，那么这时候客户端方建立了动态表，但是服务端方因为没有接受到HTTP报文尚未建立表，那么在之后的请求中，如果客户端用压缩后的头部来请求服务端，服务端就会不认识这个压缩后的头部，就会等待前面那个HTTP报文到了后建立起来动态表后才会识别，这也就引起了队头阻塞；在新的QPACK算法中，有两个特殊的单向流，一个叫QPACK Encoder Stream将一个字典传递给对方，比如面对不属于静态表的头部，通过这个Stream来发送字典告诉对方；一个叫QPACK Decoder Stream，用于响应对方，告诉发送方刚发的字典已经更新到他本地的动态表了，后序就可以用这个压缩后的头部来通信了。白话来说就是，发送方发出建立的动态表新字段后，需要收到接收方的确认，之后才用这个进行编码。

d.TLS版本升级（1.2 -> 1.3）更快建立连接：在HTTP/2中，因为TLS和TCP分属于两个独立的模块，因此在建立连接时需要先经过TCP三次握手，在经过TLS四次握手，也就是3个往返时延RTT后才可以开始通信，在HTTP/3中，依然是基于HTTPS，而且TLS版本从1.2升级到了1.3，并且QUIC和TLS1.3并不是分层的，只需要1个RTT就可以同时完成连接建立和会话秘钥的协商，甚至在第二次连接的时候，应用数据包可以和QUIC握手信息（连接信息+TLS信息）一起发送，达到0个RTT的效果。

e. 连接迁移：在之前的HTTP版本中，采用四元组（源IP、源端口、目的IP、目的端口）来标识一个会话，那么在网络环境变化后，比如：从WIFI网络切换到移动网络时，源IP源端口可能就会发生变化，四元组相应也会变化，这样就需要重新建立连接（TCP握手SSL握手），给用户带来一种卡顿的体验；在HTTP/3中不采用四元组来标识一次会话，而是通过连接ID来标记通信的两个端点，客户端和服务端可以各自选择一组ID来标记自己，即使网络环境发生了变化导致IP地址变化，只要仍保有上下文信息（连接ID、TLS密钥），就可以无缝地还原链接，没有卡顿的感觉，达到了连接迁移的效果。

6、HTTPS相关

HTTP协议具有“窃听、篡改、冒充伪装”三大安全缺陷，于是推出了HTTPS，所谓HTTPS就是HTTP+SSL/TLS，SSL和TLS其实是一个东西，只是在早期叫SSL，现在都叫TLS了，因此都叫SSL/TLS。他是在HTTP和传输层之间新增了一个类似安全层的SSL/TLS，在HTTP报文传输过程中，先TCP三次握手后，然后TLS四次握手协商会话秘钥，之后用协商的会话秘钥加密数据进行通信，要知道的是TLS并不是只有HTTP可以用的，其他的应用层协议比如TELNET要想实现安全会话都可以基于TLS去实现，因此可以说TLS是一个用户态的协议实体。

HTTPS涉及非对称加密和对称加密，所谓对称加密就是加密和解密都是使用的同一个密钥，而非对称加密中加密和解密采用的是不同的密钥，比如用公钥加密，那就只能用私钥解密，换句话说传输过程中的报文就算被拦截了，但是只要保证拦截人没有私钥那他就没有办法破解，公钥是解不开的。

HTTPS，在最开始是非对称加密，因为需要保障会话秘钥安全地同步给双方，如果使用对称加密来传递会话秘钥这个过程就会被窃听，所以在会话最开始先采用非对称加密来协商会话秘钥（四次握手），但是非对称加密非常耗费算力和资源，所以之后就用协商的密钥进行对称加解密了，节约资源。

下面这张图是b站一个视频中的截图，图中展示的是TLS四次握手的过程：

1、首先由客户端发起Client Hello，发送客户端生成的第1随机数、TLS版本与支持的加密套件，申请与服务端进行加密通信；

2、服务端响应Server Hello，发送服务端生成的第2随机数、CA数字证书（包括哈希后的认证信息和数字签名）、确认TLS版本、选择加密套件；

3、客户端拿到服务端给的数字证书后（这个证书包括了实体部分和数字签名部分，数字签名部分是由实体信息经过Hash+CA私钥加密后得到的，如下图所示），会进行验证，如何验证？通常浏览器和操作系统中一般都会有CA的公钥，用CA公钥就可以对数字签名进行解密，得到Hash Value1，再将实体部分同样经过Hash算法得到Hash Value2，那么比较Hash Value1和2，如果相同则可以认为对方身份正常；

认为服务端可信之后，客户端会再次生成一个新的随机数，叫做预主密钥（pre-master），用服务端的公钥加密随机数，发送给服务端。服务端收到以后用自己的私钥解开就得到了预主密钥。

至此，双方都有三个随机数，用这三个随机数来生成最终的会话秘钥，这个会话秘钥就是之后用于对称加密会话时所用的密钥。

然后客户端再发送Encrypted Handshake Message，把之前发送的消息再用会话秘钥加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否被中途篡改过。