TCP太多重传!

TCP太多重传!,第1张

可能的原因:
1交换机或路由器过载使TCP包或确认包丢失;
2接收端对TCP包的确认速度慢,致使发送端超时重发;
3接收端缓存溢出;
4TCP数据在传输过程中丢失或损坏;
5发送端与接收端之间的距离太远或传输速度太慢;
请检查:
1交换机或路由器的工作状态;
2接收主机正在运行的服务;
3检查接收主机的工作状态

重传机制是tcp最重要和最复杂的问题之一
TCP每发送一个报文段,就对这个报文段设置一个计时器,只要计时器设置的重传时间到了还没有收到确认,就要重传这一报文段。
tcp采用自适应算法,就是记录每一个报文段发出的时间,以及收到相应的确认报文段的时间。这两个时间差就是报文段的往返时延rtt,把各个报文段的往返时延样本加权平均,就得出报文段的平均往返时延。每测量到一个新的rtt样本,就按下试重新计算一次平均rtt:
平均rtt=a(旧rtt)+(1-a)(新rtt样本) 0《=a<1; a 典型值为7/8
计时器设置的超时重传时间rto应略大于上面的平均往返时延rtt
即 rto=brtt
tcp原先的标准推荐吧b取2
由于如果发出一个tcp报文段1后重传时间到后在重新发送报文段2 如果收到确认报文段ACK 我们将无法判断是对报文段1 的确认还是2的确认(报文段1和重传报文段2是完全一样的) 因此Karn提出了一个算法:在计算平均rtt时,只要报文段重传了,就不采取七往返时延样本。这样得出的平均rtt和重传时间就较准确 但又因为这样将无法更新重传时间,所以要对Karn算法进行修正:报文段每重传一次,就将重传时间增大一些
新的重传时间=r旧的重传时间 r的典型值为2

有了超时就要有重传,但是就算是重传也是有策略的,而不是将数据简单的发送。 前面曾经提到过,数据在传输的时候不能只使用一个窗口协议,还需要有一个拥塞窗口来控制数据的流量,使得数据不会一下子都跑到网路中引起“拥 塞”。也曾经提到过,拥塞窗口最初使用指数增长的速度来增加自身的窗口,直到发生超时重传,再进行一次微调。但是没有提到,如何进行微调,拥塞避免算法和 慢启动门限就是为此而生。
所谓的慢启动门限就是说,当拥塞窗口超过这个门限的时候,就使用拥塞避免算法,而在门限以内就采用慢启动算法。所以这个标准才叫做门限,通常,拥塞窗口记做cwnd,慢启动门限记做ssthresh。下面来看看拥塞避免和慢启动是怎么一起工作的。 这是数据丢包的情况下给出的一种修补机制。一般来说,重传发生在超时之后,但是如果发送端接受到3个以上的重复ACK的情况下,就应该意识到,数据丢了,需要重新传递。这个机制是不需要等到重传定时器溢出的,所以叫做快速重传,它可以避免发送端因等待重传计时器的超时而空闲较长时间,以此增加网络吞吐量。而重新传递以后,因为走的不是慢启动而是拥塞避免算法,所以这又叫做快速恢复算法。流程如下:
当收到第3个重复的ACK时,将ssthresh设置为当前拥塞窗口cwnd的一半。重传丢失的 报文段。设置cwnd为ssthresh加上3倍的报文段大小。每次收到另一个重复的ACK时, cwnd增加1个报文段大小并发送1个分组(如果新的 cwnd允许发送)。当下一个确认新数据的ACK到达时,设置cwnd为ssthresh(在第1步中设置的值)。这个 ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外,这个ACK也应该是对丢失的分组和收到的第1个重复的ACK之间的所有中间报文段 的确认。这一步采用的是拥塞避免。ICMP不会引起重新传递,TCP会坚持用自己的定时器,但是TCP会保留下ICMP的错误并且通知用户。 TCP为了提高自己的效率,允许再重新传输的时候,只要传输包含重传数据报文的报文就可以,而不用只重传需要传输的报文。

一个数据包的生命过程:数据包如何送达主机、主机如何将数据包转交给应用、数据是如何被完整地送达应用程序

互联网,实际上是一套理念和协议组成的体系架构 。其中,协议是一套众所周知的规则和标准,如果各方都同意使用,那么它们之间的通信将变得毫无障碍。数据通信是通过数据包来传输的。如果发送的数据很大,那么该数据就会被拆分为很多小数据包来传输。之后再由接收方按照数据包中的一定规则将小的数据包整合成全部数据。

IP 是非常底层的协议,只负责把数据包传送到对方电脑,不负责该数据包将由哪个程序去使用。

数据包要在互联网上进行传输,就要符合网际协议(Internet Protocol,简称 IP)标准。计算机的地址就称为 IP 地址,访问任何网站实际上只是你的计算机向另外一台计算机请求信息。

简单理解数据传输过程就是:装包和拆包。 如果要想把一个数据包从主机 A 发送给主机 B,那么在传输之前,数据包上会被附加上主机 B 的 IP 地址信息,这样在传输过程中才能正确寻址。额外地,数据包上还会附加上主机 A 本身的 IP 地址,有了这些信息主机 B 才可以回复信息给主机 A。这些附加的信息会被装进一个叫 IP 头的数据结构里。IP 头是 IP 数据包开头的信息,包含 IP 版本、源 IP 地址、目标 IP 地址、生存时间等信息。

过程:

1、上层将含有“数据”的数据包交给网络层;

2、网络层再将 IP 头附加到数据包上,组成新的 IP 数据包,并交给底层;

3、底层通过物理网络将数据包传输给主机 B;

4、数据包被传输到主机 B 的网络层,在这里主机 B 拆开数据包的 IP 头信息,并将拆开来的数据部分交给上层;

5、最终,含有“数据”信息的数据包就到达了主机 B 的上层了。

基于 IP 之上开发能和应用打交道的协议,最常见的是“用户数据包协议(User Datagram Protocol)”,简称 UDP。负责将传输的数据包交给某一应用程序。

UDP 中一个最重要的信息是端口号,端口号其实就是一个数字,每个想访问网络的程序都需要绑定一个端口号。通过端口号 UDP 就能把指定的数据包发送给指定的程序了, 所以 IP 通过 IP 地址信息把数据包发送给指定的电脑,而 UDP 通过端口号把数据包分发给正确的程序。 和 IP 头一样,端口号会被装进 UDP 头里面,UDP 头再和原始数据包合并组成新的 UDP 数据包。UDP 头中除了目的端口,还有源端口号等信息。

为了支持 UDP 协议,我把前面的三层结构扩充为四层结构,在网络层和上层之间增加了传输层

过程:

1、 上层将数据包交给传输层;传输层会在数据包前面附加上 UDP 头,组成新的 UDP 数据包,再将新的 UDP 数据包交给网络层;

2、网络层再将 IP 头附加到数据包上,组成新的 IP 数据包,并交给底层;

3、数据包被传输到主机 B 的网络层,在这里主机 B 拆开 IP 头信息,并将拆开来的数据部分交给传输层;

4、在传输层,数据包中的 UDP 头会被拆开,并根据 UDP 中所提供的端口号,把数据部分交给上层的应用程序;

5、最终,含有信息的数据包就旅行到了主机 B 上层应用程序这里。

在使用 UDP 发送数据时,有各种因素会导致数据包出错,虽然 UDP 可以校验数据是否正确,但是对于错误的数据包, UDP 并不提供重发机制,只是丢弃当前的包 ,而且 UDP 在发送之后也无法知道是否能达到目的地。虽说 UDP 不能保证数据可靠性,但是传输速度却非常快 ,所以 UDP 会应用在一些关注速度、但不那么严格要求数据完整性的领域,如在线视频、互动游戏等

上文说到的使用 UDP 来传输会存在两个问题 :

1、数据包在传输过程中容易丢失;

2、大文件会被拆分成很多小的数据包来传输,这些小的数据包会经过不同的路由,并在不同的时间到达接收端,而 UDP 协议并不知道如何组装这些数据包,从而把这些数据包还原成完整的文件。

所以TCP协议很好地解决的这个问题。

TCP(Transmission Control Protocol,传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。

1、对于数据包丢失的情况,TCP 提供重传机制;

2、TCP 引入了数据包排序机制,用来保证把乱序的数据包组合成一个完整的文件。

和 UDP 头一样,TCP 头除了包含了目标端口和本机端口号外,还提供了 用于排序的序列号 ,以便接收端通过序号来重排数据包

一个完整的 TCP 连接的生命周期包括了“建立连接”“传输数据”和“断开连接”三个阶段。

首先,建立连接阶段。这个阶段是通过“三次握手”来建立客户端和服务器之间的连接。TCP 提供面向连接的通信传输。面向连接是指在数据通信开始之前先做好两端之间的准备工作。所谓 三次握手 ,是指在建立一个 TCP 连接时,客户端和服务器总共要发送三个数据包以确认连接的建立。

其次,传输数据阶段。在该阶段,接收端需要对每个数据包进行确认 *** 作,也就是接收端在接收到数据包之后,需要发送确认数据包给发送端。所以当发送端发送了一个数据包之后,在规定时间内没有接收到接收端反馈的确认消息,则判断为数据包丢失,并触发发送端的重发机制。同样,一个大的文件在传输过程中会被拆分成很多小的数据包,这些数据包到达接收端后,接收端会按照 TCP 头中的序号为其排序,从而保证组成完整的数据。

最后,断开连接阶段。数据传输完毕之后,就要终止连接了,涉及到最后一个阶段“ 四次挥手 ”来保证双方都能断开连接。

三次握手和四次挥手限于篇幅可看另一篇文章: TCP协议中 的三次握手和四次挥手

1、IP 负责把数据包送达目的主机。

2、UDP 负责把数据包送达具体应用(可能会丢包)。

3、而 TCP 保证了数据完整地传输 ,它的连接可分为三个阶段:建立连接、传输数据和断开连接。

完整的数据流程


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/10587870.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-09
下一篇 2023-05-09

发表评论

登录后才能评论

评论列表(0条)

保存