「计算机网络」前端必备知识,看到就是赚到系列(下)

3,037 阅读12分钟

计算机网络之应用层-HTTP、HTPS、DNS-下篇

⭐️⭐️这篇文章是一个我计算机网络复习的大汇总,由于内容太多了我把它分成了上下两篇来写,上一篇将传输层协议TCP、UDP,这一篇讲的是应用层协议HTTP、HTPS、DNS~~

在这里插入图片描述

HTTP协议

HTTP 是一个在客户端和服务器之间传输文字、图片、音频、视频等超文本数据的约定和规范。默认使用 80 端口,它使用 TCP 作为传 输层协议,保证了数据传输的可靠性。

HTTP的特点?它有什么缺点?

特点: 端对端, 灵活可拓展,可靠, 无状态, 持久连接

  • HTTP协议是一种端对端的协议,也是一种请求/响应模式的协议。

  • 灵活可扩展:一个是语义上的自由,只规定了基本格式,其它的各部分没有严格的限制;第二个它允许传输任意类型的数据对象,例如文本、图片、音频等,传输的类型由Content-Type加以标记。

  • 可靠传输,HTTP 基于 TCP/IP,因此把这一特性继承了下来。

  • 无状态,也就是说HTTP请求不具备保存之前发送过的请求或响应的功能,每一次请求都是独立无关的。

  • 持久连接,HTTP1.1 以后默认采用的是持续的连接,持续连接下,TCP 连接默认不关闭,可以被多个请求复用,目前对于同一个域,大多数浏览器支持 同时建立 6 个持久连接。

    缺点:可能被窃听,篡改,遭遇伪装,无状态,队头阻塞

  • 明文传输(不加密),内容可能被窃听。

  • 无法验证报文的完整性,内容可能被篡改。

  • 不验证通信方的身份,有可能遭遇伪装。

  • 无状态,它是缺点也是优点吧,分不同的场景。

  • 队头阻塞。HTTP2多路复用解决问题

    • HTTP/2 实现了多路复用,在一个连接里,客户端和服务器都可以同时发送多个请求或回 应,而且不用按照顺序一一发送,这样就避免了"队头堵塞"的问题。
    • 根源源于二进制分针:报文格式如今被拆分成了一个个二进制的帧,用Headers帧存放头部字段,Data帧存放请求体数据。分帧之后,服务器看到的不再是一个个完整的 HTTP 请求报文,而是一堆乱序的二进制帧。这些二进制帧不存在先后关系,因此也就不会排队等待,也就没有了 HTTP 的队头阻塞问题。乱序的二进制帧到达后对方会将 Stream ID 相同的二进制帧组装成完整的请求报文响应报文

HTTP请求报文

HTTP 请求报文(响应报文)的第一行叫做请求行(响应行),后面跟的首部字段,首部后还可以跟一个实体主体。请求首部之后有一个空行,这个空行不能省略,它用来划分首部与实体。

请求行字段:方法字段、URL 字段和 HTTP 版本字段。

方法字段

一般有 GET、POST、HEAD、PUT 和 DELETE GET:获取资源,幂等操作 HEAD:获取报文首部,和GET很像但是不返回报文主体,幂等操作 POST: 创建或更新资源,非幂等操作 PUT: 创建或更新资源本身,幂等操作 PATCH:对资源进行局部更新,非幂等操作 DELETE:删除资源,和PUT功能相反,幂等操作 OPTIONS:查询服务器端支持的HTTP方法种类 CONNECT:建立连接隧道,用于代理服务器,幂等操作 TRACE:追踪请求,查询发出去的请求是怎样被加工/篡改的,幂等操作。容易引发XST跨站追踪攻击。

Post 和 Get 的区别?

(1)从应用场景上来说,GET 请求是一个幂等的请求,一般 Get 请求用于对服务器资源不会产生影响的场景,比如说请求一个网页。而 Post 不是一个幂等的请求,一般用于对服务器资源会产生影响的情景。比如注册用户这一类的操作。

(2)从缓存的角度,浏览器一般会对 Get 请求缓存,但很少对 Post 请求缓存。

(3)从发送的报文格式来说,Get 请求的报文中实体部分为空,Post 请求的报文中实体部分一般为向服务器发送的数据。

(4)从参数的角度上说,GET一般放在URL上传递参数,POST放在请求体里,更适合传递敏感信息。(还有就是 post 的参数传递支持更多的数据类型。GET 只能进行 URL 编码)

HTTP响应报文

响应行字段:版本号、状态码和原因短语

状态码

1xx: 表示目前是协议处理的中间状态,还需要后续操作。101 Switching Protocols

2xx: 表示成功状态。200 OK 204 No Content 206 Partial Content

3xx: 重定向状态,资源位置发生变动,需要重新请求。301 Moved Permanently 302 Found 303 See Other 304 Not Modefied 307 Temprary Redirect

302是http1.0的协议状态码,在http1.1版本的时候为了细化302状态码又出来了两个303和307。303明确表示客户端应当采用get方法获取资源,他会把POST请求变为GET请求进行重定向。307会遵照浏览器标准,不会从post变为get。

4xx: 请求报文有误。400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found

5xx: 服务器端发生错误。500 Internal Server Error 501 Not Implemented 502 Bad GateWay 503 Service Unavailable

HTTP的部首

HTTP的部首挺多的,都记下来没必要,我只挑了比较重点的列出来:

通用首部字段(General Header Fields):请求报文和响应报文两方都会使用的首部

  • Cache-Control  控制缓存
  • Connection 连接管理、逐条首部
  • Transfor-Encoding 报文主体的传输编码格式

请求首部字段(Reauest Header Fields):客户端向服务器发送请求的报文时使用的首部

  • Accept 客户端或者代理能够处理的媒体类型
  • If-Match 比较实体标记(ETage)
  • If-None-Match 比较实体标记(ETage)与 If-Match相反
  • If-Modified-Since 比较资源更新时间(Last-Modified)
  • If-Unmodified-Since比较资源更新时间(Last-Modified),与 If-Modified-Since相反
  • If-Rnages 资源未更新时发送实体byte的范围请求
  • Range 实体的字节范围请求
  • Authorization web的认证信息
  • Host 请求资源所在服务器
  • User-Agent 客户端程序信息

响应首部字段(Response Header Fields):从服务器向客户端响应时使用的字段

  • Accept-Ranges 能接受的字节范围
  • Location 令客户端重定向的URI
  • ETag 能够表示资源唯一资源的字符串
  • Server 服务器的信息

实体首部字段(Entiy Header Fields):针对请求报文和响应报文的实体部分使用首部

  • Allow 资源可支持http请求的方法
  • Last-Modified 资源最后的修改资源
  • Expires 实体主体的过期资源

HTTP/2协议

HTTP/2的新特性:二进制协议、 多路复用、数据流、 头信息压缩、服务器推送

二进制协议 HTTP/2 则是一个彻底的二进制协议,头信息和数据体都是二进制,并且统称为"帧",可以分为头信息帧和数据帧。 帧的概念是它实现多路复用的基础。

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

数据流 HTTP/2 将每个请求或回应的所有数据包,称为一个数据流。每 个数据流都有一个独一无二的编号。数据包发送的时候,都必须标记数据流 ID ,用来区分它属于哪个数据流。

头信息压缩 HTTP/2 实现了头信息压缩,由于 HTTP 1.1 协议不带有状态,每次请求都必须附上所有信息。所以,请求的很多字段都是 重复的,比如 Cookie 和 User Agent ,一模一样的内容,每次请求都必须附带,这会浪费很多带宽,也影响速度。HTTP/2 对这一点做了优化,引入了头信息压缩机制。

服务器推送 HTTP/2 允许服务器未经请求,主动向客户端发送资源,这叫做服务器推送。

HTTPS协议

其实也就是弥补了HTTP的缺点: 数据隐私性,内容经过加密;(加解密) 数据完整性,内容经过完整性校验;(数字签名) 身份认证,第三方无法伪装客户端/服务器的身份(数字证书)

HTTP与HTTPS的区别

HTTPS标准端口443,HTTP是80 HTTPS在浏览器上会显示绿色的安全锁,而HTTP没有 弥补了HTTP的缺点,数据的隐私性、完整性、身份验证。也就是更加安全。

混合加密机制(HTTPS采用的方式)

结合两种加密方式的优点,在交换密钥环节使用非对称加密方式,之后的建立通信交换报文阶段使用对称加密方式。

流程:发送密文的一方使用"对方的公钥"进行加密处理"对称的密钥",然后对方接收到之后使用自己的私钥进行解密得到"对称的密钥",这就达到了确保交换的密钥是安全的前提下使用对称加密方式进行通信。

数字签名、数字证书流程(两张图搞定)

在这里插入图片描述

在这里插入图片描述

主流TLS1.2版本的握手,即ECDHE握手过程?

  A:client_random、TSL版本号、加密套件列表->B
  B:确认版本号后,server_random、server_params、需使用的加密套件、以及自己的证书->A
  A:证书验证,成功则client_params ->B
  A:与此同时,计算出一个pre_random,ECDHE(client_params, server_params) = per_random
  A:将得到的三个随机数通过一个伪随机函数计算得出最终的secret,后续通信所要用的对称密钥,并发送收尾信息给B
  B:服务器也会使用和客户端一样的方式生成secret,并且也会发送一个收尾消息给客户端。
  AB:都收到收尾消息并验证成功后,握手就结束了。后面开始用这个secret对称密钥加密报文进行传输。、

详细过程:

  1. 客户端在第一次发送HTTPS请求的时候,会把 client_random、TSL版本号、加密套件列表发送给服务器

  2. 服务器在接收到之后确认TSL的版本号,同时发送 server_random、server_params、需要使用的加密套件、以及自己的证书给客户端

  3. 客户端在收到这些信息之后,首先是会对服务器的证书进行验证(也就是题目7),若是验证成功则会传递一个 client_params 给服务器

  4. 与此同时客户端会通过ECDHE算法计算出一个pre_random,其中是传入了两个参数,一个是 client_params,还一个是 server_params。(也就是说:ECDHE(client_params, server_params) = per_random)

  5. 这时候客户端就同时拥有了 client_random、server_random、pre_random,它会将这三个参数通过一个伪随机函数计算得出最终的secret,这个secret就是它们后续通信所要用的对称密钥。

  6. 而在客户端生成完secret之后,会给服务器发送一个收尾消息,告诉服务器之后都要用对称加密,且对称加密的算法是用第一次约定好的。

  7. 服务器它在接收到刚刚传递过来的client_params之后,也会使用和客户端一样的方式生成secret,并且也会发送一个收尾消息给客户端。

  8. 当双方都收到收尾消息并验证成功之后,握手就结束了。后面开始用这个secret对称密钥加密报文进行传输。

描述RSA握手

  1. 客户端首先向服务端发送一个HTTPS请求

  2. 服务端会把事先配置好的公钥证书随着其它的信息返回给客户端

  3. 客户端在收到服务端发来的证书之后进行验证,验证的过程参考数字证书验证,会得到服务端的信息以及它的公钥

  4. 验证成功之后会用伪随机函数计算出一个加密所需要的对称密钥(secret),并且用服务端的公钥加密这个对称密钥发送给服务端

  5. 服务端再用自己的私钥解密刚刚的消息,得到里面的对称密钥。此时服务端和客户端都有了对称密钥。

  6. 后面的传输都会用这个 secret 进行对称密钥加解密传输

与TLS握手的区别? 最主要的:RSA不具备向前安全性,ECDHE有;一次破解并不影响历史信息的性质就是向前安全性。

参考文章

可能还有一些我参考到的忘记了,我把我记得的都列出来,再次感谢~

  • 一百个Chocolategithub.com/Chocolate19…
  • CavsZhouyougithub.com/CavsZhouyou
  • 神三元:(建议精读)HTTP灵魂之问,巩固你的 HTTP 知识体系
  • LinDaiDai_霖呆呆:Shutdown HTTP系列文章
  • 寻找海蓝96:面试官(9):可能是全网最全的http面试答案

⭐️⭐️ 都看到这了,求一个赞不过分吧 ,能一键三连的话那就更好啦 ❀ ,你的支持是我继续写作的动力 ❀

⭐️ 后续应该会补上遇到的网络面试题,可能也会出一些小知识点的总结比如cookie,反正这篇下不是终点啦~

最后祝大家身体健康,天天开心,事事顺心,心想事成,暴富暴富~~