Http持久连接与HttpClient连接池

最新推荐文章于 2024-06-20 05:31:07 发布
最新推荐文章于 2024-06-20 05:31:07 发布
阅读量999 收藏 2
点赞数
分类专栏： Just Java 文章标签： http 持久连接 HttpClient

本文摘自微信公众号ImportNew。来源kingszelda，www.cnblogs.com/kingszelda/p/8988505.html

 

一、背景

    HTTP协议是无状态的协议，即每一次请求都是互相独立的。因此它的最初实现是，每一个http请求都会打开一个tcp socket连接，当交互完毕后会关闭这个连接。

    HTTP协议是全双工的协议，所以建立连接与断开连接是要经过三次握手与四次握手的。显然在这种设计中，每次发送HTTP请求都会消耗很多的额外资源，即连接的建立与销毁。

    于是HTTP协议进行了发展优化，通过持久连接的方法来进行Socket连接复用。

 

从图中可以看到：

        1.在串行连接中，每次交互都要打开关闭连接。

        2.在持久连接中，第一次交互会打开连接，交互结束后连接并不会关闭，下次交互就神曲了建立连接的过程。

 

    持久化连接的实现方式有两种：HTTP/1.0+的keep-alive与HTTP/1.1的持久化连接。

二、HTTP/1.0+的keep-alive

    96年开始，很多HTTP/1.0浏览器与服务器都对协议进行了扩展，即“keep-alive”扩展协议。该协议是作为1.0的补充——“实验型持久连接”出现的。keep-alive已经不再使用了，最新的HTTP/1.1规范中也没有对它进行说明，只是很多应用延续了下来。

    使用HTTP/1.0的客户端在首部header中加上“Connection:Keep-Alive”，请求服务端将一条连接保持在打开状态。服务端如果愿意将这条连接保持在打开状态，就会在响应中包含同样的首部。如果响应没有包含“Connection:Keep-Alive”首部，则客户端会人为服务端不支持Keep-Alive，会在发送完响应报文之后关闭掉当前连接。

 

通过keep-alive补充协议，客户端与服务器之间完成了持久连接，然而还存在着一些问题：

    在HTTP/1.0中keep-alive不是标准协议，客户端必须发送Connection:keep-alive来激活keep-alive连接；代理服务器可能不支持keep-alive。因为一些代理是“盲中继”，无法理解首部的含义，只是将首部逐跳转发。所以可能造成客户端和服务端都保持了连接，但是代理不接受该连接上的数据。

 

三、HTTP/1.1的持久化连接

    HTTP/1.1采取持久连接的方式替代了Keep-Alive。HTTP/1.1的连接默认情况下是持久连接的，如果要显示关闭，需要在保文中加上Connection:Close首部。即在HTTP/1.1中所有的连接都进行了复用。

    然而如同Keep-Alive一样，空闲的持久连接也可以随时被客户端与服务端关闭；不发送Connection:Close不意味着服务器承诺连接永远保持打开。

 

四、HttpClient如何生成持久连接

    HttpClient中使用了连接池来管理持有连接，同一条TCP链路上，连接是可以复用的。HttpClient通过连接池的方式进行连接持久化。

    “池”是一种通用的设计，其设计思想并不复杂：

 

  1. 第一次使用连接的时候创建新的拦截；
  2. 结束时对应的连接不关闭，归还到池中；
  3. 下次同个目的的连接可从池中直接获取一个可用连接；
  4. 定期清理过期拦截。

 

     所有的连接池都是这个思路。不过HttpClient源码主要关注两点：

 

  1. 连接池的具体设计方案——以供以后自定义连接池做参考；
  2. 如何与HTTP协议对应上——即理论抽象转为代码的实现。

 

4.1HttpClient连接池的实现

 

    HttpClient关于持久连接的处理在下面的代码中可以集中体现，下面从MainClientExec摘取了和连接池相关的部分，去掉了其他部分：

 

public class MainClientExec implements ClientExecChain {

    @Override
    public CloseableHttpResponse execute(

            final HttpRoute route,

            final HttpRequestWrapper request,

            final HttpClientContext context,

            final HttpExecutionAware execAware) throws IOException, HttpException {

　　　　　//从连接管理器HttpClientConnectionManager中获取一个连接请求ConnectionRequest

        final ConnectionRequest connRequest = connManager.requestConnection(route, userToken);final HttpClientConnection managedConn;

        final int timeout = config.getConnectionRequestTimeout();

        //从连接请求ConnectionRequest中获取一个被管理的连接HttpClientConnection

        managedConn = connRequest.get(timeout > 0 ? timeout : 0, TimeUnit.MILLISECONDS);

　　　　 //将连接管理器HttpClientConnectionManager与被管理的连接HttpClientConnection交给一个ConnectionHolder持有

        final ConnectionHolder connHolder = new ConnectionHolder(this.log, this.connManager, managedConn);

        try {
            HttpResponse response;
            if (!managedConn.isOpen()) {
　　　　　　　　　//如果当前被管理的连接不是出于打开状态，需要重新建立连接
                establishRoute(proxyAuthState, managedConn, route, request, context);
            }
　　　　　　　//通过连接HttpClientConnection发送请求
            response = requestExecutor.execute(request, managedConn, context);
　　　　　　　//通过连接重用策略判断是否连接可重用         
            if (reuseStrategy.keepAlive(response, context)) {
                //获得连接有效期
                final long duration = keepAliveStrategy.getKeepAliveDuration(response, context);
                //设置连接有效期
                connHolder.setValidFor(duration, TimeUnit.MILLISECONDS);
　　　　　　　　　//将当前连接标记为可重用状态
                connHolder.markReusable();
            } else {
                connHolder.markNonReusable();
            }
        }
        final HttpEntity entity = response.getEntity();
        if (entity == null || !entity.isStreaming()) {
            //将当前连接释放到池中，供下次调用
            connHolder.releaseConnection();
            return new HttpResponseProxy(response, null);
        } else {
            return new HttpResponseProxy(response, connHolder);
        }
}

    这里看到了在Http请求过程中对连接的处理是和协议规范是一致的，这里要展开讲一下具体实现。

 

    PoolingHttpClientConnectionManager是HttpClient默认的连接管理器，首先通过requestConnection()获得一个连接的请求，注意这里不是连接。

public ConnectionRequest requestConnection(final HttpRoute route,final Object state) {
    
    final Future<CPoolEntry> future = this.pool.lease(route, state, null);

    return new ConnectionRequest() {

            @Override
            public boolean cancel() {
                return future.cancel(true);
            }

            @Override
            public HttpClientConnection get(final long timeout,final TimeUnit tunit) throws InterruptedException, ExecutionException, ConnectionPoolTimeoutException {
                final HttpClientConnection conn = leaseConnection(future, timeout, tunit);
                if (conn.isOpen()) {

                    final HttpHost host;

                    if (route.getProxyHost() != null) {
                        host = route.getProxyHost();
                    } else {
                        host = route.getTargetHost();
                    }
                    final SocketConfig socketConfig = resolveSocketConfig(host);

                    conn.setSocketTimeout(socketConfig.getSoTimeout());
                }
                return conn;
            }
        };
    }

 

    可以看到返回的ConnectionRequest对象实际上是一个持有了Future<CPoolEntry>，CPoolEntry是被连接池管理的真正连接实例。从上面的代码我们应该关注的是：

 

 

  • Future<CPoolEntry> future = this.pool.lease(route, state, null)如何从连接池CPool中获得一个异步的连接，Future<CPoolEntry>；
  • HttpClientConnection conn = leaseConnection(future, timeout, tunit)如何通过异步连接Future<CPoolEntry>获得一个真正的连接HttpClientConnection。

 

4.2 Future<CPoolEntry>

    看一下CPool是如何释放一个Future<CPoolEntry>的，AbstractConnPool核心代码如下：

private E getPoolEntryBlocking(

            final T route, final Object state,

            final long timeout, final TimeUnit tunit,

            final Future<E> future) throws IOException, InterruptedException, TimeoutException {

　　　　　//首先对当前连接池加锁，当前锁是可重入锁ReentrantLockthis.lock.lock();

        try {

　　　　　　　 //获得一个当前HttpRoute对应的连接池，对于HttpClient的连接池而言，总池有个大小，每个route对应的连接也是个池，所以是“池中池”

            final RouteSpecificPool<T, C, E> pool = getPool(route);

            E entry;

            for (;;) {

                Asserts.check(!this.isShutDown, "Connection pool shut down");

　　　　　　　　　　//死循环获得连接

                for (;;) {

　　　　　　　　　　　　//从route对应的池中拿连接，可能是null，也可能是有效连接

                    entry = pool.getFree(state);

　　　　　　　　　　　　//如果拿到null，就退出循环

                    if (entry == null) {

                        break;

                    }

　　　　　　　　　　　　//如果拿到过期连接或者已关闭连接，就释放资源，继续循环获取

                    if (entry.isExpired(System.currentTimeMillis())) {

                        entry.close();

                    }

                    if (entry.isClosed()) {

                        this.available.remove(entry);

                        pool.free(entry, false);

                    } else {

　　　　　　　　　　　　　　//如果拿到有效连接就退出循环

                        break;

                    }

                }

　　　　　　　　　　//拿到有效连接就退出

                if (entry != null) {

                    this.available.remove(entry);

                    this.leased.add(entry);

                    onReuse(entry);

                    return entry;

                }

　　　　　　　　　 //到这里证明没有拿到有效连接，需要自己生成一个                

                final int maxPerRoute = getMax(route);

                //每个route对应的连接最大数量是可配置的，如果超过了，就需要通过LRU清理掉一些连接

                final int excess = Math.max(0, pool.getAllocatedCount() + 1 - maxPerRoute);

                if (excess > 0) {

                    for (int i = 0; i < excess; i++) {

                        final E lastUsed = pool.getLastUsed();

                        if (lastUsed == null) {

                            break;

                        }

                        lastUsed.close();

                        this.available.remove(lastUsed);

                        pool.remove(lastUsed);

                    }

                }

　　　　　　　　　 //当前route池中的连接数，没有达到上线

                if (pool.getAllocatedCount() < maxPerRoute) {

                    final int totalUsed = this.leased.size();

                    final int freeCapacity = Math.max(this.maxTotal - totalUsed, 0);

　　　　　　　　　　　　//判断连接池是否超过上线，如果超过了，需要通过LRU清理掉一些连接

                    if (freeCapacity > 0) {

                        final int totalAvailable = this.available.size();

　　　　　　　　　　　　　　 //如果空闲连接数已经大于剩余可用空间，则需要清理下空闲连接

                        if (totalAvailable > freeCapacity - 1) {

                            if (!this.available.isEmpty()) {

                                final E lastUsed = this.available.removeLast();

                                lastUsed.close();

                                final RouteSpecificPool<T, C, E> otherpool = getPool(lastUsed.getRoute());

                                otherpool.remove(lastUsed);

                            }

                        }

　　　　　　　　　　　　　　//根据route建立一个连接

                        final C conn = this.connFactory.create(route);

　　　　　　　　　　　　　　//将这个连接放入route对应的“小池”中

                        entry = pool.add(conn);

　　　　　　　　　　　　　　//将这个连接放入“大池”中

                        this.leased.add(entry);

                        return entry;

                    }

                }

　　　　　　　　　//到这里证明没有从获得route池中获得有效连接，并且想要自己建立连接时当前route连接池已经到达最大值，即已经有连接在使用，但是对当前线程不可用

                boolean success = false;

                try {

                    if (future.isCancelled()) {

                        throw new InterruptedException("Operation interrupted");

                    }

　　　　　　　　　　　　//将future放入route池中等待

                    pool.queue(future);

　　　　　　　　　　　　//将future放入大连接池中等待

                    this.pending.add(future);

　　　　　　　　　　　　//如果等待到了信号量的通知,success为true

                    if (deadline != null) {

                        success = this.condition.awaitUntil(deadline);

                    } else {

                        this.condition.await();

                        success = true;

                    }

                    if (future.isCancelled()) {

                        throw new InterruptedException("Operation interrupted");

                    }

                } finally {

                    //从等待队列中移除

                    pool.unqueue(future);

                    this.pending.remove(future);

                }

                //如果没有等到信号量通知并且当前时间已经超时，则退出循环

                if (!success && (deadline != null && deadline.getTime() <= System.currentTimeMillis())) {

                    break;

                }

            }

　　　　　　　//最终也没有等到信号量通知，没有拿到可用连接，则抛异常

            throw new TimeoutException("Timeout waiting for connection");

        } finally {

　　　　　　　//释放对大连接池的锁

            this.lock.unlock();

        }

    }

 

    上面的代码逻辑有几个重要点：

  1. 连接池有个最大连接数，每个route对应一个小连接池，也有个最大连接数;
  2. 不论是大连接池还是小连接池，当超过数量的时候，都要通过LRU释放一些连接
  3. 如果拿到了可用连接，则返回给上层使用;
  4. 如果没有拿到可用连接，HttpClient会判断当前route连接池是否已经超过了最大数量，没有到上限就会新建一个连接，并放入池中;
  5. 如果到达了上限，就排队等待，等到了信号量，就重新获得一次，等待不到就抛超时异常;
  6. 通过线程池获取连接要通过ReetrantLock加锁，保证线程安全;

到这里为止，程序已经拿到了一个可用的CPoolEntry实例，或者抛异常终止了程序。

 

4.3 HttpClientConnection

    

protected HttpClientConnection leaseConnection(

            final Future<CPoolEntry> future,

            final long timeout,

            final TimeUnit tunit) throws InterruptedException, ExecutionException, ConnectionPoolTimeoutException {

        final CPoolEntry entry;

        try {

　　　　　　　//从异步操作Future<CPoolEntry>中获得CPoolEntry

            entry = future.get(timeout, tunit);

            if (entry == null || future.isCancelled()) {

                throw new InterruptedException();

            }

            Asserts.check(entry.getConnection() != null, "Pool entry with no connection");

            if (this.log.isDebugEnabled()) {

                this.log.debug("Connection leased: " + format(entry) + formatStats(entry.getRoute()));

            }

　　　　　　　//获得一个CPoolEntry的代理对象，对其操作都是使用同一个底层的HttpClientConnection

            return CPoolProxy.newProxy(entry);

        } catch (final TimeoutException ex) {

            throw new ConnectionPoolTimeoutException("Timeout waiting for connection from pool");

        }

    }

 

五、HttpClient如何复用持久连接

 

    在上一章中，我们看到了HttpClient通过连接池来获得连接，当需要使用连接的时候从池中获得。
对应着第三章的问题：

  1. 当有连接第一次使用的时候建立连接
  2. 结束时对应连接不关闭，归还到池中
  3. 下次同个目的的连接可从池中获取一个可用连接
  4. 定期清理过期连接

    我们在第四章中看到了HttpClient是如何处理1、3的问题的，那么第2个问题是怎么处理的呢？

 

即HttpClient如何判断一个连接在使用完毕后是要关闭，还是要放入池中供他人复用？再看一下MainClientExec的代码：

                //发送Http连接
                response = requestExecutor.execute(request, managedConn, context);

                //根据重用策略判断当前连接是否要复用
                if (reuseStrategy.keepAlive(response, context)) {

                    //需要复用的连接，获取连接超时时间，以response中的timeout为准
                    final long duration = keepAliveStrategy.getKeepAliveDuration(response, context);

                    if (this.log.isDebugEnabled()) {

                        final String s;

　　　　　　　　　　　　　//timeout的是毫秒数，如果没有设置则为-1，即没有超时时间
                        if (duration > 0) {
                            s = "for " + duration + " " + TimeUnit.MILLISECONDS;
                        } else {
                            s = "indefinitely";
                        }
                        this.log.debug("Connection can be kept alive " + s);
                    }

　　　　　　　　　　 //设置超时时间，当请求结束时连接管理器会根据超时时间决定是关闭还是放回到池中
                    connHolder.setValidFor(duration, TimeUnit.MILLISECONDS);

                    //将连接标记为可重用
　　　　　　　　　　　connHolder.markReusable();
                } else {
　　　　　　　　　　　　//将连接标记为不可重用
                    connHolder.markNonReusable();

                }

    可以看到，当使用连接发生过请求之后，有连接重试策略来决定该连接是否要重用，如果要重用就会在结束后交给HttpClientConnectionManager放入池中。那么连接复用策略的逻辑是怎么样的呢？

public class DefaultClientConnectionReuseStrategy extends DefaultConnectionReuseStrategy {

    public static final DefaultClientConnectionReuseStrategy INSTANCE = new DefaultClientConnectionReuseStrategy();

    @Override
    public boolean keepAlive(final HttpResponse response, final HttpContext context) {

　　　　　//从上下文中拿到request
        final HttpRequest request = (HttpRequest) context.getAttribute(HttpCoreContext.HTTP_REQUEST);

        if (request != null) {

　　　　　　//获得Connection的Header
            final Header[] connHeaders = request.getHeaders(HttpHeaders.CONNECTION);

            if (connHeaders.length != 0) {

                final TokenIterator ti = new BasicTokenIterator(new BasicHeaderIterator(connHeaders, null));

                while (ti.hasNext()) {

                    final String token = ti.nextToken();
 　　　　　　　　　　//如果包含Connection:Close首部，则代表请求不打算保持连接，会忽略response的意愿，该头部这是HTTP/1.1的规范
                    if (HTTP.CONN_CLOSE.equalsIgnoreCase(token)) {

                        return false;

                    }
                }
            }
        }

　　　　 //使用父类的的复用策略
        return super.keepAlive(response, context);
    }
}

看一下父类的复用策略：

if (canResponseHaveBody(request, response)) {

    final Header[] clhs = response.getHeaders(HTTP.CONTENT_LEN);

    /**
     * 如果reponse的Content-Length没有正确设置，则不复用连接。
     * 因为对于持久化连接，两次传输之间不需要重新建立连接，则需要根据Content-Length确认内容属于哪次请求，以正确处理“粘包”现象。
     * 所以，没有正确设置Content-Length的response连接不能复用。
     */

    if (clhs.length == 1) {
        final Header clh = clhs[0];
        try {
            final int contentLen = Integer.parseInt(clh.getValue());
            if (contentLen < 0) {
                return false;
            }
        } catch (final NumberFormatException ex) {
            return false;
        }
    } else {
                return false;
    }

}

if (headerIterator.hasNext()) {
    try {
        final TokenIterator ti = new BasicTokenIterator(headerIterator);
        boolean keepalive = false;
        while (ti.hasNext()) {
            final String token = ti.nextToken();
 　　　　　　//如果response有Connection:Close首部，则明确表示要关闭，则不复用
            if (HTTP.CONN_CLOSE.equalsIgnoreCase(token)) {
                return false;
                //如果response有Connection:Keep-Alive首部，则明确表示要持久化，则复用
            } else if (HTTP.CONN_KEEP_ALIVE.equalsIgnoreCase(token)) {
                keepalive = true;
            }
        }
        if (keepalive) {
            return true;
        }

    } catch (final ParseException px) {
            return false;
    }
}

//如果response中没有相关的Connection首部说明，则高于HTTP/1.0版本的都复用连接
return !ver.lessEquals(HttpVersion.HTTP_1_0);

总结一下：

  1. 如果request首部中包含Connection:Close，不复用；
  2. 如果response中Content-Length长度设置不正确，不复用；
  3. 如果response首部包含Connection:Close，不复用；
  4. 如果reponse首部包含Connection:Keep-Alive，复用；
  5. 都没命中的情况下，如果HTTP版本高于1.0则复用。

从代码中可以看到，其实现策略与我们第二、三章协议层的约束是一致的。

 

六、HttpClient如何清理过期的连接

    在HttpClient4.4版本之前，在从连接池中获取重用连接的时候会检查下是否过期，过期则清理。之后的版本则不同，会有一个单独的线程来扫描连接池中的连接，发现有离最近一次使用超过设置的时间后，就会清理。默认的超时时间是2秒钟。

public CloseableHttpClient build() {

    //如果指定了要清理过期连接与空闲连接，才会启动清理线程，默认是不启动的
    if (evictExpiredConnections || evictIdleConnections) {
　　　　　　　　 //创造一个连接池的清理线程
        final IdleConnectionEvictor connectionEvictor = new IdleConnectionEvictor(cm,
            maxIdleTime > 0 ? maxIdleTime : 10, 
            maxIdleTimeUnit != null ? maxIdleTimeUnit : TimeUnit.SECONDS, 
            maxIdleTime, maxIdleTimeUnit);

        closeablesCopy.add(new Closeable() {
            @Override
            public void close() throws IOException {
                connectionEvictor.shutdown();
                try {
                    connectionEvictor.awaitTermination(1L, TimeUnit.SECONDS);
                } catch (final InterruptedException interrupted) {
                    Thread.currentThread().interrupt();
                }
            }
        });
　　　　 //执行该清理线程
        connectionEvictor.start();
    }
}

    可以看到在HttpClientBuilder进行build的时候,如果指定了开启清理功能，会创建一个连接池清理线程并运行它。

public IdleConnectionEvictor(

    final HttpClientConnectionManager connectionManager,

    final ThreadFactory threadFactory,

    final long sleepTime, final TimeUnit sleepTimeUnit,

    final long maxIdleTime, final TimeUnit maxIdleTimeUnit) {

        this.connectionManager = Args.notNull(connectionManager, "Connection manager");

        this.threadFactory = threadFactory != null ? threadFactory : new DefaultThreadFactory();

        this.sleepTimeMs = sleepTimeUnit != null ? sleepTimeUnit.toMillis(sleepTime) : sleepTime;

        this.maxIdleTimeMs = maxIdleTimeUnit != null ? maxIdleTimeUnit.toMillis(maxIdleTime) : maxIdleTime;

        this.thread = this.threadFactory.newThread(new Runnable() {

            @Override
            public void run() {
                try {
    　　　　　　　　　　　//死循环，线程一直执行
                    while (!Thread.currentThread().isInterrupted()) {

    　　　　　　　　　　　　　//休息若干秒后执行，默认10秒
                        Thread.sleep(sleepTimeMs);
    　　　　　　　　　　　　　//清理过期连接
                        connectionManager.closeExpiredConnections();
    　　　　　　　　　　　　　//如果指定了最大空闲时间，则清理空闲连接
                        if (maxIdleTimeMs > 0) {
                            connectionManager.closeIdleConnections(maxIdleTimeMs, TimeUnit.MILLISECONDS);
                        }

                    }
                } catch (final Exception ex) {
                    exception = ex;
                }
            }

        });

}

总结一下：

  1. 只有在HttpClientBuilder手动设置后，才会开启清理过期与空闲连接；
  2. 手动设置后会启动一个线程死循环执行，每次执行sleep一定时间，调用HttpClientConnectionManager的清理方法清理过期与空闲连接。

七、本文总结

 

  1. HTTP协议通过持久连接的方式，减轻了早期设计中的过多连接问题；
  2. 持久连接有两种方式：HTTP/1.0+的Keep-Avlive与HTTP/1.1的默认持久连接；
  3. HttpClient通过连接池来管理持久连接，连接池分为两个，一个是总连接池，一个是每个route对应的连接池；
  4. HttpClient通过异步的Future<CPoolEntry>来获取一个池化的连接；
  5. 默认连接重用策略与HTTP协议约束一致，根据response先判断Connection:Close则关闭，在判断Connection:Keep-Alive则开启，最后版本大于1.0则开启；
  6. 只有在HttpClientBuilder中手动开启了清理过期与空闲连接的开关后，才会清理连接池中的连接；
  7. HttpClient4.4之后的版本通过一个死循环线程清理过期与空闲连接，该线程每次执行都sleep一会，以达到定期执行的效果。

 

 

本文摘自微信公众号ImportNew。来源kingszelda，www.cnblogs.com/kingszelda/p/8988505.html

崔大崔
关注
专栏目录
httpclient 连接池工具类_C#中HttpClient的使用小结
weixin_39527487的博客
11-22 1238
在之前的一周里，我利用业余时间帮人做视频下载工具，花了差不多20小时。期间发生的一些事情令我很不愉快，虽然到底是写好了相关类库，但最终成品是不打算做了。好在这段时间算是把 HttpClient 的相关知识复习了一遍，倒也不算白忙一场。本文便是对此的总结。------19.10.31 01.14AM-------朋友联系我，说之前忙疯了，一直没回我。 所以我不生气了，打算认真把这东西做完。但前面的字...
十二、连接池线程池配置——HttpClient连接池
最新发布
流楚丶格念的博客
08-27 1452
3.x、4.x 和 5.x API 是完全不兼容的，使用起来比较麻烦。在 HttpClient 的执行过程中，连接复用是一个关键的性能优化点。通过合理配置连接池参数、正确处理连接的使用和释放，以及关注连接池的生命周期和性能监控，可以有效提高。下面是对连接池源码的重要步骤分析，包括连接的复用和非复用情况的处理，以及连接池内部的数据结构。此异常通常表示连接池中的连接用尽，导致无法获取到可用连接。这种状态表示线程在等待连接池中的连接。时，到每个主机的并发最多只有 200，但总的并发连接数为 300。
谈谈持久连接——HTTP权威指南读书心得（五）
weixin_30706691的博客
01-17 80
从这次开始突然想尝试下新的笔记方式，昨天码完上一篇博客以后，突然收到了系统消息了，说不符合首页要求，仔细看了看要求的范围，赫然有一项没有“心得读书笔记”，估计就是这个躺枪了吧_(:з」∠)_。。。后来反省了下确实是这样，最开始做笔记的时候感觉这本说太"学术了"，有很多信息如果靠自己描述的很怕弄掉了一些重点，后来想想其实也是，读书笔记这东西嘛，就是方便自己记忆的，即使笔记再全，真正消化掉...
HTTP持久连接
Life is hard, it is supposed to be. If we don't suffer, we would never learn anything.
01-12 205
Persistent Connections What is HTTP Persistent Connections? HTTP persistent connections, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using the same TCP connection to send...
HTTP的持久连接（Persistent Connection）
qq_62311779的博客
06-20 810
HTTP 的持久连接（Persistent Connection），也称为长连接（Keep-Alive），是指在同一个 TCP 连接上可以发送和接收多个 HTTP 请求和响应，而不是每次请求都建立一个新的连接。持久连接旨在提高网络效率和性能，减少连接建立和拆除的开销。为了防止持久连接长期占用资源，通常会设置连接超时（timeout）。如果在一定时间内没有新的请求，服务器会关闭连接。超时的时间可以由服务器配置，也可以在。指定了在此连接上最多可以发送 100 个请求。指定了连接的空闲超时时间为 10 秒，
持久HTTP连接
友善啊，朋友的博客
07-01 989
早期的HTTP连接每进行一次HTTP就要进行一次tcp连接和断开： 每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的开销。 持久连接（HTTP Persistent Connections）是为了解决此问题提出的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。 持久性连接使得请求以管线化方式发送请求成为可能。发送一个请求后不用等待其回复即可发送下一个请求。 ...
java httpclient 单例_HttpClient实战二：单线程和多线程连接池实例
weixin_33870147的博客
02-24 831
随着系统架构风格逐渐向前后端分离架构，微服务架构转变，RestFul风格API的开发与设计，同时SpringMVC也很好的支持了REST风格接口。各个系统之间服务的调用大多采用HTTP+JSON或HTTPS+JSON方式。HTTP1.1默认是持久连接，HTTP1.0也可以通过在请求头中设置Connection:keep-alive使得连接成为长连接。既然HTTP协议支持长连接，那么HTTP连接同样...
java httpclient 连接池
10-21
Java HttpClient连接池是一种管理HTTP连接的机制，它可以在多个线程之间共享连接，从而提高应用程序的性能。PoolingHttpClientConnectionManager是Java HttpClient连接池的一个复杂类，它可以管理连接池，为多个线程...
httpClient连接池管理，你用对了？
技术原始积累
06-12 1514
一、前言为何要用http连接池那？因为使用它我们可以得到以下好处：因为使用它可以有效降低延迟和系统开销。如果不采用连接池，每当我们发起http请求时，都需要重新发起Tcp三次握手建立链接...
HttpCient连接池Demo
04-19
实现httpClient连接池，同时支持http和https请求，代码可直接导入IDE运行，无冗余代码
Http连接池工具类
04-25
两个主机建立连接的过程是很复杂的一个过程，涉及到多个数据包的交换，并且也很耗时间。Http连接需要的三次握手开销很大，这一开销对于比较小的http消息来说更大。但是如果我们直接使用已经建立好的http连接，这样花费就比较小，吞吐率更大。 传统的HttpURLConnection并不支持连接池，如果要实现连接池的机制，还需要自己来管理连接对象。对于网络请求这种底层相对复杂的操作，个人以为如果有可用的其他方案，也没有必要自己去管理连接对象。 除了HttpURLConnection，大家肯定还知道HttpClient。一般情况下，普通使用HttpClient已经能满足我们的需求，不过有时候，在我们需要高并发大量的请求网络的时候，还是用“连接池”这样的概念能提升吞吐量。
httpclient 连接池工具类_C# 中 HttpClient 的简单使用
weixin_39634438的博客
11-20 252
介绍当我们在开发客户端还有少部分服务端程序时，数据需要从 Webapi 服务器取得。在以前我使用的比较多的时 WebClient 和 HttpWebRequese，在新的 .Net 版本中，团队为其带来了更多的可选择性——新的 HttpClient。它有着更加灵活的 API。发送请求和接收响应主要是通过 HttpRequestMessage 和 HttpResponseMessage 这来给你个类...
HttpClient 连接池
mayongbo19的博客
05-08 285
HttpClient 4.3连接池参数配置及源码解读https://blog.csdn.net/umke888/article/details/54881946
HTTP长连接、短连接及持久连接浅谈
xiaoweids的博客
04-09 1093
为保持和HTTP/1.0的兼容性, 包含报文体的HTTP/1.1请求必须包含合法的Content-Length头域,除非明确知道服务端是HTTP/1.1兼容的.如果请求包含消息体, 而没有Content-Length域,那么如果服务端无法确定消息长度时,它会返回400(无效请求),或者坚持获取合法Content-Length 而返回411(要求包含长度).持久连接对关闭TCP连接的行为提供信号量机制支持。同样的，HTTP/1.1客户端可以期望连接是持久的，除非如前所述收到表示连接关闭的应答。
实现一个简单的HttpClient连接池(转自博客园)
u011187735的博客
09-01 2397
一、为什么要用Http连接池 1、降低延迟：如果不采用连接池，每次连接发起Http请求的时候都会重新建立TCP连接(经历3次握手)，用完就会关闭连接(4次挥手)，如果采用连接池则减少了这部分时间损耗，别小看这几次握手，本人经过测试发现，基本上3倍的时间延迟 2、支持更大的并发：如果不采用连接池，每次连接都会打开一个端口，在大并发的情况下系统的端口资源很快就会被用完，导致无法建立新的连接
Httpclient多线程连接池封装
xiaosongwahaha的博客
01-05 899
1、封装 package com.suning.search.utils; import java.io.IOException; import java.io.UnsupportedEncodingException; import java.util.ArrayList; import java.util.HashMap; import java.util.
C#之使用HttpClient的优解
weixin_40333655的博客
05-17 4647
转载http://www.sohu.com/a/123674135_467799 新工作入职不满半周，目前仍然还在交接工作，适应环境当中，笔者不得不说看别人的源码实在是令人痛苦。所幸今天终于将大部分工作流畅地看了一遍，接下来就是熟悉框架技术的阶段了。 也正是在看源码的过程当中，有一个比较明显的用法细节引起了我的注意，我发现一位同事在请求远程Web Api时，虽然使用了 HttpClient 类，但...
深入解析Http持久连接与HttpClient连接池
总结来说，理解Http持久连接和HttpClient连接池对于优化Java网络请求性能至关重要。通过HTTP/1.1的持久连接，我们可以减少连接开销；而通过HttpClient连接池，我们可以有效地管理这些连接，提高程序的稳定性和效率。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值