My question is simple: How many http requests make how many tcp connections to server in Go.
I'm coding a tool can send many http requests, but I find all this requests over one or two tcp connetions, seem like golang http Transport have a connections pool.
If you are using the DefaultTransport for your HTTP requests then the TCP connections are reused.
DefaultTransport is the default implementation of Transport and is used by DefaultClient. It establishes network connections as needed and caches them for reuse by subsequent calls.
You can use MaxConnsPerHost to limit the total number of connections:
// MaxConnsPerHost optionally limits the total number of
// connections per host, including connections in the dialing,
// active, and idle states. On limit violation, dials will block.
//
// Zero means no limit.
//
// For HTTP/2, this currently only controls the number of new
// connections being created at a time, instead of the total
// number. In practice, hosts using HTTP/2 only have about one
// idle connection, though.
MaxConnsPerHost int
Edit
I highly suggest you read the docs as Go has one of the most well documented standard library. Anyway, you can configure http.Transport to disable keep-alive to force usage of one TCP connection per request.
// DisableKeepAlives, if true, disables HTTP keep-alives and
// will only use the connection to the server for a single
// HTTP request.
//
// This is unrelated to the similarly named TCP keep-alives.
DisableKeepAlives bool
Related
I am trying to write a heavy duty proxy to a set of web APIs in Golang. In order to prevent port exhaustion, I have decided to not use the DefaultClient and instead create a customized instance for http.Client. There are many interesting setting in the http.Transport that I can play around with.
I have come across the MaxIdleConnsPerHost and IdleConnTimeout fields and I have this question.
If I increase the value of MaxIdleConnsPerHost it means there will be more idle connection, but are they reusable idle connections? Or in other words, to make a decent connection pool, should I increase the value of MaxIdleConnsPerHost together with the timeout for IdleConnTimeout accordingly, or does it behave exactly the opposite?
yes, IdleConns are reusable as these are keep-alive connections. But to make golang honour the reusability of keep-alive connections you need to make sure of 2 things in your applications.
Read until Response is complete (i.e. ioutil.ReadAll(rep.Body))
Call Body.Close()
here's a link for more explaination.
I want to limit the number of HTTP connections for web applications on OpenLiberty. Which parameters should I change to do this? I'm looking at the docs, should I change maxConcurrentStreams in HTTPOption or maxThread in executer?
There isn't an existing property to specifically limit HTTP connections, so I'd recommend using maxOpenConnections, which is a tcpOptions configuration[1]. That property allows you to restrict the number of open connections for a TCP endpoint. The default value is 128000.
maxConcurrentStreams applies specifically to HTTP/2 the number of streams that are allowed per HTTP/2 (TCP) connection, and maxThread won't directly accomplish what you want.
[1] https://openliberty.io/docs/21.0.0.2/reference/config/httpEndpoint.html#tcpOptions
(1) If I make a hundred http request asynchronously from a client application to a single destination(i.e- same ip/port), is there any chance of conflict in the client side?
What I understand is whenever an application makes a http request the OS assigns a random port as source, and the server response is sent to that source port only. As the requests are asynchronous and too many, can there be cases where OS assigns a same source port to another of this 100 request, and when the server responses actually for the first request the second request also receives that response?
(2) Even if conflict is not probable for 100 request, is there any upper limit to this(because ports are limited, and number of simultaneous requests made are nearly same or more)?
(3) And is the scenario same for all applications(whether using a Winforms client or a curl)?
You can create maximum of 65535 (2^16 - 1) ports in a system - including server and client ports.
Ans 1: The ports won't overlap/conflict when you make 100 or above simultaneous requests. But make sure at the server side, whether you can do such huge requests from a particular system/network.
Ans 2: Upper limit is 65535.
And 3: Yes, this limit is for all the ports used by the application running in the system.
We really like the async model with web sockets. In some of our applications, we implement widgets in frames (often as many as 10 or 20 widgets on a page). Each widget opens a web socket to receive notifications of state changes.
Are there any best practices, practical limits, or hard limits on the number of web sockets a page can open?
It depends on the browser.
See:
HTTP simultaneous connections per host limit... are per tab, browser instance or global?
HTML5 websockets: max number of open connections?
It seems that the maximum number of possible open Websockets is defined by the browser implementation, and it is being difficult to find numbers.
In the Chromium source code (Google Chrome for Linux) I can see a max of 30 per host, 256 overall.
// Limit of sockets of each socket pool.
int g_max_sockets_per_pool[] = {
256, // NORMAL_SOCKET_POOL
256 // WEBSOCKET_SOCKET_POOL
};
// Default to allow up to 6 connections per host. Experiment and tuning may
// try other values (greater than 0). Too large may cause many problems, such
// as home routers blocking the connections!?!? See http://crbug.com/12066.
//
// WebSocket connections are long-lived, and should be treated differently
// than normal other connections. 6 connections per group sounded too small
// for such use, thus we use a larger limit which was determined somewhat
// arbitrarily.
// TODO(yutak): Look at the usage and determine the right value after
// WebSocket protocol stack starts to work.
int g_max_sockets_per_group[] = {
6, // NORMAL_SOCKET_POOL
30 // WEBSOCKET_SOCKET_POOL
};
In the Firefox configuration, (go to about:config and search for network.websocket) I can see a max of 6 persistent connections per host and 200 overall, but apparently the persistent conection limit does not affect WebSocket connections, so only the 200 limit applies.
About the approach...
My recommendation is that you should use one per page/tab. If you have widgets as frames, use .postMessage( +info ) to communicate between frames and the main page, and let the main page communicate with the server with a single connection. Use a publisher/subscriber model to allow different widgets subscribe to particular events.
Having so many connections is a waste of resources in both browser and server.
A server is listening, let's say, on port 3000. When he receives a connection request and the connection is successful, if i call a function, let's say "getRemotePort" it will say 1234. My question is, the server will send data to the remote devise (client) on port 1234, but what about the other way around? Will the client keep sending data on the same port, in this case 3000? So everything that the server will receive (connection requests and other data) will come through the same port?
Yes it will
This is not a problem.
The point behind this is, that a connection is defined by the (LocalIP, LocalPort, RemoteIP, RemotePort) tupel - this is the only combination, that has to be unique.
On the performance side, this is no problem as well: A port is a logic construct, that has no limiting effect on the throughput of a connection, some edge cases aside (Very high latency combined with very high throughput can create a case, where a single connection can not saturate a physical link, so a second connection, requiring a second port, can speed things up. Mind though, that even in this case not the port count, but the connection count is to blame - they just happen to be 1:1)