阅读麻烦TCP/IP图鉴第一卷：第19.4节
Trouble in reading TCP/IP illustrated Volume 1, first Editon : Section 19.4
电子书link：
TCP/IP illustrated Volume 1: 19. TCP Interactive Data Flow
图19.6 图19.5的时间线（看Nagle算法）
The first change we notice is that all 3 bytes are sent when they're ready (segments 1, 2, and 3). There is no delay—the Nagle algorithm has been disabled.
The next packet we see in the tcpdump output (segment 4) contains byte 5 from the server with an ACK 4. This is wrong. The client immediately responds with an ACK 2 (it is not delayed), not an ACK 6, since it wasn't expecting byte 5 to arrive. It appears a data segment was lost. We show this with a dashed line in Figure 19.8.
How do we know this lost segment contained bytes 2, 3, and 4, along with an ACK 3? The next byte we're expecting is byte number 2, as announced by segment 5. (Whenever TCP receives out-of-order data beyond the next expected sequence number, it normally responds with an acknowledgment specifying the sequence number of the next byte it expects to receive.) Also, since the missing segment contained bytes 2, 3, and 4, it means the server must have received segment 2, so the missing segment must have specified an ACK 3 (the sequence number of the next byte the server is expecting to receive.) Finally, notice that the retransmission, segment 6, contains data from the missing segment and segment 4. This is called repacketization,
作者让我很困惑，来自服务器（vangogh.login）的ACK 2在哪里？
我认为声明应该是“这意味着服务器必须接收到段 1，因此丢失的段必须指定一个 ACK 2”
首先，slip 期望从 vangogh.login 获取第二个字节，但它获取了第五个字节；
其次，因此我们可以得出结论，第 2、3、4 个字节在从 vangogh.login 到 slip 的传输过程中丢失了；
第三个、第二个、第三个字节从段 1() 转入 slip 发送，第 4 个字节从段 2 转入，段 1、段 2 由 vangogh.login 接收。
第四，所以丢失的段必须根据段2指定一个ACK 3( 2:3(1) )。
电子书link： TCP/IP illustrated Volume 1: 19. TCP Interactive Data Flow
图19.6 图19.5的时间线（看Nagle算法）
The first change we notice is that all 3 bytes are sent when they're ready (segments 1, 2, and 3). There is no delay—the Nagle algorithm has been disabled.
The next packet we see in the tcpdump output (segment 4) contains byte 5 from the server with an ACK 4. This is wrong. The client immediately responds with an ACK 2 (it is not delayed), not an ACK 6, since it wasn't expecting byte 5 to arrive. It appears a data segment was lost. We show this with a dashed line in Figure 19.8.
How do we know this lost segment contained bytes 2, 3, and 4, along with an ACK 3? The next byte we're expecting is byte number 2, as announced by segment 5. (Whenever TCP receives out-of-order data beyond the next expected sequence number, it normally responds with an acknowledgment specifying the sequence number of the next byte it expects to receive.) Also, since the missing segment contained bytes 2, 3, and 4, it means the server must have received segment 2, so the missing segment must have specified an ACK 3 (the sequence number of the next byte the server is expecting to receive.) Finally, notice that the retransmission, segment 6, contains data from the missing segment and segment 4. This is called repacketization,
作者让我很困惑，来自服务器（vangogh.login）的ACK 2在哪里？ 我认为声明应该是“这意味着服务器必须接收到段 1，因此丢失的段必须指定一个 ACK 2”
首先，slip 期望从 vangogh.login 获取第二个字节，但它获取了第五个字节；
其次，因此我们可以得出结论，第 2、3、4 个字节在从 vangogh.login 到 slip 的传输过程中丢失了；
第三个、第二个、第三个字节从段 1() 转入 slip 发送，第 4 个字节从段 2 转入，段 1、段 2 由 vangogh.login 接收。
第四，所以丢失的段必须根据段2指定一个ACK 3( 2:3(1) )。