零。前言
tcp自从1974年被发明出来之后，历经30多年发展，目前成为最重要的互联网基础协议。有线网络环境下，tcp表现的如虎添翼，但在移动互联网和物联网环境下，稍微表现得略有不足。
移动互联网突出特性不稳定：信号不稳定，网络连接不稳定。虽然目前发展到4g，手机网络带宽有所增强，但因其流动特性，信号也不是那么稳定：坐长途公交车，或搭乘城铁时，或周边上网密集时等环境，现实环境很复杂。
以下讨论基于linux服务器环境，假定环境为移动互联网环境。记录我目前所知tcp的一些不足，有所偏差，请给与指正。
一。三次握手
在确定传递数据之前需要三次握手，显然有些多余，业界提出了tcp fast open (tfo)扩展机制，两次握手之后就可以发送正常业务数据了。但这需要客户端和服务器端内核层面都支持才行： linux内核3.6客户端，3.7支持服务器端。
进阶阅读：
二。慢启动
一次的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，那么慢启动改动与否都是无关紧要的事情了。
进阶阅读：
三。线头阻塞(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"的通知。
四。四次摆手
两端连接成功建立之后，需要关闭时，需要产生四次交互，这在移动互联网环境下，显得有些多余。快速关闭，快速响应，冗余交互导致网络带宽被占用。
五。确认机制通知到上层应用？
这是一个比较美好的愿望，上层应用在调用内核层接口发送大段数据，内核完成发送并且收到对方完整确认，然后通知上层应用已经发送成功，那么在一些环境下，可以节省不少业务层面交互步骤。
六。nat网关超时
ipv4有限，局域网环境借助于nat路由设备扩展了接入终端设备的数量。当建立一个tcp长连接时，nat设备需要维护一个内部终端连接外部服务器所使用的内部ip:port与出去的ip:port映射对应关系。这个关系需要维护，比较耗费内存资源，有超时定时器清理，否则会导致内存撑爆。
不同nat设备超时值不一样，因此才需要心跳辅助，确保经过nat设备的连接一直保持，避免因过长的时间被踢掉。比如针对中国移动网络连接持久时间一般设置为不超过5分钟。各种网络略有差异，引入智能心跳机制比较合适。
七。终端ip漫游
手机终端经常在2g/3g/4g和wifi之间切换，导致ip地址频繁发生改变。这样造成的后果就是已有的网络请求-响应被放弃和终止，需要人工干预或重新发起请求，存在资源浪费现象。
支持multipath tcp的终端设备，可以同时利用 2g/3g/4g 和 wifi 建立mutlpath连接，通过多点优化网络下载，且互为备份。可以很好解决多个网络共存的情况下，一个网络中断不会导致全局请求处理中断，在设备的连接稳定和可靠性方面有所增强。
当然，服务器之间也可以利用multipath tcp的多个网络增强网络吞吐量。
现状是：
- 目前只有ios 7以及后续版本支持
- linux kernel 3.10实验分支上可以看到其支持身影，但何时合并到主分支上，暂时未知
进阶阅读：
八。tcp缓存膨胀
当路由器接收到的数据包超越其队列长度时，一般会随机丢包，以减少膨胀。针对上层应用程序而言，延迟增加，或误认为数据丢失，或连接丢失等。
遇到这种情况，一般建议快速发包，以避免丢失的数据部分。内核层面今早升级到最新版，不低于3.6即可。
进阶阅读：
九。tcp不是绝对可靠的
- ip和tcp协议在头部都会有check sum错误校验和机制，16位表示，反码相加，结果求反，具体可参考 。一般错误很轻松可检测出来，但遇到两个16位数字相加后结果不变的情况就一筹莫展了
-
以太网帧crc32校验一般情况下都很ok，但可能遇到两端隔离多个路由器情况下，就有可能出现问题，比如陈硕老师提供的一张图：
上图中client向server发了一个tcp segment，这个segment先被封装成一个ip packet，再被封装成ethernet frame，发送到路由器（图中消息a）。router收到ethernet frame (b)，转发到另一个网段(c)，最后server收到d，通知应用程序。ethernet crc能保证a和b相同，c和d相同；tcp header check sum的强度不足以保证收发payload的内容一样。另外，如果把router换成nat，那么nat自己会构造c（替换掉源地址），这时候a和d的payload不能用tcp header checksum校验。
-
路由器可能偶然出现硬件/内存故障导致收发ip报文出现多bit/单bit的反转或双字节交换，这个反转如果发生在payload区，那么无法用链路层、网络层、传输层的check sum查出来，只能通过应用层的check sum来检测。因此建议应用层要设法添加校验数据功能。
-
大文件下载添加校验保证数据完整性，一般采用md5，也用于防止安全篡改
参考资料：
- paper《when the crc and tcp checksum disagree》
十。小结
在这个满世界都是tcp的环境下，要想对tcp动大手术，这个是不太可能的，因为它已经固化到已有的系统内核和固件中。比如升级终端（比如android/ios等）系统/固件，linux服务器内核，中间设备/中介设备（如路由器等），这是一个浩大工程，目前看也不现实。
tcp位于系统内核层，内核空间的升级、修复，最为麻烦。服务器端升级还好说一些，用户终端系统的升级那叫一个难。用户空间/用户核的应用升级、改造相对比来说可控性强，基于此google专家们直接在udp协议上进行构建、并且运行在用户空间的quic协议，综合了udp的轻量和tcp的可靠性，是一个比较新颖的方向。
若是对以后底层传输协议有所期望的话：
- 在用户空间（用户核）出现可以定制的协议，类似于quic
- 传统的tcp/udp可以运行在用户空间，直接略过内核
- 完整协议栈以静态链接库形式提供给上层应用
- 上层应用可以在编译、打包的时包含其所依赖协议栈静态链接库so文件
- dpdk/netmap等packet io框架 用户空间协议堆栈，数据将从网卡直接送达上层应用
- linux内核重要性降低，常规的ssh系统维护
虽然tcp存在这样、那样的问题，但目前还是无法绕过的网络基础设施，但稍微明白一些不足的地方，或许会对我们当前使用的现状有所帮助。