With microservices left, there are more and more http calls between services. In java, we can use httpclient, an open source tool class, for processing, but if used improperly, the possibility will be relatively poor, especially whether the connection pool can be used normally. Next, we will analyze the connection pool principle of httpclient in detail.
(1) Benefits of using httpclient
a) Reduce latency: If the connection pool is not used, the tcp link will be re-established (three handshakes) every time the connection initiates an http request, and the connection will be closed (four handshakes) when it is used up. If the connection pool is used, this will be reduced Partial time loss.
b) Support greater concurrency: If the connection pool is not used, a port will be opened for each connection. In the case of large concurrency, the port resources of the system will be used up soon, resulting in the inability to establish new connections. Using a connection pool to manage long connections can reuse previous connections, and when we use httpclient, it may be a call between two clusters, that is, a call between limited machines. In this way, multiplexing the connection pool can effectively save resources.
(2) Long and short links
Because the httpclient connection pool is all managed socket connections based on long connections. So introduce the difference between long links and short links. First of all, you need to accept the difference between http keep-alived and tcp keep-alive. They are not the same thing, and the intentions are different. http keep-alived is to make tcp live longer, so that multiple http can be transmitted on the same link, and the efficiency of socket can be improved. The keep-alived of tcp is a fresh-keeping mechanism for detecting the connection status of tcp. The tcp keep-alived freshness timer supports three system kernel configuration parameters:
tcp_keepalived_time
tcp_keepalived_intvl
tcp_keepalived_probes
keepalived is the freshness timer of tcp. When the tcp connection is established at both ends of the network and IDLE is idle for tcp_keepalived_time, the server kernel will try to send a detection packet to the client to judge the tcp connection status. If no reply from the other party is received, it will try to send the detection packet again after tcp_keepalived_intvl until it receives the ack from the other party. If there is no ack from the other party, it will try tcp_keepalived_probes times in total, each time it is 15s here , if there is still no reply after trying tcp_keepalived_probes times, the tcp connection will be discarded.