（一）、前言
　　TCP自从1974年被发明出来之后，历经30多年发展，目前成为重要的互联网基础协议。有线网络环境下，TCP表现的如虎添翼，但在移动互联网和物联网环境下，稍微表现得略有不足。
　　移动互联网突出特性不稳定：信号不稳定，网络连接不稳定。虽然目前发展到4G，手机网络带宽有所增强，但因其流动特性，信号也不是那么稳定：坐长途公交车，或搭乘城铁时，或周边上网密集时等环境，现实环境很复杂。
　　以下讨论基于Linux服务器环境，假定环境为移动互联网环境。记录我目前所知TCP的一些不足，有所偏差，请给与指正。
　　（二）、三次握手
　　在确定传递数据之前需要三次握手，显然有些多余，业界提出了TCP Fast Open (TFO)扩展机制，两次握手之后可以发送正常业务数据了。但这需要客户端和服务器端内核层面都支持才行： Linux内核3.6客户端，3.7支持服务器端。

　　进阶阅读：TCP Fast Open: expediting web services
　　（三）、慢启动
　　一次的HTTP请求，应用层发送较大HTML页面的数据，需要经过若干个往返循环时间(Round-Trip Time)之后，拥塞窗口才能够扩展到大适合数值，中间过程颇为冗余。这个参数直接关系着系统吞吐量，吞吐量大了，系统延迟小了。但设置成多大，需要根据业务进行抉择。
　　3.0内核之前初始化拥塞窗口(initcwnd)大小为3。一个已建立连接初始传输数据时可传递3个MSS，若1个MSS为1400那么一次性可传递4K的数据，若为10，一次性可传递13K的数据。
　　谷歌经过调研，建议移动互联网WEB环境下建议initcwnd设置成10，linux内核3.0版本之后默认值为10。遇到较低内核，需要手动进行设置。
　　若是局域网环境有类似大数据或文件的传输需求，可以考虑适当放宽一些。
　　若长连接建立之后传输的都是小消息，每次传输二进制不到4K，那么慢启动改动与否都是无关紧要的事情了。
　　进阶阅读：
　　Tuning initcwnd for optimum performance
　　Optimizing Your Linux Stack for Maximum Mobile Web Performance
　　An Argument for Increasing TCP's Initial Congestion Window
　　（四）、线头阻塞(Head-of-line blocking， HOL)
　　TCP协议数据传输需要按序传输，可以理解为FIFO先进先出队列，当前面数据传输丢失后，后续数据单元只能等待，除非已经丢失的数据被重传并确认接收以后，后续数据包才会被交付给客户端设备，这是所谓的线头（HOL，head-of-line blocking）阻塞。比较浪费服务器带宽又降低了系统性能，不高效。

　　1. 多路复用不理想
　　HTTP/2提出的业务层面多路复用，虽然在一定程度上解决了HTTP/1.*单路传输问题，但依然受制于所依赖的TCP本身线头阻塞的缺陷。构建于TCP上层协议的多路复用，一旦发生出现线头阻塞，需要小心对待多路的业务数据发送失败问题。
　　2. TCP Keepalive机制失效
　　理论上TCP的Keepalive保活扩展机制，在出现线头阻塞的时候，发送不出去被一直阻塞，完全失效。
　　类似于NFS文件系统，一般采用双向的TCP Keepalive保活机制，用以规避某一端因线头阻塞出现导致Keepalive无效的问题，及时感知一端存活情况。
　　3. 线头阻塞超时提示
　　数据包发送了，启动接收确认定时器，超时后会重发，重发依然无确认，后续数据会一直堆积到待发送队列中，这里会有一个阻塞超时，算法很复杂。上层应用会接收到来自内核协议栈的汇报"No route to host"的错误信息，默认不大于16分钟时间。在服务器端（没有业务心跳支持的情况下）发送数据前把终端强制断线，顺便结合TCPDUMP截包，等15分钟左右内核警告"EHOSTUNREACH"错误，应用层面可以看到"No route to host"的通知。
　　（五）、四次摆手
　　两端连接成功建立之后，需要关闭时，需要产生四次交互，这在移动互联网环境下，显得有些多余。快速关闭，快速响应，冗余交互导致网络带宽被占用。