【八股文】13 计算机网络

OSI 的七层模型分别是？各自的功能是什么？

网络七层模型是一个标准，而非实现。
网络四层模型是一个实现的应用模型。
网络四层模型由七层模型简化合并而来。

物理层：底层数据传输，如网线；网卡标准。
数据链路层：定义数据的基本格式，如何传输，如何标识；如网卡MAC地址。
网络层：定义IP编址，定义路由功能；如不同设备的数据转发。
传输层：端到端传输数据的基本功能；如 TCP、UDP。
会话层：控制应用程序之间会话能力；如不同软件数据分发给不同软件。
表示层：数据格式标识，基本压缩加密功能。
应用层：各种应用软件，包括 Web 应用。

在四层，既传输层数据被称作段（Segments）；
三层网络层数据被称做包（Packages）；
二层数据链路层时数据被称为帧（Frames）；
一层物理层时数据被称为比特流（Bits）。

为什么需要三次握手？两次不行？

首先很多人会先讲下握手的过程：
1、第一次握手：客户端给服务器发送一个 SYN 报文。
2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。
3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。
4、服务器收到 ACK 报文之后，三次握手建立完成。
作用是为了确认双方的接收与发送能力是否正常。

握手的作用
第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

为什么需要四次挥手？三次不行？

1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
2、第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
3、第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

TCP与UDP有哪些区别？各自应用场景？

介绍

1. TCP提供可靠的传输服务。

2. TCP提供全双工通信。既能发又能收

3. TCP是面向连接，必须先建立一条通道
   三次握手就是建议通道的一个过程，
   四次挥手则是结束销毁通道的其中一个过程，还有别的步骤，但是我……

4. UDP是无连接的传输层协议；

5. UDP提供尽力而为交付

6. UDP是面向报文的，对应用层交下来的报文，不合并，不拆分，保留原报文的边界；

7. UDP没有拥塞控制，因此即使网络出现拥塞也不会降低发送速率；

8. UDP支持一对一　一对多　多对多的交互通信；

9. UDP的首部开销小，只有８字节．

区别

1. TCP是可靠传输,UDP是不可靠传输;
2. TCP面向连接,UDP无连接;
3. TCP传输数据有序,UDP不保证数据的有序性;
4. TCP不保存数据边界,UDP保留数据边界;
5. TCP传输速度相对UDP较慢;
6. TCP有流量控制和拥塞控制,UDP没有;
7. TCP是重量级协议,UDP是轻量级协议;
8. TCP首部较长２０字节,UDP首部较短８字节;

HTTP 哪些常用的状态码及使用场景？

状态码分类
1xx：表示目前是协议的中间状态，还需要后续请求
2xx：表示请求成功
3xx：表示重定向状态，需要重新请求
4xx：表示请求报文错误
5xx：服务器端错误
常用状态码
101 切换请求协议，从 HTTP 切换到 WebSocket
200 请求成功，有响应体
301 永久重定向：会缓存
302 临时重定向：不会缓存
304 协商缓存命中
403 服务器禁止访问

在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

connetion:keep-alive;

HTTP 如何实现长连接？在什么时候会超时？

通过在头部（请求和响应头）设置 Connection: keep-alive，HTTP1.0协议支持，但是默认关闭，从HTTP1.1协议以后，连接默认都是长连接
1、HTTP 一般会有 httpd 守护进程，里面可以设置 keep-alive timeout，当 tcp 链接闲置超过这个时间就会关闭，也可以在 HTTP 的 header 里面设置超时时间
2、TCP 的 keep-alive 包含三个参数，支持在系统内核的 net.ipv4 里面设置：当 TCP 链接之后，闲置了 tcp_keepalive_time，则会发生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了 tcp_keepalive_probes，就会丢弃该链接。
（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800
实际上 HTTP 没有长短链接，只有 TCP 有，TCP 长连接可以复用一个 TCP 链接来发起多次 HTTP 请求，这样可以减少资源消耗，比如一次请求 HTML，可能还需要请求后续的 JS/CSS/图片等

简单说下 HTTPS 和 HTTP 的区别

开销：HTTPS 协议需要证书，需要交费；
HTTP不安全，HTTPS不安全
资源消耗：HTTP信息是明文传输，HTTPS 是有加密传输协议，需要消耗更多的 CPU 和内存资源；
端口不同：HTTP：80 HTTPS :443

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

对称密钥加密是指加密和解密使用同一个密钥的方式
非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。

非对称更安全

简单说下每一层对应的网络协议有哪些？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LTwcqj8K-1657299599465)(./FILES/4-ji-suan-ji-wang-luo.md/45b2d19b.png)]

TCP 协议是如何保证可靠传输的？

通过几个操作

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

谈谈你对停止等待协议的理解？

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。主要包括以下几种情况：无差错情况、出现差错情况（超时重传）、确认丢失和确认迟到。

谈谈你对 ARQ 协议的理解？

两种ARQ协议
自动重传请求 ARQ 协议
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。

连续 ARQ 协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

谈谈你对滑动窗口的了解？

TCP 利用滑动窗口实现流量控制的机制。滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。

TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

谈下你对流量控制的理解？

谈下你对 TCP 拥塞控制的理解？使用了哪些算法？

理解：
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。
拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。

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

TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。
慢开始：
慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
拥塞避免：
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1。
快重传与快恢复：
在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。
没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。
有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和快恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

什么是粘包？

如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

结构原因：
1、TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；
2、从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。

TCP 黏包是怎么产生的？

发送方产生粘包
采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。

接收方产生粘包
接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（C 语言用 recv、read 等函数）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）

怎么解决拆包和粘包？

分包机制一般有两个通用的解决方法：
1、特殊字符控制；
2、在包头首都添加数据包的长度。
如果使用 netty 的话，就有专门的编码器和解码器解决拆包和粘包问题了。

tips：UDP 没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报，发送的时候既不合并，也不拆分。

forward 和 redirect 的区别？

两种请求转发方式：直接转发和间接转发。
直接转发就相当于：“A 找 B 借钱，B 说没有，B 去找 C 借，借到借不到都会把消息传递给 A”；
间接转发就相当于：”A 找 B 借钱，B 说没有，让 A 去找 C 借”。

HTTP 方法有哪些？

1、GET：获取资源，当前网络中绝大部分使用的都是 GET；
2、HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分；
3、POST：传输实体主体
4、PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。
5、PATCH：对资源进行部分修改。PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。
6、OPTIONS：查询指定的 URL 支持的方法；
7、CONNECT：要求在与代理服务器通信时建立隧道。使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
8、TRACE：追踪路径。服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。
9、Delete：删除文件,与 PUT 功能相反，并且同样不带验证机制。

在浏览器中输入 URL 地址到显示主页的过程？

过程：
DNS 解析、建立TCP 连接、发送 HTTP 请求、服务器处理请求并返回 HTTP 报文、浏览器解析渲染页面、连接结束

DNS 的解析过程？

1、主机向本地域名服务器的查询一般都是采用递归查询。
2、本地域名服务器向根域名服务器的查询的迭代查询。

递归查询：本地域名服务器查不到，服务器就以客户身份向上查、而不是让主机自己在查
迭代查询：要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”

HTTPS 的优缺点？

优点：
使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性；
HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：
HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；
HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；
SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；
HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

什么是数字签名？

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

什么是数字证书？

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。

Cookie 和 Session 有什么区别？

Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中。

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。#### UDP 如何实现可靠传输？

IPV4 地址不够如何解决

1. NAT技术
   1. 一个地址分给多个人用
2. IPV6