跳至主要內容

计算机网络面试习题（上）

CodeShouhu大约 22 分钟使用指南Markdown

TCP与UDP

1，TCP的三次握手

Tcp三次握手

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

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

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

服务端收到客户端的 ACK，连接已建立，可以数据传输。

速记

TCP 握手三次行，连接建立心安宁。
客户端发 SYN 包，首次握手服务瞧。
服务回应 SYN/ACK，二次握手客户端晓。
客户端再发 ACK 到，三次握手连接好。
服务收到连接成，数据传输畅又行。

2，TCP为什么要进行三次握手

【答案一】因为信道不可靠，而 TCP 想在不可靠信道上建立可靠地传输，那么三次通信是理论上的最小值。（而 UDP 则不需建立可靠传输，因此 UDP 不需要三次握手。）

【答案二】因为双方都需要确认对方收到了自己发送的序列号，确认过程最少要进行三次通信。

速记

TCP 握手三次行，可靠传输有原因。
信道不可靠性存，三次通信是下限。
UDP 无需稳传输，握手自然不沾边。
双方要确认序号，最少三次来核验。

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

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

速记

接收回传 ACK 号，告知客户信息到，
客到服务通航道，通信正常没烦恼。
回传 SYN 也重要，服务到客来建交，
双向通信确认好，三次握手错不了。

4，断开tcp需要四次挥手，注意每一次挥手后系统的状态

第一次挥手：TCP客户端发送一个FIN报文，用来关闭客户到服务器的数据传送。客服端自己进入到FIN_TIMEWAIT1阶段，

第二次挥手： 服务器收到这个FIN报文，它发回一个ACK报文，确认序号为收到的序号加1。服务器自己进入CLOSE_WAIT，等待关闭状态。客服端接受到这个ACK报文后， 自己进入到FIN_TIMEWAIT2状态。等待对端服务器发过来FIN.

第三次挥手： 服务器关闭客户端的连接，发送一个FIN给客户端。自己进入LAST_ACK状态， 等待最终的对端发来ACK确认。

第四次挥手：客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

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

速记

TCP断连有诀窍，四次挥手来宣告。
首挥FIN消传数据，客户进入等待一。
服务回A序加一，自身关待客户知，
客户入二等F至。
服务再挥关连意，末等确认把步移。
客户回A终完毕，双方确认全断离。
数据终了皆可提，半关全关有序依。

5，TCP与UDP的区别

TCP（传输控制协议）和UDP（用户数据报协议）之间存在以下区别：

  1. 连接性质：TCP是面向连接的，需要在客户端和服务端传输数据之前建立连接。而UDP是无连接的，发送数据之前不需要建立连接。
  2. 可靠性：TCP提供可靠的服务，通过TCP传输的数据不会丢失、重复，且会按照顺序到达。然而，UDP提供的是不可靠的服务，它不保证数据能够可靠、完整的到达，只是尽可能的完成交付。
  3. 效率：因为TCP的可靠性和连接性质，TCP的传输效率相对较低。而UDP由于无需建立连接和数据拆分，以及可以携带原始数据，其传输效率相对较高。
  4. 数据模式与头部开销：TCP是流模式，根据发送窗口拆分数据发送。相比之下，UDP是数据报模式，不在该层做数据拆分，而是原样发送。另外，TCP头部至少需要20字节，而UDP头部只需要8字节。

总的来说，TCP和UDP都有各自的优点和使用场景。TCP的主要优点是其可靠性和顺序性，而UDP的主要优点则是其高效性和简单的数据包结构。选择使用哪一种协议主要取决于应用程序的具体需求和网络环境。

速记

TCP与UDP，区别要记清。
连接有不同，TCP先建情，
UDP无连接，发送更随性。
可靠分高低，TCP稳又行，
数据不丢序，UDP难保证。
效率各分明，TCP稍慢行，
UDP效率高，传输更轻盈。
模式开销异，TCP流拆分，
头部廿字节，UDP报文整，
八字开销轻。
应用看场景，按需来选定。

6，为何需要把 TCP/IP 协议栈分成 5 层（或7层）？

答：ARPANET 的研制经验表明，对于复杂的计算机网络协议，其结构应该是层次式的。 分层的好处：

①隔层之间是独立的

②灵活性好

③结构上可以分隔开

④易于实现和维护
⑤能促进标准化工作。

速记

ARPANET 经验妙，网络协议分层好。
隔层独立互打扰，灵活多变真灵巧。
结构分隔条理妙，实现维护没烦恼。
标准工作促成效，分层优势要记牢。

7，TCP头部中有哪些信息？

TCP头部包含以下信息：

  1. 源端口号：16位，发送方的端口号。
  2. 目标端口号：16位，发送方的目标端口号。
  3. 序号：32位，保证网络传输数据的顺序性。序号超过最大值则回到0重新开始，做的是一个取余（mod）运算。
  4. 确认号：32位，用来确认确实有收到相关封包，内容表示期望收到下一个报文的序列号，用来解决丢包的问题。
  5. 头部大小：4位，偏移量。单位为32位(bit)，单位也就是4个字节，给出头部占32bit的数目。
  6. Reserved：4位 ，预留字段，都为0。
  7. TCP标志位：有多种标志位，包括拥塞窗口减少标志（CWR）、显式拥塞提醒回应标志（ECN-Echo）、紧急指针有效标志（URG）、确认号有效标志（ACK）、接收方应该尽快将这个报文段交给应用层标志（PSH）、释放连接重连标志（RST）、发起一个连接标志（SYN）和关闭一个连接标志（FIN）。每一个标志位对应一个特定的功能。
  8. 窗口大小：16位，占16bit。此字段用来进行流量控制，主要用于解决流控拥塞的问题。单位为字节数，这个值是本机期望一次接收的字节数。
  9. 校验值：16位，占16bit。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
  10. 紧急指针：16位，占16bit。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。

TCP头部信息的固定部分总共有20个字节，如果加上最多40个字节的填充信息部分（可没有），那么整个TCP头部最大可以有60字节。

速记

TCP头信息多，且听我来唱一歌。
源目端口十六位，发送接收各有归。
序号三四保顺序，超值取余从头起。
确认三四解丢包，期望序号它来报。
头大四位偏移量，单位四字节别忘。
保留四位全为零，标志多位功能明。
CWR与ECN，URG、ACK也来拼，
PSH、RST不缺席，SYN、FIN管连离。
窗口十六控流量，校验十六保质量。
紧急指针十六位，序号相加定结尾。
固定二十字节整，填充四十可变型，
最大六十记心中，TCP头要弄通。

8，常见TCP的连接状态有哪些

TCP的连接状态主要可以大致分为以下几种：

  1. CLOSED：这是TCP连接的初始状态，表示没有任何连接。
  2. LISTEN：服务器处于监听状态，等待客户端的连接请求。
  3. SYN_SENT：客户端通过应用程序调用connect进行主动打开(active open)。于是客户端tcp发送一个SYN以请求建立一个连接，状态置为SYN_SENT。
  4. SYN_RECV：服务端应发出ACK确认客户端的SYN，同时自己向客户端发送一个SYN，状态置为SYN_RECV。
  5. ESTABLISHED：这表示一个打开的连接，双方可以进行或已经在数据交互。
  6. FIN_WAIT_1：这是终止连接的一方（通常是客户端）发送了FIN报文后进入的状态，等待对方FIN。
  7. CLOSE_WAIT：这是接收到客户端FIN包之后服务器等待关闭的阶段。
  8. FIN_WAIT_2：此时有一方要求关闭连接，等待另一方关闭，也就是半连接状态。
  9. LAST_ACK：这是服务端发动最后的FIN包，等待最后的客户端ACK响应的状态。
  10. TIME_WAIT：这是客户端收到服务端的FIN包，并立即发出ACK包做最后的确认后的状态，之后还需等待2MSL时间。

以上就是一些常见的TCP连接状态，不同系统或软件可能会有所差异。

速记

TCP状态有多种，听我来把口诀诵。
初始状态CLOSED，无连无接很轻松。
LISTEN下等连接，SYN_SENT客户端冲。
SYN_RECV两边应，ESTABLISHED通信通。
FIN_WAIT想断开，CLOSE_WAIT等收工。
FIN_WAIT_2半连中，LAST_ACK最后送。
TIME_WAIT再等等，2MSL才放松。
系统不同有差异，常见状态记心中。

流量控制与拥塞控制

9，TCP 协议如何保证可靠传输

TCP协议通过多种方式保证可靠传输：

  1. 确认应答和序列号：在TCP连接中，发送的每一个数据包（报文段）都会进行编号，接收方对数据包进行排序，把有序数据传送给应用层。如果接收方没有接收到确认，就会重传这个报文段。
  2. 超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。 如果不能及时收到一个确认，将重发这个报文段。
  3. 流量控制：TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。 当接收方来不及处理发送方的数据时，能提示发送方降低发送的速率，防止包丢失。（TCP 利用滑动窗口实现流量控制）
  4. 拥塞控制：当网络拥塞时，TCP会减少数据的发送。 TCP的接收端会丢弃重复的数据。

以上这些措施共同保证了TCP协议的可靠传输。

速记

TCP传输稳，可靠有窍门。
序号确认准，丢包能重抡。
超时别发闷，重传补裂痕。
流量控得紧，窗口来指引。
拥塞别发晕，降速保平稳。
措施齐上阵，传输超安稳。

10，TCP利用滑动窗口实现流量控制的机制？

TCP利用滑动窗口实现流量控制的机制如下：

  1. 对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许被接收。通过调整发送方窗口和接收方窗口的大小可以实现流量控制，就象通过阀门控制水流速度一样。
  2. TCP开始的时候窗口比较小，然后开始增长直到有错误发生时为止。窗口的滑动依赖于网络性能，也就是说 TCP协议通过滑动窗口来实现流量控制和差错控制以至于实现可靠传输。
  3. 当滑动窗口为0时，发送方一般不能再发送数据，但有两种情况除外：一种是可以发送紧急数据；另一种是可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

速记

TCP流控有妙方，滑窗机制来帮忙。
数据编号按序排，双窗把关严又强。
发收窗口可调整，流速如阀随心畅。
初始窗小渐增长，遇错停步莫慌张。
网络性能定滑向，可靠传输有保障。
窗零禁发也有样，紧急一字把信通。

11，TCP的拥塞控制

当网络拥塞时，减少数据的发送。

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

相反，流量控制 往往是 点对点通信量的控制，是个 端到端的问题。流量控制 所要做到的就是 抑制发送端发送数据的速率，以便使接收端来得及接收。

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

速记

网络拥塞别慌张，数据发送要减量。
资源需求若过量，网络性能就下降。
拥塞控制有良方，防注过载保通畅。
全局把控来帮忙，主机路由都要上。
流量控制不一样，点对点间速率降。
拥塞窗口要跟上，动态变化保稳当。
发送窗口取其小，网络传输才高效。

12，如何区分流量控制和拥塞控制？

流量控制 和 拥塞控制 主要的区别在于它们应对网络问题的不同侧重点。

流量控制 主要针对的是发送方和接收方之间由于速度不同步而可能导致的数据丢失问题。当发送方发送得太快，而接收方来不及接收时，就可能导致数据丢失。流量控制 通过 滑动窗口 的方式进行解决，窗口的一端是发送窗口，另一端是接收窗口，窗口的大小限制了发送和接收数据的数量。这样，发送方在任何时候只能发送窗口大小范围内的数据，接收方也会在接收窗口大小范围内接收数据。

拥塞控制 主要是为了解决网络中由于数据注入过多或者过快而导致网络拥塞，从而使得网络负载过大，超过其处理能力的问题。当网络发生拥塞时，如果不加以控制，网络可能会变得非常缓慢，甚至可能会导致网络崩溃。拥塞控制 通过 拥塞窗口 来进行，这个窗口的大小代表了在一个 RTT（Round-Trip Time，往返时间） 内可以最多发送的数据包数量。在 拥塞避免阶段，窗口大小会线性增加，而在发现丢包后，窗口会减小到 1，并把限定大小减半。

总的来说，流量控制 和 拥塞控制 各有其特点，都是为了优化网络数据传输而设计的。

速记

流控拥控有差异，应对侧重各不一。
流控针对速不同，收发失步防丢送。
滑动窗口来调控，发送接收量受控。
拥控解决网拥塞，注入过多负荷衰。
拥塞窗口显能耐，RTT内控包态。
拥塞避免线增长，丢包窗口即减量。
二者特点都很棒，优化传输有保障。

13，TCP 的拥塞控制采用了四种算法是什么？

TCP的拥塞控制采用了以下四种算法：

  1. **起始缓冲算法 **：也叫慢开始算法，慢开始算法在主机刚刚开始发送报文段时，先探测一下网络的拥塞程度，由小到大逐渐增加拥塞窗口的大小，这样可以避免一开始就发送过多的数据导致网络拥塞。
  2. 解除拥塞算法：也叫拥塞避免算法，让拥塞窗口缓慢地增大，每经过一个往返时间RTT就把发送方的拥塞窗口加1，而不是加倍，这样可以避免突然增加网络负载而导致拥塞的情况。
  3. 快重传算法：当发送方连续收到三个重复确认时，就立即重传对方尚未收到的报文段，而不必等待重传计时器到期，这样可以减少因为超时而导致的数据传输延迟。
  4. 快恢复算法：当发现有报文丢失时，并不会立刻进入慢启动状态，而是把慢开始门限减半，并重传丢失的报文段，然后把拥塞窗口设置为慢开始门限加三个报文段大小。这样可以避免因为超时而导致的拥塞窗口重新从1开始增长。

速记

TCP拥控有四招，网络畅通没烦恼。
起始缓冲慢慢搞，窗口渐大防拥牢。
解除拥塞别急躁，窗口缓增负荷小。
快重传时别傻等，仨确即发时延少。
快恢复来策略妙，减半重传窗口保。

黏包问题与解决方案

14，TCP 黏包问题

TCP 的黏包问题 主要发生在 发送端 和 接收端。

在 发送端，TCP 为了提高传输效率，通常会收集到足够多的数据后才进行发送。例如，如果连续几次发送的数据都很少，TCP 会将这些数据合成一包后一次性发送出去。这种情况下，接收方可能会在一次接收动作中收到两个或更多的数据包，从而产生 黏包现象。

在 接收端，如果接收方用户进程不及时接收数据，数据可能会存放在系统接收缓冲区中，而当新的数据到达时，如果前一包数据尚未被用户进程取走，新到的数据就会接到前一包数据之后，同样会产生 黏包现象。

TCP 是一个基于字节流的传输服务（UDP 基于报文的），“流” 意味着 TCP 所传输的数据是没有边界的。所以可能会出现两个数据包黏在一起的情况。

速记

TCP黏包两端现，发送接收藏隐患。
发送高效攒数据，多包合一一块传。
接收迟缓没处理，缓冲堆积黏一团。
字节流中无边界，黏包问题别犯难。

15 如何解决tcp的黏包问题

TCP 的黏包问题 是由于 TCP 协议为了提高传输效率而自动合并或拆分数据包导致的。为了解决这个问题，我们可以采取以下几种方法：

  1. 使用定长数据格式：在发送数据时，将每条数据都设置为固定长度，这样接收方就可以根据数据长度来判断每个数据包的边界，从而避免黏包问题。
  2. 使用分隔符：在发送数据时，在每个数据包之间添加一个特定的分隔符，这样接收方就可以根据分隔符来判断每个数据包的边界，从而避免黏包问题。
  3. 使用自定义协议：在发送数据时，将每条数据都封装成一个自定义的协议包，这样接收方就可以根据协议规定来判断每个数据包的边界，从而避免黏包问题。
  4. 使用 TCP_NODELAY 选项：在发送数据时，将 TCP_NODELAY 选项设置为 1，这样 TCP 协议就不会自动合并数据包，每个数据包都会单独发送，从而避免了黏包问题。
  5. 使用缓冲区：在接收数据时，使用缓冲区来缓存接收到的数据，并在应用程序中手动处理每个数据包的边界，从而避免了黏包问题。

总之，为了解决 TCP 的黏包问题，我们可以在发送数据时采取 定长数据格式、分隔符、自定义协议和 TCP_NODELAY 选项 等方法，或者在接收数据时 使用缓冲区 来处理每个数据包的边界。

速记

TCP黏包效率扰，解决方法真不少。
定长格式边界找，分隔符号来引导。
自定义包规则妙，NODELAY单独跑。
接收缓冲手动搞，黏包难题全赶跑。

16 什么是TCP粘包/拆包？发生的原因？

TCP 粘包/拆包 是指在网络传输过程中，TCP 协议将发送方的多个数据包合并成一个较大的数据包进行传输，或者将接收方的单个数据包拆分成多个较小的数据包进行处理。

TCP 粘包/拆包的原因 主要有以下几点：

  1. TCP 协议为了提高传输效率，通常会尽可能将多个数据包合并后一次性发送出去，这样可以减少网络中的数据包数量，减少网络拥塞，提高传输效率。
  2. TCP 协议在发送数据时，如果数据量较小，它会自动将这些数据合并成一个较大的数据包进行传输，这样可以减少网络中的数据包数量，提高传输效率。
  3. TCP 协议在接收数据时，如果接收缓冲区已满，新到达的数据包将被放在缓冲区队列中等待处理，而不会直接将数据包丢弃。因此，如果发送方连续发送多个数据包，接收方可能会一次性接收到多个数据包，从而产生拆包现象。
  4. TCP 协议在接收数据时，如果接收缓冲区已满，新到达的数据包将被放在缓冲区队列中等待处理，而不会直接将数据包丢弃。因此，如果发送方连续发送多个数据包，接收方可能会一次性接收到多个数据包，从而产生拆包现象。

总之，TCP 粘包/拆包现象 是在网络传输过程中不可避免的问题，TCP 协议通过一些机制来尽可能避免这一问题的出现，但用户仍然需要注意在应用程序中正确处理这些情况。

TCP 粘包/拆包问题 通常是由于 TCP 协议的传输机制导致的，为了解决这个问题，可以采取以下几种方法：

  1. 消息定长：规定固定大小的消息长度，例如每个报文大小固定为 200 字节。但是这种方法可能导致浪费或传输不完整的情况，使用起来并不理想。
  2. 使用特殊字符进行分割：例如 FTP 协议使用的是 ASCII 字符，用特定的字符表示消息的边界。但需要避免字符冲突，否则可能出现错误的消息拆分。
  3. 自定义协议：将消息分为消息头和消息体，消息头中包含消息总长度，这样服务端就可以知道每个数据包的具体长度了。
  4. 将消息分为消息头和消息尾。

以上方法都是在应用层对数据包进行处理，以解决 TCP 的粘包/拆包问题。但 最好的解决方案是使用 TCP 协议本身提供的功能，例如滑动窗口和流量控制机制，这些机制可以自动处理 TCP 粘包/拆包问题，使得数据传输更加可靠和高效。因此，在实际应用中，我们应该优先考虑使用 TCP 协议本身的功能来解决粘包/拆包问题。

速记

TCP传输有状况，粘包拆包常登场。
为提效率包合并，数据小了也同框。
接收缓冲若满仓，多包齐至易拆囊。
此问题呀难预防，解决方法要细想。
消息定长有短长，特殊字符需提防。
自定义协分头体，头头尾尾也无妨。

默认页脚
Copyright © 2025 CodeShouhu