После написания ответа о TCP_NODELAY и TCP_CORK я понял, что моих знаний о тонких точках TCP_CORK, должно быть, не хватает, так как это не на 100% не понятно, почему Linux разработчики считали необходимым ввести новый флаг TCP_CORK, а не просто полагаться на приложение для установки или очистки существующего флага TCP_NODELAY в соответствующие моменты времени.
В частности, если у меня есть приложение Linux, которое хочет отправить() некоторые мелкие/несмежные фрагменты данных по потоку TCP, не оплачивая налог на задержку в течение 20 месяцев, и в то же время минимизирует количество пакетов необходимо отправить его, я могу сделать это одним из двух способов:
С TCP_CORK (псевдокодом):
int optval = 1;
setsockopt(sk, SOL_TCP, TCP_CORK, &optval, sizeof(int)); // put a cork in it
send(sk, ..);
send(sk, ..);
send(sk, ..);
optval = 0;
setsockopt(sk, SOL_TCP, TCP_CORK, &optval, sizeof(int)); // release the cork
или с TCP_NODELAY (псевдокодом):
int optval = 0;
setsockopt(sk, IPPROTO_TCP, TCP_NODELAY, &optval, sizeof(int)); // turn on Nagle's
send(sk, ..);
send(sk, ..);
send(sk, ..);
optval = 1;
setsockopt(sk, IPPROTO_TCP, TCP_NODELAY, &optval, sizeof(int)); // turn Nagle back off
Я использую последнюю технику в течение многих лет с хорошими результатами, и она также может быть переносимой для ОС, отличной от ОС Linux (хотя за пределами Linux вам нужно снова позвонить send() после того, как Nagle отступит, чтобы обеспечить немедленное отправку пакетов и избежать достаточного количества нулевых байтов с помощью Nagle-delay().
Теперь разработчики Linux - умные ребята, поэтому я сомневаюсь, что вышеупомянутое использование TCP_NODELAY им никогда не приходило в голову. Должна быть какая-то причина, по которой они считали, что этого недостаточно, что привело к тому, что вместо этого они представили новый/собственный флаг TCP_CORK. Может ли кто-нибудь объяснить, в чем причина?
