TCP 紧急指针、缓冲区管理和“发送"称呼 [英] TCP Urgent Pointer, buffer management, and the "Send" call
问题描述
我的问题与发送设备上的 TCP 段创建有关.
我对 TCP 的理解是它会缓冲非紧急"字节的流量，直到达到某种内部超时......或达到 MSS.然后该段完成并传输到电线上.
My question relates to TCP Segment-creation on the sending device.
My understanding of TCP is that it will buffer "non-urgent" bytes of traffic until either some kind of internal timeout is reached...or the MSS is reached. Then the segment is finished and transmitted onto the wire.
我的问题:如果TCP一直在缓冲正常/非紧急"字节，然后从上层进程接收到一串紧急"字节会不会:
My question: If TCP has been buffering "normal/non-urgent" bytes, and then receives a string of "urgent" bytes from the upper-layer process will it:
- 终止对非紧急"字节的缓冲，发送非紧急段，并开始创建新的 TCP 段，从紧急"字节开始...或...
- 继续构建当前缓冲的部分段，将紧急字节放在段中间的某个位置在正常字节之后.
RFC 1122(第 4.2.2.4 节)表明紧急指针指向段中紧急数据的最后一个字节(推断非紧急数据可以跟在同一段中的紧急数据之后).它没有说明一个段是否必须以紧急数据开头……或者紧急数据是否可能在中间".
RFC 1122 (section 4.2.2.4) indicates that the Urgent Pointer points to the LAST BYTE of urgent data in a segment (inferring that non-urgent data could follow the urgent data within the same segment). It does not clarify if a segment must BEGIN with urgent data...or, if the urgent data might be "in the middle".
这个问题涉及一个可能的 TCP 段，它设置了紧急"位而不是推送"位.我对 RFC 793 的理解是它们相互排斥(尽管通常设置在一起).
This question concerns a possible TCP segment with the "urgent" bit set but NOT the "push" bit. My understanding of RFC 793 is that they are mutually exclusive of each other (although typically set together).
谢谢！
推荐答案
我对 TCP 的理解是它会缓冲非紧急"的数据.字节的流量，直到达到某种内部超时
My understanding of TCP is that it will buffer "non-urgent" bytes of traffic until either some kind of internal timeout is reached
如果启用了 Nagle 算法，则为默认设置.否则它会立即发送数据，受制于窗口等.
If the Nagle algorithm is enabled, which it is by default. Otherwise it will just send the data immediately, subject to windowing etc.
...或者达到 MSS.然后该段完成并传输到线路上.
...or the MSS is reached. Then the segment is finished and transmitted onto the wire.
不是真的.它会在可能的时候进行传输，仅受 Nagle 算法、窗口化、拥塞控制等约束.
Not really. It will transmit as and when it can, subject only to the Nagle algorithm, windowing, congestion control, etc.
我的问题:如果 TCP 一直在缓冲正常/非紧急"字节，然后接收一串紧急"来自上层进程的字节将:
My question: If TCP has been buffering "normal/non-urgent" bytes, and then receives a string of "urgent" bytes from the upper-layer process will it:
- 终止对非紧急"的缓冲字节，发送非紧急段，并开始创建新的 TCP 段，从紧急"开始.字节...或...
- 继续构建当前缓冲的部分段，将紧急字节放在正常字节之后的段中间.
都没有.看上面.从实际发送的角度来看，紧急数据没有什么紧急".
Neither. See above. From the point of view of actually sending, there is nothing 'urgent' about urgent data.
RFC 1122(第 4.2.2.4 节)表明紧急指针指向段中紧急数据的最后一个字节(推断非紧急数据可以跟在同一段中的紧急数据之后).
RFC 1122 (section 4.2.2.4) indicates that the Urgent Pointer points to the LAST BYTE of urgent data in a segment (inferring that non-urgent data could follow the urgent data within the same segment).
正确，只是您的意思是暗示".
Correct, except that you mean 'implying'.
它没有说明一个段是否必须以紧急数据开头...或者紧急数据是否可能在中间".
It does not clarify if a segment must BEGIN with urgent data...or, if the urgent data might be "in the middle".
它不要求段必须以紧急数据开头，所以不需要.
It doesn't require that the segment must begin with urgent data, so it needn't.
这个问题涉及一个可能的 TCP 段，其中包含紧急"请求.位设置但不是推"位.
This question concerns a possible TCP segment with the "urgent" bit set but NOT the "push" bit.
为什么?PUSH 位对于现代 TCP 实现基本上没有意义，并且被忽略，并且您无法检测段边界，所以您为什么要关心?
Why? The PUSH bit is basically meaningless to modern TCP implementations, and ignored, and there is no way you can detect segment boundaries, so why do you care?
我对 RFC 793 的理解是它们相互排斥(尽管通常设置在一起).
My understanding of RFC 793 is that they are mutually exclusive of each other (although typically set together).
为什么?请解释.
这篇关于TCP 紧急指针、缓冲区管理和“发送"称呼的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
