假设我们想与服务器建立 TCP 连接
因为在 TCP 中，由于 tcp 拥塞控制（在达到阈值之前），我们在收到 acks 后将发送段（我们发送的段数或窗口）加倍，但是发送方在 3 次握手中发送的第一个段是否计数？
基本上我要问的是在 3 次握手的第二阶段收到来自接收器的 ack 之后，我们会做哪一个：
1）只发送确认
2) 发送 ack + 1 段
3) 发送 ack + 2 段
或者可能不是上述情况？
客户端在3次握手中发送的第一段是否计入tcp拥塞控制？
网络工程
通讯协议
2021-08-01 23:24:56
1个回答
查看 RFC 5681 - TCP 拥塞控制
以及初始窗口大小的定义：
INITIAL WINDOW (IW)：初始窗口是三路握手完成后发送方拥塞窗口的大小。
所以，不，在计算拥塞窗口大小时不考虑握手。拥塞窗口的初始值在三路握手发生后设置。
初始窗口值受以下规则约束：
IW，cwnd 的初始值，必须使用以下准则作为上限进行设置。
- 如果 SMSS > 2190 字节：
- IW = 2 * SMSS 字节且不得超过 2 个段
- 如果（短信 > 1095 字节）和（短信 <= 2190 字节）：
- IW = 3 * SMSS 字节且不得超过 3 个段
- 如果 SMSS <= 1095 字节：
- IW = 4 * SMSS 字节且不得超过 4 个段
查看TCP RFC（793），在握手期间发送数据是可以的，但在握手完成之前无法将其传递给应用程序：
下面是连接启动的几个示例。尽管这些示例没有显示使用数据承载段的连接同步，但这是完全合法的，只要接收 TCP 在明确数据有效之前不将数据传送给用户（即，数据必须被缓冲）在接收方，直到连接达到 ESTABLISHED 状态）。三向握手减少了误连接的可能性。
因此可以在握手期间发送数据，并且根据 TCP 拥塞控制 RFC，在此阶段尚未设置初始窗口，因此对于握手期间发送的任何数据，拥塞控制似乎没有发挥作用。
另一方面，实际实现可能与 RFC 不同，它们的实现方式也可能不同。
为了回答您的最后一个问题，最终的 ACK 可以单独发送，也可以与用户数据一起发送，具体取决于实现方式以及数据是否已准备好发送。但是，它将被归类为单个段，数据或无数据。