TCP之网络优化

标签: tcp 网络 优化 | 发表时间:2021-06-10 08:12 | 作者:oneman0517
出处:https://juejin.cn/backend

上一篇文章我提到了Nagle算法,是为了解决报头大数据小从而导致网络利用率低的问题,这其实会带来新的问题。除此之外我们一起来看看tcp还会有什么优化策略呢!本文纯属学习记录,不完善或错误之处若指正将不胜感激。如有被误导的朋友,望海涵。


首先我们先康康Nagle算法

Nagle算法规则

  • (1)如果包长度达到MSS,则允许发送;
  • (2)如果该包含有FIN,则允许发送;
  • (3)设置了TCP_NODELAY选项,则允许发送;
  • (4)未设置TCP_CORK选项时,若所有发出去的小数据包(包长度小于MSS)均被确认,则允许发送;
  • (5)上述条件都未满足,但发生了超时(一般为200ms),则立即发送。

延迟ACK

ACK机制中,在接收方收到一个包之后会先检查是否需要立即回应ACK,否则进入延迟ACK逻辑。 参考
优点显而易见,提高了网络信道的利用率

当Nagle遇见延迟ACK

假想一个场景 MSS为8个中文字(最大报文长度)
甲需要发送两个应用层报文给乙——“你好”!“我是甲”。显然这两个报文都是不足8的,但是由于“你好”满足Nagel的第4条规则所以会第一时间发送出去,由于ACK延迟,甲迟迟收不到乙的确认。于是等到超时发送。
这会产生一个明显的延迟
解决

  • 关闭Nagle算法,使用TCP套接字选项TCP_NODELAY可以关闭套接字选项(不推荐,有更多的优化策略)
  • 使用writev,而不是两次调用write,单个writev调用会使tcp输出一次而不是两次,只产生一个tcp分节,这是首选方法

流量控制之滑动窗口

滑动窗口是为了平衡发送方和接收方速率不匹配,发送窗口在连接建立时由双方商定。但在通信的过程中,一般由接收方反馈本身的缓冲区大小从而动态调节发送窗口(缓冲区)大小

拥塞控制

为了方便,我们假设主机A给主机B传输数据
我们知道,两台主机在传输数据包的时候,如果发送方迟迟没有收到接收方反馈的ACK,那么发送方就会认为它发送的数据包丢失了,进而会重新传输这个丢失的数据包。 然而实际情况有可能此时有太多主机正在使用信道资源,导致网络拥塞了,而A发送的数据包被堵在了半路,迟迟没有到达B。这个时候A误认为是发生了丢包情况,会重新传输这个数据包。
结果就是不仅浪费了信道资源,还会使网络更加拥塞。因此,我们需要进行拥塞控制

慢开始和拥塞避免

  • 在建立连接之后是如何确定拥塞窗口的大小?(拥塞窗口和滑动窗口注意区别)
    • 第一种策略,第一次发送一个包,如果没有丢失就+1,以此类推
    • 第二种策略,第一次发送一个包,如果没有丢失就乘以2,以此类推
    实际上第一种方式增长过于缓慢,难以快速适应网络拥塞情况,而第二种方式指数型增长,很容易到达拥塞阈值。
    所以二者取其长,在前期使用指数增长,当到达某一个数值之后进行线性增长
    但是无论是指数增长还是线性增长最终都会到达一个MAX值,此时会重新以1开始启动并把阈值设置为MAX/2
    我们把确定拥塞窗口大小的过程中指数增长阶段称之为 慢开始,线性增长阶段称之为 拥塞避免

快速重传与快速恢复

前面说过了,当出现网络拥塞时会重启慢开始过程

  • 怎么判断网络拥塞?
    • 当网络拥塞时,会出现大量的丢包
  • 超时重发(丢包)一定是网络拥塞吗?
    • 网络拥塞会导致大量的包触发超时重发事件。而当一个单独的包出现损坏或者丢包时,也会导致超时重发,所以超时重发不一定是网络拥塞
  • 如何判断超时重发的原因
    • 网络拥塞会导致大量的丢包
    • 单个的丢包,由于延迟ACK规则,后序到达的每到达一个包,接收端都会回复相同的ACK。故当发送方接收到三个相同的ACK时,表明发生了单个的丢包

单个丢包事件,当发送方接收到三个相同的ACK时,此时发送方不必等待序号为ACK-1包的超时,会立即重发。并把当前的阈值设置为MAX,新的阈值为MAX/2,以 拥塞窗口 = MAX/2 进行增长
重发阶段我们称之为 快速重传 ,窗口参数的调整阶段称之为 快速恢复

相关 [tcp 网络 优化] 推荐:

TCP之网络优化

- - 掘金 后端
上一篇文章我提到了Nagle算法,是为了解决报头大数据小从而导致网络利用率低的问题,这其实会带来新的问题. 除此之外我们一起来看看tcp还会有什么优化策略呢. 本文纯属学习记录,不完善或错误之处若指正将不胜感激. 首先我们先康康Nagle算法. (1)如果包长度达到MSS,则允许发送;. (2)如果该包含有FIN,则允许发送;.

浅谈TCP优化

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

linux 系统优化tcp连接

- - 操作系统 - ITeye博客
最近几天 系统不太稳定, tcp/ip 连接超级多,估计应用服务器到极限了. 网上看到了一片好文,随抄在这里了,感谢原作者. 原文连接: http://blog.renhao.org/2010/07/setup-linux-kernel-tcp-settings/#more-162. 提高服务器的负载能力,是一个永恒的话题.

高性能网络编程7--tcp连接的内存使用

- - CSDN博客互联网推荐文章
当服务器的并发TCP连接数以十万计时,我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣. socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存,linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用,但这些配置看名字却有些互相冲突、概念模糊的感觉,如下(sysctl -a命令可以查看这些配置):.

记一次关于TIME_WAIT TCP连接数的性能优化

- - Juven Xu
一天下午3点多,我们的OPS打电话给我(你懂的,OPS打电话过来不会是请你喝咖啡),我连忙接起电话,电话那头的声音很急迫:“content集群有报警,CPU负载已经到了50多,你快过来一起看看”,我挂了电话连忙赶过去,OPS坐在另一幢楼的同一层,好在两幢楼是相连的,过去很方便. 边走我心里边嘀咕,content集群实际上是一个反向代理,上面配置了上百条apache http url rewrite 规则,每条规则的作用就是把一个url路径转换成另外一个url路径,发送到某个后端的集群上,然后把返回结果转出去,几乎没有计算量,不应该有高负载啊.

优化Linux下的内核TCP参数来提高服务器负载能力

- - Linux - 操作系统 - ITeye博客
提高服务器的负载能力,是一个永恒的话题. 在一台服务器CPU和内存资源额定有限的情况下,最大的压榨服务器的性能,是最终的目的. 要提高Linux系统下的负载能力,可以先启用Apache的Worker模式(参考我写的《Ubuntu下配置Apache的Worker模式》一文),来提高单位时间内的并发量.

tcp/ip调优

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

TCP报文结构

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

TCP 状态变化

- - 互联网 - ITeye博客
关闭socket分为主动关闭(Active closure)和被动关闭(Passive closure)两种情况. 前者是指有本地主机主动发起的关闭;而后者则是指本地主机检测到远程主机发起关闭之后,作出回应,从而关闭整个连接. 将关闭部分的状态转移摘出来,就得到了下图:. 通过图上,我们来分析,什么情况下,连接处于CLOSE_WAIT状态呢.

移动端网络优化

- - Trinea
介绍下针对移动端的网络优化,不限于 Android,同样适用于 iOS 和 H5. 这篇文章首发在微信公众号 codekk. 本文为性能优化系列第四篇,目前性能调优专题已完成以下部分:. 性能优化总纲——性能问题及性能调优方式. 性能优化第四篇——移动网络优化. 性能优化第三篇——代码优化. 性能优化第二篇——布局优化.