delegatetoproxy

Signed-off-by: Alexander Ivanov <oshli.a.er@gmail.com>

README.russian.md

@@ -574,7 +574,7 @@ null == undefined   // true
 
 **Иначе:** Ваш бедный одиночный поток будет занят выполнением инфраструктурных задач вместо того, чтобы работать с ядром приложения, и производительность будет соответственно снижаться.
 
-🔗 [**Подробнее: Delegate anything possible (e.g. gzip, SSL) to a reverse proxy**](/sections/production/delegatetoproxy.md)
+🔗 [**Подробнее: Делегируйте все возможное (например, gzip, SSL) обратному прокси**](/sections/production/delegatetoproxy.russian.md)
 
 <br/><br/>
 

sections/production/delegatetoproxy.russian.md

@@ -0,0 +1,51 @@
+# Делегируйте все возможное (например, gzip, SSL) обратному прокси
+
+<br/><br/>
+
+### Объяснение в один абзац
+
+Это очень заманчиво для карго-культа Express и использования его богатого промежуточного программного обеспечения для задач, связанных с сетью, таких как обслуживание статических файлов, кодирование gzip, запросы регулирования, завершение SSL и т.д. Это снижение производительности из-за его однопоточной модели, которая сохранит процессор занят для длительных периодов (помните, что модель выполнения Node оптимизирована для коротких задач или задач, связанных с асинхронным вводом-выводом). Лучшим подходом является использование инструмента, обладающего опытом в сетевых задачах. Наиболее популярными являются nginx и HAproxy, которые также используются крупнейшими поставщиками облачных технологий для снижения нагрузки на входящие процессы Node.js.
+
+<br/><br/>
+
+### Пример конфигурации nginx - Использование nginx для сжатия ответов сервера
+
+```nginx
+# configure gzip compression
+gzip on;
+gzip_comp_level 6;
+gzip_vary on;
+
+# configure upstream
+upstream myApplication {
+    server 127.0.0.1:3000;
+    server 127.0.0.1:3001;
+    keepalive 64;
+}
+
+#defining web server
+server {
+    # configure server with ssl and error pages
+    listen 80;
+    listen 443 ssl;
+    ssl_certificate /some/location/sillyfacesociety.com.bundle.crt;
+    error_page 502 /errors/502.html;
+
+    # handling static content
+    location ~ ^/(images/|img/|javascript/|js/|css/|stylesheets/|flash/|media/|static/|robots.txt|humans.txt|favicon.ico) {
+    root /usr/local/silly_face_society/node/public;
+    access_log off;
+    expires max;
+}
+```
+
+<br/><br/>
+
+### Что говорят другие блоггеры
+
+* Из блога [Mubaloo](http://mubaloo.com/best-practices-deploying-node-js-applications):
+> … Попасть в эту ловушку очень легко - вы видите пакет типа "Экспресс" и думаете: "Круто! Давайте начнем", - вы кодируете, и у вас есть приложение, которое делает то, что вы хотите. Это отлично, и, честно говоря, вы выиграли много битвы. Однако вы проиграете войну, если загрузите свое приложение на сервер и прослушаете его на своем HTTP-порте, потому что вы забыли очень важную вещь: Node не является веб-сервером. **Как только любой объем трафика начнет попадать в ваше приложение, вы заметите, что что-то начинает работать неправильно: соединения теряются, ресурсы перестают обслуживаться, или, в худшем случае, происходит сбой вашего сервера. То, что вы делаете, это пытаетесь заставить Node справиться со всеми сложными вещами, которые проверенный веб-сервер делает действительно хорошо. Зачем изобретать велосипед?**
+> **Это только для одного запроса, для одного изображения и с учетом того, что это память, которую ваше приложение может использовать для важных вещей, таких как чтение базы данных или обработка сложной логики; зачем вам калечить ваше приложение ради удобства?**
+
+* Из блога [Argteam](http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load):
+> Несмотря на то, что в express.js есть встроенная статическая обработка файлов через некоторое промежуточное ПО для подключения, вы никогда не должны его использовать. **Nginx может гораздо лучше справляться со статическими файлами и предотвращать засорение запросов на не динамический контент нашими процессами узлов** …