TCP三次握手

TCP建立连接

TCP三次握手过程和状态迁移

TCP是面向连接的协议，所以使用TCP前必须先建立连接，而建立连接是通过三次握手而进行的。

• 一开始，客户端和服务器都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
• 客户端会随机初始化序号（x），将此序号置于 TCP 首部的 [序号] 字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN_SENT 状态。
• 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（y），将此序号填入 TCP 首部的 [序号] 字段中，其次把 TCP 首部中的确认号字段填入 x + 1。接着把 SYN 和 ACK 标志为置为1。最后把该报文发送给客户端，该报文也不包含应用层数据，之后服务端处于 SYN_RCVD 状态。
• 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1，其次确认号字段填入 y + 1，最后把报文发送给服务端，这次报文可以携带数据，之后客户端处于 ESTABLISHED 状态。
• 服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。此时连接建立完成，客户端和服务器可以相互发送数据了。

从上面的过程可以看出，第三次握手可以携带数据，前两次握手不可以携带数据。

使用wireshark进行抓包，下图是三次握手的数据包：

对第一个数据包进行分析：

TCP：表明是个TCP协议

51936 -> 80:表明是从源地址的51936端口发送给目的地址的80端口

[SYN]表明这是一个TCP的同步请求，是TCP握手的第一步

Seq=0: TCP头部中的字段 [序号]，这里为0.

在TCP中第一个SYN 包所包含的 sequence 是随机的，而第一个 SYN+ACK包里的sequence 也是随机的，wireshark 为了便于观察都使用相对值，初始化这两个随机值为0，后面的sequence 和 acknowledge 都在上面累加

Win=64240: 发送报文段一方的接收窗口。TCP协议中的字段

Len=0: 发送文件TCP报文段Datas段的长度

MSS=1460: 最大报文段长度，指每个TCP报文段中数据字段的最大长度。它不包含首部长度。是TCP首部中，选项中的字段。

WS=256：窗口扩大因子，选项中的字段，应对窗口值不够用。 。只能在连接建立阶段确定，在连接期间他的值不能够改变，新的窗口值=首部中定义的窗口值乘以2的（窗口扩大因子）的次方。窗口扩大选项占3个字节，其中一个字节表示移位值S，S最大为14，新的窗口值等于TCP首部中的窗口位数从16增大到（16+S）。这里的256是指窗口扩大了256倍，其S=8, 2的8次方 = 256。

SACK_PERM=1: 允许选择确认。 TCP选项中的字段。

如何在 Linux 系统中查看 TCP 状态？

TCP的连接状态，在 Linux 中通过命令 netstat -napt查看

为什么是三次握手？不是两次、四次？

从三个方面分析三次握手的原因：

• 三次握手才可以阻止历史重复连接的初始化（主要原因）
• 三次握手才可以同步双方的初始序列号
• 三次握手才可以避免资源浪费

1.避免历史连接

三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

客户端连续发送多次 SYN 建立连接的报文，在网络拥堵等情况下：

• 一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；
• 那么此时服务端就会回一个 SYN + ACK 报文给客户端；
• 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。

如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：

• 如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；
• 如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接；
  所以， TCP 使用三次握手建立连接的最主要原因是防止历史连接初始化了连接。

2.同步双方初始序列号

TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：

• 接收方可以去除重复的数据；
• 接收方可以根据数据包的序列号按序接收；
• 可以标识发送出去的数据包中， 哪些是已经被对方收到的；

可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
四次握手其实也能够可靠的同步双方的初始化序号，但由于服务端给客户端发送的 SYN 报文和 ACK 报文两步操作可以优化成一步，所以就成了「三次握手」。而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。

3.避免浪费资源

如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？

如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

即两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求 SYN 报文，而造成重复分配资源。

小结：

TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。

不使用「两次握手」和「四次握手」的原因：

• 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
• 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

为什么客户端和服务端的初始序列号 ISN 是不相同的？

因为网络中的报文会延迟、会复制重发、也有可能丢失，这样会造成的不同连接之间产生互相影响，所以为了避免互相影响，客户端和服务端的初始序列号是随机且不同的。

初始序列号 ISN 是如何随机产生的？

起始 ISN 是基于时钟的，每 4 毫秒 + 1，转一圈要 4.55 个小时。

RFC1948 中提出了一个较好的初始化序列号 ISN 随机生成算法。

ISN = M + F (localhost, localport, remotehost, remoteport)

M 是一个计时器，这个计时器每隔 4 毫秒加 1。
F 是一个 Hash 算法，根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出，用 MD5 算法是一个比较好的选择。

既然 IP 层会分片，为什么 TCP 层还需要 MSS 呢？

我们先来认识下 MTU 和 MSS

• MTU：一个网络包的最大长度，以太网中一般为 1500 字节；
• MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度；

如果TCP 的整个报文（头部 + 数据）交给 IP 层进行分片，会有什么异常呢？

当 IP 层有一个超过 MTU 大小的数据（TCP 头部 + TCP 数据）要发送，那么 IP 层就要进行分片，把数据分片成若干片，保证每一个分片都小于 MTU。把一份 IP 数据报进行分片以后，由目标主机的 IP 层来进行重新组装后，在交给上一层 TCP 传输层。

这看起来井然有序，但这存在隐患的，那么当如果一个 IP 分片丢失，整个 IP 报文的所有分片都得重传。

因为 IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。

当接收方发现 TCP 报文（头部 + 数据）的某一片丢失后，则不会响应 ACK 给对方，那么发送方的 TCP 在超时后，就会重发「整个 TCP 报文（头部 + 数据）」。

因此，可以得知由 IP 层进行分片传输，是非常没有效率的。

所以，为了达到最佳的传输效能 TCP 协议在建立连接的时候通常要协商双方的 MSS 值，当 TCP 层发现数据超过 MSS 时，则就先会进行分片，当然由它形成的 IP 包的长度也就不会大于 MTU ，自然也就不用 IP 分片了。

经过 TCP 层分片后，如果一个 TCP 分片丢失后，进行重发时也是以 MSS 为单位，而不用重传所有的分片，大大增加了重传的效率。

什么是 SYN 攻击？如何避免 SYN 攻击？

1.SYN 攻击

我们都知道 TCP 连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常用户服务。

2.避免 SYN 攻击 方式一

其中一种解决方式是通过修改 Linux 内核参数，控制队列大小和当队列满时应做什么处理。

• 当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数：
  net.core.netdev_max_backlog
• SYN_RCVD 状态连接的最大个数：
  net.ipv4.tcp_max_syn_backlog
• 超出处理能时，对新的 SYN 直接回 RST，丢弃连接：
  net.ipv4.tcp_abort_on_overflow

避免 SYN 攻击 方式二

我们先来看下Linux 内核的 SYN （未完成连接建立）队列与 Accpet （已完成连接建立）队列是如何工作的？

正常流程：

• 当服务端接收到客户端的 SYN 报文时，会将其加入到内核的「 SYN 队列」；
• 接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报文；
• 服务端接收到 ACK 报文后，从「 SYN 队列」移除放入到「 Accept 队列」；
• 应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。

应用程序过慢：

• 如果应用程序过慢时，就会导致「 Accept 队列」被占满。

受到 SYN 攻击：

• 如果不断受到 SYN 攻击，就会导致「 SYN 队列」被占满。
  tcp_syncookies 的方式可以应对 SYN 攻击的方法：
  net.ipv4.tcp_syncookies = 1

• 当 「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」；
• 计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端，
• 服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性。如果合法，直接放入到「 Accept 队列」。
• 最后应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。