JavaEE

JavaEE——网络原理_应用层

网络原理——传输层_UDP

目录

• 传输层
• • TCP
  • TCP 的基本特性
  • • 确认应答机制
    • 超时重传

传输层

端到端之间的传输, 重点关注的是起点和终点

核心的协议有两个:

UDP: 无连接, 不可靠传输,面向数据报, 全双工

TCP: 有链接, 可靠传输, 面向字节流, 全双工

TCP

TCP协议端格式

实际格式, 他们都在一行

16位源端口 和16位目的端口, 和 UDP 开始的两个字段是一样的. 作为传输层协议, 协议包头中必须要明确源端口和目的端口.

16 位校验和和 UDP 的校验和类似.

TCP 的基本特性

确认应答机制

确认应答机制, TCP 保证可靠性的最核心机制.

我们来看这样一个场景: 小Gujiu 给 大GUJIU 发消息.

通过这样, 我们就可以知道上次发送的数据成功还是失败, 传输就变得可靠了.

回复的 “ok”, 就是"应答报文", 也称为 ack报文

继续来看下一个场景:

很明显, “后发先至”, 这时网络基本结构导致的, 难以避免, 我们只能想办法让含义不被误会.

解决方案: 针对请求和应答报文, 进行编号

在确认应答这个机制中, 引入序号来保证不出现歧义

TCP 是一个字节流协议, 编号的时候, 也是以字节为单位, 进行编号的.

确认应答描述的是, 数据包顺利到达对方, 对方给了个响应. 但是传输过程中, 可能会丢包

网络环境是非常复杂的, 我们上网, 是因为我们接入了运营商的网络, 运营商这边又很多很多的路由器/ 交换机, 共同的组建出一个非常庞大复杂的网络.

某个交换机上面, 不光传输我的数据包, 也在传输别人的数据包, 某个时刻, 很多很多数据包都经过这个交换机.

交换机的转发能力是有上限的, 很多数据包都走到这里了, 导致达到交换机的转发上限, 无法快捷的完成转发了, 就会导致有一部分数据包超时了.

超时重传

通过确认应答, 可以保证可靠性. 如果数据丢包了, 此时就需要考虑通过 “超时重传”

我们来看如下场景:

再看场景2:

TCP 接收方因为丢失 ACK 就会导致收到重复的消息

TCP 就会针对相同的消息进行去重(根据序号来去重)

超时时间如何确定的？

超时时间并非是均等的, 而是逐渐变大的

• 一般系统里会有一个配置项, 描述超时的时间阈值.
• 例如, 第一次出现丢包, 发送方就会在达到超时时间阈值之后, 进行重传. 如果重传的数据仍然无响应, 还会继续超时重传, 第二次的超时时间一般要比第一次时间更长
• 如果单个数据包丢包的概率较小, 这时, 第二次传输, 大概率是可以顺利到达的. 如果第二次传输也没有到达. 说明当前网络环境比较糟糕 (丢包概率非常大, 可能断网), 如果网都断了, 频繁的重传是无意义的, 不如传的频率降低一些.
• 这样的重传, 重试几次之后, 任然无法传输, 就会尝试重置 TCP 连接, 如果连不上, 及时就直接释放连接

上述过程中, 并没有带入具体数字, 原因有两点:

1. 这里的具体参数, 不同的系统不一样, 并且一般也是可配置的
2. 一旦给出了具体参数, 大家就会过度关注这个数字本身, 导致反而忽略了策略本身

以上就是今天要讲的内容了，希望对大家有所帮助，如果有问题欢迎评论指出，会积极改正！！