TCP协议缺陷不完全记录

标签: tcp 协议 完全 | 发表时间:2015-05-07 14:56 | 作者:nieyong
出处:http://www.blogjava.net/

零。前言

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,那么慢启动改动与否都是无关紧要的事情了。

进阶阅读:

三。线头阻塞(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的多个网络增强网络吞吐量。

现状是:

  1. 目前只有IOS 7以及后续版本支持
  2. Linux kernel 3.10实验分支上可以看到其支持身影,但何时合并到主分支上,暂时未知

进阶阅读: A closer look at the scientific literature on Multipath TCP

八。TCP缓存膨胀

当路由器接收到的数据包超越其队列长度时,一般会随机丢包,以减少膨胀。针对上层应用程序而言,延迟增加,或误认为数据丢失,或连接丢失等。

遇到这种情况,一般建议快速发包,以避免丢失的数据部分。内核层面今早升级到最新版,不低于3.6即可。

进阶阅读: Bufferbloat

九。TCP不是绝对可靠的

  1. IP和TCP协议在头部都会有check sum错误校验和机制,16位表示,反码相加,结果求反,具体可参考 TCP校验和的原理和实现。一般错误很轻松可检测出来,但遇到两个16位数字相加后结果不变的情况就一筹莫展了
  2. 以太网帧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校验。

  3. 路由器可能偶然出现硬件/内存故障导致收发IP报文出现多bit/单bit的反转或双字节交换,这个反转如果发生在payload区,那么无法用链路层、网络层、传输层的check sum查出来,只能通过应用层的check sum来检测。因此建议应用层要设法添加校验数据功能。

  4. 大文件下载添加校验保证数据完整性,一般采用MD5,也用于防止安全篡改

参考资料:

十。小结

在这个满世界都是TCP的环境下,要想对TCP动大手术,这个是不太可能的,因为它已经固化到已有的系统内核和固件中。比如升级终端(比如Android/IOS等)系统/固件,Linux服务器内核,中间设备/中介设备(如路由器等),这是一个浩大工程,目前看也不现实。

TCP位于系统内核层,内核空间的升级、修复,最为麻烦。服务器端升级还好说一些,用户终端系统的升级那叫一个难。用户空间/用户核的应用升级、改造相对比来说可控性强,基于此Google专家们直接在UDP协议上进行构建、并且运行在用户空间的QUIC协议,综合了UDP的轻量和TCP的可靠性,是一个比较新颖的方向。

若是对以后底层传输协议有所期望的话:

  • 在用户空间(用户核)出现可以定制的协议,类似于QUIC
  • 传统的TCP/UDP可以运行在用户空间,直接略过内核
  • 完整协议栈以静态链接库形式提供给上层应用
  • 上层应用可以在编译、打包的时包含其所依赖协议栈静态链接库so文件
  • dpdk/netmap等Packet IO框架 + 用户空间协议堆栈,数据将从网卡直接送达上层应用
  • Linux内核重要性降低,常规的SSH系统维护

虽然TCP存在这样、那样的问题,但目前还是无法绕过的网络基础设施,但稍微明白一些不足的地方,或许会对我们当前使用的现状有所帮助。



nieyong 2015-05-07 14:56 发表评论

相关 [tcp 协议 完全] 推荐:

TCP协议缺陷不完全记录

- - BlogJava-首页技术区
TCP自从1974年被发明出来之后,历经30多年发展,目前成为最重要的互联网基础协议. 有线网络环境下,TCP表现的如虎添翼,但在移动互联网和物联网环境下,稍微表现得略有不足. 移动互联网突出特性不稳定:信号不稳定,网络连接不稳定. 虽然目前发展到4G,手机网络带宽有所增强,但因其流动特性,信号也不是那么稳定:坐长途公交车,或搭乘城铁时,或周边上网密集时等环境,现实环境很复杂.

TCP协议通讯流程

- - 操作系统 - ITeye博客
服务器调用socket()、bind()、listen()完成初始化后,调用accept()阻塞等待,处于监听端口的状态,客户端调用socket()初始化后,调用connect()发出SYN段并阻塞等待服务器应答,服务器应答一个SYN-ACK段,客户端收到后从connect()返回,同时应答一个ACK段,服务器收到后从accept()返回.

MQTT协议笔记之mqtt.io项目TCP协议支持

- - BlogJava-首页技术区
MQTT定义了物联网传输协议,其标准倾向于原始TCP实现. 构建于TCP的上层协议堆栈,诸如HTTP等,在空间上多了一些处理路径,稍微耗费了CPU和内存,虽看似微乎其微,但对很多处理能力不足的嵌入式设备而言,选择原始的TCP却是最好的选择. 但单纯TCP不是所有物件联网的最佳选择,提供构建与TCP基础之上的传统的HTTP通信支持,尤其是浏览器、性能富裕的桌面涉及领域,还是企业最 可信赖、最可控的传输方式之一.

TCP之三:TCP/IP协议中backlog参数(队列参数) - duanxz - 博客园

- -
TCP洪水攻击(SYN Flood)的诊断和处理》. TCP/IP协议中backlog参数》. TCP建立连接是要进行三次握手,但是否完成三次握手后,服务器就处理(accept)呢.   backlog其实是一个连接队列,在Linux内核2.2之前,backlog大小包括半连接状态和全连接状态两种队列大小.

使用haproxy做TCP协议负载均衡

- - 行业应用 - ITeye博客
之前有使用过Nginx进行tcp负载均衡,但后来发现nginx总是会跟服务端进行断开连接、断开连接的操作,所以选择一下别的代理进行处理. 写这个的时候,我也只是把haproxy运行成功,而且简单测试了一下,具体适不适合自己的系统还有待测试. 1.下载haproxy:. 从主页下载,我使用的是最新版本,haproxy-1.4.24.tar.gz.

[转]TCP协议疑难杂症全景解析

- - 忘我的追寻
1) 本文以TCP的发展历程解析容易引起混淆,误会的方方面面. 2) 本文不会贴大量的源码,大多数是以文字形式描述,我相信文字看起来是要比代码更轻松的. 3) 针对对象:对TCP已经有了全面了解的人. 因为本文不会解析TCP头里面的每一个字段或者3次握手的细节,也不会解释慢启动和快速重传的定义. 4) 除了《TCP/IP详解》(卷一,卷二)以及《Unix网络编程》以及Linux源代码之外,学习网络更好的资源是RFC.

视频面试传输协议到底是 TCP 还是 UDP

- - IT瘾-dev
又是一年一度的秋季校招开始了,以往的校招各个公司都会在公司现场或者学校现场安排学生进行现场面试. 但是今年由于疫情的原因,不允许让同学在现场进行一个面试,所以今年的面试形式就从线下转到了线上,面试形式的转变,但是我们考核学生的方式依旧没有转变. 校招的同学和社招的同学有很大的不同,他们没有丰富的工作经验,没有太多的项目经历,那么我们如何去衡量一个校招的同学呢.

tcp/ip调优

- Lucseeker - 在路上
在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接. 第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SEND状态,等待服务器确认;. 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;.

浅谈TCP优化

- - 火丁笔记
很多人常常对 TCP优化有一种雾里看花的感觉,实际上只要理解了TCP的运行方式就能掀开它的神秘面纱. Ilya Grigorik 在「 High Performance Browser Networking」中做了很多细致的描述,让人读起来醍醐灌顶,我大概总结了一下,以期更加通俗易懂. 传输数据的时候,如果发送方传输的数据量超过了接收方的处理能力,那么接收方会出现丢包.

TCP报文结构

- - 互联网 - ITeye博客
一、TCP报文结构如下:.  固定首部长度为20字节,可变部分0~40字节,各字段解释:. source port number:源端口,16bits,范围0~65525. target port number:目的端口,16bits,范围同上. sequence number:数据序号,32bits,TCP 连接中传送的数据流中的每一个字节都编上一个序号.