Remote addr что это
Определение IP адреса
Значение REMOTE_ADDR : 31.184.215.237
HTTP заголовки, которые могут содержать информацию об IP адресе:
HTTP_CLIENT_IP : не установлено
HTTP_X_FORWARDED_FOR : не установлено
HTTP_VIA : не установлено
HTTP_X_REAL_IP : не установлено
Каждый, кто в один прекрасный день узнаёт о существовании переменной HTTP_X_FORWARDED_FOR, тут же воображает себя мегагуру, и заменяет ей REMOTE_ADDR. Потом приходит знание о других переменных (X_REAL_IP, VIA, и ещё вагон и маленькая тележка), изобретаются многослойные мегаконструкции, изобретатели хвастаются друг перед другом их многоэтажностью и сравнивают свои творения с «кодом из PHPbb!».
К примеру, возьмем, казалось бы, простой вопрос «какой именно IP адрес (из цепочки хостов, через которые идет запрос от компьютера клиента к серверу) мы хотим записать в лог?». После того, как выяснилось, что большинство пхп-программистов затрудняются на него ответить, я и решил написать эту заметку.
А это, между прочим, очень важный вопрос. Не ответив на него, наряду с вопросом «Зачем нам нужен IP адрес?», приступать к самому определению бессмысленно.
При том, что большинству читателей этого текста вопросы покажутся бессмысленными.
Ну что ж, попробуем разобраться.
Во-вторых, определимся с тем, ДЛЯ ЧЕГО нам нужен IP адрес. Если мы хотим записать в лог, то пишем однозначно только REMOTE_ADDR. В этой переменной содержится реальный IP адрес реального хоста в интернете, который произвел соединение с нашим сервером. Единственный реальный адрес. Никаких других сервер не знает.
Апач пишет в логи именно REMOTE_ADDR. Не надо считать авторов веб-сервера дурнее себя.
Практика.
Итак. Из всего вышеизложенного делается простой вывод.
IP адрес в скрипте может быть только один. Лежит он в переменной REMOTE_ADDR.
Следовательно, вожделенный код получания «идеального IP адреса» выглядит, как
$ip=$_SERVER[‘REMOTE_ADDR’]
Точка.
Примечание для хостеров: mod_realip или mod_rpaf
Примечание для пользователей: разумеется, таких хостеров надо избегать, как калёного железа. Наверняка ведь это не единственная их криворукость?
Гормональный holywar Админа и Разраба PHP или REMOTE_ADDR vs HTTP_X_FORWARDED_FOR
Давеча был свидетелем одного интересного спора о том как же действительно нужно определять IP адрес конечного пользователя из скриптов PHP.
Собственно, каждое слово сабжа отображает действительную ситуацию. Это был религиозный спор, обострённый весенней замечательной погодой, в котором, я считаю, не оказалось правых и не правых, но который побудил меня к мини-исследованию и, к моему счастью, поставил точку в понимании этого конфессионального но по факту очень простого вопроса.
Для тех, кто как и я сомневался был уверен, что во всём разобрался, но боялся спросить лень было разбираться в мелочах — под кат.
Предыстория
Занимаясь разработкой VOD сервиса для Samsung SmartTV платформы нам непременно нужно знать страну пользователя, чтобы вдруг нечаянно не показать счастливому пользователю фильм там, где запрещает правообладатель… А ведь за нарушение данного условия договора идут не детские штрафы в тысячах долларов (при чем за каждый факт такой оплошности).
[Вопрос, как заметили в комментариях, Юридический, и мошенничество возможно, но статья даже не о том как постараться предотвратить такие мошенничества, а о том как правильно подружить php и nginx]
На сервере имеем следующее: php-fpm+nginx
Как определить страну? Ну естественно через IP пользователя и GEO IP базу maxmind
«Пффф. » — подумалось нам всем мне — да проще простого. И дабы не писать свой велосипед, нагуглил на stackoverflow, даже вник в каждую строчку, прикрутил и оставил как там и росло код:
И всё работало! Почти год… пока не случилось кое-что неожиданное. Естественно неожиданное для этого кода…
Как запутать php или цепочка прокси(всё ещё часть предыстории)
Всё сломалось! А случилось это когда нам пришлось прикручивать одну из платёжных систем и весь этот код рухнул от того, что в HTTP_X_FORWARDED_FOR пришёл не один адрес, а список адресов через запятую (что строго говоря законно, допустимо, и даже не регламентировано в доке по php)
И никто бы ничего не заметил, если бы HTTP_X_REAL_IP или HTTP_CLIENT_IP(которые тоже не регламентирован докой) содержали искомый IP, но увы они были пусты 🙁
«Ну ладно» — подумали мы(теперь я был уже не один) перепишем всё и попросим админов запихивать пользовательский IP в переменную REMOTE_ADDR:
И всё работало! Почти месяц… пока не случилось кое-что неожиданное. Естественно неожиданное для этого кода…
Весенний спор крутых мужиков(это не ирония — они крутые)
Всё сломалось! А случилось это потому, что нам нужно было обновить nginx. И мы обратились к профессионалам в этом деле — к нашим админам.
А те в свою очередь решили обновить и конфиг избавившись от нашего «костыля/не костыля» (пока мы этого не поняли) с пробросом в REMOTE_ADDR.
REMOTE_ADDR оставили без изменения т.е. там теперь светилось что-то типа «127.0.0.1»
в HTTP_X_FORWARDED_FOR прокинули IP пользователя (который между делом с лёгкостью удалось переопределить отправкой из браузера заголовка `x-forwarded-for: 999.999.999.999`)
И тут понеслось — Р=Разраб, А=Админ:
А: у вас всё сломалось, и поскольку мы имеем nginx-прокси то нужный вам адрес лежит в HTTP_X_FORWARDED_FOR а в REMOTE_ADDR будет лежать реальный IP сдресс клиента к php-fpm (т.е. 127.0.0.1)
Р: но мы не можем верить HTTP_X_FORWARDED_FOR, ведь это переменная, которую с лёгкостью можно переопределить через заголовок к серверу, ссылаясь на давольно интересную статью
А: нет, мы сделаем так что в ней будет лежать реальный IP конечного пользователя, а в REMOTE_ADDR реальный адрес клиента к php
Р: тогда мы не проследим последовательность проксей, и всё равно для универсализации на другом сервере (скажем без прокси) эти конфиги могут быть не правдивыми пихайте всё в REMOTE_ADDR который в любом случае будет работать.
… это кратко и без матов…
По итогу то конечно всё завелось… и остановились на прозрачном проксировании, когда php думает, что к нему подключаются напрямую клиенты безо всяких проксей и все переменные(точнее одна на которую мы обращаем внимание) в нужном нам состоянии.
Однако не хватает фэншуя в этом деле и по факту у нас ведь есть прокся а может и не одна.
Кто виноват из них кто прав
Судить не нам, но никто!
Если мы имеем действительно кучу клиентов напрямую к php, или прозрачное проксирование то всё просто — юзай REMOTE_ADDR на здоровье и наслаждайся.
Но как быть с фэншуем и где что должно лежать, если мы используем нормальное проксирование и хотим чтобы об этом знал PHP?
Рецепт… но не панацея:
Казалось бы ну в чем проблема парсить эту переменную и доставать оттуда последний элемент. Но в нашем случае настройки не были до конца корректными и весь HTTP_X_FORWARDED_FOR заменялся заголовком от браузера x-forwarded-for, а должен был приклеивать к нему реальный IP непосредственного пользователя.
Для примера проверил на промышленном vps хостинге: 
Доверять таким данным тоже страшновато, но если всё правильно сделано в настройках то последним IP будет адресс пользователя, вне зависимости от того что придёт в заголовках.
В заключении
PS
Позже мы наведём фэншуй в настройках и избавимся от прозрачного проксирования, а так же напишем универсальную функцию определения IP для обоих случаев проксирования.
PPS
Ради фана кому интересно: если кто-то в комментариях напишет эту функцию и конфиг nginx за нас и мы её будем использовать, то под честное слово, тот получит 100р на телефон.
Но эта функция и конфиг должны быть во истину православными и учитывать всё 🙂 все зацепки есть в статье.
Главное — дзен: не торопитесь — вдруг первые напишут с ошибками и вы их учтёте, торопитесь — вдруг первый правильный ответ будет до Вас.
Всем спасибо. Хорошей весны! Договаривайтесь с коллегами и любите их! 🙂
$_SERVER
(PHP 4 >= 4.1.0, PHP 5, PHP 7, PHP 8)
$_SERVER — Информация о сервере и среде исполнения
Описание
Индексы
Абсолютный путь к исполняемому скрипту.
‘ SERVER_ADMIN ‘ Эта переменная получает своё значение (для Apache) из директивы конфигурационного файла сервера. Если скрипт запущен на виртуальном хосте, это будет значение, определённое для данного виртуального хоста. ‘ SERVER_PORT ‘ Порт на компьютере сервера, используемый сервером для соединения. Для установок по умолчанию, значение будет ‘ 80 ‘; используя SSL, например, это значение будет таким, какое сконфигурировано для соединений безопасного HTTP.
Примеры
Результатом выполнения данного примера будет что-то подобное:
Примечания
Смотрите также
User Contributed Notes 45 notes
Just a PHP file to put on your local server (as I don’t have enough memory)
That will give you the result of each variable like (if the file is server_indices.php at the root and Apache Web directory is in E:\web) :
No need to list all possible keys of the array.
The javascript block would define an event handler function and bind it to the form’s submit event. This event handler would load via an tag an external file, with the submitted username and password as parameters.
For example, with a PHP script, we can have this:
Will show something like 1492897785
However, a lot of vars are still vulnerable from environment injection.
I created a gist here ( https://gist.github.com/Pierstoval/f287d3e61252e791a943dd73874ab5ee ) with my PHP configuration on windows with PHP7.0.15 on WSL with bash, the results are that the only «safe» vars are the following:
All the rest can be overriden with environment vars, which is not very cool actually because it can break PHP applications sometimes.
An even *more* improved version.
You have missed ‘REDIRECT_STATUS’
Very useful if you point all your error pages to the same file.
ErrorDocument 404 /error-msg.php
ErrorDocument 500 /error-msg.php
ErrorDocument 400 /error-msg.php
ErrorDocument 401 /error-msg.php
ErrorDocument 403 /error-msg.php
# End of file.
Guide to absolute paths.
Data: __FILE__
Data type: String
Purpose: The absolute pathname of the running PHP file, including the filename.
Caveat: This is not the file called by the PHP processor, it’s what is running. So if you are inside an include, it’s the include.
Caveat: Symbolic links are pre-resolved, so don’t trust comparison of paths to be accurate.
Caveat: Don’t assume all operating systems use ‘/’ for the directory separator.
Works on web mode: Yes
Works on CLI mode: Yes
Data: __DIR__
Data type: String
Purpose: The absolute pathname to the running PHP file, excluding the filename
Caveat: This is not the file called by the PHP processor, it’s what is running. So if you are inside an include, it’s the include.
Caveat: Symbolic links are pre-resolved, so don’t trust comparison of paths to be accurate.
Caveat: Don’t assume all operating systems use ‘/’ for the directory separator.
Works on web mode: Yes
Works on CLI mode: Yes
If the browser sends an HTTP request header of:
X-Debug-Custom: some string
[ ‘HTTP_X_DEBUG_CUSTOM’ ]; // «some string»
?>
There are better ways to identify the HTTP request headers sent by the browser, but this is convenient if you know what to expect from, for example, an AJAX script with custom headers.
Works in PHP5 on Apache with mod_php. Don’t know if this is true from other environments.
They are still accessible, but only if the request was a POST request. When it is, it’ll be available as:
$_SERVER[‘CONTENT_LENGTH’]
$_SERVER[‘CONTENT_TYPE’]
So near, and yet so far …
$_SERVER has nearly everything you need to know about the current web page environment. Something which would have been handy is easy access to the protocol and the actual web root.
For practical purposes, I normally include something like the following in my scripts:
Depending on what you want to do the content of this variable, put in On or Off.
This happens, for example, when calling the page through a call to stream_context_create() with a HTTP header of ‘request_fulluri’ set to 1.
Apparently, request_fulluri is useful when using some proxy servers.
One quick (and improvable) way to detect it would be to compare the start of the REQUEST_URI with REQUEST_SCHEME:
A way to get the absolute path of your page, independent from the site position (so works both on local machine and on server without setting anything) and from the server OS (works both on Unix systems and Windows systems).
[«_SERVER»]=>
array(24) <
[«MANPATH»]=>
string(48) «/usr/share/man:/usr/local/share/man:/usr/X11/man»
[«TERM»]=>
string(11) «xterm-color»
[«SHELL»]=>
string(9) «/bin/bash»
[«SSH_CLIENT»]=>
string(20) «127.0.0.1 41242 22»
[«OLDPWD»]=>
string(60) «/Library/WebServer/Domains/www.example.com/private»
[«SSH_TTY»]=>
string(12) «/dev/ttys000»
[«USER»]=>
string(5) «username»
[«MAIL»]=>
string(15) «/var/mail/username»
[«PATH»]=>
string(57) «/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin»
[«PWD»]=>
string(56) «/Library/WebServer/Domains/www.example.com/www»
[«SHLVL»]=>
string(1) «1»
[«HOME»]=>
string(12) «/Users/username»
[«LOGNAME»]=>
string(5) «username»
[«SSH_CONNECTION»]=>
string(31) «127.0.0.1 41242 10.0.0.1 22»
[«_»]=>
string(12) «/usr/bin/php»
[«__CF_USER_TEXT_ENCODING»]=>
string(9) «0x1F5:0:0»
[«PHP_SELF»]=>
string(10) «Shell.php»
[«SCRIPT_NAME»]=>
string(10) «Shell.php»
[«SCRIPT_FILENAME»]=>
string(10) «Shell.php»
[«PATH_TRANSLATED»]=>
string(10) «Shell.php»
[«DOCUMENT_ROOT»]=>
string(0) «»
[«REQUEST_TIME»]=>
int(1247162183)
[«argv»]=>
array(1) <
[0]=>
string(10) «Shell.php»
>
[«argc»]=>
int(1)
>
Guide to URL paths.
Русские Блоги
Как настроить nginx для получения реального IP пользователя
## 1. Базовые знания
1.1. Предварительные знания:
В nginx есть несколько переменных:
Представляет IP-адрес клиента, но его значение не предоставляется клиентом, а указывается сервером в соответствии с IP-адресом клиента. Когда ваш браузер посещает веб-сайт, если в середине нет прокси-сервера, тогда веб-сервер веб-сайта ( Nginx, Apache и т. Д.) Установит remote_addr на IP-адрес вашего компьютера. Если вы используете прокси, ваш браузер сначала получит доступ к прокси, а затем перенаправит его на веб-сайт через прокси-сервер, чтобы веб-сервер Для remote_addr задан IP-адрес этого прокси-компьютера, если только прокси-сервер не прикрепляет ваш IP-адрес к заголовку запроса и пересылает его на веб-сервер.
X-Forwarded-For (сокращенно XFF)
Proxy3 напрямую подключен к серверу, он добавит IP2 в XFF, указывая, что он помогает Proxy2 пересылать запрос. В списке нет IP3, а IP3 можно получить на сервере через поле Remote Address. Мы знаем, что HTTP-соединение основано на TCP-соединении. В протоколе HTTP нет понятия IP. Удаленный адрес исходит из TCP-соединения, что означает IP-адрес устройства, которое устанавливает TCP-соединение с сервером, в данном примере это IP3. Удаленный адрес не может быть подделан, потому что для установления TCP-соединения требуется трехстороннее рукопожатие.Если исходный IP-адрес подделан, TCP-соединение не может быть установлено, и последующие HTTP-запросы не будут. Однако в нормальных условиях удаленный адрес, полученный веб-сервером, получит только IP верхнего уровня. В данном случае это IP3 прокси 3. Вот подсказка.
Это еще одно настраиваемое поле заголовка, которое обычно используется прокси-сервером HTTP для указания IP-адреса устройства, с которым он создает TCP-соединение. Это устройство может быть другим прокси-сервером или реальным запросчиком. Это зависит от количества уровней или Всегда ли полностью передавать реальный IP-адрес. (Примечание: если он не подвергается строгой обработке, его можно подделать)
1.2. Предпосылка и железный закон
Железный закон: при использовании многоуровневого прокси или CDN, если прокси-сервер не передает реальный IP-адрес пользователя, бизнес-сервер никогда не сможет получить реальный IP-адрес пользователя.
1.3. Источник и реальность настоящего IP пользователя
Прежде всего, на реальном IP-адресе пользователя также будет много людей, использующих один IP-адрес. При достижении бизнес-сервера запрос пользователя будет проходить в следующих ситуациях:
#### 1.3.1. Широкополосный провайдер предоставляет независимый IP
Например, если у вас дома есть широкополосное подключение к Интернету, Telecom назначил IP-адрес общедоступной сети, тогда IP-путь запроса будет следующим:
В этом случае 119.147.19.234 добавит полученный 116.1.2.3 в заголовок и отправит его на 192.168.126.127, поэтому в этом случае мы получили ip-адрес пользователя 116.1.2.3. Если 119.147.19.234 не добавляет 116.1.2.3 к информации заголовка и не отправляет ее на бизнес-сервер, бизнес-сервер может занять только верхний уровень 110.147.19.234.
1.3.2. Провайдеры широкополосного доступа не могут предоставить независимый IP
У поставщика широкополосной связи недостаточно IP-адресов общедоступной сети, и выделяется IP-адрес внутренней сети, например, небольшого поставщика услуг Интернета, например длина и ширина. Путь запроса может быть:
#### 1.3.3. Мобильный 2g Интернет
Сетевой провайдер не может напрямую предоставить IP-адрес однопользовательскому терминалу. Возьмем, к примеру, cmwap China Mobile, поэтому путь запроса может быть следующим:
#### 1.3.4. Дачанг, там десятки тысяч или сотни тысяч сотрудников, но только один экспортный интернет-IP
Также будет много пользователей с одним и тем же IP-адресом, например Tencent, Baidu и другие офисные помещения, которых могут достигать десятки тысяч, но экспортных IP-адресов может быть только несколько.
2. Как получить настоящий IP пользователя
2.1. Когда бизнес-сервер напрямую представлен в общедоступной сети, а CDN и обратный прокси-сервер не используются:
Вы можете использовать remote_addr напрямую. Например, PHP можно использовать напрямую
Например, давайте подделаем IP-адрес источника и отправим его на известный ip138.com.
Он выводит наш фальшивый XFF как есть.
2.2. Бизнес-сервер за прокси-сервером или CDN
Предварительное условие: каждый уровень агентов или CDN, указанных выше, будет полностью передавать remote_addr исходного запроса. Давайте сначала рассмотрим один из вариантов.
Если верхний уровень веб-сервера также использует nginx в качестве прокси или балансировки нагрузки, вам необходимо указать параметры XFF в конфигурации nginx уровня прокси и добавить IP-адрес предыдущей инициатора запроса в запрос заголовка. Ниже приведены параметры конфигурации nginx уровня прокси.
proxy_set_header X-NginX-Proxy true;
Если HAProxy используется перед веб-сервером, необходимо добавить следующую конфигурацию для перенаправления реального IP-адреса пользователя на веб-сервер.
Если вы хотите получить полную информацию о ссылках с бизнес-сервера или получить ее через XFF, вам необходимо добавить конфигурацию в конфигурацию nginx, плюс эта конфигурация позволяет нам получить всю информацию о ссылках:
Лучше всего добавить этот параметр во включенный fastcgi.conf В, есть куча fastcgi_param В настроенном файле пишется иначе location сегмент. Эта конфигурация может повлиять на ваш журнал nginx, это будет подробно объяснено позже. Если этот параметр не настроен, информация XFF, которую мы напрямую получаем на ВЕБ-СЕРВЕРЕ, является IP-адресом предыдущего уровня прокси. Конечно, это не влияет на получение реального IP пользователя. Однако, если вы отлаживаете конфигурацию, просматривать всю ссылку неудобно.
2.2.1 В случае только одного слоя агента
Результаты приведены ниже:
[HTTP_X_FORWARDED_FOR] => unkonw, 1.1.1.1, 10.100.11.25
Мы видим, что XFF привязан к моему IP-адресу, но предыдущая серия поддельного контента может легко обмануть многие правила и HTTP_X_REAL_IP Он передал IP моего компьютера. Поскольку в приведенной выше конфигурации X-Real-IP Он был установлен как IP-адрес рукопожатия. Но после нескольких агентов, согласно приведенным выше правилам, очевидно, что HTTP_X_REAL_IP Это больше не будет реальным IP-адресом пользователя. А также HTTP_X_FORWARDED_FOR После исходной информации (информации, которую мы подделали) прикрепляется и передается IP-адрес рукопожатия.
2.2.2 В случае двух или более агентов
Здесь мы тестируем только два слоя, фактическая ссылка:
В случае двухуровневого прокси результат:
[HTTP_X_FORWARDED_FOR] => unkonw, 1.1.1.1, 10.100.11.25, 10.200.21.34
Исходя из приведенной выше ситуации, как выбрать реальный IP пользователя? Представьте себе три варианта:
1. Агент первого уровня будет реальным IP-адресом пользователя.Поместите его в X-Real-IP и передайте, Каждый последующий уровень использует X-Real-IP для продолжения передачи вниз. Настроен как:
Как правило, CDN передает реальный IP-адрес пользователя в XFF. Мы можем провести несколько простых тестов, чтобы понять, что нам делать.
3. Взаимодействуйте с модулем nginx realip, чтобы получить реальный IP-адрес пользователя.
Мы должны придерживаться принципа:
Не используйте программы для решения задач, которые могут упростить и сделать более универсальными за счет настройки. То есть среда прозрачна для программы. Конечно, без тяжелой работы обслуживающего и обслуживающего персонала системы не обойтись.
Если вы можете разобраться с этим в конфигурации, вам не нужно использовать сложные процедуры для ее решения, потому что на сервере могут быть различные приложения, которым требуется получить IP-адрес пользователя. Если правила не являются единообразными, результаты будут несовместимыми.
Программа не знает, сколько слоев прошла ссылка до того, как она перейдет на веб-сервер, поэтому не рекомендуется разрешать программе выполнять совместимость. Просто позвольте программе рассматривать все агенты как прозрачные.
Наконец-то подошел к делу. Что мы должны делать среди трех описанных выше методов, если мы не можем гарантировать, что предыдущий уровень прокси будет использовать указанные правила?
Можно использовать только третий метод (т. Е. Сотрудничество с модулем nginx realip для получения реального IP-адреса пользователя).
Мы исключили IP-адреса различных уровней агентов и получили реальный IP-адрес пользователя. Это может использовать модуль nginxrealip_module чтобы понять.
Но в любом случае правила прокси первого уровня являются наиболее важными, которые напрямую влияют на результаты получения последующим уровнем прокси и веб-сервисом.
Затем добавьте следующую конфигурацию в конфигурацию nginx (можно добавить в раздел http, server или location)
# set user real ip to remote addr
set_real_ip_from Ниже приведены доверенные правила IP, их может быть несколько. Если CDN включен, если вам известен IP-адрес CDN для отслеживания, вы также должны добавить его. За исключением надежных, в него будет записан реальный IP-адрес пользователя. remote addr Эта переменная.
real_ip_recursive Рекурсивно удалите доверенный IP в конфигурации. Если есть только один уровень прокси, этот параметр также можно не указывать.
Потом запросил в интернете, и результат был такой
[HTTP_X_FORWARDED_FOR] => unkonw, 1.1.1.1, 112.193.23.51, 10.200.21.50
Поговорим о журнале nginx
Если XFF записывается в журнал nginx, могут быть некоторые вещи, которые мы не хотим записывать. Например, формат журнала nginx по умолчанию, который мы используем сейчас, следующий:
В настоящее время, поскольку XFF содержит слишком много информации, даже некоторый поддельный нефильтрованный текст, при использовании и анализе журнала возникнут проблемы, поэтому мы просто не записываем его. формат журнала nginx log_format Также есть значение по умолчанию “combined” Формат по умолчанию:
Мы просто используем этот формат.
подводить итоги
Мы рекомендуем следующие правила:
* Прокси-сервер первого уровня присоединяет IP-адрес подтверждения к X-Forwarded-For и передает его в обратном направлении (или задает X-Forwarded-For для передачи IP-адреса подтверждения для передачи в обратном направлении). IP-адрес квитирования накопления уровня передается обратно.
* Прокси-сервер первого уровня устанавливает для IP-адреса рукопожатия значение X-Real-IP в заголовке HTTP-запроса для обратной передачи. Каждый последующий уровень передается как есть (если он передается, он передается как есть, а если нет, он устанавливается на подтверждение IP).
IP-адрес рукопожатия: remote_addr запрашивающей стороны.
Эксплуатация и обслуживание очень важны, и обработка первого слоя агента очень важна.
Когда только O&M знает сетевую среду лучше всего, постарайтесь быть прозрачным для приложения через конфигурацию. Избавьтесь от сложных суждений на прикладном уровне. Если среда очень сложная, например при использовании CDN, может потребоваться координация нескольких сторон.
Ссылка
Интеллектуальная рекомендация
URL-тур
URL-тур Во всем процессе он может быть примерно разделен на следующие процессы. DNS-анализ домена TCP соединение HTTP-запрос Запрос процессов Возвращает ответ HTTP Рендеринг страницы Выключить соедине.
Руководство по обзору кода на основе GitLab
Luo Valley P3809 (вопросы массива суффикса)
phpMyAdmin сообщает об ошибках на главной странице
[Феномен]: phpMyAdmin сообщает о фатальной ошибке: необученная ошибка: вызов неопределенной функции mb_detect_encoding () [Анализ причины]: На этой домашней странице следует подумать, открыты ли библи.
Что такое алгоритм фильтра Блума?
Нажмите вышеСинее словоУстановить звезду Начнем сегодняшнее исследование