What happens after host receives physical data from router - networking

I know that when two machine communicate they may use the TCP/IP protocol.. But after the IP packet is routed to my router and it is converted to physical signal , how does my computer again decapsulate it and send it to proper application....I know that transport layer header is used for identifying port numbers to send it to proper process,but which device will do all these inside a host..am new to network and apologize if something was wrong or silly here

A packet comprises of information in the form of [header[body]] which will be looked up and processed across all the layers in the TCP/IP stack.
The information related to the all layers are encapsulated into a single packet.
Packet being a general term here, can be of many types based on the protocol with which two nodes are communicating (TCP Packet, UDP Packet, IP Packet etc). The information from a TCP/IP packet for example, are processed by different devices or services working at specific layers.
Switches or Bridges operate at the Ethernet layer. These devices switch packets inside LAN by looking up the MAC address information.
Routers operate at the Internet Layer and utilizes the IP protocol (i.e., IP address) to route traffic between networks.
Stateful firewalls, Proxies, Load Balancers etc. are at the transport layer. They work based on the TCP or UDP information to allow/deny/direct traffic.
Application layer facilities effective communication between application programs in a network. The application layer is not the application itself that is doing the communication. It has protocols such as DNS, FTP, SMTP, SNMP to help and serve the purpose.
References:
https://docstore.mik.ua/orelly/networking/firewall/ch06_03.htm
https://technet.microsoft.com/en-in/library/cc786128(v=ws.10).aspx

Related

How does tcp/udp connection works?

I would like to ask a general newbie question. I understand that for a computer in location A to connect to a server in location B, packets of data have to be sent to multiple data centers through multiple gateways and through multiple verification channels to ensure the connection request finds the right destination.
However after the connection is established, when the computer and the server send/receive data, do these data still need to go through [multiple data centers through multiple gateways and through multiple verification channels]?
Every TCP / UDP packet can have a different network path between source to destination. However the connection establishment of a TCP connection being stateful is all about what packet size, compression method etc.
At network layer- Connection is stateless. Please read about OSI model in detail also you can refer to this https://www.ccnahub.com/wp-content/uploads/2013/09/watermarked-pc1-comm.jpg It has good explanation of how OSI works.
A TCP packet being sent from computer A to computer B will be addressed to a particular IP address. If that TCP address is not on the local LAN, it will go first through the local LAN to whatever is designated as the local gateway. That gateway then sends it on over the connection to an external network. At that point, it will be delivered to some router in your ISP. That router will look at the destination IP address and consult a routing table to find where it should next send the packet. That will typically be another router elsewhere in the network. This continues and (assuming good routing tables in each router) the packet will get closer to its end desination on each hop. Eventually, the packet will get to a router that has a routing table that knows about either the actual IP address or the home gateway for that IP address and the packet will be sent to that gateway. That home gateway can then deliver the packet to that actual IP address. In some cases, there may be a private network at either end where private IP addresses/port combinations are converted to public IP addresses and vice versa.
If computer A sends multiple packets to computer B, they do not have to all go the exact same path, though typically they will (assuming no problems or congestion in the network between the two endpoints).
In this scenario where A and B are on different private networks, there is no direct connection between computer A and computer B so each packet has to follow the path from one router to the next until it arrive at the final gateway and then destination address.
However after the connection is established, when the computer and the server send/receive data, do these data still need to go through [multiple data centers through multiple gateways and through multiple verification channels]?
If the routers are doing their job appropriately, the very first packet takes the most efficient path from A to B that the network knows. There is no "better" way to send subsequent packets. Subsequent packets will follow the same process (to a router, router looks up in routing table where to send for next hop and so on). If the two endpoints are a long ways apart (in terms of network topology), then the packet may go through many routers. Routers are highly optimized pieces of equipment capable of passing off millions of packets a second as this is how data moves on any TCP/IP network like the internet.
There is no difference in how the first packet that initiates the TCP connection flows versus subsequent packets. At the network level, they are just packets traveling from a source IP address to a destination IP address. Once the connection is established, a reliability layer will be started to track packets that might get lost, initiate retransmissions, etc... but this doesn't have anything to do with how a given packet gets from A to B.

Where does Server stores source IP address extracted from incoming Packets during UDP transmission?

A packet reached the server of UDP type at Transport layer. When the source IP address is extracted from the received packet by the server (at Transport Layer), where does the server stores this address, as it will be required in future, since the connection between server and client is connection-less? Or what mechanism does server use to identify source (during a connection-less environment) in order to reply?
Why do you think the address is required in the future? It may not be.
Also, there is no such thing as client/server for the first four network layers of the OSI model. The client/server model is an application concept, not a network concept. Layer-2 (e.g. ethernet), layer-3 (e.g. IP), and layer-4 (e.g. TCP) are peer-to-peer protocols, not client/server protocols.
If an application on one host needs a reply from a host to which it sends data using UDP, it can include its host address as part of the UDP data in the application-layer protocol, and the receiving application can store the source IP and UDP addresses wherever it wants.
As you wrote, UDP is connectionless (and unreliable), and an application using UDP must assume that the UDP datagram will not arrive. The application either adds reliability as part of the application-layer protocol used, or it just doesn't care that some data will be lost. For instance:
Real-time applications use UDP, and some, like video applications are unidirectional. Others like VoIP use a signalling protocol to set up bidirectional traffic. Almost all real-time protocols don't want missing data to be resent because that would cause more problems. Having missing video or voice data resent, arriving out of order, would be chaos.

If IP is connectionless protocol then why does virtual packet switching is connection oriented?

We all say that IP is connection less protocol but network layer provides us with switching facility wherein we have packet switching under which, we have virtual packet switching which is connection oriented i.e resources are reserved on the way. Then why do we say IP is connection less as every packet travels in IP datagram?
Well I think that network layer has many other protocols which might use virtual ckt concept. IP uses datagram service, so it is connectionless. Because in datagram service packets go independently without any reservation of resources.

What is the technology behind port numbers?

I know that port numbers are used for identifying different processes running on a server, so that multiple processes can use the same networking resources. But how does it work internally?
For example, if a request to a website http://www.my-awesome-website.com:80 reaches a server, how does the server know that there is a web server running on port 80? I mean, what does the request pipeline look like between getting the request to finding out that a web server is running on port 80 and forwarding the request to the web server?
Port numbers are merely addresses for some transport-layer protocols, such as TCP and UDP, in the same way that IP addresses are for layer-3 protocols, and MAC addresses are for layer-2 protocols. Not all transport-layer protocols use ports, and each transport-layer protocol independently maintains its ports so that TCP port 80 is not the same as UDP port 80, and each can be used simultaneously by different applications.
Layer-2 addresses are only relevant to the LAN links, layer-3 addresses are only relevant host-to-host over the layer-3 network, and layer-4 addresses are relevant application-to-application.
IANA registers ports and maintains the official registry list at Service Name and Transport Protocol Port Number Registry.
From RFC 793, TRANSMISSION CONTROL PROTOCOL:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network
and host addresses from the internet communication layer, this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed
through the known addresses. Establishing and learning the port
addresses of other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for
each data stream. The combination of this information, including
sockets, sequence numbers, and window sizes, is called a connection.
Each connection is uniquely specified by a pair of sockets
identifying its two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid
erroneous initialization of connections.
After opening a socket(which is like an open file but used for network communications), the user of the socket may use it directly with an ephemeral port(selected by the OS), which is typical if the application is a client application.
What server processes do is to call the bind() socket API call to set a port for the socket, and then call listen() in case of a TCP socket to start listening for incoming connection requests.
Because of the bind() call the OS will know that this particular socket is the one receiving the data sent to the particular port number.
The packets sent over the network contain the source and destination IP addresses as well as the source and destination ports:
http://www.techrepublic.com/article/exploring-the-anatomy-of-a-data-packet/
So the OS has a data structure with open sockets listed by their port numbers and it will pass the received data to the correct socket's input buffer. Sent data will be marked by the port number of the sending socket.

Where is the source and destination address fields in TCP header?

From what I've read, TCP sits on the layer between the application and IP, and handles setting up the packets, checking for errors, ordering etc so the application itself doesn't have to do it.
However, when I looked at the TCP header I became confused. From the way I understand it, some data is handed to TCP from the application, and is given a destination address to which to send the data. The TCP layer packages it up, and sends it on to the IP layer, who in turn hands it off, all the way on down to the physical layer.
But looking at the TCP header on Wikipedia, there is no mention of a destination address! There is only a destination port number which I am pretty sure is not an address.
So my question is, how does TCP get the addresses? And/or, how does IP get the address if TCP isn't passing them to it?
It's the Application that's running on top of Transport Layer that chooses everything.
If the Application is designed with reliability in mind, it chooses the connection oriented protocol like TCP.
The same applications tells TCP what the Source and Destination port should be, TCP alone cannot decide this.
Example: If you're accessing a website, your Application would be the browser, since accessing websites normally happens over HTTP/HTTPS and HTTP/HTTPS is designed to be reliable, it chooses TCP. Port 80(HTTP) or 443(HTTPS) are the standard ports used for accessing websites, so either of these ports are used in the Destination Port field while the Source Port can be any random higher number port.
This combination is used to identify something called Transport Layer VC(Virtual Circuit).
Coming to IP, the same application tells what the Destination IP address is, while the Source IP is the machine from where you are running the browser.
IP in Network Layer and TCP in Transport Layer cannot choose anything, it's the Application that tells them what to choose, considering they are the chosen ones.

Resources