Simultaneous socket connections on Arduino Ethernet Shield


I was reading about the tech-specifications of the Arduino's Ethernet Shield that I'm using. It says the following:

The Wiznet W5100 provides a network (IP) stack capable of both TCP and UDP. It supports up to four simultaneous socket connections.

As I know, when modern browsers send an HTTP request they define in the headers that the connection has to be maintained. Here's an example of a Firefox HTTP request:

GET /favicon.ico HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: */*
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

My question is: if in the HTTP response I define Connection: close is the connection socket for this connection released? Or the connection socket is released with client.stop() instruction?

If you see the stop() function it seems that it's responsible to close the socket, but I'm not sure. Here's the function:

void EthernetClient::stop() {
  if (_sock == MAX_SOCK_NUM)

  // attempt to close the connection gracefully (send a FIN to other side)
  unsigned long start = millis();

  // wait up to a second for the connection to close
  uint8_t s;
  do {
    s = status();
    if (s == SnSR::CLOSED)
      break; // exit the loop
  } while (millis() - start < 1000);

  // if it hasn't closed, close it forcefully
  if (s != SnSR::CLOSED)

  EthernetClass::_server_port[_sock] = 0;
  _sock = MAX_SOCK_NUM;

And my final question is: if the socket is realised with client.stop(), it's better to define Connection: close or Connection: keep-alive? It's possible that close is better because the browser will stop trying to be connected to the Arduino?

PS: the Arduino is working as a server and the clients are the browsers.

Yes, it is a problem. If you specify the "connection close" header, the browser should not reuse the connection. But for example FireFox, to be fast, opens more connections if the html file refers images, css or js files. And those connections then hang. If "connection close" is not specified and you have the EthernetClient object global (or static in the function) then it works better and fast, more page files are downloaded, until not. The browser suddenly abandons the connection and until the arduino server realizes that the connection is closed, the socket is not used.

Of course it is important to send the content-length header or use chunked encoding, so the browser knows if it received all the data and can close the connection or send next request over it.

I have a WebServer in my project, which I tested with Ethernet shield and on esp8266. Noe it is optimized for the esp8266. I have the Client object static but I send the "connection close" header. It somehow helps to reuse the Client instance.

If I have understood you well, it's better to define it close and client object as global or static?

If I have understood you well, it's better to define it close and client object as global or static?

I had no time investigate it so deep I would like. To have the Client object static is good when the connection starts. It can be connected but no data available, so I check it again in next loop. For the end of the connection it helps too somehow to have it static.