TCP的三次握手与四次挥手

1.TCP的三次握手

基本概念：

概念：所谓“三次握手”就是TCP连接建立的过程，即需要客户端与服务端总共发送三个包，以确认连接的建立。
通过“三次握手”保证了客户端与服务器建立的是双工连接，而可靠性是更多是通过重发机制实现的。

图解：

过程简述：

1.第一次握手
Client将标志位SYN置为1，随机产生一个值seq=x，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

2.第二次握手
Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，
并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

3.第三次握手
Client收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，
如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间便可以开始传输数据了。

2.TCP的四次挥手

基本概念：

所谓“四次挥手”就是关闭TCP连接的过程，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认双方连接的断开。

图解：

过程简述：

1.第一次挥手
Client发送一个FIN（FIN=1，随机产生一个值seq=u），用来关闭Client到Server的数据传送，Client进程发出连接释放报文，并且停止发送数据。
Client进入FIN_WAIT_1（终止等待1）状态。

2.第二次挥手
Server收到FIN后，发送一个ACK（确认）给Client（ACK=1，seq=v，ack=u+1），
Server进入CLOSE_WAIT（关闭等待）状态，Client进入FIN_WAIT_2（终止等待2）状态。

3.第三次挥手
Server发送一个FIN（FIN=1，ACK=1，seq=w，ack=u+1），用来关闭Server到Client的数据传送，Server将最后的数据发送完毕后，就向Client发送连接释放报文，
Server就进入了LAST_ACK（最后确认）状态，等待客户端的确认。

4.第四次挥手
Client收到FIN后，Client进入TIME_WAIT（时间等待）状态，接着发送一个ACK（确认）给Server（ACL=1，seq=U+1， ack=w+1）
注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当Client撤销相应的TCB后，
Server和Client才进入CLOSED（已关闭）状态，完成四次挥手。

3.tcp标志位（位码）

SYN：请求创建连接/建立联机（synchronous）
ACK：确认接收（acknowledgement ）
FIN：结束（finish）
PSH：传送（push）
RST：重置（reset）
URG：紧急（urgent）

Seq：序列号（Sequence number）
ack：下一个数据包的编号

4. tcp状态

CLOSED： 初始状态，表示TCP连接是“关闭着的”或“未打开的”
 
LISTEN： 表示服务器端的某个SOCKET处于监听状态，可以接受连接了。

SYN_SENT： 表示客户端已发送SYN报文；这个状态与SYN_RCVD 状态相呼应，当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随即进入到SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。

SYN_RCVD： 表示服务器接收到了来自客户端请求连接的SYN报文；在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat很难看到这种状态，除非故意写一个监测程序，将三次TCP握手过程中最后一个ACK报文不予发送。当TCP连接处于此状态时，再收到客户端的ACK报文，它就会进入到ESTABLISHED状态。
 
ESTABLISHED： 表示TCP连接已经成功建立。
 
FIN_WAIT_1： 和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即 进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。

FIN_WAIT_2： 实际上FIN_WAIT_2状态下的SOCKET，表示半连接，即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。

TIME_WAIT： 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。

CLOSE_WAIT： 表示正在等待关闭。当对方close一个SOCKET后发送FIN报文给自己，你的系统毫无疑问地将会回应一个ACK报文给对方，此时TCP连接则进入到CLOSE_WAIT状态。接下来呢，你需要检查自己是否还有数据要发送给对方，如果没有的话，那你也就可以close这个SOCKET并发送FIN报文给对方，即关闭自己到对方这个方向的连接。有数据的话则看程序的策略，继续发送或丢弃。简单地说，当你处于CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。

LAST_ACK： 当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK 状态。当收到对方的ACK报文后，也就可以进入到CLOSED 状态了。

5.答疑解惑

（1）.为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。
只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

（2）.为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失。
所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。
所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。
如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。
MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

（3）.为什么不能用两次握手进行连接？

答：三次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，
也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，
S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。
可是，C在S的应答分组在传输中被丢失的情况下，将不知道S是否已准备好，不知道S建立什么样的序列号，
C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，
只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

(4).为什么TCP客户端最后还要发送一次确认呢？

主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
假定出现一种异常情况，即客户端发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，一直延迟到连接释放以后的某个时间才到达服务器，
本来这是一个早已失效的报文段。但服务器收到此失效的连接请求报文段后，就误认为是客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接。
假定不采用三次握手，那么只要服务器发出确认，新的连接就建立了，这样一直等待客户端发来数据，服务器的许多资源就这样白白浪费了。

(5).如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器， 时间通常是设置为2小时，
若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

(6).四次挥手释放连接时，等待2MSL的意义？

第一，为了保证客户端发送的最后一个ACK报文段能够到达服务器。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的服务器收不到对已发送的FIN和ACK 报文段的确认。
服务器会超时重传这个FIN和ACK报文段，而客户端就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着客户端重传一次确认。
第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，客户端在发送完最有一个ACK报文段后，
再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

(7).什么是SYN攻击，如何预防？

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于SYN_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态.
SYN攻击：就是攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，
服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
SYN攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.
在Linux下可以如下命令检测是否被SYN攻击    netstat -n -p TCP | grep SYN_RECV
解决方案：一般较新的TCP/IP协议栈都对这一过程进行修正来防范SYN攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.
但是不能完全防范SYN攻击。百度面试官给的一个解决方法，在服务器设置定时器，如果在限定时间内还是没有收到客户端的回应，就关闭连接。