输入www.taobao.com会发生什么？
最后关闭TCP连接
计算机网络的各层协议及作用
分为一下三种，OSI七层模型、TCP/IP四层模型和五层模型。
- OSI七层模型：大而全，但是比较复杂、而且是先有了理论模型，没有实际应用。
- TCP/IP四层模型：是由实际应用发展总结出来的，从实质上讲，TCP/IP只有最上面三层，最下面一层没有什么具体内容，TCP/IP参考模型没有真正描述这一层的实现。
- 五层模型：五层模型只出现在计算机网络教学过程中，这是对七层模型和四层模型的一个折中，既简洁又能将概念阐述清楚。
七层网络体系结构各层的主要功能：
- 应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等。
- 表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。
- 会话层：负责在网络中的两节点之间建立、维持和终止通信，如服务器验证用户登录便是由会话层完成的。
- 运输层：有时也译为传输层，向主机进程提供通用的数据传输服务。该层主要有以下两种协议：
- TCP：提供面向连接的、可靠的数据传输服务；
- UDP：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性。
- SCTP：网络连接两端之间同时传输多个数据流的协议。
- 网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
- 数据链路层：数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧，并再相邻节点的链路上传送帧。
- 物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。
UDP 和 TCP 对应的应用场景
TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：
- FTP文件传输（20传数据，21连接）
- HTTP / HTTPS
- SMTP（发邮件，25端口）
- POP3（收邮件，110端口）
UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：
- 包总量较少的通信，如 DNS（53端口） 、SNMP（管理网络，161端口）等
- 视频、音频等多媒体通信
- 广播通信
为什么需要三次握手，而不是两次
防止已过期的连接请求报文突然又传送到服务器，因而产生错误和资源浪费。
在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段。
客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到 确认报文后也进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。
此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。
三次握手才能让双方均确认自己和对方的发送和接收能力都正常。
第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；
第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；但服务器不知道客户端接受正不正常
第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。
告知对方自己的初始序号值，并确认收到对方的初始序号值。
TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。
SYN洪泛攻击？如何防范
SYN洪泛攻击属于 DOS 攻击的一种，它利用 TCP 协议缺陷，通过发送大量的半连接请求，耗费 CPU 和内存资源。
- 过滤网关防护。
- 通过加固 TCP/IP 协议栈防范，如增加最大半连接数，缩短超时时间。
- SYN cookies技术。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改，专门用来防范 SYN 洪泛攻击的一种手段。
DDoS则是采用分布式的方法，通过在网络上占领多台“肉鸡”，用多台计算机发起攻击。
DOS攻击现在基本没啥作用了，因为服务器的性能都很好，而且是多台服务器共同作用，1V1的模式黑客无法占上风。对于DDOS攻击，预防方法有：
- 减少SYN timeout时间。在握手的第三步，服务器会等待30秒-120秒的时间，减少这个等待时间就能释放更多的资源。
- 限制同时打开的SYN半连接数目。
XSS攻击
XSS也称 cross-site scripting，跨站脚本。这种攻击是由于服务器将攻击者存储的数据原原本本地显示给其他用户所致的。比如一个存在XSS漏洞的论坛，用户发帖时就可以引入带有＜script＞标签的代码，导致恶意代码的执行。
预防措施有：
前端：过滤。
后端：转义，比如go自带的处理器就具有转义功能。
三次握手的第三个ACK包丢了
服务端：
第三次的ACK在网络中丢失，那么服务端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便客户端重新发送ACK包。
如果重发指定次数之后，仍然未收到 客户端的ACK应答，那么一段时间后，服务端自动关闭这个连接。
客户端：
客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包（Reset，标示复位，用于异常的关闭连接）响应。此时，客户端知道第三次握手失败。
为什么一定要TIME-WAIT
- 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接
- 防止已失效的连接请求报文段出现在之后的连接中
存在TIME-WAIT一定保证正常关闭么
如果TIME-WAIT发送地ACK丢失，服务器超时重发FIN也丢失，则进入CLOSED阶段
如果已经建立了连接，但是客户端出现故障了怎么办
通过定时器 + 超时重试机制，尝试获取确认，直到最后会自动断开连接
具体而言，TCP 设有一个保活计时器。服务器每收到一次客户端的数据，都会重新复位这个计时器，时间通常是设置为 2 小时。若 2 小时还没有收到客户端的任何数据，服务器就开始重试：每隔 75 秒发送一个探测报文段，若一连发送 10 个探测报文后客户端依然没有回应，那么服务器就认为连接已经断开了。
TIME-WAIT 状态过多会产生什么后果？怎样处理
从服务器来讲，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。
从客户端来讲，客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。
TCP协议如何保证可靠性
TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和 流量控制等方法实现了可靠性传输。
检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
序列号/确认应答：序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。
TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。
流量控制：如果主机A 一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。
TCP的滑动窗口
传输的数据比较大，就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。
为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。
从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。
滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。
可以看到滑动窗口起到了一个限流的作用，也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。
拥塞控制
慢开始：不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。
拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。
快重传：我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。比如接收方在收到一个失序的报文段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。快重传规定：发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
快恢复：主要是配合快重传。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞），但接下来并不执行慢开始算法，因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。
粘包，拆包
TCP是基于stream机制，其实就是一串没有边界的数据流。 这里主要面临两个问题：1：如何定义数据的边界 2：拆包和粘包的问题。HTTP协议是基于TCP，所以也会面临前面两个问题。
数据读取流程
1：发送端发送数据，数据先通过网卡到服务端tcp的receive buffer中。服务端的上层应用如果需要读取数据，会申请一段业务buffer，调用JDK的IO接口，IO会将tcpreceive buffer的数据拷贝到业务的buffer里面。上层业务再通过设定的反序列化协议将业务buffer转换成对象进行业务处理。
2：服务端读取数据时，先申请一段业务buffer（大小一般是1k），通过调用JDK的channel.read(buffer)IO方法，IO会将tcp buffer的数据拷贝到业务buffer里面。返回值为读取字节的个数：如果返回值大于0，说明读取到了对应大小的数据；如果是0，表示没有读到数据，数据读取完成（可能业务buffer是满的，不能往里面写数据）；如果是-1，代表tcp连接被关闭（一般处理是关闭到该连接）
3：在java里面可以设置socket的SO_RCVBUF 参数来设置buffer的大小。默认值保存在：cat/proc/sys/net/core/rmem_default 也可通过cat /proc/sys/net/ipv4/tcp_wmem查看。
http粘包拆包说明
假如服务端连续接收了4个包。 应用申请1k的buffer空间去读取tcp数据。读取的流程如下。
1：业务先申请1k大小的业务buffer，先调用JDK IO接口，会拷贝Receive Buffer的1k数据到业务的buffer里面。
2：每个包定义有边界。通过边界定义，读取到包1和包2分别进行反序列化的处理，转换为对象供上层应用处理。（解决粘包的问题）
3：如下图：在读取到包3的时候，由于把buffer读完还没有发现边界。便将包3（剩下的10个）的数据拷贝到buffer的最前端。然后再调用JDK IO接口，tcp receive buffer拷贝数据是从业务buffer的第10个位置进行拷贝赋值。拷贝完后再读取包3的数据，直到边界（解决拆包的问题）
4：然后读取包4，发现到边界后，并且数据没有可读的，则整个流程结束。
http解决方案
1：请求行的边界是CRLF，如果读取到CRLF，则意味着请求行的信息已经读取完成。
2：Header的边界是CRLF，如果连续读取两个CRLF，则意味着header的信息读取完成。
3：body的长度是有Content-Length 来进行确定。如果没有Content-Length ，则是chunked协议。
netty实现：https://blog.csdn.net/u013378306/article/details/107742524
TIME_WAIT和CLOSE_WAIT的区别在哪?
默认客户端首先发起断开连接请求
从上图可以看出，CLOSE_WAIT是被动关闭形成的，当客户端发送FIN报文，服务端返回ACK报文后进入CLOSE_WAIT。TIME_WAIT是主动关闭形成的，当第四次挥手完成后，客户端进入TIME_WAIT状态。
HTTP常见的状态码
100 Continue：表示正常，客户端可以继续发送请求
101 Switching Protocols：切换协议，服务器根据客户端的请求切换协议。
200：服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
301 ： （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时，会自动将请求者转到新位置。
302：（临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
400 ：客户端请求有语法错误，不能被服务器所理解。
403 ：服务器收到请求，但是拒绝提供服务。
404 ：（未找到） 服务器找不到请求的网页。
500：（服务器内部错误） 服务器遇到错误，无法完成请求。
GET方法提交的请求的URL中的数据做多是2048字节，POST请求没有大小限制。
GET方法因为参数放在URL中，安全性相对于POST较差一些
GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。这个是它们本质区别。
HTTP1.0和HTTP1.1的区别
长连接：在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略，可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理：在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
如何考虑分布式 Session 问题
在互联网公司为了可以支撑更大的流量，后端往往需要多台服务器共同来支撑前端用户请求，那如果用户在 A 服务器登录了，第二次请求跑到服务 B 就会出现登录失效问题。
分布式 Session 一般会有以下几种解决方案：
客户端存储：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息
Nginx ip_hash 策略：服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。
Session 复制：任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。
共享 Session：服务端无状态话，将用户的 Session 等信息使用缓存中间件（如Redis）来统一管理，保障分发到每一个服务器的响应结果都一致。
建议采用共享 Session的方案。
介绍下进程和线程，介绍下线程的通信方式
进程是资源分配的最小单位，线程是CPU调度的最小单位
- 基于 volatile 关键字来实现线程间相互通信是使用共享内存的思想
- Object类提供了线程间通信的方法：
wait()、notify()、notifyaAl()，注意： wait和 notify必须配合synchronized使用，wait方法释放锁，notify方法不释放锁 - 使用JUC工具类 CountDownLatch，相当于也是维护了一个线程间共享变量state
- 使用 ReentrantLock 结合 Condition，condition.signal和condition.await
发现打开网站很慢的原因，简述排查流程和解决方案
一、针对这个题目我们可以简单理解成是server端出现的问题：
（1）可能的原因一：服务器出口带宽不够用。这是一个很常见的瓶颈。一方面，可能是本身购买的服务器出口带宽就很小。另一个，就是跨运营商网络导致带宽缩减。
（2）可能原因二：服务器负载过大忙不过来，比如说CPU和内存消耗完了。
（3）可能原因三：网站的开发代码没写好，例如mysql语句没有进行优化，导致数据库的读写相当耗费时间。
（4）可能原因四：数据库的瓶颈。
二、针对上面可能的原因，有哪些方法和工具去检测呢：
（1）某个用户反馈网站访问变慢，怎么去定位问题。首先你自己也打开下网站，看是否会出现用户反映的问题，如果你这边访问没问题，那就可能是用户那边的问题了，这块就是要先确定是用户那一方的问题还是自身比如说服务器或者网站的问题。
（2）发现确实是自己服务器或者网站的问题，那么可以利用浏览器的调试功能（一般浏览器都会有），调试网络看看各种数据加载的速度，哪一项消耗了多少时间都可以看到，是哪块数据耗时过多，是图片加载太慢，还是某些数据加载老半天都查不出来。
（3）然后针对服务器的负载情况，可以去查看下服务器硬件（网络带宽、CPU、内存）的消耗状况。带宽方面查看流量监控看是不是已经到了峰值，带宽不够用了，如果是公司自己买服务器搭的网站服务器的话，需要自己搭建监控环境；如果用的是阿里云腾讯云这些的，那这些平台那边会提供各方面的监控比如CPU、带宽等等，在后台就可以看到了。
（4）如果发现硬件资源消耗都不高，都比较充裕，那要去看看是不是程序的问题了。这个可以通过查日志来找，比如PHP日志、Apache日志、mysql日志等等的错误日志，特别如mysql有个慢查询的日志功能，可以看到是不是某条mysql语句特别慢，如果某条语句花的时间太长，那这条语句很有可能有问题。
（5）至于说到的数据库太庞大，这个直接看就看得到了，比如一个表的文件大小变得特别大了。
三、针对上面的这些问题，有哪些解决和优化的办法呢：
（1）出口带宽的问题，这个很简单，加带宽，有钱就多买带宽，很简单。
（2）mysql语句优化，开发人员职责。
（3）数据库太庞大，为了读写速度，进行“拆表”、“拆库”，就是把数据表或者数据库进行拆分。
（4）上面的拆库拆表都是针对数据库实在太庞大才会这样做，一般在此之前会有其他优化方法，比如mysql的主从复制，一台主服务器专门用于写，然后其他从服务器用来读，写完之后会同步更新到其他读的服务器中。例如阿里的双十一活动，都不知道用了多少万台服务器一起在扛着。
（6）用redis。
（7）CDN（content-delivery-network：内容分发网络）。
（8）上面都没有说到架构的优化，如果网站扛不住，是不是网站架构已经不能适应了，比如做个小博客把数据库服务器和web服务器都用同一台服务器，那所有负载都在同一台服务器上了。但是访问量上来扛不住了，就得加服务器了，就得在架构上优化了，比如在数据库上做集群，在web服务器上也做集群，比如web服务器集群，在服务器前面加一个负载均衡，负载均衡就是专门负责分发，把用户的请求均匀分布到各个服务器上。
Http
主要包含三部分：请求行line，请求头header，请求正文body
请求行：主要包含三部分：Method ，URI ，协议/版本。 各部分之间使用空格(SP)分割。整个请求头使用CRLF分割。
请求头： 格式为（name ：value），用于客户端请求的描述信息。header之间以CRLF进行分割。最后一个header会多加一个CRLF。
请求正文 ：里面主要是Post提交的数据（可支持多种格式，格式在Content-Type定义，长度是在Content-Length里面定义）。
主要包含三部分：状态行line,响应头header,响应正文body
状态行：包含三部分：http版本，服务器返回状态码，描述信息。以CRLF进行分割。
响应头 ： 格式为（name ：value），用于服务器返回的描述信息。header之间以CRLF进行分割。最后一个header会多加一个CRLF
响应正文：里面主要是返回数据。
读取response不是用分块编码就是用content-length
长连接
Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。
长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。
四种延迟
节点处理延迟 =》排队延迟=》发送延迟=》传播延迟
ARP协议
ARP协议属于网络层的协议，主要作用是实现从IP地址转换为MAC地址。在每个主机或者路由器中都建有一个ARP缓存表，表中有IP地址及IP地址对应的MAC地址。
IP地址可由用户自行更改，管理起来相对困难，而MAC地址不可更改，所以一般会把IP地址和MAC地址组合起来使用。
网络层实现的是主机之间的通信，而链路层实现的是链路之间的通信，所以从下图可以看出，在数据传输过程中，IP数据报的源地址（IP1）和目的地址（IP2）是一直不变的，而MAC地址（硬件地址）却一直随着链路的改变而改变。
ARP的工作流程（面试时问ARP协议主要说这个就可以了）：
- 在局域网内，主机A要向主机B发送IP数据报时，首先会在主机A的ARP缓存表中查找是否有IP地址及其对应的MAC地址，如果有，则将MAC地址写入到MAC帧的首部，并通过局域网将该MAC帧发送到MAC地址所在的主机B。
- 如果主机A的ARP缓存表中没有主机B的IP地址及所对应的MAC地址，主机A会在局域网内广播发送一个ARP请求分组。局域网内的所有主机都会收到这个ARP请求分组。
- 主机B在看到主机A发送的ARP请求分组中有自己的IP地址，会像主机A以单播的方式发送一个带有自己MAC地址的响应分组。
- 主机A收到主机B的ARP响应分组后，会在ARP缓存表中写入主机B的IP地址及其IP地址对应的MAC地址。
- 如果主机A和主机B不在同一个局域网内，即使知道主机B的MAC地址也是不能直接通信的，必须通过路由器转发到主机B的局域网才可以通过主机B的MAC地址找到主机B。并且主机A和主机B已经可以通信的情况下，主机A的ARP缓存表中寸的并不是主机B的IP地址及主机B的MAC地址，而是主机B的IP地址及该通信链路上的下一跳路由器的MAC地址。这就是上图中的源IP地址和目的IP地址一直不变，而MAC地址却随着链路的不同而改变。
- 如果主机A和主机B不在同一个局域网，参考上图中的主机H1和主机H2，这时主机H1需要先广播找到路由器R1的MAC地址，再由R1广播找到路由器R2的MAC地址，最后R2广播找到主机H2的MAC地址，建立起通信链路。
