白话TCP三次握手

了解tcp三次握手之前，我们先了解一下tcp的头部信息。

 

我们说一下TCP报文的头部：

 

 

Source Port和Destination Port分别表示原端口和目的端口，各占两个字节。TCP和UDP的数据包都是不包含IP地址信息的，因为那是IP层的事。但是TCP和UDP都会有原端口和目的端口，就是说端口是属于传输层支持范畴的。我们知道两个进程在计算机内部进行通信，可以由管道、内存共享、信号量、消息队列等方法进行通信，而两个进程需要进行通信最基本的一个前提是进程唯一标识，通过唯一标识找到对应的进程，在本地进程通信中，我们可以使用pid即进程标识符进程号唯一标识一个进程，但pid只在本地唯一，如果把两个进程放在了不同的计算机，它们要进行通信时，pid就不够用了。解决这个问题就需要在传输过程中使用协议端口号。我们知道IP层的ip地址可以唯一标识主机，而TCP协议和端口号可以唯一标识主机中的一个进程。这样我们可以利用ip地址+协议+端口号唯一标识网络中的一个进程。在一些场合，也把这种唯一标识的模式称为套接字socket，也就是说虽然通讯的重点是应用进程，但只要把要传送的报文传送到目的地主机的某一合适的端口，剩下的工作就由TCP来完成了。

Sequence Number序号占用4个字节。TCP连接中，传送的字节流中每个字节都按顺序进行编号的，例如一段报文的序号字段是107，而携带的数据共有100个字节，如果有下一个报文段，其序号就应该由107+100等于207开始。

Acknowledgment Number同样占用4个字节，是期望收到对方下一个报文第一个数据字节的序号，例如B收到了A发送过来的报文，其序列号值是301，而数据长度是200字节，这表明了B正确收到了A发送的500为止数据。因此B期望收到A下一次发送的数据序号是501，于是B在发送给A的确认报文段中会把Ack序号设置为501。

Offset即数据偏移。由于头部有可选字段，长度不固定，偏移量来计算整个TCP报头的长度，偏移量每增加1， 报头长度增加4字节。

Reserved是保留域，目前都会被标为0。

TCP Flags即控制位，由8个标志位组成。每个标志位表示一个控制功能，其中常见的有6个。URG，紧急指针标志，当它值为1时表示紧急指针有效，值为0则忽略紧急指针。ACK，确认序号标志，值为1时表示ack序号有效，值为0时表示报文中不含确认信息，忽略ack序号字段。PSH，push标志，值为1时表示是带有push标志的数据，指示接收方在接收到报文以后尽快交由应用程序处理，而不是在缓冲区排队。值为0时，表示无push标志。RST，重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接，或者用于拒绝非法的报文段或非法的连接请求。SYN，同步序号，用于建立连接过程，在连接请求中，SYN等于1和ACK等于0表示该数据段没有使用捎带的确认域，SYN等于1和ACK等于1表示有捎带确认域。FIN，finish标志，用于释放连接，值为1时表示数据已发送完毕。

Window窗口，指的是滑动窗口的大小，用来告诉发送端，接收端的缓存大小。以此控制发送端发送数据的速率，从而达到流量控制。

Checksum检验和，校验和是对整个的TCP报文段，包括TCP头部和TCP数据，以16位进行计算所得。由发送端计算存储，并由接收端验证。

Urgent Pointer 紧急指针，只有当TCP Flags控制为URG值为1时有效，指出本报文中紧急数据的字节数。

TCP Options 可选项，其长度可变，定义一些其他的可选参数。

当应用程序希望通过TCP与另一个应用程序通讯时，它会发送一个通讯请求，这个请求必须被送到一个确切的地址。在双方握手之后，TCP将在两个应用程序之间建立全双工（Full Duplex）的通讯，这个全双工的通讯将占用两台计算机的通讯线路，直到被一方或双方关闭为止，什么是全双工？计算机A可以给计算机B发送信息，在发送信息的同时，B也能够给A回发信息。而上面握手即TCP的三次握手。

 

tcp三次握手

 

第一次握手：SYN = 1, seq = x

第二次握手：SYN = 1, ACK = 1, seq = y, ack = x + 1

第三次握手：ACK = 1, seq = x + 1, ack = y + 1

我们假设AB首次进行通信，客户端A和客户端B都会处于close的状态，假如主动打开连接的是客服端被动打开连接的是服务端，TCP服务进行会先创建传输控制块，时刻准备接受其他客户端发送的连接请求，此时服务端进入了Listen监听的状态，客户端也是先创建传输控制块，向服务器发出连接请求报文，然后客服端进程进入SYN-SENT同步已发送的状态，此时发送过去的数据包被称为SYN报文段，SYN报文段是不能携带数据的，但是会消耗掉一个序号，这便是第一次握手了。当服务器接收到报文，如果同意连接，则发出确认报文，此时服务器进入SYN-RCVD状态，此报文也是不能携带数据的，同样需要消耗一个序号，这便是第二次握手。客户端收到确认报文之后，还要给服务器一个确认，可携带数据，也可不携带，之后进入ESTB-LISHED已建立连接的状态，这便是第三次握手。

为什么需要三次握手呢？
为了初始化Sequence Number的初始值，通信的双方要互相通知对方自己的初始化的Sequence Number。要作为以后数据通信需要的序号，以保证应用层不会因为网络传输问题而乱序，即tcp会用这个序号来拼接数据。

首次握手的隐患：SYN超时问题分析
服务端收到客户端的SYN，回复SYN-ACK的时候未收到ACK确认，此时连接处于中间状态，即没有成功也没有失败。服务端在一段时间内不断重发SYN-ACK直至超时，Linux默认等待63秒才断开连接，重试5次，每次重试等待时间翻倍。这样，服务器就可能遭受SYN Flood攻击。针对SYN Flood攻击有什么防护措施呢？
Linux下就给出了SYN Cookie的参数，SYN队列满后，通过tcp_syncookies参数回发SYN Cookie，若为正常
连接则Client会回发SYN Cookie，直接简历连接。

建立连接后客户端出现故障怎么办？
TCP设置有保活机制，向对方发送保活探测性报文，如果未收到响应则继续发送。尝试次数达到保活探测数
仍未收到响应则中断连接。