asp.net 跳转别的网站,sae wordpress 4.3,青岛个人接网站建设,在阿里云上建立网站的步骤客户端每发送的一个包#xff0c;服务器端都应该有个回复#xff0c;如果服务器端超过一定的时间没有回复#xff0c;客户端就会重新发送这个包#xff0c;直到有回复。
为了保证顺序性#xff0c;每一个包都有一个 ID。在建立连接的时候#xff0c;会商定起始的 ID 是什…客户端每发送的一个包服务器端都应该有个回复如果服务器端超过一定的时间没有回复客户端就会重新发送这个包直到有回复。
为了保证顺序性每一个包都有一个 ID。在建立连接的时候会商定起始的 ID 是什么然后按照 ID 一个个发送。为了保证不丢包对于发送的包都要进行应答但是这个应答也不是一个一个来的而是会应答某个之前的 ID表示都收到了这种模式称为累计确认或者累计应答cumulative acknowledgment。
为了记录所有发送的包和接收的包TCP 也需要发送端和接收端分别都有缓存来保存这些记录。发送端的缓存里是按照包的 ID 一个个排列根据处理的情况分成四个部分。
1、发送了并且已经确认的。这部分就是你交代下属的并且也做完了的应该划掉的。
2、发送了并且尚未确认的。这部分是你交代下属的但是还没做完的需要等待做完的回复之后才能划掉。
3、没有发送但是已经等待发送的。这部分是你还没有交代给下属但是马上就要交代的。
4、没有发送并且暂时还不会发送的。这部分是你还没有交代给下属而且暂时还不会交代给下属的。
在 TCP 里接收端会给发送端报一个窗口的大小叫 Advertised window。这个窗口的大小应该等于上面的第二部分加上第三部分就是已经交代了没做完的加上马上要交代的。超过这个窗口的接收端做不过来就不能发送了。 对于接收端来讲它的缓存里记录的内容要简单一些。
1、接受并且确认过的。也就是我领导交代给我并且我做完的。
2、还没接收但是马上就能接收的。也即是我自己的能够接受的最大工作量。
3、还没接收也没法接收的。也即超过工作量的部分实在做不完。 AdvertisedWindowMaxRcvBuffer-((NextByteExpected-1)-LastByteRead)。
一种方法就是超时重试也即对每一个发送了但是没有 ACK 的包都有设一个定时器超过了一定的时间就重新尝试。但是这个超时的时间如何评估呢这个时间不宜过短时间必须大于往返时间 RTT否则会引起不必要的重传。也不宜过长这样超时时间变长访问就变慢了。
估计往返时间需要 TCP 通过采样 RTT 的时间然后进行加权平均算出一个值而且这个值还是要不断变化的因为网络状况不断地变化。除了采样 RTT还要采样 RTT 的波动范围计算出一个估计的超时时间。由于重传时间是不断变化的我们称为自适应重传算法Adaptive Retransmission Algorithm。
TCP 的策略是超时间隔加倍。每当遇到一次超时重传的时候都会将下一次超时时间间隔设为先前值的两倍。两次超时就说明网络环境差不宜频繁反复发送。
有一个可以快速重传的机制当接收方收到一个序号大于下一个所期望的报文段时就会检测到数据流中的一个间隔于是它就会发送冗余的 ACK仍然 ACK 的是期望接收的报文段。而当客户端收到三个冗余的 ACK 后就会在定时器过期之前重传丢失的报文段。
LastByteSent - LastByteAcked min {cwnd, rwnd} 是拥塞窗口和滑动窗口共同控制发送的速度。
对于到网络上通道的容量 带宽 × 往返延迟。
一条 TCP 连接开始cwnd 设置为一个报文段一次只能发送一个当收到这一个确认的时候cwnd 加一于是一次能够发送两个当这两个的确认到来的时候每个确认 cwnd 加一两个确认 cwnd 加二于是一次能够发送四个当这四个的确认到来的时候每个确认 cwnd 加一四个确认 cwnd 加四于是一次能够发送八个。可以看出这是指数性的增长。
涨到什么时候是个头呢有一个值 ssthresh 为 65535 个字节当超过这个值的时候就要小心一点了不能倒这么快了可能快满了再慢下来。
每收到一个确认后cwnd 增加 1/cwnd我们接着上面的过程来一次发送八个当八个确认到来的时候每个确认增加 1/8八个确认一共 cwnd 增加 1于是一次能够发送九个变成了线性增长。
拥塞的一种表现形式是丢包需要超时重传这个时候将 sshresh 设为 cwnd/2将 cwnd 设为 1重新开始慢启动。这真是一旦超时重传马上回到解放前。但是这种方式太激进了将一个高速的传输速度一下子停了下来会造成网络卡顿。
快速重传算法。当接收端发现丢了一个中间包的时候发送三次前一个包的 ACK于是发送端就会快速地重传不必等待超时再重传。TCP 认为这种情况不严重因为大部分没丢只丢了一小部分cwnd 减半为 cwnd/2然后 sshthresh cwnd当三个包返回的时候cwnd sshthresh 3也就是没有一夜回到解放前而是还在比较高的值呈线性增长。 TCP 的拥塞控制主要来避免的两个现象都是有问题的。
第一个问题是丢包并不代表着通道满了也可能是管子本来就漏水。例如公网上带宽不满也会丢包这个时候就认为拥塞了退缩了其实是不对的。
第二个问题是 TCP 的拥塞控制要等到将中间设备都填充满了才发生丢包从而降低速度这时候已经晚了。其实 TCP 只要填满管道就可以了不应该接着填直到连缓存也填满。 TCP BBR 拥塞算法。它企图找到一个平衡点就是通过不断地加快发送速度将管道填满但是不要填满中间设备的缓存因为这样时延会增加在这个平衡点可以很好的达到高带宽和低时延的平衡。 此文章为9月Day12学习笔记内容来源于极客时间《趣谈网络协议》推荐该课程。
