TCP可靠性、滑动窗口、流量控制、拥塞控制。

1.  概念：TCP是面向连接的以字节流方式传输的协议，他提供可靠、有序。全双工的传输（TCP通信的每一段都维护着一个发送缓存和接收缓存）。TCP连接的端点不是主机中的应用进程，而是应用进程维护的套接字接口（socket），其基本的结构包含【IP：Port】。

2.  TCP可靠传输的工作原理

TCP实现可靠传输的工作原理主要有两个，我们分别来看：

1)  停止等待协议

*1. 发送方A向接收方B发送数据分组M1；

*2. 接收方B收到分组M1后向A发送M1的确认；

*3. A接收到B发送的对于M1后的确认之后再发送分组M2；

*4. 若中间的某一个分组丢失或是延迟，则A就会使用超时计时器进行超时重传，每个分组发送时都会保留其副本并且设置超时计时器；

上面的机制保证了在不可靠的信道上时间可靠的传输，这种机制称为自动重传请求(ARQ)，即重传的请求是自动的，不需要接收方向发送方请求重传某个分组。

2)  连续ARQ协议

停止等待协议的优点是简单，缺点是信道利用率太低。为此我们引入了连续ARQ协议和滑动窗口协议。

首先是连续ARQ协议：举个例子，A与B通信，发送方A缓存里面有一个长度为5的发送窗口，窗口里面有12345字节。A连续发12345给接收方B。A窗口中的数据在B没有发送确认收到之前，不能从缓存中删除。但B不是来一个数据包就确认一次，是累积确认的。现在若B收到了123，B会给A发送一个确认，表示我已经收到了第3个，他前面的也收到，请发送第4个。若B只收到12，3丢失了,4B也收到了，B会确认收到前2个。那么A会重复发3,4。连续ARQ好是好，但是后面已经收到的，发送方并不知道，重复发送。

3)  滑动窗口协议：

A与B通信，A发B收，A有一个发送缓存，B有一个接收缓存，然后通信。A与B建立连接，B设定自己的接收窗口。在建立会话时，B告知A他的接收窗口是20个字节，A就把自己的发送窗口设置为20个字节。A的发送窗口是由B的接收窗口决定的。A和B通信了，第一个数据包发送3个字节(123),根据连续ARQ协议，A又发送第二个数据包（456），第3个数据包（78910）。A发了10个字节，在还没有收到B的确认之前，A窗口里的不许删除。A只能发当前窗口里面的。现在，B收到了123,456，B一数，发现字节连续，B就给A发一个确认包，要求A传第7个。给了确认后B窗口也往后移6格，123456就会被应用程序读走。A收到确认后，知道123456已经正确收到，A窗口往后移6个，从A中删除。B又接着收到A的78910。这个就是，网页图片多，一点点加载。若发生丢失问题时：若123在传，456在传，789在传，101112也在传。若传的过程中，789丢失了，B收到了123456，接下来B收到的是101112。B就给A发一个确认7，B其实已经收到了789后面的101112包。确认包里面还有一个选择性确认，叫SACK，会告诉A哪一段缺失了。这时A只发丢失的那一块，不会再发101112了，接下来发131415。

3.  流量控制

流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。

1)  流量控制

所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待。

2)  传递效率

一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即：

*1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；

*2. 当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；

*3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就立即发送一个报文段；

对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。

4.  拥塞控制

使用网络的所有计算机如如何避免堵塞的。使用TCP协议的计算机，发现丢包现象，网堵塞了，主动把发送数据的速度降下来，避免把网堵死。有了拥塞控制，避免出现了死锁（吞吐量为0）的情况。常用的方法就是：

1. 慢开始、拥塞控制

2. 快重传、快恢复

一切的基础还是慢开始，这种方法的思路是这样的：

-1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；

-2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；

-3. 当收到第一个字节的数据的确认后，就发送2个字节的报文；

-4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；

-5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：

*1. cwnd < ssthresh， 继续使用慢开始算法；

*2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；

*3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；

-6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；

-7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；

上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。快重传的机制是：

-1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；

-2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；

-3. 此时发送方开始执行“快恢复”算法：

*1. 慢开始门限减半；

*2. cwnd设为慢开始门限减半后的数值；

*3. 执行拥塞避免算法（高起点，线性增长）；

1.  概念：TCP是面向连接的以字节流方式传输的协议，他提供可靠、有序。全双工的传输（TCP通信的每一段都维护着一个发送缓存和接收缓存）。TCP连接的端点不是主机中的应用进程，而是应用进程维护的套接字接口（socket），其基本的结构包含【IP：Port】。

2.  TCP可靠传输的工作原理

TCP实现可靠传输的工作原理主要有两个，我们分别来看：

1)  停止等待协议

*1. 发送方A向接收方B发送数据分组M1；

*2. 接收方B收到分组M1后向A发送M1的确认；

*3. A接收到B发送的对于M1后的确认之后再发送分组M2；

*4. 若中间的某一个分组丢失或是延迟，则A就会使用超时计时器进行超时重传，每个分组发送时都会保留其副本并且设置超时计时器；

上面的机制保证了在不可靠的信道上时间可靠的传输，这种机制称为自动重传请求(ARQ)，即重传的请求是自动的，不需要接收方向发送方请求重传某个分组。

2)  连续ARQ协议

停止等待协议的优点是简单，缺点是信道利用率太低。为此我们引入了连续ARQ协议和滑动窗口协议。

首先是连续ARQ协议：举个例子，A与B通信，发送方A缓存里面有一个长度为5的发送窗口，窗口里面有12345字节。A连续发12345给接收方B。A窗口中的数据在B没有发送确认收到之前，不能从缓存中删除。但B不是来一个数据包就确认一次，是累积确认的。现在若B收到了123，B会给A发送一个确认，表示我已经收到了第3个，他前面的也收到，请发送第4个。若B只收到12，3丢失了,4B也收到了，B会确认收到前2个。那么A会重复发3,4。连续ARQ好是好，但是后面已经收到的，发送方并不知道，重复发送。

3)  滑动窗口协议：

A与B通信，A发B收，A有一个发送缓存，B有一个接收缓存，然后通信。A与B建立连接，B设定自己的接收窗口。在建立会话时，B告知A他的接收窗口是20个字节，A就把自己的发送窗口设置为20个字节。A的发送窗口是由B的接收窗口决定的。A和B通信了，第一个数据包发送3个字节(123),根据连续ARQ协议，A又发送第二个数据包（456），第3个数据包（78910）。A发了10个字节，在还没有收到B的确认之前，A窗口里的不许删除。A只能发当前窗口里面的。现在，B收到了123,456，B一数，发现字节连续，B就给A发一个确认包，要求A传第7个。给了确认后B窗口也往后移6格，123456就会被应用程序读走。A收到确认后，知道123456已经正确收到，A窗口往后移6个，从A中删除。B又接着收到A的78910。这个就是，网页图片多，一点点加载。若发生丢失问题时：若123在传，456在传，789在传，101112也在传。若传的过程中，789丢失了，B收到了123456，接下来B收到的是101112。B就给A发一个确认7，B其实已经收到了789后面的101112包。确认包里面还有一个选择性确认，叫SACK，会告诉A哪一段缺失了。这时A只发丢失的那一块，不会再发101112了，接下来发131415。

3.  流量控制

流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。

1)  流量控制

所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待。

2)  传递效率

一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即：

*1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；

*2. 当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；

*3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就立即发送一个报文段；

对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。

4.  拥塞控制

使用网络的所有计算机如如何避免堵塞的。使用TCP协议的计算机，发现丢包现象，网堵塞了，主动把发送数据的速度降下来，避免把网堵死。有了拥塞控制，避免出现了死锁（吞吐量为0）的情况。常用的方法就是：

1. 慢开始、拥塞控制

2. 快重传、快恢复

一切的基础还是慢开始，这种方法的思路是这样的：

-1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；

-2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；

-3. 当收到第一个字节的数据的确认后，就发送2个字节的报文；

-4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；

-5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：

*1. cwnd < ssthresh， 继续使用慢开始算法；

*2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；

*3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；

-6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；

-7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；

上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。快重传的机制是：

-1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；

-2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；

-3. 此时发送方开始执行“快恢复”算法：

*1. 慢开始门限减半；

*2. cwnd设为慢开始门限减半后的数值；

*3. 执行拥塞避免算法（高起点，线性增长）；