TCP 三次握手（TCP Three-way Handshake）

TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

第一次握手 - 建立连接

客户端发送连接请求报文段，将Control Flag中的SYN位置为1，Sequence Number（发送序号）为x；然后，客户端进入 SYN_SENT 状态，等待服务器的确认。

SYN报文段是指，Control Flag中的SYN位为1的TCP报文段。

第二次握手 - 服务器收到SYN报文段

服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置 Acknowledgment Number（确认序号）为x+1（即Sequence Number+1）；同时，自己还要发送SYN请求信息（即将 SYN 位为1），Sequence Number（发送序号）为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入 SYN_RECV 状态。

类似地，ACK报文段是指Control Flag中的ACK位为1的TCP报文段。而SYN+ACK报文段是指Control Flag中的SYN位和ACK位均为1的TCP报文段。

第三次握手 - 客户端收到服务器的SYN+ACK报文段

客户端收到服务器发送的SYN+ACK报文段后，将Acknowledgment Number（确认序号）设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端进入 ESTABLISHED 状态。当服务器端接收到这个ACK报文段后，服务器端进入 ESTABLISHED 状态，完成TCP三次握手。

而如果，客户端向服务器发送ACK报文段没有达到服务器端（或者延迟了），服务器会重新发送一个第二次握手阶段中的SYN+ACK报文段。

SYN攻击

在三次握手过程中，Server发送SYN+ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于 SYN_RCVD 状态**，当收到ACK后，Server转入 ESTABLISHED 状态**。

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。

SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

netstat -nap | grep SYN_RECV

如何防御 SYN 攻击？

SYN攻击不能完全被阻止，除非将TCP协议重新设计。我们所做的是尽可能的减轻SYN攻击的危害，常见的防御 SYN 攻击的方法有如下几种：

缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护
SYN cookies技术

三次握手时可能发生的丢包问题

TCP规定：对有数据的TCP segment 在接收方收到数据后，必须向发送方发送一个ACK数据包以表示确认。

以主机A尝试与B进行连接为例，我们来分别讨论一下，在进行三次握手时，不同握手阶段的握手数据包丢失时的情况。

第一次握手时丢包

第一个包，即 Client 发给 Server 的SYN 数据报丢包了，没有到达B。此后，Client 会周期性超时重传，直到收到 Server 的确认（ACK+SYN数据报）。

第二次握手时丢包

**第二个包，即 Server 发给 Client 的SYN +ACK 数据报丢包了，没有到达 Client **。此后， Server 会周期性超时重传，直到收到 Client 的确认（ACK数据报）。

这就需要一个超时时间让 Server 将这个连接断开，否则这个连接就会一直占用 Client 的SYN连接队列中的一个位置，大量这样的连接就会将 Server 的SYN连接队列耗尽，让正常的连接无法得到处理。

目前，Linux下默认会进行5次重发SYN-ACK包，重试的间隔时间从1s开始，下次的重试间隔时间是前一次的双倍，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了.所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP才会把断开这个连接。

由于，SYN超时需要63秒，那么就给攻击者一个攻击服务器的机会，攻击者在短时间内发送大量的SYN包给Server(俗称 SYN flood 攻击)，用于耗尽Server的SYN队列。对于应对SYN 过多的问题，linux提供了几个TCP参数：tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 来调整应对。

第三次握手时丢包

第三个包，即 Client 发给 Server的ACK 数据报丢包了，没有到达 Server。

Client 发完ACK，单方面认为TCP为 ESTABLISHED状态，而 Server 显然认为TCP 仅处于 SYN_SENT 状态。

因此，具体存在以下三种情况：

假定在此后一段时间双方都没有数据发送，Server 会周期性超时重传，直到收到 Client 的确认。且收到之后，Server的TCP 连接也为 ESTABLISHED 状态，因而可以双向发包。
假定此时 Client 有数据发送，Server 收到 Client 的 Data + ACK后，自然会切换为ESTABLISHED 状态，并接受 Client 的Data。
假定 Server有数据发送，但是因为数据发送不了（由于 Server 未接收到 Client 发来的ACK数据报），因此会一直会周期性超时重传SYN + ACK，直到收到 Client的确认后，才可以发送数据。

Why Three

三次握手是相对于两次握手而言的。

两次握手是指，当客户端期望与服务端建立连接时，客户端向服务端发送一个SYN报文段，服务端收到后，向客户端发送一个ACK报文段。当客户端收到后，双方都会认为这个连接建立成功了。

不采用两次握手，而使用三次握手，来作为连接建立完成的标志，是为了避免已失效的客户端连接请求报文段（因为网络延迟问题）突然又传送到了服务端，因而建立了一个不被期望的客户端-服务端连接的情况。

已失效的连接请求报文段

“已失效的连接请求报文段”的产生在这样一种情况：客户端发出的第一个连接请求报文段（SYN报文段）并没有丢包（丢包是指，因为某些原因被中途经过的某个网络节点将这个包丢弃了），而是在某个网络结点长时间地滞留了，以至于延误（delay）到连接释放以后的某个时间点才到达服务端。

本来这是一个早已失效的报文段，对于客户端而言，也不希望再次建立与服务端的连接了。

但服务端收到此过时的连接请求报文段后，就误认为是客户端再次发出的一个新的连接请求。于是就向客户端发出确认报文段（ACK报文段），同意建立连接。假设不采用“三次握手”，而采用两次握手，那么这时，只要服务端发出确认报文段（ACK报文段）后，服务端就会认为新的连接已经建立完成了。

而事实上，这个建立完成的连接，并不是被客户端期望的，因此客户端不会利用这个连接，因而也不会向服务端通过这个连接来发送任何数据。

前面也提到了，由于服务端认为新的连接已经建立完成了，因而会一直苦苦地等待数据，最终服务端的资源就白白浪费掉了。

采用三次握手后：

而采用三次握手后，被延误的连接请求报文段（SYN报文段）到达了服务端后，服务端因无法判断这个报文段是正常的请求还是被延误的请求，因而自然会向客户端发出确认报文段（SYN+ACK报文段）。

然而，对于客户端而言，它能够判断这个连接请求报文段（SYN报文段）是自己之前发送的，但是因为被延误（delay）了，因此自然没有意义，所以不会向服务端发送对应的ACK报文段。

服务端通过依赖一个超时计时机制，由于在较短时间后没有得到客户端发送的ACK报文段，因而就知道客户端并没有真正要求建立连接，最终不会认为这个连接建立完成了。

因此，三次握手避免了在这种场景下，服务端的资源被白白浪费掉的情况。

换一个角度的分析

这个问题的本质是，通信信道不可靠，但是通信双方仍然需要就某个问题达成一致。

而要解决这个问题，无论你在消息中包含什么信息，三次通信是理论上的最小值。所以三次握手不是TCP本身的要求，而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的。

请注意这里的本质需求，信道不可靠，数据传输要可靠。三次达到了，那后面你想接着握手也好，发数据也好，跟进行可靠信息传输的需求就没关系了。因此，如果信道是可靠的，即无论什么时候发出消息，对方一定能收到，或者你不关心是否要保证对方收到你的消息，那就能像UDP那样直接发送消息就可以了。

【Network】TCP 三次握手（TCP Three-way Handshake）