TCP三次握手和四次挥手

1.简述TCP三次握手的过程？

假定客户端的起始序列号为X，服务器的起始序列号为Y。
第一次握手：客户端向服务器发送请求连接的数据包，此数据包的SYN标志被设置，序列号为X，发送数据包后客户端处于SYN_SEND状态。
第二次握手：服务器收到客户端请求连接的数据包后，需要给客户端回复，回复数据包的SYN标志和ACK标志被设置，确认号为X+1，序列号为Y，发送数据包后服务器处于SYN_RECV状态。
第三次握手：客户端收到服务器回复的数据包后，需要给服务器回复，回复数据包的ACK标志被设置，确认号为Y+1，序列号为X+1。发送数据包后客户端处于ESTABLISHED状态，服务器收到此数据包后处于ESTABLISHED状态并分配相关资源。

2.为什么需要第三次握手？

若没有第三次握手，则在第二次握手后就需要建立连接，两次握手的缺陷主要有两个：
（1）若客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达服务器。本来这是一个早已失效的报文段。但服务器收到此失效的连接请求报文段后，就误认为是客户端再次发出的一个新的连接请求。于是就向客户端发出确认报文段，同意建立连接。由于现在客户端并没有发出建立连接的请求，因此不会理睬服务器的确认报文，也不会向服务器发送数据。但服务器却以为新的连接已经建立，并一直等待 客户端发送数据。这样服务器的资源就白白浪费掉了。采用“三次握手”可以防止上述现象发生。
（2）两次握手无法保证客户端正确接收第二次握手的报文（服务器无法确认客户端是否收到第二次握手的报文），也无法保证客户单和服务器之间成功互换初始序列号。

3.第三次握手失败了怎么办？

如果客户端给服务器返回了ACK报文，但服务器并没有收到这个ACK报文。那么服务器就会启动超时重传机制，超过规定时间后重新发送SYN+ACK，重传次数据/proc/sys/net/ipv4/tcp_synack_retries来指定，默认是5次。如果重传指定次数到了后，仍然未收到ACK应答，那么一段时间后，server自动关闭这个连接。但是client认为这个连接已经建立，如果client端向server写数据，server端将以RST包响应。若ACK丢失后，客户端紧接着发送的数据报文，服务器若收到数据报文，则正确的获取了序列号，此时服务器不会发送RST报文。

4.简述TCP四次挥手的过程？

TCP是全双工通信，单个方向的连接需要两次挥手才能关闭。假定客户端的列号为X，服务器的序列号为Y。
第一次挥手：客户端向服务器发送关闭连接的请求，设置FIN标志，序列号为X，客户端随后进入FIN_WAIT_1状态。
第二次挥手：服务器回复客户端关闭连接的请求，设置ACK标志，确认号为X+1，序列号为Y，服务器随后进入CLOSE_WAIT状态。此时客户端到服务器的单向通信已经关闭，客户端不会再向服务器发送数据，但仍可以接受服务器发送的数据。
第三次挥手：服务器向客户端发送关闭连接的请求，设置FIN标志，确认号为X+1，序列号为Z（第二次挥手后服务器可能会向客户端发送数据，因此序列号会变动，这里用Z表示），服务器随后进入LAST_ACK状态。
第四次挥手：客户端向服务器回复关闭连接的请求，设置ACK标志，确认号为Z+1，序列号为X+1，客户端进入TIME_WAIT状态，等待2MSL（报文段最长寿命），之后进入CLOSED状态。若服务器收到数据，则也进入CLOSED状态。

5.为什么需要四次挥手？

当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，因此己方ACK和FIN一般都会分开发送。

6.TIME_WAIT状态

TCP的TIME_WAIT状态也称为2MSL等待状态，在该状态中，TCP将会等待两倍于最大段生存期的时间，有时也被称为加倍等待。当TCP的一端发起主动关闭，在发出最后一个ACK包后，即第3次挥手完成后发送了第4次挥手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次挥手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用，不过在实际应用中可以通过设置SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。

7.TCP流量控制

所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。流量控制往往指的是点对点通信量的控制，是个端到端的问题。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。发送方发送的数据不能超过接收方给出的接收窗口的数值。

8.TCP拥塞控制

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。拥塞问题是一个全局性的问题,涉及到所有的主机、所有的路由器、以及与降低网络传输性能有关的所有因素。发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量，发送方通过改变此变量，用来达到拥塞控制的目的。拥塞控制算法有四种。
（1）慢开始（Slow-start)
最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加至多1个MSS大小。用这样的方法来逐步增大拥塞窗口。
为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

当cwnd<ssthresh时，使用慢开始算法。
　　当cwnd>ssthresh时，改用拥塞避免算法。
　　当cwnd=ssthresh时，慢开始与拥塞避免算法任意

（2）拥塞避免（Congestion Avoidance)
每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。
（3）快重传（Fast Restrangsmit)
快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。
（4）快恢复（Fast Recovery）