文章目录
- 前言
- 一、TCP协议段与机制
- TCP协议的特点
- TCP报头结构
- TCP协议的机制与特性
- 二、TCP协议的 连接管理机制
- TCP建立连接:三次握手
- TCP断开连接:四次挥手
- 三、TCP协议的 确认应答机制
- 四、TCP协议的 超时重传机制
- 总结
前言
本人是一个刚刚上路的IT新兵,菜鸟!分享一点自己的见解,如果有错误的地方欢迎各位大佬莅临指导,如果这篇文章可以帮助到你,劳请大家点赞转发支持一下!
本篇文章主要介绍了传输层的TCP协议中的三大安全机制,今天分享的全都是理论,因此大家一定要认真。
一、TCP协议段与机制
TCP协议的特点
特点 | 说明 |
---|---|
有连接 | 刻意保存对端的相关信息 |
可靠传输 | 尽全力将数据传输过去不是百分百成功,自己会知道数据传输是否成功 |
面向字节流 | 以一个字节为基本单位(一个数据可以分成几份 多次发多次收) |
有接收缓冲区,也有发送缓冲区 | 后续文章介绍 |
大小不受限 | 对于要传输的数据大小没有要求 |
全双工 | 一条通信路径,双向通信。(可以同时发送和接收数据) |
TCP报头结构
6位标志位
TCP协议的机制与特性
TCP的协议段格式,比UDP的协议段格式复杂一万倍!😵😵
所以他的机制与功能也比UDP更加强大!!😇😇
TCP对数据传输提供的管控机制,主要体现在两个方面: 安全和效率 。
这些机制和多线程的设计原则类似: 保证数据传输安全的前提下,尽可能的提高传输效率 。
TCP协议的机制与特性
1️⃣连接管理
2️⃣确认应答
3️⃣超时重传
4️⃣流量控制
5️⃣拥塞控制
6️⃣滑动窗口
7️⃣延时应答
8️⃣捎带应答
9️⃣面向字节流
🔟异常处理
- 1️⃣-5️⃣是TCP协议保证数据传输安全的 安全机制 。
- 6️⃣-8️⃣是TCP协议提高传输效率的 效率机制 。
- 9️⃣-🔟是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协议中的三个安全机制,今天分享的内容大多是理论,希望大家可以细细品读,如果有哪里不理解,可以私信或评论区沟通。
路漫漫不止修身,也养性。