☰

DNS 和 OSI 层工作原理

tag-icon • tag-icon networking domain-name-system ip tcpip network-protocols
DNS 和 OSI 层工作原理

我想澄清一下我在学习DNS之后一直困扰我的一个疑问。

我会简单地把它写成一个问题。“一个用户正在 YouTube 上观看视频，突然用户使用的 DNS 服务器（主 DNS 和备用 DNS）宕机了”。从 DNS 的角度来看，我可以理解的是，由于 DNS 已经解析，用户应该能够继续观看 YouTube。但实际发生的情况是，在播放缓冲视频后，YouTube 视频停止播放，YouTube 不再播放。

您能否根据 OSI 层向我解释一下其背后的工作原理？ 

答案1

关于 OSI 模型，HTTP 并不位于 DNS 之上，但两者是独立的应用层协议，底层有自己的 OSI 模型堆栈。它们可以共享相同的电缆和网络连接，但最重要的是，它们使用单​​独的 TCP/UDP 连接从不同的 IP 地址获取数据。

OSI 和 TCP/IP 模型中的 DNS 和 HTTP

尽管 HTTP 在主机名被缓存后独立于 DNS 工作，但使用 HTTP 协议的现代服务的这些实现细节使事情变得更加复杂。尤其是像 YouTube 这样的全球流行流媒体服务根本无法从单个服务器或 IP 地址提供内容，而是需要内容分发网络（CDN）由多台服务器分担负载。

当你观看 YouTube 视频时，你实际上并没有从 下载缓冲的视频流www.youtube.com，而是向诸如 之类的主机名发出了额外的请求r2---sn-xap5-ixaz.googlevideo.com。使用开发人员工具，你可能会看到它们是不断请求的相当小的块：

Chrome 开发者工具显示 /videoplayback 查询

  • 这些主机名的 TTL 似乎很短，只有 5-15 分钟。此缓存过期后，需要进行额外的 DNS 查询。不过，这并不是一个坏选择，因为 CDN 需要能够适应需求的变化。

    从ipconfig /displaydns：

    r2---sn-xap5-ixaz.googlevideo.com
----------------------------------------
Record Name . . . . . : r2---sn-xap5-ixaz.googlevideo.com
Record Type . . . . . : 5
Time To Live  . . . . : 587
Data Length . . . . . : 8
Section . . . . . . . : Answer
CNAME Record  . . . . : r2.sn-xap5-ixaz.googlevideo.com

Record Name . . . . . : r2.sn-xap5-ixaz.googlevideo.com
Record Type . . . . . : 1
Time To Live  . . . . : 587
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 193.229.108.205

  • 出于同样的原因，后端会不时发生变化，这也需要额外的 DNS 查询。

答案2

我认为 OSI 分层并不是这个问题的真正影响因素。

对于有缓存的简单场景，问题中列出的假设似乎基本正确。
也就是说，假设相关的 DNS 数据已经缓存，并且相同的名称不断被请求，那么理论上新的 DNS 查找不会起作用，因为没有进行任何查找，这没有任何区别。

我更希望这些假设实际上并不适用于您在浏览器中使用 Youtube 播放器的复杂现实场景。也就是说，我预计必要的 DNS 数据实际上并未缓存（缓存时间不够长？）或者在整个播放过程中会查找新的/额外的名称。

您可能需要跟踪浏览器正在执行的操作（开发人员控制台？）和缓存状态，以找出这种特殊的情况。

答案3

您关于 IP 被计算机缓存的断言是错误的（几乎所有时间都是如此）。IP 可以动态更改，用户可以在观看 Youtube 的过程中更改 IP。计算机开始缓存 IP 以允许 DNS 出现小问题。但如果 DNS 服务器长时间停机（30 秒？更长时间？我不知道），当会话几乎结束时，会发出新的 DNS 请求。如果 DNS 不会回答，客户端将停止通信。去年已经启动了一项新的 DNS RFC 以继续在这种情况下工作，但实际上并未部署。

相关内容