JavaEE 初阶 — 确认应答机制

确认应答机制（安全机制）

确认应答 是实现可靠传输的最核心机制。

这里指的 可靠传输 不是说 100% 可以把消息发给接收方，而是尽力而为，尽可能的把数据传输过去。
同时，如果传输不过去，至少可以及时的获知。

我要给张三发短信，如果是在十几年前，这个发送的短信就有一个很大的问题，那就是可能会丢包，尤其是高峰期的时候。

有一天我想约张三出来一起去打球，所以就给他发了一个短信。



这里张三回答的 OK 就称为 “应答报文”，也叫做 ack（acknowledge的缩写）

当我收到 OK 的时候，我就知道，我发送的消息已经顺利的被张三看到了。（也就是短信没丢包）
如果隔了半天还没有收到张三回复，就说明发送的消息大概率是没了。

TCP 进行可靠性传输，最主要的就是靠这个确认应答机制。
A 给 B 发了一个消息，B 收到之后就会返回一个应答报文（ACK）。此时 A 收到应答之后，
就会知道了刚才发的数就已经顺利到达 B 了。

生活中随处可见这样的应答机制，比如打电话，打电话就相当于是可靠传输。

下面考虑一下更复杂的情况。


此处我可能是连续发送两条消息，我发送第一条的时候，不需要等第一条消息的回应，而张三则是收到消息就会立即回应。

1 什么是后发先至问题

网络上可能存在 “后发先至” 的情况，这个情况下，收到消息的顺序是可能存在变数的。

考虑上述约张三打球的场景，如果收到消息的顺序是可能存在变数，那么我发送的打球去收到的会是滚犊子，
而输的请客吃饭则会收到 OK。



如果发生了 “后发先至” 的情况，本来要表达的含义就会出现歧义了。

像 “后发先至” 这种情况，现实生活中也是挺常见的。

比如说马拉松比赛，刚开始选手都是在起点线排在一起，有的靠前，有的靠后。



随着比赛开始，由于每一个选手的速度和耐力都是不一样的，
并且有的选手会因为体力不支而无法完赛，撤离赛场所走的路径与比赛选手的路劲也不同，
因此想要保持比赛开始前的队形是非常困难的。

网络中数据的 后发先至 也是同理。

两个主机之间，路线存在多条，数据报1 和 数据报2 走的都是不同的路线。
数据报1 和 数据报2 转发的速率也不一样，有的快，有的慢，此时，这两个数据报到达的顺序就存在变数了。

结论：

网络后发先至这个现象是客观存在的，是无法避免的。因此应答报文到达的顺序也是可能发生变动的。
此时就需要考虑如何避免这种顺序错乱所带来的歧义。

1 如何解决后发先至问题

给传输的数据和应答报文都进行编号就可以了。


这里的 1 和 2 就是序号，而 针对1 和 针对2 就是确认序号。
当引入了序号之后，即使是顺序乱了，也可以通过序号来区分当前的应答报文是针对哪个数据进行的。

针对于 序号 的解释：

任何一条数据（包括应答报文）都是有序号的，确认序号则是只有应答报文有。（普通报文确认序号字段里的值无意义）

前面所提到的 ACK （确认号是否有效），是用来表示这一条报文是否是应答报文。
如果 ACK 这个标志位为1，表示为应答报文，如果为0，表示不是应答报文。

实际上 TCP 的序号并不是按照 “一条两条” 这样的方式来编号的。TCP 是面向字节流的，TCP 的序号也是按照字节来编号的。




TCP 的字节的序号是依次累加的，这个依次累加的过程对于后一条数据来说，
起始字节的序号就是上一个数据的最后一个字节的序号。

每个 TCP 数据报报头填写的序号只需要写 TCP 数据的头一个字节的序号即可。

TCP 知道了同一个字节的序号，再根据 TCP 报文长度，就很容易知道每一个字节的序号。

针对于 确认序号 的解释：

确认序号的取值，是收到的数据的最后一个字节的序号 + 1。


应答报文中的确认序号填写的是 1001，就是在刚才 1000 的基础上 +1。

表示的含义：

1、小于 1001 的数据都已经确认收到了。
2、主机1 接下来应该从 1001 这个序号开始继续发送。（主机2向主机1索要 1001 的数据）

小结：

1、TCP 可靠传输能力，最主要就是通过确认应答机制来保证的。
2、通过应答报文，就可以让发送方清楚的知道传输是否成功。
3、进一步的引入了序号和确认序号，针对多组数据进行详细的区分。