TCP stream 字节流

这个应该能对TCP字节流的理解有点帮助：

两 个 应 用 程 序 通 过 T C P 连接交换 8 b i t 字 节 构 成 的 字 节 流 。 T C P 不 在 字 节 流 中 插 入 记 录 标 识

符。我们将这称为字节流服务( b y t e s t r e a m s e r v i c e )。如果一方的应用程序先传 1 0 字节,又传 2 0 字节,再传 5 0 字 节 , 连 接 的 另 一 方 将 无 法 了 解 发 方 每 次 发 送 了 多 少 字 节 。 收 方 可 以 分 4 次接 收这 8 0 个字节,每次接收 2 0 字节。一端将字节流放到 T C P 连接上,同样的字节流将出现在 T C P 连接的另一端。

另外, T C P 对字节流的内容不作任何解释。 T C P 不 知 道 传 输 的 数 据 字 节 流 是 二 进 制 数 据 , 还是 A S C I I 字符、 E B C D I C 字 符 或 者 其 他 类 型 数 据 。 对 字 节 流 的 解 释 由 T C P 连 接 双 方 的 应 用 层 解释。

这种对字节流的处理方式与 U n i x 操作系统对文件的处理方式很相似。 U n i x的内核 对一个应用读或写的内容不作任何解释,而是交给应用程序处理。对 U n i x 的内核来说, 它无法区分一个二进制文件与一个文本文件 。

重复报文出现的可能有：1.在某个节点上存在多个端口同时发送多个报文的拷贝，导致最终在接收端收到了来自不同路径的报文。
                                    2.还有一种是如果有回复确认机制的情况下，当接收端对已经收到的报文进行回复确认的过程中，回复确认报文                                        在途中丢失。导致发送端超时重传。
                                    3.网络拥塞导致确认报文延时超过重传定时器。