三次握手

TCP连接的建立—三次握手建立TCP连接

在这里插入图片描述

① 若主机A中运行了一个客户进程，当它需要主机B的服务时，就发起TCP连接请求，并在所发送的分段中用SYN=1表示连接请求，并产生一个随机发送序号x，如果连接成功，A将以x作为其发送序号的初始值：seq=x。主机B收到A的连接请求报文，就完成了第一次握手。

客户端发送SYN=1表示连接请求
客户端发送一个随机发送序号x，如果连接成功，A将以x作为其发送序号的初始值：seq=x

② 主机B如果同意建立连接，则向主机A发送确认报文，用SYN=1和ACK=1表示同意连接，用ack=x+1表明正确收到A的序号为x的连接请求，同时也为自己选择一个随即发送序号seq=y作为它的发送序号的初始值。主机A收到主机B的请求应答报文，完成第二次握手。

服务端发送SYN=1和ACK=1表示同意连接
服务端发送ack=x+1表明正确收到A的序号为x的连接请求
服务端发送一个随即发送序号seq=y作为它的发送序号的初始值

③ 主机A收到主机B的确认后，还要向主机B发出确认，用ACK=1表示同意连接，用ack=y+1表明收到B对连接的应答，同时发送A的第一个数据seq=x+1。主机B收到主机A的确认报文，完成第三次握手。此时双方就可以使用协定好的参数以及各自分配的资源进行正常的数据通信了。

客户端发送ACK=1表示同意连接
客户端发送ack=y+1表明收到B对连接的应答，同时发送A的第一个数据seq=x+1

为什么需要三次握手，两次不行？

为了确认双方的接收能力和发送能力都正常。

通过第三次握手，主要目的是为了防止已失效的连接请求报文段突然又传送到了主机B，因而产生错误。

所谓“失效的连接请求报文段”是指一端（如A）发出的连接请求，由于没有在允许的时间内传送到目的方（如B），使得发送方不得不又发送一个新的连接请求报文段。

而在新的连接请求建立并传送完数据将连接释放后，出现了一种情况，即主机A发出的第一个连接请求报文段迟迟到达了B。本来，这是一个已经失效的报文段，但主机B收到此失效的连接请求报文段后，就误认为是主机A又发出一次新的连接请求，于是向主机A发出确认报文段，同意建立连接。主机A由于并没有要求建立连接，因此不会理睬主机B的确认，也不会向主机B发送数据。但主机B却以为传输连接就这样建立了，并一直等待主机A发来数据。主机B的许多资源就这样白白浪费了。

采用三次握手机制可以防止上述现象的发生。在上述情况下，主机A就不会理睬主机B发来的确认，也不会向主机B发出确认报文，连接也就建立不起来。

四次挥手

TCP连接的拆除—用四次握手释放TCP连接

在这里插入图片描述
① 在数据传输结束后，通信双方都可以释放连接。在上图，主机A的应用进程先向其TCP发出连接释放请求，并不再发送数据。TCP通知对方要释放从A到B这个方向的连接，便发送FIN=1的报文段给主机B，其序号u等于已传送过的数据的最后一个字节的序号加1。这时A处于等待B确认的状态。

② 主机B的TCP收到释放连接的通知后，即发出确认，其确认序号ack=u+1，而这个报文段自己的序号是v，等于主机B已经传送过的数据的最后一个字节的序号加1，同时通知高层的应用进程。这样，从A到B的连接就释放了，连接处于半关闭状态，即主机A已经没有数据要发送了，但主机B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，可能还要等待一段时间。等待是因为若主机B还有一些数据要发往主机A，则可以继续发送，主机A只要收到数据，仍应向主机B发送确认。

③ 在主机B向主机A的数据发送结束后，其应用进程就通知TCP释放连接。主机B发出的连接释放报文段必须将FIN置1，先假设B的序号为w（在半关闭状态下主机B可能又发送了一些数据），同时还必须重复上次已发送过的确认序号ack=u+1。这时主机B进入等待A的确认状态。

④ 主机A收到B的连接释放报文段后，必须对此发出确认，在确认报文段中将ACK置1，给出确认序号ack=w+1，而自己的序号是seq=u+1。从B到A的连接被释放掉。主机A的TCP再向其应用进程报告，整个连接已经全部释放。