s********k
发帖数: 6180 | 1 是不是主要是IP层的queue的overflow？还是可能是MAC层的？ |
r****o
发帖数: 1950 | 2 MAC 网卡?
【在 s********k 的大作中提到】
: 是不是主要是IP层的queue的overflow？还是可能是MAC层的？
|
s********k
发帖数: 6180 | 3 我觉得这个可能存在，但是不知道实际中主要是哪个queue的溢出占主导作用？
【在 r****o 的大作中提到】
: MAC 网卡?
|
X*****r
发帖数: 2521 | 4 queque还有哪层的？
【在 s********k 的大作中提到】
: 是不是主要是IP层的queue的overflow？还是可能是MAC层的？
|
s********k
发帖数: 6180 | 5 难道整个node就一个queue，即便一个queue，不同的layer应该也会有不同分配吧，总
不会IP层和MAC层共享一个queue吧
【在 X*****r 的大作中提到】
: queque还有哪层的？
|
k****o
发帖数: 82 | |
s********k
发帖数: 6180 | 7 我现在只是想搞清楚整个运行过程，好比梳理一遍。只盯住某层而不管其他感觉没法串
联起来整个过程。比如我现在想知道TCP的buffer overflow在实际中究竟在哪一层的
queue（或者只有一个queue？）drop
【在 k****o 的大作中提到】
: 研究的那层
|
k****o
发帖数: 82 | 8 分层就是能让你独立的看待每层的问题
【在 s********k 的大作中提到】
: 我现在只是想搞清楚整个运行过程，好比梳理一遍。只盯住某层而不管其他感觉没法串
: 联起来整个过程。比如我现在想知道TCP的buffer overflow在实际中究竟在哪一层的
: queue（或者只有一个queue？）drop
|
X*****r
发帖数: 2521 | 9 层只是为了理解方便划分的
【在 s********k 的大作中提到】
: 我现在只是想搞清楚整个运行过程，好比梳理一遍。只盯住某层而不管其他感觉没法串
: 联起来整个过程。比如我现在想知道TCP的buffer overflow在实际中究竟在哪一层的
: queue（或者只有一个queue？）drop
|
s********k
发帖数: 6180 | 10 那现在我的问题是TCP丢包（仅限于overflow），这个该算到哪一层？
【在 k****o 的大作中提到】
: 分层就是能让你独立的看待每层的问题
|
|
|
k****o
发帖数: 82 | 11 Transport
【在 s********k 的大作中提到】
: 那现在我的问题是TCP丢包（仅限于overflow），这个该算到哪一层？
|
s********k
发帖数: 6180 | 12 4层有queue吗？不是很清楚
【在 k****o 的大作中提到】
: Transport
|
z*****n
发帖数: 7639 | 13 一般说来，queue只存在于networklayer。
在tcp和datalink layer有transmission
control window and framing/reassembling，
不过这些buffer的使用是受控的，比如说
datalink层，如果使用selective repeat，
sliding window的大小一定，network必须等待
indication才能继续向其push packet(s)。
在链路层的接收端，每成功接收一个frame后
都会立即向上层indicate(by interrupt)。
上层（即网络层）必须响应，如果queue已满，
则造成丢包。
【在 s********k 的大作中提到】
: 我现在只是想搞清楚整个运行过程，好比梳理一遍。只盯住某层而不管其他感觉没法串
: 联起来整个过程。比如我现在想知道TCP的buffer overflow在实际中究竟在哪一层的
: queue（或者只有一个queue？）drop
|
a****l
发帖数: 8211 | 14 难道物理层就不会丢包了?
【在 z*****n 的大作中提到】
: 一般说来，queue只存在于networklayer。
: 在tcp和datalink layer有transmission
: control window and framing/reassembling，
: 不过这些buffer的使用是受控的，比如说
: datalink层，如果使用selective repeat，
: sliding window的大小一定，network必须等待
: indication才能继续向其push packet(s)。
: 在链路层的接收端，每成功接收一个frame后
: 都会立即向上层indicate(by interrupt)。
: 上层（即网络层）必须响应，如果queue已满，
|
g*****g
发帖数: 34805 | 15 会，但是可以不管，物理层丢包会在TCP层上
显示出来。也就是说，只要TCP层发出去的包
得到确认，底下物理层可以做得简单，没Q也不要紧。
【在 a****l 的大作中提到】
: 难道物理层就不会丢包了?
|
X*****r
发帖数: 2521 | 16 好虫也是搞网络的？
【在 g*****g 的大作中提到】
: 会，但是可以不管，物理层丢包会在TCP层上
: 显示出来。也就是说，只要TCP层发出去的包
: 得到确认，底下物理层可以做得简单，没Q也不要紧。
|
g*****g
发帖数: 34805 | 17 不搞，不过这算是CS的基础课吧。
【在 X*****r 的大作中提到】
: 好虫也是搞网络的？
|
S*******w
发帖数: 24236 | 18 学的很扎实
【在 g*****g 的大作中提到】
: 不搞，不过这算是CS的基础课吧。
|
s********k
发帖数: 6180 | 19 拿你这个例子说，network必须等待indication之后才向MAC层push packet，但是作为
上层的TCP并不知道MAC的sliding window，一方面queue不能向下push数据，另一方面
TCP可能又在往queue里面push数据。这就是掉包的原因？
【在 z*****n 的大作中提到】
: 一般说来，queue只存在于networklayer。
: 在tcp和datalink layer有transmission
: control window and framing/reassembling，
: 不过这些buffer的使用是受控的，比如说
: datalink层，如果使用selective repeat，
: sliding window的大小一定，network必须等待
: indication才能继续向其push packet(s)。
: 在链路层的接收端，每成功接收一个frame后
: 都会立即向上层indicate(by interrupt)。
: 上层（即网络层）必须响应，如果queue已满，
|
s********k
发帖数: 6180 | 20 另外transmission control window是说TCP congestion window吧
【在 z*****n 的大作中提到】
: 一般说来，queue只存在于networklayer。
: 在tcp和datalink layer有transmission
: control window and framing/reassembling，
: 不过这些buffer的使用是受控的，比如说
: datalink层，如果使用selective repeat，
: sliding window的大小一定，network必须等待
: indication才能继续向其push packet(s)。
: 在链路层的接收端，每成功接收一个frame后
: 都会立即向上层indicate(by interrupt)。
: 上层（即网络层）必须响应，如果queue已满，
|
|
|
z*****n
发帖数: 7639 | 21 一般来讲，物理层丢包会引发链路层重传。
【在 a****l 的大作中提到】
: 难道物理层就不会丢包了?
|
z*****n
发帖数: 7639 | 22 tcp只存在于通信的两端，中间节点上只有网络层。
这一点要搞清楚。在端节点，tcp向下push也是受控的（有
tcp transmission window)。当多个tcp stream同时
向下push的时候，也会发生network ifque full，这时候
network layer会delay tcp 的请求 （send函数会延迟
返回或者返回 error code）。
在中间节点上，情况会复杂的多，一个是因为普遍使用的
以太网没有data link layer flow control，传输方可能
会overrun接受方的物理处理能力，更多的情况是在多端
口router上，出现N对1的拥塞。
【在 s********k 的大作中提到】
: 拿你这个例子说，network必须等待indication之后才向MAC层push packet，但是作为
: 上层的TCP并不知道MAC的sliding window，一方面queue不能向下push数据，另一方面
: TCP可能又在往queue里面push数据。这就是掉包的原因？
|
z*****n
发帖数: 7639 | 23 tcp sliding window
【在 s********k 的大作中提到】
: 另外transmission control window是说TCP congestion window吧
|
z*****n
发帖数: 7639 | 24 另外一个网络掉包的情况现在也很常见：
现在很多WAN infrastructure 都是 SDH/ATM-based，
TCP/IP 这种 best effort oriented protocol
经常在 两网接口处 掉包，主要原因是 SDH
is bufferless。
【在 z*****n 的大作中提到】
: tcp只存在于通信的两端，中间节点上只有网络层。
: 这一点要搞清楚。在端节点，tcp向下push也是受控的（有
: tcp transmission window)。当多个tcp stream同时
: 向下push的时候，也会发生network ifque full，这时候
: network layer会delay tcp 的请求 （send函数会延迟
: 返回或者返回 error code）。
: 在中间节点上，情况会复杂的多，一个是因为普遍使用的
: 以太网没有data link layer flow control，传输方可能
: 会overrun接受方的物理处理能力，更多的情况是在多端
: 口router上，出现N对1的拥塞。
|
s********k
发帖数: 6180 | 25 看了一下，这个TCP sliding window操作和AIMD的congestion window似乎很像。唯一
的不同就是如果超出接收端的接受能力，会返回窗口为0.这个就是TCP上的flow
control吧
【在 z*****n 的大作中提到】
: tcp sliding window
|
z*****n
发帖数: 7639 | 26 window返零表示数据重传，是error control，
flow control是控制 window 大小。
【在 s********k 的大作中提到】
: 看了一下，这个TCP sliding window操作和AIMD的congestion window似乎很像。唯一
: 的不同就是如果超出接收端的接受能力，会返回窗口为0.这个就是TCP上的flow
: control吧
|
