TCP可靠连接的建立和释放，TCP报文段的格式，UDP简单介绍

TCP连接的建立（三次握手）

建立连接使用的三报文 

SYN 报文仅用于 TCP 三次握手中的第一个和第二个报文（SYN 和 SYN-ACK），用于初始化连接的序列号。数据传输阶段不再使用 SYN 标志。 SYN 报文通常只携带连接请求信息，并不包含实际的数据负载。

ACK表明这是一个确认报文。

seq（序列号） 是一个用于追踪每个字节流位置的编号，它确保数据传输的可靠性和有序性。序列号的作用是帮助接收方和发送方正确重组数据，即使数据包顺序错乱或丢失，也能通过序列号将其还原到正确的位置。双方的序列号（Seq）并没有直接的本质联系。每个方向的序列号是独立的，只是它们在各自方向上保持连续性。

ps:在tcp建立连接握手阶段，虽然还尚未发送数据，但是可以看到这里第三个报文和第一个报文相比，序列号增加了1。因为即使没有数据传输，每次握手中的 SYN 报文都会消耗一个序列号

确认号 (ack)：如果接收方的最后一个成功接收的数据字节的序列号为 N，那么接收方会在 ACK 中发送确认号 N + 1，表示接收方已经成功接收到了序列号 N 之前的所有字节，并且期望接收序列号为 N + 1 的字节。ack=seq+1

为什么建立TCP连接不能使用两报文？

避免旧的连接请求引发的误连接
如果采用两次握手，假设客户端发送一个 SYN 报文请求建立连接，然后因网络延迟，该报文被滞留在网络中。如果此时服务器没有接到确认就直接建立连接，当滞留的 SYN 报文到达后，服务器可能误以为客户端请求重新连接，错误地建立新的连接。三次握手的第三次 ACK 则能有效避免这一问题，因为旧 SYN 报文不会收到匹配的第三次握手确认，避免了误连接的发生。

如果采用两报文握手，那么将会是下面这样的情况：

如果采用两次握手建立连接，当TCP服务器端收到网络中已经失效的TCP连接请求之后，也会以为是客户机发来的连接请求，直接进入连接状态/但是客户机这边可能已经关闭了tcp连接，此时并不需要tcp服务传送数据，但是服务器端始终保持着这些无效连接，造成了tcp连接资源的浪费 。

TCP连接建立的一道例题

这道题选项中，主机乙选择的初始seq正好与报文要回应的主机甲的ack一样，看起来有点别扭。

TCP连接的释放（四次挥手）

释放连接使用的四报文

1.主动关闭方发送 FIN（Finish）报文

• 发送方（客户端或服务器） 发送一个 FIN 报文段，表示数据发送完毕，不再发送数据。这一步是主动关闭连接的一方（通常是客户端）发出的。
• FIN 报文中的 SEQ 字段表示最后一个字节的序列号（即发送方最后一个字节的序列号），告诉接收方发送方已经完成数据发送。

2. 被动关闭方回复 ACK 报文

• 接收方（另一方，通常是服务器或客户端） 收到 FIN 报文后，会发送一个 ACK 报文，确认已经收到对方的 FIN 请求，序列号为 接收方的下一个序列号。
• 这个 ACK 报文的确认号是 FIN 的序列号 + 1，表示已经收到 FIN 报文。

3. 被动关闭方发送 FIN 报文

• 在发送 ACK 报文后，被动关闭方（比如服务器）会准备关闭连接，发送一个 FIN 报文，表示自己也没有数据要发送，准备关闭连接。
• 这个 FIN 报文和连接的正常数据包一样，包含一个 SEQ 字段，表示自己最后发送的数据字节的序列号。

4. 主动关闭方回复 ACK 报文

• 主动关闭方（客户端或服务器） 收到 FIN 报文后，会发送一个 ACK 报文来确认接收方的 FIN 请求，表示连接完全关闭。但是此时主动关闭方并不会直接变为close状态，而是进入一个时长为2MSL的时间等待状态，为了确保对方收到了最后的 ACK 报文，即便是 ACK 丢失，被动关闭方重发的 FIN 报文也可以被主动关闭方处理，从而保证连接双方的一致性。
• 此时，确认号是 对方的 FIN 序列号 + 1。

为什么需要四次挥手？

1. 每方都要告知对方自己没有数据要发送：由于 TCP 是全双工的协议，连接的关闭是单独的。每个方向的数据流都需要单独关闭，因此需要四次挥手。
2. 保证数据的完整性：每一方都确保对方确认自己所有的数据已经被接收并且完全关闭连接。

为什么选择设计TCP连接可单向解除？

当主动关闭方发送 FIN 请求断开连接，并得到被动关闭方的 ACK 确认后，主动关闭方会停止数据的发送，但依然会继续接收来自被动关闭方的数据。

• 确保数据传输完整性：
  如果主动关闭方在发送 FIN 后立刻关闭接收通道，则可能导致被动关闭方尚未传输的数据被丢弃。通过保持接收通道的开放，即使主动关闭方停止发送数据，它仍可以接收被动关闭方的剩余数据，确保任何未完成的数据传输不会因为连接关闭而丢失。

• 支持渐进式的双向关闭：
  在实际应用中，有时主动关闭方可能已经不需要发送更多数据，但被动关闭方仍然有待传输的数据。例如，当客户端请求断开连接时，服务器可能仍有一些待发送的响应或日志。通过分离关闭方向，TCP 允许服务器在完成数据发送后再发送 FIN 请求来正式关闭连接，从而实现一个更优雅的连接终止过程。

TCP连接/释放推荐参考视频：

5.8.2 TCP的运输连接管理—TCP的连接释放_哔哩哔哩_bilibili

【复试自用计算机网络】TCP连接建立的三次握手+TCP连接断开的四次握手_哔哩哔哩_bilibili

TCP报文段的首部格式 

 

 

• 源端口号：标识发送方应用程序的端口号，通常由发送方操作系统动态分配（除非应用程序指定固定端口号）。
• 目的端口号：标识接收方应用程序的端口号，通常是由接收方服务或应用程序指定。例如，HTTP 服务通常使用端口 80，HTTPS 使用端口 443。
• 序列号：表示报文段中数据的第一个字节的编号，用于确保数据的顺序传输和重组。在建立连接的第一次握手（SYN）中，序列号会作为初始序列号（ISN）发送。
• 确认号：确认号是接收方发送给发送方的一个字段，表示接收方期望收到的下一个字节的序列号。TCP 使用这个字段来实现确认机制，确保数据的可靠传输。
• 数据偏移：指出 TCP 报文段首部的总长度，以 32 位字（4 字节）为单位。这一字段帮助接收方知道数据从报文段的哪个位置开始。（由于tcp报文段的首部包含拓展首部，其长度不固定，而我们首部总长度又必须要求为4字节的倍数，所以拓展首部的后面有填充字段，用来帮助首部长度凑为4的倍数）
• 关于后面的几个字段这里也不详细一一介绍了，可以观看视频：5.9 TCP报文段的首部格式_哔哩哔哩_bilibili

关于tcp首部中序列号和确认号的详细解释

当 TCP 连接建立时，双方都会生成一个 初始序列号（ISN）。这个初始序列号通常是一个 随机数，而不是固定的 0。使用随机的 ISN 是为了提高安全性，防止 序列号预测攻击（例如，攻击者利用已知的序列号猜测数据流）。

tcp数据报其中包含的数据字节都会按顺序编号，并且每个字节都会分配一个唯一的序列号。发送报文的序列号是 连续增长 的，即每发送一个新的数据段，序列号就会增加相应的数量。虽然一个报文段中可以包含若干字节，但是一个tcp数据报中的序列号只填入这个数据报中的第一个字节的编号。

• 假设初始序列号 ISN = X，发送方发送了一个包含 N 字节数据的报文段。则该报文段的序列号为 X，而确认号会是 X + N（即对方期望接收的下一个字节的序列号）。
• 下一个报文段的序列号将是 X + N，并且它会继续递增，直到所有的数据都发送完。
• 注意： 序列号是按字节递增的，而不是报文段递增。这意味着每个数据字节都有一个唯一的序列号。

确认号（ACK）是 TCP 报文段头中的一个字段，表示接收方期望下一个收到的数据字节的序列号。它用于确认已经成功接收到的数据，并告诉发送方接收方期望接收的下一个字节。

序列号和确认号是密切联系配合的！！！

• 发送方：
  • 发送方在发送数据时会给数据报文段分配序列号。序列号表示该报文段中的数据相对于字节流的偏移量。
• 接收方：
  • 接收方收到数据后，会根据自己期望的下一个字节的序列号来发送确认号。接收方的确认号是 期望接收到的下一个字节的序列号。
  • 例如，如果接收方已经收到了序列号为 1000 到 1500 的数据，那么它的确认号会是 1501，表示它已经收到并确认了 1000 到 1500 的数据，期望收到下一个字节 1501。

UDP简单介绍