「计算机网络」前端必备知识，看到就是赚到-技术圈

文章首发自掘金「HearLing」，小狮子姐姐原创文章~

这篇文章是一个我计算机网络复习的大汇总，由于内容太多了我把它分成了上下两篇来写，这一篇讲的是应用层协议 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 的参数传递支持更多的数据类型。）

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对称密钥加密报文进行传输。、

详细过程：

客户端在第一次发送 HTTPS 请求的时候，会把 client_random、TSL 版本号、加密套件列表发送给服务器
服务器在接收到之后确认 TSL 的版本号，同时发送 server_random、server_params、需要使用的加密套件、以及自己的证书给客户端
客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目 7)，若是验证成功则会传递一个 client_params 给服务器
与此同时客户端会通过 ECDHE 算法计算出一个 pre_random，其中是传入了两个参数，一个是 client_params，还一个是 server_params。(也就是说：ECDHE(client_params, server_params) = per_random)
这时候客户端就同时拥有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的 secret，这个 secret 就是它们后续通信所要用的对称密钥。
而在客户端生成完 secret 之后，会给服务器发送一个收尾消息，告诉服务器之后都要用对称加密，且对称加密的算法是用第一次约定好的。
服务器它在接收到刚刚传递过来的 client_params 之后，也会使用和客户端一样的方式生成 secret，并且也会发送一个收尾消息给客户端。
当双方都收到收尾消息并验证成功之后，握手就结束了。后面开始用这个 secret 对称密钥加密报文进行传输。

描述 RSA 握手

客户端首先向服务端发送一个 HTTPS 请求
服务端会把事先配置好的公钥证书随着其它的信息返回给客户端
客户端在收到服务端发来的证书之后进行验证，验证的过程参考数字证书验证，会得到服务端的信息以及它的公钥
验证成功之后会用伪随机函数计算出一个加密所需要的对称密钥(secret)，并且用服务端的公钥加密这个对称密钥发送给服务端
服务端再用自己的私钥解密刚刚的消息，得到里面的对称密钥。此时服务端和客户端都有了对称密钥。
后面的传输都会用这个 secret 进行对称密钥加解密传输

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