I have a question related to the correct interpretation of RFC 5246 (TLS v1.2), in particular concerning the fragmentation in the record layer.
"6.2 Record Layer" states that the record layer receives data from higher layers.
"6.2.1 Fragmentation" states that multiple client messages of the same ContentType may be coalesced into a single record.
Is the word client in the cited part of 6.2.1 related to the client in the communication relationship of TLS client and TLS server or is it related to the client of the record layer in the implementation of the stack, which is the "higher layer" mentioned in 6.2?
Thanks and cheers
Wolfgang
Related
My team wants to build a chat app and so we are researching about all the available technologies available at our arsenal. I am concerned about XMPP. So i was reading the Oreilly's "XMPP: The definitive guide", and came across these lines and i quote
In XMPP, messages are delivered as fast as possible over the network. Let’s say that Alice sends a message from her new account on the wonderland.lit server to her sister on the realworld.lit server. Her client effectively “uploads” the message to wonderland.lit by pushing a message stanza over a client-to-server XML stream. The wonderland.lit server then stamps a from address on the stanza and checks the to ad- dress in order to see how the stanza needs to be handled (without performing any deep packet inspection or XML parsing, since that would eat into the delivery time). Seeing that the message stanza is bound for the realworld.lit server, the wonderland.lit server then immediately routes the message to realworld.lit over a server-to-server XML stream (with no intermediate hops).Page 45
Like email, but unlike the Web, XMPP systems involve a great deal of inter-domain connections. However, when you send an XMPP message to one of your contacts at a different domain, your client connects to your “home” server, which then connects directly to your contact’s server without intermediate hops (see Figure 2-4).Page 13
Can anyone please make me understand how can there be no intermediate hops(unlike email).
E-Mail (SMTP) also has no intermediate hops. I assume you confuse the application OSI layer, where XMPP, SMTP and so on live, with the network layer (IP).
Let's say I have a simple 2-server NATS cluster with servers A and B.
If a client on Server A publishes a message to a Subject for which there are no subscribers on Server B, does that message still get sent from Server A to Server B?
Not sure what the goal is here but more details could help clarify the context. If you're asking specifically whether the nodes can pass messages published on another server to a subscribed client, yes.. how long will it stay? Depending on the defined expiration time.. what if the server goes down before it shares with the mesh, almost impossible but can happen.
Also, though you're probably just illustrating, even numbers are not generally advisable in clusters to avoid split-brain situations where it's impossible to locate the truth source (seed server in this case)..
Yes. NATS clustered servers will forward messages that it has received from a client to the immediately adjacent nats-server instances to which it has routes. Messages received from a route will only be distributed to local clients. There is not subscriber checks in the mesh.
It's not a black and white answer because NATS supports many deployment architectures with server to client communications, server to server cluster communications, and cluster to cluster communications through gateways to form super-clusters. Gateways for example optimize the interest graph propagation (i.e. only send data to other clusters if there is interest) Super-cluster with gateways documentation
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.
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.
From this site (http://www.ipv6.com/articles/general/IPv6-Header.htm) , it says:
Packet priority/Traffic class (8 bits) The 8-bit Priority field in the IPv6 header can assume different values to enable the source node to differentiate between the packets generated by it by associating different delivery priorities to them. This field is subsequently used by the originating node and the routers to identify the data packets that belong to the same traffic class and distinguish between packets with different priorities.
I was wondering, if it is possible to actually "hack" the TCP/IP stack in order to give your packets higher priority. Would you get any substantial gain in network performance. Also, if it is possible, how is it prevented?
Yes, it's possible, but it's not really hacking. There is a standard programming interface that will allow your program to indicate to the stack how it would like the Traffic Class header field to be populated.
Whether or not you will measure any performance difference depends on the network that handles your packets. Think of the Traffic Class field as a hint for the network; a suggestion for how you would like your packet to be handled. The network might ignore it, or even change it to a different code point. Furthermore, the notion of "priority" (also known as "precedence") as an interpretation of the Traffic Class field has receded into a much richer collection of Per Hop Behaviors (PHBs).
See IETF RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6. In particular, read the first part of Section 4, Access to IPv6 and Extension Headers, and Section 6.5, Specifying/Receiving the Traffic Class value.
Here is a code snippet that sets the Traffic Class field to the integer MY_TCLASS for all packets sent on the socket sk.
int tclass;
tclass = MY_TCLASS;
setsockopt(sk, IPPROTO_IPV6, IPV6_TCLASS, &tclass, sizeof(int));
Related reading:
IETF RFC 3493 Basic Socket Interface Extensions for IPv6
Section 5 talks about basic socket options
IETF RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
Section 7.1 discusses Theft and Denial of Service, which, from the point of view of a network operator, is what what you're asking about.
IETF RFC 2475 An Architecture for Differentiated Services
Section 2.1 covers a whole bunch of terminology.
I don't understand the question. You don't need to hack anything. There's an API provided for setting the TC on a socket. What effect it has depends on the cooperation of the intervening routers.
The source can change the priority but the routers and gateway will can change the priority depending upon the type of packet that is