一、TCP流量控制
如果发送方发送速率过快，接收方可能来不及接收，会造成数据的丢失，降低吞吐率。
流量控制就是控制发送方的发送速率，使接收方来得及接收。
1. 滑动窗口实现流量控制
滑动窗口机制可以方便地实现TCP连接上的流量控制。接收方回送确认时，将给出自己的接收窗口，发送方根据对方的接收窗口确定自己的发送窗口，就可以实现流量控制。
在这个过程中，试想一种情况：B向A发送零窗口报文后，A等待B发送非零窗口通知；但B发送非零窗口通知时，该报文偶发丢失了。此时，A一直等待B发送非零窗口通知，而B等待A发送新的报文段；A与B循环等待，形成了死锁。
为避免死锁的出现，TCP连接设有一个持续计时器。当TCP的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器到达设置的时间，就给接收方发送一个零窗口探测报文段(仅1字节)。接收方收到该报文段后，回送当前的接收窗口值。若rwnd仍为0，则持续计时器重新计时；否则，发送方就可以开始发送数据。
2. 传输效率问题
对于TCP，有三种不同的机制来控制TCP报文段的发送时机：
- TCP维持一个等于最大报文段长度MSS的变量，当缓存中存放数据到达MSS字节时，组装成一个TCP报文段发送；
- 由发送方进程指明要求发送报文段，即PUSH操作；
- 发送方的一个计时器期限到了，就把当前缓存数据装入报文段发送。
尽管有这三种机制，但报文段的发送时机控制仍然是一个复杂的问题。主要遇到的问题是：
● 发送方糊涂窗口综合症
在某些进程(如Telnet服务)中，发送方可能每接收一个字节，就会开始发送报文段。这样，一个字节的数据加上TCP报文段和IP数据报的首部，就需要发送41字节的IP数据报。在这个数据报中，有效数据仅有一个字节，传输效率极低。
为解决此问题，TCP实现广泛采用了Nagle算法，其内容为：
- 当进程需要逐字节发送数据时，首先将第一个数据字节发送出去，后续的字节都缓存起来；
- 每当收到前一个报文段的确认时，把缓存中的数据组装成一个报文段发送；
- 若缓存中数据达到发送窗口大小的一半或者报文段最大长度时，立即发送一个报文段。
Negla算法可以在数据到达较快而网速较慢时，明显减少使用的网络带宽，并有效提高吞吐量。
● 接收方糊涂窗口综合症
TCP接收方的缓存已满，而应用进程每次只从缓存中读取一个字节，然后向发送方发送确认，且窗口值为1；接着发送方再发送41字节长的数据报(有效数据1字节)。这样进行下去，网络传输的效率极低，并且会导致网络性能恶化。
为解决此问题，可以让接收方等待一段时间，使其在已有足够空间容纳一个MSS报文段或已有一半的空闲缓存时，再发送确认报文，通知接收窗口的大小。
Negla算法和接收等待配合使用，可以有效提高TCP的传输效率。
二、TCP拥塞控制
1. 拥塞的产生
计算机网路中，链路的带宽、结点的缓存和处理机等，都是网络资源。
在某个时间段，若对网络中某一资源的需求超过了该资源所能提高的可用部分，网络性能就会恶化。这种现象就是拥塞。
拥塞出现的条件： 对资源的需求 > 可用资源
若网络中多个资源同时供应不足，网络性能将明显恶化，网络的吞吐量将随着负荷的增大而迅速下降。
然而，简单地增加网络资源是不可行的。增加缓存将使得分组排队等待时间显著变长，造成大量重传；而提高处理速率，又会导致网络瓶颈转移到其它资源上。问题的实质往往是整个系统各部分不匹配。
拥塞常常趋于恶化。拥塞引起的分组重传，并不会缓解拥塞情况，反而会加剧拥塞。
2. 拥塞控制与流量管理
拥塞控制是防止过多的数据注入到网路中，使链路和路由器不至于过载。拥塞控制所做的前提是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程。
流量控制则是点对点的通信量控制，是端到端的问题。所要做的是抑制发送端的发送速率，使接收端来得及接收。
拥塞控制和流量控制的直接结果都是放慢发送方的发送速率。
3. 一般原理
由于拥塞是一个全局的动态问题，因此拥塞控制很难设计。
网络的高速化，使得路由器容易出现缓存不够大而造成的分组丢失。但分组丢失是拥塞的结果而非原因。
拥塞控制需要代价。有时，拥塞控制本身会成为网络性能恶化甚至死锁发生的原因。必须全面衡量得失。
拥塞控制从控制理论的角度可以分为开环控制和闭环控制。
● 开环控制：设计网络时考虑拥塞有关的因素，力求网络工作时不产生拥塞。但系统一旦投入运行，就不能改动。
● 闭环控制：基于反馈环路的概念，主要有以下几种措施：
- 监测网络系统，检测拥塞在何时、何处发生；主要的指标有：丢弃分组百分数、平均队列长度、重传分组数、平均分组时延
- 把拥塞的信息传送到可采取行动的地方；
- 调整网络运行，解决拥塞。
4. 控制方法
TCP采用基于窗口的方法进行拥塞控制。它属于闭环控制方法。
发送方维护一个拥塞窗口cwnd。真正的发送窗口 = min{接收方接收窗口, 拥塞窗口}；
控制拥塞窗口的原则：
- 只要网络没有发生拥塞，拥塞窗口就可以增大，提高利用率；
- 如果发生拥塞，就必须将拥塞窗口减小，减少网络中的分组数。
发生拥塞的判断：
- 重传计时器超时：意味着报文段丢失，在如今通信质量良好的链路中，分组丢失往往是出现了拥塞；
- 收到三个重复ACK：个别报文段出现丢失，可能意味着拥塞，也可能是偶发丢失，但也需要立即采取措施。
● 慢开始
当主机开始发送数据时，由于不知道网络的负荷情况，应当先探测，由小到大地增大拥塞窗口。
- 拥塞窗口cwnd控制方法
初始拥塞窗口cwnd：旧规定将初始cwnd设置为1-2个最大报文段SMSS；新RFC-5681将初始cwnd设置为不超过2-4个SMSS。
每收到一个新的报文段确认时，拥塞窗口最多可以增加一个SMSS。
每次cwnd的增加量：Δcwnd = min{N, SMSS}；其中N是刚收到确认报文段所确认的字节数。
在慢开始阶段，每经过一个传输轮次，拥塞窗口将值数增长。慢指的是开始时cwnd = 1，而不是增长的慢。
传输轮次强调将cwnd中所有的数据都发送，并收到最后一个字节的确认。一次传输轮次的时间就是RTT。
![慢开始]()
- 慢开始门限ssthresh的使用
慢开始门限ssthresh用于防止拥塞窗口增长过大引起网络拥塞。
当cwnd < ssthresh时，使用慢开始算法；
当cwnd > ssthresh时，停止使用慢开始算法，改用拥塞避免算法；
当cwnd = ssthresh时，即可以使用慢开始，也可使用拥塞避免。
● 拥塞避免
拥塞避免是让cwnd缓慢增大，尽可能晚到达拥塞。拥塞避免不是没有拥塞，只是不容易出现拥塞。
- 拥塞出现前
每经过一个RTT，使发送方的cwnd加1，而不是加倍，使得cwnd按线性规律缓慢增长。
拥塞避免具有加法增大的特点，其cwnd增长速度比慢开始阶段慢得多。 - 拥塞出现时
当出现重传定时器超时，就判定发生了拥塞(无论慢开始还是拥塞避免阶段)。此时采取以下措施：
● ssthresh = max{cwnd / 2, 2}；(ssthresh置为当前拥塞窗口的一半，若不足2则设置为2)。
● cwnd = 1；
● 执行慢开始算法。
采用这一操作，可以迅速减少主机发送的分组数，使拥塞的路由器有足够时间处理。
● 快重传
- 对于接收方
快重传首先要求接收方立即发送确认，即使是失序的报文段也要发送前面报文段的重复确认。 - 对于发送方
发送方只要收到连续三个重复确认，就判断对方没有收到某个报文段，应当立即进行重传，避免超时导致误判断拥塞。
● 快恢复
收到连续的三个重复确认后，发送方除了要立即重传之外，还判断网络没有发生拥塞，而是偶发丢失分组。
因此，不执行慢开始算法，而是快恢复算法：
- ssthresh = cwnd / 2；
- cwnd = ssthresh；
- 开始执行拥塞避免算法。
即慢开始门限设为当前拥塞窗口的一半，并将拥塞窗口设为当前的慢开始门限(即自身的一半)，并执行拥塞避免算法。
● AIMD算法
拥塞避免阶段，拥塞窗口线性缓慢增大，称加法增大(AI)；而出现超时或三连重复ACK，就要将慢开始门限设置为拥塞窗口的一半，称乘法减小(MD)。两者合一就是AIMD算法。
综上，TCP的拥塞控制可以归纳为下图：
注意：发送方窗口不仅受拥塞窗口cwnd影响，也受接收方窗口rwnd影响。
发送方窗口上限 = min {rwnd, cwnd}。
三、TCP运输连接管理
TCP协议是面向连接的协议。其运输连接有三个阶段：
● 连接建立
● 数据传送
● 连接释放
在TCP建立连接时，需要解决三个问题：
● 双方要能够明确知道对方的存在；
● 要允许双方协商一些参数(窗口值、是否使用窗口扩大选项和时间戳选项)；
● 能够对运输实体资源进行分配(缓存大小、连接表中的项目等)。
TCP连接建立采用客户端/服务器方式(C/S方式)：
● 主动发起连接建立的应用进程就是客户端；
● 被动等待连接建立的应用进程就是服务器。
1. 连接建立
TCP为建立连接而发送报文段的过程，称为握手。
TCP的连接建立需要进行三次握手，即建立连接的整个过程需要发送三次报文段。
主机A运行的应用进程是客户，主机B运行的应用进程是服务器。最初，双方都处于CLOSED状态。
开始前，服务器端B已经创建传输控制模块TCB，表示准备好接受连接请求，并进入LISTEN状态，等待客户连接请求。
- 第一次握手
客户端A也创建TCB，并在试图建立连接，向B发出连接请求报文段。该报文段的同步位SYN = 1，并选择一个初始序号x(TCP规定实际上报文段不携带数据，但要消耗一个序号)。此时，客户端A进入SYN-SENT状态(同步已发送)。 - 第二次握手
B收到连接请求报文段后，如果同意建立连接，则向A发送确认。确认报文段中的SYN = 1，且ACK = 1；同时，确认号置为x + 1，表示已经收到连接请求；并且也要选择一个初始序号y。同样，该报文段不携带数据但要消耗一个序号。此时，服务器端B进入SYN-RCVD状态(同步已接收)。 - 第三次握手
A收到确认后，还要再发送一次对确认的确认。该确认报文段中的ACK = 1；确认号置为y + 1，序号置为x + 1。不同的是，该ACK报文段可以携带数据。但如果选择不携带数据，则不消耗序号，即下一个报文段的序号仍可以是x + 1。此时，TCP连接已经建立，A进入ESTABLISHED状态(连接已建立)。
最后，当B收到该ACK报文段后，也进入ESTABLISHED状态，TCP连接建立完成。
采用三次握手主要是为了避免建立失效的连接。
例如，当A向B发送了连接请求，而第一个连接请求由于网络原因超时；此时，由于超时，A会向B重传一次连接请求；这样，B就会收到两次连接请求，其中有一个超时的是失效的。如果出现异常状况，超时的那个连接请求在上一次连接释放后才到达。对于B，会误认为后到的那一个请求是新的连接请求，于是再次返回确认。如果不进行第三次握手，就会建立一个失效的连接。这时B会认为连接已建立，而等待A发送数据；但A没有发送请求，收到确认并不会作出回应，B的资源也就浪费了。
而采用了三次握手后，即使发生上述情况，B无法收到A的确认，就会知道没有建立连接，避免了资源的浪费。
2. 连接释放
TCP为释放连接而发送报文段的过程，称为挥手。
TCP的连接释放需要进行四次挥手，即释放连接的整个过程需要发送四次报文段。
数据传输结束后，TCP连接的双方都可以释放连接。这里假设A开始释放连接。释放前，双方均处于ESTABLISH状态。
- 第一次挥手
A停止传输数据，并发出连接释放报文段，主动关闭TCP连接。报文段首部的FIN = 1；序号置为u，是已传输的最后一个字节序号加1。FIN报文段即使不携带数据，也要消耗一个序号。此时，A进入FIN-WAIT-1状态(终止等待1)，等待B的确认。 - 第二次挥手
B收到连接释放报文段后，立即发送确认，报文段首部的ACK = 1，确认号置为u + 1；并且置序号为v，也是传输的最后一个字节加1。此时，B进入CLOSE-WAIT状态(关闭等待)。但此时B仍能向A发送数据，即TCP连接处于半关闭状态。A不会再向B发送数据，但B向A发送的数据仍能接收，相当于从全双工信道退化为B到A的单工信道。
A收到确认后，进入FIN-WAIT-2状态(终止等待2)，等待B发送释放报文段。
由于B可能仍有剩余数据发送，第二次挥手后到第三次挥手前这一状态，可能会持续一段时间。 - 第三次挥手
当B发送完全部的数据，不再有数据需要发送后，就发送释放报文段。其FIN = 1，ACK = 1；确认号仍为u + 1，序号为w，是剩余传送完的最后一个字节加1。此时，B进入LAST-ACK状态(最后确认)。 - 第四次挥手
A在接收到来自B的释放报文段后，还需要发出确认。其ACK = 1，确认号置为w + 1，序号置为u + 1。
对于B，收到确认后，就进入CLOSED状态。
对于A，则会先进入TIME-WAIT状态(时间等待)，等待2MSL的时间后才进入CLOSED状态。
A必须等待时间等待计时器设置的2MSL(最长报文段寿命)的时间。主要是为了：
● 保证A发送的最后一个ACK报文能够到达B，如果没有到达(丢失或超时)，B会进行重传FIN+ACK报文，而A能够在2MSL的时间内收到重传(在0~MSL内重传，2MSL前到达)，这样A就能重传一次ACK报文，并重启时间等待计时器。若是没有等待时间，A就无法收到B的重传，也不会重传给B，B就无法正常地释放连接。
● 防止已失效的连接请求报文段出现。经过2MSL的时间后，能够确保本连接持续时间内所有的报文段都消失(丢弃)，保证下一次新的连接时，不会出现旧的报文段(都因超时丢弃)。
另外，TCP设有保活计时器。当建立连接后，一方的主机突然出现故障，另一方就不再能收到传来的数据。为了不让资源白白浪费，使用保活计时器判断连接的有效性。每当收到对方传来的数据，就将保活计时器重置。若到达设置的时间限制(通常为2小时)，就发送一个探测报文段，之后每隔75秒发送一次。若10个探测报文后，对方仍没有回应，就认为对方发生故障，关闭这个TCP连接。
3. 有限状态机
为了清晰地表示TCP连接地各种状态的联系，下面给出TCP连接的有限状态机。
图中每一个方框就是TCP连接的一个可能状态。方框内的英文就是TCP标准使用的连接状态名。
状态间的箭头表示可能发生的状态变迁。箭头旁的字表示变迁发生的原因。
粗实线箭头表示客户进程的正常变迁，粗虚线箭头表示服务器进程的正常变迁。细线箭头表示异常变迁。
