LINUX网络编程：Tcp(2)

最新推荐文章于 2024-10-14 16:42:33 发布

W2155

最新推荐文章于 2024-10-14 16:42:33 发布

阅读量750

点赞数 10

文章标签： linux 运维服务器

本文链接：https://blog.csdn.net/W2155/article/details/142497943

版权

2.滑动窗口

3.拥塞控制

3.1慢启动

3.2拥塞窗口的增长

1.Tcp流量控制

为什会有流量控制？

1.在网络通信中，假如发送方的发送能力特别的强，接受方的接受缓冲区都满了，发送方还在继续发，这些多余的报文就会被丢弃，这就造成了网络资源的浪费。

2.接受方的接受能力特别强，接受方的接受缓冲区，一直是空的，接收方都快饿死了，

所以接收方需要告知发送方自己的接受能力。

当接受方对发送方进行 ACK时，Tcp报头中是有一个16位窗口大小的，16位窗口大小就是接受缓冲区剩余的大小，当接受缓冲区满了，16位窗口大小就为0。

2.滑动窗口

在tcp在发送消息的时候，不是一条一条的发送的，这样数据往返时间太长了，效率太低了。

Tcp会一口气发送多条消息，在一起收到多条应答。

那这时候就会有个问题，到底一次发送多少消息合适呢？

在tcp缓冲区中存在一个窗口，在这个窗口内的数据，不用收到任何ACK，直接就可以发送给对方。

滑动窗口本质就是两个数组的下标，一个指向窗口的开始，一个指向窗口的结束。

int win_begin = 2001 , int win_end = 6001。

2.1滑动窗口的更新

滑动窗口的大小是根据ACK应答中的16位窗口大小和确认序号，实时更新的。

确认序号就是下次该发送数据的下标。

例：收到的ACK确认序号是3001，16位窗口大小是 5000，那么滑动窗口该如何更新呢？

win_begin = 确认序号， win_end = 确认序号 + 16位窗口大小。(暂时这样认为)

2.2滑动窗口的丢包问题

1.报文丢失的情况

例：1001 - 2001 这个报文丢失

1001 - 2001 这个报文丢失所以1001 - 2001 这段报文是没有返回ACK的，根据确认序号的定义，确认序号保证确认序号之前的数据已经被收到，因为1001丢失，所以剩下所有报文ACK的确认序号都是1001，因为只有1001之前的所有数据被主机B收到了。

这里不得不提到Tcp的快重传机制

连续3个ACK确认序号都是相同的时候，这时候需要迅速对其进行补发，不用等待超时重传。

当主机B收到1001-2001的这个数据时候，7001之前的所有数据都被收到了，补发报文ACK的确认序号不就是7001吗。