TCP的三次握手和四次挥手

要搞懂这个首先得了解TCP报文段和及其首部格式，如图：



ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1

SYN ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1. 因此, SYN置1就表示这是一个连接请求或连接接受报文。

FIN ：即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。
序号（seq）：指本报文段所发送的数据的第一个字节的序。例如一个报文段的序号字段是301，携带的数据共有100字节。显然下一个报文段的序号应该从401开始
确认号（ack）：是期望收到对方的下一个数据字节的序号，例如B正确收到了A发过来的一个报文段，其序号是501，数据长度是200，则B期望收到的下一个数据序号是701，于是B把确认号（ack）置为701。

注意：TCP采用的是累积确认，即确认是对所有按序接收的数据的确认，但请注意，接收方返回的确认号是已按序号收到的数据的最高序加1



三次握手：



分析：

主机A向TCP发出主动打开命令，表明要向某个IP地址的某个端口建立传输连接。主机B向TCP发送一个被动打开命令，准备接受客户端的连接请求，自己处于监听状态。

B的服务器进程创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程处于LISTEN状态，等待客服端的连接请求。

A打的TCP客服端进程创建控制块TCB，然后向B发送连接请求报文段。该报文的首部SYN=1，并且假设序号seq=x。TCP规定，该连接请求报文段不携带任何数据，但需要占用一个序号。A发送了连接请求报文后进入SYN-SENT状态。

B收到A的连接请求报文后，会向A返回连接接受报文。该报文的首部SYN=1，ACK=1，seq=y,ack=x+1。TCP也规定，连接接受报文段也不携带任何数据，但也需要占用一个序号。B发送该报文后立即进入SYN-RECD状态。

A收到B的连接接受报文后，还需要向B发送一个确认报文段。在该报文中ACK=1，seq=x+1,ack=y+1。TCP规定，在该报文段中可以携带数据，也可不携带数据。但，不携带数据时，不会消耗一个序号，也就会说下一个发送的报文段的序号仍为x+1。该报文段发送成功后，进入ESTAB-LISHED状态，。

B收到A的确认后，也进入ESTAB-ISHED状态。

思考：为什么是三次呢？

防止已经失效的连接请求报文段突然传到主机B，因而产生错误。比如A发送的第一个连接请求因为某些原因二滞留时间太长，以致于这次连接都释放了才传到B，本来这就是一个无效的报文段，但B收到此无效的连接请求后，误认为是A发送的新连接请求，于是发确认连接，同意连接。而A并没有要求建立连接，所以不会理睬B发的确认连接，自然不会向B发送数据。但是B一直在等待A发送数据，这样就浪费了许多资源

四次挥手:



分析：

当客户A 没有东西要发送时就要释放 A 这边的连接，A会发送一个报文（没有数据），其中 FIN 设置为1, 服务器B收到后会给应用程序一个信，这时A那边的连接已经关闭，即A不再发送信息（但仍可接收信息）。 A收到B的确认后进入等待状态，等待B请求释放连接， B数据发送完成后就向A请求连接释放，也是用FIN=1 表示， 并且用 ack = u+1(如图）， A收到后回复一个确认信息，并进入 TIME_WAIT 状态， 等待 2MSL 时间。

思考：

为什么要等待？

为了这种情况： B向A发送 FIN = 1 的释放连接请求，但这个报文丢失了， A没有接到不会发送确认信息， B 超时会重传，这时A在 WAIT_TIME 还能够接收到这个请求，这时再回复一个确认就行了。（A收到 FIN = 1 的请求后 WAIT_TIME会重新记时）

为什么有保活时间：

另外服务器B存在一个保活状态，即如果A突然故障死机了，那B那边的连接资源什么时候能释放呢？ 就是保活时间到了后，B会发送探测信息， 以决定是否释放连接。