如果我没记错的话，一旦建立 TCP 连接，OP 的混淆似乎不是普通的 TCP 数据流量，而是 TCP 控制信令。

OP写道

在发送信息之前，TCP 必须与另一台主机建立连接

看起来像上下文，然后是：

那么，来自 TCP 的请求是被较低级别的堆栈协议封装还是直接发送到另一台主机？

那么问题来了，对于连接建立信令，是也被协议栈的低层封装（就像在正常的 TCP 数据流量中发生的那样），还是直接发送，不需要低层封装？

答案是，是的。考虑建立 TCP 连接的 3 次握手中的 SYN 段。除了一些重要的区别外，它就像一个普通的 TCP 段（例如，参见RFC 793）：

• 每个 TCP 标头有 6 个控制位，其中一个用于 SYN。在 SYN 段中，该位将被设置。
• 每个 TCP 标头中都有一个 32 位的序列号。这通常是该段中第一个数据八位字节的序列号， SYN 段除外。在 SYN 的情况下，序列号是初始序列号 (ISN)。
• 而不是在数据字节中携带实际数据，对于SYN，指定“第一个数据字节为ISN+1”

那么为什么不能“直接”发送 3 次握手中的 SYN 等特殊段，绕过较低层呢？我们不能直接发送它们，因为下面的 IP 层不知道如何路由这些 TCP 控制信令段！当然，我们本可以发明一些其他的方法来为这些段以不同的方式进行路由，但是我们已经有了 IP 层，具有 IP 路由和 TCP 段的封装，这对于数据包传递很有效，所以我们只是重新使用所有这些基础设施。

实际上，请求是只存在于应用层的东西，比如 HTTP GET 请求。该请求由一个 TCP 段（或多个）封装。

每个 TCP 段（传输层）都封装在 IPv4 或 IPv6 数据包（网络层）中。每个 IP 数据包依次封装在例如以太网帧（链路层）[1] 中。以太网帧经过线路编码并作为位或符号（物理层）通过线路发送。

该过程在另一端反向，并且 GET 请求被恢复。

[1] 当 IP 数据包太大而无法放入单个帧 ( MTU ) 时，可能会使用多个帧对其进行分段和传输。

因此，在 OSI 模型中，每一层都是相互独立的。如果您接受 HTTP 请求/响应，它基本上是发送一串字节，然后接收一串字节。这包含在一个 tcp 标头中，其中包括源 IP 和目标 IP。然后，在以太网的情况下，将其包裹在以太网帧中（带有源和目标 MAC 地址）并放在网络上。如果目的地与自己的 mac 匹配，接收设备将接收它并解开帧。然后根据它是否是需要转发 tcp 数据包的路由器，它可能会将其重新包装在另一个帧中并将其发送到另一个设备，或者如果它是终端主机并且与目标 IP 匹配，那么它将使用目标端口来传递内容数据包到正确的应用程序。

当涉及到 TCP 协议在连接启动之前 TCP 握手将启动。TCP syn & syn ack &ack 握手完成。这。SSL 握手在 SSL 握手完成后开始，实际应用程序数据将以加密格式传输。因为 TCP 是可靠的协议。如果队列中的任何数据包正在等待，整个队列将等待，因为在 TCP 中，新数据包将在收到旧数据包的确认后提示。

当涉及到 udp 数据包时，它是不可实现的协议。所有语音通信都在 udp 协议下