网络编程4——TCP协议的三大安全机制：三次握手四次挥手+确认应答机制+超时重传机制

---

前言

本人是一个刚刚上路的IT新兵,菜鸟!分享一点自己的见解,如果有错误的地方欢迎各位大佬莅临指导,如果这篇文章可以帮助到你,劳请大家点赞转发支持一下!

本篇文章主要介绍了传输层的TCP协议中的三大安全机制，今天分享的全都是理论，因此大家一定要认真。

---

一、TCP协议段与机制

TCP协议的特点

特点	说明
有连接	刻意保存对端的相关信息
可靠传输	尽全力将数据传输过去不是百分百成功，自己会知道数据传输是否成功
面向字节流	以一个字节为基本单位(一个数据可以分成几份 多次发多次收)
有接收缓冲区，也有发送缓冲区	接收缓冲区：接收方用一个特殊的数据结构来组织接收到的数据,使用数据就从接收缓冲区拿，然后接收缓冲区就会删除已经拿走的数据。 发送缓冲区：发送方将要发送的数据存入发送缓冲区，等发送缓冲区满了，才会集中发送一次，可能会导致BUG(数据写到了发送缓冲区而没有发送出去)，因此代码中发送数据时尽量刷新缓冲区
大小不受限	对于要传输的数据大小没有要求
全双工	一条通信路径，双向通信。(可以同时发送和接收数据)

---

TCP报头结构

6位标志位

---

TCP协议的机制与特性

TCP的协议段格式，比UDP的协议段格式复杂一万倍！😵😵
所以他的机制与功能也比UDP更加强大！！😇😇

TCP对数据传输提供的管控机制，主要体现在两个方面： 安全和效率 。
这些机制和多线程的设计原则类似： 保证数据传输安全的前提下，尽可能的提高传输效率 。

TCP协议的机制与特性
1️⃣连接管理
2️⃣确认应答
3️⃣超时重传
4️⃣流量控制
5️⃣拥塞控制
6️⃣滑动窗口
7️⃣延时应答
8️⃣捎带应答
9️⃣面向字节流
🔟异常处理

• 1️⃣-3️⃣是TCP协议保证数据传输安全的 安全机制 。
• 4️⃣-8️⃣是TCP协议提高传输效率的 效率机制 。TCP协议的五大效率机制
• 9️⃣-🔟是TCP协议的 两大特性 。TCP协议的两大特性

---

二、TCP协议的 连接管理机制

连接管理包括
TCP建立连接：三次握手 。
TCP断开连接：四次挥手 。

知识点须知

• SYN：同步报文段 ，指一方要向另一方，申请建立连接。
  位于6位标志位中的第5位，默认是0，当第5位比特位为1是则认为这是一个SYN报文。
• ACK：应答报文 ， 指对收到对方数据包的确认。
  位于6位标志位中的第2位，默认是0，当第2位比特位为1是则认为这是一个ACK报文。
• FIN：结束报文 ， 指一方要向另一方提出释放连接。
  位于6位标志位中的第6位，默认是0，当第6位比特位为1是则认为这是一个FIN报文。

6位标志位

---

切记！！！！！

• TCP是如何实现可靠性的？
  答：依靠 确认应答机制 与 超时重传机制 实现可靠性的。
  可千万不是靠三次握手与四次挥手啊！！！

---

TCP建立连接：三次握手

握手指的是通信双方，进行一次网络交互。

• 三次握手相当于 客户端 和 服务器 之间，通过三次交互，建立了连接

建立连接一定是客户端主动发起的

---

上述过程：
1️⃣客户端向服务器发送一个SYN( 确认服务器是否可以收到数据 )

2️⃣服务器收到SYN返回给客户端一个ACK( 1.告诉客户端，服务器可以收到数据 ， 2.服务器知道客户端可以发送数据 )

3️⃣服务器向客户端发送一个SYN( 确认客户端是否可以收到数据 )

4️⃣客户端收到SYN返回给服务器一个ACK( 1.告诉服务器，客户端可以收到数据 ， 2.客户端知道服务器可以发送数据 )

• 这四次交互是为了检验服务器与客户端的收发数据的功能是否正常。

---

• 明明完成了四次交互，为什么叫做三次握手呢？？

原因是服务器返回给客户端的ACK与发送给客户端的SYN合并成一个报文了。
因此这个报文的标志位的第2位与第5位都是1，就代表这个报文即使ACK报文又是SYN报文。

这两个报文是一定会合并的，因为这个ACK报文与SYN报文是同一个时机触发的(都是由内核来完成的)，所以才称之为三次握手，而不是四次握手

---

TCP断开连接：四次挥手

挥手指的是一方提出的释放连接请求。

断开连接客户端与服务器都有可能主动发起的，下面假设客户端主动申请断开连接

上述过程与三次握手的过程非常相似，只不过SYN报文换成了FIN报文。

上述过程：
1️⃣客户端向服务器发送一个FIN( 告知服务器，客户端要断开连接 )

2️⃣服务器收到FIN返回给客户端一个ACK( 服务器知道了 )

3️⃣服务器向客户端发送一个FIN( 告知客户端，服务器要断开连接 )

4️⃣客户端收到SYN返回给服务器一个ACK( 客户端知道了 )

不用担心第四次的ACK返回不了，内核会一直维护TCP直到四次挥手结束的。

别想了，就是四次挥手，中间的ACK与FIN不是一定合并的。
原因： ACK与FIN是不同时机触发的 。
ACK是由内核完成的，会在收到FIN的时候第一时间返回ACK 。
FIN是调用close方法或进程结束时才会触发的 。

因此这就和你写的代码有很大的关系了，有两种情况。

1.服务器发现客户端断开连接后，立刻调用close方法，服务器的ACK还没发，那么此时就FIN与ACK就会合并起来一起发出去。
2.服务器发现客户端断开连接后，并没有立刻调用close方法，而是执行了其他操作，服务器的ACK已经发出去了，此时FIN就只能单独发了。

这两个报文是不一定会合并的，所以才称之为四次挥手。

---

三、TCP协议的 确认应答机制

TCP协议是可靠传输，而保证可靠传输的最核心的机制就是确认应答机制。

确认应答机制的大概内容就是， 每次收到数据 ，都会 给对端发送一个应答报文(ACK) ，应答报文与TCP报文的格式一样。

发送端可以根据有没有收到对端应答报文，来确定这条信息是不是安全可靠的传输给了对端。

但是此时也会遇到一个问题！

这是正常的回答。但是在网上经常会出现后发先至的情况。就变成了下面这样。

明明是明晚要回家的意思，因为后发先至，滚啊先到了，变成了回复第一句话的应答，好啊好变成了回复第二句话的应答。那么这个意思可就完全变了。😇😇😇

可以为每句话与回答添加序号

这样就不会弄巧成拙了。

所以真实的TCP数据传输也引入了序号和确认序号。协议段中的32位序号与32位确认序号

因为TCP传输数据的基本单位是字节，
所以就给发送的每个字节都编了序号。

---

应答报文中确认序号的意义就是告诉发送方，确认序号之前的字节我都收到了，并且确认序号就是你下一个要发送数据的编号。
对应上图中的两个应答报文即，
1001号前面的字节都收到了，你该发1001字节了。
13139号前面的字节都收到了，你该发13139字节了。

---

确认序号 须知

• 发送方的确认序号是无意义的数据
• 确认序号的规则，取自己接收到数据的最后一个字节的 下一个字节的序号 (假设对面发了1000个字节过来，但是我收到的最后一个字节编号是10，那么我给发送方的应答报文ACK中确认序号就是11)。
• 确认序号的作用：接收方通过ACK的确认序号，告诉发送方哪些数据已经收到了，便于发送方判断数据是否安全完整的送达。

---

四、TCP协议的 超时重传机制

如果一切都顺利，那么自然一切都好。

但是网络环境是十分复杂的，两台设备进行网络交互，中间要经过许许多多的节点，如果中间任何一个节点，出现了问题都会导致丢包。
因此网络传输中都会有概率出现丢包。

丢包：设备间进行传输的数据包，丢失了一部分或全部丢失都叫做丢包。

以下两种丢包情况会触发超时重传机制：
1️⃣

客户端发送的数据丢失，
服务器没有收到数据，不会返回ACK

2️⃣

服务器收到数据，但是返回的ACK丢包了。

---

这两种情况下，客户端向服务器发送数据，客户端会等待一段时间(TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间) 如果一段时间后没有收到应答报文ACK ，发送方就视为数据丢包，就会 触发超时重传机制：重新再发送一遍数据 。

如果是应答报文ACK丢包，也就是说接收方会重复收到两遍数据，不用担心，TCP已经帮我们处理好了。
TCP会在接收缓冲区中根据数据的序号自动去重，保证应用程序读不到重复数据。

当然了，重新传送的数据也有可能会再次丢包。一旦出现连续丢包，那么网络就出现了非常严重的问题。

TCP针对多次丢包的思路是：多次进行超时重传。
但是没进行一次超时重传，超时等待的时间都会变长(降低重传频率)。
连续多次重传仍无法收到ACK的话，TCP就会尝试重置连接(相当于重新连接)，如果重置连接也失败，TCP就会断开连接，放弃通信。

总结

以上就是今天要讲的内容，本文分享了TCP协议中的三个安全机制，今天分享的内容大多是理论，希望大家可以细细品读，如果有哪里不理解，可以私信或评论区沟通。

路漫漫不止修身，也养性。