TCP 连接过程问题集

TCP 包头信息

  • 16位端口号：源端口号，主机该报文段是来自哪里；目标端口号，要传给哪个上层协议或应用程序
  • 32位序号：一次TCP通信（从TCP连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编号。
  • 32位确认号：用作对另一方发送的tcp报文段的响应。其值是收到的TCP报文段的序号值加1。
  • 4位头部长度：表示tcp头部有多少个*32bit位（4字节）。因为4位最大能标识15，所以TCP头部最长是60字节。
  • 6位标志位：URG(紧急指针是否有效)，ACk（表示确认号是否有效），PSH（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了）
  • 16位窗口大小：是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。
  • 16位校验和：由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。
  • 16位紧急指针：一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。

TCP 是如何保证可靠性的

  • 首先，TCP的连接是基于三次握手，而断开则是四次挥手。确保连接和断开的可靠性。
  • 其次，TCP的可靠性，还体现在有状态; 

    状态管理可以分为连接状态管理和分组数据状态管理两种，连接状态管理是个典型的状态机，用于双方同步数据发送与接收状态。分组数据状态管理用于保证数据的可靠传输。

  • 再次，TCP的可靠性，还体现在可控制。它有报文校验、ACK应答、超时重传(发送方)、失序数据重传（接收方）、流量控制（滑动窗口）和拥塞控制等

1.TCP的流量控制

流量控制是根据接收端的实际接收能力去控制发送速度，防止分组丢失的。接收端将自己的接收缓冲窗口大小告诉发送端，来控制发送端的发送量。 如果接收窗口为 0，发送端得知这个消息后，会不再发送数据，而只会定时去询问，是否可以继续发送。

2.TCP的拥塞控制

拥塞控制是作用于网络的，防止过多的数据包注入到网络中，避免出现网络负载过大的情况。它的目标主要是最大化利用网络上瓶颈链路的带宽。

拥塞控制主要有这几种常用算法

  • 慢启动
  • 拥塞避免
  • 拥塞发生
  • 快速恢复

发送方维护一个拥塞窗口cwnd，只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，来减少给到网络中的数据包数。

RTT：，一个数据包从发出去到回来的时间，即数据包的一次往返时间。

1.慢启动算法

  • 每当收到一个ACK，cwnd就加一;
  • 每当过了一个RTT，cwnd就增加一倍; 呈指数让升

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢启动阀值ssthresh（slow start threshold）状态变量。当cwnd到达该阀值后，进入拥塞避免状态。

2.拥塞避免算法

  • 每收到一个ACK时，cwnd = cwnd + 1/cwnd
  • 当每过一个RTT时，cwnd = cwnd + 1

显然这是一个线性上升的算法，避免过快导致网络拥塞问题。

3.拥塞发生

当网络拥塞发生丢包时，会有两种情况：

  • RTO超时重传
  • 快速重传

如果是发生了RTO超时重传，就会使用拥塞发生算法

  • 慢启动阀值sshthresh = cwnd /2
  • cwnd 重置为 1
  • 进入新的慢启动过程

其实还有更好的处理方式，就是快速重传。发送方收到3个连续重复的ACK时，就会快速地重传，不必等待RTO超时再重传。

4.快速恢复

快速重传和快速恢复算法一般同时使用。快速恢复算法认为，还有3个重复ACK收到，说明网络也没那么糟糕，所以没有必要像RTO超时那么强烈。真正的快速算法如下：

  • cwnd = sshthresh + 3
  • 重传重复的那几个ACK（即丢失的那几个数据包）
  • 如果再收到重复的 ACK，那么 cwnd = cwnd +1
  • 如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK，表明恢复过程已经结束，可以再次进入了拥塞避免的算法了。

TCP的三次握手和四次分手

​ 我们知道TCP建立连接需要经过三次握手，而断开连接需要经过四次分手，那三次握手和四次分手分别做了什么和如何进行的。

三次握手

  1. 客户端通过 connect 发起主动，向服务器发出连接请求，请求中首部同步位 SYN = 1，同时选择一个初始序号 sequence ，简写 seq = x。SYN 报文段不允许携带数据，只消耗一个序号。此时，客户端进入 SYN-SEND 状态。
  2. 服务器收到客户端连接后，需要回复确认客户端的报文段。在确认报文段中，把 SYN 和 ACK 位都置为 1 。确认号 ack = x + 1，同时也为自己选择一个初始序号 seq = y。这个报文段也不能携带数据，但同样要消耗掉一个序号。此时，TCP 服务器进入 SYN-RECEIVED(同步收到) 状态。
  3. 客户端在收到服务器发出的响应后，还需要给出确认连接。确认连接中的 ACK 置为 1 ，序号为 seq = x + 1，确认号为 ack = y + 1。TCP 规定，这个报文段可以携带数据也可以不携带数据，如果不携带数据，那么下一个数据报文段的序号仍是 seq = x + 1。这时，客户端进入 ESTABLISHED (已连接) 状态

为什么一定要三次，两次行不行

不行。 三次是为了达成网络通信中的绝对闭合环路。 发出去，并且收到了回包。发送端可以知道自己可以和对面建立连接，并且自身的发送和接收能力都是 ok 的。 所以一定要有第三次，来让服务端确认，自身的发送能力是 ok 的。

四次挥手

  1. 客户端停止发送数据，主动关闭 TCP 连接。发送 FIN 位，置为 1 ，不包含数据，假设此时序列号位 seq = u，此时客户端主机进入 FIN-WAIT-1(终止等待 1) 阶段。这表示主机没有数据要发送给服务端了；

  2. 服务器主机接受到客户端发出的报文段后，即发出确认应答报文，确认应答报文中 ACK = 1，生成自己的序号位 seq = v，ack = u + 1，然后服务器主机就进入 CLOSE-WAIT(关闭等待) 状态。客户端主机收到服务端主机的确认应答后，即进入 FIN-WAIT-2(终止等待2) 的状态。等待客户端发出连接释放的报文段。

  3. 服务端主机会发出断开连接的报文段，报文段中 ACK = 1，序列号 seq = v，ack = u + 1，在发送完断开请求的报文后，服务端主机就进入了 LAST-ACK(最后确认)的阶段。

  4. 客户端收到服务端的断开连接请求后，客户端需要作出响应，客户端发出断开连接的报文段，在报文段中，ACK = 1, 序列号 seq = u + 1，因为客户端从连接开始断开后就没有再发送数据，ack = v + 1，然后进入到 TIME-WAIT(时间等待) 状态，请注意，这个时候 TCP 连接还没有释放。必须经过时间等待的设置，也就是 2MSL 后，客户端才会进入 CLOSED 状态，时间 MSL 叫做最长报文段寿命（Maximum Segment Lifetime）。

  5. 服务端主要收到了客户端的断开连接确认后，就会进入 CLOSED 状态。

1.为什么关闭连接是四次挥手呢

关闭连接时，当收到对方的 FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据。所以客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

TCP 连接的任意一方都可以发起关闭操作，只不过通常情况下发起关闭连接操作一般都是客户端。然而，一些服务器比如 Web 服务器在对请求作出相应后也会发起关闭连接的操作。TCP 协议规定通过发送一个 FIN 报文来发起关闭操作。

2. 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

  • 1个 MSL 保证四次挥手中主动关闭方最后的 ACK 报文能最终到达对端
  • 1个 MSL 保证对端没有收到 ACK 那么进行重传的 FIN 报文能够到达
  • 同时可以让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

3．TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态会产生什么问题

通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态，TIME_WAIT状态维持时间是两个MSL时间长度，也就是在1-4分钟，Windows操作系统就是4分钟。进入TIME_WAIT状态的一般情况下是客户端，一个TIME_WAIT状态的连接就占用了一个本地端口。一台机器上端口号数量的上限是65536个，如果在同一台机器上进行压力测试模拟上万的客户请求，并且循环与服务端进行短连接通信，那么这台机器将产生4000个左右的TIME_WAIT Socket，后续的短连接就会产生异常，如果使用Nginx作为方向代理也需要考虑TIME_WAIT状态，发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决。

解决方法：允许将TIME-WAIT sockets 快速回收，重新用于新的TCP连接。  甚至也可以修改这个时间，减少timeout时间

4．半连接队列和 SYN Flood 攻击的关系

  • TCP三次握手时，客户端发送SYN到服务端，服务端收到之后，便回复ACK和SYN，状态由LISTEN变为SYN_RCVD，此时这个连接就被推入了SYN队列，即半连接队列。
  • 当客户端回复ACK, 服务端接收后，三次握手就完成了。这时连接会等待被具体的应用取走，在被取走之前，它被推入ACCEPT队列，即全连接队列。

SYN Flood是一种典型的DoS (Denial of Service，拒绝服务) 攻击，它在短时间内，伪造不存在的IP地址,向服务器大量发起SYN报文。当服务器回复SYN+ACK报文后，不会收到ACK回应报文，导致服务器上建立大量的半连接半连接队列满了，这就无法处理正常的TCP请求啦。

主要有 syn cookie和SYN Proxy防火墙等方案应对。

  • syn cookie：在收到SYN包后，服务器根据一定的方法，以数据包的源地址、端口等信息为参数计算出一个cookie值作为自己的SYN ACK包的序列号，回复SYN+ACK后，服务器并不立即分配资源进行处理，等收到发送方的ACK包后，重新根据数据包的源地址、端口计算该包中的确认序列号是否正确，如果正确则建立连接，否则丢弃该包。

  • SYN Proxy防火墙：服务器防火墙会对收到的每一个SYN报文进行代理和回应，并保持半连接。等发送方将ACK包返回后，再重新构造SYN包发到服务器，建立真正的TCP连接。

其他类型的打开和关闭

TCP 半开启

TCP 连接处于半开启的这种状态是因为连接的一方关闭或者终止了这个 TCP 连接却没有通知另一方。此时就认为这条连接处于半开启状态。这种情况发生在通信中的一方处于主机崩溃的情况下，只要处于半连接状态的一方不传输数据的话，那么是无法检测出来对方主机已经下线的。

另外一种处于半开启状态的原因是通信的一方关闭了主机电源 而不是正常关机。这种情况下会导致服务器上有很多半开启的 TCP 连接。

TCP 半关闭

既然 TCP 支持半开启操作，那么我们可以设想 TCP 也支持半关闭操作。同样的，TCP 半关闭也并不常见。TCP 的半关闭操作是指仅仅关闭数据流的一个传输方向。两个半关闭操作合在一起就能够关闭整个连接。在一般情况下，通信双方会通过应用程序互相发送 FIN 报文段来结束连接，但是在 TCP 半关闭的情况下，客户端发起了 FIN 报文，要求主动断开连接，服务器收到 FIN 后，回应 ACK ，由于此时发起半关闭的一方也就是客户端仍然希望服务器发送数据，所以服务器会继续发送数据，一段时间后服务器发送另外一条 FIN 报文，在客户端收到 FIN 报文回应 ACK 给服务器后，断开连接。

同时打开和同时关闭

还有一种比较非常规的操作，这就是两个应用程序同时主动打开连接。虽然这种情况看起来不太可能，但是在特定的安排下却是有可能发生的。我们主要讲述这个过程。

同时打开： 

通信双方都在收到对方报文前主动发送了 SYN 报文，都在收到彼此的报文后回复了一个 ACK 报文。

一个同时打开过程需要交换四个报文段，比普通的三次握手增加了一个，由于同时打开没有客户端和服务器一说，所以这里我用了通信双方来称呼。

同时关闭

同时关闭过程中需要交换和正常关闭相同数量的报文段，只不过同时关闭不像四次挥手那样顺序进行，而是交叉进行的。

 

初始序列号

也许是我上面图示或者文字描述的不专业，初始序列号它是有专业术语表示的，初始序列号的英文名称是Initial sequence numbers (ISN)，所以我们上面表示的 seq = v，其实就表示的 ISN。

在发送 SYN 之前，通信双方会选择一个初始序列号。初始序列号是随机生成的，每一个 TCP 连接都会有一个不同的初始序列号。RFC 文档指出初始序列号是一个 32 位的计数器，每 4 us（微秒） + 1。因为每个 TCP 连接都是一个不同的实例，这么安排的目的就是为了防止出现序列号重叠的情况。

当一个 TCP 连接建立的过程中，只有正确的 TCP 四元组和正确的序列号才会被对方接收。这也反应了 TCP 报文段容易被伪造 的脆弱性，因为只要我伪造了一个相同的四元组和初始序列号就能够伪造 TCP 连接，从而打断 TCP 的正常连接，所以抵御这种攻击的一种方式就是使用初始序列号，另外一种方法就是加密序列号。

Nagle 算法与延迟确认

Nagle算法

如果发送端疯狂地向接收端发送很小的包，比如就1个字节，那么会有什么问题呢？

TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。

Nagle算法的基本定义是：任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。

Nagle算法的实现规则：

  • 如果包长度达到MSS，则允许发送；
  • 如果该包含有FIN，则允许发送；
  • 设置了TCP_NODELAY选项，则允许发送；
  • 未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
  • 上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

延迟确认

如果接受方刚接收到发送方的数据包，在很短很短的时间内，又接收到第二个包。那么请问接收方是一个一个地回复好点，还是合并一起回复好呢？

接收方收到数据包后，如果暂时没有数据要发给对端，它可以等一段时再确认（Linux上默认是40ms）。如果这段时间刚好有数据要传给对端，ACK就随着数据传输，而不需要单独发送一次ACK。如果超过时间还没有数据要发送，也发送ACK，避免对端以为丢包。

但是有些场景不能延迟确认，比如发现了乱序包、接收到了大于一个 frame 的报文，且需要调整窗口大小等。

一般情况下，Nagle算法和延迟确认不能一起使用，Nagle算法意味着延迟发，延迟确认意味着延迟接收，酱紫就会造成更大的延迟，会产生性能问题。

15. TCP的粘包和拆包

TCP是面向流，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分和发送。 所以一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

为什么会产生粘包和拆包呢?

  • 要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包；
  • 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包；
  • 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包；
  • 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。

解决方案：

  • 发送端将每个数据包封装为固定长度
  • 在数据尾部增加特殊字符进行分割
  • 将数据分为两部分，一部分是头部，一部分是内容体；其中头部结构大小固定，且有一个字段声明内容体的大小。
posted @ 2021-12-17 14:41  Clovran-Wong  阅读(179)  评论(0)  编辑  收藏  举报