TCP三次握手+四次挥手

TCP三次握手

TCP报文是TCP层传输的数据单元,也叫报文段.
TCP报文重要的控制字段

ACK	1(确认收到数据包)0(不确认)
SYN	1(发送请求建立连接)0(不请求)
FIN	1(发送请求断开连接)0(不请求)
–	–
Seq	因为文件过大,传输可能会产生顺序紊乱,为解决这个问题,产生了seq序列

TCP三次握手过程如下图所示：

1)为什么要三次握手?
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

举个栗子：
“已失效的连接请求报文段”的产生：客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达服务端。

本来这是一个早已失效的报文段。但服务端收到此失效的连接请求报文段后，就误认为是客户端再次发出的一个新的连接请求。于是就向客户端发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要服务端发出确认，新的连接就建立了。由于现在客户端并没有发出建立连接的请求，因此不会理睬服务端的确认，也不会向服务端发送数据。但服务端却以为新的运输连接已经建立，并一直等待客户端发来数据。这样，服务端的很多资源就白白浪费掉了。

采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，客户端不会向服务端的确认发出确认。服务端由于收不到确认，就知道客户端并没有要求建立连接。这就很明白了，防止了服务器端的一直等待而浪费资源。

下面附上一张三次握手图:

三次握手过程详解:

//此时client已经有了server端的IP地址
serverA: SYN=1  seq=x 
//主机A 向主机B 发送SYN=1建立连接请求  生成seq编号 seq=x(A-->B第一个数据包).
serverB: SYN=1 ACK=1 seq=y ACK=x+1
//主机B 向主机A 发送SYN=1建立连接请求 确认收到数据 生成 seq编号seq=y(B-->A第一个数据包) 确认下一次A要给我发送 x+1
serverA: ACK=1 seq=x+1 ACK=y+1
//主机A 向主机B 确认收到数据 发送B想要的x+1 确认下一次B要给我发送y+1

TCP三次握手过程中的状态

1. 初始阶段
   客户端和服务器都处于CLOSED状态.

2. 服务器运行服务
   systemctl start sshd
   从CLOSED状态 变成 LISTEN 监听状态.

3. 客户端向服务器发送SYN请求建立连接
   从CLOSED状态 变成 SYN_SENT 已发送状态

4. 服务端向客户端发送ACK确认 同时发送SYN请求建立连接
   从LISTEN状态 变成SYN_RCVD 同步状态
   注意:黑客会利用三次握手的缺陷对服务器进行洪水攻击
   netstat -na | grep SYN_RCVD |more 统计数量.
   解决方法:扩展

5. 客户端向服务端发送ACK确认
   从SYN_SENT状态 变成 ESTABLISHED状态

6. 服务器从SYN_RCVD状态 变成 ESTABLISHED状态

送礼物的过程:

1. 男孩和女孩想搞对象 进行表白(SYN=1) 并且向女孩送了第一个礼物(seq=x)
2. 女孩确认收到了男孩的礼物(ACK=1) 女孩也想和男孩搞对象(SYN=1)
   并且女孩告诉男孩 你应该送给我第二个礼物了(ack=x+1)
   并且女孩也送给了男孩第一个礼物(seq=y)
3. 男孩确认收到了女孩的信息(ACK=1)
   并且向女孩送了第二个礼物(seq=x+1) 这个 序号是女孩告诉男生的
   并且男孩也告知女孩 你应该给我送第二个礼物了(ack=y+1)

TCP四次挥手

过程:
1)主机A 向主机B 发送FIN 断开请求
2)主机B 向主机A 发送 ACK确认信息
3)主机B 向主机A 发送FIN 断开请求 ACK确认信息
4)主机A 向主机B 发送ACK确认

图解

为什么要四次分手？

那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，主机1收到主机2的FIN报文段时，回复ACK，表示知道主机2也没有数据传输了，之后彼此就会愉快的中断这次TCP连接。

四次挥手过程详解:
注意:谁主动关闭谁就处于TIME-WAIT状态
初始状态:
客户端和服务器处于 ESTABLISHED状态
1)客户端向服务器发送FIN断开连接请求
客户端状态 由 ESTABLISHED状态 变成 FIN-WAIT-1 终止等待状态
2)服务端向客户端发送ACK确认信息
服务端由ESTABLISHED状态 变成 CLOSE-WAIT 关闭等待

3)客户端收到请求后由 FIN-WAIT-1 变成 FIN-WAIT-2 终止等待状态2
4)服务器把没有发送完的数据传送完毕 主要发送FIN请求断开
服务器从 CLOSE-WAIT 变成 LAST-ACK 最终确认状态
5)客户端收到请求后 发送最后的ACK确认信息
客户端从 FIN-WAIT-2 变成 TIME-WAIT 时间等待
客户端经过2*MSL 报文最大存活时间 变成 CLOSE 关闭状态
6) 服务器接收到客户端的确认后 直接从 LAST-ACK 变成 CLOSE状态