关于三次握手、四次挥手总结

1、介绍TCP的三次握手？追问：为什么TCP握手需要三次？

三次握手：

         在建立一个TCP连接时，需要客户端和服务器总共发送三个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始序列号为后面的可靠性传送做准备。实质就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

流程：

         ●第一次握手：

         客户端给服务器发送一个SYN报文，并指明客户端的初始化序列号ISN。此时客户端处于SYN_SENT状态。

         首部的同步位SYN=1，初始序号seq=X，SYN=1的报文段不能携带数据，但是需要消耗一个序号。

         ●第二次握手：

         服务器收到客户端的SYN报文后，会以自己的SYN报文作为应答，并且也是指定了自己的初始化序列号ISN（s）。同时会把客户端的ISN+1作为ACK的值，表示自己已经收到了客户端的SYN，此时服务器处于SYN_RCVD的状态。

         在确认报文中SYN=1，ACK=1,确认号ack=x+1，初始序号seq=y。

         ●第三次握手：

         客户端收到SYN报文后，会发送一个ACK报文，当然，也是一样把服务器的ISN+1作为ACK的值，表示已经收到了服务器的SYN报文，此时客户端处于ESTABLISED状态。服务器收到ACK报文之后，也是处于ESTABLISHED装态，此时，双方已经建立起了连接。

         确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=1，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

备注：

1、三次握手数据包：

第一个包（SYN包）：

第二个包（SYN+ACK包）

第三个包（ACK包）：

2、常用字段含义：

3、三次握手原理图：

 

2、为什么TCP握手需要三次？TCP建立连接可以两次握手吗？

         <1>、首先TCP是面向链接的，一次握手是建立不了链接的。

         第一次握手：客户端发送网络包，服务端收到了。服务端就知道：客户端的发送能力，服务端的就收能力是正常的。

         第二次握手：服务端发送网络包，客户端收到了。客户端就知道：服务端的接收，发送能力，客户端的接收发送能力是正常的。但是，服务器端不知道客户端是否接收能力正常。

         第三次握手：客户端发包，服务器收到了。服务器就知道，客户端的发送，接收能力正常，服务器的发送，接收能力正常。

         因此，需要三次握手才能确认双方的接收与发送能力是否正常。

         不可以，从以下两点原因来分析：

         <1>、可能会出现已经失效的链接请求报文段有传到了服务器端。

         假设client发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留了，以延误到连接释放以后的某个时间才到达server。本来这就已经是一个早已经失效的报文段。但是server收到这个失效的连接请求报文后，就会误认为client再次发出的一个新的请求连接。于是就向client发出确认报文段，同意建立连接。

         假设不采用“三次握手”，那么直要server发出确认，就代表新的连接已经建立。由于现在client并没有发出建立连接的请求，因此就不会理睬server的确认，也不会向server发送数据。但是在这个阶段，server却以为新的传输连接已经建立了，并且一直在等待client发来的数据，处于一个半连接的装态。这样就会导致server的资源浪费问题。而采用三次握手，就可以防止这个现象发生。

         <2>、两次握手无法保证client正确接收第二次握手的报文（server无法确认client是否收到），也无法保证client和server之间成功互换初始序列号。

3、可以采用四次握手吗？

         可以，但是相比较三次握手，四次握手传输效率会比较低一些。

         四次握手就是：在第二次握手中，server只发送ACK和acknowledge number；而server的SYN和初始序列号可以放在第三次握手时进行发送；就使得原来协议中的第三次握手变为第四次握手。但是，可以处于优化的目的，在四次握手中，二次握手和三次握手可以进行合并。

4、第三次握手中，如果客户端的ACK未送达服务器，会怎么样？

Server端：

         由于server没有收到ACK确认，因此会重发之前的SYN+ACK（默认重发5次，之后自动关闭连接进入到CLOSED装态），client收到后会重新传ACK给server。

         当server自动关闭这个连接后，但是client认为这个连接已经建立，如果client端向server写数据，server端将以RST包响应，才能感知到server的错误。

         当第三次握手失败时，服务器并不会重传ack报文，而是直接发送RST报文段，进入CLOSED装态，这样做的目的是为了防止SYN攻击。

RST报文：

Client端：

         <1>、在server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取ACK number，进入establish装态。

         <2>、在server进入CLOSED状态之后，如果Client向服务器端发送数据，服务器会以RST包应答。

5、什么是SYN攻击？

         原理：

         <1>、Client伪造大量的虚假IP，向server发送SYN包

         <2>、server在接收到SYN包后，会返回响应，并进入SYN_RECV状态，等待客户端确认。

         <3>、伪造的IP不会给予响应，于是server以为数据包丢失，不断重发，直到超时。

         危害：

         这些伪造的SYN包会长期占用未连接队列，导致后来真实的IP无法加入队列，从而被丢弃，引起网络拥堵甚至网络瘫痪。

         检查SYN攻击：

         当服务器上有大量的半连接且ip为随机的，可以确定是SYN攻击。

         netstat  -nap | grep  SYN_RECV

6、如何防御SYN攻击？

         <1>、缩短超时时间（SYN Timeout）

         <2>、增加最大半连接数

         <3>、过滤网关防护

         <4>、SYN cookies技术

7、如果已经建立了连接，但是客户端出现了故障怎么办？

         服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2个小时，若两个小时还没有收到客户端的任何数据，服务器就会发送一个探测报文，以后每隔75秒发送一次。若连续发送10个探测报文任然没有反应，服务器就会认为客户端出了故障，接着就关闭连接。

8、三次握手过程中可以携带数据吗？

         在第一次和第二次不可以，在第三次握手的时候是可以携带数据的。

         假设第一次可以携带数据。如果有人想要恶意攻击服务器，那他每次都在第一次握手中的SYN报文中放入大量的数据。因为攻击者根本就不会理睬服务器的接收，发送能力是否正常，然后疯狂着重复发送SYN报文的话，会让服务器花费很多时间，内存空间来接收这些报文。

         而对于第三次连接的时候，此时客户端就已经处于ESTABLISTEND状态。对于客户端来说，他已经建立连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以携带数据也是没问题的。

9、队列问题

         ●半连接队列

         服务器第一次收到客户端的SYN之后，就会处于SYN_RCVD状态，此时双方还没有完全建立其连接，服务器就会把这种状态下请求的连接放在一个队列里，这种队列就是半连接队列。

         ●全连接队列

         已经完成三次握手，建立其连接的就会放在全连接队列中。如果队列满了就会出现丢包现象。

         补充：关于SYN-ACK重传次数问题：

                   服务器端发送完SYN-ACK包，如果未收到客户端确认包，服务器端进行首次重传，等待一段时间任然没有收到客户确认包，进行第二次重传，如果重传次数超过规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传输等待的时间不一定相同，一般是指数增长，例如时间间隔为1s,2s,4s,8s,……

10、TCP四次挥手

         TCP连接的拆除需要发送四个数据包，因此成为四次挥手。客户端或者服务器端均可以发起挥手动作，任何一方发起close()操作即可产生挥手操作。

附四次挥手图示：

         流程：

         假设双方都处于established状态，假设客户端先发起关闭请求。

         ●第一次挥手：

         客户端发送一个FIN报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。即发出连接释放报文段（FIN=1,序号seq=u），并且停止再发送数据，主动关闭TCP连接，FIN_WAIT1（终止等待1）状态，等待服务端的确认。

         ●第二次挥手：

         服务器端收到FIN之后，会发送ACK报文，且把客户端的序列号值+1（ACK=seq+1）作为ACK报文的序列号值，表名已经收到客户端的报文了，此时服务器端处于CLOSE_WAIT状态。

         即服务器端收到连接释放报文段后即发出确认报文段（ACK=1,确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT(关闭等待)状态，此时的TCP处于半闭状态，客户端到服务端的链接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的链接释放报文段。

    ●第三次挥手：

         如果服务器也想断开连接了，和客户端的第一次挥手一样，发送FIN报文，且指定一个序列号。此时服务端处于LAST_ACK的状态。

         即服务端没有要想客户端发出的数据，服务端发出的链接释放报文段（FIN=1,ACK=1,序号seq=w,确认号ack=u+1）,服务端进入LAST_ACK(最后确认)状态，等待客户端的确认。

         ●第四次挥手：

         客户端收到FIN之后，一样发送一个ACK报文作为应答，且把服务端的序列号值+1作为自己ACK报文的序列号值，此时客户端处于TIME_WAIT状态。需要过一会儿以确保服务端收到自己的ACK报文之后才会进入CLOSED状态，服务端收到ACK报文之后，就处于关闭连接了，处于CLOSED状态。

         即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1,seq=u+1,ack=w+1），客户端进入TIME_WAIT(时间等待)状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才能进入CLOSED状态

附：1、四次挥手状态含义：

2、四次挥手数据包：

第一个包：这个包是客户端先断开的，所以FIN先由客户端发出。

第二个包：服务器对客户端发出的FIN包进行确认，ack=seq+1

第三个包：由服务端发出断开，FIN位置为1，ACK为1

第四个包：客户端收到服务端的FIN后，给服务端回复ACK，确认序列号为ack=seq+1。

 

11、为什么不把第二次和第三次挥手合并起来，二者有何区别？

         因为服务器收到客户端断开连接请求时，可能还有一些数据没有发完，这时先回复ACK，表示已经收到了客户端的断开请求连接。等到数据发完之后再发FIN，这时再断开服务器到客户端的数据传送。

         只有等到服务端所有的报文都发送完了，才能发送FIN报文，因此不能一起发送。所以，需要四次挥手。

12、客户端的TIME_WAIT状态的意义是什么？

         ●保证客户端发送的最后一个ACK报文能够到达服务端

    在第四次挥手时，客户端发送给服务器的ACK有可能丢失，TINE_WAIT状态就是用来重发可能丢失的ACK报文。如果Server没有收到ACK，就会重新发送FIN，如果Client在2*MSL的时间内再次收到了Server的FIN，Client就会重新发送ACK并且再次等待2MSL，防止Server没有收到ACK而不断的重发FIN。

    MSL（Maximum Segment Lifetime），是指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需要的最大时间。如果知道2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被Server成功接收，则结束TCP连接。

    ●防止“已经失效的连接请求报文段”出现在本连接中。

    客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

    理论上，当四个报文都发送完毕了，就可以直接进入到CLOSE状态了，但是可能网络时不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。