网络---TCP通信的三次握手与四次挥手

TCP（Transport control protocal ）: 一种面向连接的、可靠的、基于字节流的传输层通信协议。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：释放一个连接。

三次握手

在这里插入图片描述

三次握手过程描述：
（1）客户端和服务端都处于CLOSED状态，第一次握手时，客户端发起，客户端与服务端建立连接，SYN = 1，seq = x；之后客户端处于SYN-SEND状态，服务端置于LISTEN状态；

（2）服务端接收到消息后，发起第二次握手，SYN = 1，ACK = 1；服务端发起握手之后处于SYN-REVD状态；

（3）客户端接收到服务端的连接，发起第三次握手，ACK= 1，客户端发出握手之后处于ESTAB-LISTHED状态，服务端接收到第三次握手消息后处于ESTAB-LISTHED状态，都处于ESTAB-LISTHED状态之后就可以进行双向通信了。

四次挥手

在这里插入图片描述

四次挥手的过程描述：

1. 客户端主动发起第一次挥手，FIN = 1，客户端发出挥手后处于FIN-WAIT-1状态；
2. 服务端接收到挥手消息后，发起第二次挥手，ACK = 1，服务端处于CLOSE-WAIT状态；
3. 客户端接收到第二次挥手消息后，处于FIN-WAIT-2状态，即客户端不能给服务端发送消息，服务端可以给客户端发消息（全双工-单向通信）；
4. 服务端发起第三次挥手，FIN=1，ACK=1，服务端处于LAST-ACK状态；
5. 客户端接收到第三次挥手的消息后，发起第四次挥手，ACK=1，客户端处于TIME-WAIT状态；
6. 服务端接收到客户端挥手消息，即进入CLOSED状态，客户端在2MSL时间之后由TIME-WAIT状态进入到CLOSED状态。

注意： seq = w的原因：在进行两次挥手之后，客户端不能给服务端发消息了，而服务端还可以给客户端发消息，序列号是不断改变的，所以在第三次服务端给客户端进行第三次挥手时，seq = w 而不是seq = v + 1；

TCP协议的特点是面向连接的、可靠的，而数据可靠性的体现在哪？？

数据通信前进行连接，通信结束后释放连接；
保证数据完全到达目的端：确认应答机制和超时重传机制；
接收方接收的数据都是有序的，在发送数据头部的序号+数据的大小，就可以确定数据的位置以及下一次接收数据的起始位置；
数据发送和接收都是完全相同的，通过头部的校验和字段来判断接收数据是否存在损坏，存在损坏则丢弃重新接收客户端的发送。

三次握手 四次挥手的相关问题

为什么要进行三次握手呢？？？

在这里插入图片描述

在结束连接的过程中，为什么在收到服务器端的连接释放报文段之后，客户端还要继续等待2MSL之后才真正关闭TCP连接呢？

这里有两个原因：

第一个是：需要保证服务器端收到了客户端的最后一条确认报文。假如这条报文丢失，服务器没有接收到确认报文，就会对连接释放报文进行超时重传，而此时客户端连接已关闭，无法做出响应，就造成了服务器端不停重传连接释放报文，而无法正常进入关闭状态的状况。而等待2MSL，就可以保证服务器端收到了最终确认；若服务器端没有收到，那么在2MSL之内客户端一定会收到服务器端的重传报文，此时客户端就会重传确认报文，并重置计时器。

第二个是：存在一种“已失效的连接请求报文段”，需要避免这种报文端出现在本连接中，造成异常。这种“已失效的连接请求报文段”是这么形成的：假如客户端发出了连接请求报文，然而服务器端没有收到，于是客户端进行超时重传，再一次发送了连接请求报文，并成功建立连接。然而，第一次发送的连接请求报文并没有丢失，只是在某个网络结点中发生了长时间滞留，随后，这个最初发送的报文段到达服务器端，会使得服务器端误以为客户端发出了新的请求，造成异常。