TCP优化指导

TCP优化指导

翻译了一段优化TCP得文档,英文原文见:
http://dsd.lbl.gov/TCP-tuning/background.html
http://dsd.lbl.gov/TCP-tuning/linux.html

以下是如何最大化TCP WAN吞吐量的技术摘要。

TCP
使用一种称为“拥塞窗口”的机制来决定在同一时间能够传送多少数据包,拥塞窗口越大,吞吐量越。TCP使用“slow start”和“congestion avoidance”算法来决定拥塞窗口的大小。最大的拥塞窗口大小与内核分配给每个socket的缓冲空间数量有关。对于每个socket都有一个默认的缓冲大小,这个大小可以改变,在打开这个socket之前,应用程序可以使用系统库调用更改这个大小。另外,内核还会强制指定一个最大的缓冲数值。The buffer size can be adjusted for both the send and receive ends of the socket.

获得最大的吞吐量的关键是针对你所使用的连接类型最佳化TCP接收和发送的socket缓冲区的大小。如果缓冲太小,那么TCP拥塞窗口永远不会全部打开。如果接收缓冲过大,TCP的流量控制会失效,发送方的流量会造成接收方的溢出,从而导致TCP窗口关闭,这种问题通常发生在发送方主机比接收方主机快的情况下。如果有足够的内存,那么很大的窗口在发送一方不会产生太大的问题。

最佳的缓冲大小应该是 链路带宽*延时乘积的两倍

   buffer size = 2 * bandwidth * delay

使用ping 可以获得延时的大小,使用类似pathrate的工具可以获得端到端的容量(链路中最慢的一跳的带宽)。因为ping可以给出round trip
time (RTT)
,通常可以使用下面的公式替代上边的那个:

   buffer size = bandwidth * RTT

举例来说,如果ping值是50ms,端到端的网络全部由100M以太网组成,那么TCP缓冲的大小应该是:

   0.05 sec * (100 Mbits / 8 bits) = 625 KBytes

你需要了解的TCP设置有两个,一个是 default TCP发送和接收的缓冲大小,另一个是maximum TCP发送和接收的缓冲大小。当前的类unix系统的maximum TCP缓冲大小只有256KB!关于如何调整maximum TCP缓冲的大小,请参考不同的操作系统设置方法。注意,不要将default 缓冲值设置大于128KB,因为这可能会降低LAN的性能。因此你需要在发送者和接收者两边都使用Unix setsockopt调用来设置缓冲区的大小。

====================================================================
Linux
系统的调节

因为2.4和2.6内核有很大的不同,因此我们首先调整两者相同的部分:
将下边的内容加入/etc/sysctl.conf,然后运行 "sysctl -p"

 # increase TCP max buffer size
 net.core.rmem_max = 16777216
 net.core.wmem_max = 16777216
 # increase Linux autotuning TCP buffer limits
 # min, default, and max number of bytes to use
 net.ipv4.tcp_rmem = 4096 87380 16777216
 net.ipv4.tcp_wmem = 4096 65536 16777216

注: 请保持tcp_mem不动,默认值可以很好的工作。

另外一个可以增加TCP吞吐量的参数是增加网卡的队列大小,参考以下命令:

    ifconfig eth0 txqueuelen 1000

我曾经在一条很长而且很快的线路上做了上边的修改,结果带宽增加了近8倍!!当然这仅仅对于那些使用GigaEthernet连接的主机来说是个好主意,而且可能会有副作用,例如uneven sharing between multiple streams。

Linux 2.4

Starting with Linux 2.4, Linux has implemented a sender-side autotuning mechanism, so that setting the opitimal buffer size on the sender is not needed. This assumes you have set large buffers on the recieve side, as the sending buffer will not grow beyond the size of the recieve buffer.
However, Linux 2.4 has some other strange behavior that one needs to be aware of. For example: The value for ssthresh for a given path is cached in the routing table. This means that if a connection has has a retransmition and reduces its window, then all connections to that host for the next 10 minutes will use a reduced window size, and not even try to increase its window. The only way to disable this behavior is to do the following before all new connections (you must be root):

      sysctl -w net.ipv4.route.flush=1

More information on various tuning parameters for Linux 2.4 are available in the Ipsysctl tutorial .


Linux 2.6

Starting in Linux 2.6.7 (and back-ported to 2.4.27), BIC TCP is part of the kernel, and enabled by default. BIC TCP helps
recover quickly from packet loss on high-speed WANs, and appears to work quite well. A BIC implementation bug was discovered, but this was fixed in Linux 2.6.11, so you should upgrade to this version or higher.

Linux 2.6 also includes and both send and receiver-side automatic buffer tuning (up to the maximum sizes specified above).

There is also a setting to fix the ssthresh caching weirdness described above.

There are a couple additional sysctl settings for 2.6:

  # don't cache ssthresh from previous connection
  net.ipv4.tcp_no_metrics_save = 1
  # recommended to increase this for 1000 BT or higher
  net.core.netdev_max_backlog = 2500
  # for 10 GigE, use this
  # net.core.netdev_max_backlog = 30000   

Starting with version 2.6.13, Linux supports pluggable congestion control algorithms . The congestion control algorithm used is set using the sysctl variable net.ipv4.tcp_congestion_control, which is set to Reno by default. (Apparently they decided that BIC was not quite ready for prime time.) The current set of congestion control options are:

   * reno: Traditional TCP used by almost all other OSes. (default)
   * bic: BIC-TCP
   * highspeed: HighSpeed TCP: Sally Floyd's suggested algorithm
   * htcp: Hamilton TCP
   * hybla: For satellite links
   * scalable: Scalable TCP
   * vegas: TCP Vegas
   * westwood: optimized for lossy networks

For very long fast paths, I suggest trying HTCP or BIC-TCP if Reno is not is not performing as desired. To set this, do the following:

   sysctl -w net.ipv4.tcp_congestion_control=htcp

More information on each of these algorithms and some results can be found here .

Note: Linux 2.6.11 and under has a serious problem with certain Gigabit and 10 Gig ethernet drivers and NICs that support "tcp segmentation offload", such as the Intel e1000 and ixgb drivers, the Broadcom tg3, and the s2io 10 GigE drivers. This problem was fixed in version 2.6.12. A workaround for this problem is to use ethtool to disable segmentation offload:
    ethtool -K eth0 tso off
This will reduce your overall performance, but will make TCP over LFNs far more stable.

More information on tuning parameters and defaults for Linux 2.6 are available in the file ip-sysctl.txt, which is part of
the 2.6 source distribution.

And finally a warning for both 2.4 and 2.6: for very large BDP paths where the TCP window is > 20 MB, you are likely to hit the Linux SACK implementation problem. If Linux has too many packets in flight when it gets a SACK event, it takes too long to located the SACKed packet, and you get a TCP timeout and CWND goes back to 1 packet. Restricting the TCP buffer size to about 12 MB seems to avoid this problem, but clearly limits your total throughput. Another solution is to disable SACK.


Linux 2.2

If you are still running Linux 2.2, upgrade! If this is not possible, add the following to /etc/rc.d/rc.local

  echo 8388608 > /proc/sys/net/core/wmem_max  
  echo 8388608 > /proc/sys/net/core/rmem_max
  echo 65536 > /proc/sys/net/core/rmem_default
  echo 65536 > /proc/sys/net/core/wmem_default

====================================================================
Windows
系统的调节

使用注册表编辑器修改下边的键值

# turn on window scale and timestamp option
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323=3
# set default TCP window size (default = 16KB)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=131400
# and maybe set this too: (default = not set )
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=16777216

进一步信息请参考:
http://support.microsoft.com/default.aspx?scid=kb;en-us;314053
http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
http://www.speedguide.net/read_articles.php?id=157
====================================================================
FreeBSD
系统的调节

将下面的内容添加到/etc/sysctl.conf中,然后重启。

   kern.ipc.maxsockbuf=16777216
   net.inet.tcp.rfc1323=1
   net.inet.tcp.sendspace=1048576
   net.inet.tcp.recvspace=1048576

进一步信息请参考FreeBSD Network Tuning Performance Tuning Guide

http://www.wormulon.net/files/pub/FreeBSD_Network_Tuning_-_slides.pdf

 

 

Windows系统下的TCP参数优化 续上文:TCP连接的状态与关闭方式,及其对Server与Client的影响   通常会采用修改注册表的方式改进Windows的系统参数。下面将为大家介绍Windows系统下的TCP参数优化方式,适用于Windows 2003、Windows XP、Windows 7以及Server版。对于具体的系统环境与性能需求,优化方式会有所差异,效果也不尽相同,仅是个人的建议。所有的优化操作都通过修改注... 阅读详情

相关推荐

TCP小包优化

接收方窗口大小通知 在《TCP滑动窗口与缓冲区》的博文中说过接收方会通知发送方滑动窗口的大小,但是如果应用程序每调用read函数读出一些数据,就通知发送方,那么网络中将会有大量的只通知对方窗口大小的报文,而每个TCP报文都会添加几十字节的头部信息,也就是说这个报文的有效负载非常低,网络带宽将浪费在这些小报文上。实际上RFC有优化的,不会缓冲区一变大,就通知对方接收窗口大小的,很多情况下是同数据报文或者ACK报文一块通知的。 ACK应答优化 TCP是可靠连接的,每个数据报文都得收到对方的ACK应答,才能从发送

qq_32680371的博客 1897

如何设置TCP参数,提升系统性能

前言 TCP 性能的提升不仅考察 TCP 的理论知识,还考察了对于操作系统提供的内核参数的理解与应用。 TCP 协议是由操作系统实现,所以操作系统提供了不少调节 TCP 的参数。 Linux TCP 参数 如何正确有效的使用这些参数,来提高 TCP 性能是一个不那么简单事情。我们需要针对 TCP 每个阶段的问题来对症下药,而不是病急乱投医。 接下来,将以三个角度来阐述提升 TCP 的策略,分别是: TCP 三次握手的性能提升; TCP 四次挥手的性能提升; TCP 数

闪电小子 2615

tcp网络优化工具

TCP Optimizer 是一款简单易用的网络调整优化工具,无需安装,只需以管理员身份运行即可。软件包括网络参数调整、提示和推荐值,备份和还原当前网络设置,重置 TCP/IP,重置 Winwock 等功能,可最大程度的避免因错误调整后导致的网络问题。 该程序可帮助新手和高级用户在 Windows 中调整相关的 TCP/IP 参数,使您可轻松地将系统调整到使用的互联网连接类型的最佳效果。该工具使用高级算法,而带宽延迟功能可为您的特定连接速度找到最佳的 TCP 窗口。它提供了对所有相关 TCP/IP 参数(例如 MTU、RWIN)甚至包括 QoS 和 ToS/区分服务优先级等高级参数的简单轻松的调整。该程序适用于所有当前版本的 Windows,并包含了其他工具,如测试多个主机的平均延迟时间和查找最大可能的数据包大小(MTU)等功能。 TCP Optimizer 的设计目的是针对宽带互联网连接的调整, 但它可帮助您调整任何类型的互联网连接, 从拨号连接到千兆+网络等。 支持系统:Windows 9x/ME/2K/XP/XP-SP2/2k3/Vista/7/2008/8/8.1/10/2012 Server 此汉化版由 th_sjy 汉化分享。

TCP建立连接、性能优化、拥塞控制总结

吐血整理的TCP相关的知识,包括TCP的连接建立、连接断开,三次握手、四次挥手、还有TCP的包确认、延迟确认、慢启动、滑动窗口、拥塞控制、累计应答等和TCP相关的概念做了一个梳理。有些地方没有深入去写,因为我们毕竟不用自己去实现TCP协议,但是理解TCP的各个机制和算法可以很好的学习到设计一个靠谱的协议需要考虑到的东西是多么细致复杂。 老铁们一次看不完可以加个收藏先

不会骑摩托的程序员不是好的摄影师 1946

华中农业大学C++考试基础练习题

实验一 1 通过日期求某月的天数。 输入日期的年份和月份,求该月有多少天。提示:对于月份为1、3、5、7、8、10、12的月份天数为31,月份为4、6、9、11的月份天数为30,月份为2时要结合年份考虑闰年的情况。 输入描述 输入两个正整数y和m分别表示年份和月份。 输出描述 如果y和m满足条件:1900<=y<3000,0<m<13,输出该月的天数;否则输出“Input error!”。 输入样例 2010 12 输出样例 31 #include"iostream" using n

雨的博客 1万+

Ubuntu 22.04源码编译安装ROS Noetic

Ubuntu 22.04源码编译安装ROS Noetic

Drknown的博客 2万+

TCP 的优化

TCP 三次握手优化/四次挥手优化/窗口优化

Sky_Lee_1的博客 1486

YOLO系列训练时出现loss出现nan值或者测试时P\R\map全部为0值的解决办法(GTX16xx系列显卡大坑)

YOLO系列训练时出现loss出现nan值或者测试时P\R\map全部为0值的解决办法(GTX16xx系列显卡大坑)

weixin_55249340的博客 3万+

tcp网络编程性能优化点

TCP网络编程是网络编程中常见的一种方式,广泛应用于服务器端和客户端开发。为了提高TCP网络程序的性能,需要对程序进行优化。本文将介绍一些常见的TCP网络编程性能优化点。

Where there is life, there is hope. 1029

MTK平台 MT6789 烧录 efuse 3.0 Configuration SOP

=====================生成cert1和cert2 key===============================================生成efuse key相关文件===========================================签名DA==========================================================正常编译。=====================Security3.0 的SOP 说明。

a785722173的博客 2329

SAP-ABAP:SAP系统调优利器:RZ11动态参数修改全指南

SAP系统调优利器:RZ11动态参数修改全指南

baidu_35680696的博客 970

如何进行TCP性能优化

本次和大家聊一下TCP性能优化。 TCP全称为Transmission Control Protocol,每一个IT人士对TCP都有一定了解。TCP协议属于底层协议,对于大部分研发人员来说,这是透明的,无需关心TCP的实现与细节。 不过如果想做深入的性能优化,TCP是绕不过去的一环。要讲TCP性能优化,必须先回顾一下TCP的一些细节。让我们先来看一下TCP的首部格式 TCP报文段的首部格式 TCP报文段首部的前20个字节是固定的,后面有4n字节是根据需要而增加的选项(n是整数)。因此TCP首部的最小长度是

6735

学习STM32的DS18B20温度传感器

该函数首先复位传感器,然后发送跳过ROM命令和转换命令,并等待转换完成。接下来,它再次复位传感器,发送跳过ROM命令和读取温度命令。最后,它读取温度值的最低字节和最高字节,并将其组合成16位温度值。传感器的VCC引脚连接到STM32的3.3V电源,GND引脚连接到GND,而数据引脚连接到任何一个IO引脚。需要注意的是,示例代码中使用了一个简单的延时函数来等待转换完成。实际上,您可能需要使用定时器或其他更精确的延时方法来实现更准确的延时。下面是一个示例代码,演示如何读取DS18B20传感器的温度值。

m0_75244442的博客 1182

TCP的优化方式

tcp_synack_retries 的默认重试次数是 5 次,与客户端重传 SYN 类似,它的重传会经历 1、2、4、8、16 秒,最后一次重传后会继续等待 32 秒,如果服务端仍然没有收到 ACK,才会关闭连接,故共需要等待 63 秒。反之则可以调小重发次数。此时,内核会定时重发FIN 报文,其中重发次数由 tcp_orphan_retries 参数控制(注意,orphan 虽然是孤儿的意思,该参数却不只对孤儿连接有效,事实上,它对所有 FIN_WAIT1 状态下的连接都有效),默认值是 0。

庄小焱 3350

水声信号处理开源算法库最新进展

欢迎关注本专栏,一起探索新世界大家好,我是ZhuChunSHU。985院校硕士毕业,现担任算法研究员一职,热衷于深度学习算法研究与应用。曾获得阿里云天池比赛第三名,CCE比赛第五名,科大讯飞Q比赛第六名。拥有多项发明专利。对机器学习和深度学习拥有自己独到的见解。曾经辅导过若干个非计算机专业的学生进入到算法行业就业。希望和大家一起成长进步。今天继续我们的专栏分享!!!!!!!!!!!!!!!!!!!!水声信号处理是海洋科学与工程领域的核心组成部分,对于水下通信、目标探测、海洋环境监测以及生物声学研究至关重要。

u012133341的博客 1254

一文搞定 ST22 短转储 MEMORY_NO_MORE_PAGING:看懂 SAP Paging 机制,参数 rdisp/PG_SHM 与 rdisp/PG_MAXFS 怎么设才稳

SAP系统MEMORY_NO_MORE_PAGING错误通常源于Paging资源耗尽而非物理内存不足。关键排查点包括:通过ST22确认错误类型,ST02监控Paging使用情况,检查工作进程trace中的"no more free blocks"提示。解决方案建议将rdisp/PG_SHM和rdisp/PG_MAXFS设为相同值(如250000块≈2GB),使Paging完全在内存中运行。同时需优化易耗Paging的代码逻辑,如避免滥用EXTRACT命令和超大内存对象传输。典型案例如月末

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 335

[TCP]TCP 文件传输速度优化

最近写了一个TCP文件传输的C/S程序。Client是windows C++程序。Server是Linux C++(ubuntu)程序,虚拟机。作用是,可以从客户端向服务端传输文件(单线程)。测试用例是一个wireshark抓包文件,文件大小约235m。初始的测试结果发现,传输完文件需要Client debug版:5’42’‘,Client release版: 2’30’'。

zlllc的博客 1589

win10 跳过U8环境检测的IE WebControls.rar

win10 安装u8的时候 提示IE WebControls 不通过,这个工具可以欺骗u8的检查。 跳过U8环境检测的IE WebControls。提示导入失败后,重新检测通过。

TCP优化一:TCP 三次握手的优化

TCP 是面向连接的、可靠的、双向传输的传输层通信协议,所以在传输数据之前需要经过三次握手才能建立连接。 那么,三次握手的过程在一个 HTTP 请求的平均时间占比 10% 以上,在网络状态不佳、高并发或者遭遇 SYN 攻击等场景中,如果不能有效正确的调节三次握手中的参数,就会对性能产生很多的影响。如何正确有效的使用这些参数,来提高 TCP 三次握手的性能,这就需要理解「三次握手的状态变迁」: 客户端和服务端都可以针对三次握手优化性能。主动发起连接的客户端优化相对简单些,而服务端需要监听端口,属于被动连接方,

qq_38658567的博客 2090

ET2012新版免狗免安装绿色软件

ET2012新版免狗免安祖昂绿色软件。,新界面,新视觉,

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

TCP如何优化

当服务端 SYN 半连接队列溢出后,会导致后续连接被丢弃,可以通过 netstat -s 观察半连接队列溢出的情况,如果 SYN 半连接队列溢出情况比较严重,可以通过 tcp_max_syn_backlog、somaxconn、backlog 参数来调整 SYN 半连接队列的大小。可是,默认的滑动窗口最大值只有 64 KB,不满足当今的高速网络的要求,要想提升发送速度必须提升滑动窗口的上限,在 Linux 下是通过设置 tcp_window_scaling 为 1 做到的,此时最大值可高达 1GB。

weixin_44832243的博客 617

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

Linux TCP优化

直接上配置 vi /etc/sysctl.conf --------------start------------- # max open files fs.file-max = 51200 # max read buffer net.core.rmem_max = 67108864 # max write buffer net.core.wmem_max = 67108864 # defaul

killapper的博客 893

TCP优化

客户端:根据网络稳定性和对方服务器的繁忙程度通过参数调整SYN的重传次数服务端:半连接队列大小的调整,syncookie的使用。

2301_81325575的博客 1301

TCP的优化

当发送方接收到接收方的ACK报文后会进入FIN_WAIT2状态.如果调用的是shutdown函数,因为可能还可以继续发送或接收数据,所以发送方可以一直处于FIN_WAIT2状态.但如果调用的是close函数,那么则会处于孤儿连接,因此在FIN_WAIT2状态不能持续太长时间,这个时间有tcp_fin_timeout参数决定,通常是60s(超过60s会直接关闭连接.),和TIME_WAIT一致.WR:关闭连接的写.即不能再发送数据.如果发送缓冲区中有数据会立即发送,并发送一个FIN报文.

weixin_52477733的博客 1206

如何优化TCP三次握手

如果出现了问题,先用netstat命令查看是哪个握手阶段出现了问题,再来对症下药。

moriaaa的博客 291

TCP连接及其优化

作为一个后端程序员,网络连接这块是一个绕不过的砍,当你在做服务器优化的时候,网络优化也是其中一环,那么作为网络连接中最基础的部分-TCP连接你了解吗?今天我们来仔细看看这个部分。 TCP建立连接-三次握手 详解 客户端和服务器还未建立连接,但服务器一般处于listen状态 客户端主动建立连接,向服务器发送SYN报文,客户端变为SYN_SENT状态 服务器收到客户端发送的报文,也回了一个SYN...

death05的博客 1957
上一篇: jdbc 隔离级别
下一篇: SQL Server易混淆的数据类型
csbison
博客等级 码龄23年 1粉丝 5原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值