Some said HTTP is in the session layer in the OSI model.
But in Tanenbaum's Computer Network, HTTP is said to be in the application layer in the OSI model.
Also some said that HTTP has no concept of session. Does it mean that HTTP can't be in the session layer?
So is HTTP in the session layer? Thanks.
Update: For HTTP/2 what is the layer in OSI model?
In which layer is HTTP in the OSI model?
It's in the application layer. See the following quotes from the RFC 7230, one of the documents that currently defines the HTTP/1.1 protocol:
The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems.
HTTP is a stateless request/response protocol that operates by exchanging messages across a reliable transport- or session-layer "connection".
Also some said that HTTP has no concept of session. Does it mean that HTTP can't be in the session layer?
As previously mentioned in the quotes from the RFC 7230, the HTTP protocol is stateless, where each request from client to server (should) contain all of the information necessary to understand the request, without taking advantage of any stored context on the server.
The RFC 6265 defines some mechanisms for state management in HTTP, such as cookies, allowing session management on server side (but it doesn't make HTTP stateful in any ways).
The concept of session in HTTP is different from the concept of session in the OSI model. Anyways, HTTP is an application layer protocol.
The OSI model
The OSI (Open Systems Interconnection) model is a conceptual model created by the International Organization for Standardization which enables diverse communication systems to communicate using standard protocols.
It provides a standard for different computer systems to be able to communicate with each other and can be seen as a universal language for computer networking. It’s based on the concept of splitting up a communication system into seven abstract layers, each one stacked upon the last.
The following picture borrowed from Cloudflare illustrates pretty well what the OSI model is like:
The application layer is the only layer that directly interacts with data from the user. So software applications like web browsers and email clients rely on the application layer to initiate communications.
But it should be made clear that client software applications are not part of the application layer: rather the application layer is responsible for the protocols (such as HTTP and SMTP) and data manipulation that the software relies on to present meaningful data to the user.
The OSI model vs the TCP/IP model
While the OSI model is comprehensive reference framework for general networking systems, it's important to mention that the modern Internet doesn’t strictly follow the OSI model.
The modern Internet more closely follows the simpler Internet protocol suite, which is commonly known as TCP/IP because the foundational protocols in the suite are the TCP (Transmission Control Protocol) and the IP (Internet Protocol).
The following image illustrates how the OSI and TCP/IP models relate to each other:
Update: This section has been added to address the bounty started by noɥʇʎԀʎzɐɹƆ, who requested to update this answer with HTTP/2 details.
Despite the quotes of the document that defines the HTTP/1.1 protocol, all of the above also applies to HTTP/2. Refer to the following quote from the RFC 7540, the document that defines the HTTP/2 protocol:
An HTTP/2 connection is an application-layer protocol running on top of a TCP connection. The client is the TCP connection initiator.
The HyperText Transfer Protocol (HTTP), is the Web’s application-layer protocol,
is at the heart of the Web. It is defined in [RFC 1945] and [RFC 2616].
HTTP is in the Application layer of the Internet protocol suite model and in the Session Layer of the OSI Model. The Session layer of the OSI Model is responsible for creating and managing sessions and is the first layer that passes data.
HTTP can redirect sessions, reuse them and have persistent connections.
Related
I was wondering how HTTP is stateless while its built over TCP which is stateful ?
I'm still begineer backend engineer and I dont have solid understanding of this topics.
I tried to search for explanations but I'm not sure if this question has been asked before.
There are transport layer (TCP) states and application layer (HTTP) states.
When talking about TCP being stateful one is talking about transport layer states. TCP is stateful because a transport layer state consisting of current sequence numbers etc is needed to provide the reliability guarantees of TCP, i.e. ordering of packets, removing of duplicates, acknowledgements and retransmission. Thus a state spanning over multiple "units" (packets) is needed.
In HTTP this unit is the HTTP message, i.e. the HTTP request from the client and the HTTP response from the server. When talking about HTTP being stateless it means that there is no state inside the HTTP protocol needed which spans multiple such messages: a response strictly follows a request and there is no state covering multiple requests or responses - all requests are independent from each other from the perspective of HTTP.
Within web applications itself though some state usually is needed, like for a user session. These states are implemented on top of HTTP, usually with cookies shared between the requests. These states are then independent from a specific HTTP request and also independent from the underlying TCP connection.
I'm aware there are a lot of protocols at the application layer,
The question is more about when it is ok to not follow any of them,
Lets say i have a client and a server and the client app should send some data to that server, for instance, some statistics about a person using the app,
Now, for a good programming practice, is it ok to just open a tcp socket and send the data as is without the overhead of following a protocol or am i breaking the osi model and should i follow one of the protocols at the application layer?
Am i reinventing the wheel here or is it a practical solution?
There's always an application layer protocol. If your concept is to transmit some statistics to a server ''on a certain TCP or UDP port as a plain, decimal number'' then that is your (implicit) application protocol. The protocol enables the server to receive data and assigns a meaning to the number.
The OSI model is a model, not a law. In your application layer protocol you can do whatever you want.
However, it may be useful to anticipate future expansion of the service, so that you could e.g. transmit value_a:data\0value_b:data in one stream/datagram without having to keep client and server versions in perfect sync (with the server not expecting all values and just ignoring unknown values). Of course, you can also use a different server port each time instead - your choice.
HTTP is mainly used for viewing web pages. Coap is a simplified version of HTTP for IoT or WSNs. Although COAP is based on UDP, it should have ACK messages to emulate TCP. Since COAP is simpler than HTTP, it will have lower latency and draw less power.
Then, why browsers and web servers do not replace HTTP with COAP? Given the previous arguments, is it expected that COAP will completely replace HTTP? Is it just a matter of time? Are there any features which are supported only by HTTP?
If coap is more efficient, can I say that http is useless in the future if we replace them to coap?
The industry plan is to improve HTTP by moving to HTTP/2, and HTTP/2 includes (amoung other features) a header compression, which should bring you similar benefits than CoAP.
While most web servers and some browsers today support HTTP/2 already, AFAIK no browser nor any server support CoAP. Same goes for TLS vs. DTLS.
Are there features coap cannot support but http can?
As you said, HTTP is TCP based, while CoAP is UDP based.
UDP requires that you send UDP pings every few seconds to keep the NAT/Firewall connection open, while in TCP typically it is only required every 15 min or so.
So if you need to keep the connection open (e.g. for push technologies), then CoAP is less efficient than HTTP (and HTTP/2).
CoAP was never intended to replace HTTP, while it seems to "emulate" http, it only because it follows the REStful Paradigm. CoAP is intended as a application layer for device and more specifically was design for Constraint device.
The REStful design was chosen also to facilitate proxying operation through http (there are recommendation for doing that in the RFC). But again was never intended to replace HTTP.
CoAP is build with small amount of resources in mind. The small header and different feature of CoAP are in place to make sure that constraint device have standards mean to communicate on the internet.
HTTP and CoAP each have their own purpose.
CoAP and HTTP con be used for different purposes. CoAP has been implemented for IoT and M2M environment,in other words,to send short messagges using UDP. For instance:
A typical CoAP exchange consists of 2 messages, i.e., a request and a
response. In contrast, an HTTP request first requires the client to establish a TCP
connection and later terminate it. This results in at least 9 messages for only one
request [11]. Note that this argument is not necessarily true for large payloads. After
TCP’s slow-start phase, it is able to send multiple packets at once and acknowledge
all of them with a single acknowledgement. CoAP’s blockwise transfer [8] though,
requires an acknowledgement for each block and leads to more messages and higher
transfer time. Since we expect the majority of CoAP messages to be rather short, this
is of less importance. However, CoAP’s blockwise mechanism allows a constrained
server to not only receive but also process a large request block-by-block. This
would not be possible if we used HTTP and TCP.
(Scalability for IoT CLoud Services by Martin Lanter)
Actually, Firefox can support CoAP using Copper(CU) plug-in. ;)
CoAP is optimized for the resource constrained networks and devices typical of IoT and M2M applications. It uses less resources than HTTP and can provide an environment for communication in WSNs, IoTs, and M2M comm. It is not made to replace HTTP.
HTTP has different application scenarios, while CoAP has a different one. HTTP is mainly designed for Internet devices where the power and other constraints are not an important issues. HTTP is more reliable than CoAP as it uses TCP.
HTTP,the protocol residing over TCP protocol is stateless and also the IP protocol is stateless
But how can we conclude that TCP is stateless or not?
You can't assume that any stacked protocol is stateful or stateless just looking at the other protocols on the stack. Stateful protocols can be built on top of stateless protocols and stateless protocols can be built on top of stateful protocols. One of the points of a layered network model is that the kind of relationship you're looking for (statefulness of any given protocol in function of the protocols it's used in conjunction with) does not exist.
The TCP protocol is a stateful protocol because of what it is, not because it is used over IP or because HTTP is built on top of it. TCP maintains state in the form of a window size (endpoints tell each other how much data they're ready to receive) and packet order (endpoints must confirm to each other when they receive a packet from the other). This state (how much bytes the other guy can receive, and whether or not he did receive the last packet) allows TCP to be reliable even over inherently non-reliable protocols. Therefore, TCP is a stateful protocol because it needs state to be useful.
I would also like to point out that while HTTP and HTTPS (which is just HTTP over SSL/TLS, really) are essentially stateless (each request is a valid standalone request per the protocol), applications built on top of HTTP and HTTPS aren't necessarily stateless. For instance, a website can require you to visit a login page before sending a message. Even though the request where the client sends a message is a valid standalone request, the application will not accept it unless the client authenticated herself before. This means that the application implements state over HTTP.
On a side note, the statefulness of HTTP can be somewhat confusing, as several applications (on a clearly different OSI layer) will leak their state to HTTP. For instance, if a user tries to view a blog post that doesn't exist, the blog application might send back a response with the 404 status code, even though the file handling the blog post search itself was found.
tl;dr TCP is stateful.
While Zneak points out that you can use any communication for stateful purposes, the ACTUAL question being asked is whether the protocol itself is stateful.
Wikipedia:
In computing, a stateless protocol is a communications protocol that
treats each request as an independent transaction that is unrelated to
any previous request so that the communication consists of independent
pairs of requests and responses. A stateless protocol does not require the server to retain
session information or status about each communications partner for
the duration of multiple requests. In contrast, a protocol which
requires keeping of the internal state on the server is known as a
stateful protocol.
TCP's "request" (unit of communication) is a TCP packet.
TCP a stateful protocol since parties must remember what state the other is in, and what bytes the other has. Hence the TCP state diagram.
In contrast, UDP is a stateless protocol. Neither endpoint retains any notion of state. (Though as always, the encapsulated information could be used for stateful purposes.)
Here is a nice explanation :
Consider the phone service to be TCP and consider your relationship with distant family members to be HTTP. You will contact them with the phone service. Each call to them would be a stateful TCP connection. However, you don't constantly stay on the phone with them, as you will disconnect and call them back again at a later time. You would certainly expect them to remember what you talked about on the last call. HTTP in itself does not do that, but it is rather a function of the web server that maintains the state of the overall converstation.
To properly answer the question, we need the concept of a stateless protocol used to manage external stateful resources. Section 2.4 of http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/ws-modelingresources.pdf is about a service that implements such a protocol:
A Service that acts upon stateful resources may be described
“stateless” if it delegates responsibility for the management of the
state to another component such as a database or file system. ... A
consequence of statelessness is that any dynamic state needed for a
given message-exchange execution must be:
provided explicitly within the request message, whether directly by-value or indirectly by-reference, and/or
maintained implicitly within other system components with which the Web service can interact.
So, the http protocol is stateless, if we consider that the files that are served, the database that is accessed, etc. are separated from the implementation of the protocol itself. A service (which implements a protocol) that is stateless in relation with both sides taken together might not appear stateless on each side, because the other side can carry a state.
I would like to understand what happens when we type "google.com" in our browser wrt OSI model. What all protocols comes into picture AT EACH LAYER any how does they know which one to be used?
Also I would like to know, TCP/UDP which one to be used in Transport layer is decided for network/application? That is for a normal web page like google.com TCP must be used but for video streaming UDP. how is this conveyed to network?
Is the browser also part of this as it is helping. Should it also come under application layer?
Http comes under Application layer of OSI model. now for this particular example, what will come under Presentation and Session layers? Will the sessions be maintained in session layer or HTTP will be doing it on their behalf?
It sounds like you would like a tutorial on TCP/IP. May I suggest a couple of good books
URLs in webpages have a prefix that tells the applications what to do with that link. For instance, ftp:// opens an ftp session, which uses tcp (ref RFC 959 - File Transfer Protocol). As a general rule, the URL prefixes correspond to a standardized protocol, which was specified via RFC. The RFC denotes which transport protocol is used.
EDIT
In the case of youtube, their videos have a http:// URL prefix, but after you make the request, it is redirected to a rtsp:// URL. RTSP can be streamed over UDP.
To answer questions like this, you may find that wireshark is very useful to investigate these things... keep in mind that wireshark works best on wired connections.
Applications don't use any layer of the OSI protocol stack. They use TCP or UDP from the TCP/IP stack, and they 'know which' because of they are programmed to use one or the other or both. The OSI model is obsolete and certainly doesn't apply to TCP/IP.
EDIT: The OSI layer model is a Procrustean bed into which TCP/IP does not fit. You should forget about OSI immediately. It doesn't describe anything in the real world.