1

I know there're ethernet,token ring,FDDI ,etc protocat the link layer,

but how to know the exact protocol used to perform a specific task,like browsing a web page?

kernel
  • 8,211
  • 5
  • 18
  • 14
  • 1
    this question is so vague it can't really be answered correctly. **ALL** OSI protocol layers are involved in browsing a web page... the individual protocol layers become more prominent as you start either debugging a problem, or coding a service to operate on them. The real question is, what problem are you solving with this knowledge? – Mike Pennington Apr 17 '11 at 19:10

5 Answers5

5

First you must understand something that the OSI model can help:

OSI Layers model

The protocols you are talking about are application protocols, and are handled on the Application layer, the contents of this layer are encapsulated and passed to the layer right after it (Presentation), and so on. So each layer only needs to know what format are the layers directly related to it.

That means that application protocols like FTP, HTTP and so on are not really recognized by the link layer, the link layer is only concerned about MAC addresses and talking to the Network and Physical Layers.

If what you want to know to what layer or what protocol is used for something, you can battle the IANA long listings or use the Wikipedia simplified list of protocols.

coredump
  • 12,573
  • 2
  • 34
  • 53
  • Still,how to know whether link layer is using ethernet or token ring protocol? – kernel Apr 17 '11 at 16:36
  • 1
    Ah, that was your question :) You check the hardware you are using, the physical layer is pretty specific and the hardware will sure tell you what kind of protocol it is using. – coredump Apr 17 '11 at 16:38
  • I don't think so,and I know for LAN the link layer protocol is ethernet,but not sure what is the one for WAN. – kernel Apr 17 '11 at 16:43
  • 1
    as @mgjk mentioned on his answer, the media and the protocol will change from your router forward. I am not sure if its possible to discover all the link medias on a path between 2 points. You could try using the MTU, but that's a completely wild guess. – coredump Apr 17 '11 at 16:45
3
  • The protocols are abstracted so that you don't need to know.
  • Even if you did know what Link-layer was used between you and the first hop, it will change on the route (Ethernet -> PPPoE -> ATM -> Serial ->.... )

There are tricks to reverse-engineer what might be going on. Depends on whether you're trying to visit a web page, or perform reconnaissance.

mgjk
  • 854
  • 3
  • 9
  • 19
  • How to do the tricks to reverse-engineer what might be going on? – kernel Apr 17 '11 at 16:40
  • You can use non-fragmenting packets of progressively decreasing size to try to learn something about the frame size of the networks you're traversing. Note that the MTU along the path will only decrease... never increase, so your knowledge will be very, very incomplete. The frame size is a hint as to the technology of the Link Layer. Another way as @coredump mentioned, for your first hop, you can use your MTU to give you a hint as to what you're on. (1500 Ethernet, 4464 Token Ring, 1492 PPPoE... ) – mgjk Apr 17 '11 at 17:39
3

There is no definitive way to trace the media used along a TCP/IP transmission path, the protocol was specifically designed to abstract that way from higher level protocols. Sometimes hints can be gleaned by examining things like the MTU size, as certain transmission media use slightly different MTUs, but fancier routers will reassemble packets to hide even that much information.

Your best bet is to run a trace-route along the path. Sometimes the names the telcos give the hops can tell you what kind of link it is, and from there sufficient googling can sometimes give you what kind of media path it is likely to be along that segment.

Keep in mind that media translation hides all of this. In one memorable troubleshooting case of mine a decade ago, one Ethernet segment was translated 3 times between hops (Router -> Fibre -> twisted-pair -> thick-net -> twisted-pair -> distribution switch) which was invisible when looking at packets; the only clue that this was going on was in inter-packet latencies and round-trip-times, and even then it took consulting the network documentation to figure out exactly what's going on. This gets even worse when talking about Internet communication.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
1

There is no obvious and reliable way to determine the underlying transport used to connect you to a webpage. Sometimes a traceroute will give you hints... for example, when I traceroute to Google, I see:

  • my cable provider's DOCSIS network
  • my cable provider's Ethernet network
  • the backbone transit network (either Level-3 or tbone)

Beyond that, knowing whether your bits are moving over an ATM, SONET, DOCSIS, DWDM, etc network is interesting trivia, but not very relevant.

duffbeer703
  • 20,077
  • 4
  • 30
  • 39
0

I will add my answer from a possibly different vantage point.

Look at the OSI model on coredump's answer.
There is this "Network" layer (Layer 3 from bottom up). Its responsibility is to navigate all of the mess of networks and routers on the Internet and "find a way" to reach the destination. A layer 3 packet is usually the same, unchanged, on the whole path from the sending device to the receiving computer (please disregard some minor tweaks along the way). Why? Because it's its job: to make the two endpoints of the communication reach each other, traversing different and numerous networks.

The layer 2 protocol, "Data Link" (and the frames built using this protocol) has a quite different job. Its Jobs is to make the two Network Cards (NICs) talk to each other on the same network. When your messages (packets inside frames) are spit out from your computer to your home network and reach the next NIC (on the router, I suppose), the Layer 2 frame is discarded, only layer 3 packets and up pass through. On the other side of the router, another brand new layer 2 frame, possibly built according to a different protocol, is created carrying the original layer 3 packet.

Let's say you have a home network and an ADSL internet connection. If you want to browse facebook.com, your computer will always generate an IP packet (layer 3), which will be always encapsulated inside an Ethernet frame (layer 2). The protocol does not change, it`s always Ethernet. This frame (containing the packet) will be carried by the blue cables to your router. On the router, still inside your house, your Ethernet frame will be discarded, and the IP packet will be encapsulated in another Layer 2 frame, but this time an ADSL frame, not an Ethernet one!

Every time you change networks (and you change networks a lot while you travel through the Internet sea!) that Layer 2 frame is discarded and another one is created.

So, it's rather pointless for you to ask "how to know the exact protocol used to perform a specific task,like browsing a web page", because Layer 2 protocols don't even know what a web page is. Their job is to take an IP packet and take it from NIC a to NIC B on the same network. And what Layer 2 protocol to use depends on the network, not on the application (this is the job of Layer 7 protocols).

Summary:
- Layer 2 protocols (Ethernet, FDDI etc) are related to the physical network technology used.
- Layer 3 protocols (today, mostly IP) are related to the path, to reach the destination.
- Layer 3 packets travel inside Layer 2 frames.
- Layer 3 packets survive the whole journey, Layer 2 frames die on each router along the way - and there are several routers on your path.
- Both layers of protocols, 2 and 3, are oblivious of what the application is doing. They simply don't know!
- If you want to know which protocols are used for what application, you must study Layer 4 (Transport) and Layer 7 (Application) protocols.

Summary of the summary: if you are at home, your hardware (cables, NICs, router) probably is Ethernet, so frames will Always leave you computer as Ethernet, no matter what you are doing (browsing, FTP, streaming, chat etc). So your question doesn't even make sense.

Henrique
  • 161
  • 1
  • 11