计算机网络中的TCP/UDP协议到底是怎么回事（二）
上一篇博客阐述了TCP/IP五层网络结构模型以及一些关于TCP、UDP的基础知识，这篇博客会接着写一些关于TCP拥塞控制的算法以及对TCP中常有的疑问进行解答。
TCP拥塞控制
首先了解几个概念，为下面的叙述做铺垫
- 拥塞窗口（cwnd）：TCP拥塞控制中的主要参数，表示发送端下一次最多可以发送的数据分包的个数，是来自发送端的流量控制。
-
接收端窗口（rwnd）：又称通知窗口（
Advertise Window），接受端目前每次所能接收的数据分组的最大个数，是来自接收端的流量控制。 - 慢开始门限（ssthresh）：当拥塞窗口增长到慢开始门限时，启动拥塞避免算法（后面会具体阐述）。
- 拥塞控制常用算法：慢开始、拥塞避免、快重传、快恢复。
最初，发送方不知道接收方的容纳能力，如果初次就发送较大量的数据，极有可能造成整个网络的瘫痪，TCP为了防止此类问题的出现，在通信一开始就会通过一个叫慢开始的算法得到的数值，对发送数据量进行控制。
慢开始：
由于需要考虑拥塞控制和流量控制两个方面的内容，发送端的发送窗口为min(cwnd，rwnd)，但是rwnd是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑rwnd的值，我们暂时只讨论如何确定cwnd值的大小。
在执行慢开始算法时，拥塞窗口 cwnd的初始值为 1，发送第一个报文段。当发送端收到来自接收端的ACK之后，拥塞窗口开始以1、2、4这样的指数形式增长。当拥塞窗口cwnd 增长到慢开始门限值 ssthresh 时，就改为执行拥塞避免算法，拥塞窗口按线性规律增长。
拥塞避免：
最初，拥塞窗口指数增长，可以很快进行大数据的发送，最大限度的利用网络宽带资源。当达到慢开始门限值，开始进入拥塞避免阶段，拥塞窗口开始加法增加。这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。
快重传与快速恢复
上面都没有遇到网络拥塞，当真正遇到网络拥塞时，如何处理呢？当发送方连续收到三个重复的ACK之后，TCP会进入快速重传、快速恢复的阶段。
为什么叫快速重传呢？如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时，相比之下，前者速度更快。
快速恢复的主要步骤：
- 当收到3个重复ACK时，把
ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段。 - 再收到重复的ACK时，拥塞窗口增加1。
- 当收到新的数据包的ACK时，把
cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。
TCP窗口变化
当TCP通信开始之后，网络吞吐量会逐渐上升，但是随着网络拥堵的发生，吞吐量也会急速下降。于是会再次进入吞吐量慢慢上升的过程。但是所谓TCP的吞吐量的特点就好像是在逐渐占领网络宽带的感觉。
TCP疑问解答
为什么采用三次握手而不是二次握手？
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
TCP三次握手时，第三次握手失败怎么办？
如果三次都成功的话：
- 客户端发出了SYN包给服务器,客户端进入SYN_SEND状态。
- 服务器收到SYN包后发出SYN+ACK数据包,服务器进入SYN_RECV状态。
- 客户端收到SYN+ACK后发出ACK给服务器,客户端进入ESTABLISH状态
- 服务器收到最后的ACK，服务器进入ESTABLISH状态。
我们了解一下TCP状态转换图和状态伪码可以发现：
case：SYN_RECV状态
if(收到ACK报文)
进入ESTABLISH状态
if(超时)
发送RTS报文，进入CLOSED状态
if(收到“关闭报文”)
发送FIN报文，进入FIN_WAIT_1状态
if(收到RTS报文)
进入LISTEN状态
if(收到其他报文段或报文)
发出差错报文
break
当第三次握手失败时的处理操作，可以看出当失败时服务器并不会重传ACK报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。
何为SYN洪泛攻击呢？在TCP连接建立过程中很容易碰到严重的的安全问题，称为SYN洪泛攻击。当一个或多个恶意攻击者向服务器发送大量的SYN报文时，服务器认为不同客户发来了打开请求，于是就回分配资源。然后，服务器向假冒的客户发送SYN＋ACK报文，而这些报文都丢失了。如果在第三次握手这段很短的时间内，服务器大量资源被占用而没有被利用，服务器会因为资源耗尽而无法接受合法客户的连接请求。这种SYN洪泛攻击称为拒绝服务攻击的安全攻击，即攻击者用大量的请求垄断一个系统，使这个系统因超载而拒绝为合法的请求提供服务。（更多内容请参考TCP/IP协议簇一书）
关闭连接时半关闭选项的四向握手
TCP连接是全双工的，所以它允许两个方向的数据传输被独立关闭。换言之，通信的一端可以发送结束报文段给对方，告诉它本端已经完成了数据的发送，但允许继续接收来自对方的数据，直到对方也发送结束报文段以关闭连接。TCP连接的这种状态称为半关闭（half close）状态。
当客户端向服务器发送一个FIN报文段后，此连接被半关闭了。服务器发送ACK报文段来接受这个半关闭。但是服务器仍然可以发送数据，当服务器把处理完的数据都发送完毕之后，发送FIN报文段（半关闭），并且被客户发来的ACK予以确认（关闭）。
当关闭连接时最后一个ACK丢失怎么办？
如果最后一个ACK丢失的话，TCP就会认为它的FIN丢失，进行重发FIN。在客户端收到FIN后，就会设置一个2MSL计时器，2MSL计时器可以使客户等待足够长的时间，使得在ACK丢失的情况下，可以等到下一个FIN的到来。如果在TIME－WAIT状态汇总有一个新的FIN到达了，客户就会发送一个新的ACK，并重新设置2MSL计时器。
示例图解如下：
半关闭终止时间图
如果重传FIN到达客户端时，客户端已经进入CLOSED状态时，那么客户就永远收不到这个重传的FIN报文段，服务器收不到ACK，服务器无法关闭连接。
但是服务器并不会一直无法关闭，服务器会进行不断的探查，会发送十个间隔为75秒的探查，如果探查都没有收到回应，则认为客户端已经关闭，服务器也将关闭，终止链接。
PS
