While transmiting data via localhost address or 127.0.0.1 which layers are used in the OSI model?
I believe communication starts through application layer and goes down till some layer but no data goes through physical layer, or does any?
Traffic to 127.0.0.1 will be looped back by the internet layer of the TCP/IP model, which is matched in the OSI model by the Network layer. This is the layer where routing and address resolution take place.
I believe (although I'd be happy to be corrected) that data may actually go down as far as Layer 2 ("Datalink Layer").
There's no need to add any protocol headers or encoding to handle loopback interfaces, but never-the-less the operating system will normally treat the loopback interfaces as if they were real interfaces, each with their own packet counters, etc.
There's no reason at all why a loopback interface can't be used for non-IPv4 protocols - indeed many current systems automatically put an IPv6 address on the loopback interfaces.
In that sense a loopback interface is just a "null" Layer 2 device.
Related
There's something I don't understand about TCP/IP stack : ports.
There's an IP to identify a machine and port for a specific process on that machine.
For me ports have to do with application layer ; there are some ports for some process (80 for HTTP, 25 for SMTP etc...). Ports have nothing to do with TCP layer (transport). Ports should be implemented at a higher level (application layer). So why do you say "TCP port" and not "application port" ?
Thanks
TCP or UDP ports are defined in either layer 4 of the OSI model or layer 3 of the TCP/IP model, both are defined as the 'transport' layer.
OSI layer 5 'session layer' uses the ports defined in layer 4 to create sockets and sessions between communicating devices/programs/etc.
Reminder about OSI model:
It is a conceptual model. That means it describes an idealized, abstract, theoretical group of networking functions. It does not describe anything that someone actually built (at least nothing that is in use today).
It is not the only model. There are other models, most notably the TCP/IP protocol suite (RFC-1122 and RFC-1123), which is much closer to what is currently in use.
The most important things to understand about the OSI (or any other) model are:
We can divide up the protocols into layers
Layers provide encapsulation
Layers provide abstraction
Layers decouple functions from others
Dividing the protocols into layers allows us to talk about their different aspects separately. It makes the protocols easier to understand and easier to troubleshoot. We can isolate specific functions easily, and group them with similar functions of other protocols.
Each “function” (broadly speaking) encapsulates the layer(s) above it. The network layer encapsulates the layers above it. The data link layer encapsulates the network layer, and so on.
Layers abstract the layers below it. Your web browser doesn’t need to know whether you’re using TCP/IP or something else at at the network layer (as if there were something else). To your browser, the lower layers just provide a stream of data. How that stream manages to show up is hidden from the browser. TCP/IP doesn’t know (or care) if you’re using Ethernet, a cable modem, a T1 line, or satellite. It just processes packets. Imagine how hard it would be to design an application that would have to deal with all of that. The layers abstract lower layers so software design and operation becomes much simpler.
I'm new to ruby and rails. I'm working on windows 10. Rails server is starting on tcp://0.0.0.0:3000 instead of http://localhost:3000. I'm using the following command.
rails server
When your Rails server says that it started on tcp://localhost:3000 , that actually means http://localhost:3030 , and on Windows machines you have to use http://127.0.01:3030 instead or else Windows messes it up somehow. Magic!
I think you are a bit confused with some basics in networks. I'll take the chance to clarify this to you.
Based on the Open Systems Interconnection model (OSI model) https://en.wikipedia.org/wiki/OSI_model
There are 7 layers to standardize the communication functions.
TCP is at Transport layer
The transport layer provides the functional and procedural means of transferring variable-length data sequences from a source to a destination host, while maintaining the quality of service functions.
The transport layer controls the reliability of a given link through flow control, segmentation/desegmentation, and error control. Some protocols are state- and connection-oriented. This means that the transport layer can keep track of the segments and re-transmit those that fail delivery. The transport layer also provides the acknowledgement of the successful data transmission and sends the next data if no errors occurred. The transport layer creates segments out of the message received from the application layer. Segmentation is the process of dividing a long message into smaller messages.
OSI defines five classes of connection-mode transport protocols ranging from class 0 (which is also known as TP0 and provides the fewest features) to class 4 (TP4, designed for less reliable networks, similar to the Internet). Class 0 contains no error recovery, and was designed for use on network layers that provide error-free connections. Class 4 is closest to TCP, although TCP contains functions, such as the graceful close, which OSI assigns to the session layer. Also, all OSI TP connection-mode protocol classes provide expedited data and preservation of record boundaries. Detailed characteristics of TP0-4 classes are shown in the following table:
HTTP is at Application layer.
The application layer is the OSI layer closest to the end user, which means both the OSI application layer and the user interact directly with the software application. This layer interacts with software applications that implement a communicating component. Such application programs fall outside the scope of the OSI model. Application-layer functions typically include identifying communication partners, determining resource availability, and synchronizing communication. When identifying communication partners, the application layer determines the identity and availability of communication partners for an application with data to transmit. The most important distinction in the application layer is the distinction between the application-entity and the application. For example, a reservation website might have two application-entities: one using HTTP to communicate with its users, and one for a remote database protocol to record reservations. Neither of these protocols have anything to do with reservations. That logic is in the application itself. The application layer per se has no means to determine the availability of resources in the network.
This means that TCP is not something else than HTTP. Basically, HTTP (Layer 7) is built on TCP/IP (Layer 4).
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
I know that MAC address is used for local routing and error free data transfer, but is it used regardless the transmission medium infrastructure? I know it is used for Ethernet, but is it used for fiber, copper...etc?
Also, do we use MAC address when routing traffic between two adjacent routers? If we do, does that mean we have MAC address over serial connections?
Thanks
MAC addresses are used in most IEEE 802 network technologies, like Ethernet (802.3) and Wifi (802.11), but not all technologies use them. For instance, Fibre Channel use a different and more modern address type, called World Wide Name. It's longer and can be 64-bits or 128-bits.
So, to answer your questions, a router can use MAC addresses if it forwards packets over Ethernet interfaces, regardless of the physical medium. But it could also use other technologies or even label-switching protocols like MPLS. A serial link does not have medium access control and therefore has no MAC layer.
is it used regardless the transmission medium infrastructure? I know it is used for Ethernet, but is it used for fiber, copper...etc?
You mix OSI layer 1 (transmission medium) and layer 2 (Ethernet). If we use Ethernet as our data link layer, Ethernet MAC addresses will be there regardless of transmission medium. More on that on Wikipedia:
https://en.wikipedia.org/wiki/OSI_model
do we use MAC address when routing traffic between two adjacent routers?
Yes, if the router are connected using Ethernet. Even if we use a back-to-back cable to connect two routers.
does that mean we have MAC address over serial connections?
For the most of serial connections we do not use Ethernet, but use other layer 2 protocols, like ppp, Frame-Relay or HDLC. Note, that all of those protocols use their own addressing, but it is just one or two bytes, not 6 as in the Ethernet MACs. More on those protocols on Wikipedia:
https://en.wikipedia.org/wiki/Point-to-Point_Protocol
https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
https://en.wikipedia.org/wiki/Frame_Relay
I am developing an application which aims to simulate a real network. In order to do this, I need to have detailed information about how a packet is formed in a system.
Imagine you have an application layer message and you want to encapsulate it in a transport layer payload and add a specific port number for desired process in the header, and then encapsulate it in network layer payload and add IP addresses.
My question is that
Where does the encapsulation of upper layer protocols' packets to lower layers happen?
Is network card driver responsible for that or some other part in OS? and if so, which part?
I just want to note that I’ve read computer networks: A top down approach and Foruzan's book on the subject but all the information there ,was so theoretical.
Thanks in advance.
If you are asking about a real implementation, usually every message of a layer is conveyed as the whole payload of the lower layer message. Talking about TCP/IP stack in an OS like Windows or Linux, without SSL/TLS, this depends on the types of sockets you use. Supposing you use TCP, STREAM sockets, the application layer message you send with send or write system calls will become the payload of the TCP message. The processing of a TCP segment and an IP datagram happens in the OS Kernel. The processing of a layer 2 frame happens part in the NIC's device driver (in the kernel) and part in the NIC hardware. This depends on the specific NIC.
Something else to add is that some NIC's are able to calculate the checksum of TCP segments and UDP datagrams. Then the kernel offloads this task to the NIC. Only the checksum.
Here is a wireshark capture of an ARP request PNG image, I contains the sender MAC inside the ARP packet. The receiving station can derive the MAC from the Ethernet frame. It seems to be redundant. Is there any particular use of separately including the sender MAC address in ARP Request too ?.
The "redundancy" was by design (RFC 826), and can be useful in targeting different layers. In RFC 3927 there's what is known as Gratuitous Address Resolution Protocol (GARP), and in certain circumstances the redundancy, or lack of, plays an important role, especially in troubleshooting and monitoring networking stacks.
Actually it's not rendunancy at all, the MAC (physical, layer 2) and IP (logical, layer 3) addresses are not the same thing. They serve different purposes on different network layers.
On large scale networks it's quite common to observe changes in the MAC/ARP/Source/Dest information, and at times can seem almost incorrect. For example, you might see a host send an ARP request with its own address as the target address. Depending on the exact situation, it might be telling us it's a link up/down event, maybe it's trying update other devices ARP tables, or possibly detecting an ip conflict and moving the ip to another NIC.
I could get into clustering, failovers — the list goes on, although I would end up writing a book trying to explain it all. Hopefully this gives you a bit of insight about the "redundancy" you were questioning. ;-)
More Info:
RFC 826 /
RFC 3927
/ Wireshark Gratuitous ARP
Although often used in conjunction with Ethernet, ARP by itself is an independent protocol. Imagine other link layer protocols that do not expose MAC addresses. ARP would not work in such circumstances if the sender field was not provided.
There is no rule that the ARP protocol field sender mac address to be same as ethernet source mac address. Eg: Its possible in few applications where multiple interfaces of same host are on network, but one only interface sends arp responses for all interfaces.