MyPrototypeWhat/take-down

网络层知识点

MyPrototypeWhat opened this issue · 0 comments

MyPrototypeWhat commented

网络层知识点

HTTP和HTTPS

  • Http：

    • 明文传输
    • 不会验证通信方身份
    • 接收方和发送放不会验证报文的完整性

  • Https:

    • 属于http的扩展，本身不保证传输的安全性
    • 由传输层安全协议（TSL） 或 安全套接层协议(SSL) 对通讯协议进行加密，也就是 HTTP + SSL(TLS) = HTTPS
    • http会直接和tcp通信，而https会先与ssl通信后，ssl再和tcp通信
    • 三个指标：
      • 加密
      • 数据完整性
      • 身份验证
    • https加密过程
      • 某网站拥有非对称加密的私钥A和公钥A，
      • 浏览器请求服务器 ，服务器把公钥A传给浏览器
      • 浏览器通过对称加密生成一个密钥X，用公钥A将密钥X加密，传给服务器
      • 服务器通过私钥A解密出密钥X，这样双方都有密钥X
      • 之后的数据传输都通过密钥X进行加密解密
      • 缺点：中间人攻击

  • 每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？

    • 显然每次请求都经历一次密钥制作传输过程非常耗时，那怎么达到只传输一次呢？
    • 服务器会为每一个浏览器生成一个sessionID，在TSL握手阶段传给浏览器
    • 浏览器将生成好的密钥传给服务器，服务器把密钥存在对应的sessionID下
    • 之后浏览器每次请求都会携带sessionID，服务器通过sessionID找到对应的密钥，进行加密解密操作
    • 这样就只有一次密钥制作和传输

  • 中间人攻击

    • 某网站拥有非对称加密的私钥A和公钥A，
    • 浏览器请求服务器 ，服务器把公钥A传给浏览器
    • 中间人劫持到公钥A，然后把数据包中的公钥A换成自己的公钥B（同时也拥有私钥B），传给浏览器
    • 浏览器通过对称加密生成一个密钥X，使用公钥B加密密钥X
    • 中间人劫持后把密钥X通过私钥B解密出来，再用公钥A加密传给服务器
    • 这么操作之后，中间人得到了密钥X，其根本原因是浏览器无法确认收到的公钥是不是网站自己的

  • 如何证明浏览器拿到的公钥一定是该网站的公钥？

    数字证书

    • CA机构，给网站颁发“身份证”，“身份证”就是数字证书
    • 网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书中由公钥信息、持有者信息等，服务器把证书传给浏览器，浏览器从证书中获取对应网站的公钥

  • 证书本身的传输过程中，如何防止被篡改?

    数字签名

    • 我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名
    • 数字签名制作流程：
      • CA机构拥有非对称加密的公钥和私钥
      • CA机构将证书明文数据T获取hash值
      • 获取的hash值通过私钥加密，得到数字签名s
      • 明文和数字签名共同组成数字证书，颁发给网站
    • 浏览器验证流程：
      • 拿到证书，获得明文T和数字签名s
      • 用CA机构的公钥将数字签名进行解密，得到hash值
      • 用证书中指明的hash算法将明文T进行hash，得到计算后的hash值
      • 两个hash值相等，证书可信
    • 中间人可篡改证书吗？
      • 不能，由于中间人没有CA机构的私钥，所以加密得来的签名，在浏览器验证不通过
    • 中间人可以掉包证书吗？
      • 假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，会有这种情况吗？
      • 不会，因为证书中的信息包含了网站A的信息，其中含有域名，浏览器将请求网站的域名与证书中的域名进行比对，就知道有没有被掉包

  • SSL/TSL:

    • 身份验证和加密的协议,1999年SSL被更名为TLS
    • 通过x.509证书（公钥的标准格式）将 网站和公司信息 绑定到加密密钥，每一个密钥对都有一个私有密钥一个共有密钥，用私钥解密公钥加密的信息
    • TLS 在根本上使用对称加密和 非对称加密 两种形式。

  • 对称加密

    • 加密密钥和解密密钥都是同一个密钥，所以需要对密钥的安全性有保障
    • TSL目前最常用的加密算法是 AES-128, AES-192、AES-256 和 ChaCha20。

  • 非对称加密

    • 公钥加密，私钥解密，公钥在网络间传播
    • RSA 加密算法是最重要的、最出名的一个

  • HTTP请求报文

    image.png

    • 请求⾏:

      • 请求⽅法字段、URL字段、HTTP协议版本字段。
      • 它们⽤空格分隔。例如，GET /index.html HTTP/1.1。

    • 请求头部:

      • 请求头部由关键字/值对组成，每⾏⼀对，关键字和值⽤英⽂冒号“:”分隔

    • 空⾏

    • 请求体

      • post put等请求携带的数据

      image.png

  • HTTP响应报文

    image.png

    • 响应⾏
      • 由网络协议版本，状态码和状态码的原因短语组成，
      • 例如 HTTP/1.1 200 OK 。
    • 响应头
      • 响应部⾸组成
    • 空⾏
    • 响应体
      • 服务器响应的数据

TCP相关与UDP

  • UDP

    • UDP的全称是用户数据报协议，是一种无连接的协议。
    • 面向无连接
      • 首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。
      • 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头，标识下是 UDP 协议，然后就传递给网络层了
      • 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作
    • 有单播，多播，广播的功能
      • UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。
    • 面向报文
      • 发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文
    • 不可靠性
      • 首先不可靠性体现在无连接上，并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。
      • 再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。
    • 头部开销小，传输数据报文时是很高效的。
      • UDP 的头部开销小，只有8字节，相比 TCP 的至少20字节要少得多，在传输数据报文时是很高效的。

  • TCP和UDP的区别

    • TCP是一个面向连接的、可靠的、基于字节流的传输层协议，UDP是一个面向无连接的传输层协议
    • 和 UDP 相比TCP三大核心特征：
      • 面向连接的：指服务端和客户端的连接，在通信之前，双方需要三次握手
      • 可靠性：有状态，可控制。
        • 有状态：tcp会精确记录哪些数据发送，哪些没有被对方接受了，哪些没有收到
        • 可控制：当意识到丢包，tcp会根据具体情况调整自己的行为，控制发送速度或者重发
      • 面向字节流：udp的数据传输是基于数据报的，而tcp为了维护状态，把一个个ip包变成了字节流

  • TCP三次握手

    • 为了证明双方的发送能力和接收能力
    • 一句话概括：A和B打电话，A：“能听见吗”（一次），B：“能听见，你能听见吗”（两次），A：“能听见”（三次）
    • 具体流程：
      • 双方处于CLOSED状态，服务端监听某个端口，变成LISTEN状态
      • 客户端主动发起连接报文，SYN=1报文段(同步位)，随机产生sep(初始序列号)，要求建立连接，变成SYN-SENT状态
      • 服务端收到，向客户端发送确认报文，SYN和ACK(acknowledgement 确认)都为1,以及ack( Acknowledge number确认号)(对应客户端的seq+1)，为自己随机产生seq，变成SYN-RCVD状态
      • 客户端收到确认报文，客户端发送ACK=1以及ack(对应服务端seq+1)，状态变成ESTABLISHED
      • 服务端收到ACK和ack，对比ack是否和seq值相同，状态变成ESTABLISHED，连接建立
      • 凡是需要对端确认的，一定消耗TCP报文的序列号

  • TCP四次挥手

    • 双方处于ESTABLISHED状态，当客户端主动关闭，服务端被动关闭（双方都可主动与另一方释放连接）
    • 客户端主动发送释放连接报文，同时停止客户端数据传输，FIN=1，seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1)客户端进入FIN-WAIT-1
    • 服务端收到释放连接报文，发起确认报文ACK=1、ack=u+1并生成seq=v，状态变为CLOSE-WAIT。服务器通知上层的应用进程，客户端向服务器的方向连接关闭，此时TCP连接处于半关闭状态，虽然此时客户端已经没有数据要发送了，但是服务器如果要发送数据给客户端，客户端还是要接受。
    • 客户端接收到了服务端的确认报文，变成了FIN-WAIT-2状态。等待服务器发送连接释放报文。
    • 服务器将需要发送给客户端的数据发送完毕后，服务端向客户端发送释放连接的报文FIN=1、ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，进入LAST-ACK状态.
    • 客户端收到服务端发来的关闭连接请求后，变成了TIME-WAIT状态，然后发送 ACK=1 ack=w+1 给服务端，而自己的序列号是seq=u+1。
    • 注意了，这个时候，客户端需要等待足够长的时间，具体来说，是 2 个 MSL(Maximum Segment Lifetime，报文最大生存时间)(4分钟), 在这段时间内如果客户端没有收到服务端的重发请求，那么表示 ACK 成功到达，挥手结束，否则客户端重发 ACK。
    • 为什么要等待2MSL：
      • 确认最后一个ACK报文到达服务端。因为这个ACK可能会丢失，所以如果在最后服务端没有收到最后的确认报文，那么服务端会重新发一次，而客户端就能在2MSL内收到，并且给出回应，重启2MSL计时器

常见http错误码

  • 2XX(Success 成功状态码)

    • 201 - Created 文档创建成功,比如新增一个user成功

    • 202 - Accepted 请求已被接受，但相应的操作可能尚未完成。这用于后台操作，例如数据库压缩等异步操作

    • 204 - No Content 该状态码表示客户端发送的请求已经在服务器端正常处理了，但是没有返回的内容，响应报文中不包含实体的主体部分。一般用于只需要从客户端往服务器端发送信息，而服务器端不需要往客户端发送内容时使用。

    • 206 Partial Content 该状态码表示客户端进行了范围请求，而服务器端执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

  • 3XX(表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。)

    • 300 - Multiple Choices 针对请求，服务器可执行多种操作

    • 301 - Moved Permanently 请求的网页已永久移动到新位置

    • 302 - redirect 代表暂时性转移，一些旧客户端会将请求方法错误的更改为GET（尽管302标准禁止post变化get，但实际使用时大家并不太遵守）(http1.0的协议状态码)

    • 303 - See Other 该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源（302状态码有着相同的功能，但是303明确表示客户端应当采用GET方法获取资源，把POST请求变为GET请求进⾏重定向）(http1.1的协议状态码)

    • 304 - Not Modified 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容

    • 305 - Use Proxy 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。

    • 307 - Temporary Redirect 代表暂时性转移，不会更改请求方法和消息主体（与302有相同的含义）(http1.1的协议状态码)

  • 4XX(Client Error 客户端错误状态码)

    • 400 - Bad Request 参数错误
    • 401 - Unauthorized 未被授权
    • 403 - Forbidden 请求被拒绝
    • 405 - Method Not Allowed 请求类型错误，例如不支持post但用post请求
    • 406 - Not Acceptable 服务器不支持请求的content-type
    • 413 - Request Entity Too Large 请求体太大不支持，一般是上传的文件超出了限定导致的

  • 5XX(Server Error 服务器错误状态码)

    • 500 - Internal Server Error 表示服务端在执行请求时发生了错误。 可能是服务器或者应用存在bug
    • 503 - Service Unavailable 服务不可用，现在无法处理请求。

缓存

  • 强缓存

    status code : 200

    不和服务器交互

    • expires
      • 值为一个时间戳，格林尼治时间
      • 服务器返回该请求结果缓存的到期时间，如果未超过过期时间，直接使用缓存,通过本地时间判断
    • Cache-Control:
      • 优先级更高
      • public：资源客户端和服务器都可以缓存。
      • privite：资源只有客户端可以缓存。
      • no-cache：客户端缓存资源，但是是否缓存需要经过协商缓存来验证。
      • no-store：不使用缓存。
      • max-age：缓存保质期。单位秒，相对时间

  • 协商缓存

    status code : 304

    强缓存失效就走协商缓存

    与服务器交互

    • If-Modified-Since：
      • 请求头，意为上次资源最后修改时间，值为上次请求的响应头 Last-Modified
    • If-None-Match:
      • 请求头，意为上次资源的唯一标识，值为上次请求返回的响应头 Etag
    • Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since，同时存在则只有Etag / If-None-Match生效

  • 缓存位置

    • 存储图像和网页等资源主要缓存在disk cache，操作系统缓存文件(如.JS)等资源大部分都会缓存在memory cache中。具体操作浏览器自动分配，看谁的资源利用率不高就分给谁。
    • Memory Cache
      • 内存中的缓存，主要包含的是当前中页面中已经抓取到的资源，例如页面上已经下载的样式、脚本、图片等。
      • 读取内存中的数据肯定比磁盘快，内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。一旦我们关闭页面，内存中的缓存也就被释放了
    • Disk Cache
      • 存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。
    • Push Cache
      • 推送缓存，是 HTTP/2 中的内容，当以上三种缓存(以上两种和service-worker)都没有命中时，它才会被使用。它只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在Chrome浏览器中只有5分钟左右，同时它也并非严格执行HTTP头中的缓存指令。

Http2.0

  • 二进制分帧层

    • HTTP2是二进制协议，他采用二进制格式传输数据而不是1.x的文本格式。
    • 1.1响应是文本格式，而2.0把响应划分成了两个帧，HEADERS（首部）和DATA（消息负载）

  • 多路复用

    • HTTP2建立一个TCP连接，一个连接上面可以有任意多个流（stream），所有的通信都在一个TCP连接上完成，真正实现了请求的并发

  • 头部压缩

    • HTTP2为此采用HPACK压缩格式来压缩首部。头部压缩需要在浏览器和服务器端之间：

      静态字典

      • 维护一份相同的静态字典，包含常见的头部名称，以及常见的头部名称和值的组合
      • 维护一份相同的动态字典，可以动态的添加内容
      • 通过静态Huffman编码对传输的首部字段进行编码

    • 例如要传输method:GET,那我们只需要传输静态字典里面method:GET对应的索引值就可以了，一个字节搞定。

    • 像user-agent、cookie这种静态字典里面只有首部名称而没有值的首部，第一次传输需要user-agent在静态字典中的索引以及他的值，值会采用静态Huffman编码来减小体积。第一次传输过user-agent之后呢，浏览器和服务器端就会把它添加到自己的动态字典中。后续传输就可以传输索引了，一个字节搞定。

  • 服务器端推送

    • 服务器端推送使得服务器可以预测客户端需要的资源，主动推送到客户端。
    • 例如：客户端请求index.htm，服务器端能够额外推送.js和.css。

常见请求头和响应头

参考：

「2021」高频前端面试题汇总之计算机网络篇

  • HTTP Request Header 常见的请求头：

    • Accept:浏览器能够处理的内容类型
    • Accept-Charset:浏览器能够显示的字符集
    • Accept-Encoding：浏览器能够处理的压缩编码
    • Accept-Language：浏览器当前设置的语言
    • Connection：浏览器与服务器之间连接的类型
    • Cookie：当前页面设置的任何Cookie
    • Host：发出请求的页面所在的域
    • Referer：发出请求的页面的URL
    • User-Agent：浏览器的用户代理字符串

  • HTTP Responses Header 常见的响应头：

    • Date：表示消息发送的时间，时间的描述格式由rfc822定义
    • server:服务器名称
    • Connection：浏览器与服务器之间连接的类型
    • Cache-Control：控制HTTP缓存
    • content-type:表示后面的文档属于什么MIME类型

请求方法相关

参考：

「2021」高频前端面试题汇总之计算机网络篇

  • GET方法URL长度限制的原因

    • 实际上HTTP协议规范并没有对get方法请求的url长度进行限制，这个限制是特定的浏览器及服务器对它的限制。
    • IE对URL长度的限制是2083字节(2K+35)。由于IE浏览器对URL长度的允许值是最小的，所以开发过程中，只要URL不超过2083字节

  • GET和POST的请求的区别

  • 应用场景： GET 请求是一个幂等的请求，一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作

    • 是否缓存： 因为两者应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。
    • 发送的报文格式： Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。
    • 安全性： Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。
    • 请求长度： 浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。
    • 参数类型： post 的参数传递支持更多的数据类型。

  • POST和PUT请求的区别

    • PUT请求是向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。（可以理解为时更新数据）
    • POST请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）

  • OPTIONS请求方法及使用场景

    • 通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。
    • OPTIONS请求方法的主要用途有两个：
      • 获取服务器支持的所有HTTP请求方法；
      • 用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

DNS

参考：

「2021」高频前端面试题汇总之计算机网络篇

  • DNS 协议是什么

    • DNS 是域名系统 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务
    • 将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址。

  • DNS完整的查询过程

    • 首先会在浏览器的缓存中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步
    • 将请求发送给本地DNS服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步
    • 本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址
    • 本地DNS服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址
    • 本地DNS服务器向权威域名服务器发送请求，域名服务器返回对应的结果
    • 本地DNS服务器将返回结果保存在缓存中，便于下次使用
    • 本地DNS服务器将返回结果返回给浏览器

  • DNS查询过程例子

    • 比如要查询www.baidu.com的 IP 地址
    • 首先会在浏览器的缓存中查找是否有该域名的缓存
    • 本地DNS服务器向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名服务器的 IP 地址的列表
    • 本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com 的顶级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表
    • 然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，最后权威域名服务器返回一个对应的主机名的 IP 地址列表

  • 迭代查询与递归查询

    • 实际上，DNS解析是一个包含迭代查询和递归查询的过程。
    • 递归查询指的是查询请求发出后，域名服务器代为向下一级域名服务器发出请求，最后向用户返回查询的最终结果。使用递归 查询，用户只需要发出一次查询请求。
      • 一般我们向本地 DNS 服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地 DNS 服务器返回给我们最终的请求结果。
    • 迭代查询指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询，用户需要发出 多次的查询请求。
      • 本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次查询的结果，下一级的查询由本地 DNS 服务器自己进行。

网络模型

  • OSI七层模型

    img
    • 应用层
      • OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。
    • 表示层
      • 表示层提供各种用于**应用层数据的编码和转换功能**,确保一个系统的应用层发送的数据能被另一个系统的应用层识别
      • 在项目开发中，为了方便数据传输，可以使用base64对数据进行编解码。如果按功能来划分，base64应该是工作在表示层。
    • 会话层
      • 会话层就是负责建立、管理和终止表示层实体之间的通信会话。
      • 该层的通信由不同设备中的应用程序之间的服务请求和响应组成。
    • 传输层
      • 传输层建立了主机端到端的链接
      • 作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。
      • 该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。
      • TCP UDP就是在这一层。端口号既是这里的“端”。
    • 网络层
      • 本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。
      • 我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。
    • 数据链路层
      • 将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。
      • 网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。
    • 物理层
      • 实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。
    • OSI七层模型通信特点：对等通信
      • 对等通信，为了使数据分组从源传送到目的地，源端OSI模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信**。在每一层通信过程中，使用本层自己协议进行通信**。