计算机网络|计算机网络之TCP协议相关问题


文章目录

  • TCP三次握手
    • 为什么选择三次握手?
    • 如何处理丢包问题&&如何保证乱序问题
  • TCP四次挥手
    • 为什么要有超时等待状态
  • TCP拥塞控制
    • 问题描述
    • 四种拥塞控制算法

TCP三次握手 先对几个包进行概述
SYN包:看是否能建立连接
SYN-ACK包:如果服务器同意连接会发送SYN-ACK包
【计算机网络|计算机网络之TCP协议相关问题】ACK包:客户端收到服务器的回复会发送ACK包
计算机网络|计算机网络之TCP协议相关问题
文章图片

三次握手机制:
第一次:客户端尝试与服务器端建立连接,发送SYN=1包,同时选择一个随机数seq=x作为初始序列号
第二次:服务器端收到客户端的SYN包,如果同意连接,向客户端发送SYN-ACK包,确认号为ack = x+1,同时选择一个随机数seq = q作为初始序列号
第三次:客户端收到服务器端的确认后,发送一个确认报文ACK = 1,完成三次握手
总结:总共发送了三包数据SYN SYN-ACK ACK
为什么选择三次握手? 为了防止已经失效的请求报文再次发送到服务器端引起错误
两次握手出现的问题:
  1. 客户端发送SYN包请求与服务器端进行连接,这时网络发生阻塞现象未达到服务器端,为了建立连接客户端再次发送SYN进行连接,这次包正常发送正常.
  2. 服务器端发送SYN-ACK到客户端建立连接,但是第一个包阻塞节点突然恢复,与服务器端进行连接,这时服务器以为是新的连接.客服端认为是一次连接,服务器端认为是两次连接,造成状态不一致
在三次握手下,客户端收不到ACK包,自然不会认为连接成功
如何处理丢包问题&&如何保证乱序问题 ? TCP协议为每个连接建立一个缓冲区,建立连接后的第一个字节的序列号为0,后面的每个序列号会+1,在发送数据时,从缓冲区取一部分数据组成发送报文,在TCP协议头中会附带序列号和长度,在接收端收到数据后,需要回复确认收到,确认报文中的ACK=序列号+长度 = 下一包传送的起始位置,这样一问一答的发送方式能够使发送端的数据已被对方收到,发送端也可以发送多包数据,接收端只需要回复一次ACK就可以.
? 这样发送端可以把待发送的数据分割成一系列碎片,发送到对端,对端根据序列号和长度在接收后重构出来完整的数据,假设其中丢失了某些数据包,就要进行重传
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BQdqZpmH-1654937133689)(C:\Users\小刘同学\AppData\Roaming\Typora\typora-user-images\image-20220611160850145.png)]
发送报文:序列号长度+数据内容
回复确认:ACK = 序列号长度 + 长度 = 下一包起始序列号
TCP四次挥手 计算机网络|计算机网络之TCP协议相关问题
文章图片

四次挥手过程描述:
  1. 客户端要与服务器端断开连接,向服务器端发送一个FIN包,表示要断开连接,客户端进入终止等待状态
  2. 服务器端收到FIN包,发送ACK包表示自己进入关闭等待状态,客户端进入终止等待状态
  3. 服务器端此时还可以发送未发送的数据,客户端还可以接受数据,服务器端发送完数据,发送FIN包进入最后确认状态
  4. 客户端收到之后回复ACK包,进入超时等待状态,超时等待状态过后断开连接
为什么要有超时等待状态 这是为了保证对方已收到ACK包,因为假设客户端发送完最后一包就释放了连接,一旦ACK包在网络中丢失,服务器端一直等待停留在最后确认状态,就无法正常断开连接。如果等待一段时间后,服务器端重发FIN,客户端会响应FIN包,重发ACK包,并刷新超时时间,和三次握手一样,保证不可靠的网络连接中进行可靠的连接
TCP拥塞控制 问题描述 拥塞概念:在某段时间,对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏
  • 在计算机网络中的链路容量(宽带),交换节点中的缓存和处理机都是网络的资源
问题描述:如果出现拥塞不进行控制,整个网络的吞吐量将随输入负荷的增大而下降
在理想状态下,达到吞吐量饱和之前,网络吞吐量应等于输入负载,超过某一限度时,吞吐量达到饱和
实际上,随着输入负载的增大,吞吐量进入轻度拥塞,当输入负载到达某一状态时,吞吐量和输入负载成反比,到达一定程度,出现死锁.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jHx3hX5v-1654937133690)(C:\Users\小刘同学\AppData\Roaming\Typora\typora-user-images\image-20220609154705198.png)]
四种拥塞控制算法
  1. 慢开始
  2. 拥塞避免
  3. 快重传
  4. 快恢复
假定如下条件
  • 数据是单向传送,另一方只传送确认
  • 接受方有足够大的缓存空间,因而发送方发送窗口的大小由网络的拥塞程度来决定
  • 以最大报文段MSS的个数为讨论问题的单位,而不是以字节为单位
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OUNRV2Su-1654937133690)(C:\Users\小刘同学\AppData\Roaming\Typora\typora-user-images\image-20220609160103344.png)]
双发维护一个拥塞窗口CWND,
维护原则:网络中没有阻塞时,拥塞窗口尽可能大一些,网路中有阻塞时,拥塞窗口尽可能小一些
  • 慢开始: 慢开始算法的思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。经验表明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1,每经过一个传播轮次,cwnd 加倍。
  • 拥塞避免: 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大,即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1。
  • 快重传与快恢复:
    在 TCP/IP 中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。有了 FRR,就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时,快速重传和恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作.

    推荐阅读