大家好，今天给大家分享性能是什么意思，一起来看看吧。
要点- TCP协议的基本概念。
- 定位TCP问题的常用工具。
- 一些常见的网络问题。
TCP的状态变迁图如下：
掌握TCP的状态变迁，对分析网络问题，有着非常重要的意义。结合tcpdump工具，能发现很多网络相关的问题。
连接建立与关闭通过上图，可以清晰地知道，每个系统函数调用之后，TCP的状态转换过程，对于定位应用程序的网络相关问题，有重要帮助。
复位报文TCP首部中的RST比特是用于“复位”的，一般情况是：到不存在的端口的连接请求和异常终止一个连接。
backlog它表示未完成连接队列和已经完成连接队列之各。如果连接队列中已没有空间，对于新的连接请求，TCP将不会理会收到的SYN，也不发回RST。
SO_KEEPALIVETCP套接字设置该选项后，如果2小时内(tcp_keepalive_time)内，在该套接字的任一方向上都没有数据交换，TCP就自动给对端发送一个保活探测报文。这是一个对端必须响应的TCP分节，它会导致以下三种情况之一：
- 对端以期望的ACK响应：一切正常。
- 对端以RST响应：对端已崩溃且重新启动，套接字关闭，错误为ECONNRESET。
- 对端没有任何响应：套接字关闭，分以下两种情况：1) 服务器没有任何响应，并在75秒(tcp_keepalive_intvl)后超时，服务器总发送10个(tcp_keepalive_probes)这样的探查，每个间隔75秒，错误为ETIMEOUT。2) 收到一个ICMP错误的响应，服务不可达，错误为EHOSTUNREACH。
UDP是一种面向报文的、无连接、不可靠的通信协议，它支持一对一，一对多，多对一和多对多的通信方式。在能容忍数据包丢失，实时性要求较高的场景中，可以考虑使用，如视频、直播等。
分析工具netstat查看网络连接状态。
tcpdump -i eth0- 抓取eth0网卡中，主机10.1.1.2所有的收发数据包。
- rxpck/s、txpck/s：每秒接收(发送)的数据包。
- rxkB/s、txkB/s：每秒接收(发送)的千字节。
- rxcmp/s、txcmp/s：每秒接收(发送)的压缩包数。
- rxmcst/s：每秒接收的多播数据包数。
可以用来查看网卡的实时流量信息，中间的箭头表示流量方向。
- RX、TX：接收(发送)流量。
- TOTAL：总流量。
- Cumm：运行iftop到目前时间的总流量。
- peak：过去40s的流量峰值。
- rates：分别表示过去2s 10s 40s 的平均流量。
显示数据包到指定主机之间的路由信息，可以检查网络延时。
# traceroute github.comtraceroute to github.com (20.205.243.166), 30 hops max, 60 byte packets1 9.30.191.130 (9.30.191.130) 2.445 ms 2.714 ms 2.959 ms2 9.30.251.110 (9.30.251.110) 2.172 ms 2.391 ms 2.523 ms3 10.196.36.126 (10.196.36.126) 2.234 ms 2.417 ms 10.196.36.62 (10.196.36.62) 2.215 ms4 10.200.65.101 (10.200.65.101) 2.986 ms 10.200.65.121 (10.200.65.121) 3.352 ms 10.200.65.101 (10.200.65.101) 2.838 ms5 10.162.5.110 (10.162.5.110) 3.908 ms 101.227.217.26 (101.227.217.26) 2.977 ms 7.735 ms^C每一跳会显示连续的三个RTT值。
分析策略1、检查网络统计信息，网络包速率和网络接口吞吐量：ss、netstat、sar。
2、跟踪新TCP连接的建立和时长来分析负载：tcplife。
3、跟踪TCP重传和其他的不常见TCP事件：tcpretrans、tcpdrop、skb:kfree_skb跟踪点。
4、测量DNS延迟，这可能是一个性能问题，如：gethostlatency。
5、测量各维度的网络延迟，如连接延迟、首字节延迟、软件栈各层之间的延迟等。注意，如有可能，网络延迟测试应该在负载和空闲网络中分别测试，进行比较。
6、检查主机之间的网络吞吐量上限，同时检查在已知负载情况下发生的网络事件。
7、使用高频CPU性能分析抓取内核调用栈信息，以量化CPU资源在网络协议和驱动程序之间的使用情况。
8、使用跟踪点和kprobes来探索网络软件栈的内部情况。
常见问题TIME_WAIT存在的2MSL的意义在TCP实现中，每个报文的最大生存时间为MSL，2MSL则表示，一个报文在一个连接中，一来一回的时长。它存在的意义主要是，1、保证最后一个ACK，已经到达到远端。2、保证连接(客户端IP和端口，服务端IP和端口)只能在2MSL后才能使用。
TIME_WAIT过多从TCP状态转换图可知，TIME_WAIT状态的出现，是由于主动断开连接导致的。也就是说，应用程序中存在大量的短连接，因此，解决TIME_WAIT过多的方法是，找出短连接的业务逻辑，将其修改为长连接。当然，如果应用程序作为服务端，主动断开了大量连接，可能需要结合业务作进一步分析断开原因。
可能还有的解决方案是，修改系统参数：tcp_tw_reuse、tcp_tw_recycle和tcp_max_tw_buckets，这三个参数的含义是：
- tcp_tw_reuse：该参数需要在两端打开tcp_timestamps，否则无效。它表示复用TIME_WAIT状态下的连接，在主动连接时生效。
- tcp_tw_recycle：该参数需要在两端打开tcp_timestamps，否则无效。它表示将TIME_WAIT状态下的连接快速回收，在4.12内核版本中已废弃。
- tcp_max_tw_buckets：控制TIME_WAIT的并发数量，达到一定数量后，系统会清理所有的TIME_WAIT连接，并打印日志。
使用修改tcp_tw_reuse和tcp_tw_recycle参数的方式，本身是有风险的，并不符合TCP协议规范。它可能导致延时的报文与新连接混在一起。尤其是tcp_tw_recycle参数，在NAT网络中，可能会导致SYN报文丢弃。可参考RFC 1122中关于TIME_WAIT重用的处理。
close_WAIT过多当应用程序收到对端发过来的FIN报文，而未调用close()函数时，会在被动关闭一方，出现CLOSE_WAIT状态。因此，当出现大量CLOSE_WAIT状态时，通常是应用程序，未及时调用close()关闭连接。更进一步分析，可以看看，应用程序在处理对端连接关闭请求时是否有问题，还是Recv-Q有堆积。
Recv-Q和Send-Q堆积判断当前连接状态是，Established还是Listening，然后，分析应用程序，是堵塞在收发数据包阶段，还是取连接的阶段。
TCP中KeepAlive与HTTP中keep-alive区别- KeepAlive是传输层的保活机制。keep-alive是应用层的保活机制。
- KeepAlive是当两个socket之间无数据交换时，进行保活检测的机制。keep-alive是指一次HTTP请求之后，不会将该连接断开，即与web服务之间，维护一个长连接，后续请求可以复用该连接。
《Systems Performance:Enterprise and Cloud》
《BPF Performance Tools》
《Computer Systems》
《Modern Operating Systems》
《TCP/IP详解 卷1：协议》
http://www.brendangregg.com/linuxperf.html
https://datatracker.ietf.org/doc/html/rfc1122
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
以上就是性能是什么意思的内容分享，希望对大家有用。
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权发表，未经许可，不得转载。
