你是如何理解“TCP是面向字节流的协议”的

UDP协议为应用层提供不可靠、无连接和基于数据报的服务。所以，使用UDP协议的应用程序通常要自己处理数据确认、超时重传等逻辑。而TCP协议则完全相反，为应用层提供可靠的、面向连接的和基于流的服务。当发送端应用程序连续执行多次写操作时，TCP模块先将这些数据放入TCP发送缓冲区中。当TCP模块真正发送数据时，发送缓冲区中等待发送的数据就可能被封装成一个或者多个TCP报文段发出。因此，TCP模块发送出的TCP报文段的个数和应用程序执行的写操作次数之间没有固定的数量关系。

显然的tcp发帧数据，你需要自己处理好分帧问题，这块写起来既不方便，也很麻烦，所以用tcp收发帧数据，往往需要在上层再包装一层协议，比如IoT中比较流行的mqtt，钦定只支持tcp封装，并且流传输肯定是有序的，后面的数据到了前面没到，也必须等待前面数据到了才能够组装起来，这也导致其延迟控制能力更差。

但好处是tcp非常适合于传输大量数据，比如像文件或http这种，能够保证数据是按照顺序发给你的，如果丢包了，底层也有重发机制能够尽可能保证数据发送可靠性，还有一系列拥塞机制，尽可能利用信道带宽。

udp就简单粗暴多了，发送一个数据包，要么完整收到，要么丢包，传输层中没有那么多七七八八的算法，所以udp很快，也非常适合做裸协议发送一些控制帧数据，包括rts游戏中的网络同步，能够更好控制延迟问题，但是显然的就得付出代价，比如可能会丢包哦，可能收到的数据包是乱序的哦，所以如果你用udp来传输大文件，七写八写一通下来，可能就是实现了一个蹩脚的tcp。

除此之外还有什么别的么，诶，如果我们再往上层走，维护tcp连接和逻辑实现，需要更多的性能及资源哦，所以面向tcp的攻击会更多，比如synflood，或者是面向序列号的三方攻击或某些不可说的rst中间人中断攻击。当然，如果不触及传输层实现，tcp往往需要再包装一层协议(会话或表示层），针对该层的慢速攻击及半连接攻击甚至是溢出攻击，处理起来尤为头疼，这也是这层协议设计起来尤为头疼的地方。

WRITE-BUG研发团队衷心希望【WRITE-BUG数字空间】可以给每位同学一个属于自己的秘密空间，同时祝愿大家在“公开圈子”世界里，遇见志同道合的伙伴们，因为我们与大家一样，都曾孤独前行着。