TCP连接异常，timewait状态过多

问题描述

服务链路：nginx -> sprintboot(vertx + httpclient) -> 后端长连接
问题：服务Time wait状态过多；随着不断增加请求，tw状态也线性？增长
在这里插入图片描述

netstat -n

查看网络连接状态：netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’ 在这里插入图片描述
netstat -n结合grep查看服务器端口使用状态，发现nginx服务器状态正常，无大量tw或cw状态；sprintboot服务器大量tw状态；
已知
nginx 开启了http1.1，
sprintboot代码如下，开启了keep-alive；

ThreadPoolExecutor tp = new ThreadPoolExecutor(200, 200, 300, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(200));

VertxOptions vertxOptions = new VertxOptions();
HttpServerOptions options = new HttpServerOptions().setLogActivity(true);
options.setIdleTimeout(20);
options.setIdleTimeoutUnit(TimeUnit.SECONDS);
options.setTcpKeepAlive(true);

HttpServer server = vertx.createHttpServer(options);
server.requestHandler(new HttpHandler(tp));
server.listen(port, res -> { });

通过打印请求头发现传到sprintboot的请求头如下（部分）：

[HTTP]HTTP_1_1
Content-Type: application/json
Connection: close
Content-Length: 21
User-Agent: Apache-HttpClient/4.5.13 (Java/1.8.0_181)
Accept-Encoding: gzip,deflate

应该是从客户端发出的请求带Connection: close；

TCP 状态及含义

https://new.qq.com/omn/20200618/20200618A0D67200.html
在这里插入图片描述
TW是主动端的状态

解决方法

Nginx配置：proxy_set_header Connection “”;
修改nginx到server为长连接

JVM锯齿

问题描述 unreachable objects较多

程序消耗Eden区呈现锯齿状，堆使用逐渐增大到-xmx大小，然后通过一次gc下降到使用比较小的情况；
在这里插入图片描述
通过dump发现unreacheable objects对象比较多

主要对象是HeapCharBuffer

网上找了一些资料：

Java NIO中的缓冲区Buffer（二）创建/复制缓冲区：https://www.cnblogs.com/chenpi/archive/2017/02/28/6478624.html
主要有以下两种方式创建缓冲区：
1、调用allocate方法
2、调用wrap方法
返回的都是new HeapCharBuffer（）对象；
源码阅读：https://gitee.com/joejay/LearningJDK/blob/master/src/java/nio/HeapCharBuffer.java
6个重要的JVM性能参数:https://zhuanlan.zhihu.com/p/122261143 （暂时没找到别的文章说这个锯齿）

总结

从网上资料看，jvm正常运行来说是就是锯齿状的（？存疑）
因为看dump文件里char[]包含了比较多东西，http请求报文，/metric，Prometheus的监控，还有很多乱码，以及压测没发现其他的问题，打到xmx就触发gc可以恢复。所以就不去细纠这个到底是jvm就这样，还是三方包使用的问题了。。

协议概览

这一part主要是因为本来想用wireshark分析下我本地发出请求状态及计算下tps啥的。。
后来发现获取了很多之前没见过的协议类型，找了几个比较有意思的记一下。
对协议类型总结比较全的可以参考：科来网络通讯协议图 http://www.colasoft.com.cn/download/protocols_map.php

SSDP 简单服务发现协议

应用层
SSDP（Simple Service Discovery Protocol），简单服务发现协议，用于发现局域网里面的设备和服务；239.255.255.250是默认SSDP广播ip地址；SSDP消息分为设备查询消息、设备通知消息两种;
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: “ssdp:discover”
MX: 5
ST: ssdp:all
在这里插入图片描述

ARP 地址解析协议

地址解析协议，用于实现从 IP 地址到 MAC 地址的映射，即询问目标IP对应的MAC地址。
ARP（地址解析协议）：根据IP地址获取物理地址的一个TCP/IP协议。
RARP（反向地址转换协议）：允许局域网的物理机器从网关服务器的 ARP 表或者缓存上请求自己的 IP 地址。
在这里插入图片描述

BROSWSER

SMS协议：局域网文件设备操作协议
https://blog.csdn.net/qq_33336155/article/details/53307308
摘抄：
SMB（ServerMessage Block）通信协议是微软（Microsoft）和英特尔(Intel)在1987年制定的协议，主要是作为Microsoft网络的通讯协议。SMB 是在会话层（session layer）和表示层（presentation layer）以及小部分应用层（application layer）的协议。SMB使用了NetBIOS的应用程序接口（Application Program Interface，简称API），一般端口使用为139，445。另外，它是一个开放性的协议，允许了协议扩展——使得它变得更大而且复杂；大约有65个最上层的作业，而每个作业都超过120个函数，甚至Windows NT也没有全部支持到，最近微软又把 SMB 改名为 CIFS（CommonInternet File System），并且加入了许多新的特色。
SMB/CIFS–NetBOIS/Browser/NBNS 协议
https://blog.csdn.net/woswod/article/details/63253500
摘抄：
浏览在SMB协议中，计算机为了访问网络资源，就需要了解网络上存在的资源列表（例如在Windows下使用网络邻居查看可以访问的计算机），这个机制就被称为浏览（Browsing）
工作组和域都可以跨越多个子网，因此网络中就存在两种Browser，一种为Domain Master Browser，用于维护整个工作组或域内的浏览数据，另一种为Local Master Browser，用于维护本子网内的浏览数据，它和Domain Master Browser通信以获得所有的可浏览数据。划分这两种Browser主要是由于浏览数据依赖于本地网广播来获得资源列表，不同子网之间只能通过浏览器之间的交流能力，才能互相交换资源列表。　　　
　　但是，为了浏览多个子网的资源，必须使用NBNS名字服务器的解析方式，没有NBNS 的帮助，计算机将不能获得子网外计算机的NetBIOS名字。Local Master Browser也需要查询NetBIOS名字服务器以获得Domain Master Browser的名字，以相互交换网络资源信息。　
　　在这里插入图片描述

NBNS 网络基本输入/输出系统 (NetBIOS) 名称服务器 (NBNS) 协议

https://zhuanlan.zhihu.com/p/115607631
网络基本输入/输出系统 (NetBIOS) 名称服务器 (NBNS) 协议是 TCP/IP 上的 NetBIOS (NetBT) 协议族的一部分，它在基于 NetBIOS 名称访问的网络上提供主机名和地址映射方法
NBNS是网络基本输入/输出系统 (NetBIOS) 名称服务器的缩写。它也是TCP/IP协议的一部分。它负责将计算机名转化为对应的IP。其中，Name query NB是请求包，Name query response NB是响应包。双方的端口号均为137。NBNS在WIndows用的较少，Windows普遍采用LLMNR协议。

LLMNR 链路本地多播名称解析

当DNS名称服务器请求失败时，Microsoft Windows系统就会通过链路本地多播名称解析（LLMNR）和Net-BIOS名称服务（NBT-NS）试图在本地进行名称解析。
LLMNR为使用IPv4、IPv6或者同时使用这两种地址的设备提供了点对点名称解析服务，可以让同一子网中的IPv4和IPv6设备不需要WINS或DNS服务器就可以解析对方的名称，而这个功能是WINS和DNS都无法完全提供的。