计算机网络基础知识及面试总结-这应该是最全的了

计算机网络基础知识及面试总结

原先的整理，在经过多次面试之后发现其中许多内容冗余不实用，加上缺乏的部分，更新这了这篇博客，尤其新增了关于IP地址的计算，改头换面荣誉登场~

1 基本概念

1.1 TCP/IP协议栈，OSI参考模型

1.2 简要的介绍各层的作用

• 应用层是面向用户的软件，提供各种协议下的服务。分为服务端、客户端。用户控制软件，发出相关的服务请求，形成相应的进程、数据。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文。
• 计算机用端口号标识，进入传输层基于相关的TCP/UDP协议发送。向两台主机进程之间的通信提供通用的数据传输服务
• 网络层选择相关的路由，网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。
• 数据链路层将数据在线路上传输， 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
• 最后物理层实现最后的交互，实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。

1.3 常见的协议

• 应用层：常见协议：
  • HTTP(80端口)：超文本传输协议
  • DNS(53端口)：运行在UDP上，域名解析服务
  • FTP(21端口)：文件传输协议
  • SSH(22端口)：远程登陆
  • TELNET(23端口)：远程登录
  • SMTP(25端口)：发送邮件
  • POP3(110端口)：接收邮件
• 传输层：TCP/UDP，SSL协议**（https基于此加密）**
• 网络层：IP、ARP、RIP、ICMP**（ping的协议）**

2 应用层

2.1 HTTP请求有哪些常见状态码？

1. 2xx状态码：操作成功。200 OK
2. 3xx状态码：重定向。301 永久重定向；302暂时重定向
3. 4xx状态码：客户端错误。400 Bad Request；401 Unauthorized；403 Forbidden；404 Not Found；
4. 5xx状态码：服务端错误。500服务器内部错误；501服务不可用，502 网关错误，504网关超时

2.2 常见的HTTP方法

GET与POST的区别？

GET“读取“一个资源。比如Get到一个html文件。反复读取不应该对访问的数据有副作用。post，比如提交表单，一般会有影响，不能缓存

• GET是幂等的，读取同一个资源得到相同的数据，POST不是幂等的；GET在浏览器回退时是无害的，而POST会再次提交请求。

• GET 一般用于获取/查询资源信息，而 POST 一般用于更新资源信息

• GET参数通过URL传递，POST放在Request body中。

• 安全性：GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• GET只允许ASCII字符，POST对数据类型没有要求

• GET的长度有限制（操作系统或者浏览器），而POST数据大小无限制

2.3 http客户端和服务端如何建立请求

1、TCP三次握手，建立连接

2、Web浏览器向Web服务器发送请求命令，例如：GET/sample/hello.jsp HTTP/1.1

3、 Web浏览器发送请求头信息，描述浏览器自己. 之后浏览器发送了一空白行来通知服务器, 表示它已经结束了该头信息的发送. 若是post请求, 还会在发送完请求头信息之后发送请求体.

4、Web服务器应答， HTTP/1.1 200 OK 协议的版本号和状态码+描述

5、Web服务器发送应答头信息，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档.

6、 Web服务器向浏览器发送数据，以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

7、Web服务器关闭TCP连接

2.4 http和https的区别

2.5 Session与Cookie的区别？

Session是服务器端保持状态的方案，Cookie是客户端保持状态的方案

浏览器打开一个网页，用到的是HTTP协议，它是无状态的，这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。好处是快速，但是不方便，于是基于这种需求就出现了Cookie.

Cookie

• 帮助web站 保留访问者信息的技术，存储在用户电脑上的小文件，保存一些站点的用户数据。
• 可以通过HTTP响应头set cookie来设置，Cookie是按照网站来进行组织和保存的，保存之后，浏览器向这个网站发出的请求会携带这些Cookie，然后后台就可以分析这些Cookie。
• 比如：免用户名登录。第一次登录成功之后，服务器给浏览器发送了用户名和密码的cookie，浏览器存储，下一次浏览器又要登录时，在发送请求头的时候一起把cookie发送给服务器，服务器解析出直接填入用户名和密码实现免用户名登录。

Cookie虽好，但是存在于用户端，存储的尺寸大小有限，用户可见，并可以随意的修改，很不安全。那如何又要安全，又可以方便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：Session 诞生了。

会话：打开浏览器到关闭浏览器的这个过程

客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

• Session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID 为标识符来存取服务器端的Session存储空间。
• 而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一 SessionID提交到服务器端，来存取Session数据。

2.6 从输入网址到获得页面的过程 (越详细越好)？

1. 在浏览器中输入www.baidu.com域名，操作系统会先检查自己本地的hosts文件是否有这个域名的映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2. 如果hosts文件中没有，则查询本地DNS解析器缓存，如果有，则完成地址解析。
3. 如果本地DNS解析器缓存中没有，则去查找本地DNS服务器，如果查到，完成解析。
4. 如果没有，则本地服务器会向根域名服务器发起查询请求。根域名服务器会告诉本地域名服务器去查询哪个顶级域名服务器。
5. 本地域名服务器向顶级域名服务器发起查询请求，顶级域名服务器会告诉本地域名服务器去查找哪个权限域名服务器。
6. 本地域名服务器向权限域名服务器发起查询请求，权限域名服务器告诉本地域名服务器www.baidu.com所对应的IP地址。
7. 本地域名服务器告诉主机www.baidu.com所对应的IP地址。

2.7 讲一下https的认证授权

超文本传输协议 (HTTP) 是一个用来通过互联网传输和接收信息的协议。HTTP 使用请求/响应的过程，因此信息可在服务器间快速，但 HTTP 是不安全的，可以轻松对窃听你跟 Web 服务器之间的数据传输。

HTTPS 是基于安全套接字层的超文本传输协议。HTTPS 在 HTTP 应用层的基础上使用安全套接字层作为子层。

1. 对称加密算法， 加密和解密用的是同一个密钥

如果我把密钥发给你， 也被他截取了， 那加密岂不白费工夫？这个加密解密算法需要的密钥双方必须得知道啊， 但是密钥又无法通过网络发送

2. 非对称加密算法，有一对钥匙：私钥+公钥，用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据， 只有对应的私钥才能解密

3 、中间人攻击，非对称加密算法比之前的对称密钥算法要慢很多，所以考虑只用非对称加密算法去传输对称算法的秘钥，再用对称算法的秘钥进行加密传输。但是出现一个问题

4 、所以现在问题变成了怎么证明这个公钥就是对方的。

在网络世界也可以建立一个这样的具备公信力的认证中心， 这个中心给大家颁发一个证书， 用于证明一个人的身份。

5 、但是证书怎么安全传输？ 要是证书传递的过程中被篡改了怎么办？

Bill可以把他的公钥和个人信息用一个Hash算法生成一个消息摘要，但是如果整个消息摘要都被替换了，一样起不到作用。

6 、“数字证书”

认证中心（简称CA）用它的私钥对消息摘要加密，形成签名： 还把原始信息和数据签名合并， 形成一个全新的东西，叫做“数字证书”，当Bill把他的证书发给我的时候， 我就用同样的Hash 算法， 再次生成消息摘要，然后用CA的公钥对数字签名解密， 得到CA创建的消息摘要， 两者一比，就知道有没有人篡改了！

3 传输层

传输层提供 应用进程之间，发送端端口到接收端端口之间的服务，要进行差错检验、流量控制、面向连接或无连接的服务

• 用户数据报协议UDP：不建立连接，尽最大努力交付，不保证接收

• 数据传输协议TCP：网络尽最大努力交付数据，但不保证不丢失、不保证先后顺序、不保证在时限内交付；网络发生拥塞时，可能会将一些分组丢弃；

3.1 TCP传输连接三阶段：连接建立、数据传送、连接释放

3.1.1 三次握手建立连接

第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态；
第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态；
第三次握手：客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和acknowledge number为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。

---

TCP建立连接可以两次握手吗？为什么?

• 首先，可能会出现已失效的连接请求报文段又传到了服务器端。

client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。

• 其次，两次握手无法保证Client正确接收第二次握手的报文（Server无法确认Client是否收到），也无法保证Client和Server之间成功互换初始序列号。

---

可以采用四次握手吗？为什么？

可以。但是会降低传输的效率。

四次握手是指：第二次握手：Server只发送ACK和acknowledge number；而Server的SYN和初始序列号在第三次握手时发送；原来协议中的第三次握手变为第四次握手。出于优化目的，四次握手中的二、三可以合并。

---

第三次握手中，如果客户端的ACK未送达服务器，会怎样？

• Server端：

由于Server没有收到ACK确认，因此会重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。

• Client端，两种情况：

在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK number，进入 establish 状态
在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

如果已经建立了连接，但客户端出现了故障怎么办？

服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

初始序列号是什么？

TCP连接的一方A，随机选择一个32位的序列号（Sequence Number）作为发送数据的初始序列号（Initial Sequence Number，ISN），比如为1000，以该序列号为原点，对要传送的数据进行编号：1001、1002…三次握手时，把这个初始序列号传送给另一方B，以便在传输数据时B可以确认什么样的数据编号是合法的；同时在进行数据传输时，A还可以确认B收到的每一个字节，如果A收到了B的确认编号（acknowledge number）是2001，就说明编号为1001-2000的数据已经被B成功接受。

---

3.1.2 传输数据

1、滑动窗口

• 客户端通过TCP首部告知服务端自己的接收缓存大小，相互告知对方自己的接受缓存大小，让对方设置相应的发送缓存大小
• 服务端设置自己的发送窗口大小，开始发送数据，每次发的数据大小可以不一致，当窗口中还有未发送的数据时，可以一直发数据，但是因为为收到确认，所以不能删除。
• 客户端收到之后，并非收一个确认一个，而是发累计确认号，发送确认号=收到的数据包编号+1，发送过确认号之后，客户端的接收窗口滑动右移
• 服务端收到确认号，窗口右移，删除已经发送的数据包，读取新的内容进窗口进行发送
• 有丢包7-9的情况之下，发送相关的确认号7，再加一个选择性确认号SACK告诉10-12已经收到，让服务端知道丢了什么包，重传丢包

2、拥塞控制——针对整个网络通路的控制

拥塞：路由器忙不过来，给的数据包越多，收到的数据包越少

拥塞控制主要由四个算法组成：慢开始、拥塞避免、快重传、快恢复

---

1.慢开始：指数增大

2.拥塞避免：线性增大

当出现网络拥塞之后，重新计算慢开始门限：出现网络拥塞窗口大小的一半

---

3.快重传
客户端确认丢包之后比如收到了1 2 4，就知道丢了3 ，此时不等待接受的窗口大小 5 填满数据，直接连发三个确认号，让服务端重发丢包3。收到快重传之后进入快恢复的阶段，不再从零开始。而是直接从新的慢开始门限阈值开始

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

4. 快恢复：
当发送方连续收到三个重复确认时，就把慢开始门限减半，然后执行拥塞避免算法。不执行慢开始算法的原因：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方认为现在网络可能没有出现拥塞。

3.1.3 四次挥手断开连接

第一次挥手：Client将FIN置为1，发送一个序列号seq给Server；进入FIN_WAIT_1状态；
第二次挥手：Server收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1；进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。
第三次挥手：Server将FIN置1，发送一个序列号给Client；进入LAST_ACK状态；
第四次挥手：Client收到服务器的FIN后，进入TIME_WAIT状态；接着将ACK置1，发送一个acknowledge number=序列号+1给服务器；服务器收到后，确认acknowledge number后，变为CLOSED状态，不再向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手。

为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手（CLOSE_WAIT状态意义是什么）？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送。

如果第二次挥手时服务器的ACK没有送达客户端，会怎样？

客户端没有收到ACK确认，会重新发送FIN请求。

客户端TIME_WAIT状态的意义是什么？

第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果Server没有收到ACK，就会重发FIN，如果Client在2*MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。

MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

什么时候会出现很多CLOSE_WAIT状态码，CLOSE_WAIT状态码是正常的吗？

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。

3.1.4 什么是TCP粘包/拆包问题

TCP以流方式传输，是没有界限的一串数据，并没有消息边界。

• TCP传输数据时，会根据底层的TCP缓存区实际情况进行数据包划分：
• 1.业务上定义的完整数据(比方说一个完整的json串)，可能会被TCP拆分成多个数据包进行发送(拆包)
• 2.业务上特殊含义的独立数据，也有可能因为大小或者缓冲区原因，被TCP封装成一个大数据包发送(粘包)。

通过图我们可以发现，数据包接收有很多情况：

1. 没有粘包拆包，终端2收到了完整的数据包A和数据包B。
2. 终端2一次性读取到数据包A和数据包B，这就是粘包。
3. 终端2读取到完整的数据包A和部分数据包B1,第二次才读取到数据包B剩余部分(数据包B2),这就是拆包
4. 类似第三点，数据包A也有可能分成两部分(A1、A2), 被前后读取。
5. 假设数据包很大，那么可能产生多次拆包，如数据包A分N次被读取

TCP粘包/拆包解决策略

由于TCP无法理解上一层的业务数据特点，所以TCP是无法保证发送的数据包不发生粘包和拆包，这个问题只能通过上层的协议栈设计来解决，解决思路有一下几种：

• 消息定长。每个发送的数据包大小固定，比如100字节，不足100字节的用空格补充，接受方取数据的时候根据这个长度来读取数据
• 消息末尾增加换行符来表示一条完整的消息。接收方读取的时候根据换行符来判断是否是一条完整的消息。如果消息的内容也包含换行符，那么这种方式就不合适了。
• 将消息分为消息头和消息尾两部分，消息头指定数据长度，根据消息长度来读取完整的消息。例如UDP协议是这么设计的，用两个字节来表示消息长度，所以UDP不存在粘包和拆包问题。

3.1.5 TCP如何保证无差错？有哪些控制算法？

TCP通过首部检验、失序重排、丢弃重复、序列号和确认应答机制、超时重传、流量控制、拥塞控制

1、通过序列号识别是否已经接收数据并且保证顺序，扔掉重复的数据包，从而实现可靠传输。所以，即使产生了丢包、重复，TCP仍然能实现可靠传输。

2、序列号和确认应答信号。发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知，这个消息叫做确认应答（ACK）=收到的序列号+1，如果在一定时间内发送端都没有得到确认应答ACK，发送端就会认为数据丢失，并进行超时重传。

3、超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

4、流量控制： 利用滑动窗口实现流量控制，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度。早期：发送方发送一个包1，这时候接收方确认包1。发送包2，确认包2。吞吐量非常的低。为了增大吞吐量，连发几个包等他一起确认，那么如何实现连发几个包的最优解？就是滑动窗口算法。

3.2 TCP与UDP的区别

1. **TCP是面向连接的，UDP是无连接的；**什么叫无连接？UDP发送数据之前不需要建立连接
2. TCP是可靠的，UDP不可靠；什么叫不可靠？UDP接收方收到报文后，不需要给出任何确认
3. TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多；
4. TCP是面向字节流的，UDP是面向报文的；
   面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。
5. TCP有拥塞控制机制,UDP没有。网络出现的拥塞不会使源主机的发送速率降低，这对某些实时应用是很重要的，比如媒体通信，游戏；
6. TCP首部开销（20字节）比UDP首部开销（8字节）要大
7. UDP 的主机不需要维持复杂的连接状态表

对某些实时性要求比较高的情况，选择UDP，比如游戏，媒体通信，实时视频流（直播），即使出现传输错误也可以容忍；
其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失，比如HTTP不可以使用UDP，HTTP需要基于可靠的传输协议，而UDP不可靠

3.2.1 什么协议是基于UDP传输？

使用UDP协议端口常见的有：

（1）RIP：路由选择信息协议（RIP）是一种在网关与主机之间交换路由选择信息的标准

（2） DNS：用于域名解析服务，这种服务在Windows NT系统中用得最多的。因特网上的每一台计算机都有一个网络地址与之对应，这个地址是常说的IP地址，它以纯数字+"."的形式表示。然而这却不便记忆，于是出-现了域名，访问计算机的时候只需要知道域名，域名和IP地址之间的变换由DNS服务器来完成。DNS用的是53号端口。
（3） SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
（4） OICQ：OICQ程序既接受服务，又提供服务，这样两个聊天的人才是平等的。OICQ用的是无连接的协议，也是说它用的是UDP协议。OICQ服务器是使用8-000号端口，侦听是否有信息到来，客户端使用4000号端口，向外发送信息。如果上述两个端口正在使用（有很多人同时和几个好友聊天），就顺序往上加。

4 网络层

4.1 IPV4 （32位）和IPV6（128位）

4.2 A B C三类地址

IP地址包含 网络地址+主机地址，即IP地址=网络地址+主机地址

网络地址:同一网络上的网络号相同，也叫划分子网

IP地址中：

• 全为0 表示是主机地址，即是这个网络中的所有主机的地址；
• 全为1表示是广播地址，即是向这个网络中所发送广播的地址，把网络地址中的主机为全换成1

C类地址最多可以放多少台主机，哪些地址不可用，分别用作什么？

A类IP地址的子网掩码为255.0.0.0

B类IP地址的子网掩码为255.255.0.0

C类IP地址的子网掩码为255.255.255.0

子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。

通过子网掩码，就可以判断两个IP在不在一个局域网内部。

子网掩码可以看出有多少位是网络号，有多少位是主机号

已知一个ip地址是192.168.1.1，子网掩码是255.255.255.0，那么它的网络地址是多少？

已知某主机的ip地址是192.168.100.200，子网掩码为255.255.255.192，其网络内可用的ip地址个数为多少？

一个A类ip地址的子网掩码是255.255.240.0，共有几位被用来划分子网？****且可以划分多少个子网？每个子网ip地址数量是多少？

IP地址为：10.135.255.19子网掩码为255.255.255.248的广播地址是什么？

4.3 什么是ARP协议：地址解析协议(广播机制)

ARP协议完成了IP地址与物理地址的映射。每一个主机都设有一个 ARP 高速缓存，里面有所在的局域网上的各主机和路由器的 IP 地址到硬件地址的映射表。

当源主机要发送数据包到目的主机时，会先检查自己的ARP高速缓存中有没有目的主机的MAC地址，如果有，就直接将数据包发到这个MAC地址

如果没有，就向所在的局域网发起一个ARP请求的广播包: APR请求：我是 209.0.0.5，硬件地址是 00-00-C0-15-AD-18,我想知道主机 209.0.0.6 的硬件地址，收到请求的主机检查自己的IP地址和目的主机的IP地址是否一致，如果一致，则先保存源主机的映射到自己的ARP缓存，然后给源主机发送一个ARP响应数据包。APR响应：我是 209.0.0.6，硬件地址是 08-00-2B-00-EE-0A

源主机收到响应数据包之后，先添加目的主机的IP地址与MAC地址的映射，再进行数据传送。如果源主机一直没有收到响应，表示ARP查询失败。

如果所要找的主机和源主机不在同一个局域网上，那么就要通过 ARP 找到一个位于本局域网上的某个路由器的硬件地址，然后把分组发送给这个路由器，让这个路由器把分组转发给下一个网络。剩下的工作就由下一个网络来做。