Некоторые пули указывают на то, что вы должны знать:
- Как и почему работает TCP ... 3-х сторонние рукопожатия, подтверждение, задержка подтверждения, Nagling, протокол скользящего окна. Для каждой из этих функций есть конкретная причина ... и все они могут нарушить производительность вашего приложения, если с ним неправильно обращаться.
- UDP multicast ... даже если вы никогда не думаете, что будете его использовать, вам нужно знать, почему он существует, чтобы вы могли принимать обоснованные решения при проектировании систем.
- IP-фрагментация и влияние MTU.
- Двоичная сериализация и упорядочение сетевых байтов (даже если вы просто собираетесь использовать протобуферы Google, приятно понять , почему они эффективны).
- Сериализация Ascii и создание сообщений (что означает
\r\n\r\n в HTTP?)
- Различные модели диспетчеризации ввода / вывода: предварительная обработка в стиле Apache, поток на соединение, основанный на событиях однопоточный, на основе событий с рабочими потоками и т. Д.
- Влияние уязвимостей переполнения буфера в сетевом приложении
- Проектирование на основе протокола, в отличие от проектирования на основе API или библиотеки
- асинхронные против синхронных протоколов. Многие высокопроизводительные системы являются асинхронными. HTTP является синхронным, если вы не используете конвейерную обработку, и даже тогда есть много ограничений на то, что возможно ... нет, например, неупорядоченных ответов.
Обновление: что означает проект на основе протокола?
Рассмотрим HTTP, протокол Интернета. Apache, IIS, Lighttpd, Firefox, Opera, WebKit и т. Д. Все эти части программного обеспечения говорят на HTTP. Вполне возможно, что никто из них не делится кодом для этого. Недостатком, конечно же, является повышенная вероятность ошибок из-за чистого объема кода. Есть множество достоинств:
- Любая программа может общаться через HTTP, независимо от языка реализации
- Легкие / встроенные среды могут выбирать подмножество протокола, а не использовать все это
- Возможно оптимизировать обработчик протокола для конкретных ситуаций. Невозможно оптимизировать библиотеку, не жертвуя общностью.
- Разнообразие различных реализаций заставляет поставщиков библиотек устранять ошибки (а не просто устранять их, потому что все используют одну и ту же библиотеку).
- Для пользователей HTTP нет организационных или договорных обязательств, нет лицензионных сборов.
Когда вы разрабатываете сетевой протокол, вы можете создать себе несколько API, каждый из которых предназначен для конкретных случаев использования. Или вы можете построить один, решать только вам. Сетевые программные компоненты могут быть обновлены независимо друг от друга. По сути, все, что вы слышите, хорошо для интерфейсов Java / C # и абстрактных классов C ++, но применяется на сетевом уровне, а не на уровне языка программирования.