这又是一篇基于Netty的IM编码实践文章，因为合成一篇内容太长，读起来太累，所以也就顺着作者的思路分开成4篇，读起来心理压力也就没那么大了。

对于基于互联网的通信应用（比如IM聊天、推送系统），数据传递时使用TCP协议相对较多。这是因为在TCP/IP协议簇的传输层协议中，TCP协议具备可靠的连接、错误重传、拥塞控制等优点，所以目前在应用场景上比UDP更广泛一些。

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，支持iOS、Android、H5、标准Java平台，服务端基于Netty编写。

在如今的移动互联网时代，IM类产品已是我们生活中不可或缺的组成部分。像微信、钉钉、QQ等是典型的以 IM 为核心功能的社交产品。另外也有一些应用虽然IM功能不是核心，但IM能力也是其整个应用极其重要的组成部分，比如在线游戏、电商直播等应用。

说到TCP协议，对于从事即时通讯/IM这方面应用的开发者们来说，再熟悉不过了。随着对TCP理解的越来越深入，很多曾今碰到过但没时间深入探究的TCP技术概念或疑问，现在是时候回头来恶补一下了。

本文由cxuan分享，原题“原来这才是 Socket”，有修订。1、引言本系列文章前面那些主要讲解的是计算机网络的理论基础，但对于即时通讯IM这方面的应用层开发者来说，跟计算机网络打道的其实是各种API接口。本篇文章就来聊一下网络应用程序员最熟悉的Socket这个东西，抛开生涩的计算机网络理论，从应用层的角度来理解到底什...

网络协议是每个搞网络通信应用开发（比如IM、推送、网关等等）的程序员都必须要掌握的基础知识，TCP/IP协议簇中有两个最具有代表性的传输层协议——分别是 TCP 和 UDP。

本次更新为次要版本更新，进行了若干优化（更新历史详见：码云 Release Nodes）。可能是市面上唯一同时支持 UDP+TCP+WebSocket 三种协议的同类开源IM框架。

本次为主要版本更新（本次更新内容见文末“MobileIMSDK v6.0更新内容 ”一节），强势升级，将同时支持TCP、UDP、WebSocket三种协议，精心封装之下，实现同一套API、三种协议同时并存。

这次的文章由作者张彦飞原创分享，写作本文的原因是现在本机网络 IO 应用非常广。在 php 中 一般 Nginx 和 php-fpm 是通过 127.0.0.1 来进行通信的；在微服务中，由于 side car 模式的应用，本机网络请求更是越来越多。所以，如果能深度理解这个问题在各种网络通信应用的技术实践中将非常的有意义。

网关是一个比较成熟的产品，基本上各大互联网公司都会有网关这个中间件，来解决一些公有业务的上浮，而且能快速的更新迭代。如果没有网关，要更新一个公有特性，就要推动所有业务方都更新和发布，那是效率极低的事，有网关后，这一切都变得不是问题。

对于IM开发者而言，网络保活这件事再熟悉不过了，比如这是我最近一篇有关网络保活话题文章《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》，以及我分享的大量代码实战编码中也都必须要考虑这个问题的实现，比如最近的这篇《跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现》。

网络编程能力对于即时通讯技术开发者来说是基本功，而计算机网络又是网络编程的理论根基，因而深刻准确地理解计算机网络知识显然能夯实你的即时通讯应用的实践品质。本文风格类似于《网络编程懒人入门》、《脑残式网络编程入门》两个系列，但通俗又不失内涵，简洁又不简陋，非常适合对计算机网络知识有向往但又有惧怕的...

整个暑假去面试，面试了很多家公司（无论是小厂还是大厂）问到的深度不同，网络原理是面试最容易问到的问题，虽然我们在项目中很少去实践它，但是了解其原理，会让我们背后网络通信是如果工作的，既能在面试官面前体现出你的基础是否扎实，也能对以后深入网络这部分学习有更多的了解。

但TCP 协议在创建连接之前需要进行三次握手（如下图 1，更详细原理请见《理论经典：TCP协议的3次握手与4次挥手过程详解》），如果需要提高数据交互的安全性，既增加传输层安全协议（TLS），还会增加更多的更多握手次数（如下图 2）。

大多数回答都是说请求响应之后 DOM 怎么被构建，被绘制出来。但是你有没有想过，收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？

关于微信内部正在使用的网络层封装库Mars开源的消息，1个多月前就已满天飞（参见《微信Mars：微信内部正在使用的网络层封装库，即将开源》），不过微信团队没有失约，微信Mars 于2016年12月28日正式公开源码（源码地址：[链接]，也可从本文文末的附件下载之，Android版演示程序可以从文末的附件中下载）。

本文的上篇《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》中，我们讨论了在线实时消息的投递可以通过应用层的确认、发送方的超时重传、接收方的去重等手段来保证业务层面消息的不丢不重。

对于高性能即时通讯技术（或者说互联网编程）比较关注的开发者，对C10K问题（即单机1万个并发连接问题）应该都有所了解。“C10K”概念最早由Dan Kegel发布于其个人站点，即出自其经典的《The C10K problem（英文PDF版、中文译文）》一文。

作为应用层开发人员，接触最多的网络协议通常都是传输层的TCP（与之同处一层的另一个重要协议是UDP协议），但对于IP协议，对于应用程序员来说更多的印象还是IP地址这个东西，再往深一点也就很难说的清楚。

很多人认为，TCP协议自身先天就有KeepAlive机制，为何基于它的通讯链接，仍然需要在应用层实现额外的心跳保活？本文将从移动端IM实践的角度告诉你，即使使用的是TCP协议，应用层的心跳保活仍旧必不可少。

有过移动端开发经历的开发者都深有体会：移动端IM的开发，与传统PC端IM有很大的不同，尤其无线网络的不可靠性、移动端硬件设备资源的有限性等问题，导致一个完整的移动端IM架构设计和实现都充满着大量的挑战。本文将简述移动端IM最重要的架构设计和通信协议选择方面的坑点，希望为IM开发者同行带来些许启发。（本文同步...