【Linux】TCP协议【中】{确认应答机制/超时重传机制/连接管理机制}

1.确认应答机制

TCP协议中的确认应答机制是确保数据可靠传输的关键部分。以下是该机制的主要步骤和特点的详细解释：

数据分段与发送：
发送方将要发送的数据分成一个个数据段（或称为TCP报文段）进行发送。
接收方确认：
接收方在成功收到数据段后，会向发送方发送一个确认（ACK）报文。这个ACK报文包含了确认序号，通常是接收到的数据段的下一个字节的序列号，表示接收方已经成功接收到了该序列号之前的数据。
发送方继续发送：
发送方在收到接收方的ACK确认后，会继续发送下一个数据段。
超时重传：
如果发送方在发送数据段后的一定时间内（称为超时时间，RTO）没有收到接收方的ACK确认，它会认为该数据段可能丢失或出错，并会重新发送该数据段。这个时间是根据往返时间（RTT）和网络条件来动态调整的。
重复确认：
如果接收方检测到有数据段重复（即接收到了先前已确认的数据），它会向发送方发送一个重复确认（Duplicate ACK）。这有助于发送方更快地识别出数据丢失，并触发快速重传。
快速重传：
当发送方收到连续的3个或更多的重复ACK时，它会认为有数据段丢失，并立即重新发送该数据段，而不是等待超时时间到达。这有助于减少传输延迟并提高网络效率。
拥塞控制：
如果发送方的数据段在一段时间内未收到确认（即发生了超时），发送方会认为网络发生了拥塞，并会减慢发送速率，以减轻网络负载。这通常是通过调整拥塞窗口大小来实现的。
序列号与确认号：
TCP协议使用32位的序列号和确认号来对数据进行编号和确认。这有助于发送方和接收方精确地跟踪数据传输的进度，并确保数据的完整性和顺序性。
通过这些机制，TCP协议能够确保数据的可靠传输，即使在复杂的网络环境中也能保持较高的传输效率和准确性。

2.超时重传机制：超时不一定是真超时了

TCP协议中的超时重传机制是确保数据可靠传输的关键部分之一。当TCP发送一个数据段（或称为报文段）后，它会等待接收方的确认应答（ACK）。如果在规定的时间内没有收到确认应答，发送方会认为该数据段已经丢失或者出现了错误，并会启动超时重传机制。

以下是超时重传机制的基本步骤：

设置定时器：
当TCP发送一个数据段后，它会为该数据段设置一个定时器（或称为重传定时器）。这个定时器的超时时间（RTO, Retransmission TimeOut）是根据网络条件动态计算的，通常基于之前的往返时间（RTT, Round-Trip Time）的样本值进行估计。
等待确认：
发送方在发送数据段后会等待接收方的确认应答（ACK）。确认应答中包含了一个确认序号，表示接收方已经成功接收到了该序号之前（不包括该序号）的所有数据。
检查超时：
如果在定时器超时之前收到了确认应答，发送方会停止该定时器并继续发送后续的数据段。
如果在定时器超时之前没有收到确认应答，发送方会认定该数据段已经丢失或出错，并会重传该数据段。
重传数据段：
当发送方决定重传数据段时，它会再次发送该数据段，并重置相应的定时器。
调整超时时间：
TCP使用一种称为指数退避（Exponential Backoff）的算法来动态调整RTO值。每次发生超时重传时，RTO值会按照指数增长，以应对网络条件的变化。这种调整有助于避免在网络拥塞时频繁地发送无用的重传数据。
快速重传：
除了基于定时器的超时重传外，TCP还使用了一种称为快速重传的机制。当接收方检测到有数据段丢失时（通过收到重复的ACK），它会立即向发送方发送重复ACK。如果发送方收到足够多的重复ACK（通常是3个或更多），它会认为有数据段丢失，并会立即重传该数据段，而不需要等待定时器超时。
通过超时重传和快速重传机制，TCP能够确保在网络出现丢包或错误时，数据仍然能够可靠地传输到接收方。这些机制是TCP协议中可靠性保证的重要组成部分。
参考优质博文
发送方发生了一个数据没有收到ack，他不知道这个数据：丢包？在网络中未到达？有应答但是应答丢了？

丢包或 数据包/应答 因速度原因在网络里传输很慢

应答丢了：发送重复数据 – 重复数据是不可靠的一种情况 --需要去重 – 通过序号！

如何确定超时？

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
但是这个时间的长短, 随着网络环境的不同, 是有差异的.
如果超时时间设的太长, 会影响整体的重传效率;
如果超时时间设的太短, 有可能会频繁发送重复的包;

如何设置？

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.
Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传.
如果仍然得不到应答, 等待 4500ms 进行重传. 依次类推, 以指数形式递增.
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

3.连接管理机制

连接管理机制，特别是在TCP协议中，是确保数据在客户端和服务器之间可靠传输的关键过程。以下是TCP连接管理机制的主要步骤和特点的详细解释：

三次握手建立连接：
第一次握手：客户端发送一个SYN（同步）报文段到服务器，请求建立连接。客户端进入SYN_SENT状态。
第二次握手：服务器收到SYN报文段后，如果同意建立连接，则回复一个SYN+ACK（同步/确认）报文段，表示接受请求。服务器进入SYN_RECV状态。
第三次握手：客户端收到服务器的SYN+ACK报文段后，发送一个ACK（确认）报文段给服务器，表示连接已经建立。客户端进入ESTABLISHED状态，服务器也进入ESTABLISHED状态，此时连接正式建立。
这个过程就像是两个人在建立关系，互相确认对方的意图和意愿。
状态转换：
客户端状态转换：从CLOSED（关闭）到SYN_SENT，再到ESTABLISHED，以及后续的FIN_WAIT1、FIN_WAIT2、TIME_WAIT，最后回到CLOSED。
服务器状态转换：从CLOSED（关闭）到LISTEN（监听），再到SYN_RECV，然后进入ESTABLISHED，以及后续的CLOSE_WAIT、LAST_ACK，最后回到CLOSED。
四次挥手断开连接：
客户端或服务器中的一方（假设为客户端）首先发起断开连接的请求，发送一个FIN（结束）报文段。
另一方（服务器）收到FIN报文段后，回复一个ACK报文段，表示收到断开连接的请求。
随后，服务器也发送一个FIN报文段给客户端，表示自己也准备断开连接。
客户端收到服务器的FIN报文段后，回复一个ACK报文段，表示连接已经关闭。
这个过程就像是两个人在结束关系，互相确认并道别。
超时重传：如果在规定的时间内没有收到对方的确认报文段（ACK），发送方会启动超时重传机制，重新发送之前的报文段。这是为了确保在网络不稳定或丢包的情况下，数据仍然能够可靠地传输。
连接管理机制的作用：连接管理机制是TCP保证可靠性的一个核心机制。通过三次握手建立连接和四次挥手断开连接，TCP能够在客户端和服务器之间建立一个可靠的、全双工的、面向连接的通信管道。同时，通过状态转换和超时重传机制，TCP能够确保数据在传输过程中的完整性和准确性。

1. 客户端connect发起连接请求，客户端tcp会发一个带有syn的报文，收到ack后一旦客户端发起ack connect返回。accpet只会把建立好的连接拿上来用。即应用层的接口只会开始和结束某一动作，动作怎么完成的不关心，有OS完成。即他们并不关心三次握手的具体过程，只把握手前和后的结果拿来用。
2. tcp通信是基于连接的，需要建立和断开连接 — 三次握手四次挥手

为什么要进行三次握手四次挥手？

1. 实际上三次还是四次并不重要，三次握手也可以是四次握手，只不过捎带应答让握手次数三次就可以；挥手三次也可以，稍带应答即可。即进行握手挥手的主要目的是通过双方分别一个发送一个响应来保证我们要开始建立或结束连接的可靠性！
2. 为什么大多数情况下握手压缩成三次，挥手不压缩？握手时，客户端发来连接请求，服务端都是无条件答应即服务端一定会发送ack和syn，所以这里压缩。而挥手时，即便服务端发了ack，也不一定就会给客户端说我们断开连接吧，所以如果挥手想要变成三次，需要一种场景：服务端一定会断开链接。
3. 另外，三次握手可以验证全双工是否通畅：三次握手使得cs双方至少都经历了一次发收。即三次握手的目的是保证双方都能进行收发 — 可靠的验证全双工。
4. 三次握手确保一般情况下握手失败的管理连接成本让客户端承担：首先达成共识：这里我们讲握手挥手并没讲这样安不安全而是在讲逻辑上这样能不能为通信建立前提，至于安全问题这里暂且不讨论，只考虑逻辑正确性。一次握手：c向s只发起一次syn，这是服务端和客户端都认为建立好连接了，于是服务端会创建连接结构体对象，如果客户端恶意发起很多个syn，那么服务端就会建立很多连接 ---- 成本增加且没用 — 浪费资源降低效率；二次握手：c发syn到s，s发ack给c，s一经发出ack就认为握手成功，那么s就会创建连接结构体对象，同样的，c恶意发起多个syn或发起syn后崩掉，服务端都会建立原来的连接对象，只有在很久之后没有收到消息认为客户端关闭后才会关闭连接 — 成本/资源/效率问题；三次握手：c在收到ack后就建立连接，而s只有在收到第三次ack才会建立连接，所以即便第三次ack丢失，s不会建立连接。而c会===》把成本压在客户端而非服务端上了。— 从设计减少服务端的成本。
5. 是不是次数越多越好？不！且不说浪费资源，三次已经可以了没必要。其次，次数越多带来试错次数多也同样带来犯错的次数多==》本来建立好了，但有一次ack丢了认为建立好的连接是不成功的连接。其次，一般都是奇数次的握手，这样使得发起连接请求的一方在第一次和最后一次都是它，使得即便最后一次丢失了成本在它不在客户端。（x是奇数，前x-1次都是可靠的因为都有ack只有最后一次没有ack也就不知道对方是否收到）
6. 三次握手也有可能受syn洪水攻击，具体见下面syn洪水介绍。黑客用肉机某一时间段统一向某服务端发起连接请求消耗服务端半连接资源。这属于安全范畴。我们上面谈的是功能逻辑范畴。
7. 为什么四次挥手？保证双方都能得知对方不再发送数据的意愿。一个fin–我不想跟你发送数据了但是我还可以收数据，也可以发报头即回应服务端分的ack；一个ack–我知道了。然后对方发了一个fin：我也不想跟你发送数据了；一个ack–知道了；
8. 三次握手不仅仅是握手！即不仅仅是syn/ack等。由于只是传输报头，所以此时他们还进行了协商缓冲区大小等事情。有一个字段是16位窗口大小，并不意味着窗口大小一定是65535，因为还有一个字段：窗口扩展因子，在握手阶段，双方通过该字段来协商缓冲区大小！
   

gpt回答

面试中经常被问到为什么TCP协议需要三次握手来建立连接以及四次挥手来断开连接，以下是这两个问题的详细解释：

为什么需要三次握手来建立连接？
TCP协议使用三次握手来建立连接，主要是为了确保通信双方的连接状态是可靠的，并且能够处理网络中的异常情况。以下是三次握手的主要目的：

确认双方的通信能力：通过三次握手，双方可以确认彼此都能够发送和接收数据，从而确保连接的可靠性。
同步双方的初始序列号：TCP是一个字节流协议，没有报文边界。因此，需要双方协商一个初始序列号，以便后续的数据传输能够按照正确的顺序进行。三次握手中的SYN和ACK报文段就用于协商和确认双方的初始序列号。
避免失效的连接请求报文段：如果客户端发送的连接请求报文段在网络中滞留（例如，由于网络拥堵），客户端可能会超时并重发连接请求。如果此时旧的连接请求报文段到达了服务器，服务器会发送一个确认报文段给客户端。但是，由于客户端已经关闭了连接，这个确认报文段对于客户端来说是无效的。使用三次握手可以避免这种情况，因为服务器只有在收到客户端的确认报文段后才会认为连接已经建立。
为什么需要四次挥手来断开连接？
TCP协议使用四次挥手来断开连接，主要是为了确保通信双方都能够可靠地关闭连接，并且处理数据发送的完成情况。以下是四次挥手的主要目的：

确保数据发送完成：在断开连接之前，通信双方需要确保所有数据都已经成功发送和接收。四次挥手中的第二次和第三次挥手就是用于处理这个问题的。客户端发送一个FIN报文段告诉服务器它已经完成了数据的发送，但是服务器可能还有数据要发送给客户端。因此，服务器需要发送一个ACK报文段告诉客户端它已经收到了FIN报文段，并且等待自己的数据发送完成后再发送一个FIN报文段给客户端。
释放连接资源：在断开连接后，通信双方需要释放与连接相关的资源（如缓冲区、连接状态等）。四次挥手中的最后一次挥手就是用于通知对方连接已经关闭，并且可以释放相关资源。
处理半关闭状态：TCP连接是一个全双工的连接，即通信双方都可以同时发送和接收数据。四次挥手可以处理连接处于半关闭状态的情况，即一方已经关闭了发送通道（或接收通道），但另一方仍然可以发送（或接收）数据。
综上所述，三次握手和四次挥手是TCP协议中非常重要的机制，它们确保了TCP连接的可靠性和数据的完整性。

SYN洪水（又名SYN洪水攻击或SYN洪泛）

SYN洪水（又名SYN洪水攻击或SYN洪泛）是一种分布式拒绝服务（DDoS）攻击，其目标是耗尽目标服务器上的资源，使其无法响应合法流量。以下是关于SYN洪水攻击的详细解释：

定义
SYN洪水攻击是一种利用TCP协议缺陷进行的攻击，攻击者向被攻击的主机发送大量伪造的TCP连接请求（SYN数据包），导致目标主机上的资源耗尽（如CPU满负荷或内存不足），从而无法处理正常的TCP连接请求。

工作原理
TCP三次握手：在正常的TCP连接建立过程中，客户端和服务器会进行三次握手。首先，客户端向服务器发送一个SYN（同步）数据包请求建立连接；然后，服务器响应一个SYN-ACK（同步-确认）数据包；最后，客户端发送一个ACK（确认）数据包完成连接建立。
攻击过程：在SYN洪水攻击中，攻击者会向目标服务器上的每个端口重复发送SYN数据包，通常使用伪造的IP地址。服务器收到这些看似合法的连接请求后，会向每个请求分配资源并发送SYN-ACK数据包。然而，由于攻击者使用了伪造的IP地址或者选择不发送ACK数据包，服务器将无法完成三次握手并一直保持这些连接处于半开状态。
资源耗尽：随着半开连接的数量不断增加，服务器上的资源（如内存和CPU）将逐渐被耗尽。当服务器的连接溢出表填满时，它将无法再处理新的连接请求，从而导致对合法用户的服务被拒绝。
特点
分布式：SYN洪水攻击通常是由多个攻击源同时发起的，使得攻击更加难以检测和防御。
伪装性：攻击者通常使用伪造的IP地址发起攻击，使得追踪和定位攻击源变得困难。
资源消耗：SYN洪水攻击会大量消耗目标服务器的资源，导致服务不可用。
缓解方法
微块：管理员可以在服务器内存中为每个传入的SYN请求分配一个微记录（少至16字节），而不是一个完整的连接对象，以减少资源消耗。
SYN Cookie：使用SYN Cookie技术，服务器可以在收到SYN数据包时生成一个唯一的Cookie值，并将其与SYN-ACK数据包一起发送。当客户端发送ACK数据包时，服务器将验证Cookie值以确认连接的有效性。这可以防止攻击者利用伪造的IP地址发起攻击。
防火墙和入侵检测系统：配置防火墙和入侵检测系统以检测和过滤异常的SYN数据包流量，从而减少SYN洪水攻击的影响。
通过了解SYN洪水攻击的工作原理和缓解方法，网络管理员可以采取相应的措施来保护他们的服务器和网络免受此类攻击的影响。

连接管理机制中在四次挥手时客户端状态从TIME_WAIT到CLOSE为什么隔一段时间

在TCP连接管理机制的四次挥手过程中，客户端状态从TIME_WAIT到CLOSE需要隔一段时间，这是为了保证网络传输的可靠性和避免因为网络丢包或者网络延迟而造成的问题。以下是对此过程的详细解释：

TIME_WAIT状态的作用：
在TCP四次挥手中，当客户端接收到来自服务器的FIN包并发送ACK确认后，客户端进入TIME_WAIT状态。
这个状态存在的目的是确保客户端发送的最后一个ACK包能够到达服务器，因为TCP协议是可靠的，需要确保双方的连接都已经被关闭。
如果客户端发送的ACK包在网络中丢失，服务器会因为没有收到ACK而重传FIN包，这时客户端需要再次发送ACK包。
TIME_WAIT状态的持续时间：
这个状态通常持续的时间是2MSL（Maximum Segment Lifetime，报文最大生存时间）。在RFC 793协议中，建议的MSL时间是两分钟，但在实际操作系统（如Linux）中，这个时间通常被设置为30秒，因此2MSL就是60秒。
设置这样的时间间隔是为了确保在网络中的残留数据包都已经过期，从而避免因为网络延迟或丢包而引发的问题。
从TIME_WAIT到CLOSE的转换：
当客户端在TIME_WAIT状态持续了2MSL时间后，如果没有再次收到来自服务器的数据包，那么客户端就可以安全地关闭连接，从TIME_WAIT状态转变为CLOSED状态。
这个过程确保了客户端和服务器之间的连接已经完全关闭，并且网络中的残留数据包不会对下一次连接造成影响。
综上所述，客户端在TCP四次挥手过程中从TIME_WAIT状态到CLOSE状态需要隔一段时间，这是为了确保网络传输的可靠性，避免因为网络丢包或延迟而引发的问题。这个时间间隔通常是2MSL，也就是60秒（在Linux系统中）。