TCP状态转移图
一、TCP状态介绍：
在TCP/IP协定中，TCP协定提供牢靠的连贯服务，采纳三次握手建设一个连贯。
_第一次握手：建设连贯时，客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，期待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时本人也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送结束，客户端和服务器进入ESTABLISHED状态，实现三次握手。_
实现三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：
未连贯队列：在三次握手协定中，服务器保护一个未连贯队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到 SYN包，并向客户收回确认，正在期待客户的确认包。这些条目所标识的连贯在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目， 服务器进入ESTABLISHED状态。
Backlog参数：示意未连贯队列的最大包容数目。
SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，期待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超 过零碎规定的最大重传次数，零碎将该连贯信息从半连贯队列中删除。留神，每次重传期待的工夫不肯定雷同。
半连贯存活工夫：是指半连贯队列的条目存活的最长工夫，也即服务从收到SYN包到确认这个报文有效的最长工夫，该工夫值是所有重传申请包的最长等待时间总和。有时咱们也称半连贯存活工夫为Timeout工夫、SYN_RECV存活工夫。
状态解释
CLOSED: 示意初始状态。
LISTEN:
示意服务器端的某个SOCKET处于监听状态，能够承受连贯
SYN_RCVD:
示意承受到了SYN报文，在失常状况下，这个状态是服务器端的SOCKET在建设TCP连贯时的三次握手会话过程中的一个中间状态，很短暂，基本上用 netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，成心将三次TCP握手过程中最初一个ACK报文不予发送。因而这种状态时，当 收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT:
这个状态与SYN_RCVD遐想响应，当客户端SOCKET执行CONNECT连贯时，它首先发送SYN报文，因而也随即它会进入到了SYN_SENT状态，并期待服务端的发送三次握手中的第2个报文。SYN_SENT状态示意客户端已发送SYN报文。
ESTABLISHED：示意连贯曾经建设
FIN_WAIT_1:
FIN_WAIT_1和FIN_WAIT_2状态的真正含意都是示意期待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当 SOCKET在ESTABLISHED状态时，它想被动敞开连贯，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对 方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在理论的失常状况下，无论对方何种状况下，都应该马上回应ACK报文，所以 FIN_WAIT_1状态个别是比拟难见到的，而FIN_WAIT_2状态还有时经常能够用netstat看到。
FIN_WAIT_2:
FIN_WAIT_2状态下的SOCKET，示意半连贯，也即有一方要求close连贯，但另外还通知对方，我临时还有点数据须要传送给你，稍后再敞开连贯。
TIME_WAIT:
示意收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标记和ACK标记的报文时，能够间接进入到TIME_WAIT状态，而无须通过FIN_WAIT_2状态。
CLOSING:
失常状况下，发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。然而CLOSING状态示意你发送FIN 报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么状况下会呈现此种状况呢？其实细想一下，也不难得出结论：那就是如果单方简直 在同时close一个SOCKET的话，那么就呈现了单方同时发送FIN报文的状况，也即会呈现CLOSING状态，示意单方都正在敞开SOCKET连 接。
CLOSE_WAIT:
示意在期待敞开。怎么了解呢？当对方close一个SOCKET后发送FIN报文给本人，你零碎毫无疑问地会回应一个ACK报文给对方，此时则进入到 CLOSE_WAIT状态。接下来呢，实际上你真正须要思考的事件是观察你是否还有数据发送给对方，如果没有的话，那么你也就能够 close这个SOCKET，发送FIN报文给对方，也即敞开连贯。所以你在CLOSE_WAIT状态下，须要实现的事件是期待你去敞开连贯。
LAST_ACK:
被动敞开一方在发送FIN报文后，最初期待对方的ACK报文。当收到ACK报文后，也即能够进入到CLOSED可用状态了。
须要C/C++ Linux服务器架构师学习材料加qun(563998835)获取（材料包含C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），收费分享
二、调优：
所有的TCP/IP调优参数都位于/proc/sys/net/目录. 例如, 上面是最重要的一些调优参数, 前面是它们的含意:
- /proc/sys/net/core/rmem_max — 最大的TCP数据接管缓冲
- /proc/sys/net/core/wmem_max — 最大的TCP数据发送缓冲
- /proc/sys/net/ipv4/tcp_timestamps — 工夫戳在(请参考RFC 1323)TCP的包头减少12个字节
- /proc/sys/net/ipv4/tcp_sack — 有抉择的应答
- /proc/sys/net/ipv4/tcp_window_scaling — 反对更大的TCP窗口. 如果TCP窗口最大超过65535(64K), 必须设置该数值为1
- rmem_default — 默认的接管窗口大小
- rmem_max — 接管窗口的最大大小
- wmem_default — 默认的发送窗口大小
- wmem_max — 发送窗口的最大大小
- *
net.core.rmem_default = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.wmem_max = 256960
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack =1
net.ipv4.tcp_window_scaling = 1
其余调优：
开启SYN Cookies。当呈现SYN期待队列溢出时，启用cookies来解决，可防备大量SYN*，默认为0，示意敞开；
net.ipv4.tcp_syncookies = 1
开启重用。容许将TIME-WAIT sockets从新用于新的TCP连贯，默认为0，示意敞开；
net.ipv4.tcp_tw_reuse = 1
开启TCP连贯中TIME-WAIT sockets的疾速回收，默认为0，示意敞开；
net.ipv4.tcp_tw_recycle = 1
零碎默认的TIMEOUT工夫。
net.ipv4.tcp_fin_timeout = 5
当keepalive起用的时候，TCP发送keepalive音讯的频度。缺省是2小时，改为20分钟(20*60s)
net.ipv4.tcp_keepalive_time = 1200
示意用于向外连贯的端口范畴。缺省状况下很小：32768到61000，改为10000到65000
net.ipv4.ip_local_port_range = 10000 65000
SYN队列的长度，默认为1024，加大队列长度为8192，能够包容更多期待连贯的网络连接数
net.ipv4.tcp_max_syn_backlog = 8192
零碎同时放弃TIME_WAIT的最大数量，如果超过这个数字，TIME_WAIT将立即被革除并打印正告信息。默认为180000，改为5000
net.ipv4.tcp_max_tw_buckets = 5000
其余调优参数
tcp_syn_retries ：INTEGER
默认值是5
对于一个新建连贯，内核要发送多少个 SYN 连贯申请才决定放弃。不应该大于255，默认值是5，对应于180秒左右工夫。(对于大负载而物理通信良好的网络而言,这个值偏高,可批改为2.这个值仅 仅是针对对外的连贯,对进来的连贯,是由tcp_retries1 决定的)
tcp_synack_retries ：INTEGER
默认值是5
对于远端的连贯申请SYN，内核会发送SYN ＋ ACK数据报，以确认收到上一个 SYN连贯申请包。这是所谓的三次握手( threeway handshake)机制的第二个步骤。这里决定内核在放弃连贯之前所送出的 SYN+ACK 数目。不应该大于255，默认值是5，对应于180秒左右工夫。(能够依据下面的 tcp_syn_retries 来决定这个值)
tcp_keepalive_time ：INTEGER
默认值是7200(2小时)
当keepalive关上的状况下，TCP发送keepalive音讯的频率。(因为目前网络等因素,造成了利用这个进行的很频繁,已经也有cu 的敌人提到过,说如果2边建设了连贯,而后不发送任何数据或者rst/fin音讯,那么继续的工夫是不是就是2小时,空连贯*? tcp_keepalive_time就是预防此情景的.我集体在做nat服务的时候的批改值为1800秒)
tcp_keepalive_probes：INTEGER
默认值是9
TCP发送keepalive探测以确定该连贯曾经断开的次数。(留神:放弃连贯仅在SO_KEEPALIVE套接字选项被关上是才发送.次数默认不须要批改,当然依据情景也能够适当地缩短此值.设置为5比拟适合)
tcp_keepalive_intvl：INTEGER
默认值为75
探测音讯发送的频率，乘以tcp_keepalive_probes就失去对于从开始探测以来没有响应的连贯杀除的工夫。默认值为75秒，也就是没有流动 的连贯将在大概11分钟当前将被抛弃。(对于一般利用来说,这个值有一些偏大,能够依据须要改小.特地是web类服务器须要改小该值,15是个比拟适合的 值)
tcp_retries1 ：INTEGER
默认值是3
放弃回应一个TCP连贯申请前﹐须要进行多少次重试。RFC 规定最低的数值是3﹐这也是默认值﹐依据RTO的值大概在3秒 – 8分钟之间。(留神:这个值同时还决定进入的syn连贯)
tcp_retries2 ：INTEGER
默认值为15
在抛弃激活(已建设通信情况)的TCP连贯之前﹐须要进行多少次重试。默认值为15，依据RTO的值来决定，相当于13-30分钟(RFC1122规定，必须大于100秒).(这个值依据目前的网络设置,能够适当地改小,我的网络内批改为了5)
tcp_orphan_retries ：INTEGER
默认值是7
在近端抛弃TCP连贯之前﹐要进行多少次重试。默认值是7个﹐相当于 50秒 – 16分钟﹐视 RTO 而定。如果您的零碎是负载很大的web服务器﹐那么兴许须要升高该值﹐这类 sockets 可能会消耗大量的资源。另外参的考 tcp_max_orphans 。(事实上做NAT的时候,升高该值也是益处显著的,我自己的网络环境中升高该值为3)
tcp_fin_timeout ：INTEGER
默认值是 60
对于本端断开的socket连贯，TCP放弃在FIN-WAIT-2状态的工夫。对方可能会断开连接或始终不完结连贯或不可意料的过程死亡。默认值为 60 秒。过来在2.2版本的内核中是 180 秒。您能够设置该值﹐但须要留神﹐如果您的机器为负载很重的web服务器﹐您可能要冒内存被大量有效数据报填满的危险﹐FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1 ﹐因为它们最多只吃 1.5K 的内存﹐然而它们存在工夫更长。另外参考 tcp_max_orphans。(事实上做NAT的时候,升高该值也是益处显著的,我自己的网络环境中升高该值为30)
tcp_max_tw_buckets ：INTEGER
默认值是180000
系 统在同时所解决的最大 timewait sockets 数目。如果超过此数的话﹐time-wait socket 会被立刻砍除并且显示正告信息。之所以要设定这个限度﹐纯正为了抵挡那些简略的 DoS *﹐千万不要人为的升高这个限度﹐不过﹐如果网络条件须要比默认值更多﹐则能够进步它(或者还要减少内存)。(事实上做NAT的时候最好能够适当地减少 该值)
tcp_tw_recycle ：BOOLEAN
默认值是0
关上疾速 TIME-WAIT sockets 回收。除非失去技术专家的倡议或要求﹐请不要随便批改这个值。(做NAT的时候，倡议关上它)
tcp_tw_reuse：BOOLEAN
默认值是0
该文件示意是否容许从新利用处于TIME-WAIT状态的socket用于新的TCP连贯(这个对疾速重启动某些服务,而启动后提醒端口曾经被应用的情景十分有帮忙)
tcp_max_orphans ：INTEGER
缺省值是8192
零碎所能解决不属于任何过程的TCP sockets最大数量。如果超过这个数量﹐那么不属于任何过程的连贯会被立刻reset，并同时显示正告信息。之所以要设定这个限度﹐纯正为了抵挡那些 简略的 DoS *﹐千万不要依赖这个或是人为的升高这个限度(这个值Redhat AS版本中设置为32768,然而很多防火墙批改的时候,倡议该值批改为2000)
tcp_abort_on_overflow ：BOOLEAN
缺省值是0
当守护过程太忙而不能承受新的连贯，就象对方发送reset音讯，默认值是false。这意味着当溢出的起因是因为一个偶尔的猝发，那么连贯将复原状态。 只有在你确信守护过程真的不能实现连贯申请时才关上该选项，该选项会影响客户的应用。(看待曾经满载的sendmail,apache这类服务的时候,这 个能够很快让客户端终止连贯,能够给予服务程序解决已有连贯的缓冲机会,所以很多防火墙上举荐关上它)
tcp_syncookies ：BOOLEAN
默认值是0
只有在内核编译时抉择了CONFIG_SYNCOOKIES时才会产生作用。当呈现syn等待队列呈现溢出时象对方发送syncookies。目标是为了避免syn flood*。
留神：该选项千万不能用于那些没有收到的高负载服务器，如果在日志中呈现synflood音讯，然而考察发现没有收到synflood，而是非法用户的连贯负载过高的起因，你应该调整其它参数来进步服务器性能。参考:
tcp_max_syn_backlog
tcp_synack_retries
tcp_abort_on_overflow
syncookie重大的违反TCP协定，不容许应用TCP扩大，可能对某些服务导致重大的性能影响(如SMTP转发)。(留神,该实现与BSD下面应用 的tcp proxy一样,是违反了RFC中对于tcp连贯的三次握手实现的,然而对于进攻syn-flood确实很有用.)
tcp_stdurg ：BOOLEAN
默认值为0
应用 TCP urg pointer 字段中的主机申请解释性能。大部份的主机都应用老旧的 BSD解释，因而如果您在 Linux 关上它﹐或会导致不能和它们正确沟通。
tcp_max_syn_backlog ：INTEGER
对于那些仍然还未取得客户端确认的连贯申请﹐须要保留在队列中最大数目。对于超过 128Mb 内存的零碎﹐默认值是 1024 ﹐低于 128Mb 的则为 128。如果服务器经常出现过载﹐能够尝试减少这个数字。正告﹗如果您将此值设为大于 1024﹐最好批改 include/net/tcp.h 外面的 TCP_SYNQ_HSIZE ﹐以放弃 TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog ﹐并且编进外围之内。(SYN Flood利用TCP协定分布握手的缺点，伪造虚伪源IP地址发送大量TCP-SYN半关上连贯到指标零碎，最终导致指标零碎Socket队列资源耗 尽而无奈承受新的连贯。为了应酬这种，古代Unix零碎中广泛采纳多连贯队列解决的形式来缓冲(而不是解决)这种，是用一个根本队列解决失常的完 全连贯利用(Connect()和Accept() )，是用另一个队列独自寄存半关上连贯。这种双队列解决形式和其余一些零碎内核措施(例如Syn-Cookies/Caches)联结利用时，可能比拟有 效的缓解小规模的SYN Flood(事实证明<1000p/s)加大SYN队列长度能够包容更多期待连贯的网络连接数，所以对Server来说能够思考增大该值.)
tcp_window_scaling ：INTEGER
缺省值为1
该 文件示意设置tcp/ip会话的滑动窗口大小是否可变。参数值为布尔值，为1时示意可变，为0时示意不可变。tcp/ip通常应用的窗口最大可达到 65535 字节，对于高速网络，该值可能太小，这时候如果启用了该性能，能够使tcp/ip滑动窗口大小增大数个数量级，从而进步数据传输的能力(RFC 1323)。（对一般地百M网络而言，敞开会升高开销，所以如果不是高速网络，能够思考设置为0）
tcp_timestamps ：BOOLEAN
缺省值为1
Timestamps 用在其它一些货色中﹐能够防备那些伪造的 sequence 号码。一条1G的宽带线路或者会重遇到带 out-of-line数值的旧sequence 号码(如果它是因为上次产生的)。Timestamp 会让它晓得这是个 ‘旧封包’。(该文件示意是否启用以一种比超时重发更准确的办法（RFC 1323）来启用对 RTT 的计算；为了实现更好的性能应该启用这个选项。)
tcp_sack ：BOOLEAN
缺省值为1
使 用 Selective ACK﹐它能够用来查找特定的遗失的数据报— 因而有助于疾速复原状态。该文件示意是否启用有抉择的应答（Selective Acknowledgment），这能够通过有选择地应答乱序接管到的报文来进步性能（这样能够让发送者只发送失落的报文段）。(对于广域网通信来说这个 选项应该启用，然而这会减少对 CPU 的占用。)
tcp_fack ：BOOLEAN
缺省值为1
关上FACK拥塞防止和疾速重传性能。(留神，当tcp_sack设置为0的时候，这个值即便设置为1也有效)
tcp_dsack ：BOOLEAN
缺省值为1
容许TCP发送”两个完全相同”的SACK。