本系列文章对整个Android网络编程进行了总结，包括基本的TCP/IP协议，HTTP协议，HTTPS协议，HttpClient,UrlConnection,一些网络通信的库到棉花糖新加入的OKHTTP。
本文主要对TCP协议的连接管理和拥塞控制两部分知识进行总结。
连接管理
TCP协议是传输层的重要协议，负责端到端的通信。为了实现面向连接的可靠传输，TCP协议使用“三次握手”和“四次挥手”的方式来创建连接，结束连接。
三次握手：
- 第一次握手：建立连接时，客户端C发起建立连接请求（SYN=1）到服务器S，并进入SYN_SEND状态，等待服务器返回确认。
- 第二次握手：服务器S收到客户端C发来的连接请求后，返回确认报文（SYN=1，ACK），并进入SYN_RECV状态。
- 第三次握手：客户端C收到服务器S发来的确认报文后，也要返回一个确认（SYN=0，ACK），进入ESTABLISHED状态，开始传送数据。
这里需要提一下的是确认号数值ACK=期望对方下次发来的字节序号。
当需要断开连接时候，采用“四次挥手”的方式：
- 第一次挥手：客户端C发送完数据后，发起释放连接请求（FIN=1）,表示要关闭数据传送，进入FIN_WAIT1状态。
- 第二次挥手：服务端S收到请求后，会继续发送之前未发完的数据（ACK）并进入CLOSE_WAIT状态，关闭读通道，也就是不能再从这个链接上读取数据。C收到对自己释放连接请求的ACK后，关闭写通道，不再向连接中写数据，进入FIN_WAIT2状态。
- 第三次挥手：服务端S发送完要发送的数据后，发送会关闭写通道（FIN=1）报文，进入LAST_ACK状态。而此时客户端接到该报文后，关闭读通道，进入TIME_WAIT状态。
- 第四次挥手：客户端C发送对上一步服务器的FIN报文的ACK，然后在等待2个MSL的时间后，进入CLOSED状态。而服务器S在收到该ACK后也进入CLOSED状态。
关于连接建立和释放过程中，有两个状态需要说明一下：
- SYN_RECV:服务器S收到了来自客户端的建立连接请求，此时称为半连接状态，存储在服务器端的一个半连接队列中。当收到C发来的ACK报文后，会在该队列中查找并移除。如果受到flood SYN攻击，半连接队列溢出，后续连接请求则会被丢弃。可以通过SYN Cookie来防止flood SYN攻击。
- TIME_WAIT:客户端C在发送对服务器S的FIN报文的确认ACK后，进入了TIME_WAIT状态。客户端会维持这个状态2MSL后才释放socket。这个机制从逻辑上保证了重新被分配的socket不会受到之前残留的延迟重发报文的影响。如果直接关闭客户端C，假如服务器S并未收到C对之前FIN报文的确认，则会重新发送FIN报文给C，但是此时C已经CLOSED了，无法找到此连接只好返回RST（reset）给S。这样虽然没有数据丢失，但是不符合可靠连接的要求。另外，如果C直接关闭后，又重新向server建立了一个连接，端口号又相同，但是之前上一个socket有些滞留数据也会发送到server。这时，服务器就会认为这些滞留数据是新连接发来的，产生混淆。等待2MSL可以保证这些数据消失。
拥塞控制与流量控制
拥塞控制就是防止过多数据注入到网络中，这样可以使网络中的路由器和链路不至于过载。它是一个全局性的过程，涉及到链路上所有的主机和路由器。而流量控制是点对点通信量的控制，是为了防止发送端数据发送过快接收端来不及接收。TCP协议采用慢开始、拥塞避免、快重传以及快恢复的算法进行拥塞控制。发送端维持了一个称为“拥塞窗口”的状态变量cwnd，它随着网络拥塞程度动态变化，这里我们先不去考虑流量控制以及接收方的接收能力，而是让发送方的发送窗口等于拥塞窗口。
慢开始和拥塞避免算法
当主机开始发送数据的时候并不知道网络负荷状况，所以由小到大逐渐增大发送窗口，即由小到大增大拥塞窗口cwnd。初始设置cwnd=1MSS，发送一个报文给接收方。接收方收到该报文后，会返回确认。发送方每次收到一个对新报文段的确认，就将cwnd增加1.因此，慢开始算法每经过一个传输轮次RTT，拥塞窗口加倍：1,2,4…所以说“慢开始”不是说cwnd增长速度慢，而是说在开始发送的时候cwnd=1进行网络试探。
为了防止cwnd过速增长，需要设置一个慢开始阈值ssthresh状态变量：
- 当cwnd<ssthresh时，使用慢开始算法。
- 当cwnd>ssthresh时，改用拥塞避免算法。
这里拥塞避免算法与慢开始算法不同，每经过一个传输轮次RTT发送方的拥塞窗口cwnd增加1，而不是加倍，同时ssthresh的值也加1.无论是在慢开始算法还是在拥塞避免算法阶段，一旦发生拥塞（是否按时收到确认报文），则把ssthresh值设置为拥塞时cwnd值的1/2，然后cwnd设置为1，重新开始慢开始算法。（这是不使用快重传的思路）
快重传和快恢复
在传输过程中，如果发送方在计时器时限已到仍未收到确认，则可能出现了拥塞。对于这种可能出现的拥塞，上面所述情况未使用快重传算法。而对于快重传算法，首先要求接收方在每收到一个失序报文，都会发出重复确认，而不是等自己发数据时候才捎带发送ack。当接收方连续收到3个重复确认，应当立即重传该报文而不必等待计时器时间到。
快重传算法需要和快恢复算法配合使用。在连续收到3个确认报文并重发该报文的同时，为了预防拥塞发生，把慢开始阈值ssthresh减半。此时并不去执行慢开始算法（cwnd=1），而是把cwnd设置为ssthresh减半后的数值，然后执行拥塞避免算法。在采用快恢复的算法时候，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。
我们在谈论上面四种算法的时候，假设接收方拥有足够大的缓存来接收数据。但是实际上接收方缓存有限，所以需要设定一个接收窗口rwnd，在每次向发送方返回确认的时候传送给发送方。这个接收窗口又称为通知窗口，从流量控制的角度发送方的发送窗口不能超过接收方的rwnd值。
综合拥塞控制和流量控制两方面考虑，发送窗口值=min{rwnd，cwnd}。
下一篇文章中将对http协议和HTTPS协议进行总结。