运输层协议---TCP协议总结


TCP概述

TCP,Transmission Control Protocol(传输控制协议)是一种面向连接,可靠的,基于字节流服务的传输层的通信协议。
面向连接:TCP和UDP不同,TCP是面向连接的,关于面向连接,是指通信的双方要先建立连接,然后才能进行数据的读写。这是字节流服务的特点,通信双方的线路是存储在路由器中的。相当于一个“虚电路”。
可靠:TCP通过应答确认和超时重传的机制保证通信是可靠的。TCP是把数据交给IP层,从IP层的角度看,如果网络环境不好,就会出现丢包的情况,这是无法避免的,IP层只是尽自己最大的努力吧数据传输过去,TCP对此也无能为力,只能通过自身的算法来弥补网络环境不好造成的不足。

TCP报文结构

在这里插入图片描述
序号:和确认号两者共同保证TCP的可靠性。序号是建立在传送的字节流之上,而不是建立在传送的报文段之上。通俗的讲就是序号是以字节为单位进行编号,每个字节对应一个字节流编号,这个工作由TCP协议底层完成,我们用户是感受不到的。一个报文段的序号是该报文段首字节的字节流编号。

假设主机A的一个进程想通过一条TCP连接向主机B上的一个进程发送一个数据流,主机A中的TCP将隐式地对数据流中的每一个字节编号。假定数据流由一个包含500 000字节的文件组成,其MSS(最大报文段长度)为1000字节,数据流的首字节编号是0,如下图所示:
在这里插入图片描述
该TCP将为该数据流构建500个报文段,给第一个报文段分配序号0,第二个报文段分配序号1000,以此类推,每一个序号被填入到相应TCP报文段首部的序号字段中

确认号:TCP是全双工的,即主机A在向主机B发送数据的同时,也许也在接收来自主机B的数据。从主机B到达的每个报文段中都有一个序号用于从B流向A的数据。主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。

例子1:假设主机A已经收到了来自主机B的编号为0-535的所有字节,同时假设它打算发送一个报文段给主机B,主机A等待主机B的数据流中字节536及其后的所有字节,所以主机A会在它发往主机B的报文段的确认号字段中填上536。(即seq + 1)。
例子2:假设主机A已收到主机B的包含字节0-535字节的报文段,以及另一个包含字节900-1000的报文段。由于某种原因,主机A还没有收到字节536-899的报文段。在这个例子里,主机A为了重新构建主机B的数据流,仍在等待字节536(和其后的字节)。因此,A到B的下一个报文段将在确认号字段中包含536。因为TCP只确认该流中到第一个丢失字节为止的字节,所以TCP提供的是累积确认
主机A虽然收到了字节900-1000的报文段,但是并不会在下一个发往主机B的报文段的确认号字段中填1001,因为535后面的字节还没有得到确认,而收到的900-1000字节的报文段属于失序到达,对于失序到达的报文段的处理方法由TCP编程人员去具体实现,有两个基本选择:一是丢弃失序报文段,二是保留失序字节并等待缺少的字节以填补该间隔(这是实践中采用的方法)

标志位
SYN(请求建立连接–synchronous)
FIN (请求断开连接–finish)
RST(重新建立连接–reset 复位报文段
ACK(确认 – acknowledgement)
URG(表示紧急指针域有效–urgent)
PSH(push操作)所谓Push操作就是指在数据包到达接收端以后,立即传送给应用程序,而不是在缓冲区中排队

窗口大小:用来流量控制,指示接收方愿意接受的字节数量。由接收端填充。

4位 头部长度:标识该TCP头部有多少个32bit字(4字节)。因为4位最大能标识15,所以TCP头部最长是60字节。

16位校验和:由发送端填充,接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意,这个校验不仅包括TCP头部,也包括数据部分。这也是TCP可靠传输的一个重要保障。

16位紧急指针:是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此,确切地说,这个字段是紧急指针相对当前序号的偏移,不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。

TCP头部选项:TCP头部的最后一个选项字段(options)是可变长的可选信息。这部分最多包含40字节,因为TCP头部最长是60字节

TCP连接的建立与释放

三次握手四次挥手

TCP可靠性传输

应答确认

是指每次发送端给接收端发送一段数据m1,接收端收到数据之后会给客户端回复一个ACK报文,表明数据已经收到。在发送方未收到m1的确认信息之前,m1应该保留。直到收到确认信息才能丢弃。
在这里插入图片描述
在这里插入图片描述

超时重传

超时重传是指当发送端发送数据给接收端的时候会设置一个定时器,当超过定时器的时间,仍然没有接收到来自接收端的应答回复,这时候发送端就认为发送的数据没有到达接收端,将会重新发送数据给接收端。
关于没有接收到数据有两种情况:①发送的数据确实没有到达接收端 ②发送的数据到达了接收端,但是接收端回复的ack报文没有到达发送端,这种情况当接收端再次接到同样的报文的时候会丢弃重复的报文。
超时重传最核心的是确定超时重传的时间,这个时间不能过长,因为会导致访问变慢,但也不能过短,因为报文还没传输完成就认为没有到达,重新发送,引起不必要的重传即时间必须大于往返时间(RTT)。
在这里插入图片描述

快速重传

在超时重传中,重点是定时器溢出超时了才认为发送的数据包丢失,快速重传机制,实现了另外的一种丢包评定标准,即如果我连续收到3次dup ACK,发送方就认为这个seq的包丢失了,立刻进行重传,这样如果接收端回复及时的话,基本就是在重传定时器到期之前,提高了重传的效率。

在传输过程中会出现out-of-order的现象,但是在滑动窗口中会有严格的顺序控制,假设有4,5,6三个待接收的数据包,先收到了5,6,协议栈是不会回复对5,6包的确认,而是根据TCP协议的规定,当接收方收到乱序片段时,需要重复发送ACK, 在这个地方会发送报文4 seq的ACK,表明需要报文4没有被接收到,如果此后收到的是报文7,那么仍然要回报文4 seq的ACK如果连续发送3个 dup ACK,接收端认为这个片段已经丢失,进行快速重传。也就是tcp回复的确认号是我下次想接收到的序号。

乱序重排

TCP具有乱序重排的功能。当发送端想接收端发送数据的时候,可能某一条线路堵塞导致先发送的数据可能后到达,对于传输层来说,可能报文顺序乱了,但是传输层会根据报文序号排序,再交给应用层。

流量控制

一般来说,我们希望数据传输的更快一些,不会一次只发一个字节,但是如果太快的话,接收方可能没有足够的时间接收数据,造成数据的丢失。所谓流量控制就是让发送方不要发送的太快,让接收方也有足够的时间接收。TCP利用滑动窗口实现流量控制。

在 TCP 的报头中有一个字段叫做接收通告窗口,这个字段由接收端填充,是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。所以发送端就会有一个发送窗口,这个发送窗口的大小是由接收端填充的接收通告窗口的大小决定的,并且窗口的位置会随着发送端数据的发送和接收到接收端对数据的确认而不断的向右滑动,将之称为滑动窗口。

在这里插入图片描述
在这里插入图片描述
流程:
图片1
在这里插入图片描述
死锁
在这里插入图片描述
死锁的解决

TCP为每一个连接设置一个持续计时器,如果TCP的一端收到另一端的0窗口报文,就是启动持续计时器,让持续计时器时间到的时候,会向另一方发送一个探测报文(携带一字节数据),另一方如果收到之后,会回复自己的窗口状态,如果窗口仍然为0,那么继续启动持续计时器,如果不是0,那么死锁的僵局就可以打破了。

在这里插入图片描述
TCP规定即使接收窗口为0,也要接受确认报文段,零窗口探测报文段,携带有紧急数据的报文段。

rwnd:receive Window 接收窗口

注意点:
在这里插入图片描述

TCP拥塞控制

拥塞控制概念

 拥塞控制也是通过窗口的大小来控制的,前面的滑动窗口rwnd是怕发送方把接收方缓存塞满,拥塞窗口cwnd是怕把网络塞满。(congestion window )

 在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏。这种情况就叫做拥塞(congestion)。
 在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等,都是网络的资源。
若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降。

图示:
拥塞控制描述图
理想状态下的拥塞控制是输入负载等于吞吐量。

TCP拥塞控制算法

  • 慢开始算法
  • 拥塞避免算法
  • 快重传算法
  • 快恢复算法

介绍算法之前,我们假定这些条件:
在这里插入图片描述
慢开始和拥塞避免
在这里插入图片描述

慢开始算法是将拥塞窗口的值指数级增长
拥塞避免算法是将拥塞窗口的值递增增长

图示:
在这里插入图片描述
快重传算法
在这里插入图片描述
在这里插入图片描述
快恢复算法
在这里插入图片描述
四种算法的描述:
在这里插入图片描述
在这里插入图片描述
粘包及解决方案

参考:计算机网络微课堂.湖科大教书匠

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值