本系列文章对整个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协议进行总结。