Google 서버에 대한 낮은 RTD

Google 서버에 대한 낮은 RTD

Google 서버에 대한 RTD가 어떻게 그렇게 낮은지 알아내려고 노력 중입니다.

$ ping google.com
PING google.com (173.194.113.64): 56 data bytes
64 bytes from 173.194.113.64: icmp_seq=0 ttl=57 time=28.166 ms

173.194.113.64캘리포니아주 마운틴뷰에 등록되어 있으며 저는 독일에 있습니다. 캘리포니아에 있는 호스트에 대한 핑은 훨씬 더 길어질 것입니다. Traceroute를 실행하면 호스트 이름이 제공됩니다 fra02s21-in-f0.1e100.net. 내 요청을 리디렉션하기 위해 어떤 기술을 사용하고 있는지 스스로에게 묻고 있습니다.

답변1

미국의 경우 RTD가 30ms 미만일 수 없다는 말이 맞습니다. 유럽에서 미국까지의 거리는 약 60ms(편도)입니다.

따라서 Google은 아마도 바다 이쪽에 캐시 서버를 가지고 있을 것입니다
(실제로는 유럽에 있지만 방금 Mountain View에 등록되었습니다.).

나는 찾았다이 기사그것을 설명합니다:

구글의 비밀

Google은 데이터 센터를 어디에 보관하고 있는지, 얼마나 많은지 파악하는 것을 어렵게 만들었습니다. 이에 대한 가장 큰 이유 중 하나는 Google이 사용하는 거의 모든 IP 주소(그리고 IP 주소가 너무 많음)입니다.캘리포니아주 마운틴뷰 주소에 등록되어 있습니다., 따라서 IP 주소만 보면 됩니다(IP WHOIS 또는 IP-위치 데이터베이스 사용).데이터 센터가 어디에 있는지 알아내는 데 도움이 되지 않습니다.또는 얼마나 많은지.

이 외에도 Google은 일반적으로 노스캐롤라이나의 Lapis LLC 및 아이오와의 Tetra LLC와 같이 Google을 전혀 언급하지 않는 회사(LLC)를 사용하여 데이터 센터 프로젝트에 대한 허가를 구합니다.

Google은 일반적으로 데이터 센터에 대해 매우 비밀스러운 경향이 있으므로 여기에 제시된 정보는 100% 완전하지 않을 가능성이 높습니다.

보너스 링크;)Google 데이터 센터 내부 살펴보기.


여기는다른 소스:

2) 전 세계에 지사를 두고 있는 대기업은 whois에서 실제 위치에 대한 정보를 공유하지 않습니다.

  • 예: Google Inc.는 전 세계에 데이터 센터를 두고 있지만 whois는 항상 본사가 Mountain View(미국 캘리포니아)에 있음을 나타냅니다. 실제로는 다양한 국가의 사용자가 가장 가까운 데이터 센터로 이동됩니다. 예를 들어 독일인의 경우 메인 페이지는 독일 데이터 센터(74.125.39.104)에서 로드됩니다.

편집하다:(저는 이 주제에 대한 전문가가 아니라는 점을 명심해 주세요 :)

일부 리디렉션을 수행하는 "권한 있는 이름 서버"에 대한 귀하의 말이 옳을 것입니다. 뒤에 서버가 여러 개 있는지 잘 모르겠습니다.저것추가 리디렉션을 수행합니다. dig google.com +traceDNS 요청이 어떤 서버에서 어떤 서버로 가는지 확인하려면 다음을 수행할 수 있습니다 . (읽다여기그 뒤에 있는 몇 가지 기본 사항에 대해)

리디렉션의 메커니즘에 관해서. Akamai CDN을 언급하셨습니다. Google은 자체 CDN을 사용합니다. 몇 년 전에 Google이 Akamai를 인수한다는 소문이 있었지만 그런 일은 일어나지 않았습니다. 제 생각에는 Apple이 (다른 CND 중에서) Akamai CDN을 사용하는 것 같습니다.

~에이 페이지Google이 "edns-client-subnet 확장"을 사용한다는 것을 읽을 수 있습니다.

OpenDNS와 Google DNS는 오랫동안 edns-client-subnet 확장을 지원해 왔습니다. 이 메커니즘은 이 문제를 해결하기 위해 Google에서 특별히 설계했습니다. 그리고 그것은 아름답게 작동합니다. 어떤 리졸버를 사용하든 CDN은 최상의 서버로 리디렉션을 보낼 수 있습니다.

좀 더인터넷 검색이 메커니즘에 대해 자세히 알아볼 수 있습니다. 좋다여기:

Google, Bitgravity, CDNetworks, DNS.com 및 Edgecast는 다음을 지원합니다.edns-클라이언트-서브넷. 아이디어는 매우 간단합니다. 요청 시 IP 주소의 일부(반익명성을 유지하기 위한 일부만)를 전달합니다. 이 확장을 지원하는 서버는 이를 사용하여 사용자에게 가장 가까운 CDN 노드를 지역 타겟팅하고 찾을 수 있습니다. 이전에 할 수 있는 최선의 방법은 DNS 서버의 위치를 ​​이용하는 것이었고, 많은 경우 DNS 서버는 멀리 떨어져 있었습니다.

CDN과 edns-client-subnet 확장에 대한 또 다른 좋은 자료는 다음과 같습니다.이것.

충분한 독서 자료를 통해Google;)

관련 정보