📒博客首页：崇尚学技术的科班人
小肖来了🏇
🍣今天给大家带来的文章是《【面试题】计算机网络 -- 常见面试题总结》🍣
🍣希望各位小伙伴们能够耐心的读完这篇文章🍣
🙏博主也在学习阶段，如若发现问题，请告知，非常感谢🙏
💗同时也非常感谢各位小伙伴们的支持💗

本文参考于JavaGuide

1、OSI 与 TCP/IP 各层的结构与功能, 都有哪些协议?

2、TCP三次握手和四次挥手

2.1、三次握手过程

• 简单示意图

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

• 详细示意图

1. 建立过程中，TCP客户机会首先发送给TCP服务器一个TCP连接请求报文（SYN = 1, seq = x）；
2. TCP服务器进程收到后发送一个TCP连接请求确认报文（SYN = 1，ACK = 1，seq = y，ack = x + 1），TCP客户端进程收到相应的报文后进入连接已建立状态；
3. 然后向TCP服务器进程发送一个TCP普通确认报文段，然后TCP服务器进程进入连接已建立状态。

2.2、为什么需要三次握手？

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

1. 第一次握手：客户端什么都不能确认；服务器确认了对方发送正常，自己接收正常
2. 第二次握手：客户端确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：对方发送正常，自己接收正常
3. 第三次握手：客户端确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：自己发送、接收正常，对方发送、接收正常

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

• 那么，首先我们需要对SYN同步序列编号进行介绍，SYN同步序列编号是 TCP/IP 建立连接时使用的握手信号。当我们需要在客户端和服务器端建立TCP连接的时候，客户端需要向服务器端发送一个带有SYN标志的数据包。
• 所以说，但我们进行过了第一次握手之后，从客户端到服务器端的TCP连接已经完全建立。那么只剩下服务器端的TCP连接还未完全建立。而回传 SYN则是为了建立并确认从服务端到客户端的通信。

2.4、四次挥手过程

（1）、 TCP客户进程向TCP服务器发送TCP连接释放报文

当TCP客户端进程要主动关闭连接时，TCP客户端进程就会向TCP服务器端发送一个TCP连接释放报文（FIN = 1 ，ACK= 1，seq = u，ack = v）。此时TCP客户端进入终止等待状态。

（2）、TCP服务器端进程向TCP客户端进程发送一个普通的TCP确认报文

然后TCP服务器端进程会向TCP客户端进程发送一个普通的TCP确认报文（ACK = 1，seq = v，ack = u+ 1），且此时的TCP服务器端进入关闭等待状态，TCP客户端进程进入终止等待状态。

此时TCP客户端进程到TCP服务器端的进程的连接已经关闭，而TCP服务器端到TCP客户端进程的连接还未关闭。所以此时TCP服务器端进程还可以给TCP客户端进程进行数据传输。

（3）、TCP服务器端进程向TCP客户端进程发送TCP连接释放报文

当TCP服务器端的进程数据传输完毕后，TCP服务器端进程会向TCP客户端进程发送TCP连接释放报文（FIN = 1，ACK = 1，seq = w，ack = u + 1），且此时TCP服务器端进程进入最后确认状态。

（4）、TCP客户端进程向TCP服务器端进程发送普通的TCP连接释放确认报文

TCP客户端进程收到TCP服务器端进程发送而来的TCP连接释放报文后，TCP客户端进程会向TCP服务器端进程发送一个普通的TCP连接释放确认报文。且此时从TCP服务器端进程到TCP客户端进程的连接关闭。TCP服务器端进程进入关闭状态，而TCP客户端进程进入时间等待状态。经过2MSL后进入关闭状态。

2.5、为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接?

MSL的意思是报文的最长寿命。要确保服务器是否已经收到了我们的ACK报文，过了一个MSL后如果没有收到的话，服务器会重新发报FIN文给客端，此时又花了一个MSL，客户端再次收到FIN报文之后，就知道之前的ACK报文丢失了，然后再次发送ACK报文，一来一去正好2个MSL。

3、TCP、UDP协议的区别

4、TCP协议如何保证可靠传输

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

5、流量控制和拥塞控制的对比

• 流量控制：TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

• 拥塞控制：在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。

• TCP 的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。

• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送放的 cwnd 加 1.

• 快重传与快恢复：在 TCP/IP 中，快速重传和恢复是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

6、在浏览器中输入 url 地址到显示主页的过程

1. DNS 解析：浏览器查询 DNS，获取域名对应的 IP 地址
2. TCP 连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手
3. 发送 HTTP 请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求
4. 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处 理，并将处理结果及相应的视图返回给浏览器
5. 浏览器解析渲染页面
6. 连接结束

• 期间所涉及到的协议

1. 首先浏览器查找域名的IP地址的过程会使用DNS协议
2. 与服务器建立TCP连接使用到了TCP协议
3. 建立TCP协议时，需要发送数据，发送数据在网络层使用IP协议
4. IP数据包在路由器之间，路由选择使用OPSF协议
5. 路由器在与服务器通信时，需要将ip地址转换为MAC地址，需要使用ARP协议
6. 在TCP建立完成后，使用HTTP协议访问网页

7、状态码

8、HTTP长连接、短连接

• 短连接：在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。
• 长连接：而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

Connection:keep-alive

9、Cookie 的作用是什么? 和 Session 有什么区别？

• Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
• Cookie 一般用来保存用户信息 比如 ① 我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；② 一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③ 登录一次网站后访问网站其他页面不需要重新登录。
• Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

10、HTTP 1.0 和 HTTP 1.1 的主要区别是什么?

1. 长连接 : 在 HTTP/1.0 中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 1.1 起，默认使用长连接 ，默认开启 Connection： keep-alive。
2. 错误状态响应码：在 HTTP1.1 中新增了 24 个错误状态响应码。
3. 缓存处理：在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用：在HTTP 1.0中会存在浪费带宽的现象，主要是因为不支持断点续传功能，客户端只是需要某个对象的一部分，服务端却将整个对象都传了过来。在HTTP1.1中请求头引入了range头域，它支持只请求资源的某个部分，返回的状态码为206。

11、URI和URL的区别

• URI是统一资源标志符，可以唯一标识一个资源。
• URL是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源

12、HTTP和HTTPS的区别

1. HTTP的端口号是80，HTTPS的端口号是443。
2. HTTP协议运行在TCP协议之上，但其传输的时候都是明文传输，所以十分的不安全。而HTTPS是运行在SSL/TLS之上的HTTP协议，而SSL/TLS协议优势运行在TCP协议之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

• 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有 DES、AES 等；
• 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有 RSA、DSA 等。

13、GET 和 POST 的区别？

1. URL 中参数可见性：GET 参数可见（通过拼接 URL 进行传递参数），POST 参数不可见。
2. 是否可缓存：GET 请求是可以缓存的，POST 请求不可以缓存。
3. 传输数据的大小：GET 一般传输数据大小不超过 2k-4k（根据浏览器不同，限制不一样，但相差不大），POST 请求传输数据的大小根据 php.ini 配置文件设定，也可以无限大。
4. 安全性：GET 不安全，POST 安全。
5. 数据包个数：GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。