NetworkManager или сетевой [LWN.net]

Кто-то должен написать одну из статей о “ложных убеждениях программистов” для TCP, потому что это просто отражает более широкую тенденцию программного обеспечения, которое думает, что оно знает лучше, чем TCP, и обычно это не так. Здесь я даже заведу игру (помните, все следующие утверждения *ложны* по крайней мере иногда, но для некоторых из них, возможно, не очень часто):

1. TCP надежен, поэтому все, что я отправляю, будет получено на другом конце.
2. Хорошо, в основном надежно.
3. Хорошо, хорошо, это ненадежно (в указанном выше смысле слова), но отправитель и получатель всегда в конечном итоге придут к согласию относительно того, какие именно байты были переданы по транспортному каналу.
4. Можно создать гарантию, аналогичную (3), путем создания некоторого ориентированного на сообщения протокола уровня приложений поверх TCP, например HTTP или SMTP.
5. Существует такое понятие, как TCP-пакет.
6. Такого понятия, как TCP-пакет, не существует.
7. Если нам не удается подключиться к известному удаленному хосту, значит, мы находимся в автономном режиме.
8. Алгоритм Нейгла хорош.
9. Алгоритм Нейгла плох.
10. Мне не нужен алгоритм Нейгла.
11. Это все низкоуровневый педантизм. Я могу думать о TCP как о двустороннем канале Unix, который идет по сети, и полностью игнорировать то, как он реализован.
12. Если сеть прозрачна для TCP, то она должна быть прозрачна и для IP.
13. Если сеть прозрачна для HTTP/1.1, то она должна быть прозрачна и для TCP.
14. Странные сети, непрозрачные для стандартных протоколов, являются отклонением. Я могу спокойно их игнорировать.
15. TCP реализован на основе IP.

Объяснение для 1-4: https://en.wikipedia.org/wiki/Two_Generals%27_Problem. TL;DR: Если соединение разрывается, пока ACK ожидает подтверждения, отправитель не сможет узнать, был ли получен сегмент, и это оказывается неразрешимой проблемой, независимо от того, насколько сложным вы ее усложните. Вам нужно что-то вроде Paxos или Raft, чтобы получить такую гарантию, и это всегда требует минимум трех узлов, поэтому его нельзя построить поверх одного двухстороннего потока TCP. См. RFC 1047 для обсуждения этой проблемы, специфичного для SMTP (которое все еще применимо к современному SMTP, поскольку RFC 2821 говорит, что реализации ДОЛЖНЫ следовать основным рекомендациям 1047), но обратите внимание, что некоторые вариации этой проблемы применимы буквально к каждой двухсторонней службе TCP (и, если на то пошло, к каждой службе UDP или IP), независимо от того, как она работает или какие абстракции она вводит. SMTP отличается только тем, что обе стороны явно обязаны заботиться о том, было ли получено сообщение или нет, что несколько необычно для служб TCP (сравните и сопоставьте: загрузку файлов по FTP, HTTP POST и PUT и т. д., большинство из которых опускают существенное обсуждение логики повторных попыток клиента, оставляя это на усмотрение приложения или конечного пользователя).

15 оставлен в качестве упражнения для читателя (подсказка: он в первую очередь представляет исторический интерес, но я не уверен, что можно полностью исключить современные контрпримеры, поскольку мы не знаем, какие странные вещи происходят в [any large organization]частная сеть).