操作系统我把应用程序封装好了，TCP连接和udp连接，两种接口。绝大多数情况下，我们只需要使用这两种封装好的连接就可以了，如果需要使用自定义的连接方式，比如修改IP包，产生自己的传输协议，那需要以核心态运行程序和网卡直接打交道。
此外，由于网络中各种基础设施长期的固化，大家对TCP连接以及IP包中的数据有一些默认但是没有成文的规定，这些规定在实际操作中影响了新的传输层协议的产生，也限制了TCP的进步。于是我们可以看到Google的quick协议是基于udp的，而没有产生一个直接和TCP竞争的传输层协议。
在在线视频和游戏当中，大多使用的是udp协议传输数据，因为此时丢失短暂的几个数据包，通常还不到一帧，是不影响整体体验的。而这种不可靠的传输方式能够带来更高的速度和更低的延迟，所以在要求低延迟或者速度上位于稳定性的情况下，是非常合适的。
在即时通讯软件当中，以目前的网络状况来看，使用TCP连接是可行的。然而TCP连接是以流的形式传输消息的，一对输输出流当中，如果前边的消息比较长，后期的消息则要等待很久才能够接收。比较典型，您的例子是发送文件和消息，如果文件很大，需要10分钟才能传输完毕，那么在他之后发送的消息也要等待这10分钟，这10分钟内消息无法发送出去，这显然是难以接受的。
如果使用udp建立发送消息的协议，那么我们需要自己手动的封装成一个类似TCP的协议，从而完成数据包排序合并，以及失败后重发等工作。如果不出意外的话，不应该这么做。
对于网络应用而言，如果不像Google一样追求极致的性能和效果，而又想要使用现成的，稳定的连接，那么直接使用TCP是比较合适的。
TCP是输入输出流的形式，传输消息，那么就要想办法解决消息阻塞的问题。
一个思路是，对于小的消息，集中起来使用一个连接；对于大的消息开启新的线程异步通信，建立新的链接来传输这个大消息。
如果从一个连接发送的消息的个数上来看，这就是使用长连接和短连接相搭配。如果单纯的从连接的时间长度上来看，他们全都是长链接。
在旧的HTTP服务当中，使用的TCP连接多数都是短连接。而在即时通信领域，使用短连接意味着每次发送消息的时候都要带上验证信息，这给传输消息带来了很大的额外负担。新的HTTP服务当中，如果在头信息当中标注了保持连接活跃的这个头信息，那么这个连接就会是长连接会在一段时间内长期提供网络服务，而不必重新建立连接。
在即时通信服务方面，通常使用长连接来验证用户的在线状态是更加方便和合适的。我们可以假设小于1000字节的消息长度，都属于小的消息，可以在主要的长链接当中发送，而大于这个长度的消息全部都开启新的线程，异步发送。如此一来解决了了TCP连接消息阻塞的问题。
