I read that HTTP protocol uses the reliable TCP connections by default
,and one of the HTTP feature is connectionless.
Now I am confused how does it make sense ?
How does it use TCP and the same time it is connectionless and as I know TCP is connection-oriented
HTTP and TCP are different things. TCP is a transport layer protocol, whereas HTTP is an application layer protocol. HTTP uses TCP for data transmissions.
IMO this website has a nice explanation:
HTTP is connectionless: The HTTP client, i.e., a browser initiates an HTTP request and after a request is made, the client waits for the response. The server processes the request and sends a response back after which client disconnect the connection. So client and server knows about each other during current request and response only. Further requests are made on new connection like client and server are new to each other.
However, Wikipedia defines HTTP as stateless:
HTTP is a stateless protocol. A stateless protocol does not require the HTTP server to retain information or status about each user for the duration of multiple requests. However, some web applications implement states or server side sessions using for instance HTTP cookies or hidden variables within web forms.
Based on their explanations, the terms seems to be used interchangeably. However, these are not really true as the in-use HTTP versions allow you to identify the users through cookies etc. and create persistent connections.
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.
My understanding regarding network model communication:
Application layer:
1. HTTP(Not Persistent or stateless): For exchanging messages like get, post, put etc. Here connection is made to webserver and disconnected after sending response. So server will not keep track of the previous requests.
2. Websockets(Persistent or statefull): For creating a communication channel that will be open to exchange data. Here we can keep track of the previous requests. Like we can know how many users are currently connected to our server.
Transport layer:
TCP(Persistant and Statefull): Will let the server know to which application to connect using port number. Both HTTP and web sockets will work upon this layer.
Considering working with HTTP and TCP:
I make a HTTP request from browser(application layer):
Connects to web server sends all files requested and also makes a TCP connection with the application(transport layer).
After sending response it's disconnected.
My confusion:
I got totally confused when I heard, read that TCP is Statefull and Persistant connection.
Q1. Now after step three is browser still connected to webserver because of TCP?
Q2. Is the context object we get in server side in c# code is the complete request packet with HTTP info, TCP info, function to invoke or controller to invoke in MVC etc?
Q3. If client and server are still connected with TCP. Then on next HTTP request does it will use the available TCP connection or will create new TCP and HTTP connection? Why can't it use previous TCP to communicate? Or TCP will be destroyed after HTTP? Or what's happening?
I just went through the specification of http 1.1 at http://www.w3.org/Protocols/rfc2616/rfc2616.html and came across a section about connections http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8 that says
" A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.
Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection. "
Then I also went through a section on http state management at https://www.rfc-editor.org/rfc/rfc2965 that says in its section 2 that
"Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests;"
A section about the need to have persistent connections in the RFC 2616 also said that prior to persistent connections every time a client wished to fetch a url it had to establish a new TCP connection for each and every new request.
Now my question is, if we have persistent connections in http/1.1 then as mentioned above a client does not need to make a new connection for every new request. It can send multiple requests over the same connection. So if the server knows that every subsequent request is coming over the same connection, would it not be obvious that the request is from the same client? And hence would this just not suffice to maintain the state and would this just nit be enough for the server to understand that the request was from the same client ? In this case then why is a separate state management mechanism required at all ?
Basically, yes, it would make sense, but HTTP persistent connections are used to eliminate administrative TCP/IP overhead of connection handling (e.g. connect/disconnect/reconnect, etc.). It is not meant to say anything about the state of the data moving across the connection, which is what you're talking about.
No. For instance, there might an intermediate (such as a proxy or a reverse proxy) in the request path that aggregates requests from multiple TCP connections.
See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-21.html#intermediaries.
The HTTP protocol is stateless, but I found this on the Kurose-Ross book:
The default HTTP method is with persistent connections and pipeling.
This means that it can handle multiple requests, so it keeps opened the socket of a client that wants to ask multiple requests.Is that true? If yes, why is HTTP protocol considered stateless?
HTTP persistent connections relate to TCP connection being left open. HTTP operates on top of TCP - so TCP can be connected and/or stateful whereas HTTP would not. TCP is just the transport for HTTP.
If you look at the OSI model, you can see that TCP is on layer 4 (transport), whereas HTTP is on layer 7 (application). HTTP is not tied to TCP and could use other ways of transport too - as a protocol, it is not "inheriting" features from TCP.
(Note also that the persistent connection is not really persistent for a very long time. For Apache 2, it is open only for 5 seconds per default, and "According to RFC 2616 (page 46), a single-user client should not maintain more than 2 connections with any server or proxy".)
My Question is related to the HTTP Streaming Method for realizing HTTP Server Push:
The "HTTP streaming" mechanism keeps a request open indefinitely. It
never terminates the request or closes the connection, even after the
server pushes data to the client. This mechanism significantly
reduces the network latency because the client and the server do not
need to open and close the connection.
The HTTP streaming mechanism is based on the capability of the server
to send several pieces of information on the same response, without
terminating the request or the connection. This result can be
achieved by both HTTP/1.1 and HTTP/1.0 servers.
The HTTP protocol allows for intermediaries
(proxies, transparent proxies, gateways, etc.) to be involved in
the transmission of a response from server to the client. There
is no requirement for an intermediary to immediately forward a
partial response and it is legal for it to buffer the entire
response before sending any data to the client (e.g., caching
transparent proxies). HTTP streaming will not work with such
intermediaries.
Do I avoid the descibed problems whith proxy servers if i use HTTPS?
HTTPS doesn't use HTTP proxies - this would make security void. HTTPS connection can be routed via some HTTP proxy or just HTTP redirector by using HTTP CONNECT command, which establishes transparent tunnel to the destination host. This tunnel is completely opaque to the proxy, and proxy can't get to know, what is transferred (it can attempt to modify the dataflow, but SSL layer will detect modification and send an alert and/or close connection), i.e. what has been encrypted by SSL.
Update: for your task you can try to use one of NULL cipher suites (if the server allows) to reduce the number of operations, such as perform no encryption, anonymous key exchange etc. (this will not affect proxy's impossibility to alter your data).