前言

各位读者好, 我是小陈, 这是我的个人主页, 希望我的专栏能够帮助到你:
📕 JavaSE基础: 基础语法, 类和对象, 封装继承多态, 接口, 综合小练习图书管理系统等
📗 Java数据结构: 顺序表, 链表, 堆, 二叉树, 二叉搜索树, 哈希表等
📘 JavaEE初阶: 多线程, 网络编程, TCP/IP协议, HTTP协议, Tomcat, Servlet, Linux, JVM等(正在持续更新)

TCP 协议是一种有链接的可靠传输协议, 并且 TCP 设计的宗旨是保证可靠性的同时, 尽可能地提高传输效率, 因此 TCP 具有八大机制 :

1️⃣连接管理(三次握手 + 四次挥手)
2️⃣确认应答
3️⃣超时重传
4️⃣滑动窗口
5️⃣流量控制
6️⃣拥塞控制
7️⃣延迟应答
8️⃣捎带应答

在这里插入图片描述

看不懂吧, 没关系, 我会出手, 先记住2~3 用来保证可靠性, 4~8 用来提高效率

上篇文章介绍了连接管理机制(三次握手四次挥手)

很多人都误以为连接管理机制也是用来保证可靠性的, 其实并不是

UDP 协议是无连接传输, 因此使用 UDP 协议协议传输数据, 发送方甚至不关心对端是否能接收, 不做任何检查就一股脑发出去了, 而 TCP 则不然, TCP 实现了在通信之前先建立连接, 通信完了再断开连接, 所以连接管理机制仅仅是通信前的"检查"

本篇就来介绍 TCP 保证可靠性的确认应答机制和超时重传机制

提示：是正在努力进步的小菜鸟一只，如有大佬发现文章欠佳之处欢迎批评指点~ 废话不多说，直接上干货！

一、确认应答

之前的文章就提到过, TCP协议的可靠性不是说确保每次发送数据都能 100% 能成功, 而是如果发送失败, 发送方会知道自己发送失败

如何做到呢? 正是因为有确认应答机制

1, 什么是确认应答

是指 : 如果接收方收到了数据报, 由操作系统内核来返回一个 ack (确认应答报文)

确认应答最明显的作用就是 : >如果发送方收到了 ack, 视为数据发送成功, 如果没有收到 ack, 就视为数据发送失败

确认应答机制有三种情况, 如图 :
在这里插入图片描述
第一次发送数据, 发送方收到了 ack, 视为发送成功
第二次发送数据, 数据报半路丢了, 接收方当然不会返回 ack, 发送方没有收到 ack, 视为发送失败
第三次发送数据, 接收方确实收到了数据报, 但是 ack 半路丢了, 发送方没有收到 ack , 也视为发送失败

ack 也是数据报, 数据报半路丢了的情况, 称作"丢包"

2, 序列号和确认应答号

实际上, TCP 的报头格式中包含两个字段 : (发送方的)序列号和 (接收方的)确认应答号

序列号是指 : 给发送的数据的每一个字节标号, 第一个字节就是该数据报的序列号
确认应答号是指 : 接收方已经收到的序列号 + 1, 来表示下次应该收到的序列号
在这里插入图片描述
上图中第一个数据报发送之后, 接收端已经收到了序列号为1000之前的所有数据, 返回 ack 中的确认应答序号为 1001 的意思就是"我该接收序列号为 1001 "的数据了