Go http pkg provide a Hijacker interface, can anyone tell when should I use it.
I check the comment, after a Hijack call lets the caller take over the connection, the HTTP server library will not do anything else with the connection.
I understand it as it's used to support both http request and common tcp interactive within one port. Is it right? Does it has any other benefits.
It means that you take over the control of TCP connection.
TCP is a generic transport protocol, whereas HTTP is an application protocol on top of TCP. The OSI seven layer model describes TCP as layer 4 and HTTP is layer 7.
If you need to implement a different application protocol, this is one use-case for hijacking.
Or if you need to do something specialised with HTTP, like preventing keep-alive connections, that is another use-case.
An example for an alternative web application protocol is Google's SPDY. It's also a good reason why you might hijack an existing HTTP connection, rather than create a TCP connection directly. For SPDY, a browser would first make an HTTP request that included 'accept' headers indicating that it is also able to understand SPDY. So now you could hijack the connection and implement SPDY instead of HTTP.
Related
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.
As we all know that the HTTP is stateless protocol, means it disconnects the connection after the end of every transaction.
But that's not enough for me to understand it. What makes me confuse that, Is the TCP connection also ends?
As HTTP is a TCP network protocol, so it talks to other nodes through the TCP pipe. So Is the stateless means that the TCP connection also ends?
So, it will make another TCP connection by using another TCP 3 way-handshake?
What makes the protocol stateless is that the server is not required to track state over multiple requests, not that it cannot do so if it wants to. This simplifies the contract between client and server, and in many cases minimizes the amount of data that needs to be transferred.and the Internet is a stateless development environment" is often used. This simply means that the HTTP that is the backbone of the Web is unable to retain a memory of the identity of each client that connects to a Web site and therefore treats each request for a Web page as a unique and independent connection, with no relationship whatsoever to the connections that preceded it.
As we all know that the HTTP is stateless protocol, means it disconnects the connection after the end of every transaction.
No, we don't all know that it means that at all: no, it doesn't mean that at all; and no, it doesn't do that at all.
What makes me confuse that, Is the TCP connection also ends?
The TCP connection ends when the HTTP connection ends.
As HTTP is a TCP network protocol, so it talks to other nodes through the TCP pipe.
Correct.
So Is the stateless means that the TCP connection also ends?
No. The HTTP and TCP connections can be persistent, and they are by default from HTTP 1.1 (previously via the so-called KEEPALIVE feature). This has nothing to do with statelessness.
So, it will make another TCP connection by using another TCP 3 way-handshake?
Yes, whenever required, but that isn't as often as you seem to think. You are conflating two different aspects of HTTP.
Websocket is designed in such a way that its servers can share a port with HTTP servers, by having its handshake be a valid HTTP Upgrade request.
I have a doubt in this design philosophy.
Any ways the WebSocket Protocol is an independent TCP-based protocol.
Why would we need this HTTP handshake(upgrade request) and a protocol switching. Instead why can't we directly(& independently) follow a websocket like protocol?
To quote from the IETF 6455 WebSocket spec:
The WebSocket Protocol attempts to address the goals of existing
bidirectional HTTP technologies in the context of the existing HTTP
infrastructure; as such, it is designed to work over HTTP ports 80
and 443 as well as to support HTTP proxies and intermediaries, even
if this implies some complexity specific to the current environment.
However, the design does not limit WebSocket to HTTP, and future
implementations could use a simpler handshake over a dedicated port
without reinventing the entire protocol.
In other words, there is a vast infrastructure for HTTP and HTTPS that already exists (proxies, firewalls, caches, and other intermediaries). In order to increase the chances of being adopted widely, the WebSocket protocol was designed to allow adjustments and extensions to the existing infrastructure without having to recreate everything from scratch to support a new protocol on a dedicate port.
It's also important to note that even if WebSocket protocol were to get rid of the HTTP compatible handshake, it would still need a handshake of almost equivalent complexity to support security requirements of the modern web so the browser and server can validate each other and to support CORS (cross-origin request sharing) securely. Even "raw" Flash sockets do a handshake with the server via the security policy request prior to creating the actual socket.
RPC protocol uses TCP as an underlying protocol and HTTP again uses TCP as an underlying protocol. So why is HTTP is widely accepted?
Why does SOAP use HTTP as an underlying protocol - why not RPC?
Remote Procedure Calls (RPC) is not a protocol, it's a principle that is also used in SOAP.
SOAP is an application protocol that uses HTTP for transport (so it won't have to think about encoding, message boundaries and so on). One of the reasons to use SOAP over HTTP is that for HTTP you usually don't need firewall rules and that the HTTP infrastructure is mature and commonly rolled out.
RPC does not require HTTP. Basically, RPC describes any mechanism that is suitable to invoke some piece of code remotely. The transport mechanism used to perform the RPC could be SOAP over HTTP. It could also be a REST call returning some JSON data over HTTP.
SOAP can also be used via Mails, and AFAIK (not sure here) the BizTalk Server should support this scenario. But even something exotical like trying SOAP over Avian Carriers can also be considered an RPC, although the latency of the latter may not be sufficient for real-world applications.
Think of an RPC as sending somehow some kind of message to a destination, in order to initiate a specific action and (optionally) getting some information back after the action has been completed. What prticular technology you choose to transmit these messages does not really matter.
From this article on Wikipedia:
Keepalive messages were not officially
supported in HTTP 1.0. In HTTP 1.1 all
connections are considered persistent,
unless declared otherwise.
Does this mean that using this
mechanism I can actually simulate a
TCP socket connection?
Using this can I make a Server
"push" data to a client?
Are all HTTP connections, even the
one I am using to connect to Stack
Overflow "HTTP persistent"?
Does the COMET technology of
server push use this mechanism of
HTTP persistent connection to push
data to clients?
Does this mean that using this mechanism I can actually simulate a
TCP socket connection?
Not really, sockets have MANY more features and flexibility.
Using this can I make a Server "push" data to a client?
Not directly, it's still a request/response protocol; the persistent connection just means the client can use the same underlying socket to send multiple requests and receive the respective responses.
Are all HTTP connections, even the one I am using to connect to Stack
Overflow "HTTP persistent"?
Unless your browser (or a peculiar server) says otherwise, yes.
Does the COMET technology of server push use this mechanism of HTTP
persistent connection to push data to
clients?
Kinda (for streaming, at least), but with a lot of whipped cream on top. There are other Comet implementation approaches, such as hidden iframes and AJAX long polling, that may not require persistent connections (which give some firewalls &c the fits anyway;-).
Actually, the HTTP server can "push" data to a connected http client without the client requesting it. See "HTTP server push" at http://en.wikipedia.org/wiki/Push_technology. However it does seem to be commonly implemented.