Я искал повсюду, но не смог найти четкого ответа или даже сообщения в инженерном блоге, чтобы описать, как компании сопоставляют пользовательские домены со своими приложениями.
Например, допустим, у меня есть страница в Tumblr с URL-адресом www.ashley.tumblr.com. Сайт позволяет вам добавить собственный домен, чтобы посещение www.Ashley.com отображало www.ashley.tumblr.com с полной поддержкой дополнительных страниц и каталогов.
Каково техническое название этой разработки?
Для того, что они делают, нет единого названия - разработки кода HTTP / веб-сервера для обработки запросов из произвольного HTTP-запроса Host: заголовка и сопоставления их с существующими учетными записями Tumblr. Это не имеет ничего общего с DNS, кроме требования к владельцу пользовательского доменного имени изменить свои записи A, AAAA или CNAME так, чтобы они указывали на тот же хост, что и не пользовательский домен (чтобы гарантировать, что это произойдет, обычно пользовательское доменное имя a CNAME для нестандартного домена, в случае, если IP-адрес нестандартного домена может быть изменен).
Время экспозиции! - Большинство обычных веб-серверов (Apache, IIS) построены на концепции «веб-сайта»: физический каталог, сопоставленный с запросами, соответствующими предопределенному списку значений HTTP Host: заголовка (или некоторый шаблон сопоставления подстановочных знаков) и привязки протокола и порта. Например, вы должны добавить запись под названием «MyWebsite.com» (имя веб-сайта), которая принимает запросы к mywebsite.com и www.mywebsite.com (поскольку это два разных значения заголовка Host:) и, возможно, еще несколько, например secure.mywebsite.com с использованием HTTPS на порту 443) .
Более современные легкие веб-серверы и обратные прокси (например, nginx и Node.js 'Express) обходятся без физического сопоставления каталогов и позволяют коду приложения полностью решать, как маршрутизировать запросы в логике приложения (это то, что «маршрутизатор» и / или « демультиплексор "(демультиплексор) в терминологии веб-приложений) - это происходит за счет необходимости самостоятельно обрабатывать всю эту логику (честно говоря, эти веб-серверы поставляются с необходимыми инструментами, чтобы легко их настраивать, как старые обычные веб-серверы, это просто не по умолчанию).
... но преимущество в том, что вы можете заставить его работать именно так, как вы хотите.
В псевдокоде их программа, вероятно, выглядит примерно так:
void handleRequest(Request request) {
String hostHeader = request.getHeader("Host")
RegexMatch nonCustomDomainMatch = hostHeader.match( "([^\.]+).tumblr.com" )
if nonCustomDomainMatch.success {
String accountName = nonCustomDomainMatch.groups[0]
showAccount( accountName )
}
else {
// Look up the custom domain name in a database or other mutable data store:
String accountName = db.execQuery( "SELECT accountName FROM accounts WHERE accounts.customDomainName = @cdn", new { cdn: hostHeader } )
if accountName == null {
showHttp404Error()
}
else {
showAccount( accountName )
}
}
}
В реальности, учитывая их размер и масштаб, скорее всего, это будет некоторая настраиваемая логика внутри аппаратных балансировщиков нагрузки или какой-либо другой облегченной интерфейсной службы - и всегда с агрессивным кэшированием (поиск в базе данных стоит дорого!).
