TCP Urgent Pointer, управление буфером и вызов "Отправить"
Мой вопрос касается создания сегмента TCP на отправляющем устройстве.
В моем понимании TCP - это то, что он буферизует "несрочные" байты трафика до тех пор, пока не будет достигнут какой-то внутренний тайм-аут... или не будет достигнут MSS. Затем сегмент заканчивается и передается на провод.
Мой вопрос: если TCP буферизует "нормальные / несрочные" байты, а затем получает строку "срочных" байтов из процесса верхнего уровня, будет ли это:
- Завершите буферизацию "несрочных" байтов, отправьте несрочный сегмент и начните создание нового сегмента TCP, начиная с "срочных" байтов... или...
- Продолжайте строить частичный сегмент в буфере, помещая байты срочности где-то посередине сегмента после обычных байтов.
RFC 1122 (раздел 4.2.2.4) указывает, что указатель Urgent указывает на ПОСЛЕДНИЙ БАЙТ срочных данных в сегменте (вывод, что несрочные данные могут следовать за срочными данными в том же сегменте). Он не уточняет, должен ли сегмент начинаться с срочных данных... или, если срочные данные могут быть "посередине".
Этот вопрос касается возможного сегмента TCP с установленным битом "срочно", но НЕ с битом "push". Насколько я понимаю, RFC 793 состоит в том, что они взаимно исключают друг друга (хотя обычно они объединяются).
Спасибо!
1 ответ
Я понимаю, что TCP будет буферизовать "несрочные" байты трафика, пока не будет достигнут какой-либо внутренний тайм-аут
Если алгоритм Nagle включен, то это по умолчанию. В противном случае он просто отправит данные немедленно, в зависимости от окна и т. Д.
... или MSS достигнут. Затем сегмент заканчивается и передается на провод.
На самом деле, нет. Он будет передавать, как и когда может, с учетом только алгоритма Nagle, управления окнами, контроля перегрузки и т. Д.
Мой вопрос: если TCP буферизует "нормальные / несрочные" байты, а затем получает строку "срочных" байтов из процесса верхнего уровня, будет ли это:
- Завершите буферизацию "несрочных" байтов, отправьте несрочный сегмент и начните создание нового сегмента TCP, начиная с "срочных" байтов... или...
- Продолжайте строить частичный сегмент в буфере, помещая байты срочности где-то посередине сегмента после обычных байтов.
Ни. Смотри выше. С точки зрения фактической отправки, нет ничего "срочного" в срочных данных.
RFC 1122 (раздел 4.2.2.4) указывает, что указатель Urgent указывает на ПОСЛЕДНИЙ БАЙТ срочных данных в сегменте (вывод, что несрочные данные могут следовать за срочными данными в том же сегменте).
Правильно, за исключением того, что вы имеете в виду "намекающий".
Он не уточняет, должен ли сегмент начинаться с срочных данных... или, если срочные данные могут быть "посередине".
Это не требует, чтобы сегмент начинался с срочных данных, поэтому это не нужно.
Этот вопрос касается возможного сегмента TCP с установленным битом "срочно", но НЕ с битом "push".
Зачем? Бит PUSH в основном не имеет смысла для современных реализаций TCP и игнорируется, и вы никак не можете определить границы сегментов, так почему вас это волнует?
Насколько я понимаю, RFC 793 состоит в том, что они взаимно исключают друг друга (хотя обычно они объединяются).
Зачем? Пожалуйста, объясни.