面试题总结——网络

面试题总结——网络

 1.TCP/IP五层模型（OSI七层模型）

  ①应用层（HTTP<超文本传输>，DNS<域名系统>）：负责应用程序间的数据沟通，对于不同的网络应用需要不同的应用层协议；
   <应用层>：针对特定应用的协议（电子传输协议SMTP，远程登录协议，文件传输协议）
   <表示层>：设备固有数据格式和网络标准数据格式的转换（接收不同表现形式的信息，文字，图像等）
   <会话层>：通信管理，负责建立和断开通信连接，管理下面的分层（何时建立连接，何时断开，保持多久的连接）
  ②传输层（TCP，UDP）：负责两台主机之间的数据传输，传输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面传输层的服务，分用和复用相反，是传输层把收到的信息分别交付上面应用层中的相应进程；
  ③网络层（IP）：负责地址管理和路由选择，网络层把传输层产生的报文段或用户数据报封装成分组和包进行传送；
  ④数据链路层（局域网）：负责设备之间的数据帧的传输，数据链路层将网络层交下来的 IP 数据报组装成数据帧进行传输；
  ⑤物理层：负责光/电信号的传递方式，尽可能屏蔽掉具体传输介质和物理设备的差异。

 2.三次握手与四次挥手

  2.1.三次握手（客户端主动）

   三次握手是指在建立TCP连接时，客户端与服务端进行发送能力与接收能力判断的过程。还未建立连接时客户端处于Closed（关闭）状态，服务端处于Listen监听状态。三次握手是客户端主动建立连接；
   第一次握手，客户端向服务端发送一个SYN报文（握手报文），请求与服务器建立连接，此时客户端处于SYN_SENT（等待回复）状态；
   第二次握手，服务端收到SYN报文后，此时服务端处于SYN_RCVD（同步收到）状态，会给客户端的SYN报文回应一个ACK报文（确认报文）与此同时也会向客户端发送一个SYN报文，请求与客户端建立连接；
   第三次握手，客户端收到SYN+ACK报文后处于ESATABLISHED（就绪）状态，会回应一个ACK报文给服务端，当服务端收到该ACK后也会处于ESTABLISHED就绪状态。连接建立成功。

   2.1.1.为什么是三次握手而不能是两次握手？

    造成的后果：若客户端发出连接请求，连接请求SYN报文丢失，由于超时重传机制的存在，此时客户端会再向服务端发送一次连接请求，收到服务端确认成功建立连接，数据传输结束后释放了连接。若只采用两次握手，当第一次发送的连接请求只是因为网络的原因长时间的滞留，延迟到第二个连接释放后的某个时间才到达服务端，此时服务端就会误认为客户端又发出一次新的连接请求，于是就向客户端发送确认报文段，此时服务端就会同意建立连接，而客户端此时会忽略服务端发来的确认请求，服务端就会一直在等待客户端的发送数据，浪费了大量的资源。
    能力方面：三次握手的目的是为了判断客户端与服务端的发送接收能力；
     第一次握手：服务端收到客户端发送的SYN报文，此时服务端可知客户端的发送能力，服务端的接受能力是正常的；
     第二次握手：客户端收到服务端发送的SYN+ACK报文，此时客户端可知客户端的发送+接收能力，服务端的发送+接收能力是正常的；
     两次握手后，客户端已知双端的发送接收能力都是正常的，但服务端并不确定客户端的接收能力是否正常，此时的连接是不安全的
     第三次握手：服务端收到客户端发送的ACK报文，此时服务端也知道客户端的接受能力，服务端的发送能力是正常的。

   2.1.2.三次握手携带数据吗？

    第一次和第二次不携带，第三次可以携带，第一次和第二次握手，客户端并不知道服务端的接收发送能力是否正常，此时若恶意攻击服务器携带大量数据，就会导致服务器花费大量时间空间来处理这些数据。而当第三次握手时，客户端处于ESATABLISHED状态，此时客户端已经知道服务器的接受发送能力正常，因此可以携带数据。

   2.1.3.第三次握手由于网络问题ACK报文丢失会发生什么？

    若客户端给服务端发送ACK包在网络中丢失，由于前两次握手的存在，服务端处于SYN_RECV状态，服务端会依次等待3秒，6秒，12秒后重新想客户端发送SYN+ACK包，以便客户端重新发送ACK包。如果重发指定次数后，服务端仍未收到ACK应答，则服务端就会自动关闭该连接。但此时客户端认为该连接已经建立，如果客户端向服务端写数据，服务端会响应RST包（复位，重新连接），则客户端便能感知到服务端的错误。

   2.1.4.服务端传了SYN，为何还要传ACK？

    因为双端都需要确认通信无误，传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

   2.1.5.什么是SYN攻击？业界最新的解决方案有哪些？

    SYN攻击：模拟大量客户端向服务端发送syn请求，当服务端给客户端返回确认ack以及syn报文后，客户端不再回复ack给服务端，让服务端一直处于SYN_RCVD状态（半开连接），如果SYN攻击泛洪的话就会导致服务端有大量的无用tcp连接，消耗大量的服务器资源，也会使正常的连接请求无法被相应。
    解决方案：
     无效链接监视释放：服务端监视系统中的半开连接（SYN_RCVD状态）和不活动连接，当达到一定阈值时断开这些连接，从而释放系统资源（有可能将正常连接误断开）
     使用SYN Proxy防火墙：对视图穿越的SYN请求进行验证后才放行。

  2.2.四次挥手（双端均可）

   四次挥手是指断开TCP连接时，未断开时两端都处于ESTABLISHED状态；
   第一次挥手，客户端给服务端发送一个FIN报文，此时客户端处于FIN_WAIT1（终止等待1）状态；
   第二次挥手，服务端收到FIN报文后，向客户端发送ACK报文，此时服务端处于CLOSE_WAIT（关闭等待）状态，客户端到服务端的连接释放，客户端收到ACK报文后处于FIN_WAIT2（终止等待2）状态；
   第三次挥手，服务端也要断开连接，向客户端发送FIN报文，此时服务端处于LAST_ACK（最后确认）状态；
   第四次挥手，客户端收到FIN报文后，向服务端发送ACK报文，此时客户端处于TIME_WAIT状态，等待2*MSL的时间以确保服务端收到客户端的ACK报文后客户端才会进入CLOSED状态，当服务端接收到该ACK报文后，服务端处于CLOSED状态。成功断开连接。

   2.2.1.为什么是四次挥手而不是三次挥手？

    当服务端收到FIN报文时，此时服务端并未将全部数据都发送给对端了，因此先回复一个ACK报文，告诉客户端，该服务端已收到FIN报文了，当服务端发送完所有数据后，才会向客户端发送FIN报文，故需要四次挥手。

   2.2.2.TIME_WAIT状态/等待2*MSL时间的作用？

    网络是不可靠的，有可能客户端给服务端发送的ACK会丢失，服务端没有收到ACK报文会一直处在LAST_ACK状态而不是CLOSED状态，因此客户端可以在TIME_WAIT状态下重新发送可能丢失的ACK报文。

   2.2.3.TIME_WAIT状态带来的风险？

    在socket的TIME_WAIT状态结束之前，该socket所占用的本地端口号一直无法被释放，当TIME_WAIT状态比较多时，导致该机器上的可用本地端口号被占完，从而导致客户端的程序无法向服务端建立新的socket连接。（这是端口层的，句柄层的暂且不说）

   2.2.4.为什么是2*MSL

    MSL：Maximum Segment Lifetime
    客户端收到FIN报文后就给服务器一个回信，为了防止回信丢失，客户端就再等2MSL个时间，之所以是2个，是因为涉及到来回，第一个MSL中是回信在路上的最大时间，第二个MSL是万一回信没到服务端，服务端重发的FIN确认在路上的时间。

   2.2.5.已经建立连接，客户端崩了怎么办？

    TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就自动关闭连接。

 3.GET和POST的区别

  ①功能上：GET一般用来从服务器上获取资源，POST一般用来修改服务器上的资源（只是Restful设计的初衷，实际并不一定是这样）；
  ②请求大小：GET请求的长度受限于浏览器或服务器对URL长度的限制，而POST请求没有长度限制；
  ③请求参数上：GET请求会通过URL传递参数，即将请求的数据放在HTTP请求报文的请求头中，以？分割URL和传输数据，参数之间采用&进行连接。而POST请求会将提交的数据放置在HTTP请求报文的请求体中；
  ④安全性：GET请求提交的数据将明文出现在URL上，安全性较低，而POST请求参数被包装到请求体中，相对更安全。

 4.HTTP与HTTPS的区别

  ①URL：HTTP的URL是以http://开头的，而HTTPS的URL是以https://开头的；
  ②安全性：HTTPS比HTTP更安全；
  ③端口号：HTTP与HTTPS使用不同的连接方式，用的端口不相同，HTTP标准端口是80，而HTTPS标准端口是443；
  ④资源消耗：和HTTP通信相比，HTTPS通信由于加密解密处理消耗更多的CPU以及内存资源；
  ⑤开销：HTTP不需要证书，而HTTPS需要证书；
  总结：HTTP协议运行于TCP之上，明文传输，客户端与服务端都无法验证对方的身份；HTTPS是身披SSL（安全套接层）/TLS外壳的HTTP协议（HTTP与SSL的结合），运行于SSL/TLS上，而SSL/TLS运行于TCP之上，所有传输的内容都经过对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。因此，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

  4.1.对称加密与非对称加密

   对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快（典型的对称加密算法有DES、AES等）
   非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢。（典型的非对称加密算法有RSA、DSA等）

 5.TCP和UDP的区别

  总体上讲：UDP（无连接，不可靠，面向数据报），TCP（有连接，可靠，面向字节流）
  有无连接：TCP是面向连接的，UDP是无连接的（有连接就类似打电话，你打了，对面必须得接才能通信，而无连接就类似发短信，只要你发了，对面就一定会收到）
  可靠性：TCP是可靠的，而UDP是不可靠的（所谓可靠就是发送者能感知到发送失败了）
  面向性：TCP是面向字节流的，而UDP是面向数据报的。（面向数据包就不能灵活的控制读写数据的次数和数量）

  5.1.TCP和UDP的应用场景

   TCP：多用于文件传输，发送和接收邮件，远程登录等场景
   UDP：多用于即时通信，如QQ语音，QQ视频，直播等场景

  5.2.为什么UDP比TCP传输的快？

   由于UDP采用不可靠传输，数据报一旦发送出去，UDP不管是否丢失，是否出错，是否发给对方。而TCP采用确认机制，创建连接时需要采用三次握手，断开连接时采用四次挥手，这个过程会耗费时间和资源。因此UDP的传输效率比TCP快。

  5.3.为什么TCP是面向字节流而UDP是面向数据报？

   UDP：应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用层必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率。若太短，会使IP太小。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。
   TCP：虽然应用层和TCP的交互是一次一个数据块（大小不等），但是TCP把应用层交下来的数据仅仅看成是一连串的无结构的字节流，TCP并不知道所传送的字节流的含义。另外如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送，如果数据块太短，也可以累积几次一起发送。

  5.4.TCP与UDP协议格式区别？

   UDP：16位源端口号+16位目的端口号+16位UDP长度+16位UDP校验和+数据
    16位校验和：检测用户数据报在传输过程是否有错，有错就丢弃。将首部和数据部分一起校验，主要应用反码求和的原理，二进制反码求和等价于二进制求和再取反。
   TCP：16位源端口号+16位目的端口号+32位序号+32位确认序号+4位TCP报头长度+6位标志位+16位窗口大小+16位校验和+16位紧急指针+40字节头部选项+数据
    32位序号（4个字节）：TCP面向字节流，每个字节都是按顺序编号
    32位确认序号：期望收到对方下一个报文段第一个字节的序号
    4位数据偏移：报文段的数据部分的起始位置，距离整个报文段的起始位置的距离，间接说明了报头首部的长度
    6位标志位：URG（紧急，尽快发送），ACK（确认），PSH（推送），RST（复位，出现严重差错重新连接），SYN（同步，建立连接），FIN（终止，断开连接）
    16位窗口大小：发送方自己的接收窗口，告知对方允许发送的数据量
    16位校验和：范围包括首部+数据部分，利用反码求和的性质
    16位紧急指针：URG标志位==1时，发送报文段中紧急数据的字节数
    头部选项（max=40字节）：数据部分的长度（不是TCP的长度）

 6.TCP核心机制

  TCP最核心的两个机制就是可靠传输，尽量提高传输效率。

  6.1.TCP如何保证可靠传输（为什么TCP是可靠的）

   ①确认应答机制：确认应答ACK机制，每个ACK应答都带有对应的确认序列号，告知发送者，我已经接收了哪些数据，下次该从哪里继续发；
   ②超时重传机制（停止等待ARQ协议）：若接收方没有返回确认应答ACK报文，则发送方隔一段时间后，再次传输同样的数据，降低丢包的可能性；
   ③连接管理机制：先试探对方是否适合与我进行通信，三次握手，四次挥手。

  6.2.TCP如何提高传输效率

   6.2.1.滑动窗口机制

    产生原因：由于确认应答机制对于每一个发送的数据段都会返回一个ACK报文，在收到ACK后才会继续发送下一个数据段，若数据的往返时间较长，则这样做效率就会很低，性能很差。
    滑动窗口机制：TCP采取滑动窗口机制，设置一个窗口大小，在该窗口中的数据无需等待确认应答就可继续发送数据。每当收到某数据报的ACK应答后，窗口就会向后滑动。操作系统开启缓冲区用以保存还没有确认应答的数据，若收到确认应答后，则会从缓冲区中删掉。
    快速重传机制（连续ARQ协议）：在滑动窗口机制中就不是使用超时重传机制了，而是使用快速重传机制，若发生数据报丢包情况，接收端反复给发送端主机发送相同的序列号，若发送端主机连续三次收到相同的序列号，说明该序列号所对应的数据报应该得重新发送。比如，一个滑动窗口中的数据从1000传到7000，而1000-2000序列号的数据报丢失，但其他数据发送接收正常，发送端会反复收到3次相同的确认应答1001，会对1001-2000这段数据进行重传，因此当接收端成功接收1000-2000的数据报后，直接返回序列号7001。其他正常接收的数据都被放在操作系统的接收缓冲区了。（发送方->接收方缓冲区->接收方，类似于一个生产消费者模型）

   6.2.2.流量控制机制

    产生原因：由于接收方缓冲区大小存在界限，一旦发送端发送数据太快，会导致接收端缓冲区溢满，若继续发送数据，缓冲区将不再接收数据，此时就会导致数据溢出，因此需要采用流量控制决定发送端的发送速度。
    流量控制机制：接收端将接收端缓冲区的大小赋值为TCP首部中的“窗口大小”字段，并通过确认应答ACK报文返回给发送端，发送端会根据这个窗口大小的数值来调整自己的发送速度。窗口越大，发送速度越快，若接收端缓冲区已满，则将窗口大小设置为0，此时发送端就不会发送数据，而是定期发送一个窗口探测数据段获取接收端当前的窗口大小。
    延迟应答机制：若接收端收到数据后立即返回ACK应答，此时返回的窗口大小可能比较小，假设接收端处理数据的速度比较快，短时间内就可以处理大量数据。此时若直接返回，就会浪费大量的缓冲区，而如果采用延迟应答，等待一会再响应，则会放大窗口大小，使网络吞吐量越大，效率越高。（eg：缓冲区设置为1M，一次收到500K，直接返回窗口大小就是500K，若接收端2ms就能处理300K，则过2ms后，就能返回窗口大小为800K了）
    捎带应答机制：由于存在延迟应答，TCP发送确认应答的同时也发送其他数据。减少收发数据的次数，提高网络利用率。

   6.2.3.拥塞控制机制

    产生原因：由于不清楚当前网络状态，因此不能直接发送大量的数据，若在网络拥堵的状态下发送大量数据可能会导致网络瘫痪。
    拥塞控制：采用慢启动机制，先发少量的数据探测此时的网络拥堵状态，再决定按照多大的速度传输数据。发送开始时将拥塞窗口设置为1，每收到一个ACK应答，拥塞窗口+1。这样的增长是指数式增长，当然也不会一直增长，当增长到一定值时，按照线性方式增长。当网络发送阻塞时（少量的丢包超时重传），吞吐量立即会下降。

   6.2.4.实际滑动窗口的大小

    实际上的窗口大小==min(流量控制窗口大小，拥塞控制窗口大小)

  6.3.自动重传机制（ARQ协议）

   ARQ协议通过确认和超时两个机制，在不可靠服务的基础上实现可靠的信息传输，若发送方在发送一段时间内没有收到确认帧，则通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

   6.3.1.停止等待ARQ协议

    A发送过程中出现差错，B在接收M1时出现差错：B直接丢弃M1，不会发任何信息，而A通过超时计时器进行时间判断，若到期之前没有收到接收方的确认信息则会重新发送M1（A端会暂存已发送的M1的副本，等收到确认后才会清除该副本）
    B正常接收到M1，但在返回确认信息时由于网络原因导致信息丢失：A通过超时计时器会再次给B发送M1，此时B会直接丢弃当前M1（之前已经接收过了），然后向A重传确认信息。
    B正常接收到M1，但在返回确认信息时由于网络原因导致延迟：A收到延迟的确认信息直接丢弃，向B重传M1，B收到后会丢弃当前M1，并向A重传确认信息。

   6.3.2.连续ARQ协议

    发送方采用流水线传输可连续发送多个分组，不必每发完一个分组就停下来等待对方确认，连续ARQ协议通常结合窗口协议来使用，发送方维护一个发送窗口，提高信道利用率。
    发送方每收到一个确认，就会将发送窗口向前滑动一个分组的位置，接受方采用累积确认的方式，不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，则表示这个分组为止的所有分组都已经正确接收到了。

 7.Cookie和Session的区别

  ①作用域：Cookie机制是在客户端保持状态的方案，数据存储在浏览器端，Session机制是在服务器端保持状态的方案，数据存储在服务器端；
  ②大小限制：Cookie有大小限制，浏览器对每个站点的Cookie有个数限制，Session没有大小限制，理论上至于服务器的内存大小相关；
  ③实现机制：Session的实现常常依赖于Cookie机制，服务器会通过Cookie机制回传的SessionID找到对应的Session进行处理。（服务器第一次响应客户端请求时会创建Cookie对象，并将此次会话的sessionID封装到Cookie对象中返回给浏览器，当浏览器第二次请求服务器时，浏览器会将Cookie作为请求信息的一部分提交给服务器，服务器会根据Cookie中的sessionID找到对应的Session）
  ④安全性：由于浏览器将Cookie信息保存在内存或硬盘中，可拦截本地文件找到Cookie进行攻击，因此存在安全隐患，而Session保存在服务器端，相对更加安全。

 8.浏览器上输入url后的流程

  ①浏览器查询DNS域名系统协议，将域名解析为对应的IP地址；
   1>浏览器搜索自身的DNS缓存找IP
   2>若没找到，在本地Hosts文件中查找IP
   3>若没找到，在路由器缓存中找
   4>若没找到，在DNS缓存中找
   5>若没找到，浏览器域名服务器向根域名服务器(baidu.com)查找域名对应IP,还没找到就把请求转发到下一级,直到找到IP
  ②浏览器向服务器请求建立连接，发起三次握手；
  ③浏览器向服务器发送HTTP请求；
  ④服务器对收到的请求进行处理，并将处理结果及相应的视图返回给浏览器；
  ⑤浏览器解析并渲染视图，若遇到js，css文件以及图片等静态资源的引用，重复上述步骤向服务器请求这些资源；
  ⑥浏览器得到其请求到的资源、数据渲染页面，最终向用户呈现完整页面。

---

                    HTTP

---

 9.HTTP长连接与短连接

  短连接：HTTP/1.0默认使用短连接，所谓短连接是指客户端和服务器每进行一次HTTP操作就建立一次TCP连接，任务结束就中断连接。（建立连接后完成一次请求就关闭）；
  长连接：HTTP/1.1起默认使用长连接，用以保持连接活性，当一个网页打开完成后，客户端与服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问服务器时，会继续使用这一条已经建立的连接，实现长连接需要客户端和服务端都支持长连接（长连接响应头添加：Connection:keep-alive，Keep-Alive不会永久保持连接，不同服务器会设定该保持时间）；
  总结：长连接和短连接实际上是TCP协议的长连接和短连接。

  9.1.长短连接的优劣势

   长连接：省去较多TCP建立断开的操作，节省时间，但如果客户端与服务端的连接一直不关闭的话，随着客户端连接的增多，服务器总有扛不住的时候。因此长连接多用于操作频繁，点对点的通信且连接不太多的情况；（数据库连接）
   短连接：服务器管理较为方便，存在的链接都是有用的连接，不需要额外的控制手段，但如果客户端请求频繁，由于需要不停的建立断开TCP连接，会耗费大量时间。短连接一般应用于连接较多的情况。（Web网站上亿的客户端连接，并发量非常大）

  9.2.服务器如何处理长连接多的场景？

   限制客户端的最大长连接数
   关闭长时间没有交互的连接：TCP的保活功能，服务器对于每个连接都存在一个保活定时器，若一个连接在两个小时内没有任何动作，则服务器向客户端发送一个探测报文段，若客户端不能响应该报文，则服务器总共会发送10个这样的探测，每个间隔75秒，若服务器没有收到任何一个响应，则认为客户端已经关闭并终止连接；若收到响应，客户端正常运行，则服务器将该保活定时器复位。

 10.HTTP协议常见响应状态码

  ①1XX：代表接收的请求正在处理
  ②2XX：代表服务器已经成功接收并处理了该请求。eg：200 OK表示请求成功
  ③3XX：代表客户端需要进一步请求，需要重定向。
  ④4XX：客户端错误，请求不合法。eg：404 表示访问资源不存在
  ⑤5XX：服务器错误，服务器不能处理合法请求。eg：500表示服务器内部错误，502 表示服务器挂了

 11.HTTP请求/响应格式

  请求：
   ①首行，请求方法+URL+协议及版本号
   ②协议头header
   ③空行（header的结束标记）
   ④正文body
  响应：
   ①首行，协议及版本号+响应状态码+状态码描述信息
   ②协议头header
   ③空行
   ④正文body

 12.HTTP协议常见的请求头

  Content-Type：body部分的数据格式(text/html…)
  Content-Length：body部分的长度
  Host：访问哪个主机的哪个端口
  referer：当前页面是从哪个页面跳转过来的
  location：搭配3XX状态码使用，告诉客户端接下来要访问哪里
  Cookie：在客户端存储少量信息，用于实现会话session的功能

 13.HTTP常见方法

  GET：获取资源
  POST：传输数据
  PUT：上传文件
  DELETE：删除文件

 14.HTTP 1.0和HTTP 1.1的区别

  长短链接：HTTP 1.0默认使用短连接，HTTP 1.1起默认使用长连接
  错误状态响应码：HTTP 1.1新增了一些错误状态响应码
  缓存处理：HTTP1.1引入了更多的缓存控制策略
  带宽优化及网络连接的使用：HTTP1.1方便了开发者自由的选择以便于充分利用带宽和连接。

 15.URI和URL的区别

  URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
  URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
  个人理解：URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

---

 16.基本网络术语

  IP地址：在网络中唯一标识一台主机
  端口号：在一台主机中标识一个进程（一个进程可以有多个端口号，一个端口号只能对应一个进程）

 17.网络层常见协议

  IP->物理mac地址：地址解析协议ARP协议，ARP的高速缓存可以大大减少网络上的通信量。因为这样可以使主机下次再与同样地址的主机通信时，可以直接从高速缓存中找到所需要的硬件地址而不需要再去广播方式发送ARP请求分组。
  物理mac地址->IP：反向地址转换RARP协议。