TCP是如何名副其实地进行传输控制的呢？它对传输进行的控制，主要目的是为了解决 UDP 中发生的丢包，重复收包，乱序等问题。
以下插图和内容分凝练于《图解TCP/IP(第5版)》((日)竹下隆史) 。对此书感兴趣网上资源自搜。侵权联系删除
太长不看可跳最后总结
TCP的序列号以及确认应答号
确认应答的起因：告知发送端，其发出的数据，接收端已收到。发送端借此决定对丢包重发。
序号的起因：接收端需要知道是否接收了重复的包（包中字节已收过）。所以给字节编号。比如1~1000号字节打包发送。
序列号的起因：发送端告知接收端此次发送的包的起始字节的序列号。
确认应答号的起因：发送端需要知道接收端后续需要的数据。是接收端根据接收到的包头的起始字节序号和包的数据段长推算到的。
TCP的超时重发计算
计算的起因：在不同的网络状况下，发送端的包被接收端接收到的时间，以及接收端发送的ACK包到达发送端时间，二者总和称为RTT往返时延，是不同的。且每一个包的RTT也是不同的，称为偏差。TCP 需要确认一个阈值，保证重发不占用带宽。
偏差的计入起因：虽然某一轮 RTT 低，但如果它相对上一轮低了好多，加入偏差后的阈值更满足该网络的不稳定性特质。
TCP的连接管理
连接的起因：TCP 通信中，发送端与接收端做好互相通信准备后，才会互相发数据包。UDP 中则不管对方的状态，直接发送。
连接的管理：TCP的包头中，有对应的控制字段。
TCP以段为单位发送数据
MSS的解释：最长段大小，TCP对大量数据也是分段发送的。
MSS的计算：TCP包作为IP包的数据段最好包大小不超过IP包能承载的数据段大小，也就是MSS受限于MTU。假设网络的 MTU 为 1500，IP首部为20，那么TCP包最大为 1480 字节，TCP包的包头大概 20 字节，那么 MSS 就是 1480-20=1460 字节。
TCP使用窗口提高性能
性能问题：TCP以段位单位进行通信，接收端每接收一个段都要给确认应答号，发送端才会继续发送下一个段。大数据传输耗时。
解决方法：允许发送端在接收到应答前，还能连续发送一定数量的段，这个数量就是窗口大小。允许接收端连续接收段并处理后，只发送最新的确认应答号。
具体做法：发送端与接收端的通信如下图所示。在接收到最新的确认应答号前，可以发送四个数据段，窗口大小为4。
TCP的窗口控制与重发控制
重发的起因：丢包。丢包有两种情况：一种接收端的应答丢了，这种情况没有关系，只要窗口内该段后的确认应答号包没掉，就代表段已收到；一种是发送端的包丢了，这种情况需要重发。
重发控制：接收端即便收到了滑动窗口内后面的段，但是一直回复的确认应答号是那个丢掉的段号，发送端在收到了三次重复的确认应答号后，确定丢包才重发。
TCP流控制
流控制的起因：接收端收到包需要处理时间，发送端的发送速率超出了接收端处理的能力。引发接收端丢包，发送端重发。
解决方法：接收端告知发送端自己处理数据的能力，控制发送端发包。发送端在迟迟没接收到接收端告知接受能力的时候，主动窗口探测询问接受能力。
具体做法：接收端使用缓冲区存放发送端传来的包，排队处理。接收端在TCP报头加入缓冲区大小，告知发送端，发送端根据接收端缓冲区大小和收到的包ACK控制发送速率。具体发送端会建立一个发送窗口，只发窗口内的包，比如只发1~1000，发到1000后，就不再发送；直到收到接收端返回的窗口最前端的包ACK，说明接收端已处理完缓冲区中对应的包，缓冲区有空位腾出了，发送端此时将窗口后移，继续发包；比如收到了1~500的ACK时，窗口后移至 501~1501，继续发送1001~1501包。
TCP拥塞控制
拥塞的产生：刚开始通信时，发送端根据接收端通知的窗口大小 W 连续发包。
解决方法：慢启动，发送端控制启动时的吞吐量。窗口从1个数据段大小开始增长，每接到一个接收端ACK窗口增加一个数据段大小。
拥塞产生：按上述方法建模窗口 W(1) = 1，W(n+1) = W(n) + W(n) = 2W(n)。容易推知 W(∞)=∞。
解决方法：设置慢启动窗口大小阈值W，当窗口大小超过W时，增长公式调整为 W(n+1) = W(n) + 1个数据段大小² / W(n) 。
Nagle 算法
Nagle算法的产生：避免小分组降低网络利用率 [ = 1-(包头/包头+数据）]
解决方案：就等着不发出去，一直等到——要么发送端等了一会儿数据量达到了MSS水平；要么等接收端全部已发的都确认收到了。再继续发送。
缺点：对于实时性应用来说，这种拖延战略不适合。
优点：降低小包数量，提高了网络利用率
延迟确认应答
延迟确认应答的产生：确认应答包不带数据，降低了网络利用率。
解决方案：确认应答可以表示该序列号-1之前的所有包都收到了，所以可以等一会儿，等收到一定数量处理完后，一次性确认。
这个解决方案中发送端可在收到确认前连续发送一定数量的包，是基于滑窗机制的。
缺点：不宜制定标准，通常设定两个包（不一定是MSS）应答一次，当第二个包迟迟不来时，最多等待0.2s，一定会返回确认应答，这个值是实现了TCP协议的UNIX操作系统决定的。
捎带应答
捎带应答的产生：远程登陆中的回送校验，邮件系统中的回执机制，www的HTTP应用，都是交互式应用，互相发送信息，双方都既需要发空包确认应答，又同时要发数据包，两倍的包量拉低了网络利用率。
解决方案：二包合体。在确认包里带上要回复的数据。
总结
1、TCP 为了确保数据送达，引入了确认应答机制，每个包从原来的一去变成需要都要一去一回，为了不影响性能，又使用了滑动窗口机制，允许在通信开始时，以及通信中每收到一个确认应答号后，可连续发送一定数量的包，提升了发送的并行度。
2、滑动窗口在确认窗口大小时使用窗口探测同时解决了发送端发送能力与接收端接收能力不匹配的问题。
3、TCP 为了控制大量的连续发包导致的网络拥塞（接收端处理能力强，奈何网络不佳），引入了慢启动机制。
4、TCP为了降低纯控制包和小分组的数量，以提高网络利用率，引入了Nagle算法，延迟确认应答，捎带应答。
