TCP三次握手与四次挥手的浅述

TCP的三次握手与四次挥手

参考链接：https://blog.csdn.net/qzcsu/article/details/72861891

网络传输各层与相应协议与熟知端口号

网络传输分层结构

层级	名称	包含的协议
7	应用层	例如HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP
6	表示层	例如XDR、ASN.1、SMB、AFP、NCP
5	会话层	例如ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets
4	传输层	例如TCP、UDP、RTP、SCTP、SPX、ATP、IL
3	网络层	例如IP、ICMP、IGMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、 X.25
2	数据链路层	例如以太网、令牌环、HDLC、帧中继、ISDN、ATM、IEEE 802.11、FDDI、PPP
1	物理层	例如线路、无线电、光纤、信鸽

层级	名称	功能
7	应用层	文件传输，电子邮件，文件服务，虚拟终端
6	表示层	数据格式化，代码转换，数据加密
5	会话层	解除或建立与别的结点的联系
4	传输层	提供端对端的接口
3	网络层	为数据包选择路由
2	数据链路层	传输有地址的帧以及错误检测功能
1	物理层	以二进制数据形式在物理媒体上传输数据

常用熟知端口

应用程序	FTP	TFTP	TELNET	SMTP	DNS	HTTP	SSH	MYSQL
熟知端口	21,20	69	23	25	53	80	22	3306
传输层协议	TCP	UDP	TCP	TCP	UDP	TCP	TCP	TCP

TCP与UDP对比

​ 网络层可以实现两个主机之间的通信，但是并不具体，因为真正的通信实体是主机中的进程，IP协议虽然把数据报文送到目的主机，但是并没有交付给主机中具体的某个应用进程，而端到端的通信才应该是应用进程之间的通信。

1. UDP

   ​ 在数据传送前不需要进行建立连接，同样也不需要数据接收方的回复，因此，UDP不提供可靠的数据交付，但也正是因为这个特点，使得它一方面省去很多开销，另一方面数据传输相对较快。对一些对实时性要求较高的服务是更高的选择。对应的应用层的协议有：DNS、TFTP、DHCP、SNMP、NFS等。

2. TCP

   ​ 面向连接的服务，在传输数据前要建立连接，数据传送完要释放连接。因此，TCP一种可靠数据传输服务，但也因为这样增加了许多开销，比如确认，流量控制等。对应的应用层协议有：SPTP、TELNET、HTTP、FTP等。

TCP三次握手与相应协议

一. 握手过程

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

1. 第一次握手：
   建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；
   SYN：同步序列编号(Synchronize Sequence Numbers)
2. 第二次握手：
   服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个ACK包（ACK=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；
3. 第三次握手：
   客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ACK=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手.

完成三次握手后，客户端与服务器之间开始传输数据。

基于TCP的syn握手特性，产生syn攻击：

​ 在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：
​ netstat -nap | grep SYN_RECV

图示：

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

一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

​ 如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

​ 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

三. TCP报文格式

图示：

上图中有几个字段需要重点介绍下：
（1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
（A）URG：紧急指针（urgent pointer）有效。
（B）ACK：确认序号有效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）SYN：发起一个新连接。
（F）FIN：释放一个连接。

​ 需要注意的是：
​ （A）不要将确认序号Ack与标志位中的ACK搞混了。
​ （B）确认方Ack=发起方Req+1，两端配对。

TCP连接的释放（四次挥手）

​ 所谓四次握手，就是断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

​ 由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。TCP连接的断开分为两种情况：(1).一方主动断开；(2).双方主动断开

1. 一方主动断开

​ （1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

​ （2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

​ （3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

​ （4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

图示：

2.双方同时断开

​ 正常情况下，TCP在断开过程中，由客户端或服务端一方发送FIN，请求断开，等待接收来自对方的ACK。但在双方同时发送FIN请求断开的情况下，发送方所接收的并不是ACK，而是对方发来的FIN，那么发送方就会进入CLOSING状态，并且向对方发送ACK确认，接收方也是同理。双反都是主动断开，都会进入TIME_WAIT状态。

图示：

注：在思考TCP连接与断开过程的问题中，可考虑网络堵塞因素