TCP的三次握手与四次挥手的深刻总结

TCP协议报文构成

TCP/IP协议是个协议族，包含各种协议这里不再叙述，主要分为链路层、网络层、传输层、应用层。这里主要讲一下面向连接过程的传输层TCP协议。它的报文结构如下图：

• 序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

• 确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

• 确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

• 同步SYN（synchronous）：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

• 终止FIN（finish）：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

• URG （urgent） 紧急指针是否有效。为1，表示某一位需要被优先处理

• ACK （acknowledgement） 确认号是否有效，一般置为1。

• PSH （push） 提示接收端应用程序立即从TCP缓冲区把数据读走

• RST （reset） 对方要求重新建立连接，复位。

• ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

粗体关键字段比较重要

三次握手的过程

下图为客户端和服务端三次握手的过程：

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

关于伯克利套接字的说明

我们在Linux类操作系统环境下实现网络通信通常会使用伯克利套接字。伯克利套接字**（Berkeley sockets），也称为**BSD Socket。伯克利套接字的应用编程接口（API）是采用C语言的进程间通信的库，经常用在计算机网络间的通信。 BSD Socket的应用编程接口已经是网络套接字的事实上的抽象标准。大多数其他程序语言使用一种相似的编程接口。BSD Socket作为一种API，允许不同主机或者同一个计算机上的不同进程之间的通信。它支持多种I/O设备和驱动，但是具体的实现是依赖操作系统的。这种接口对于TCP/IP是必不可少的，所以是互联网的基础技术之一。它最初是由加州伯克利大学为Unix系统开发出来的。所有现代的操作系统都都实现了伯克利套接字接口，因为它已经是连接互联网的标准接口了。

和连接建立相关的API有：connect, listen, accept3个，connect用在客户端，另外2个用在服务端。对于TCP/IP protocol stack来说，我们这里只讨论这3个应用层的API干了什么事情。

connect:

发送了一个SYN，收到Server的SYN+ACK后，代表连接完成。发送最后一个ACK是protocol stack,tcp_out完成的。

listen

在Server这端，准备了一个未完成的连接队列，保存只收到SYN_C的socket结构；还准备了已完成的连接队列，保存了收到了最后一个ACK的socket结构。

accept

应用进程调用accept的时候，就是去检查上面说的已完成的连接队列，如果队列里有连接，就返回这个连接；空的，blocking方试调用，就睡眠等待，nonblocking方式调用，就直接返回，一般一"EWOULDBLOCK“ errno告诉调用者，连接队列是空的。

四次挥手的过程

​ 1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

而四次挥手对应的socket api为：

主要为close(fd),剩下的确认等待等操作会交给内核。

Socket三次握手四次挥手通信模型：

为什么要三次握手

我们要知道网络传输是有延迟的，可能丢失的，不是说A发一个包给B，B保证能立刻收到，甚至B可能一直收不到。

​ 第一次。A跟B说，我要建立连接了。

​ 第二次。B跟A说，OK，那我也建立连接。

​ 第三次。A跟B说，嗯，我知道了。

第二次和第三次都是为了保证连接是可靠的。

​ 假设只有一次握手，而A的包无法发到B那里去，那A就是自顾自的建立了连接，傻傻的发信息，却不知道对方其实根本收不到。所以第二次握手是为了告诉A，B收到了你的信息。假设只有两次握手，那么对B来说，B是不知道A是否收到了自己的信息的，第三次握手是为了告诉B，A收到了B的信息了，并且可以互发信息了。 B真的需要知道 A是否收到了自己发出的第二次握手的信息吗？是的，如果A的第一次握手因为某些原因延迟很久才到B，而其实现在A和B已经聊完天，关闭连接了，这时B发出第二次握手，而A已经没什么想跟B说的，就不会发出第三次握手，这样B就不会建立连接消耗资源。若是只有二次握手的这种情况，B会直接建立连接消耗资源。

为什么要四次挥手

第一次。A跟B说，我要断开连接了。

第二次。B跟A说，好的，我知道了，我不再接收你的信息了。

第三次。B跟A说，我传给你的信息传完了，你可以关闭连接了。

第四次。A跟B说，好的，我关闭连接了。

第二次挥手是为了告诉A，B知道你不再发送信息了，且B不再接收信息。但B仍可以向A发送信息。因为A是主动关闭的一方，但B可能仍然有信息未发送完。第三次挥手是为了告诉A，B的信息发完了，A你可以关闭连接了。
第四次挥手是为了告诉B，A我知道可以关闭连接了，你也可以关闭了。对B来说，第四次挥手B才知道A成功关闭连接了，不关闭很耗费资源，所以要保证关闭了。若B接收不到第四次挥手信息，将会继续第三次挥手，直到收到确认信息为止。注意：对A来说，第四次挥手后2MSL内未接收到B的第三次挥手信息才会关闭连接，否则会继续第四次挥手。防止B接收不到第四次挥手信息。（若B接收不到第四次挥手信息，将重复发送第三次挥手信息，这个2MSL就是如果真的有重复发送的第三次挥手信息，在这个时间内肯定到达A了（路由不出问题的话），就是为了保证B收到第四次挥手信息）。

状态图：

关于一个很出名的状态图附上：

客户端的状态变迁：CLOSED–>SYN_SENT–>ESTABLISHED–>FIN_WAIT_1–>FIN_WAIT_2–>TIME_WAIT–>CLOSED

服务器的状态变迁：CLOSED–>LISTEN–>SYN_RCVD–>ESTABLISHED–>CLOSE_WAIT–>LAST_ACK—>CLOSED

CLOSED：这个状态不是一个真正的状态，是图中假想的一个起点或者是终点

LISTEN: 服务器等待连接过来的状态

SYN_SENT: 客户端发起连接（主动打开），变成此状态，如果SYN超时，或者服务器不存在直接CLOSED

SYN_RCVD:服务器收到SYN包的时候，就变成此状态，

ESTABLISHED：完成三次握手，进入连接建立状态，说明此时可以进行数据传输了

FIN_WAIT_1:客户端执行主动关闭，发送完FIN包之后便进入FIN_WAIT_1状态

FIN_WAIT_2:客户端发送FIN包之后，收到ACK，即进入此状态，其实就是半关闭的状态

TIME_WAIT：这个状态从图上看，有3中情况，从FIN_WAIT_2进入，客户端收到服务器发送过来的FIN包之后进入TIME_WAIT状态，有CLOSING状态进入，这是同时关闭的状态，同时发起FIN请求，同时接收并做了ACK的回复，从FIN_WAIT_1进入，收到对端的FIN,ACK，并回复ACK，这个地方感觉是，FIN和ACK是一块来的.

CLOSE_WAIT:接收到FIN之后，被动的一方进入此状态，并回复ACK

LAST_ACK：被动的一端发送FIN包之后 处于LAST_ACK状态