diff --git a/locale/ru/docs/guides/anatomy-of-an-http-transaction.md b/locale/ru/docs/guides/anatomy-of-an-http-transaction.md index 289514b9c553..7fe3034403c3 100644 --- a/locale/ru/docs/guides/anatomy-of-an-http-transaction.md +++ b/locale/ru/docs/guides/anatomy-of-an-http-transaction.md @@ -1,9 +1,9 @@ --- -title: Anatomy of an HTTP Transaction +title: Анатомия HTTP Транзакции layout: docs.hbs --- -# Anatomy of an HTTP Transaction +# Анатомия HTTP Транзакции The purpose of this guide is to impart a solid understanding of the process of Node.js HTTP handling. We'll assume that you know, in a general sense, how HTTP @@ -12,11 +12,20 @@ assume a bit of familiarity with Node.js [`EventEmitters`][] and [`Streams`][]. If you're not quite familiar with them, it's worth taking a quick read through the API docs for each of those. -## Create the Server +Цель данного руководства дать твердое понимание процесса обработки HTTP в +Node.js. Мы предположим, что вам известно, в общих чертах, как работают HTTP +запросы, в независимости от языка програмирования и среды разработки. Мы +так же предположим, что у вас есть некоторое представление о [`EventEmitters`][] +и [`Streams`][] в Node.js. Если вы недостаточно знакомы с этими модулями, стоит +пролистать их API документацию. + +## Создание Сервера Any node web server application will at some point have to create a web server object. This is done by using [`createServer`][]. +Рано или поздно любое веб-сервер приложение в node должно создать объект веб-сервера. + ```javascript const http = require('http'); diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md index 5dad10472b70..741a423dc54c 100644 --- a/locale/ru/docs/guides/blocking-vs-non-blocking.md +++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md @@ -1,51 +1,53 @@ --- -title: Overview of Blocking vs Non-Blocking +title: Блокирующие и Неблокирующие Вызовы layout: docs.hbs --- -# Overview of Blocking vs Non-Blocking +# Обзор Блокирующих и Неблокирующих Вызовов -This overview covers the difference between **blocking** and **non-blocking** -calls in Node.js. This overview will refer to the event loop and libuv but no -prior knowledge of those topics is required. Readers are assumed to have a -basic understanding of the JavaScript language and Node.js callback pattern. +Этот обзор рассматривает разницу между **блокирующими** и **неблокирующими** +вызовами в Node.js. Он ссылается на цикл событий (event loop) и библиотеку libuv, +однако предварительное знание этих тем не требуется. Предпологается, что +читатели имеют базовое понимание JavaScript и паттерна обратных вызовов (callback) +в Node.js. -> "I/O" refers primarily to interaction with the system's disk and -> network supported by [libuv](http://libuv.org/). +> Обозначение "I/O" (Ввод/Вывод) в первую очередь ссылается на взаимодействие +> с системным диском и сетью при поддержке [libuv](http://libuv.org/). -## Blocking +## Блокирование -**Blocking** is when the execution of additional JavaScript in the Node.js -process must wait until a non-JavaScript operation completes. This happens -because the event loop is unable to continue running JavaScript while a -**blocking** operation is occurring. +О **блокировании** говорят, когда выполнение оставшегося JavaScript кода в Node.js +приостановленно до тех пор, пока не завершится работа сторонней операции (например, чтение +какого-нибудь файла). Так происходит, потому что цикл событий не может продолжить исполнение оставшегося JavaScript +кода, так как работает **блокирующая** операция. -In Node.js, JavaScript that exhibits poor performance due to being CPU intensive -rather than waiting on a non-JavaScript operation, such as I/O, isn't typically -referred to as **blocking**. Synchronous methods in the Node.js standard library -that use libuv are the most commonly used **blocking** operations. Native -modules may also have **blocking** methods. +В Node.js медленный код JavaScript не принято называть **блокирующим**, +если причиной тому высокая нагрузка кода на процессор, а не ожидание завершения +сторонней операции. Синхронные методы в стандартной библиотеке Node.js, +которые используют libuv, наиболее часто применяемые **блокирующие** операции. +Нативные модули также могут иметь **блокирующие** методы. -All of the I/O methods in the Node.js standard library provide asynchronous -versions, which are **non-blocking**, and accept callback functions. Some -methods also have **blocking** counterparts, which have names that end with -`Sync`. +Все I/O методы в стандартной библиотеке Node.js предоставляют свои асинхронные версии, +которые являются **неблокирующими** и принимают функции обратного вызова +в качестве аргумента. Некоторые методы также имеют свои **блокирующие** аналоги. +Названия таких методов закнчиваются на `Sync`. -## Comparing Code +## Сравнение Кода -**Blocking** methods execute **synchronously** and **non-blocking** methods -execute **asynchronously**. +**Блокирующие** методы исполняются **синхронно**, а **неблокирующие** методы +исполняются **асинхронно**. -Using the File System module as an example, this is a **synchronous** file read: +Возьмем модуль File System для примера. Вот пример **синхронного** чтения файла: ```js const fs = require('fs'); -const data = fs.readFileSync('/file.md'); // blocks here until file is read +// исполнение кода заблокированно, пока файл не будет полностью считан +const data = fs.readFileSync('/file.md'); ``` -And here is an equivalent **asynchronous** example: +А вот эквивалентный **асинхронный** пример: ```js const fs = require('fs'); @@ -54,23 +56,23 @@ fs.readFile('/file.md', (err, data) => { }); ``` -The first example appears simpler than the second but has the disadvantage of -the second line **blocking** the execution of any additional JavaScript until -the entire file is read. Note that in the synchronous version if an error is -thrown it will need to be caught or the process will crash. In the asynchronous -version, it is up to the author to decide whether an error should throw as -shown. +Первый пример выглядит проще чем второй, но он имеет один недостаток: вторая строка +**блокирует** исполнение любого нижеследующего JavaScript кода, до тех пор, пока +весь file.md не будет считан. Обратите внимание, если синхронная версия кода сгенерирует +исключение, его нужно обработать, иначе процесс Node.js "упадёт". В асинхронном варианте +выбор сгенерировать исключение или нет оставлено на усмотрение программиста. -Let's expand our example a little bit: +Давайте немного расширим наш пример: ```js const fs = require('fs'); -const data = fs.readFileSync('/file.md'); // blocks here until file is read +// исполнение кода заблокированно, пока файл не будет полностью считан +const data = fs.readFileSync('/file.md'); console.log(data); -moreWork(); // will run after console.log +moreWork(); // функция будет исполнена, после console.log ``` -And here is a similar, but not equivalent asynchronous example: +А вот похожий, но не эквивалентный асинхронный пример: ```js const fs = require('fs'); @@ -78,39 +80,38 @@ fs.readFile('/file.md', (err, data) => { if (err) throw err; console.log(data); }); -moreWork(); // will run before console.log +moreWork(); // функция будет исполнена до console.log ``` -In the first example above, `console.log` will be called before `moreWork()`. In -the second example `fs.readFile()` is **non-blocking** so JavaScript execution -can continue and `moreWork()` will be called first. The ability to run -`moreWork()` without waiting for the file read to complete is a key design -choice that allows for higher throughput. +В первом примере метод `console.log` будет вызван до срабатывания функции `moreWork()`. +Во втором примере метод `fs.readFile()` является **неблокирующим**, поэтому исполнение +JavaScript кода может продолжаться, не дожидаясь окончания его работы. Как следствие +функция `moreWork()` сработает раньше `console.log`. Эта возможность — отсутствие необходимости +дожидаться окончания чтения файла и т.п. системных вызовов — ключевое +инженерное решение, которое обеспечивает высокую пропускную способность Node.js. -## Concurrency and Throughput +## Конкурентность и Пропускная Способность -JavaScript execution in Node.js is single threaded, so concurrency refers to the -event loop's capacity to execute JavaScript callback functions after completing -other work. Any code that is expected to run in a concurrent manner must allow -the event loop to continue running as non-JavaScript operations, like I/O, are -occurring. +Исполнение JavaScript кода в Node.js является однопоточным. Поэтому, говоря о конкурентности +(параллельности вычислений) в Node.js, подразумевают, что после того, как цикл событий обработал синхронный код, +он способен обработать функции обратного вызова. Подобно сторонним операциям (таким как I/O), +любой конкурентный код должен позволять циклу событий продолжать свою работу. -As an example, let's consider a case where each request to a web server takes -50ms to complete and 45ms of that 50ms is database I/O that can be done -asynchronously. Choosing **non-blocking** asynchronous operations frees up that -45ms per request to handle other requests. This is a significant difference in -capacity just by choosing to use **non-blocking** methods instead of -**blocking** methods. +В качестве примера возьмем запросы к веб-серверу. Допустим, обработка сервером одного запроса +занимает 50мс. Из этих 50мс, 45мс уходит на операции чтения/записи в базу данных. +С базой данных можно взаимодействовать и **асинхронно**. При таком подходе, на каждый запрос +к веб-серверу **неблокирующая** асинхронная операция высвободит 45мс для обработки других +запросов, а это существенная разница. -The event loop is different than models in many other languages where additional -threads may be created to handle concurrent work. +Обработка конкурентной (параллельной) работы при помощи цикла событий в Node.js +отличается от подходов во многих других языках программрования, в которых могут +создаваться дополнительные потоки. -## Dangers of Mixing Blocking and Non-Blocking Code +## Опасность Смешивания Блокирующего и Неблокирующего Кода -There are some patterns that should be avoided when dealing with I/O. Let's look -at an example: +Существует паттерны, которые следует избегать при работе с I/O. Взглянем на пример: ```js const fs = require('fs'); @@ -121,10 +122,9 @@ fs.readFile('/file.md', (err, data) => { fs.unlinkSync('/file.md'); ``` -In the above example, `fs.unlinkSync()` is likely to be run before -`fs.readFile()`, which would delete `file.md` before it is actually read. A -better way to write this, which is completely **non-blocking** and guaranteed to -execute in the correct order is: +В вышеукзанном примере метод `fs.unlinkSync()`, с высокой вероятностью, будет исполнен до +`fs.readFile()`. Это приведет к удалению файла до его прочтения. Лучше переписать +этот код в **неблокирующем** виде, что гарантирует правильный порядок исполнения методов: ```js @@ -138,11 +138,11 @@ fs.readFile('/file.md', (readFileErr, data) => { }); ``` -The above places a **non-blocking** call to `fs.unlink()` within the callback of -`fs.readFile()` which guarantees the correct order of operations. +В последнем примере **неблокирующий** вызов метода `fs.unlink()` расположен в функции обратного вызова +`fs.readFile()`. Такой подход гарантирует парвильную последовательность операций. -## Additional Resources +## Дополнительные рессурсы - [libuv](http://libuv.org/) -- [About Node.js](https://nodejs.org/en/about/) +- [О Node.js](https://nodejs.org/en/about/) diff --git a/locale/ru/docs/guides/getting-started-guide.md b/locale/ru/docs/guides/getting-started-guide.md index a66d897400f4..5d3c1034a35d 100644 --- a/locale/ru/docs/guides/getting-started-guide.md +++ b/locale/ru/docs/guides/getting-started-guide.md @@ -8,6 +8,9 @@ layout: docs.hbs Once you have installed Node, let's try building our first web server. Create a file named "app.js", and paste the following code: +После того как вы установили Node, давайте попробуем создать наш первый веб-сервер. +Создайте файл с именем "app.js", и скопируйте следующий код: + ```javascript const http = require('http'); @@ -26,3 +29,4 @@ server.listen(port, hostname, () => { ``` After that, run your web server using ``` node app.js ```, visit http://localhost:3000, and you will see a message 'Hello World' +После этого запуститье ваш веб-сервер используя комманду ``` node app.js ```, откройте http://localhost:3000 в браузере, и вы увидите сообщение 'Hello World'