渭南网站建设公司,农产品网站建设背景,淘宝客网站怎么批量采集淘宝商品方维采集淘宝数据思路,海口网站建设托管获取pdf#xff1a;密码7281专栏目录首页#xff1a;【专栏必读】考研湖科大教书匠计算机网络笔记导航 文章目录一#xff1a;流量控制概述二#xff1a;流量控制举例三#xff1a;拓展阅读#xff08;可不看#xff09;#xff08;1#xff09;TCP流量控制完整例子密码7281专栏目录首页【专栏必读】考研湖科大教书匠计算机网络笔记导航 文章目录一流量控制概述二流量控制举例三拓展阅读可不看1TCP流量控制完整例子2操作系统缓冲区与滑动窗口的关系A若应用程序没有及时读取缓冲区B操作系统直接减少缓冲区大小本节对应视频如下 【计算机网络微课堂有字幕无背景音乐版】TCP流量控制 一流量控制概述
流量控制一般来说我们总希望数据能够传输得更快一些但是存在一个问题如果发送方发送数据过快那么接收方就有可能来不及接收从而造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快让接收方能够来得及接收TCP流量控制是利用滑动窗口机制来实现流量控制的
二流量控制举例
如下图A和B是因特网行两台主机它们之间已经建立了TCP连接A给B发送数据B对A进行流量控制。左上角是主机A中待发送数据的字节序号假设主机A发送的每个TCP报文段可携带100字节数据因此图中每个小格子表示100字节数据的序号。在主机A和B建立TCP连接时B告诉A“我的接收窗口为400”因此主机A将自己的发送窗口也设置为400这意味着主机A在未收到主机B发来的确认时可将序号落入发送窗口中的全部数据发送出去 主机B对主机A进行流量控制过程如下 主机A将发送窗口内序号1-100的数据封装为一个TCP报文段发送出去发送窗口内还有300字节可以发送 seq是TCP报文段首部中的序号字段取值为1表示TCP报文段数据载荷的第一个字节序号是1Data是TCP数据报文段 主机A将发送窗口内序号101-200的数据封装为一个TCP报文段发送出去发送窗口内还有200字节可以发送 主机A将发送窗口内序号201-300的数据封装为一个TCP报文段发送出去但丢失了发送窗口内还有100字节可以发送 主机B对主机A所发送的201号之前的数据进行累积确认并在该累积确认中将窗口字段额值调整为300也就是对主机A进行流量控制 ACK是TCP报文段首部中的标志位取值为1表示这是一个TCP确认报文段ack是TCP报文段首部中的确认号字段取值为201表示201之前的数据已全部正确接收现在希望收到序号201及其后续数据rwnd是TCP报文段首部中的窗口字段取值300表示自己的接收窗口大小为300 主机A收到该累积确认后将发送窗口向前滑动使已发送并收到确认的这些数据的序号移出发送窗口 由于主机B在该累积确认中将自己的接收窗口调整为了300因此主机A相应地也将自己的发送窗口调整为300 主机A现在可以将发送缓存中序号1-200的字节数据全部删除了因为已经收到了主机B对它们的累积确认 目前主机A发送窗口内的序号为201-500也即主机A还可以发送这300字节 201-300是已发送的数据若重传计时器超时它们会被重传301-400和401-500还未被发送可被分别封装在一个TCP报文段中发送 主机A将发送窗口内序号301-400的数据封装成一个TCP报文段发送出去发送窗口内还有100字节可以发送 主机A将发送窗口内序号401-500的数据封装成一个TCP报文段发送出去。 至此序号落在发送窗口内的数据已经全部被发送出去了不能再发送新数据了 现在发送窗口内序号201-300这100字节数据的重传计时器超时了主机A将它们重新封装为一个TCP报文段发送出去暂时不能发送其他数据 主机B收到重传的TCP报文段后对主机A所发送的501号之前的数据进行累积确认并在该累积确认中将接收窗口调整为100这是主机B对主机A进行的第二次流量控制 主机A收到该累积确认后将发送窗口向前滑动使以发送并收到确认的这些数据的序号移出发送窗口 由于主机B在该累积确认中将自己的接收窗口调整为了100因此主机A相应地也将自己的发送窗口调整为100 主机A现在可以将发送缓存中序号201-500的字节数据全部删除了因为已经收到了主机B对它们的累积确认 目前主机A发送窗口内的序号为501-600也即主机A还可以发送这100字节 主机A将发送窗口内序号501-600的数据封装成一个TCP报文段发送出去 至此序号落在发送窗口内的数据已经全部被发送出去了不能再发送新数据了 主机B对主机A所发送的601号之前的数据进行累积确认并在该累积确认中将窗口字段的值调整为0这是主机B对主机A进行的第三次流量控制 主机A收到该累积确认后将发送窗口向前滑动使以发送并收到确认的这些数据的序号移出发送窗口 由于主机B在该累积确认中将自己的接收窗口调整为了0因此主机A相应地也将自己的发送窗口调整为0 目前主机A不能再发送一般的TCP报文段了 主机A现在可以将发送缓存中序号501-600的字节数据全部删除了因为已经收到了主机B对它们的累积确认 假设主机B向主机A发送了零窗口的报文段后不久主机B的接收缓存又有了一些存储空间 于是主机B向主机A发送了接收窗口为300的报文段然后它在传输过程中丢失了 主机A一直等待主机B发送的非零窗口的通知 主机B一直等到主机A发送的数据 如果不采取措施这种互相等待的死锁局面将会一直持续下去 为了解决这个问题TCP为每一个连接设置了一个持续计时器只要TCP连接的一方收到对方的零窗口通知就启动持续计时器若持续计时器超时就发送一个零窗口探测报文仅携带一字节的数据而对方在确认这个探测报文段时给出自己现在的接收窗口值。TCP规定即使接收窗口为0也必须接收零窗口探测报文段、确认报文段以及携带有紧急数据的报文段 如果接收窗口仍然为0那么收到这个报文段的一方就会重新启动持续计时器如果接收窗口不是0那么死锁局面就可以被打破 对于本例主机A收到零窗口通知时就启动一个持续计时器当持续计时器超时主机A立刻发送一个仅携带一字节数据的零窗口探测报文段 假设此时主机B的接收窗口又为0了主机B就在确认这个零窗口探测报文段时给出自己现在的接收窗口值为0 主机A再次收到零窗口通知就再次启动一个持续计时器当持续计时器超时主机A立刻发送一个仅携带一字节数据的零窗口探测报文段 假设主机B此时的接收缓存又有了一些存储空间于是将自己的接收窗口调整为了300 主机B就在确认这个零窗口探测报文段时给出自己现在的接收窗口值为300
三拓展阅读可不看
1TCP流量控制完整例子
如下图是一个经典的场景其中客户端是接收方服务端是发送方。假设接受窗口和发送窗口都为200。假设两个设备在传输过程中都保持相同的窗口大小不受外界影响
过程如下
1客户端向服务端发送请求数据报文2服务端受到请求报文后发送确认报文和80字节的数据于是可用窗口可用窗口减少为120字节。同时SND.NXT指针也向右移动80字节指向321意味着下次发送数据序列号为3213客户端收到80字节数据后其接受窗口向右移动80字节RCV.NXT指向321意味着客户端期望的下一个报文序列号是321接着发送确认报文给服务端4服务端再次发送120字节数据可用窗口耗尽为0无法再发送数据5客户端收到120字节数据后接受窗口向右移动120字节RCV.NXT指向441接着发送ACK6服务端收到对80字节数据的确认报文后SUD.UNA指针向右偏移指向321于是可用窗口增大到807服务端受到对120字节的确认报文后SUD.UNA指针向右偏移指向441于是可用窗口增大到2008服务端现在可以继续发送发送160个字节的数据后SND.NXT指向601可用窗口减少到409客户端收到160字节后接收窗口向右移动160字节RCV.NXT指向601接着发送ACK10服务端收到对160字节数据的确认报文后发送窗口向右面移动60字节SND.UNA指针偏移160后指向601可用窗口增大至200 2操作系统缓冲区与滑动窗口的关系
上面的例子中发送窗口和接受窗口的大小是不变的。但在实际情况中发送窗口和接受窗口中存放的字节数都会存放在操作系统中的内存缓冲区因此一定会受到操作系统的控制而被调整。当应用程序由于各种原因未及时读取缓冲区中的内容时也会对缓冲区造成影响
A若应用程序没有及时读取缓冲区
下面的例子展示的是由于应用程序没有及时读取缓冲区时发送窗口和接受窗口的变化情况其中
客户端为发送方服务端为接收方发送窗口和额接受窗口初始大小为360服务端很忙收到客户端数据时应用层未能及时处理数据
过程如下
1客户端发送140字节数据可用窗口变为2202服务端受到140字节数据由于服务器繁忙应用程序仅仅读取了40字节还有100字节占用缓冲区因此接收窗口缩小到260360-100最后发送ACK时将窗口大小告知客户端3客户端收到ACK后将发送窗口减少为2604客户端发送180字节数据可用窗口减少到805服务端收到180字节后但是应用层没有读取任何数据180字节直接留在了缓冲区于是接收窗口缩小到了80260-180最后发送ACK时将窗口大小告知客户端6客户端收到ACK后将发送窗口减少为807客户端发送80字节数据后可用窗口耗尽8服务端收到80字节数据但是应用程序依然没有读取任何数据这80字节仍然留在缓冲区于是接收窗口缩小到了0最后发送ACK时将窗口大小告知客户端9客户端收到ACK后将发送窗口减少为0
最后窗口变为了0也即是发生了窗口关闭。当发送方窗口为0时发送方实际上会定时发送窗口探测报文以便知道接受方的窗口是否发生了改变 B操作系统直接减少缓冲区大小
当服务器系统资源很紧张的时候操作系统可能会直接减少接受缓冲区的大小这时应用程序又无法及时读取缓冲区数据的话那么可能导致丢包现象的产生
过程解释如下
1客户端发送140字节的数据可用窗口减少到了2202服务端因为现在非常繁忙操作系统于是就把接受缓存减少了120字节当收到140字节数据后由因为应用程序没有及时读取数据所以140字节留在了缓冲区中于是接受窗口大小由360缩小到了100。最后发送ACK时通知窗口大小给对方3此时客户端因为还没有收到服务端的ACK所以不知道此时接受窗口缩减到了100客户端只会看到自己的可用窗口还有220于是客户端发送了180字节数据可用窗口减少到了404服务端收到了140字节数据发现数据大小超过了接收窗口的大小于是直接把数据丢了5客户端收到第2步服务端发送的ACK后尝试减少发送窗口到100把窗口的右端向左收缩了80但是在第3步时已经发送了超过100字节的数据所以可用窗口出现负值
所以如果发生了先减少缓存再收缩窗口就会出现丢包的现象。因此为了防止这种情况发生TCP规定不允许同时减少缓存又收缩窗口的而是先收缩窗口一定时间后再减少缓存
