基于字节流和面向数据报

TCP基于字节流：TCP接收到应用层协议的消息(已编码为二进制)后，然后参考该计算机连接的网络数据链路层MTU（最大传输单元）确定是否要分包，然后交给IP层。但是并不会在不同的消息之间设置分隔符，应用层协议需要在自己的消息中包含该消息的长度信息。类比：你向一个文件追加一系列的序列化对象数据（可看做应用层协议包），如果你自己不标记每次序列化数据的长度，到了反序列化的时候就没办法了。如果你类似Redis在处理字符串的时候在头部维护字符串的长度，就可以安全的读出该字符串。

UDP基于数据报：Udp接收到应用协议的某个消息(已编码为二进制)后，不会分包，但是要记录当前数据包的大小（消息大小加上8个字节头部），然后交给IP层。IPV4对UDP数据报的大小限制为65535字节（包含头部8个字节），你每次可以直接发送的消息不能超过65507字节。然后UDP协议会自行根据头部的报文长度字段确定完整的消息，对于应用层协议来说，这就是一条完整的消息，不用再做逻辑分离消息。

不管是TCP或者UDP，IP层都会再次考虑MTU确定是否分包。IP层的功能这里不展开。

可靠性和时效性

TCP是可靠的，可靠性通过确认和超时重传机制保证。它是保证路由可达时最终能传输成功。

但是如果你加上时效性要求，这个“可靠性”就大打折扣了！考虑RPG游戏场合，如果因为网络丢包等原因，导致超时重传消息1秒后才到，这种延迟你能接受么？

通信链路不总是可靠的，如果出现问题，TCP协议是不会向上汇报的。而是通过ICMP协议来完成，最终由操作系统接收处理，而操作系统一般会接受多次反馈后才会最终确认“断网了”，WIndows就会长达几分钟。你可以尝试拔掉路由器的WLAN端口，再看看你的操作系统什么时候才反应过来无法连接到因特网。你的应用协议可以忍受这么长时间的“懵逼”状态么？

所以，即使TCP有可靠性保证，绝大部分基于TCP的应用层协议都会显示或隐式地包含确认功能和超时设置。考虑HTTP，显示的确认功能，客户端都会有请求超时时间限制。

Tips:

自定义应用层协议需要保证消息有序传输时，tcp的滑动窗口是个很好的实现参考。