likes
comments
collection
share

计算机网络-网络模型&对应协议

作者站长头像
站长
· 阅读数 65

前言

这两年会时不时的去关注下 jd。发现大厂要求会计算机网络。于是～ 于是 就回顾下大学知识，并做个笔记（嗯 我也馋大厂），希望 正在阅读的你可以也有所收获，如果你觉得我写的不好，看不懂，也可以在评论区留言

网络模型

OSI模型

  • 物理层： 网线，光纤 来传输数据（双胶线，来传输0，1 ）
  • 数据链路层： 两个设备间的数据传输 交换机（局域网）每个设备有自己的 mac 地址 交换机通过 mac 地址建立逻辑链接
  • 网络层：寻址 ip 通过路由器 找到 对方的 mac 地址
  • 传输层：网络环境复杂 安全性不高，数据传输存在泄漏等问题，需要 tcp 对数据提供完整性包含
  • 会话层：建立会话
  • 表示层：数据的表示形式，
  • 应用层：用户最终访问的接口

为神马要做这个分层呢

功能拆分 复杂问题简单化处理 和我们开发的模块化化思想应该是；类似的 底层为上层服务（由上到下：物理层为数据链路层服务 以此类推）

这里纯粹是个人理解，没有官方依据

工作过程

  • 应用层（应用层，表示层，会话层 这里统称应用层）：准备好要传输的数据
  • 传输层： 根据 tcp 协议规则 对应用层的数据 进行打包，变成 tcp 包 增加 tcp 头 保证数据的完整性
  • 网络层 ：根据 ip 地址 找到对应的 mac 地址，将自己的 mac 地址给对方，并将 tcp 数据包根据 ip 协议再次包装 增加 ip 头
  • 数据链路层：对上层的数据包增加 mac 地址信息（上一层找到的对方的 mac） 用于传输 物理层：通过网线进行实际的数据传输

注意： tcp/ip 协议 指不是单个协议 而是一个协议族 （网络传输中 的各种规则）

对应的协议

只记常见的

  • 网络层：ip 协议，用于 从路由器寻址获得对方 mac 地址，到将自己的 mac 地址发给对方的过程中的通信规则
  • 传输层：tcp和 UDP
    1. tcp :在 ip 层上建立可靠的传输层，提供数据双向传播的管道（可以同一时间双向通信的 即：双工服务）
    2. UDP :视频传输时候 更多使用的应该是UDP，
    3. 两者的区别（仅做了解）
      1. tcp建立连接有3次握手过程，UDP无连接过程
      2. 通过tcp连接传送的数据，无差错，不丢失，不重复，且按序到达 ，udp 有可能存在丢帧情况
      3. tcp传输效率相对较低 ，udp传输效率高，适用于对高速传输和实时性有较高的通信或广播通信
      4. tcp连接只能是点到点、一对一的 ，udp支持一对一，一对多，多对一和多对多的交互通信
  • 应用层：http（超文本传输协议），ftp（文件传输协议）等等

tcp

组成

头部 ➕ 数据包

  • 头部：（数据来源的端口）源端口 ，（发送位置的端口）目的端口）
  • 数据包：单次最大支持40个字节，超出需要分包

三次握手

推荐工具：wireshark（这个抓包工具）看 tcp 握手和挥手的 信息

  1. 客户端发起链接请求（一个 tcp 包） 带有标识位 syn 对应的码 seq 为 1（告诉服务端我想和你发起链接）
  2. 客户端 收到链接请求 同意后 给客户端发一个 tcp 包 带 ACK 标识位，对应码数值 1 和原来收到的 syn 和 syn 对应的码 seq 值 ➕1 回传给客户端 告知客户端想和客户端发起双向链接
  3. 户端收到同意建立链接后 留下 syn 将收到的 ack 对应的 ack 码值等于 syn 的码值，塞入 tcp 包回给服务器说表示 ok 对应的码不仅仅是 1 和 0 是相对的，非固定不变

题外话：syn 和 ack 的关系

1:客户端 to 服务端 seq 值是 是第一次握手？0：上一次服务端给的 ack 的值
2.服务端 to 客户端 ack 的值是 是第二次握手？1（其实是随机值）:上一次收到的客户端传来的 seq+len
3.下一次 客户端要和服务端发起请求的时候 的syn 和数据len 的和是服务端收到请求后要返回的ack的对应码值
4.收到服务端返回的ack和syn后 再次给服务端发起请求时候的syn 是收到的ack的对应值 要回给服务端的 syn值是上次收到额ack的值加上次收到的len

为什么是三次握手而不能两次或四次

  1. 2 次的话 服务端无法得知 客户端是否真的收到了自己的响应 ；
  2. 4 次显的 没必要 因为彼此都确认过眼神是对的那个人，然后开始通信 可以发起 http 请求

四次挥手

  1. 客户端发起断开请求 Fin（finish）和 ack（ack 还是上次收到服务端返回的 seq+len）表示自己不会再发起请求
  2. 服务端响应 断开请求 和 ack 标识 以免客户端以为服务器没收到 连续发起 fin
  3. 服务端再发起自己的 fin+ack 标识 我也断开了 不会再响应 （2 和 3 为什么不合在一起 ：一方面怕客户端连续发起 fin，一方面怕还有数据响应在路上没发完，要确认完再断开）
  4. 客户端收到 服务端的 断开 tcp 包 返回 ack 的 tcp 说 好的

也可以是服务端发起断开链接 但更多是客户端主动断开

tcp特点

滑动窗口

两个窗口，不停的滑动来确定发送的数据的区域和接收方的缓存区域）

  1. 滑动窗口tcp是全双工的，所以发送端有发送缓存区；接收端有接收缓存区，要发送的数据都放到发送着的缓存区，发送窗口（要发送的数据）就是要发送缓存中的那一部分
  2. 核心是流量控制：在建立链接的时候，接收端就会告诉发送端自己的窗口大小（rwnd这是一个名字），每次接收端收到的数据都会再次确认（rwnd）的大小，如果为0，停止发送数据。（并发送窗口探测包，持续检查窗口大小）
  3. Nagle算法：任意时刻，最多只能有一个未确认的小段（tcp内部控制默认的） （Nagle 是等待对方接收到通过ack确认，就继续往下发）
  4. Cork算法，当达到MSS（maximun Segment Size）值时统一进行发送（此时的值就是帧的大小-ip头-tcp头=1460个字节大概）ps:nagle的进阶版
  5. Nagle算法和Cork算法都是未来减少包量 ，提高tcp效率 前者是tcp内部控制的默认 但我们可以手动启用Cork 不深入了解 滑动窗口的算法 我也只是 做了解 未深入研究，有兴趣 可以自行深入了解
tcp 阻塞处理

  1. 什么是tcp阻塞

    假设接收方窗口大小是无限的，接收到数据后就能发送ACK包，那么传输数据主要是依赖网络宽带，带宽的大小是有限制的，所以需要做阻塞

  2. 拥塞窗口cwnd

    tcp维护一个拥塞窗口cwnd（congestion window）变量（ssthresh），在传输过程中没有阻塞就将此值增大，如果出现拥塞（超时重传 RTO(retransmission Timeout)）就将窗口值减少

  3. cwnd< ssthresh 时使用慢算法

  4. cwnd > sshresh时 使用拥塞避免算法

  5. RTO时更新sstresh值为当前窗口的一半，更新cwnd=1

算法对应文章

占个吭，http的文章总结，待填吭

转载自:https://juejin.cn/post/6979008080650436644
评论
请登录