回顾内容
传输层使用的两个主要协议：TCP和UDP。
TCP 主要特性有特性有以下几点：
(1)面向连接，在数据传送前必须建立连接，在数据传送结束后必须释放连接。在一个TCP连接中，仅有两方进行彼此通信。广播和多播不能用于TCP。
(2)点对点，每一条TCP连接只能有两个端点。从socket角度来说，通信双方需要建立套接字，套接字由IP地址和端口号组成，数据到达传输层之后会被送到端口对应的应用程序。
(3)提供可靠交付服务。
(4)支持全双工通信。
(5)面向字节流。面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率。若太短，会是IP太小。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。面向字节流的话，虽然应用程序和TCP的交互是一次一个数据块(大小不等)，但TCP把应用程序数据看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。
总述
1、确认应答（ACK）机制：
2、超时重传机制：
接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。
3、滑动窗口机制：
4、数据校验：
TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。
5、数据合理分片和排序：
UDP：IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片.把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报.
TCP会按MTU合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层。
5、流量控制：
当接收方来不及处理发送方的数据，就提示发送方降低发送的速率，防止包丢失。
7、拥塞控制：
当网络拥塞时，减少数据的发送。
上面简单的讲了TCP保证可靠传输的几个机制，下面对较难理解的面深入探究。
滑动窗口
滑动窗口是干什么的？
有一种机制叫做ACK确认应答【过程如图】，收到数据段，给发送一个ACK确认应答，收到ACK应答后，再发送数据段，明显会降低效率，如果数据往返时间较长时，会影响到性能。
上面这种方式浪费效率，如果换种方式发送呢 ^_^
- 一次发送多个数据段，统一确认后，再发送多个数据段。
上面这种传送机制就是窗口机制。
- 窗口是什么？
窗口大小：就是无需等到确认应答而可以继续发送数据的最大值。（上图窗口就是4000字节，也就是四个段）
- 传输过程：
1、客户端和服务器端各自建立套接字，通过彼此的套接字进行通信；
2、服务器端绑定监听端口，然后监听，循环等待来自客户端的连接；
3、一旦收到来自客户端的连接，进行三次握手，一旦连成功就fork()一个子进程来处理和当前客户端的连接，然后父进程继续监听客户端的连接；
4、发送前面四个段，无需ACK确认应答，直接发送；
5、收到第一个ACK后，滑动窗口向后移动，发送第五个数据段，以此类推；
6、操作系统为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有那些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉；
7、一旦数据传输完毕就是放连接。
就是说随着时间推移，滑动窗口也在推移，滑动窗口的会变化，内部缓存数据不停的更新，根据网络的拥塞情况，发送端可以调控滑动窗口的大小来控制流量 ，滑动窗口就是一个滑的过程啊~ ^_* ~ ^_* 可能解释的有点啰嗦了
4、窗口越大，网络吞吐量就越高。
吞吐量就是单位时间内通过某个网络（信道、接口）的数据量。
- 接收窗口大小取决于应用（比如说tomcat：8080端口的监听进程）、系统、硬件的限制。
流量控制
简单来说就是接收方处理不过来的时候，就把窗口缩小，并把窗口值告诉发送端。
当窗口值为0，而接受方把窗口值恢复（比如ACK=1，ack=601，rwnd=200），但确认丢失，进入相互等待的死锁局面。所以如果窗口值为0，发送端就会开启一个持续计数器，每个一段时间询问一下接收方。
拥塞控制
什么是拥塞？
是指计算机网络中，某一个时段，某一资源的需求量超过了该资源可提供的可用部分，网络性能变差。
什么是拥塞控制？
所谓的拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或者节点不至于过载，拥塞控制是一个全局的过程。
几种拥塞控制的方法：因特网建议标准RFC定义了几种拥塞控制的算法；
- 满开始，拥塞避免，
- 快重传，快恢复。
拥塞控制描述：
唯一的方法就是尝试各种不同的发送速度。比如一开始以 100kb/s 的速率发送数据，如果没问题，再将速率提高到 200kb/s，再没问题继续提升发送速率。一旦达到某个上限后，便开始出现丢包现象，发送方就可以认为，网络已经拥塞了，于是降低发送速率，减轻网络负担。
控制流程简述：
满开始、拥塞避免
发送方维持一个拥塞窗口的状态变量，其大小取决于网络的拥塞程度，动态地变化，而发送窗口一般取拥塞窗口和对方给出的接收窗口的最小值（为了便于描述，后面的分析中假定对方给出的接收窗口足够大，这样将发送窗口等于拥塞窗口就可以了）。
慢开始算法的核心是从小到大逐渐增大发送窗口，也就是说，从小到大逐渐增大拥塞窗口的数值。通常在刚开始发送报文段时，先把拥塞窗口设置为一个最大报文段MSS的数值，而在每收到对上一轮报文段（，每次加倍后的报文段的个数，可能不止一个报文段）的确认后，就把拥塞窗口的数值加倍。
为了防止拥塞窗口增长过大引起网络拥塞，还需要维护一个慢开始门限的状态变量，当拥塞窗口的值小于慢开始门限时，使用慢开始算法，一旦拥塞窗口的值大于慢开始门限的值，就改用拥塞避免算法。
拥塞避免算法的思路是让拥塞窗口缓慢地增大，收到每一轮的确认后，将拥塞窗口的值加1，而不是加倍，这样拥塞窗口的值按照线性规律缓慢增长。
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（没有按时收到确认），就把慢开始门限设置为出现拥塞时发送窗口值的一般，但最小不能小于2个MSS值，而后把拥塞窗口的值重新设置为1个MSS，执行慢开始算法。
快重传，快恢复
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（重复发送对前面有序部分的确认），而不是等待自己发送数据时才进行稍待确认，也不是累积收到的报文发送累积确认，如果发送方连续收到三个重复确认，就应该立即重传对方未收到的报文段（有收到重复确认，说明后面的报文段都送达了，只有中间丢失的报文段没送达）。
快恢复算法与快重传算法配合使用，其过程有如下两个要点：
1、当发送方连续收到三个重复确认时，就把慢开始门限减半，这是为了预防网络发生拥塞。注意，接下来不执行慢开始算法。
2、由于发送方现在认为网络很很可能没有发生特别严重的阻塞（如果发生了严重阻塞的话，就不会一连有好几个报文段到达接收方，就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口的值不设为1个MSSS），而是把拥塞窗口的值设为慢开始门限减半后的值，而后开始执行拥塞避免算法，线性地增大拥塞窗口。
总结
- 问题思考：
1、网络拥堵是怎么来的？
2、RFC 定义的 4 种拥塞控制算法是什么？分别讲述流程以及原理