Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
Well, first of all I am new to networking.
And I have studied the layered structure of tcp/ip protocol stack.
I know that the layered structure is an abstract model, but I didn't know how the protocol stack is implemented in an operating system.
How is an HTTP message created?
Where does the TCP live and how is data segmented at the transport layer? Etc..
Please help me and correct me where I am wrong
Each layer in the stack has its very own function and all layers together form the complete functionality, the "stack".
Ethernet (physical and data link layers) transports packetized data in frames within a local segment. While the physical size of this segment can be many km, it's usually much more limited, to a building for instance.
IP (network layer) uses this functionality and puts logical addresses on top that can be routed on a global scale. Its IP packets are wrapped in Ethernet frames for delivery in a local segment. Multiple segments = IP subnets are connected by routers. Frames can't cross routers but the IP packets inside can.
IP is still only transporting readily packetized data. In order to get a data stream that an application can easily use, a transport layer protocol like TCP creates a virtual, bilateral, stream connection (a socket) that is very similar to a simple, serial connection - think of a telephone call between two parties. The inner workings of TCP are far more complicated than most things on the lower layers and not so easy to grasp. The beauty is that you don't necessarily need to know how it works in order to use it.
HTTP is an application layer protocol that makes use of this socket connection to GET a resource from a web server (a web page, graphics file, ...).
Because TCP does all the packetizing and reassembly work, and IP does all the work traveling across the globe, and Ethernet does all the work messing with the cables and hardware interfaces, HTTP can concentrate on its own job and keep it (rather) simple.
This is a simplified, rough overview. Of course you can use other physical and link layer protocols with IP, but Ethernet is extremely popular. You can also use other transport protocols on top of IP, depending on the application's requirements. And obviously, you can use an extremely large variety of application protocols on top of TCP or UDP or whatever.
The key to packet networks is that you can run all of this together in a single, extremely multi-functional network.
Your question is very broad, but I will give you some broad answers because the detail is far too large for this site. You are also touching on topics not allowed here, e.g. protocols above OSI layer-4 and applications.
How http message created?
HTTP is an application-layer protocol (off-topic here), and the messages are created by the application.
Where did the tcp live how data is segmented at transport layer?
The host OS implements TCP and other transport protocols. A source application will send a stream of data to the source TCP, and the source TCP will handle all the segmentation and delivery of the segments to the destination TCP, where the data stream is reassembled for the destination application.
You should read and understand the RFCs for things like TCP and IP. Simply search fo something like rfc tcp or rfc ip. The definition of TCP is in RFC 793, Transmission Control Protocol. This will give you a full explanation of how TCP works, including how it segments a data stream.
The internet was built to interconnect a diverse range of computer systems over a diverse range of networks.
In general therefore internet standards focus on what is seen on the wire. The details of how those processes are implemented on any given host were dependent on the design of the host operating system.
In practice on the vast majority of hosts there is a split between the network stack which is part of the OS (usually in the kernel) and the applications that use it.
To carry information across this split an API is needed. Variants of the "Berkerly Sockets" API became the norm across all major operating systems. For Unix-like systems a variant of Berkerly Sockets was standardised as part of Posix. Winsock on windows is also a variant of this API.
There is also typically some stuff implemented in userland libraries. For example on Unix-like systems name resoloution is usually handled by libc (which is part of the OS but not part of the kernel).
The core Berkerly Sockets API was not defined in a RFC, though many extensions to it were.
Note that the Berkerly Sockets API uses the term socket differently from the TCP RFC. A socket in the berkerly sockets sense is an operating system object that represents a communication interface between the application and the OS.
With TCP the application works with a stream of bytes. These are passed to and from the OS using a file-like interface. On unix-like systems the socket is actually represented by a file descriptor and applications can use either the send and recv calls provided by the sockets api or the normal file descriptor read and write calls. On windows sockets have their own type of descriptor and the application must use the send and recv calls provided by the sockets API.
