수년 동안 우리 주소 표시 줄에서 작은 pedantry 전쟁이 격렬 해졌습니다. 한쪽 구석에는 다음과 같은 브랜드가 있습니다. 구글, 인스타그램및 페이스북. 이 그룹은 리디렉션을 선택했습니다. example.com 에 www.example.com. 반대편 코너에서: GitHub의, DuckDuckGo및 디스코드. 이 그룹은 역방향 및 리디렉션을 선택했습니다. www.example.com 에 example.com.
"WWW"가 URL에 속합니까? 일부 개발자는 이 주제에 대해 강한 의견을 가지고 있습니다. 우리는 약간의 역사 후에 그것에 대한 찬반 논쟁을 탐구할 것입니다.
Ws는 무엇입니까?
XNUMX개의 W는 다음을 의미합니다. "월드 와이드 웹", 브라우저와 웹사이트에 세계를 소개한 1980년대 후반의 발명품. "WWW"를 사용하는 관행은 제공하는 서비스 유형에 따라 하위 도메인 이름을 지정하는 전통에서 비롯됩니다.
- 의 웹 서버 www.example.com
- 의 FTP 서버 ftp.example.com
- IRC 서버 irc.example.com
WWW-less 도메인 문제 1: 하위 도메인으로 쿠키 유출
"WWW-less" 도메인에 대한 비평가들은 특정 상황에서 하위 도메인.example.com 에 의해 설정된 쿠키를 읽을 수 있습니다. example.com. 예를 들어 귀하가 클라이언트가 귀하의 도메인에서 하위 도메인을 운영할 수 있도록 허용하는 웹 호스팅 공급자인 경우 이는 바람직하지 않을 수 있습니다. 우려 사항은 유효하지만 동작은 Internet Explorer에만 해당됩니다.
RFC 6265 브라우저가 쿠키를 처리하는 방법을 표준화하고 이 동작을 올바르지 않은 것으로 명시적으로 호출합니다.
누출의 또 다른 잠재적 원인은 다음과 같습니다. Domain 가치 의해 설정된 모든 쿠키 example.com. 경우 Domain 값이 명시적으로 example.com, 쿠키는 하위 도메인에도 노출됩니다.
| 쿠키 값 | 노출 example.com | 노출 하위 도메인.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
결론적으로 명시적으로 Domain 가치와 귀하의 사용자가 Internet Explorer를 사용하지 않으면 쿠키 유출이 발생하지 않습니다.
WWW가 없는 도메인 문제 2: DNS 두통
때때로 "WWW-less" 도메인은 DNS(도메인 이름 시스템) 설정을 복잡하게 만들 수 있습니다.
사용자가 입력할 때 example.com 브라우저의 주소 표시줄에 입력하려면 브라우저는 방문하려는 웹 서버의 인터넷 프로토콜(IP) 주소를 알아야 합니다. 브라우저는 일반적으로 사용자 인터넷 서비스 제공업체(ISP)의 DNS 서버를 통해 간접적으로 도메인의 이름 서버에서 이 IP 주소를 요청합니다. 네임서버가 다음과 같이 응답하도록 구성된 경우 기록 IP 주소를 포함하는 "WWW-less" 도메인이 제대로 작동합니다.
경우에 따라 정식 이름(CNAME) 귀하의 웹사이트에 대한 기록. 그러한 기록은 다음과 같이 선언할 수 있습니다. www.example.com 의 별칭입니다. example123.somecdnprovider.com, 사용자의 브라우저가 대신 IP 주소를 조회하도록 지시합니다. example123.somecdnprovider.com 거기에 HTTP 요청을 보냅니다.
위의 예에서는 WWW 하위 도메인을 사용했습니다. 다음에 대한 CNAME 레코드를 정의할 수 없습니다. example.com. 에 따라 RFC 1912, CNAME 레코드는 다른 레코드와 공존할 수 없습니다. 다음에 대한 CNAME 레코드를 정의하려고 시도한 경우 example.com, 네임서버(NS)는 다음에 대해 기록합니다. example.com 도메인 이름 서버의 IP 주소를 포함하는 도메인은 존재할 수 없습니다. 결과적으로 브라우저는 귀하의 이름 서버가 어디에 있는지 파악할 수 없습니다.
일부 DNS 공급자는 이 제한을 해결할 수 있습니다. Cloudflare는 솔루션을 호출합니다. CNAME 병합. 이 기술을 사용하여 도메인 관리자는 CNAME 레코드를 구성하지만 이름 서버는 A 레코드를 노출합니다.
예를 들어 관리자가 다음에 대한 CNAME 레코드를 구성하는 경우 example.com 를 가리키는 example123.somecdnprovider.com, 및 A 레코드 example123.somecdnprovider.com 가리키는 존재 1.2.3.4, 그러면 Cloudflare는 다음에 대한 A 레코드를 노출합니다. example.com 를 가리키는 1.2.3.4.
결론적으로 CNAME 레코드를 사용하려는 도메인 소유자의 우려는 타당하지만 이제 특정 DNS 공급자가 적절한 해결 방법을 제공합니다.
WWW 없는 혜택
대부분의 반대 주장 WWW는 실용적이거나 장식적입니다. "No-WWW" 지지자들은 말하고 입력하기가 더 쉽다고 주장했습니다. example.com 보다 www.example.com (기술에 정통하지 않은 사용자에게는 덜 혼란스러울 수 있습니다).
WWW 서브도메인의 반대자들은 또한 그것을 버리면 약간의 성능상의 이점이 있다고 지적했습니다. 웹사이트 소유자는 이렇게 함으로써 각 HTTP 요청에서 4바이트를 줄일 수 있습니다. 이러한 절감액은 Facebook과 같이 트래픽이 많은 웹사이트에 합산될 수 있지만 일반적으로 대역폭은 부족한 리소스가 아닙니다.
WWW 혜택
WWW를 선호하는 한 가지 실질적인 주장은 최신 최상위 도메인이 있는 상황입니다. 예를 들어, www.example.miami 웹 주소로 즉시 인식할 수 있습니다. 예.마이애미 그렇지 않습니다. 다음과 같이 인식할 수 있는 최상위 도메인이 있는 사이트에서는 문제가 되지 않습니다. .COM.
검색 엔진 순위에 미치는 영향
현재 합의는 귀하의 선택이 검색 엔진 성능에 영향을 미치지 않는다는 것입니다. 하나에서 다른 것으로 마이그레이션하려면 임시 리디렉션(HTTP 301) 대신 영구 리디렉션(HTTP 302)을 구성해야 합니다. 영구 리디렉션은 이전 URL의 SEO 값이 새 URL로 전송되도록 합니다.
둘 다 지원하기 위한 팁
사이트는 일반적으로 다음 중 하나를 선택합니다. example.com or www.example.com 공식 웹사이트로 지정하고 다른 웹사이트에 대해 HTTP 301 리디렉션을 구성합니다. 이론적으로 둘 다 지원 가능 www.example.com 및 example.com. 실제로는 비용이 이점보다 클 수 있습니다.
기술적인 관점에서 기술 스택이 이를 처리할 수 있는지 확인하고 싶을 것입니다. 콘텐츠 관리 시스템(CMS) 또는 정적으로 생성된 사이트는 방문자의 기본 호스트 이름을 유지하기 위해 내부 링크를 상대 URL로 출력해야 합니다. 호스트 이름을 별칭으로 구성할 수 없는 경우 분석 도구는 두 호스트 이름에 대한 트래픽을 개별적으로 기록할 수 있습니다.
마지막으로 검색 엔진 성능을 보호하기 위해 추가 조치를 취해야 합니다. Google은 URL의 'WWW' 및 '비WWW' 버전을 중복 콘텐츠. 검색 색인에서 콘텐츠를 중복 제거하기 위해 Google은 사용자가 선호한다고 생각하는 둘 중 좋든 나쁘든 표시합니다.
Google에 표시되는 방식을 제어하려면 표준 링크 태그를 삽입하는 것이 좋습니다. 먼저 어떤 호스트 이름이 공식(표준) 호스트 이름이 될지 결정합니다.
예를 들어 선택하면 www.example.com, 다음 스니펫을 태그 https://example.com/my-article:
이 스니펫은 'WWW-less' 변형이 동일한 콘텐츠를 나타낸다는 것을 Google에 나타냅니다. 일반적으로 Google은 검색 결과에서 표준으로 표시한 버전을 선호합니다. 이 예에서는 "WWW" 변형이 됩니다.
결론
양측의 치열한 캠페인에도 불구하고 이점과 제한 사항을 알고 있는 한 두 가지 접근 방식 모두 유효합니다. 모든 기지를 커버하려면 한 기지에서 다른 기지로 영구적인 리디렉션을 설정해야 합니다. 그러면 모든 준비가 완료됩니다.
