计算机⽹络⾯试问题集锦（附答案）
写在前⾯：
  ⼯作告⼀段落，期间经历了很多事情，也思考了许多问题，最后也收获了⼀些沉甸甸的东西 —— 成长和⼀些来⾃阿⾥、百度、京东(sp)、华为等⼚⼦的Offer。好在⼀切⼜回到正轨，接下来要好好总结⼀番才不枉这段经历，遂将此过程中笔者的⼀些笔试/⾯试⼼得、⼲货发表出来，与众共享之。在此特别要感谢CSDN以及⼴⼤朋友的⽀持，我将坚持记录并分享⾃⼰所学、所想、所悟，央请⼤家不吝赐教，提出您宝贵的意见和建议，以期共同探讨提⾼。
摘要：
  本⽂对⾯试/笔试过程中经常会被问到的⼀些关于计算机⽹络的问题进⾏了梳理和总结，⼀⽅⾯⽅便⾃⼰温故知新，另⼀⽅⾯也希望为⼯作的同学们提供⼀个复习参考。关于这块内容的初步了解和掌握，建议⼤家读⼀读《图解HTTP》⼀书。
版权声明：
1、Http和Https的区别
  Http协议运⾏在TCP之上，明⽂传输，客户端与服务器端都⽆法验证对⽅的⾝份；Https是⾝披SSL(Secure Socket Layer)外壳的Http，运⾏于SSL上，SSL运⾏于TCP之上，是添加了加密和认证机制的HTTP。⼆者之间存在如下不同：
端⼝不同：Http与Http使⽤不同的连接⽅式，⽤的端⼝也不⼀样，前者是80，后者是443；
资源消耗：和HTTP通信相⽐，Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，⽽证书⼀般需要向认证机构购买；
Https的加密机制是⼀种共享密钥加密和公开密钥加密并⽤的混合加密机制。
2、对称加密与⾮对称加密
  对称密钥加密是指加密和解密使⽤同⼀个密钥的⽅式，这种⽅式存在的最⼤问题就是密钥发送问题，即如何安全地将密钥发给对⽅；⽽⾮对称加密是指使⽤⼀对⾮对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有⾃⼰知道。发送密⽂的⼀⽅使⽤对⽅的公钥进⾏加密处理，对⽅接收到加密信息后，使⽤⾃⼰的私钥进⾏解密。
  由于⾮对称加密的⽅式不需要发送⽤来解密的私钥，所以可以保证安全性；但是和对称加密⽐起来，
它⾮常的慢，所以我们还是要⽤对称加密来传送消息，但对称加密所使⽤的密钥我们可以通过⾮对称加密的⽅式发送出去。
3、三次握⼿与四次挥⼿
　(1). 三次握⼿(我要和你建⽴链接，你真的要和我建⽴链接么，我真的要和你建⽴链接，成功)：
第⼀次握⼿：Client将标志位SYN置为1，随机产⽣⼀个值seq=J，并将该数据包发送给Server，Client进⼊SYN_SENT状态，等待Server确认。
第⼆次握⼿：Server收到数据包后由标志位SYN=1知道Client请求建⽴连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产⽣⼀个值seq=K，并将该数据包发送给Client以确认连接请求，Server进⼊SYN_RCVD状态。
第三次握⼿：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建⽴成功，Client和Server进⼊ESTABLISHED状态，完成三次握⼿，随后Client与Server之间可以开始传输数据了。
　(2). 四次挥⼿(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)：
第⼀次挥⼿：Client发送⼀个FIN，⽤来关闭Client到Server的数据传送，Client进⼊FIN_WAIT_1状态。
第⼆次挥⼿：Server收到FIN后，发送⼀个ACK给Client，确认序号为收到序号+1（与SYN相同，⼀个FIN占⽤⼀个序号），Server进⼊CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
第三次挥⼿：Server发送⼀个FIN，⽤来关闭Server到Client的数据传送，Server进⼊LAST_ACK状态。
第四次挥⼿：Client收到FIN后，Client进⼊TIME_WAIT状态，接着发送⼀个ACK给Server，确认序号为收到序号+1，Server进⼊CLOSED状态，完成四次挥⼿。
4、为什么TCP链接需要三次握⼿，两次不可以么，为什么？
  为了防⽌已失效的链接请求报⽂突然⼜传送到了服务端，因⽽产⽣错误。
  客户端发出的连接请求报⽂并未丢失，⽽是在某个⽹络节点长时间滞留了，以致延误到链接释放以后
的某个时间才到达Server。这是，Server误以为这是Client发出的⼀个新的链接请求，于是就向客户端发送确认数据包，同意建⽴链接。若不采⽤“三次握⼿”，那么只要Server发出确认数据包，新的链接就建⽴了。由于client此时并未发出建⽴链接的请求，所以其不会理睬Server的确认，也不与Server通信；⽽这时Server⼀直在等待Client的请求，这样Server就⽩⽩浪费了⼀定的资源。若采⽤“三次握⼿”，在这种情况下，由于Server端没有收到来⾃客户端的确认，则就会知道Client并没有要求建⽴请求，就不会建⽴链接。
5、TCP协议如何来保证传输的可靠性
  TCP提供⼀种⾯向连接的、可靠的字节流服务。其中，⾯向连接意味着两个使⽤TCP的应⽤（通常是⼀个客户和⼀个服务器）在彼此交换数据之前必须先建⽴⼀个TCP连接。在⼀个TCP连接中，仅有两⽅进⾏彼此通信；⽽字节流服务意味着两个应⽤程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插⼊记录标识符。
  对于可靠性，TCP通过以下⽅式进⾏保证：
数据包校验：⽬的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报⽂段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序：既然TCP报⽂段作为IP数据报来传输，⽽IP数据报的到达可能会失序，因此TCP报⽂段的到达也可能会失序。TCP将对失序数据进⾏重新排序，然后才交给应⽤层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当TCP收到发⾃TCP连接另⼀端的数据，它将发送⼀个确认。这个确认不是⽴即发送，通常将推迟⼏分之⼀秒；
超时重发：当TCP发出⼀个段后，它启动⼀个定时器，等待⽬的端确认收到这个报⽂段。如果不能及时收到⼀个确认，将重发这个报⽂段；
流量控制：TCP连接的每⼀⽅都有固定⼤⼩的缓冲空间。TCP的接收端只允许另⼀端发送接收端缓冲区所能接纳的数据，这可以防⽌较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使⽤的流量控制协议是可变⼤⼩的滑动窗⼝协议。
6、客户端不断进⾏请求链接会怎样？DDos(Distributed Denial of Service)攻击？
  服务器端会为每个请求创建⼀个链接，并向其发送确认报⽂，然后等待客户端进⾏确认
1)、DDos 攻击
客户端向服务端发送请求链接数据包
服务端向客户端发送确认数据包
客户端不向服务端发送确认数据包，服务器⼀直等待来⾃客户端的确认
2)、DDos 预防 ( 没有彻底根治的办法，除⾮不使⽤TCP )
限制同时打开SYN半链接的数⽬
缩短SYN半链接的Time out 时间
tcp三次握手图解
关闭不必要的服务
7、Get与POST的区别
  GET与POST是我们常⽤的两种HTTP Method，⼆者之间的区别主要包括如下五个⽅⾯：
(1). 从功能上讲，GET⼀般⽤来从服务器上获取资源，POST⼀般⽤来更新服务器上的资源；
(2). 从REST服务⾓度上说，GET是幂等的，即读取同⼀个资源，总是得到相同的数据，⽽POST不是幂
等的，因为每次请求对资源的改变并不是相同的；进⼀步地，GET不会改变服务器上的资源，⽽POST会对服务器资源进⾏改变；
(3). 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报⽂的请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英⽂字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中⽂/其他字符，则直接把字符串⽤BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表⽰的ASCII)；⽽POST请求会把提交的数据则放置在是HTTP请求报⽂的请求体中。
(4). 就安全性⽽⾔，POST的安全性要⽐GET的安全性⾼，因为GET请求提交的数据将明⽂出现在URL上，⽽且POST请求参数则被包装到请求体中，相对更安全。
(5). 从请求的⼤⼩看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量⽐较⼩，⽽POST请求则是没有⼤⼩限制的。
1). GET请求中URL编码的意义
  我们知道，在GET请求中会对URL中⾮西⽂字符进⾏编码，这样做的⽬的就是为了避免歧义。看下⾯的例⼦，
  针对“name1=value1&name2=value2”的例⼦，我们来谈⼀下数据从客户端到服务端的解析过程。⾸先，上述字符串在计算机中⽤ASCII吗表⽰为：
6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
6E616D6531：name1
3D：=
76616C756531：value1
26：&
6E616D6532：name2
3D：=
76616C756532：value2
  服务端在接收到该数据后就可以遍历该字节流，⼀个字节⼀个字节的吃，当吃到3D这字节后，服务端就知道前⾯吃得字节表⽰⼀个key，再往后吃，如果遇到26，说明从刚才吃的3D到26⼦节之间的是上⼀
个key的value，以此类推就可以解析出客户端传过来的参数。
  现在考虑这样⼀个问题，如果我们的参数值中就包含=或&这种特殊字符的时候该怎么办？⽐如，“name1=value1”，其中value1的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。这样，我们的本意是只有⼀个键值对，但是服务端却会解析成两个键值对，这样就产⽣了歧义。
  那么，如何解决上述问题带来的歧义呢？解决的办法就是对参数进⾏URL编码：例如，我们对上述会产⽣歧义的字符进⾏URL编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在“%”后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符。更多关于 URL编码的内容，请参考我的博⽂，此不赘述。
8、TCP与UDP的区别
  TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议，它们之间的区别包括：
TCP是⾯向连接的，UDP是⽆连接的；
TCP是可靠的，UDP是不可靠的；
TCP只⽀持点对点通信，UDP⽀持⼀对⼀、⼀对多、多对⼀、多对多的通信模式；
TCP是⾯向字节流的，UDP是⾯向报⽂的；
TCP有拥塞控制机制;UDP没有拥塞控制，适合媒体通信；
TCP⾸部开销(20个字节)⽐UDP的⾸部开销(8个字节)要⼤；
9、TCP的拥塞处理
  计算机⽹络中的带宽、交换结点中的缓存及处理机等都是⽹络的资源。在某段时间，若对⽹络中某⼀资源的需求超过了该资源所能提供的可⽤部分，⽹络的性能就会变坏，这种情况就叫做拥塞。拥塞控制就是防⽌过多的数据注⼊⽹络中，这样可以使⽹络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是⼀个全局性的过程，⽽后者指点对点通信量的控制。拥塞控制的⽅法主要有以下四种：
1). 慢启动：不要⼀开始就发送⼤量的数据，先探测⼀下⽹络的拥塞程度，也就是说由⼩到⼤逐渐增加拥塞窗⼝的⼤⼩;
2). 拥塞避免：拥塞避免算法让拥塞窗⼝缓慢增长，即每经过⼀个往返时间RTT就把发送⽅的拥塞窗⼝cwnd加1，⽽不是加倍，这样拥塞窗⼝按线性规律缓慢增长。
3). 快重传：快重传要求接收⽅在收到⼀个失序的报⽂段后就⽴即发出重复确认（为的是使发送⽅及早知道有报⽂段没有到达对⽅）⽽不要等到⾃⼰发送数据时捎带确认。快重传算法规定，发送⽅只要⼀连收到三个重复确认就应当⽴即重传对⽅尚未收到的报⽂段，⽽不必继续等待设置的重传计时器时间到期。
4). 快恢复：快重传配合使⽤的还有快恢复算法，当发送⽅连续收到三个重复确认时，就执⾏“乘法减⼩”算法，把ssthresh门限减半，但是接下去并不执⾏慢开始算法：因为如果⽹络出现拥塞的话就不会收到好⼏个重复的确认，所以发送⽅现在认为⽹络可能没有出现拥塞。所以此时不执⾏慢开始算法，⽽是将cwnd设置为ssthresh的⼤⼩，然后执⾏拥塞避免算法。
10、从输⼊⽹址到获得页⾯的过程
  (1). 浏览器查询 DNS，获取域名对应的IP地址：具体过程包括浏览器搜索⾃⾝的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host⽂件和向本地DNS服务器进⾏查询等。对于向本地DNS服务器进⾏查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS 服务器区域解析，但该服务器已缓存了此⽹址映射关系，
则调⽤这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该⽹址映射关系，那么将根据其设置发起递归查询或者迭代查询；
  (2). 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建⽴链接，发起三次握⼿；
  (3). TCP/IP链接建⽴起来后，浏览器向服务器发送HTTP请求；
  (4). 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进⾏处理，并将处理结果及相应的视图返回给浏览器；
  (5). 浏览器解析并渲染视图，若遇到对js⽂件、css⽂件及图⽚等静态资源的引⽤，则重复上述步骤并向服务器请求这些资源；
  (6). 浏览器根据其请求到的资源、数据渲染页⾯，最终向⽤户呈现⼀个完整的页⾯。
11、Session、Cookie 与 Application
  Cookie和Session都是客户端与服务器之间保持状态的解决⽅案，具体来说，cookie机制采⽤的是在客户端保持状态的⽅案，⽽session机制采⽤的是在服务器端保持状态的⽅案。
(1). Cookie及其相关API
  Cookie实际上是⼀⼩段的⽂本信息。客户端请求服务器，如果服务器需要记录该⽤户状态，就使⽤response向客户端浏览器颁发⼀个Cookie，⽽客户端浏览器会把Cookie保存起来。当浏览器再请求该⽹站时，浏览器把请求的⽹址连同该Cookie⼀同提交给服务器，服务器检查该Cookie，以此来辨认⽤户状态。服务器还可以根据需要修改Cookie的内容。   
(2). Session及其相关API
  同样地，会话状态也可以保存在服务器端。客户端请求服务器，如果服务器记录该⽤户状态，就获取Session来保存状态，这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使⽤；如果客户端请求不包含sessionid，则为此客户端创建⼀个session并且⽣成⼀个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。保存这个sessionid的⽅式可以采⽤ cookie机制，这样在交互过程中浏览器可以⾃动的按照规则把这个标识发挥给服务器；若浏览器禁⽤Cookie的话，可以通过 URL重写机制将sessionid传回服务器。
(3). Session 与 Cookie 的对⽐
实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID；
⼤⼩限制：Cookie有⼤⼩限制并且浏览器对每个站点也有cookie的个数限制，Session没有⼤⼩限制，理论上只与服务器的内存⼤⼩有关；
安全性：Cookie存在安全隐患，通过拦截或本地⽂件得到cookie后可以进⾏攻击，⽽Session由于保存在服务器端，相对更加安全；
服务器资源消耗：Session是保存在服务器端上会存在⼀段时间才会消失，如果session过多会增加服务器的压⼒。
Application（ServletContext）：与⼀个Web应⽤程序相对应，为应⽤程序提供了⼀个全局的状态，所有客户都可以使⽤该状态。
(4). Application
  Application（Java Web中的ServletContext）：与⼀个Web应⽤程序相对应，为应⽤程序提供了⼀个全局的状态，所有客户都可以使⽤该状态。
12、SQL 注⼊
  SQL注⼊就是通过把SQL命令插⼊到Web表单提交或输⼊域名或页⾯请求的查询字符串，最终达到欺骗服务器执⾏恶意的SQL命令。
1). SQL注⼊攻击的总体思路
  (1). 寻到SQL注⼊的位置
  (2). 判断服务器类型和后台数据库类型
  (3). 针对不通的服务器和数据库特点进⾏SQL注⼊攻击
2). SQL注⼊攻击实例
  ⽐如，在⼀个登录界⾯，要求输⼊⽤户名和密码，可以这样输⼊实现免帐号登录：
⽤户名： ‘or 1 = 1 --
密码：
  ⽤户⼀旦点击登录，如若没有做特殊处理，那么这个⾮法⽤户就很得意的登陆进去了。这是为什么呢?下⾯我们分析⼀下：从理论上说，后台认证程序中会有如下的SQL语句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，当输⼊了上⾯的⽤户名和密码，上⾯的SQL语句变成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL语句我们知道，
username=‘ or 1=1 这个语句⼀定会成功；然后后⾯加两个-，这意味着注释，它将后⾯的语句注释，让他们不起作⽤。这样，上述语句永远都能正确执⾏，⽤户轻易骗过系统，获取合法⾝份。
3). 应对⽅法
(1). 参数绑定
  使⽤预编译⼿段，绑定参数是最好的防SQL注⼊的⽅法。⽬前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数⽽不是SQL命令被执⾏。在mybatis的mapper⽂件中，对于传递的参数我们⼀般是使⽤#和$来获取参数值。当使⽤#时，变量是占位符，就是⼀般我们使⽤javajdbc的PrepareStatement时的占位符，所有可以防⽌sql注⼊；当使⽤$时，变量就是直接追加在sql中，⼀般会有sql注⼊问题。
(2). 使⽤正则表达式过滤传⼊的参数
13、 XSS 攻击
  XSS是⼀种经常出现在web应⽤中的计算机安全漏洞，与SQL注⼊⼀起成为web中最主流的攻击⽅式。XSS是指恶意攻击者利⽤⽹站没有对⽤户提交数据进⾏转义处理或者过滤不⾜的缺点，进⽽添加⼀些脚本代码嵌⼊到web页⾯中去，使别的⽤户访问都会执⾏相应的嵌⼊代码，从⽽盗取⽤户资料、利⽤⽤户⾝份进⾏某种动作或者对访问者进⾏病毒侵害的⼀种攻击⽅式。
1). XSS攻击的危害
盗取各类⽤户帐号，如机器登录帐号、⽤户⽹银帐号、各类管理员帐号
控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能⼒
盗窃企业重要的具有商业价值的资料
⾮法转账
强制发送电⼦邮件
⽹站挂马
控制受害者机器向其它⽹站发起攻击
2). 原因解析
  主要原因：过于信任客户端提交的数据！
  解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进⾏相应的过滤处理然后⽅可进⾏下⼀步的操作。
  进⼀步分析细节：客户端提交的数据本来就是应⽤所需要的，但是恶意攻击者利⽤⽹站对客户端提交数据的信任，在数据中插⼊⼀些符号以及javascript代码，那么这些数据将会成为应⽤代码中的⼀部分了，那么攻击者就可以肆⽆忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据
3). XSS 攻击分类
(1). 反射性XSS攻击 (⾮持久性XSS攻击)
  漏洞产⽣的原因是攻击者注⼊的数据反映在响应中。⼀个典型的⾮持久性XSS攻击包含⼀个带XSS攻击向量的链接(即每次攻击需要⽤户的点击)，例如，正常发送消息：
接收者将会接收信息并显⽰Hello,World；但是，⾮正常发送消息：
接收者接收消息显⽰的时候将会弹出警告窗⼝！
(2). 持久性XSS攻击 (留⾔板场景)
  XSS攻击向量(⼀般指XSS攻击代码)存储在⽹站数据库，当⼀个页⾯被⽤户打开的时候执⾏。也就是说，每当⽤户使⽤浏览器打开指定页⾯时，脚本便执⾏。与⾮持久性XSS 攻击相⽐，持久性XSS攻击危害性更⼤。从名字就可以了解到，持久性XSS攻击就是将攻击代码存⼊数据库中，然后客户端打开时就执⾏这些攻击代码。
例如，留⾔板表单中的表单域
<input type=“text” name=“content” value=“这⾥是⽤户填写的数据”>
正常操作流程是：⽤户是提交相应留⾔信息 —— 将数据存储到数据库 —— 其他⽤户访问留⾔板，应⽤去数据并显⽰；⽽⾮正常操作流程是攻击者在value填写:
<script>alert(‘foolish!’)；</script> <!--或者html其他标签（破坏样式。。。）、⼀段攻击型代码-->
并将数据提交、存储到数据库中；当其他⽤户取出数据显⽰的时候，将会执⾏这些攻击性代码。
4). 修复漏洞⽅针
  漏洞产⽣的根本原因是太相信⽤户提交的数据，对⽤户所提交的数据过滤不⾜所导致的，因此解决⽅案也应该从这个⽅⾯⼊⼿，具体⽅案包括：
将重要的cookie标记为http only, 这样的话Javascript 中的kie语句就不能
获取到cookie了（如果在cookie中设置了HttpOnly属性，那么通过js脚本将⽆法读取到cookie信息，这样能有效的防⽌XSS攻击）；
表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合。。。。
对数据进⾏Html Encode 处理
过滤或移除特殊的Html标签，例如: <script>, <iframe> , < for <, > for>, " for
过滤JavaScript 事件的标签，例如 “οnclick=”, “onfocus” 等等。
  需要注意的是，在有些应⽤中是允许html标签出现的，甚⾄是javascript代码出现。因此，我们在过滤数据的时候需要仔细分析哪些数据是有特殊要求（例如输出需要html代码、javascript代码拼接、或者此表单直接允许使⽤等等），然后区别处理！
14、OSI⽹络体系结构与TCP/IP协议模型
  为了更好地了解计算机⽹络体系结构，笔者以两篇博客的篇幅来介绍这个计算机⽹络中最为重要的知识点，具体见和。下⾯只做简要的总结。
  在⼀⽂中，我们知道TCP/IP与OSI最⼤的不同在于：OSI是⼀个理论上的⽹络通信模型，⽽TCP/IP则是实际上的⽹络通信标准。但是，它们的初衷是⼀样的，都是为了使得两台计算机能够像两个知⼼朋友那样能够互相准确理解对⽅的意思并做出优雅的回应。现在，我们对OSI七层模型的各层进⾏简要的介绍：
1). 物理层
  参考模型的最低层，也是OSI模型的第⼀层，实现了相邻计算机节点之间⽐特流的透明传送，并尽可能地屏蔽掉具体传输介质和物理设备的差异，使其上层(数据链路层)不必关⼼⽹络的具体传输介质。
2). 数据链路层（data link layer）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。