Java Web 实战 16 - 计算机网络之传输层协议(1)

大家好 , 这篇文章 , 给大家分享的是 传输层协议中的 UDP 协议 , 以及部分 TCP 协议的知识 . 本篇文章还会给大家讲解网络中非常有名的三次握手四次挥手问题
大家收拾收拾 , 我们准备发车了~
在这里插入图片描述
上一篇文章的链接也给大家贴在这里了
文章专栏在此

传输层协议

我们之间提到过 , 传输层有两种协议 : UDP、TCP
传输层中的协议都是操作系统内核中已经包含好了的
我们也介绍过 UDP TCP 的特点
UDP : 无连接、不可靠传输、面向数据报、全双工
TCP : 有连接、可靠传输、面向字节流、全双工

认识协议的细节 , 需要先认识协议的报文格式

1. UDP 协议

image.png
基于 UDP 的应用层协议

  • NFS : 网络文件系统
  • TFTP : 简单文件传输协议
  • DHCP : 动态主机配置协议
  • BOOTP : 启动协议(用于无盘设备启动)
  • DNS : 域名解析协议

2. TCP 协议

特点 : 有连接、可靠传输、面向字节流、全双工
可靠传输 , 是 TCP 最核心的部分 , TCP 内部的很多机制 , 都是在保证可靠传输
这里的可靠传输 , 指的是 : 发了之后 , 对方收没收到 , 我心里清楚 . 而不是说 , 发出去之后 , 对方 100% 就能收到 . 比如 : 极端情况下 , 网线断了 .

那可靠性是如何保证的呢 ?
其中最核心的机制 : 确认应答
举个栗子 :
image.png
此处说的 “可靠性” 跟 “安全性” 没有任何关系 .
千万不能把 TCP 这个可靠的通信协议 , 说成 “安全的” 通信协议
安全性指的是 : 数据被截获之后 , 不容易被理解内部的意思 , 以防数据被篡改 . 这是通过加密来做到的

2.1 TCP 协议报头 + 确认应答

Demo.png
在确认应答的情况下 , 如果收到了 ACK , 就好办 . 那如果没收到呢 ? 还需要通过其他的途径来处理

2.2 超时重传

不是说我们没收到 ACK 就立即放弃 , 我们就需要重新再发一遍数据
网络环境错综复杂 , 尤其是有些时候 , 网络会拥堵 , 就可能导致丢包(数据就丢了)

比如 : 我们打联盟 , 有的时候突然就卡了

  1. 本地程序卡了 (CPU过载 / 显卡过载 / 硬盘过载) , FPS 降低了 , FPS < 60 就会感觉到明显的卡顿

FPS 代表每秒钟有多少帧 , 数字越大 , 就越流畅

  1. 网络延时比较大 : 因为网络拥堵导致客户端到服务器之间 , 消耗的时间更长了

可以通过 ping 值来看 , 网络延时比较大 , ping 值就变高了
正常 ping 在 20~30 ms 左右 , 如果 ping > 100ms 就会明显感觉到卡顿

  1. FPS 和 ping 都不高 , 但是丢包严重 : 如果丢包率达到 5% , 就会有明显卡顿感 . 如果已经达到 10% , 基本就玩不了了

丢包是无差别丢包的 , 任何一个数据报 , 都是有可能丢的
发的普通的报文 , 有可能会丢 ; 发的 ACK 也是有可能会丢的

如果是业务数据丢了
image.png
如果是 ACK 丢了
image.png
那有没有可能数据丢了一半呢 ?
image.png

在超时重传的机制下 , 发一个数据 , 丢包了 . 那么重传数据 , 还是会有可能丢包的
但是站在概率的角度来看 , 就比如假设一次传输数据 , 丢包概率是 10% (已经是一个很大的数字了)
A->B 发一次数据 , 丢包的概率 : 10% .
A->B 连续发两次都丢包的概率 : 10%* 10% = 1%

丢包操作还有一个超时时间 , 超时时间具体是多少 , 在操作系统内核中是可以控制的
第一次传输丢包 , 超时时间是 t1 . 第二次又丢包 , 超时时间是 t2.
一般 t2 > t1 , 这里的等待时间间隔 , 随着时间的推移 , 要越来越大
连续两次都没发过去 , 意味着当前单次发送的丢包概率已经相当大了
连续重传之后丢包的次数越多 , 此时意味着单次发送的丢包概率就更大
很可能是网络上遇到了非常严重的故障 , 短期内恢复不了 . 发送的再频繁 , 也没啥用
如果连续几次重传都不行 , 就只能放弃了
超时重传也不会无限制的重传下去 . 尝试几次之后 , 仍然无法传输过去 , 此时就会放弃尝试 , 然后就只能断开连接尝试重连 . 如果重连也还是连不上 , 就彻底放弃了


我们刚才介绍的两个机制 : “确认应答”、“超时重传” , 这是保证 TCP 可靠性的最核心机制
但是这两个机制 , 面试却很少考 …

2.3 连接管理 (三次握手 , 四次挥手)

三次握手

三次握手的原理

TCP 是一个有连接的协议 , 那就一定存在建立连接、断开连接
我们先来看建立连接的过程 : 三次握手
Demo.png
这就相当于男女生恋爱的过程
男生和女生 , 已经关系很好了
男生给女生说 : 我爱你 , 做我对象吧(syn)
女生听到这句话 , 瞬间脸红了(ack) , 然后说我也爱你(syn)
男生:好耶!(ack)
关系就确立好了

为什么要三次握手 ?

三次握手我们认为是一种保证可靠性的机制 , 这个东西相当于 “投石问路”
在正式通信之前 , 先确定好通信链路是否畅通
如果通信链路不畅通 , 后续大概率要丢包

❗ 但是为啥三次握手要握三次呢 ? 四次行不行?
✅ 行,但是没必要,因为效率低
❗ 两次行不行呢 ?
✅ 指定不行的 , 三次握手也是在验证通信双方的发送能力和接收能力是否正常
比如 : 你跟室友连麦打游戏 , 会先试试能不能听到对方说话
我 : 能听到吗 (SYN)
室友 : 能 (SYN + ACK)
我 : ok (ACK)
Demo.png

三次握手的意义

为了验证通信双方发送能力和接收能力都是正常的

三次握手另外的作用

三次握手还能够让通信双方协商一些重要的参数
比如 :
序号要从几开始是需要协商的 , 实际上一次连接中的序号不一定是从 1 开始的

举个栗子 :
image.png
三次握手的意义:

  1. 投石问路 , 验证通信双方发送 / 接收能力是否正常
  2. 协商重要参数

四次挥手

四次挥手就是断开连接的流程

三次挥手是客户端主动发起第一次 . 四次挥手 , 客户端和服务器都可以主动
Demo.png

连接管理机制

无标题.png
其中 , 我们还需要关注每个环节涉及到的 Socket API
image.png


这篇文章到这里就已经 over 了
如果对大家有帮助的话 , 请一键三连~
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/m0_53117341/article/details/129778252