diff --git a/README-ru.md b/README-ru.md index ea85bcc6..1b4c76b0 100644 --- a/README-ru.md +++ b/README-ru.md @@ -277,6 +277,7 @@ l10n:p --> * [Task queues](#task-queues) * [Back pressure](#back-pressure) * [Communication](#communication) + * [Hypertext transfer protocol (HTTP)](#hypertext-transfer-protocol-http) * [Transmission control protocol (TCP)](#transmission-control-protocol-tcp) * [User datagram protocol (UDP)](#user-datagram-protocol-udp) * [Remote procedure call (RPC)](#remote-procedure-call-rpc) @@ -371,6 +372,7 @@ l10n:p --> * [Task queues](#task-queues) * [Back pressure](#back-pressure) * [Communication](#communication) + * [Hypertext transfer protocol (HTTP)](#hypertext-transfer-protocol-http) * [Transmission control protocol (TCP)](#transmission-control-protocol-tcp) * [User datagram protocol (UDP)](#user-datagram-protocol-udp) * [Remote procedure call (RPC)](#remote-procedure-call-rpc) @@ -3131,7 +3133,27 @@ l10n:p --> ### Transmission control protocol (TCP) -TBD +

+ +
+ Источник: How to make a multiplayer game +

+ +TCP - это протокол с установкой соединения, работающих поверх [межсетевого протокола IP](https://ru.wikipedia.org/wiki/IP). Соединение устанавливается и завершается с помощью [рукопожатия](https://en.wikipedia.org/wiki/Handshaking). Гарантия доставки пакетов в оригинальном порядке и без искажений получателю основана на: + +* номерах последовательности и [полем контрольной суммы](https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%81%D1%83%D0%BC%D0%BC%D0%B0_(Checksum)) +* [подтверждении](https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#%D0%9D%D0%BE%D0%BC%D0%B5%D1%80_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F) пакетов и автоматической повторной передаче. + +Если отправитель не получает правильного ответа, пакеты будут отправление повторно. Если время ожидания истекает несколько раз, соединиение разрывается. TCP также реализует [контроль потока](https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B0) и [отслеживание перегрузок](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control). Такие гарантии вызывают задержки и обычнго приводят к менее эффективной передаче по сравнению с UDP. + +Для поддержики высокой пропускной способности, веб-сервера могут держать большое количество открытых TCP соединений, что приводит к использованию большого количества оперативной памяти. Ресурсозатратным можем быть поддержание большого количества открытых соединений между потоками веб-сервера и, например, сервером [Memcached](https://memcached.org/). В этом случае может помочь использование [пула соединений](https://en.wikipedia.org/wiki/Connection_pool) и UPD там, где он может быть применим. + +TCP полезен для приложений, которым необходимы высокая надежная, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH. + +Используйте TCP (а не UDP) в случаях, когда необходимо: + +* сохранить данные неповрежденными +* наилучшим образом использовать пропускную способность сети автоматически ### User datagram protocol (UDP) -TBD +

+ +
+ Источник: How to make a multiplayer game +

#### Source(s) and further reading: TCP and UDP -TBD +UPD не требует соединения. Датаграммы (по аналогии с пакетами данных) гарантированы только на уровне датаграммы. Датаграммы могут быть доставлены в другом порядке (отличном от того, в котором они были отправлены), либо не доставлены совсем. UDP не поддерживает контроля перегрузок. Из-за отсутствия гарантий TCP, обычно UDP является более эффективным. + +UDP поддеживает широковещательную передачу данных, отправляя датаграммы всем устройствам подсети. Это полезно использовать вместе с [DHCP](https://ru.wikipedia.org/wiki/DHCP), так как с клиентом, который еще не получил IP адрес, нельзя установить TCP соединение. + +UPD менее надежный, но работает хорошо для приложений реального времени, например, VoIP, видеочатов, потоковой передачи данных и мультиплеерных игр реального времени. + +Используйте UPD (а не TCP) в случаях, когда: + +* вам необходима минимальная задержка передачи данных +* данных, которые пришли поздно, хуже, чем потеря данных +* вы хотите сами реализовать исправление ошибок ### Remote procedure call (RPC) -TBD +

+ +
+ Источник: Crack the system design interview +

+ +При использовании RPC, клиент вызывает выполнение процедуры в другом адрессном пространстве, обычно на удаленном сервере. Эта процедура запрограммирована для использования, как локальный вызова, абстрагируя детали взаимодействия сервера и клиенского приложения. Удаленные вызовы обычно медленее и менее надежны, чем локальные вызовы. Поэтому полезно различать удаленные вызовы от локальных. Популярными RPC фреймворками являются [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), и [Avro](https://avro.apache.org/docs/current/). + +RPC - это протокол на основе запроса и ответа: + +* **Клиентское приоложение** - вызывает клиентскую процедуру-заглушку. Параметры передаются в стек, также как и с вызовом локальной процедуры. +* **Клиентская процедура-заглушка** - собирает идентификатор процедуры и её аргументы в сообщение для запроса. +* **Клиентский модуль взаимодействия** - ОС отправляет сообщение с клиента на сервер. +* **Серверный модуль взаимодействия** - ОС передает входящие пакеты серверной процедуре-заглушке. +* **Серверная процедура-заглушка** - разбирает входящее сообщение, вызывает процедуру по полученному идентификатору и передаёт ей полученные аргументы. +* Таким же образом, только в обратном порядке, идет ответ от сервера клиенту. + +Примеры вызовов RPC: + +``` +GET /someoperation?data=anId + +POST /anotheroperation +{ + "data":"anId"; + "anotherdata": "another value" +} +``` + +RPC сфокусированы на поведении системы. RPC обычно используются для достижения высокой производительности при внутренней передаче данных, так как можно использовать нативные вызовы, подходящие для ваших сценариев использования. + +Используйте нативные библиотеки (SDK), когда: + +* вы знаете целевую платформу +* вы хотите контролировать доступ к вашей логике +* вы хотите контролировать работу с ошибками в вашей библиотеке +* производительность и опыт конечного пользователя является вашим основным интересом. + +REST API на основе HTTP часто используются для публичных API. + #### Disadvantage(s): RPC -TBD +* клиентские приложения RPC становятся сильно связанными с сервисной реализацией. +* необходимо делать новое API для каждой новой операции или сценария использования. +* отладка (debug) вызов RPC может быть непростой. +* вы, возможно, не сможете использовать существующие технологии как есть "из коробки". Например, могут понадобиться дополнительные действия для того, чтобы убедиться, что [RPC запросы закэшированы]((http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)) на серверах системах кэширования таких, как [Squid](http://www.squid-cache.org/). ### Representational state transfer (REST) -TBD +REST - это архитектурный стиль взаимодействия клиента и сервера, где клиент работает с ресурсами, управляемыми сервером. Сервер предоставляет представление ресурсов и действия для их управления, или получения нового представления. Любое взаимодействие не должно иметь состояния и быть кэшируемым. + +Существует четыре характеристики REST-интерфейса: + +* **Определение ресурса (URI в HTTP)** - независимо от операции используется один и тот же URI. +* **Изменение представления** - используйте методы, заголовки и тело. +* **Самодостаточное сообщение об ошибке (код состояния в HTTP)** - используйте коды состояния и не изобретайте велосипед. +* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML интерфейс для HTTP)** - ваш веб-сервис должен быть доступен через браузер. + +Пример REST запроса: + +``` +GET /someresources/anId + +PUT /someresources/anId +{"anotherdata": "another value"} +``` + +REST ориентирован на предоставление данных. Он снижает связанность между клиентом и сервером и часто используется для публичных API. REST использует обобщенный и унифицированный метод предоставления ресурсов через URI, [представление через заголовки](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), и действия с помощью методов, таких как GET, POST, PUT, DELETE и PATCH. Не имея состояния, REST хорошо подходит для горизонтального масштабирования и партицирования. #### Disadvantage(s): REST -TBD +* Учитывая, что REST ориентирован на предоставление данных, этот подход может не подойти, если ресурсы не достаточно организовоны или их можно получить в виде простой иерархии. Например, возвращение всех обновленных за последних час записей, соответствующих определенному набору событий не так просто представить в виде пути. Скорее всего, в таком случае реализация будет включать сочетание пути URI, параметров запросы и, возможно, тело запроса. +* REST обычно полагается на несколько методов (GET, POST, PUT, DELETE и PATCH), что не всегда может подходить для вашего сценария использования. Например, нет определенного метода для представления перемещения документов с истекшим сроком в архивную папку. +* Получение сложных ресурсов с вложенными иерархиями требует нескольких повторных запросов между клиентов и сервером, например, получение контента записи в блоге и комментариев к этой записи. Для мобильных приложений, которые функционируют в условиях переменного качества сети, эти повторные запросы являюется крайне нежелательными. +* С течением времени, больше полей может добавляться в ответ API, и более старые клиенты будут получать все новые поля, даже те, которые не нужны. В результате, увеличивается размер пересылаемых данных, что приводит к увеличению задержки передачи данных. ### RPC and REST calls comparison -TBD +| Действие | RPC | REST | +|------------------------------------------------|-------------------------------------------------------------------------------------------|--------------------------------------------------------------| +| Регистрация | **POST** /signup | **POST** /persons | +| Удаление пользователя | **POST** /resign
{
"personid": "1234"
} | **DELETE** /persons/1234 | +| Получение пользователя (person) | **GET** /readPerson?personid=1234 | **GET** /persons/1234 | +| Получения списка элементов (item) пользователя | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items | +| Добавления элемента в список пользователя | **POST** /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | **POST** /persons/1234/items
{
"itemid": "456"
} | +| Обновления элемента | **POST** /modifyItem
{
"itemid": "456";
"key": "value"
} | **PUT** /items/456
{
"key": "value"
} | +| Удаление элемента | **POST** /removeItem
{
"itemid": "456"
} | **DELETE** /items/456 | + +

+ Source: Do you really know why you prefer REST over RPC +

#### Source(s) and further reading: REST and RPC -TBD +* [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/) +* [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186) +* [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc) +* [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) +* [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs) +* [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) +* [Thrift](https://code.facebook.com/posts/1468950976659943/) +* [Why REST for internal use and not RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508) ## Security -Этот параграф было бы хорошо дополнить. [contributing](#contributing)! +Эта секция нуждается в дополнении. [contributing](#contributing)! Обеспечение безопасноcти - это обширная тема. Если у вас нет значительного опыта в безопасности, либо вы не подаётесь на вакансию, которая требует знаний по безопасности, возможно вам будет достаточно основ: