网络原理 | 传输层重点协议之TCP协议(TCP连接的三次握手与四次挥手、TCP的安全机制与效率机制)

最新推荐文章于 2022-11-18 20:43:36 发布

Li_yizYa

最新推荐文章于 2022-11-18 20:43:36 发布

阅读量2.6k

点赞数 1

分类专栏：网络原理文章标签：网络 tcp/ip 安全

本文链接：https://blog.csdn.net/qq_58284486/article/details/127354848

版权

网络原理专栏收录该内容

7 篇文章 0 订阅

订阅专栏

TCP协议

· 传输层的作用负责数据能够从发送端到接收端，TCP协议是传输层的一个重点协议.

· TCP即传输控制协议，它需要对数据的传输进行一个详细的控制

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

TCP协议段格式

· 源/目的端口号：表示数据是哪个进程发送，哪个进程接收

· 4位TCP报头长度：表示该TCP头部有多少个32位bit(即有多少个4字节)，TCP头部最大长度为60(15 * 4)

· 6位标志位，boolean值，0/1数据.

ACK：确认号是否有效(应答)

SYN：请求建立连接，把携带SYN标识的称为同步报文段

FIN：申请断开连接，把携带FIN表示的称为结束报文段

安全机制

确认应答机制

发送的数据，接收端需要返回确认接收到数据报的应答

TCP将每个字节的数据都进行了编号(序列号)，并使用32位序号保存

每一个ACK都带有对应的确认序列号，它的目的是告诉发送端，接收端已经收到了哪些数据，下一次你应该从哪里开始发.

超时重传机制

发送端超过一定时限没有收到ACK应答包，就会发生重传。

· 时限是动态的，跟网络环境有关

· 没有收到ACK应答包的原因：①发送数据丢包、ACK应答包丢包

· 重传：发送的数据包才重新发送

例如上图中，主机A发送数据给主机B后，可能因为网络拥堵等原因，数据无法到达主机B，此时B没有收到A发送的数据包就不会确认应答，主机A在一个特定时间间隔内没有收到主机B发来的确认应答，就会重新发送数据.

主机A未收到主机B发来的确认应答，也可能是因为ACK的丢失

此时主机B就会收到主机A重新发来的数据包，此时TCP协议就需要识别出这重复的数据报，并把重复的包丢掉，根据序列号，就可以做到去重.

TCP为了保证在任何环境下都能比较高性能的通信，因此会动态计算这个超时时限：

· Linux、Unix、Windows中，超时以500ms为一个单位进行控制，每次判定超时重发的时间都是500ms的整数倍

· 如果重发一次后，仍然得不到应答，就等待2 * 500ms后再次重发，如果还是得不到应答，就间隔4 * 500ms再重发，以指数形式递增

· 累计到一定的重传次数后，TCP认为网络或者对端主机出现异常，就会强制关闭连接

连接管理机制

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接

三次握手

三次握手时TCP建立连接，其本质是双方都保存了一个连接状态ESTABUSHED.

` SYN：连接请求/接收报文段

· seq：发送的第一个字节的序号

· ACK：确认报文段

· ack：确认号，希望收到的下一个数据的第一个字节的序号

刚开始客户端处于Closed状态，服务端处于Listen状态

① 第一次握手：客户端向服务端发送一个SYN报文(SYN = 1)，并指明客户端的初始化序列号ISN(x)，即图中的seq = x，表示本报文段所发送的数据的第一个字节的序列号，此时客户端处于SYN_SENT状态(发送连接请求后等待匹配的连接请求)

② 第二次握手：服务端在接收到客户端发送的请求报文段后，会向客户端发送确认报文，在确认报文段中将SYN和ACK置为1，确认号ack = x + 1，同时也为自己选择与i个初始化序列号ISN(y)，seq = y，此时服务端处于SYN_RCVD状态(在收到和发送一个连接请求后等待对连接请求的确认)

③ 第三次握手：客户端在收到服务端的确认后，还要再向服务端给出确认，确认报文段ACK位置为1，把服务端的ISN + 1作为ack的值，表示已经收到了服务端发来的SYN报文，希望收到的下一个数据的第一个字节的序号是y+1，并指明此时客户端的序列号seq = x + 1(因为初始时的seq = x，所以第二个报文段要+1)，此时客户端处于Established状态.服务端在收到ACK报文后，也处于Established状态，至此，双方都建立起了TCP连接.

四次挥手

· FIN：连接终止位

· seq：发送的第一个字节的序号

· ACK：确认报文段

· ack：确认号

① 第一次挥手：客户端发送一个FIN报文(请求终止连接：FIN = 1)，报文中会有一个指定序列号seq = u.并停止发送数据，主动关闭TCP连接，此时客户端处于FIN_WAIT_1状态，等待服务端的确认

② 第二次挥手：服务端收到FIN后，会对客户端发送ACK报文，并把客户端的序列号+1作为ACK报文的序列号值，表明已经收到了客户端的报文，此时客户端处于CLOSE_WAIT状态.

此时的TCP进入半关闭状态，客户端到服务端的连接释放.客户端收到服务端的确认后，进入FIN_WAIT_2(终止等待2)状态，等待服务端发出的连接释放报文段

③ 第三次挥手：如果服务端也想关闭连接，和客户端第一次挥手一样，发送FIN报文，并指定一个序列号此时服务端处于LAST_WAIT状态，等待客户端确认

④ 第四次挥手：客户端收到FIN后，一样发送一个ACK报文作为应答(ack = w + 1)，并把服务端的序列值+1作为自己ACK报文的序号值(seq = u + 1)，此时客户端处于TIME_WAIT状态

流量控制机制

接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会发生丢包，进而引起丢包重传等一系列连锁反应.

TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制机制

· 接收端将自己可以接收的缓冲区大小放在TCP首部中的“窗口大小”字段，通过ACK端通知发送端

· 窗口大小字段越大，说明网络的吞吐率越大

· 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置为一个更小的值通知给发送端

· 发送端接收到这个窗口之后，就会降低发送速度

· 如果接收端缓冲区满了，就将窗口大小设置为0，这时发送端就不再发送数据了，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端

拥塞控制机制

网络状态不明的情况下，如果贸然发送大量数据报，就可能产生网络拥堵.TCP实现拥塞控制的方法：慢启动、拥塞避免、快重传、快恢复

· 慢启动：先发送少量数据，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据

· 发送开始的时候，定义拥塞窗口大小为1

· 每次收到一个ACK应答，拥塞窗口+1

· 每次发送数据报的时候，将拥塞窗口和主机反馈的窗口进行比较，取较小的值作为实际发送的窗口

· 拥塞避免：当拥塞窗口增长达到慢开始门限值后，使拥塞窗口按照线性规律增长

· 当TCP开始启动时，慢启动的阈值等于窗口最大值

· 在每次超时重发(网络拥塞)的时候，慢启动的阈值会变成原来的一半，同时拥塞窗口置为1

· 快重传：当接收端发现丢了一个中间包的时候，立刻发送三次前一个包的ACK，当发送端连续收到三个重复确认，就会快速的重传，不必等待超时再重传.

· 快恢复：快速重传和快恢复一般同时使用，快恢复算法将拥塞窗口调整为原来的一半，即cwnd = cwnd / 2，并使拥塞阈值ssthresh = cwnd，有的快恢复算法是将快恢复开始时的拥塞窗口cwnd的值在增大一些，即cwnd = ssthresh + 3，因为发送方收到了3个重复的确认，就表明有三个分组已经离开了网络.之后再开始执行拥塞避免算法.

效率机制

滑动窗口机制

根据确认应答机制可知，发送端没发送一个数据段，接收端都需要给出一个ACK应答，收到ACK应答后再发送下一个数据段，这样做的话性能比较差，尤其是在数据往返时间较长的情况下.此时就引入了滑动窗口机制：每次发送多条数据，将多个段的等待时间重合在一起，这样就可以提高性能

发送端滑动窗口的大小 = Min(拥塞窗口，接收方流量窗口)

· 窗口大小是指无需等待确认应答而可以继续发送数据的最大值，上图的窗口大小就是4000个字节

· 发送前四个数据段时，不需要等待接收端的ACK应答，直接发送

· 在收到第一个ACK后，滑动窗口向下移动，继续发送第五个数据段，以此类推

· 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有被应答.只有确认应答后的数据，才能从缓冲区删掉

· 发送窗口越大，网路的吞吐率越高