为什么 youtube.com 解析后的 IP 会指向 google.com?

发布于 2024-10-19 16:51:29 字数 234 浏览 4 评论 0原文

这可能是一个非常愚蠢的问题,但我很好奇。

对 youtube.com 的 ping 显示解析的 IP 为 74.125.127.93。现在,如果您在浏览器中访问此 IP http://74.125.127.93/ 您会期望显示 YouTube 页面向上。相反,搜索引擎会出现。

有人可以解释幕后发生了什么吗? 谢谢。

This might be a really stupid question, but I'm curious.

A ping of youtube.com showed the resolved IP to be 74.125.127.93. Now, if you access this IP in a browser http://74.125.127.93/ you would expect the youtube page to show up. Instead the search engine shows up.

Can someone explain what's going on behind the curtain?
Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

看海 2024-10-26 16:51:29

因为服务器名称很多,但IP地址却很少。

让我解释一下。 IPv4 允许 2^32(40 亿)个不同的 IP 地址。听起来很多,但大多数都不能使用。 IP 地址始终按块分配。最小的块是 255 个地址(8 位 - 1 个广播地址),最大的块是 1600 万个地址 (2^24-1)。中等大小的块有 64k 地址(16 位)。

如果您是 ISP,您会获得一组固定的地址。但当然,您总是要求一个比您绝对需要的块更大的块 - 否则您将耗尽地址,这对 ISP 来说确实很糟糕。您可以要求两个 16 位块,但是连接两个块总是很麻烦。

上周,我们用完了 IPv4 块。所以...你有一个 64k 的块并且不能获得更多。但是您有 150,000 个客户想要运行 Web 服务器。

解决方案:虚拟服务器。您告诉您的 DNS“xycom”是 13.242.251.17,“aycom”是相同的地址,“bycom”也是。

当客户端发出请求时,它将执行 DNS 查询,该查询始终返回相同的 IP。然后它向刚刚获得的 IP 发送 HTTP 请求。诀窍在于 HTTP 请求包含服务器名称。因此,即使所有请求都发送到同一个 IP 地址,网络服务器仍然可以找出您真正想要的人。

只要你给它起个名字。如果您使用 IP,您将获得默认服务,即 Google 搜索引擎。

[编辑]使用telnet,您可以自己尝试一下。使用 telnet 74.125.127.93 80 启动它,然后键入:

GET http://www.google.com/index.html HTTP/1.1

按 Enter 键两次。您将获得您所在国家/地区的 Google 主页的重定向。现在输入:

GET http://www.youtube.com/ HTTP/1.1

按回车键两次。这次,YouTube主页将返回。

Because there are many server names but only a few IP addresses.

Let me explain. IPv4 allows 2^32 (4 billion) different IP addresses. Sounds like a lot but most of them can't be used. IP-addresses are always allocated in blocks. The smallest block is 255 addresses (8 bit - 1 address for broadcasts), the biggest one is 16 million addresses (2^24-1). Medium sized blocks have 64k addresses (16 bit).

If you're an ISP, you get a fixed set of addresses. But of course you always ask for a block that is larger than what you absolutely need - otherwise you'll run out of addresses and that's really bad for an ISP. You could ask for two 16 bit blocks but joining the two blocks is always a hassle.

Last week, we ran out of IPv4 blocks. So ... you have a 64k block and can't get more. But you have 150'000 customers which want to run a web server.

The solution: virtual servers. You tell your DNS "x.y.com" is 13.242.251.17 and "a.y.com" is the same address and "b.y.com", too.

When a client makes a request, it will do a DNS query which always returns the same IP. Then it sends a HTTP request to the IP it just got. The trick is that the HTTP request contains the server name. So even though all the requests go to the same IP address, the web server can still figure out who you really want.

As long as you give it the name. If you use the IP instead, you get the default service which is the Google search engine.

[EDIT] With telnet, you can try this yourself. Start it with telnet 74.125.127.93 80 and then type:

GET http://www.google.com/index.html HTTP/1.1

Hit enter twice. You will get a redirect for the Google homepage of your country. Now type:

GET http://www.youtube.com/ HTTP/1.1

Hit enter twice. This time, the YouTube homepage will be returned.

滥情空心 2024-10-26 16:51:29

Google 拥有 YouTube。
他们可能使用相同的负载平衡服务器和基于名称的虚拟主机来检测您尝试浏览的站点。
这可以通过查看客户端提供的主机标头(这是您尝试浏览的域)来实现。由于主机标头不同,因此直接使用 IP 与通过域访问时并不总是会到达相同的站点。

Google owns Youtube.
They probably use the same load-balancing server together with name-based virtual hosts for detecting which site you are trying to browse to.
This can be achieved by looking at the host header supplied by the client (which is the domain you are trying to browse to). Since the host header is different, you don't always get to the same site when going directly with the ip as when you go through the domain.

海之角 2024-10-26 16:51:29

Google 使用虚拟主机——同一 IP 地址上的两个(或多个)服务处理请求的服务器由请求的 URL 确定。

Google is using virtual hosting -- two (or more) services on the same IP address where the web server to handle a request is determined by the URL of the request.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文