彪锅锅来啦

TCP的分片先来认识下 MTU 和 MSSMTU：一个网络包的最大长度，以太网中一般为 1500 字节；MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度；既然 IP 层会分片，为什么 TCP 层还需要 MSS呢？如果在 TCP 的整个报文（头部 + 数据）交给 IP 层进行分片，会有什么异常呢？当 IP 层有一个超过 MTU 大小的数据（TCP 头部 + TCP 数据）要发送，那么 IP 层就要进行分片，把数据分片成若干片，保证每一个分片都小于 MTU。把一份

经过前面不懈的努力，初步打造了一个比较好的技术根基，好马配好鞍，好车配风帆，怎么就把领先优势拱手送与特斯拉了。用户欲壑难平，资源供不应求，靠“术”并无法优雅的解决。跳出来从产品角度去观察，还有些什么能够触动我们思考的深度呢。根据不同的需求和使用场景，用有损服务的价值观去权衡取舍，用完美的精神追求不完美，此乃道的层面。所谓大道至简，完美之道，不在无可添加，而在无可删减。通过多异步和各类缓存机制，提供区分网络、区分业务场景下的差异化服务，是我们孜孜以求的大“道”。下面通过一些实践案例的总结，来探索简洁优雅的弱联

2) 异步并发请求的能力，HTTP协议最早的设计中，在拉取多个资源时，会对应并发多个HTTP链路（HTTP/1.1的Pipeline类似）时，服务端无法区分客户端请求的优先级，会按照先入先出（FIFO）的模式对外提供服务，这样可能会阻塞客户端一些重要优先资源的加载，而在链路复用的通道上，则提供了异步并发多个资源获取请求指令的能力，并且可以指定资源加载的优先级，比如CSS这样的关键资源可以比站点ICON之类次要资源优先加载，从而提升速度体验；APNS解决了信息找人的问题，在过去，只有运营商的。

为了保持链路还需要做心跳机制（从另外一个角度看，这也是针对简单信息一个不错的PULL/PUSH时机,，但需注意数据传输要够轻，比如控制在0.5KB以内），而心跳机制是引入长链接方案复杂度的一个重要方面，移动网络链路环境复杂，国内网关五花八门，链路超时配置各有千秋，心跳时长选择学问比较大，不但要区分网络类型，还得区分不同运营商甚至不同省市，历史上曾经实践了2分钟的心跳间隔，最近比较多的产品实践选择4.5分钟的心跳间隔。在持续运营的过程中，根据观察到的数据，发现并非物理距离最近的就是最快的。

被释放的TCP链接的TUPLE信息同时也就就清除了。假设一个服务器作为TCP链接的被动打开方（通常是作为服务器角色）和主动关闭方，则大量主动关闭的链接会进入到TIME_WAIT状态，如果大伙在这个状态都折腾60秒，本地机器TCP/IP协议栈维护的TUPLE数据项会快速堆积并占用大量内核内存资源，最关键的是因为此时TCP四元组碰撞概率极低（因为源IP、源端口大多都是不同的），导致TUPLE的积压几乎不受限制而野蛮生长，这对于一个高负载又要求高性能的服务器而言，感情上是相当痛苦的，肉体上勉强能接受。

RTT是TCP超时重传机制的基础，也是拥塞控制的关键参数，准确的估算出RTT具有伟大的现实意义，同时也是一项相当艰巨复杂的任务。对于移动APP，大部分网络交互都是HTTP并发短链接小数据量传输的形式，如果服务器端有10KB +的数据返回，采用过去的慢启动机制时，效率会低一些，大概需要2~3个RTT才能完成数据传输，反应到用户体验层面就是慢，而把拥塞窗口cwnd初始值提升到10后，在大多数情况下都能在1个RTT的周期内完成应用数据的传输，这在移动网络这样的高时延、不稳定、易丢包的场景下，显得尤其意义重大。

我们需要有一条（相对）快速、（相对）顺畅、（相对）稳定的网络通道承载业务数据的传输，这条路的最好是传输快、不拥堵、带宽大、收费少。生活中做个类比，我们计划驱车从深圳到广州，如果想当然走广深高速十之八九要杯具，首先这个高速略显破败更像省道，路况不佳不敢提速；其次这条路上的车时常如过江之鲫，如果身材不好操控不便，根本就快不起来；最后双向六车道虽然勉强可以接受，但收费居然比广深沿江高速双向八车道还贵；正确的选路方案目前看是走沿江高速，虽然可能要多跑一段里程，但是通行更畅快。实际上，真实情况要更复杂，就如同【图二

【弱联网优化】作为海量之道2.0系列课题的基础方法论之一，望文生义，想必定是卖弄移动网络信号不佳时如何优化的奇技淫巧。恭喜你，感觉靠谱，不过我们还想多聊一点其它话题。移动互联网颠覆着我们的生活方式，这个每时每刻伴随着我们的网络到底有哪些特点，又是如何影响我们接入信息世界的体验呢。以下场景如似曾相识，敬请对号入座：上班路上收到朋友分享的一张美女图片，缩略图目测衣服用料相当节俭，立马兴奋点开欲详细钻研，却发现怎么脱也脱不下来，不对，是“拖”不是“脱”，仰望苍天，欲哭无泪。

最近花了些时间在学习TCP/IP协议上，首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上，所以希望深入了解一下。再者，TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上，比如说TCP 拥塞控制算法也可以用在以响应时间来限流的中间件上。更深一层，像TCP/IP协议这种基础知识和原理性的技术，都是经过长时间的考验的，都是前人智慧的结晶，可以给大家很多启示和帮助...