拥塞控制

文章目录 一、参考书籍 二、必须掌握的内容 1.TCP/IP协议体系的认知 2.数据链路层 3.网络层 4.传输层 5.应用层 三、常见面试题目 1.分层的概念 2.数据链路层 3.网络层 （1）IP协议 （2）ICMP协议 四、传输层 1.UDP协议 2.TCP协议 五、应用层 1.DNS 2.http基本格式 六、参考 一、参考书籍 （1）TCP/IP详解 卷1：协议 （2）计算机网络：自顶向下方法 二、必须掌握的内容 1.TCP/IP协议体系的认知 （1）分层。一部分处于用户态，一部分处于内核态。数据链路层，网络层，传输层封装于操作系统内核态。应用层存在于操作系统的用户空间，包括DNS，FTP，HTTPs，HTTP，工作中接触较多的是应用层的部分。但其它层的原理必须理解，面试考察。 （2）层与层之间下层对上层是透明的，传输在每一层是对等的。 2.数据链路层 （1）以太网帧的格式。 （2）MTU（最大传输单元）的概念。 （3）ARP协议和RARP协议（地址协议和逆地址协议，网卡MAC地址和IP地址互查机制）（网络层和链路层的中间层）ARP报文格式，查询原理，缓存机制 3.网络层 （1）掌握IP首部格式：如16位分片标识、DF不分片标志、MF更多分片标志、13位片偏移、8位生存时间TTL、16位的首部检验和等等。 （2）掌握如何IP分片：如总长大于MTU值，画分片情况

有关TCP你不能不知道的三次握手和四次挥手问题， 点我跳转 流量控制 1. 滑动窗口 数据的传送过程中很可能出现接收方来不及接收的情况，这时就需要对发送方进行控制以免数据丢失。利用滑动窗口机制可以很方便地在TCP连接上对发送方的流量进行控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。 TCP规定，即使设置为零窗口，也必须接收以下几种报文段： 零窗口探测报文段 确认报文段 携带紧急数据的报文段 确认丢失和确认迟到 持续计时器 存在这样一种情况：发送方接收到零窗口报文之后将发送窗口设置为0，停止发送数据。但等到接收方有足够缓存，发送了非零窗口大小的报文，但是这个报文中途丢失，那么发送方的发送窗口就一直为0导致死锁。 为此，TCP为每一个连接设有一个持续计时器(Persistence Timer)：当TCP连接的一方收到对方的零窗口通知时就启动持续计时器。若持续计时器时间到期，就发送一个零窗口探测报文段(携有1字节的数据)，那么收到这个报文段的一方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器；若窗口不是零，则死锁的僵局就可以打破了。 2. 延迟ACK 如果TCP对每个数据包都发送一个ACK确认，那么只是一个单独的数据包为了发送一个ACK代价比较高，所以TCP会延迟一段时间

TCP提供了最可靠的数据传输，它给发送的每个数据包做顺序化（这看起来非常烦琐），然而，如果TCP没有这样烦琐的操作，那么，可能会造成更多的麻烦。如造成数据包的重传、顺序的颠倒甚至造成数据包的丢失。 那么，TCP具体是通过怎样的方式来保证数据的顺序化传输呢？ 主机每次发送数据时，TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收主机对分配的这个序列号进行确认，如果发送主机在一个特定时间内没有收到接收主机的确认，则发送主机会重传此数据包。接收主机利用序列号对接收的数据进行确认，以便检测对方发送的数据是否有丢失或者乱序等，接收主机一旦收到已经顺序化的数据，它就将这些数据按正确的顺序重组成数据流并传递到高层进行处理。 具体步骤如下： （1）为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区； （2）并为每个已发送的数据包启动一个超时定时器； （3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区; （4）否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。 （5）接收方收到数据包后，先进行CRC循环冗余校验(Cyclic Redundancy Check, CRC)校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到

我大概知道他在说什么了，是对内存单元的竞争访问吧。Python有GIL，在执行伪码时是原子的。但是伪码之间不保证原子性。 UDP丢包，你是不是做了盲发？没有拥塞控制的情况下，确实会出现丢包严重的情况。你先看看发送速率，还有是否带有拥塞控制。 https://groups.google.com/forum/#!topic/python-cn/Vivn--4LfGM 来源： https://www.cnblogs.com/yuanjiangw/p/11430179.html

1.TCP发送方变量 cwnd cwnd（拥塞窗口）变量，即发送方一次想发多少字节的数据 cwnd 有一个初始值，RFC 2581 规定，它的大小不超过 2MSS cwnd 是一个动态变化的值，它会根据网络的情况实时的调整自己，最后，cwnd 就会适应网络的情况，以保证发送 cwnd 字节的数据而网络不会拥塞 ssthresh 慢启动门限，这是一个阈值，当 cwnd 超过这个值的时候，慢启动算法结束，进入拥塞避免算法 2.慢启动过程 从前面我们了解到cwnd会变化的，那么cwnd拥塞窗口是怎么控制的 假设cwnd的窗口的单位为MSS，并初始为1，发送后每次收到对方的确认后，cwnd逐渐加1，直到当cwnd大于慢启动门限值ssthresh，将cwmd重新设置为1，并ssthresh减半，并慢启动过程结束，进入拥塞避免 3.拥塞避免过程 当 cwnd > ssthresh 时 无论是在慢启动阶段，还是在拥塞避免阶段，只要发送方判断网络出现拥塞（依据就是没有按照收到确认），就要把 ssthresh 设置为出现拥塞时的 cwnd 值的一半（这里只是举例） 更新了 ssthresh 后，同时将 cwnd 重新设置为 1，又开始执行慢启动算法。这样做的目的是要迅速减少主机发送到网络中的分组数，使得发生拥塞的中间设备有足够的时间把缓冲区中积压的分组处理完毕 来源： https://blog

1.什么是拥塞 如果发送方发送的数据接收方没有收到，那么可以判断在网络上出现了拥塞（前提是接受方对数据来者不拒） 那什么情况下会向出现网络拥塞呢？ 发送方发送太快，交换机或路由器目前还没有能力处理（转发数据都是按照“存储+转发”的方式进行的——即接收到数据后先保存到自己的缓存，然后再挨个处理，发送到对应的接口），也就是接收缓冲区满了，导致发送方接收不到ack确认 发送连续收到重复的 ack 2.什么是拥塞控制 尝试各种不同的发送速度。比如一开始以 100kb/s 的速率发送数据，如果没问题，再将速率提高到 200kb/s，再没问题继续提升发送速率。一旦达到某个上限后，便开始出现丢包现象，发送方就可以认为，网络已经拥塞了，于是降低发送速率，减轻网络负担。 3.拥塞控制算法 慢启动（slow-start） 拥塞避免（congestiono avoidance） 快重传（fast retransmit） 快恢复（fast recovery） 来源： https://blog.csdn.net/Hh20161314/article/details/100133647

关于 TCP 并发连接的几个思考题与试验 TCP 源端口号与目的端口号: 源端口号与目的端口号, 加上IP首部的源IP地址和目的IP地址唯一确定一个TCP连接 序号: 一次TCP通信(从TCP连接建立到断开)过程中某一个传输方向上的字节流编号 确认号: 仅当ACK标志位1时有效. 表示期望下一个字节的序号 头部长度: 标识TCP头部有多少个32bit(4字节). 因为4位最大能表示15, 所以TCP头部长度是60字节 保留位: 6位, 必须全为0 6个标志位: URG: 紧急指针是否有效 ACK: 确认序号是否有效 PSH: 接收方应尽快将这个报文段从TCP接收缓冲区中读走 RST: 表示要求对方中心建立连接. 称携带RST标志的TCP报文为复位报文段 SYN: 请求建立连接. 称携带SYN标志的TCP报文为同步报文段 FIN: 表示通知对方本端要关闭连接. 称携带FIN标志的TCP报文为结束报文段 16位窗口大小: 通过窗口大小来达到流量控制 检验和: 由发送端填充, 接收端对TCP报文执行CRC算法以检验TCP报文在传输过程中是否损坏. TCP特点: 基于字节流 --> 边界问题, 粘包问题 面向连接 可靠传输 缓冲传输 全双工 流量控制 --> 窗口机制 选项与填充(选项为4字节整数倍, 否则用0填充) 最常见的可选字段是最长报文大小MSS(Maximum Segment

本文内容如下： 1）TCP协议概念 2）TCP头部结构和字段介绍 3）TCP流量控制 滑动窗口 4）TCP拥塞控制 慢启动、拥塞避免、快重传、快恢复 有关TCP的三次握手四次挥手单独写了一篇博客: 【TCP协议】---TCP三次握手和四次挥手 有关TCP粘包和黏包,也单独写一篇博客,下一篇博客就写有关粘包黏包问题。 一、TCP概念 TCP(Transmission Control Protocol 传输控制协议)是一种面向连接(连接导向)的、可靠的、 基于IP的传输层协议。 首先来看看OSI的七层模型 我们需要知道TCP工作在网络OSI的七层模型中的第四层——传输层，IP在第三层——网络层，ARP 在第二层——数据链路层;同时，我们需要简单的知道，数据从 应用层发下来，会在每一层都会加上头部信息，进行 封装，然后再发送到数据接收端。这个基本的流程你需要知道，就是每个数据都会经过数据的封装和解封 装的过程。 在OSI七层模型中，每一层的作用和对应的协议如下： 二、TCP头部结构和字段介绍 从上面图片可以看出,TCP协议是封装在IP数据包中。 下图是TCP报文数据格式。TCP首部如果不计选项和填充字段，它通常是20个字节。 下面分别对其中的字段进行介绍： 源端口和目的端口 各占2个字节，这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接

DP、TCP、可靠传输的工作原理、TCP首部格式、TCP可靠传输的实现、TCP流量控制、TCP的拥塞控制、TCP的连接管理这几个方面进行解析。 一、运输层协议概述 1.进程之间的通信 从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。 当两台主机使用网络的核心部分的功能进行点对点通信的时候，只有位于边缘部分的主机的协议栈才有运输层，而网络核心的路由器在转发的时候只有用到下三层的功能。 image 应用进程之间的通信： 两个主机进行通信实际上就是两个主机中的应用进程互相通信。 应用进程之间的通信又称为端到端的通信。 输层的一个很重要的功能就是复用和分用。应用层不同进程的报文通过不同的端口向下交到运输层，再往下就共用网络层提供的服务。 “运输层提供应用进程间的逻辑通信”。“逻辑通信”的意思是：运输层之间的通信好像是沿水平方向传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。 image 运输层的主要功能： 运输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信）。 运输层还要对收到的报文进行差错检测。 运输层需要有两种不同的运输协议，即面向连接的 TCP 和无连接的 UDP。 两种不同的运输协议： 运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等）

1. TCP 流量控制 流量控制就是让发送方的发送速率不要太快，要让接收方来的及接收。 原理是通过确认报文中窗口字段来控制发送方的发送速率，发送方的发送窗口大小不能超过接收方给出窗口大小。 考虑一种特殊的情况，接收方向发送方发送了零窗口的报文段后，接收方又有了一些存储空间。与接收方向发送方发送了非零窗口的报文段。然而这个报文段在传送过程中丢失了。发送方的发送窗口一直为零导致死锁。 为了解决这个问题，每个连接设置有持续计时器，只要连接的一方收到零窗口通知，就启动持续计数器。若持续计数器设置的时间到期，就发送一个零窗口探测报文段，而对方就在确认这个探测报文段给出现在的窗口值。如果窗口仍然为零，那么收到这个报文段的一方重置持续计数器，否则，那么死锁的僵局就可以打破。 2.TCP的拥塞控制 拥塞控制:防止过多的数据注入到网络中，这样可以使网络中的路由器或链路过载。 如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收（端对端的通信），而拥塞控制是为了降低整个网络的拥塞程度（全局性）。 2.1TCP的拥塞控制方法 TCP进行拥塞控制的算法有四种，即慢开始，拥塞避免，快重传，快恢复。 发送方让自己的发送窗口等于拥塞窗口，拥塞窗口的大小取决于网络的拥塞程度