Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

网络层知识点 #7

Open
MyPrototypeWhat opened this issue Dec 6, 2021 · 0 comments
Open

网络层知识点 #7

MyPrototypeWhat opened this issue Dec 6, 2021 · 0 comments

Comments

@MyPrototypeWhat
Copy link
Owner

MyPrototypeWhat commented Dec 6, 2021 •
edited
Loading

网络层知识点

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模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信**。在每一层通信过程中，使用本层自己协议进行通信**。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@MyPrototypeWhat