为什么TCP要做成流式协议，而非包？

TCP被设计成流式协议而非包协议，主要有以下技术方面的原因：

适应早期硬件与网络环境：

    实现简单：在1970年代，硬件条件有限，如处理器速度慢、内存小等。字节流协议的实现相对简单，允许将控制信息插入字节序列空间，并和有效数据一样期望得到确认，比如SYN、FIN等控制位。这比处理复杂的包结构更适合当时的硬件环境。

    适配异构网络：当时IP尚未从TCP分离，作为整体的TCP底层逻辑需要包含分包（即分离后的IP分片）功能。无边界字节流允许将TCP载荷在需要的时候拆分合并成任意大小，以适配早期非常异构的网络环境，不同网络可能有不同的最大传输单元（MTU）等特性。

满足应用层需求：

    统一数据处理：早期应用以远程登录和文件传输为主。对于远程登录，会产生大量单字符报文；而文件传输则涉及块数据。字节流作为交集更具适应性，能统一处理这两类数据，相比将数据严格按照包来划分，更有利于提高传输效率和资源利用率。例如，在远程登录时，可以将多个连续的单字符报文合并传输，减少报文数量。

    减少传输开销：如果以包为单位，当主机为远程登录产生大量单字符报文时，每个字符都需要封装成一个包，会增加大量的包头开销，严重浪费网络带宽。而TCP作为流式协议，可以将多个连续的单字符或小数据量的报文合并重传，减少传输报文数量，缓解网络拥塞，提高传输效率。

提高传输效率与灵活性：

    自由分片与MTU适配：如果TCP承诺按用户提交的报文一次性完整传输（即作为包协议），当遇到中间承载设备（如以太网）的MTU较小时，就会出现问题。例如，用户发送一个大于MTU的报文，就需要在IP层进行分片，增加了额外的IP头开销，降低了传输效率，且在遇到传输错误和丢包时，处理也会变得复杂。而流式协议允许TCP协议栈根据底层网络的MTU自动计算并以最合适的大小传输报文，无需考虑用户数据组织，只要按顺序传输字节流即可，确保了数据高效安全传输。

    智能打包与缓冲区管理：TCP的流式特性允许其智能地把缓冲区未发送的数据尽量按MTU大小打包发送，每个报文都刚好填满MTU，充分利用底层硬件性能，同时减少“无用”的报头传输，提高网络利用率。此外，像Nagle算法等机制，还能在数据提交速度较慢时，主动等待积攒足够的数据后再发送大包，进一步提高网络整体利用率。

降低协议实现与使用复杂度：

    避免包大小限制问题：如果TCP是面向用户的包协议，就必须给包设计一个最大大小，否则TCP不知道要分配多大内存来接收数据。但上层应用可能无法提前知道一个包的大小，例如上传一个文件时，文件大小是不确定的。这会导致一系列问题，如recv接口在面对用户包大于接收buffer时，难以设计合理的行为，是返回一部分数据、返回错误、还是逼发送方手工拆包等，都会增加协议实现和使用的复杂度。

    简化协议语义与连接管理：若TCP同时提供面向包、面向流两种语义，需要定义“包连接”和“流连接”两种连接，各传各的数据，这会大大增加协议设计和使用的复杂度。特别是在一些复杂的业务场景中，如需要进行有序数据传输，开头是个包，包完了是流，TCP作为通用传输协议很难处理这种情况。而只采用流式协议，语义相对简单清晰，更有利于协议的实现、维护和广泛应用。