投稿
  1. 极客之音首页
  2. 技术随笔

高并发下对接第三方请求时http请求的问题及处理方式-springboot(十四)

飞熊 • • 技术随笔 • 阅读 591

人生之路坎坎坷坷，跌跌撞撞在所难免。但是，不论跌了多少次，你都必须坚强勇敢地站起来。任何时候，无论你面临着生命的何等困惑抑或经受着多少挫折，无论道路多艰难，希望变得如何渺茫，请你不要绝望，再试一次，坚持到底，成功终将属于勇不言败的你。

导读：本篇文章讲解 高并发下对接第三方请求时http请求的问题及处理方式-springboot(十四)，希望对大家有帮助，欢迎收藏，转发！站点地址：www.bmabk.com，来源：原文

链接: 解决TIME_WAIT过多造成的问题.
链接: TCP连接的状态与关闭方式，及Windows系统下的TCP参数优化.

创建一个java web 项目 启动为8080端口

import org.springframework.web.bind.annotation.*;

@RestController
public class TestController {

    @PostMapping("selectOne")
    public String selectOnePost() {
        return "模拟第三方请求成功回调！";
    }
    
}

模拟访问第三方接口

url为127.0.0.1:8080

原先代码

链接: java实现调用Http请求常用的几种方式.
以下测试 使用Apache HttpClient 客户端

导入依赖

<dependency>
    <groupId>cn.hutool</groupId>
    <artifactId>hutool-core</artifactId>
    <version>5.6.2</version>
</dependency>

import cn.hutool.core.thread.ThreadUtil;
import org.apache.http.HttpEntity;
import org.apache.http.ParseException;
import org.apache.http.client.ClientProtocolException;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.StringEntity;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClientBuilder;
import org.apache.http.util.EntityUtils;

import java.io.IOException;
import java.nio.charset.StandardCharsets;

public class WebApplicationTests1 {

    public static void post(String url, String params) {
        HttpPost httpPost = new HttpPost(url);
        httpPost.setEntity(new StringEntity(params, "UTF-8"));
        httpPost.setHeader("Content-Type", "application/json;charset=utf8");
        try (CloseableHttpClient httpClient = HttpClientBuilder.create().build();
             CloseableHttpResponse response = httpClient.execute(httpPost)) {
            HttpEntity responseEntity = response.getEntity();
            if (responseEntity != null) {
                System.out.println("响应内容为:" + EntityUtils.toString(responseEntity, StandardCharsets.UTF_8));
            }
        } catch (ClientProtocolException e) {
            e.printStackTrace();
        } catch (ParseException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        // 模拟每秒1000次并发
        for (int i = 0; i < 60; i++) {
            ThreadUtil.concurrencyTest(1000, () -> {
                String url = "http://127.0.0.1:8080/selectOne";
                post(url,"1111");
            });
            Thread.sleep(1000);
        }
    }
}

启动测试类进行访问

观察tcp连接情况

// windows查看tcp连接情况命令
netstat -ant|find  /I "192.168.1.167:8080"

刚开始无tcp连接

在这里插入图片描述

运行测试代码时 tcp连接占用端口满了 65535

在这里插入图片描述

观察电脑内存和cup情况

刚开始

在这里插入图片描述

运行测试代码时

cup 和 内存 都在飙升
在这里插入图片描述

运行测试代码时 端口到65535满了之后，服务器无法访问报错

在这里插入图片描述

发生的原因

对于Client而言，每个连接都需要占用一个端口，而系统允许的可用端口数不足65000个
（这也是在TCP参数优化后才能达到）。因此，如果Client发起过多的连接并主动关闭
（假设没有重用端口或者连接多个Server），就会有大量的连接在关闭后处于TIME_WAIT状态，
等待2MSL的时间后才能释放网络资源（包括端口），于是Client会由于缺少可用端口而无法新建连接。

对代码进行优化-使用线程池进行管理

程序正常运行 直到完成60次循环
在使用 netstat -ant|find /I “192.168.1.167:8080” 查看tcp链接
可以看到tcp链接已经被复用了 ，大大节省的资源
tcp链接的数也被限制了
cup也正常
在这里插入图片描述

import org.apache.http.client.config.RequestConfig;
import org.apache.http.config.Registry;
import org.apache.http.config.RegistryBuilder;
import org.apache.http.conn.socket.ConnectionSocketFactory;
import org.apache.http.conn.socket.PlainConnectionSocketFactory;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.conn.ssl.TrustSelfSignedStrategy;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.DefaultHttpRequestRetryHandler;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.impl.conn.PoolingHttpClientConnectionManager;
import org.apache.http.ssl.SSLContextBuilder;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.security.KeyManagementException;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;


public class HttpConnectionPoolUtil {

    private final static int RETRY_COUNT = 0; // 请求重试次数

    private static Logger logger = LoggerFactory.getLogger(HttpConnectionPoolUtil.class);

    // 池化管理
    private static PoolingHttpClientConnectionManager poolConnManager = null;

    private static CloseableHttpClient httpClient;// 它是线程安全的，所有的线程都可以使用它一起发送http请求

    public static CloseableHttpClient getHttpClient() {
        return httpClient;
    }

    static {
        try {
            System.out.println("初始化HttpClientTest~~~开始");
            SSLContextBuilder builder = new SSLContextBuilder();
            builder.loadTrustMaterial(null, new TrustSelfSignedStrategy());
            SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(builder.build());
            // 配置同时支持 HTTP 和 HTPPS
            Registry<ConnectionSocketFactory> socketFactoryRegistry = RegistryBuilder.<ConnectionSocketFactory>create()
                    .register("http", PlainConnectionSocketFactory.getSocketFactory())
                    .register("https", sslsf).build();
            // 初始化连接管理器
            poolConnManager = new PoolingHttpClientConnectionManager(socketFactoryRegistry);
            poolConnManager.setMaxTotal(100);// 同时最多连接数
            // 设置最大路由
            poolConnManager.setDefaultMaxPerRoute(50);
            // 此处解释下MaxtTotal和DefaultMaxPerRoute的区别：
            // 1、MaxtTotal是整个池子的大小；
            // 2、DefaultMaxPerRoute是根据连接到的主机对MaxTotal的一个细分；比如：
            // MaxtTotal=400 DefaultMaxPerRoute=200
            // 而我只连接到http://www.abc.com时，到这个主机的并发最多只有200；而不是400；
            // 而我连接到http://www.bac.com 和
            // http://www.ccd.com时，到每个主机的并发最多只有200；即加起来是400（但不能超过400）；
            // 所以起作用的设置是DefaultMaxPerRoute
            // 初始化httpClient
            httpClient = getConnection();
            System.out.println("初始化HttpClientTest~~~结束");
        } catch (NoSuchAlgorithmException e) {
            e.printStackTrace();
        } catch (KeyStoreException e) {
            e.printStackTrace();
        } catch (KeyManagementException e) {
            e.printStackTrace();
        }
    }

    public static CloseableHttpClient getConnection() {
        RequestConfig config = RequestConfig.custom()
                .setConnectTimeout(5000)
                .setConnectionRequestTimeout(5000)
                .setSocketTimeout(5000).build();
        CloseableHttpClient httpClient = HttpClients.custom()
                // 设置连接池管理
                .setConnectionManager(poolConnManager)
                .setDefaultRequestConfig(config)
                .setRetryHandler(new DefaultHttpRequestRetryHandler(RETRY_COUNT, false))
                .build();
        return httpClient;
    }


}

import cn.hutool.core.thread.ThreadUtil;
import com.zm.web.util.HttpConnectionPoolUtil;
import org.apache.http.HttpEntity;
import org.apache.http.ParseException;
import org.apache.http.client.ClientProtocolException;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.StringEntity;
import org.apache.http.util.EntityUtils;

import java.io.IOException;
import java.nio.charset.StandardCharsets;

public class WebApplicationTests1 {

    public static void post(String url, String params) {
        HttpPost httpPost = new HttpPost(url);
        httpPost.setEntity(new StringEntity(params, "UTF-8"));
        httpPost.setHeader("Content-Type", "application/json;charset=utf8");
        // 修改处 调用HttpConnectionPoolUtil线程池的HttpClient
        try (CloseableHttpResponse response = HttpConnectionPoolUtil.getHttpClient().execute(httpPost)) {
            HttpEntity responseEntity = response.getEntity();
            if (responseEntity != null) {
                System.out.println("响应内容为:" + EntityUtils.toString(responseEntity, StandardCharsets.UTF_8));
            }
        } catch (ClientProtocolException e) {
            e.printStackTrace();
        } catch (ParseException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        // 模拟每秒1000次并发，共60秒
        for (int i = 0; i < 60; i++) {
            ThreadUtil.concurrencyTest(1000, () -> {
                String url = "http://127.0.0.1:8080/selectOne";
                post(url,"1111");
            });
            Thread.sleep(1000);
        }
    }
}
  1. TCP连接的状态
CLOSED：初始状态，表示没有任何连接。

LISTEN：Server端的某个Socket正在监听来自远方的TCP端口的连接请求。

SYN_SENT：发送连接请求后等待确认信息。当客户端Socket进行Connect连接时，会首先发送SYN包，随即进入
SYN_SENT状态，然后等待Server端发送三次握手中的第2个包。

SYN_RECEIVED：收到一个连接请求后回送确认信息和对等的连接请求，然后等待确认信息。通常是建立TCP连接的三次
握手过程中的一个中间状态，表示Server端的Socket接收到来自Client的SYN包，并作出回应。

ESTABLISHED：表示连接已经建立，可以进行数据传输。

FIN_WAIT_1：主动关闭连接的一方等待对方返回ACK包。若Socket在ESTABLISHED状态下主动关闭连接并向对方发送
FIN包（表示己方不再有数据需要发送），则进入FIN_WAIT_1状态，等待对方返回ACK包，此后还能读取数据，但不能
发送数据。在正常情况下，无论对方处于何种状态，都应该马上返回ACK包，所以FIN_WAIT_1状态一般很难见到。

FIN_WAIT_2：主动关闭连接的一方收到对方返回的ACK包后，等待对方发送FIN包。处于FIN_WAIT_1状态下的Socket收
到了对方返回的ACK包后，便进入FIN_WAIT_2状态。由于FIN_WAIT_2状态下的Socket需要等待对方发送的FIN包，所有
常常可以看到。若在FIN_WAIT_1状态下收到对方发送的同时带有FIN和ACK的包时，则直接进入TIME_WAIT状态，无须
经过FIN_WAIT_2状态。

TIME_WAIT：主动关闭连接的一方收到对方发送的FIN包后返回ACK包（表示对方也不再有数据需要发送，此后不能再读
取或发送数据），然后等待足够长的时间（2MSL）以确保对方接收到ACK包（考虑到丢失ACK包的可能和迷路重复数据
包的影响），最后回到CLOSED状态，释放网络资源。

CLOSE_WAIT：表示被动关闭连接的一方在等待关闭连接。当收到对方发送的FIN包后（表示对方不再有数据需要发
送），相应的返回ACK包，然后进入CLOSE_WAIT状态。在该状态下，若己方还有数据未发送，则可以继续向对方进行发
送，但不能再读取数据，直到数据发送完毕。

LAST_ACK：被动关闭连接的一方在CLOSE_WAIT状态下完成数据的发送后便可向对方发送FIN包（表示己方不再有数据
需要发送），然后等待对方返回ACK包。收到ACK包后便回到CLOSED状态，释放网络资源。

CLOSING：比较罕见的例外状态。正常情况下，发送FIN包后应该先收到（或同时收到）对方的ACK包，再收到对方的
FIN包，而CLOSING状态表示发送FIN包后并没有收到对方的ACK包，却已收到了对方的FIN包。有两种情况可能导致这种
状态：其一，如果双方几乎在同时关闭连接，那么就可能出现双方同时发送FIN包的情况；其二，如果ACK包丢失而对方
的FIN包很快发出，也会出现FIN先于ACK到达。

TCP连接的关闭方式

建立TCP连接需要三次握手，而关闭连接则需要四次握手，并且分为主动关闭和被动关闭。
这是由于TCP连接是全双工的，我关了你的连接，并不等于你关了我的连接，因此双方都
必须单独进行关闭。当一方完成它的数据发送任务后可以发送FIN包来终止这个方向的连
接，表明自己不再有数据需要发送；收到FIN包的那一方虽然不能再读取数据，但仍能发送数据。

以Client主动关闭连接为例

Client向Server发送FIN包，表示Client主动关闭连接，然后进入FIN_WAIT_1状态，
等待Server返回ACK包。此后Client不能再向Server发送数据，但能读取数据。
Server收到FIN包后向Client发送ACK包，然后进入CLOSE_WAIT状态，此后
Server不能再读取数据，但可以继续向Client发送数据。Client收到Server
返回的ACK包后进入FIN_WAIT_2状态，等待Server发送FIN包。
Server完成数据的发送后，将FIN包发送给Client，然后进入LAST_ACK状态，
等待Client返回ACK包，此后Server既不能读取数据，也不能发送数据。
Client收到FIN包后向Server发送ACK包，然后进入TIME_WAIT状态，接着等
待足够长的时间（2MSL）以确保Server接收到ACK包，最后回到CLOSED状态，
释放网络资源。Server收到Client返回的ACK包后便回到CLOSED状态，释放网络资源。

Client（客户端）

CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

Server（服务端）

CLODES -> LISTEN -> SYN_RECEIVED -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

对Server与Client的影响

在详细了解TCP连接的状态和关闭方式后，我们会发现TIME_WAIT状态是一个坑爹的存在！
主动关闭连接的一方在发送最后一个ACK包后，无论对方是否收到都会进入TIME_WAIT状态，
等待2MSL的时间，然后才能释放网络资源。
MSL就是Maximum Segment Lifetime（数据包的最大生命周期），
是一个数据包能在互联网上生存的最长时间，若超过这个时间则该数据包将会消失在网络中。
操作系统通常会将2MSL设为4分钟，最低不少于30秒，因而TIME_WAIT状态一般维持在30秒至4分钟。
这个是TCP/IP协议必不可少的，是TCP/IP设计者设计的，也就是无法解决的。

TIME_WAIT状态的存在主要有两个原因：

	  可靠地实现TCP全双工连接的终止。在关TCP闭连接时，最后的ACK包是由主动关闭方发出的，
	如果这个ACK包丢失，则被动关闭方将重发FIN包，因此主动方必须维护状态信息，以允许它
	重发这个ACK包。如果不维持这个状态信息，那么主动方将回到CLOSED状态，并对被动方重
	发的FIN包响应RST包，而被动关闭方将此包解释成一个错误
	（在Java中会抛出connection reset的SocketException)。
	因而，要实现TCP全双工连接的正常终止，必须能够处理四次握手协议中任意一个包丢失的
	情况，主动关闭方必须维持状态信息进入TIME_WAIT状态。

	  确保迷路重复数据包在网络中消失，防止上一次连接中的包迷路后重新出现，影响新连接。
	TCP数据包可能由于路由器异常而迷路，在迷路期间，数据包发送方可能因超时而重发这个包，
	迷路的数据包在路由器恢复后也会被送到目的地，这个迷路的数据包就称为Lost Duplicate。
	在关闭一个TCP连接后，如果马上使用相同的IP地址和端口建立新的TCP连接，那么有可能出现
	前一个连接的迷路重复数据包在前一个连接关闭后再次出现，影响新建立的连接。为了避免这一
	情况，TCP协议不允许使用处于TIME_WAIT状态的连接的IP和端口启动一个新连接，只有经过
	2MSL的时间，确保上一次连接中所有的迷路重复数据包都已消失在网络中，才能安全地建立新连接。

　　  对于Client而言，每个连接都需要占用一个端口，而系统允许的可用端口数不足65000个
　　（这也是在TCP参数优化后才能达到）。因此，如果Client发起过多的连接并主动关闭
　　（假设没有重用端口或者连接多个Server），就会有大量的连接在关闭后处于TIME_WAIT状态，
　　等待2MSL的时间后才能释放网络资源（包括端口），
　　于是Client会由于缺少可用端口而无法新建连接。

　　  对Server而言（特别是处理高并发短连接的Server），Server端与Client建立的连接
　　是使用同一个端口的，即监听的端口，每个连接通过一个五元组区分，包括源IP地址、
　　源端口、传输层协议号（协议类型）、目的IP地址、目的端口，因而在理论上，Server
　　不受系统端口数的限制。但是，Server对每个端口上的连接数是有限制的，它要使用哈
　　希表记录端口上的每个连接，并受到文件描述符的最大打开数的限制。所以，如果Server
　　主动关闭连接，同样会有大量的连接在关闭后处于TIME_WAIT状态，等待2MSL的时间后
　　才能释放网络资源（包括哈希表上的连接记录和文件描述符），于是Server会由于达到
　　哈希表和文件描述符的限制而无法接受新连接，造成性能的急剧下滑，
　　性能曲线会持续产生严重的波动。

对于这种情况，有三种应对方式：

1.试图让Client主动关闭连接，由于每个Client的并发量都比较低，因而不会产生性能瓶颈。
2.优化Server的系统TCP参数，使其网络资源的最大值、消耗速度和恢复速度达到平衡。
3.改写TCP协议，重新实现底层代码，不过该方式难度很大，而且系统的稳定性和安全性可能受到影响。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/133942.html

赞 (0)
飞熊的头像飞熊bm
0 0

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站，欢迎收藏到浏览器，订阅我们！