网络协议-计算机网络

Posted 2022-02-21 Panda_Java

各种网络协议

• 1 从发送一个请求到响应页面经历了哪些过程？
• 2 http协议
• • 2.1 http响应状态码
  • 2.2 http组成成分
  • 2.3 http与 https 区别
  • 2.4 https加密过程
  • 2.5 对称加密与非对称加密的区别
• 3 TCP与UDP协议
• • 3.1 三次握手
  • 3.2 为什么要三次握手
  • 3.3 第 2 次握手传回了 ACK，为什么还要传回 SYN？
  • 3.2 四次挥手
  • 3.3 TCP 协议如何保证可靠传输?
  • 3.4 TCP与UDP区别
• 4 参考JavaGuide

1 从发送一个请求到响应页面经历了哪些过程？

详细过程请参阅
链接: 前端经典面试题: 从输入URL到页面加载发生了什么？.
总体来说分为以下几个过程:
①DNS 解析
②TCP 连接
③发送 HTTP 请求
④服务器处理请求并返回 HTTP 报文
⑤浏览器解析渲染页面
⑥连接结束
链接: 发送一个url请求到页面渲染完成经历的流程.

2 http协议

2.1 http响应状态码

2.2 http组成成分

HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。
请求行
链接: HTTP协议由哪些部分组成？.

2.3 http与 https 区别

端口 ：HTTP 的 URL 由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

1. 由于HTTP的内容在网络上实际是明文传输，并且也没有身份验证之类的安全措施，所以容易遭到挟持与攻击
2. HTTPS是通过SSL(安全套接层)和TLS(安全传输协议)的组合使用，加密TCP载荷即HTTP报文内容，同时通过不对称密钥方式认证身份，保证传输的安全可靠

2.4 https加密过程

HTTPS即加密的HTTP，HTTPS并不是一个新协议，而是HTTP+SSL（TLS）。原本HTTP先和TCP（假定传输层是TCP协议）直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和TCP通信，相当于SSL被嵌在了HTTP和TCP之间。

请求过程：

1.客户端访问 https开头的url

2.服务端返回公钥1，客户端验证通过（如果不通过，则访问终断）。

3.客户端根据公钥1生成一个私钥2，这个私钥2用来加密和解密请求信息。使用公钥1对私钥2进行加密，回传给服务端。服务端用私钥1对该信息解密，得到私钥2。至此，客户端和服务端都已经有了私钥2。

4.客户端和服务端之间使用私钥2对信息进行加密后通信，这样即使第三方抓包，也无法轻易获取通信内容了。
换种方式解释

1. 服务器把自己的公开密钥登录至数字证书认证机构。

2. 数字证书认证机构用自己的私有密钥向服务器的公开密码署数字签名并颁发公钥证书。

3. 客户端拿到服务器的公钥证书后，使用数字签名认证机构的公开密钥，向数字证书认证机构验证公钥证书上的数字签名，以确认服务器的公开密钥的真实性。

4. 使用服务器的公开密钥对报文加密后发送。

5. 服务器用私有密钥对报文解密。

链接: https加密解密过程详解 .
链接: HTTPS的加密过程.

2.5 对称加密与非对称加密的区别

对称加密:编/解码使用相同密钥的算法,一般是共享密钥

非对称加密:非对称加密算法需要两个密钥，公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。 公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。 因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法

3 TCP与UDP协议

3.1 三次握手

客户端–发送带有 SYN 标志的数据包–一次握手–服务端
服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端

3.2 为什么要三次握手

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

3.3 第 2 次握手传回了 ACK，为什么还要传回 SYN？

接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立并确认从服务端到客户端的通信。

3.2 四次挥手

断开一个 TCP 连接则需要“四次挥手”：

1. 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
2. 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加 1 。和 SYN 一样，一个 FIN 将占用一个序号
3. 服务器-关闭与客户端的连接，发送一个 FIN 给客户端
4. 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加 1

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

上面讲的比较概括，推荐一篇讲的比较细致的文章：https://blog.csdn.net/qzcsu/article/details/72861891

3.3 TCP 协议如何保证可靠传输?

1. 应用数据被分割成 TCP 认为最适合发送的数据块。
2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3. 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
4. TCP 的接收端会丢弃重复的数据。
5. 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
6. 拥塞控制： 当网络拥塞时，减少数据的发送。
7. ARQ 协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

流量控制
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

拥塞控制
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

3.4 TCP与UDP区别

4 参考JavaGuide

链接: JavaGuide.