I read in Wikipedia, an expression "IP-based protocol".
Do we have any "non-IP-based protocol"?
What are other protocols which are not "IP-based protocol"?(what is the similar categories?)
Access to a certain IP address is denied. If the target Web site is hosted on a shared hosting server, all websites on the same server will be blocked. This affects IP-based protocols such as HTTP, FTP, and POP.
https://en.wikipedia.org/wiki/Internet_censorship#Content_suppression_methods
The actual meaning of IP-based protocol is that if some protocol(Like TCP, HTTP, POP, FTP, TLS/SSL) uses IP protocol in the internet layer of TCP/IP model for the transportation of their actual data.
HTTP is a application layer protocol which uses IP in internet layer.
There can be non-IP-based protocol if they do not uses IP protocol at all. For example all protocols of data link layer are can be said non IP based or we can say they do not uses the services of IP. Eg. ARP, NDP, OSPF
Related
Actually i have three Questions in this regard
IP ADDRESS:- Does router and default gateway same? if same , then why router (internet IP) address is public and Gateway IP address is local (i mean why both are different)
MAC ADDRESS:- what is the difference between WAN MAC address and ROUTER MAC address and Default Gateway MAC address , why are they different?
Difference between Data packets and IP packets? are data packets travel from a host to a remote server present in some other country through submarine cables or through router to router by hop-by-hop transport?
I am a new learner , please don't get angry if i asked something silly
Router and gateway are essentially the same - a gateway provides access to remote subnets. The hardware for that is called router. Routers route between networks.
A default gateway is a gateway to provide access to all subnets that are not specifically configured. At a minimum, a host requires a default gateway to connect to the Internet.
IP addresses are configured on (logical) interfaces. A router usually requires at least two interfaces, each configured with an IP address from the connected subnet.
Likewise, a MAC address is required for a physical interface - specifically for the data link layer to work (OSI layer 2). It uniquely identifies interfaces within a network segment and is used by network switches for forwarding.
A data packet can be many things. An IP packet is a packet (also protocol data unit PDU) on the network layer (OSI layer 3). IP packets travel between hosts around the globe and transport user data (payload) between them.
User data is actually transported by an application-layer protocol (e.g. HTTP) that in turn uses a transport-layer protocol (e.g. TCP) between processes/applications. The transport layer uses the network layer (IPv4 or IPv6) which in turn uses the data link layer (e.g. Ethernet) which in turn uses the physical layer (physical interfaces and cables).
if when i try to connect with webRTC from outside the local network, it uses a STUN server to exchange info like ip address, port..., and then once the two clients know each other they will directly connect, but the thing is, if any router by default blocks any port that's opened exept for 80, then how do the two clients connect, on what port?
WebRTC is an open framework and does not dictate how the connections are established between the communicating peers. Establishing the connection itself involves the following.
1-The peer discovery is made via Signaling for doing SDP exchanges and exchanging remote host identities. The Signaling can be done over any transport – UDP/TCP, any protocol and via any standard (SIP/XMPP) or custom application level protocol over HTTP/WebSockets etc. The choice of Ports for signalling traffic is left open to the application developer.
2-Once the peer discovery is complete, and the PeerConnections are established at each endpoints, the media data can be sent. Depending on the network topology of the Peers (whether they are in the same host network, or they are in different network (behind Nated IP address), they can choose to connect such that the media traffic is sent over UDP or over TCP. For a more protected environment, the peers may even need a TURN server to relay the media traffic on Peers behalf. Here again, the choice of Media Ports is left open and can be decided via the end application.
I found this on web I hope its helpful
As far as i know what we get from a dns query is a ip address. So in the end of the day if thats true we are still using ip addresses to connect the server and domains are pretty names for them.
So how does a server know which domain i used to query that ip address?
How does vhosts work an understand that if the domain data is lost during dns query?
The Internet works in layers. Each layer uses different kind of parameters to do its work.
Layer 3 is typically IP aka Internet Protocol. To work it uses IP addresses, each computer has at least one to be able to discuss with another one. And there are two families in fact: version 4 and version 6.
Since multiple services can be on any given computer at some point, you need a layer on top of that, layer 4, that deals with transport. The "predominant" one is TCP aka Transport Control Protocol, but there is also UDP. TCP and UDP uses ports: a 2 bytes integer that encodes for a specific protocol.
For example, HTTP was given port number 80 (completely arbitrary), and HTTPS port 443.
The DNS, which itself uses UDP and TCP (on port 53), allows, among other things, to map a given hostname to a given IP address or multiple IP addresses. This is the typical A and AAAA records. There is also a CNAME record that maps one domain name to another. There also exists a SRV record that maps a service (which is a protocol name + a transport) to a given hostname and port number.
When one computer connects to another, its first step for all the above is to find out which IP address to use to connect to. It can use the DNS for that. Typically it will get only the IP address, but, depending on the protocol (layer above 4), may also get a port (if using SRV records).
The HTTP world does not use SRV records. So a browser just uses the hardcoded 80 or 443 ports, or the port number appearing in the URL.
Then we are at the transport level, let us say TCP.
The connection is done (since now the remote IP address and port are known) and the protocol above TCP, like HTTP, is free to convey any kind of extra data, such as the hostname that the client initially used (as taken from the URL) to find out the IP address.
This is done through the HTTP host header, see RFC 2616
Note that if you do things through TLS (which conceptually sits between TCP and HTTP) there is even something else happening: SNI or Server Name Indication.
When doing the TLS handshake, so before any kind of HTTP headers or content, the client will send the final hostname desired in some specific TLS message. Why? So that the server can find which specific certificate it should answer which as otherwhise it would not be able to know which hostname is requested as this sits in some HTTP header which do not exist until the TLS handshake is finished.
A webserver will be able to see both the SNI content to find out which certificate to send back and then the host header to find out which VirtualHost (in Apache) section is relevant to the query being processed.
If you are not in HTTP world, then it all depends on the protocol used. Older protocols, like FTP, did not plan for "multihoming" at the beginning, a given IP address meant only one hostname and service for example.
How actually DNS will work based on different layers of OSI? I mean when we will type google.com, it will mapped IP Address of google.com with its domain name.But when we are not knowing the IP address of Authoritative DNS server, so how it will move to different Layers of OSI (TL,NL, DLL) of our system to Authoritative DNS Server?
Your assumption is not correct, as in reality the DNS works as a application layer service. It is not a layer-to-layer service of OSI layers.
DNS is an application layer service that uses UDP, which is part of the TCP/IP stack.
When we type www.google.com, it is the workhead of application referred to mapping into IP-Address.
The application will invoke the client side of DNS, specifying the hostname that needs to be translated. (On many UNIX-based machines, gethostbyname()a Web Browser or a mail reader) is the function
call that an application calls in order to perform the translation.) DNS in the
user’s host then takes over, sending a query message into the network. All DNS
query and reply messages are sent within UDP datagrams to port 53. After a delay,
ranging from milliseconds to seconds, DNS in the user’s host receives a DNS
reply message that provides the desired mapping. This mapping is then passed to
the invoking application. Thus, from the perspective of the invoking application
in the user’s host, DNS is a black box providing a simple, straightforward translation
service. But in fact, the black box that implements the service is complex,
consisting of a large number of DNS servers distributed around the globe, as well
as an application-layer protocol that specifies how the DNS servers and querying
hosts communicate.
SOURCE: Computer Networking: A Top-Down Approach.
I was wondering that how application like skype ( a popular chat client ) works in local network with one router, How it can listen on particular port?
for example:=
In one network A and B are two machines running skype , gateway of both is G1,
now how A and B will have same IP on internet that is of G1, but how can they ensure that they are listening on different ports? How can they ask to router G1 for unique port.
I want to make a simple text chat server on linux. How can I have connections between two different computers in two different networks?
Solution to your problem is to have a forwarding server somewhere in the net.
Different programs use different means to connect to each other. But every chat server, including Skype, has a server, which forwards data or information about subnet IP/port availability.
There are two types of clients: "listening" clients and "passive" ones. Listening clients have direct access to Internet via router port forwarding, and "passive" ones have to use additional tricks to get their hands on external data, line external servers or additional ports to listen.
The point is, not clients connect to each other, but they connect to a server, which then connects back to them to verify they are available, and, if at least one of them is not firewalled, direct another on to connect to the first one, excludint itself from further communication. And if both are firewalled, then is has to forward their messages through itself.
Host Discovery
Manual discovery, client A knowns who client B is
Discovery through broadcast UDP which is used by lot of games for LAN play. A client sends out a packet to the broadcast address for their subnet. The peers can choose to pick up this broadcast and respond. The downside is that this is limited to the current subnet. The more general INADDR_BROADCAST (255.255.255.255) works for all subnets on the local-link, but it cannot be routed, so won't work over internet (this is what DHCP auto-configuration uses).
Discovery through a central (Rendezvous) server. Each individual client knows the address of the server, and the latter informs them about each other. This technique is used by IRC, Voip, IMs and by most 'peer-to-peer' networks.
Communication
After the initial discovery is done you want to be able to talk to eachother. On the internet this can get tricky. Most people nowadays have their own router and sit behind a NAT, so direct connections are impossible.
Using a Rendezvous server, you can possibly talk to each other using the server itself. client A tells the server what to say, and it in turn tells client B, since both clients have an outbound connection to the server.
It is possible for the clients to talk to each other without the server proxying. This requires either DMZ, port forwarding or UPnP. DMZ will basically forward all incoming connections on all the ports to a given local IP. Port forwarding only forwards certain ports to local IPs. UPnP is a bit more advanced, the client requests that the router temporarily forwards a port to it, and you tell the other client via the rendezvous server where to connect.
Chatting app implementation
The easiest solution to your problem is most likely to use a central server, which is known by all the clients, that proxies host discovery and possibly the communication between the clients. If you want the clients to communicate directly, you can just proxy host discovery, and then let either DMz, manual port forwarding or UPnP do the rest.
Another solution would be to just have direct communication through NAT traversal techniques discussed above, and do manual host discovery.
Yet another solution would be to use a public webserver and 'abuse' its ability to insert content to chat with each other.
You need a central UDP Rendezvous Server.
After the initial connection from the client to the server the UDP clients can be redirected to talk to eachother directly even if firewalled.
The trick is to open an UDP connection from the inside.
Check out Real-Time Media Flow Protocol and how they use it.
Check out UDP Hole Punching
alt text http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
Traditional NAT servers replace the source address and port with the address and a random port number of the external interface of the NAT server. This works well for simple protocols such as HTTP and SMTP, but it can create problems for more complex protocols that require multiple response ports on the external interface of the NAT server. NAT servers also aren’t aware of information stored in the data portion of the application layer header without the help of NAT editors and similar software fixes.
Windows XP’s answer to these problems is NAT Traversal, which can automatically allow the UPnP-enabled NAT client application to communicate with a UPnP NAT device. NAT Traversal provides methods to allow the UPnP client to learn the public IP address of the NAT server and to negotiate dynamically assigned port mappings for UPnP NAT client applications.
NAT Traversal features can be built into any hardware device or software application. Applications that commonly cause troubles for NAT devices but work well when UPnP-enabled include the following:
Multiplayer Internet games
Audio and video communications
Terminal Services clients and servers
Peer-to-peer file sharing applications
When these applications are UPnP-enabled, access through the Windows XP ICS allows them to work seamlessly.
Unless A and B are actually "listening" to the responses to outgoing requests, your router will need to be cofigured to forward the relevant port numbers to the relevant hosts. This isn't something that you can request in the code, it's something you need to configure on the router itself.