HTTP is client - server communication where client always initiates the connection and server responds.
In the client server communication with HTTP 1.1 the following steps takes place:
1. Client sends the request to the server.
2. Server sends the response to the client with the response message and the status code.
My question is how is the data transfer handled in the protocol? I know HTTP is stateless and also it is either everything or nothing mechanism but how do you prove this? How is the handshake between server and client?
For example: When the server sends the response back to the client, what happens if 50% of the data is sent and then there is connection loss...then what will happen in this scenario? Will the client wait for remaining 50% of the message or it will start new transfer where server tries to send 100% of the message again? (In synchronous communication)
HTTP relies on a TCP connection, so in your example if 50% of the data is correctly sent but others packets (yes, you should think in terms of packets) are lost, the data will be sent again following the rules defined in TCP protocol
Related
I need to implement a tcp/ip client which connects to existing tcp server with a permanent connection. the client has to send multiple requests and response arrives asynchronously. I have use netty to do the integration part. I have to ensure that the response is done for the relevant request. How to implement this using apache camel.
rest()
.consumes("application/json").produces("application/json")
.post("/tcp")
.type(RequestBean.class)
.route()
.process(this::transformTcpMessage)
.to("netty://tcp://127.0.0.1:9898")
.endRest();
This is What I need to achieve. this TCP client need to have a permeant connection and server may response asynchronously. So I need to make sure that the relevant response has been send to the relevant request.
I know that a http request first makes a 3 way handshake to establish connection. Followed by the request and response.
If a handshake is required for future requests then it is called non persistent connection.
The server can choose to keep the connection alive so that a handshake is not required untill a timeout value (persistent). This is called persistent connection. It saves time required by not requiring the 3 way handshake for each request.
My colleague mentions that http supports both persistent and non persistent. My understanding is that - tcp makes the connection. So persistence is controlled by tcp layer. Am I right?
May be not right. HTTP is higher layer than TCP and HTTP 1.0 will send close() when they finish tranportint some data streams. But in HTTP 1.1, the controller will not send close(), instead, it'll send keepalive/hearbeat to the other side for live. It is controlled by the application layer, in other words, by the HTTP itself.
One way HTTP can support a persistent connection is called Server-Sent-Events.
An alternative to HTTP for persistant connections is WebSocket. WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. WebSocket enables streams of messages on top of TCP. WebSocket is distinct from HTTP.
While I'm writing a service with grpc, I'm trying to compare http/2 with websocket by server side pushing mechanism.
I know for websocket, the client will send a request with Upgrade: WebSocket and Connection: Upgrade headers to server and establish the long-lived connection. Then server will send the data freely after the connection is established.
But for grpc, as it is routed upon http/2, from the wiki page, https://en.wikipedia.org/wiki/HTTP/2_Server_Push, it says the server would need to predict the potential requests the client would send, and send a PUSH_PROMISE frame as early as possible.
Here are my two questions:
Does it mean that the server would also need to receive a corresponding response(request) from client in response to this PUSH_PROMISE header to decide if client wants to receive or decline the certain push?
In Grpc, if I have a sever side streaming, say send a message every 1 second from server. Does it mean the server need to send a PUSH_PROMISE to client every 1 second or at least before every data frame that server pushes to client?
gRPC does not currently support/use PUSH_PROMISE.
Streaming RPCs in gRPC use HTTP/2 streams; the entire RPC is contained in a request/response in HTTP. The main difference is that HTTP/2 implementations generally allow such streams to be streaming and bidirectional (the client can send more in the request after reading part of the response), while in HTTP/1 that was hit-or-miss.
In gRPC the client will always initiate the RPC. But for server-streaming the server can then reply with multiple messages over time via the stream. This would be similar to the scenario you described with websockets.
I have two questions on HTTP Connection close:
If a client sends a HTTP request with Connection: close to HTTP Server, Is it the HTTP Server or client responsibility to send TCP FIN after response is received by client?
If a client sends a bad formatted HTTP request, and server sends a 400 BAD REQUEST, is it best practice to close the connection by server (even though the HTTP request has connection: keep-alive) or is it good practice to keep the connection still active?
Thanks in advance for answering my queries?
When the server receives a 400 Bad Request, it is going to send the response with the keep-alive header because if the client feels like sending another request, then they can use a pre-existing connection (this connection is shut down within a certain amount of time, it has an expiration date). The Keep-Alive Header is more about not saturating the network with TCP connection demands. You basically say "I am going to talk to you, for 2 minutes, whatever you send me, I'll answer you though this connection"
The server is only an object that receives commands from an user. You ask him, he does or not. The TCP FIN is something you send to the server to shut down the connection, but you choose when you don't want to communicate with him anymore. The client transmits the first FIN, and receives an ACK to ensure that the server got it. Then the server launches its own FIN, and waits for the ACK. If everything is okay, you and your server are no longer friends.
I have a Web service based application, where the web server is running in the application on a particular port. Recently in the production environment, I have noticed that application is sending a RST packet to the client side resetting the connection. After analyzing the TCP dump, I have observed that the TCP 4 way connection closure is not happening properly. After sending a response from application web server to the client, the application is sending a FIN packet to the client and receiving an ACK, but there is no FIN packet initiation from the client side to the application, instead some request packet is received. At this point, the application sends a RST packet to the client as the application was expecting a FIN packet initiation from the client. This results in loss of the request packet. I believe this is a normal/expected behavior of the web server application and needs to be fixed in the client side.
Please comment on the above scenario. your comments will be much appreciated.
Thanks in advance
The client is ignoring the EOS condition on the socket and continuing to write. The client will then get a 'connection reset by peer'. This is basically an application protocol error. Either the client shouldn't be sending another request on the same conneciton, or the server should be looking for it instead of closing the connection after the first response.