TCP为什么可靠，UDP如何实现可靠，二者区别？ 基金债券稳定吗安全吗可靠吗为什么不可靠

https://blog.csdn.net/Awille/article/details/79748193 https://www.jianshu.com/p/ff36b6ab503e

ACK机制 由于通信过程的不可靠性，传输的数据不可避免的会出现丢失、延迟、错误、重复等各种状况，TCP协议为解决这些问题设计了一系列机制。 这个机制的核心，就是发送方向接收方发送数据后，接收方要向发送方发送ACK（回执）。如果发送方没接收到正确的ACK，就会重新发送数据直到接收到ACK为止。比如：发送方发送的数据序号是seq，那么接收方会发送seq + 1作为ACK，这样发送方就知道接下来要发送序号为seq + 1的数据给接收方了。 ACK机制是怎么工作的： a 数据丢失或延迟。发送方发送数据seq时会起一个定时器，如果在指定时间内没有接收到ACK seq + 1，就把数据seq再发一次。

b 数据乱序。接收方上一个收到的正确数据是seq + 4，它返回seq + 5作为ACK。这时候它收到了seq + 7，因为顺序错了，所以接收方会再次返回seq + 5给发送方。

c 数据错误。每一个TCP数据都会带着数据的校验和。接收方收到数据seq + 3以后会先对校验和进行验证。如果结果不对，则发送ACK seq + 3，让发送方重新发送数据。

d 数据重复。接收方直接丢弃重复的数据即可。

ACK的优化 按照ACK机制，只要整个数据传输顺利结束，接收方就能收到完整有序的数据了。但是，如果我们针对每一个数据包都发送ACK，就会有大量的网络资源消耗在ACK的发送上，这不太划算的。于是，TCP设计了延迟ACK的机制。

这个机制其实很简单。客户端一次给服务器发送多个数据包，当服务器收到客户端的数据包时，不马上发送ACK，而是稍微等一小段时间。在这个过程中服务器可能能收到后续几个数据包，服务器就可以直接按照最后一个正确的数据发送ACK，减少发送ACK的总数。

当发送错误的时候，会发生： a、超时重传机制 发送方发送的报文中含有序列号，每当发送一个报文后，就启动一个计时器（RTO），该计时器的时间一般是有当前网络来决定的，一个RTT指的是当一个报文从发送到接收到对应的ACK标志的时间，RTO的决定一般是发送方尝试发送几个报文，然后取平均RTT时间来决定计时器的值。 当发送一个报文以后，发送方在计时范围以内，如果没有接收到相应的ACK确认报文，那么发送方就会重传该报文。

b、快速重传机制 该机制指的是，发送方一直发送报文，不会每发一次报文就都要等待到这个报文的ACK标志才发送下个报文。 当接收方发现接受的序列号不对的时候，发送连续的3个ACK标志，告诉发送方，这个报文在传输过程中出现了丢包。发送方如果接收到某个相同序列号的三个ACK报文，那么此时立马重发该报文，不用等待计时器的时间结束。

流量控制就是让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

发送方通过维持一个发送滑动窗口来确保不会发生由于发送方报文发送太快接收方无法及时处理的问题。此时发送方的报文分为四类， 第一类是已经发送并且得到接收方确认的报文，第二类是已经发送但是没有接收到确认的报文，第三类是发送方还没发送，但是滑动窗口还足够巨大，允许被发送的报文， 第四类是还没发送并且窗口已经被占满，不允许发送的报文。 一般来说，滑动窗口的最左端都是介于第一类跟第二类报文的分界线，最右端是第三类跟第四类报文的分界线。

滑动窗口的流量控制可以包括那么几个协议： a、停等协议。 滑动窗口的大小为1， 每个发送报文都要等到被确认以后，发送方才继续发送下一个报文。

b、后退n步协议。 该协议下，滑动窗口大于1，发送方可以一直发送报文，但是当接收到接收方发送的三个连续的同一序列号的ACK报文时，说明该序列号的报文是已经丢失的，那么此时重发该丢失报文以及该报文以后的报文（包括那些已经发送的）。

c、选择重传。在后退n步协议当中，如果某个报文丢失，那么将要重新发送这个丢失报文及以后的所有报文（包括已经发送的），选择重传协议不用做此要求，只要重新发送丢失的报文即可。

滑动窗口协议有

1、停等协议，发送窗口=1，接受窗口=1； 2、退后N帧协议，发送>1,接收=1; 3、选择重传协议，发送>1,接收>1;

（rwnd接收窗口的大小）如图所示，说明了利用可变窗口大小进行流量控制。设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,图中的箭头上面大写ACK，表示首部中的却认为为ACK，小写ack表示确认字段的值。

接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300，第二次减小到rwnd=100最后减到rwind=0，即不允许发送方再发送过数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。

假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段，然而这个报文段在传送中丢失 了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若计时器的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

首先要明白拥塞控制与流量控制有什么不同，流量控制考虑的是单纯的发送方与接收方，这两个在全部网络过程中的两个端点。而拥塞控制考虑的是整个网络，防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。可以想象一下，在流量控制当中，接收方跟发送方考虑的只是自己的报文有没有发送并且被接收的问题，假设现在网络阻塞，在超时重传机制当中，发送方没有发送后在计时器时间内没有接收到确认报文，就立马重新发送报文，这时候对已经拥塞的网络来说，无异于雪上加霜。同样实在拥塞的网络情况下，考虑下快速重传机制，同样是这个道理。所以，针对以上问题，TCP应该要有一个拥塞控制机制，不然，后果不堪设想。

在拥塞控制机制中，发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就增大一些，以便把