三次握手过程

用"三次握手"建立TCP连接

• 第一步：客户机的TCP首先向服务器的 TCP 发送一个连接请求报文段。这个特殊的报文段中不含应用层数据，其首部中的 SYN 标志位被置为１．另外，客户机会随机选择一个起始序号 seq=x (连接请求报文不携带数据，但要消耗掉一个序号)。然后客户端进入 SYN-SENT 状态，等待服务器的确认
• 第二步：服务器的 TCP 收到连接请求报文后，如同意建立连接，就向客户机发回确认，并为该 TCP 连接分配 TCP 缓存和变量。在确认报文段中，SYN 和 ACK 位都被置为 1 ，确认号字段的值为 x+1，并且服务器随机产生起始序号 seq=y (确认报文不携带数据，但也要消耗掉一个序号)。确认报文段同样不包含应用层数据。
• 第三步：当客户机收到确认报文段后，还要向服务器给出确认，并且也要给该连接分配缓存和变量。这个报文段的 ACK 标志为被置 1，序号字段为 x+1，确认号字段 ack=y+1。该报文段可以携带数据，如果不携带数据则不消耗序号

为什么 "三次握手" 而不是 "两次握手" 建立连接：

TCP 三次握手缺陷

• 服务器端的资源是在完成第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的。这就使得服务器易受到 SYN 洪泛攻击。
• SYN 洪泛攻击: 通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。
• 防范:
  1、降低SYN timeout时间，使得主机尽快释放半连接的占用
  2、采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。
  3、此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击。

四次挥手过程

用 "四次握手" 释放TCP连接

• 第一步：客户端打算关闭连接，就向其 TCP 发送一个连接释放报文段，并停止再发送数据，主动关闭 TCP 连接，该报文的 FIN 标志位被置为 1，seq=x，它等于前面已传送过的数据的最够一个字节的序号加 1 (FIN 报文段即使不携带数据，也要消耗掉一个序号)。TCP 是全双工的，即可以想象成是一条 TCP 连接上的两条数据通路。当发送 FIN 报文时，发送 FIN 的一端就不能再发送数据，也就是关闭了其中一条数据通路，但对方还可以发送数据
• 第二步：服务器收到连接释放报文段后即发出确认，确认号是 ack=u+1，而这个报文段自己的序号是 v，等于它前面已传送过的数据的最后一个字节的序号加 1。此时，从客户机到服务器这个方向的连接就释放了，TCP 连接处于半关闭状态。但服务器若发送数据，客户机仍要接收，即从服务器到客户机这个方向的连接并未关闭
• 第三步：若服务器已经没有要向客户机发送的数据，就通知 TCP 释放连接，此时其发出 FIN=1 的连接释放报文段
• 第四步：客户机收到连接释放报文段后，必须发出确认。在确认报文段中，ACK 字段被置为 1，确认号 ack=w+1，序号 seq=u+1。此时 TCP 连接还没有释放掉，必须等待时间计时器设置的时间 2MSL 后，A 才进入到连接关闭状态

time-wait 状态，最后一次握手报文后要等待 2MSL(最长报文段寿命) 的时间呢? 参考

• 第一、为了保证 A 发送的最后一个确认报文段能够到达 B 。如果 A 不等待 2MSL，若 A 返回的最后确认报文段丢失，则 B 不能进入正常关闭状态，而 A 此时已经关闭，也不可能再重传。
• 第二、A 在发送完最后一个确认报文段后，再经过 2MSL 可保证本连接持续的时间内所产生的所有报文段从网络中消失。假设没有time-wait 限制，因某些原因我们先关闭这条TCP连接，然后很快又以相同的<源ip,源port,目的ip,目的port> 建立一个新的TCP连接，然后发送数据，设想此时前一个连接在网络中滞留的数据报现在到达接收方，会被当做正常数据接收并上传到应用层，而这些旧数据不应该被接收。从而引起数据错乱而导致各种无法预知诡异错误

time-wait 状态如何避免

• 首先服务器可以设置 SO_REUSEADDR 套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。

TCP 知识框架图

• 特点：有连接、一对一、提供可靠交付、全双工通信、面向字节流
• 首部：20B，源端口、目的端口、序号、确认号等控制信息
• 连接管理：三次握手建立、四次握手释放
• 可靠传输机制
  １、 序号：用来保证数据能有序提交给应用层
  ２、 确认：确认号为期待收到的下一个报文段第一个字节的序号
  ３、 重传：１、超时：计时器到期还没收到确认则重传对应报文。２、冗余确认：当收到失序报文时向发送端发送冗余 ACK。例如发送方A发送了序号1、2、3、4、5的TCP报文段，其中２号报文丢失，3、4、5对于Ｂ来说就是失序报文，当3、4、5到达Ｂ就发送3个对１号报文段的冗余ACK，表明自己期望得到2号报文段，这时Ａ收到三个冗余ACK，立即对２号报文重传
• 流量控制：在确认报文中设置接收窗口 rwnd(接收窗口) 的值来限制发送速率
  在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，这就是接收窗口 rwnd
  流量控制是为了控制发送方发送速率，保证接收方来得及接收。
  接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
  流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
• 拥塞控制：
  • 原理：发送方根据自己估算的网络拥塞程度设置 cwnd(拥塞窗口) 的值来限制发送速率
  • 方法：
    １、慢开始：当 cwnd < ssthresh 时，每收到一个报文段的确认 cwnd 加１
    ２、拥塞避免：当 cwnd > ssthresh 时，每经过一个往返时延 cwnd 加 1
    ３、快重传：当收到连续的三个重复的 ACK，直接重传对方期待的报文
    ４、快恢复： 当收到连续的三个冗余 ACK，令 ssthresh = cwnd = cwnd/2
  • 拥塞处理：ssthresh 置为原 cwnd 的一半，cwnd 置 1
• 开环控制 就是在设计网络时事先将有关拥塞发生的所有因素考虑周到，一旦系统运行起来就不能在中途改正。
• 闭环控制 是基于反馈环路的概念，包括如下措施：
  1）监测网路系统以便检测拥塞在何时何地发生
  2）把拥塞发生的信息传送到可采取行动的地方
  3）调整网络系统的行动以解决出现的问题。

参考

• TCP报文段首部格式详解
• TCP中的Nagle算法
• 通俗大白话来理解TCP协议的三次握手和四次分手
• 图解TCP协议中的三次握手和四次挥手