欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 新闻 > 焦点 > 计算机网络常见面试题(一):TCP/IP五层模型、TCP三次握手、四次挥手,TCP传输可靠性保障、ARQ协议

计算机网络常见面试题(一):TCP/IP五层模型、TCP三次握手、四次挥手,TCP传输可靠性保障、ARQ协议

2024/12/26 22:27:46 来源:https://blog.csdn.net/qq_44700578/article/details/143577096  浏览:    关键词:计算机网络常见面试题(一):TCP/IP五层模型、TCP三次握手、四次挥手,TCP传输可靠性保障、ARQ协议

文章目录

  • 一、TCP/IP五层模型(重要)
  • 二、应用层常见的协议
  • 三、TCP与UDP
    • 3.1 TCP、UDP的区别(重要)
    • 3.2 运行于TCP、UDP上的协议
    • 3.3 TCP的三次握手、四次挥手
      • 3.3.1 TCP的三次握手
      • 3.3.2 TCP的四次挥手
      • 3.3.3 随机生成序列号的原因
  • 四、TCP传输可靠性保障
    • 4.1 保证传输的可靠性
    • 4.2 实现流量控制
      • 发送窗口
      • 接收窗口
    • 4.3 拥塞控制的实现
    • 4.4 ARQ协议
      • 停止等待ARQ协议
      • 连续ARQ协议
  • 五、ARP协议
    • 5.1 MAC地址
    • 5.2 ARP协议工作原理
      • 同一局域网内的MAC寻址
      • 不同局域网内的MAC地址

本文对于计算机面试、笔试过程中经常被问到的计算机网络类问题,做一个梳理总结,方便自己查看学习,同时也希望为其他找工作、学习的伙伴提供一个参考。

一、TCP/IP五层模型(重要)

在这里插入图片描述

TCP/IP五层模型:应用层、传输层、网络层、数据链路层、物理层

  • 应用层:为程序提供交互服务。在互联网中应用层协议有很多,如域名系统DNS、HTTP协议、SMTP协议
  • 传输层:负责向两台主机进程之间的通信提供数据传输服务。协议主要有传输控制协议TCP,用户数据协议UDP
  • 网络层:选择合适的路由和交换结点,确保数据及时传送,包括IP协议
  • 数据链路层:在两个相邻节点之间传送数据时,将网络层交下来的IP数据包组装成帧,在两个相邻节点间的链路上传送帧
  • 物理层:实现相邻节点间比特流的透明传输,尽可能屏蔽传输介质和物理设备差异

二、应用层常见的协议

HTTP(超文本传输协议):主要是为Web浏览器与Web服务器之间的通信而设计

SMTP(Simple Mail Transfer Protocol,简单邮件传输协议):电子邮箱的发送过程(我邮箱"1@qq.com”,向目标邮箱"2@qq.com"发生邮件)

  • 通过SMTP协议,将我写好的邮件交给163邮箱服务器(邮局)
  • 163邮箱服务器发现我发送的邮箱是qq邮箱,然后使用SMTP协议将我的邮件转发给qq邮箱服务器
  • qq邮箱服务器接收邮件后通知邮箱"2@qq.com"用户来收邮件,然后用户就通过POP3/IMAP协议将邮件取出

判断邮箱真正存在?

  1. 查找邮箱域名对应的SMTP服务器地址
  2. 尝试与服务器建立连接
  3. 连接成功后尝试向需要验证的邮箱发送邮件
  4. 根据返回结果判定邮箱地址的真实性

POP3/IMAP(两者都是负责邮件接收的协议)

FTP(文件传输协议):主要提供文件传输服务,基于TCP实现可靠的传输,传输过程可屏蔽操作系统和文件存储方式

基于客户-服务器模型而设计,在客户端、服务器之间建立两个连接

  • 控制连接:用于传送控制信息(命令和响应)
  • 数据连接:用于数据传送

Telnet(远程登陆协议)

  • 通过一个终端登录到其他服务器,建立在可靠的传输协议TCP之上
  • 缺点:所有数据(包括用户名、密码)均以明文形式发送,现如今正在被SSH所替代

SSH(安全的网络传输协议)

  • 建立在可靠的传输控制协议TCP之上。
  • 可防止信息泄露问题,专门用于远程登录会话和其他网络服务提供安全的协议

三、TCP与UDP

什么是TCP? TCP是传输控制协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议。

  • TCP:用于对传输准确性要求特别高的场景。如文件传输、发送和接收邮件、远程登录等
  • UDP:一般用于即时通信。如语音、视频、直播等

3.1 TCP、UDP的区别(重要)

TCPUDP
面向连接无连接
提供可靠服务不保证可靠交互
有状态无状态
面向字节流面向报文
传输效率较慢传输效率较快
有拥塞控制没有拥塞控制
每一条TCP连接只能是stron支持一对一、一对多、多对一、多对多
首部开销20字节首部开销8字节

3.2 运行于TCP、UDP上的协议

  • 运行于TCP之上的协议:HTTP、HTTPS、FTP、SMTP、POP3/IMAP、Telnet、SSH
  • 运行于UDP之上的协议
    • DHCP:动态主机配置协议,动态配置IP地址
    • DNS:域名系统(DNS,Domain Name System)将人类可读的域名(如www.baidu.com)转化为机器可读的IP地址(如220.181.38.148),可将其理解为专为互联网设计的电话簿。实际上DNS同时支持UDP、TCP

3.3 TCP的三次握手、四次挥手

3.3.1 TCP的三次握手

假设发送端为客户端,接收端为服务端。开始客户端、服务端的状态都是CLOSED

在这里插入图片描述

  • 第一次握手(无任何状态):客户端向服务端发起建立连接请求,客户端会随机生成一个起始序列号x,客户端向服务端发送的字段包含标志位SYN=1,序列号seq=x。第一次握手后客户端的状态为SYN-SENT。此时服务端的状态为LISTEN
  • 第二次握手(保证:客户端的发送能力、服务器的接收能力没问题):服务端在收到客户端发来的报文后,会随机生成一个服务端的起始序列号y,然后给客户端回复一段报文,标志位SYN=1,序列号seq=y,ACK=1,确认号ack=x+1。第二次握手后服务端的状态为SYN-RCVD(SYN=1表示要和客户端建立一个连接,ACK=1表示确认序号有效)
  • 第三次握手(保证:客户端的接收能力、服务器的发送能力没问题):客户端收到服务端发来的报文后,会再向服务端发送报文。ACK=1,序列号seq=x+1,确认号ack=y+1。客户、服务端状态变为ESTABLISTED。此时连接建立完成

A<–>B

  • 第一个包,即A发给B的SYN中途被丢,没有到达B

    • A会周期性超时重传,直到收到B的确认
  • 第二个包,即B发给A的SYN+ACK中途被丢,没有到达A

    • B会周期性超时重传,直到收到A的确认
  • 第三个包,即A发给B的ACK中途被丢,没有到达B ——A发完ACK,单方面认为TCP为Established状态,而B显然认为TCP为Active状态

    • a.假定此时双方都没有数据发送,B会周期性超时重传,直到收到A的确认
    • b.假定此时收到A的数据发送,B收到A的Data+ACK,自然切换到established状态,并接受A的Data
    • c.假定B有数据发送,数据发送不了,会一直周期性超时重传SYN+ACK,直到收到A的确认才可以发送数据

3.3.2 TCP的四次挥手

在这里插入图片描述

  • A的应用进程先向B发出连接释放报文段(FIN=1,Seq=u),并停止再发送数据,主动关闭TCP连接,进入FIN-WAIT-1状态。

  • B收到连接释放报文段后发送确认报文段(ACK=1,ack=u+1,seq=v),B进入CLOSE-WAIT状态,此时的TCP处于半关闭状态

  • A收到B的确认后,进入FIN-WAIT-2状态,等待B发出的连接释放报文段

  • B发送完数据,就发出连接释放报文段(FIN=1,seq=W,ACK=1,ack=u+1),B进入LAST-ACK状态

  • A收到B的连接释放报文段后,发出确认报文段(ACK=1,seq=u+1,ack=w+1),A进入TIME-WAIT状态。此时TCP未释放掉,需要经过时间等待计时器设置的2MSL(最大报文段生存时间)后,A进入C1OSE状态。B在收到A发出的确认报文段后关闭连接,若没收到则B会重传连接释放报文段

常见问题

1)四次挥手为什么要等待2MSL?
保证A发送的最后一个ACK报文段能够达到B。这个ACK报文段可能丢失,B收不到这个确认报文,就会超时重传连接释放报文段,A可以在这个2MSL时间内收到这个重传的连接释放报文段,接着A重传一次确认,并重新启动2MSL计时器,最后A和B都进入CLOSED状态。若A在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段立即进入CLOSED,则无法收到B重传的连接释放报文段,那么A不会再发一次确认报文段,B就无法正常进入CLOSED状态

2)为什么是四次挥手?
TCP是全双工通信,可以双向传输数据。任何一方都可以在数据传送结束后 发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了TCP连接。

举个例子,A和B打电话

  • 第一次挥手:A说“我没啥要说的了”
  • 第二次挥手:B回答“我知道了”,但是B可能还会有要说的话,A不能要求B跟着自己的节奏结束通话
  • 第三次挥手:于是B可能又巴拉巴拉说了一通,最后B说“我说完了”
  • 第四次挥手:A回答“知道了”,这样通话才算结束

3.3.3 随机生成序列号的原因

  • 提供安全性:防止TCP序列号预测攻击和会话劫持
  • 避免旧连接干扰:确保新旧连接的隔离,防止旧数据包干扰新连接
  • 增强网络可靠性:减少网络延迟和重新传输造成的混淆

四、TCP传输可靠性保障

4.1 保证传输的可靠性

1.基于数据块传输:应用数据被分割成TCP认为最适合发送的数据块,再传输给网络层,数据块被称为报文段或段。

2.对失序数据包重新排序以及去重:TCP为了保证不发生丢包,就给每个包一个序列号,有了序列号能够将接收到的数据根据序列号排序,并且去掉亚复序列号的数据就可以实现数据包去重。

3.校验和:TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。
4.重传机制:在数据包丢失或延迟的情况下,重新发送数据包,直到收到对方的确认应答(ACK)。TCP重传机制主要有:基于计时器的重传(也就是超时重传)、快速重传(基于接收端的反馈信息来引发重传)、SACK(在快速重传的基础上,返回最近收到的报文段的序列号范围,这样客户端就知道,哪些数据包已经到达服务器了)、D-SACK(重复SACK,在SACK的基础上,额外携带信息,告知发送方有哪些数据包自己重复接收了)。关于重传机制的详细介绍,可以查看详解TCP超时与重传机制这篇文章。

5.流量控制:TCP连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议(TCP利用滑动窗口实现流量控制)。

6.拥塞控制:当网络拥塞时,减少数据的发送。TCP在发送数据的时候,需要考虑两个因素:一是接收方的接收能力,二是网络的拥塞程度。接收方的接收能力由滑动窗口表示,表示接收方还有多少缓冲区可以用来接收数据。网络的拥塞程度由拥塞窗口表示,它是发送方根据网络状况自己维护的一个值,表示发送方认为可以在网络中传输的数据量。发送方发送数据的大小是滑动窗口和拥塞窗口的最小值,这样可以保证发送方既不会超过接收方的接收能力,也不会造成网络的过度拥塞。

4.2 实现流量控制

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

为什么需要流量控制? 这是因为双方在通信的时候,发送方的速率与接收方的速率是不一定相等,如果发送方的发送速率太快,会导致接收方处理不过来。如果接收方处理不过来的话,就只能把处理不过来的数据存在 接收缓冲区(Receiving Buffers) 里(失序的数据包也会被存放在缓存区里)。如果缓存区满了发送方还在狂发数据的话,接收方只能把收到的数据包丢掉。出现丢包问题的同时又疯狂浪费着珍贵的网络资源。因此,我们需要控制发送方的发送速率,让接收方与发送方处于一种动态平衡才好。

这里需要注意的是(常见误区):

  • 发送端不等同于客户端
  • 接收端不等同于服务端

TCP为全双工(Full-Duplex,FDX)通信,双方可以进行双向通信,客户端和服务端既可能是发送端又可能是服务端。因此,两端各有一个发送缓冲区与接收缓冲区,两端都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制(TCP传输速率不能大于应用的数据处理速率)。通信双方的发送窗口和接收窗口的要求相同

发送窗口

TCP发送窗口可以划分成四个部分:

  1. 已经发送并且确认的TCP段(已经发送并确认);
  2. 已经发送但是没有确认的TCP段(已经发送未确认);
  3. 未发送但是接收方准备接收的TCP段(可以发送);
  4. 未发送并且接收方也并未准备接受的TCP段(不可发送)

TCP发送窗口结构图示:

在这里插入图片描述

接收窗口

TCP接收窗口可以划分成三个部分:

  1. 已经接收并且已经确认的TCP段(已经接收并确认);
  2. 等待接收且允许发送方发送TCP段(可以接收未确认);
  3. 不可接收且不允许发送方发送TCP段(不可接收)

TCP接收窗口结构图示:

在这里插入图片描述

接收窗口的大小是根据接收端处理数据的速度动态调整的。 如果接收端读取数据快,接收窗口可能会扩大。否则,它可能会缩小。

另外,这里的滑动窗口大小只是为了演示使用,实际窗口大小通常会远远大于这个值。

4.3 拥塞控制的实现

在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。

  • 拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。
  • 拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

在这里插入图片描述

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

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

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

4.4 ARQ协议

自动重传请求(Automatic Repeat-reQuest,ARQ)是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时两个机制,在不可靠服务的基础上实现可靠的信息传输。若发送方在发送一段时间内没有收到确认信息(ACK),它通常会重新发送,直到收到确认或重试超过一定的次数

ARQ包括停止等待ARQ、连续ARQ协议

停止等待ARQ协议

停止ARQ协议:实现可靠传输。它的基本原理是每发完一个分组就停止发送,等待对方确认(回复ACK),若过了一段时间还是没收到ACK确认,就说明没有发送成功,需要重新发送,直到收到确认后再发下一个分组;若接收方收到重复分组,就丢弃该分组,但同时还有发送确认

  • 无差错情况:发送方发送分组,接收方再规定时间内收到,并且回复确认,发送方再次发送
  • 出现差错情况(超时重传):超过一段时间没有收到确认,就重传前面发送过的分组。因此每发送完一个分组需要设置一个超时计时器,其重传时间应比数据再分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求ARQ
  • 确认丢失和确认迟到
    • 确认丢失:确认消息在传输过程中丢失。A发送M1给B,B收到并发送确认,却在传输过程中丢失。A并不知道,在超时计时后,A重传M1消息,B再次收到该消息后采取以下两点措施
      • 丢弃这个重复的M1消息,不向上层交付
      • 向A发送确认消息
    • 确认迟到:确认消息在传输过程中迟到。A发送M1给B,B收到并发送确认,在超时时间内A没收到确认,A重传M1,B收到并继续发送确认(B收到两份M1)。此时A收到B第二次发送的确认。过了一会,A收到B收到的第一次发送的确认(A也收到了两份确认),处理如下
      • A收到重复确认后直接丢弃
      • B收到重复M1后,也直接丢弃重复的M1

连续ARQ协议

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

  • 优点:信道利用率高,容易实现,即使确认丢失,也不必重传
  • 缺点:不能向发送方反映出接收方已经正确收到的所有分组信息。比如:发送方发送了5条信息,中间第三条丢失,接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,只好把后三个全部重传一次,这也叫Go-Back-N(回退N),表示需要退回来重传已经发送过的N个消息

五、ARP协议

每当我们学习一个新的网络协议的时候,都要把他结合到OSI七层模型中,或者是TCP/IP协议栈中来学习,一是要学习该协议在整个网络协议栈中的位置,二是要学习该协议解决了什么问题,地位如何?三是要学习该协议的工作原理,以及一些更深入的细节。

ARP协议,可以说是在协议栈中属于一个偏底层的、非常重要的、又非常简单的通信协议。

开始阅读这篇文章之前,你可以先看看下面几个问题:

  1. ARP协议在协议栈中的位置?ARP协议在协议栈中的位置非常重要,在理解了它的工作原理之后,也很难说它到底是网络层协议,还是链路层协议,因为它恰恰串联起了网络层和链路层。国外的大部分教程通常将ARP协议放在网络层。
  2. **ARP协议解决了什么问题,地位如何?ARP协议,全称 ** 地址解析协议(Address Resolution Protocol),它解决的是网络层地址和链路层地址之间的转换问题。因为一个IP数据报在物理上传输的过程中,总是需要知道下一跳(物理上的下一个目的地)该去往何处,但IP地址属于逻辑地址,而 MAC地址才是物理地址,ARP 协议解决了 IP地址转 MAC地址的一些问题。
  3. ARP工作原理? 只希望大家记住几个关键词:ARP表、广播问询、单播响应

5.1 MAC地址

MAC全称 媒体访问控制地址(Media Access Control Address):如果说互联网中每一个资源都由IP地址唯一标识(IP协议内容),那么一切网络设备都由MAC地址唯一标识

可以理解为,MAC地址是一个网络设备真正的身份证号,IP地址只是一种不重复的定位方式(比如说
住在某省某市某街道的张三,这种逻辑定位是IP地址,他的身份证号才是他的MAC地址),也可以
理解为 MAC 地址是身份证号,IP地址是邮政地址。MAC 地址也有一些别称,如LAN地址、物理地
址、以太网地址等。MAC地址具有可携带性、永久性

5.2 ARP协议工作原理

ARP协议工作时有一个大前提,那就是ARP表

在一个局域网内,每个网络设备都自己维护了一个ARP表,ARP表记录了某些其他网络设备的IP地址-MAC地址映射关系,该映射关系以<IP,MAC,TTL>三元组的形式存储。其中,TTL为该映射关系的生存周期,典型值为 20分钟,超过该时间,该条目将被丢弃。

  • 每台主机都会在自己的ARP缓冲区中建立一个ARP列表,以表示IP地址和MAC地址的对应关系。
  • 当源主机需要将一个数据包要发送到目的主机时,会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址,如果有,就直接将数据包发送到这个MAC地址;如果没有,就向本地网段发起一个ARP请求的广播包,查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、MAC地址、以及目的主机的IP地址。
  • 网络中所有的主机收到这个ARP请求后,会检查数据包中的目的IP是否和目己的IP地址一致。如果不相同就忍略此数据包;如果相同,该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中,如果ARP表中已经存在该IP的信息,则将其覆盖,然后给源主机发送一个ARP响应数据包,告诉对方自己是它需要查找的MAC地址,
  • 源主机收到这个ARP响应数据包后,将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中,并利用此信息开始数据的传输。
  • 如果源主机一直没有收到ARP响应数据包,表示ARP查询失败

ARP的工作原理将分两种场景讨论:

  1. 同一局域网内的MAC寻址;
  2. 从一个局域网到另一个局域网中的网络设备的寻址。

同一局域网内的MAC寻址

假设当前有如下场景:IP地址为137.196.7.23 的主机A,想要给同一局域网内的IP 地址为137.196.7.14主机B,发送IP数据报文。

再次强调,当主机发送IP数据报文时(网络层),仅知道目的地的IP地址,并不清楚目的地的MAC地址,而ARP协议就是解决这一问题的。

为了达成这一目标,主机A将不得不通过ARP协议来获取主机B的MAC地址,并将IP报文封装成链路层帧,发送到下一跳上。在该局域网内,关于此将按照时间顺序,依次发生如下事件:

  1. 主机 A 检索自己的 ARP 表,发现 ARP 表中并无主机 B 的 IP 地址对应的映射条目,也就无从知道主机 B 的MAC地址.

  2. 主机A 将构造一个ARP 查询分组,并将其广播到所在的局域网中。

    ARP分组是一种特殊报文,ARP分组有两类,一种是查询分组,另一种是响应分组,它们具有相同的格式,均包含了发送和接收的IP地址、发送和接收的 MAC地址。当然了,查询分组中,发送的IP地址,即为主机A的 IP 地址,接收的 IP 地址即为主机 B 的IP 地址,发送的 MAC 地址也是主机A的 MAC 地址,但接收的MAC地址绝不会是主机B的MAC地址(因为这正是我们要问询的!),而是一个特殊值一一FF-FF-FF-FF-FF-FF,之前说过,该MAC地址是广播地址,也就是说,查询分组将广播给该局域网内的所有设备。

  3. 主机A构造的查询分组将在该局域网内广播,理论上,每一个设备都会收到该分组,并检查查询分组的接收IP地址是否为自己的IP地址,如果是,说明查询分组已经到达了主机B,否则,该查询分组对当前设备无效,丢弃之。

  4. 主机 B 收到了查询分组之后,验证是对自己的问询,接着构造一个ARP 响应分组,该分组的目的地只有一个一一主机A,发送给主机A。同时,主机B 提取查询分组中的IP 地址和MAC 地址信息,在自己的ARP 表中构造一条主机A的IP-MAC映射记录。

    ARP 响应分组具有和 ARP 查询分组相同的构造,不同的是,发送和接受的 IP 地址恰恰相反,发送的 MAC地址为发送者本身,目标MAC地址为查询分组的发送者,也就是说,ARP响应分组只有一个目的地,而非广播。

  5. 主机A 终将收到主机B的响应分组,提取出该分组中的IP地址和MAC 地址后,构造映射信息,加入到自己的 ARP 表中。

在这里插入图片描述

在整个过程中,有几点需要补充说明的是:

  1. 主机A 想要给主机B 发送IP数据报,如果主机B的IP-MAC映射信息已经存在于主机A的ARP表中,那么主机A无需广播,只需提取MAC地址并构造链路层帧发送即可。
  2. ARP表中的映射信息是有生存周期的,典型值为20分钟。
  3. 目标主机接收到了问询主机构造的问询报文后,将先把问询主机的IP-MAC映射存进自己的ARP表中,这样才能获取到响应的目标 MAC地址,顺利的发送响应分组。

总结来说,ARP协议是一个广播问询,单播响应协议。

不同局域网内的MAC地址

更复杂的情况是,发送主机A和接收主机B不在同一个子网中,假设一个一般场景,两台主机所在的子网由一台路由器联通。这里需要注意的是,一般情况下,我们说网络设备都有一个IP地址和一个MAC 地址,这里说的网络设备,更严谨的说法应该是一个接口路由器作为互联设备,具有多个接口,每个接口同样也应该具备不重复的 IP 地址和 MAC地址。因此,在讨论 ARP 表时,路由器的多个接口都各自维护一个 ARP 表,而非一个路由器只维护一个ARP 表。

接下来,回顾同一子网内的MAC寻址,如果主机A发送一个广播问询分组,那么A所在的子网内所有设备(接口)都将会捕获该分组,因为该分组的目的IP与发送主机A的IP在同一个子网中。但是当目的IP与A不在同一子网时,A所在子网内将不会有设备成功接收该分组。那么,主机A应该发送怎样的查询分组呢?整个过程按照时间顺序发生的事件如下:

  1. 主机A 查询ARP表,期望寻找到目标路由器的本子网接口的MAC地址。

    目标路由器指的是,根据目的主机B的IP地址,分析出B所在的子网,能够把报文转发到B所在子网的那个路由器。

  2. 主机A未能找到目标路由器的本子网接口的MAC地址,将采用ARP协议,问询到该MAC地址,由于目标接口与主机A在同一个子网内,该过程与同一局域网内的MAC寻址相同。

  3. 主机A 获取到目标接口的MAC 地址,先构造IP数据报,其中源IP是A的IP 地址,目的IP地址是B的IP地址,再构造链路层帧,其中源MAC地址是A的MAC地址,目的MAC地址是本子网内与路由器连接的接口的MAC地址。主机A将把这个链路层帧,以单播的方式,发送给目标接口。

  4. 目标接口接收到了主机A 发过来的链路层帧,解析,根据目的IP 地址,查询转发表,将该IP 数据报转发到与主机B所在子网相连的接口上。

    到此,该帧已经从主机A所在的子网,转移到了主机B 所在的子网了。

  5. 路由器接口查询ARP 表,期望寻找到主机 B 的 MAC 地址。

  6. 路由器接口如未能找到主机 B 的 MAC 地址,将采用 ARP 协议,广播问询,单播响应,获取到主机 B 的MAC 地址.

  7. 路由器接口将对IP数据报重新封装成链路层帧,目标MAC地址为主机B的MAC地址,单播发送,直到目的地。

在这里插入图片描述

参考 JavaGuide(Java面试+学习指南)

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com