【http协议】
断句 ：
由于tcp协议是基于流的传输协议，也就是在传输层本身是做不到断句的功能的，
于是断句需要在应用层协议实现。
最初用回车和换行来标示一套命令的结束 如果信息里面有 的情况呢
可以通过转义来解决这个问题，但是转义工作量太大，而且会增加传输大小，
因为转义字符一般情况比原始字符更大。而且这样也会有一个问题，如果接受到了
数据了，我们需要转义了第三个字符，吧 %20 转换成 = 那么在内存里buffer里
%20后面的所有字符都要向前移动。
当然后来在smtp的协议中有人提出可以用base64进行编码，这样的话就能避免上述问题，
但是使用base64会增加传输数据本身的内容。就会膨胀1/3。
但是如果在http协议中也使用这种东西，那么就太浪费带宽了，
于是在http协议里面，固定增加一个 Content-length字段 用来表示后续数据的大小
Header和content用 分割，这样就解决了问题。
但是随着互联网的日益发达，有很多情况使用这种方式不能解决问题，比如在线直播，
于是来提供了trunk模式，就是将内容分段
【长连接和短连接，网络推送】
如果我们要实现一个类似微信易一样的app 怎么实现推送机制
我们有两种选择
1 Client轮训Server端，类似每隔个n秒 Client 去Server上面查询
2 Server端主动联系Clinet端 有效期的情况下Server通知Client端 ，让Client去取
然而第一种方法是一个两难的问题
n大了 就比较节省资源，但是消息的实时性比较低
n小了 实时性比较高 但是比较浪费资源
而第二种方法也有自己的问题,
大部分的NAT的实现，会导致局域网用户可以主动想Interbet发起TCP连接，但是局域网外部的ip不可以想内部ip主动发起连接。
在网络层心跳中，心跳时间过长，两分钟，那么我们应该在应用层再加一次心跳。这种情况就是为了防止网络的不稳定。
长连接主要解决的问题是 tcp握手连接的开销。