关于TCP / IP的链路层

首先，您必须了解OSI模型可以提供的帮助：

您正在讨论的协议是应用程序协议，并在应用程序层上进行处理，此层的内容被封装并在其之后（Presentation）传递到该层，等等。 所以每一层只需要知道与它直接相关的图层格式。

这意味着像FTP，HTTP等应用协议并没有真正被链路层所识别，链路层只关心MAC地址和与networking和物理层的对话。

如果你想了解什么层次或什么协议用于某些事情，你可以与IANA长列表战斗或使用维基百科简化的协议列表 。

• 协议是抽象的，所以你不需要知道。
• 即使你知道你和第一跳之间使用了什么链路层，它也会在路由上改变（以太网 – > PPPoE – > ATM – >串行 – > ….）

有一些技巧可以对可能发生的事情进行反向工程。 取决于你是否试图访问一个网页，或执行侦察。

没有明确的方式来跟踪沿着TCP / IP传输path使用的媒体，该协议专门devise为从高层协议中抽象出来。 有时可以通过检查诸如MTU大小来收集提示 ，因为某些传输媒体使用稍微不同的MTU，但是更高级的路由器将重组数据包以隐藏更多的信息。

你最好的办法是沿着path运行一个跟踪路线。 有时候，电话公司给跳跃的名字可以告诉你它是什么样的链接，从那里有足够的谷歌search有时可以给你什么样的媒体path，可能是沿着这个部分。

请记住，媒体翻译隐藏所有这一切。 在十年前我的一个令人难忘的故障排除案例中，一个以太网段在跳跃（路由器 – >光纤 – >双绞线 – >粗网 – >双绞线 – >分配开关）之间翻译了3次，在数据包; 唯一的线索是发生在数据包间的延迟和往返时间，即使如此，它还是通过查阅networking文档来弄清楚到底发生了什么。 谈论互联网通信时，情况会变得更糟。

确定用于将您连接到网页的底层传输方式没有明显可靠的方法。 有时traceroute会给你提示…例如，当我跟踪到谷歌，我看到：

• 我的有线电视提供商的DOCSISnetworking
• 我的有线电视提供商的以太网
• 骨干中转networking（Level-3或tbone）

除此之外，了解您的位是否在ATM，SONET，DOCSIS，DWDM等networking上移动是有趣的琐事，但不是很相关。