本文共 1488 字，大约阅读时间需要 4 分钟。

**

tcp三次握手和四次握手

**

符号说明

seq:"sequance"序列号

ack:"acknowledge"确认号

SYN:"synchronize"请求同步标志

ACK:“acknowledge"确认标志”

FIN："Finally"结束标志

三次握手过程:

1.首先服务端处以LISTEN监听状态，等待客户端的请求，此时客户端A发送建立连接的请求，SYN=1,选择一个序号x 2.B收到连接请求，如果同意建立连接，则向A发送连接确认报文，此时SYN=1，ACK=1,确认号ack=x+1,选择一个序号y 3.A收到服务器的确认报文，再次向B发送确认，确认号为ack=y+1,选择序号为x+1（在刚开始发送连接请求的基础上加一）

三次握手的原因

三次握手的原因是因为，在发送连接请求的过程当中，有可能报文信息在网络中滞留的时间过长，导致客户端等待很长时间才能收到服务器端的连接确认报文，而此时客户端有个超时重传的规则。就会重新发送连接请求，由于之前的那个在网络中滞留过长的连接请求最终还是被服务器同意建立连接了，发送确认报文给客户端，如果说没有第三次握手，那么此时，客户端就会再次向服务器端发出确认，因而打开了错误的连接。如果有了第三次握手的话，那么在收到了服务器的确认报文之后，就会忽略该滞留的连接，不进行第三次握手，服务器因此也就不用打开该连接，而去处理那个重新发送的连接。

可以仅仅是两次握手吗？

不能，在只有两次“握手”的情形下，假设Client想跟Server建立连接，但是却因为中途连接请求的数据报丢失了，故Client端不得不重新发送一遍；这个时候Server端仅收到一个连接请求，因此可以正常的建立连接。但是，有时候Client端重新发送请求不是因为数据报丢失了，而是有可能数据传输过程因为网络并发量很大在某结点被阻塞了，这种情形下Server端将先后收到2次请求，并持续等待两个Client请求向他发送数据…问题就在这里，Cient端实际上只有一次请求，而Server端却有2个响应，极端的情况可能由于Client端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待，因而造成极大的资源浪费！所以，“三次握手”很有必要！

四次握手过程分析:

1.客户端A发送连接释放报文，此时FIN=1.

2.服务器受到了客户端释放报文，此时tcp处以半关闭状态，B可以向A发送数据，但是A不能向B发送数据。

3.当B传送完数据之后，就可以释放连接了，因此向A发送释放连接报文FIN=1

4.A收到后发出确认，进入了TIME-WAIT状态，等待2MSL（最大报文存活时间），后释放连接

5.B收到A的确认之后，释放连接。

为什么要进行四次挥手？

因为当客户端不传输数据的时候，并不能保证服务器也不会传输数据，所以当客户端发送了连接释放的报文，B收到之后，就会进入CLOSE-WAIT状态，把可能还未传输完成的数据发送给客户端，这也算是一次挥手的过程。等B不再用传输数据之后，就发送释放报文给A，这是另一次挥手，后面A收到回复之后，再次发出确认给B，这也是一个挥手。（总之它跟三次握手建立连接的过程相比，中间多了一步数据传输的过程）

为什么需要等待2MSL时间客户端再关闭连接

1.确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。

2.等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

转载地址：http://jrlen.baihongyu.com/