TCP连接就是传说中的长连接，有所谓的3此握手来保证消息一定可达，在java中，TCP传输的方式属于流数据传输，而流数据传输的特点就是数据到达的顺序是固定的，比如说数据A写入到TCP连接中，数据B接着再写入到TCP连接中，数据C再写入TCP连接，那么在另一端，如果数据不丢失，那么A到达后，B到达，C再到达；当B丢失了，那么就是A到达，B丢失，C这时候也不会到达，因为TCP连接是可靠连接，一定会确保B到达了之后才会再去处理C数据，因此要么只收到A，B和C都丢失（TCP连接断开），要么A收到后过一段时间重新发送B和C，然后另一端再接收B，C，最后数据接收的顺序还是A，B，C，而绝对不可能出现A，C或者B，C的情况；

TCP数据传输还存在一个粘包问题，之所以会出现数据粘包就是因为TCP数据传输是流数据传输，假设数据包A是10个字节，数据包B是20字节，数据包C是30字节，那么发送顺序是A，B，C，这时候TCP连接的流里面就有10+20+30=60个字节，但是有可能由于网络原因这60个字节并不会一次性都发出去，有可能先发了15个字节，再发20个字节，再发30个字节，那么在接收端就会连续收到三次数据，但是接收端必须对每次接收到的数据进行处理，第一次接收到了15个字节，而A只有10个字节，那么多出来的5个字节就是B的，这时候就出现了粘包，就是说数据包B的部分数据粘在的数据包A后面了，所以在接收端要截取完整的数据包再进行处理，把多出来的5个字节缓存起来等待接收B数据，以此类推UDP就不存在粘包的问题，UDP发送的数据包都是一个完整的包，因此接收端收到的包也会是一个完整的数据包，但是UDP每次发送的数据包大小是有限的，最大不超过【UDP中的总长度字段为2字节 所能表示的最大数为65535 UDP协议头本身占据了8字节 所以所能发送的最大数据长度是65535-8=65527】，而且UDP在网络环境不好的情况下容易丢失，丢失了也不会通知到发送方或者接收方，所以UDP是不可靠连接，但是UDP连接并不会一直维持一条从发送放到接收方的连接，发送方只要把数据扔出去就结束了发送流程，而接收方只是开一个指定的端口并监听这个端口，有数据来就处理，没数据就不管，所以UDP连接省资源，在不丢失数据的情况下发送的效率比较高，占用内存少，而TCP是时时刻刻维持一个长连接，比较耗资源，占用较多内存

在移动开发中，IM一般采用TCP长连接，TCP长连接会遇到一下几个问题 :

耗资源，增加app的耗电量；占内存，增加app的运行内存，提升了在手机休眠情况下app被系统杀死的概率，导致TCP连接断开，消息无法即时收到

IM开发中一般有一个心跳包的概念，为什么要心跳包呢？因为网络运营商中有一个NAT超时，大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰NAT【(Network Address Translation，NAT)。简单的说运营商的网关需要维护一个外网IP、端口到内网IP、端口的对应关系，以确保内网的手机可以跟Internet的服务器通讯】表中的对应项，造成链路中断。NAT超时是影响TCP连接寿命的一个重要因素(尤其是国内)，所以客户端自动测算NAT超时时间，来动态调整心跳间隔

android设备的一个bug，从网上查到的，DHCP租期到了不会主动续约并且会继续使用过期IP，这会导致TCP连接编程无效连接，参考网上资料DHCP租期

最近碰到一个问题就是app开一个TCP连接成功连到服务器，然后手机锁屏休眠，过一段时间后（可能是几个小时）会发现这条TCP连接变成无效连接了，我从后台服务器查看手机设备的TCP连接确实是断开了，但是手机app代码检测TCP连接中Socket连接却显示连接正常，并且连接也没有任何中断异常，然后手机发送数据也是正常write成功，但是实际上服务器根本没有收到手机发送过来的数据，也就是说手机app的连接判断都是错误的，这种情况下TCP连接判断都是正常的，但是这条TCP连接确实无效不可用的，只有把这条TCP连接主动断开重新连接才能正常收发数据，服务器才能重新显示设备的TCP连接成功，我估计这个很有可能就是3造成的，有可能DHCP租期到了，但是没有继续续约，而采用过期IP，那么手机到运营商的网关的网络是通的，而由于目标服务器的IP已经过去，导致网关无法帮手机app路由消息

关于TCP连接状态的判断，在java里面是提供了isClosed()和isConnected()判断的是本地的状态，想要判断TCP连接是否真的有效： socket.sendUrgentData(0xff)，这个是立即发送一个字节数据，如果服务端的Socket没有开启setOOBInline(true)的话是会默认忽略这个收到的字节的，所以如果字节数据发送成功就说明连接可用，如果字节数据发送不成功就会抛出异常，说明连接不可用