My TCP Server not close client socket,but the client read EOF.,Then client closes socket,my server recv failed with 64..(winsock)
I want to konw when does this happen.
Related
I understand that http2 uses one tcp connection to serve multiple requests, for example, if I request index.html which contains a.css and a.js, these three requests will be done in one tcp connection.
What happens if user clicks index2.html? does this request still use the same previous tcp connection? If so, will the browser keep the connection open until user closes the browser? And on the server side, does the server keep many connections open all the time?
When using HTTP/2, browsers typically open only one connection per domain.
In your example, index2.html will be sent on the same TCP connection that was used for index.html, a.css and a.js.
In HTTP/2 requests are multiplexed on the same TCP connection, so that the browser can send them concurrently, without waiting for a previous request to be responded to.
Both browsers and servers have an idle timeout for TCP connections.
If the connection is idle for long enough, it will be closed by either party - the one that has the shorter idle timeout, to save resources.
For example, you may open a connection to a wikipedia.org, perform a few requests, and then leave that tab and work on something else.
After a while (typically 30 seconds) the browser will close the TCP connection to wikipedia.org.
On the server side, the server will keep the connections from various clients open, until they are either closed by the client or until the server-side idle timeout fires, at which point it's the server that initiated the close of the TCP connection.
With HTTP/2, the number of connections that a server has to maintain is vastly less than it was with HTTP/1.1.
With HTTP/2, a server has to maintain just 1 TCP connection per client; with HTTP/1.1, the server had to maintain typically 2-8 TCP connections per client.
What happens if user clicks index2.html? does this request still use the same previous tcp connection?
Yes. On top of that, multiple browser tabs/windows also share a single HTTP/2 connection.
If so, will the browser keep the connection open until user closes the browser?
Below from RFC - connection management
For best performance, it is expected that clients will not close
connections until it is determined that no further communication with
a server is necessary (for example, when a user navigates away from a
particular web page) or until the server closes the connection.
Clients SHOULD NOT open more than one HTTP/2 connection to a given
host and port pair.
And on the server side, does the server keep many connections open all the time?
Servers are encouraged to maintain open connections for as long as
possible but are permitted to terminate idle connections if necessary.
When either endpoint chooses to close the transport-layer TCP
connection, the terminating endpoint SHOULD first send a GOAWAY
(Section 6.8) frame so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks.
More info on connection error below.
RFC connection-error-handling
A connection error is any error that prevents further processing of
the frame layer or corrupts any connection state. An endpoint that
encounters a connection error SHOULD first send a GOAWAY frame with
the stream identifier of the last stream that it successfully received
from its peer. The GOAWAY frame includes an error code that indicates
why the connection is terminating. After sending the GOAWAY frame for
an error condition, the endpoint MUST close the TCP connection. It is
possible that the GOAWAY will not be reliably received by the
receiving endpoint. In the event of a connection error, GOAWAY only
provides a best-effort attempt to communicate with the peer about why
the connection is being terminated.
An endpoint can end a connection at any time. In particular, an
endpoint MAY choose to treat a stream error as a connection error.
Endpoints SHOULD send a GOAWAY frame when ending a connection,
providing that circumstances permit it.
To explain my question I tried doodling the scenario. Keep in mind I've been digging into TCP on my own so the diagram might not be too reliable. Please let me know if this is so.
Question:
What happens if a client that has an open connection with a server over TCP does not ACK a FIN sent by the server (seen at #1)?
Possible Answers:
Does the server close the connection anyway?
Does the server wait for ACK until connections are cleaned up forcefully?
If the client wants to keep the connection open after the server sent FIN can the client do anything to tell the server to keep it open? ie Ask for some more data
The FIN will be sent again, exactly as for a data segment, subject to the same retry counters and timeouts.
If the client wants to keep the connection open after the server sent FIN can the client do anything to tell the server to keep it open? i.e. Ask for some more data.
No. Once a host has sent a FIN it cannot send any more data. However the peer can send in the other direction, unless the host has actually closed the socket.
To establish a connection normally we will send a data from server to client, but can data be sent from client to server.
To establish a TCP connection we will not just 'normally' but always send a connection request from the client to the server, acknowledge it from the server to the client, and acknowledge the acknowledgement from the client to the server.
This will normally be followed by a data request from the client and then a data response from the server.
Your question is based on a false premiss.
I noted that fiddler sends "connection:close" header when the client sends a CONNECT request to initiate secure connection along with the "200 connection established" message.
CONNECT request to a forward HTTP proxy over an SSL connection?
As explained in above question, the connection should be kept-alive between the client and the proxy so that the client can subsequently sent the actual request.
Why does fiddler sends the close header? wouldn't the client close the connection because of the header instead?.
Any Connection header in the successful response to the CONNECT request does not make any sense and gets ignored. CONNECT will establish a tunnel, which only ends with the end of the TCP connection. But a Connection header would make sense with an unsuccessful CONNECT, because with close the client would need to start a new TCP connection and with keep-alive (implicit with HTTP/1.1 response) it can reuse it with another request.
Connection: Close means that the connection will be closed after the request completes. Since the request in this scenario only completes when the HTTPS connection is closed, this is exactly the behavior you want for this sort of request.
Arguably, using Connection: keep-alive on a CONNECT request is invalid, since there's no legal way for the connection to be kept-alive after the tunnel is closed.
I am working on a sip client - asterisk server. I am using tcp connections.
The client side is Zoiper as for a first test.
Registration and outbound calls do work as expected, but after 3-4 minutes from registration process or an outgoing call, when testing incoming calls I do get this message on the server:
tcptls.c:446 ast_tcptls_client_start: Unable to connect SIP socket to ip:port: Connection timed out
The invite message (incoming call) never gets on the client (Zoiper softphone).
Why is this error showing up?
The reason why this appears from my assumption is because of the fact that neither the client or the server are sending keep alive messages, so after a tcp socket timeout the client which is behind a nat will not be reachable from the server side anymore.
This error come because your NAT (or 3g if you use 3g) drop connection. As result there are no way use same connection anymore.
Correct behavour of you app - send SIP OPTIONS message, if timeout - do registration again.
And yes, you need send keepalives(recomended method - OPTIONS message) or setup keepalive on asterisk side and setup in your side correct answer.