计算机网络面试高频

1. OSI七层模型和TCP五层模型

TCP五层模型相比OSI七层模型，将OSI的应用层、表示层和会话层合为一层：应用层，其他不变。

• 物理层：利用物理传输介质为数据链路层提供物理连接，传输比特流。
• 数据链路层:： 定义通过通信媒介互联的设备之间的传输规范
• 网络层：寻址和路由
• 传输层：为上层协议提供端到端的可靠传输
• 会话层：建立 断开 维护通信连接
• 表示层：数据格式转换、数据压缩和数据加密
• 应用层：为应用程序提供网络服务

2. 面向连接型、面向无连接型

• 面向连接
  面向连接型传输包括会话建立、传输数据和会话断开，此外还包括保证传输可靠性的措施：超时重传、流量控制等。常见的：TCP
• 面向无连接
  面向无连接型仅提供基本的传输数据的功能，即使接收端不存在，发送端也能发送数据包，常见的：UDP、IP

3. UDP、TCP是什么？特点及区别

都是传输层的协议，用来建立可靠的通信传输链接

UDP仅提供了最基本的数据传输功能，至于传输时连接的建立和断开，传输可靠性的保证等这些UDP不关心，都交给了UDP上层的应用程序去处理，自己仅提供传输层协议的最基本功能。

TCP作为一种面向连接的协议，只有在确认通信对端存在时才会发送数据，建立、断开连接。还采取了保证传输可靠性的措施

区别：

• 面向连接、面向无连接
• TCP是一对一传输，UDP支持交互通信：一对一、一对多、多对一、多对多
• TCP面向字节流，将应用层传下来的报文看成字节流，拆分成大小不等的数据块，再添加TCP首部
  UDP面向报文，不拆分也不合并，直接添加UDP首部
• TCP支持传输可靠性的多种措施，包括保证报的传输顺序、超时重传、流量控制、拥塞控制
  UDP仅提供最基本的数据传输能力

4. TCP对应的应用层协议有哪些？UDP呢？

• TCP
  FTP 文件传输协议
  SSH 远程登录协议
  HTTP 超文本传输协议
• UDP
  DNS 域名解析协议
  TFTP：简单文件传输协议
  SNMP：简单网络管理协议

5. TCP三次握手

物理层、数据链路层在物理层面上架设好了通信链路，网络层确定了通信双方的地址，那下一步就是传输层建立逻辑层面上的通信连接，将从应用层获得的报文数据从源端发送给接受端。

TCP的三次握手：
发送数据前通过“三次握手”的方式建立通信连接，建立这个连接的目的是让源端和目的端确认一下双方的发送报文能力和接收报文能力是正常的

6. TCP四次挥手

三次握手是建立TCP连接，四次挥手是断开TCP连接，即客户端和服务端总共要收发4个包才能确定断开连接。

6.1 为什么会有TIME_WAIT状态？

6.2 为什么是四次挥手而不是三次或者五次？

TCP的三次握手、四次挥手

7. ARQ协议？

自动重传请求（automatic-repeat-request）
发送方在发送一段时间后没有收到确认回执，通常会重新发送。

• 停止等待ARQ协议
  发送端维护一个超时计时器，如果在设置时间内未接收到接收端发来的确认回执的话，重新发送之前的报文分组。
• 连续ARQ协议
  发送端维护一个窗口，窗口内有多个分组，窗口内的分组都可以连续发送出去而不必等待接收端返回的确认回执。
  对按序到达的最后一个分组，接收端回向发送端发送确认回执，如果有分组没有正确到达，返回最后一个正确到达的分组序号，该序号后的分组会重新发送给接收端。

8. TCP的流量控制

流量控制是为了控制发送端发送数据的速率，来保证接收端成功接收所有应接收的分组，否则会触发自动重传机制造成网络流量的浪费

具体地：
接收端会通知发送端自己能接收的数据大小，发送端发送的数据量不会超过这个大小，成为窗口，在TCP首部有一个字段来表示，该值越大吞吐量越大

9. TCP拥塞控制

计算机网络处在一个共享的环境，通信开始时如果立即把大量数据注入到网络，可能会引起网络阻塞。

常见策略：
慢启动、拥塞避免、快重传、快恢复

慢启动：
通信开始时，定义一个“拥塞窗口”，窗口大小为1，意思是一开始只发送一个分组，之后每收到一个确认回执，拥塞窗口的大小就加1，发送端在发送数据时，min(拥塞窗口、接收端流量控制窗口），实际发送的数据量比这个min还要小。

10.TCP长连接和短连接

短连接：
一次读写完成，客户端向服务端发送数据，服务端回应，然后任何一方都可发起close操作。
但一般是客户端先发起。

长连接：
完成一次读写后，之间的连接不会主动关闭，后续的读写操作会继续使用这个连接。
一般是服务端采取一些关闭策略来关闭连接。

11. TCP粘包、拆包及解决办法

11.1 为什么TCP有粘包？

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

原因：

• TCP面向字节流，把接收报文拆分成的大小不等的数据块仅仅看做一连串无结构的字节流，没有边界。
• 从TCP的帧结构也可以看出，TCP首部没有表示数据长度的字段

因此在使用TCP传输时，才有粘包或拆包现象。

11.2 为什么UDP无粘包 ？

UDP 是基于报文发送的，UDP首部采用了 16bit 来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

11.3 粘包怎么产生的？

• 发送方产生粘包
  客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，因此数据发送出来它已经是粘包的状态了。
  综上：要发送的数据大小小于TCP缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会产生粘包。
• 接收方产生粘包
  TCP协议是将接收的数据放置到接收缓冲区，然后由应用层来主动获取（C 语言用 recv、read 等函数）；若读数据的函数不能及时的拿出缓冲区中的数据，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）。
  综上：接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

11.3 简述为什么产生TCP粘包、拆包

• 要发送的数据大于 TCP 发送缓冲区剩余空间大小，将会发生拆包。
• 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行拆包。
• 要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包。
• 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

11.4 粘包、拆包解决办法

TCP 本身是面向字节流的，无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，归纳如下：

• 设置消息边界
  每个包的末尾加上特殊字符，用以区分连续的两个包
• 在报文首部添加包的长度。

参考