E D R S I H C RSS
ID
Password
Join
여자는 무서워...란 말은 여자 자체가 무서운 것이 아니다. 그 여자가 무슨 생각을 하는지, 날 어떻게 생각하고 행동하고 얘기를 하는지 모르는 것이 무서운거다. - "허니문 샐러드"라는 성인만화에서.

SWS를 설명하기 위해서 두가지 새로운 용어들을 먼저 정의하도록 하겠다. 표면적으로, window 메커니즘은 매우 단순하다 : "window"라고 불리우는 수신자로부터 송신자에게 반환되는 숫자가 전부이다. 어쨌거나, 우리는 이 숫자의 의미에 대해서 좀더 상세한 논의를 가질 필요가 있다. 데이타의 수신자는 제공된 "window"라고 하는 값을 산출한다. 단순한 경우에서는, 제공된 "window"는 receiver상에서 사용가능한 버퍼 공간의 크기와 일치한다. This correspondence is not necessarily exact, but is a suitable model for the discussion to follow. 제공된 "window"는 실제로는 수신자로부터 송신자로 역전송된다. 송신자는 제공된 window를 또다른 값, "사용가능한 window"을 산출하기 위해 사용한다. (이것은 "제공된 window - 두드러지게 공인되지않은 데이타의 크기"로 구한다.) 사용가능한 "window"는 제공된 "window"이하의 값을 가지며, 대부분 훨씬 더 작을 수 있다.

다음의 간단한 예를 생각해보자. 수신자는 초기에 1,000에 해당되는 제공된 "window"를 제공한다고 가정하자. 송신자는 이 window값을 받아 각각 200바이트의 5개의 부분으로 전송하는데 사용한다. 이 조각 메세지들중 첫번째를 처리중인 수신자는 갱신된 window값을 담고있는 알림(acknowledgement) 신호를 반환한다. 여기서 데이타의 수신자는 버퍼로부터 처음 200 바이트를 제거했다고 하고, 그 결과로 수신자는 다시 한번 1,000바이트의 사용가능한 버퍼를 가지게 되었다고 하자. 그러므로, 수신자는 이전처럼 1,000바이트의 제공된 "window"값을 반환할 수 있을 것이다. 이제 처음 알림 신호를 받은 송신자는 이제 전송될 추가적인 바이트들을 계산한다. In fact, of the 1,000 bytes which the recipient is prepared to receive at this time, 800 are already in transit, having been sent in response to the previous offered window. 이 경우에서, 사용가능한 window는 단지 200바이트가 된다.

이제 어떻게 SWS가 발생하는지 생각해보자. To continue the previous example, assume that at some point, when the sender computes a useable window of 200 bytes, it has only 50 bytes to send until it reaches a "push" point. It thus sends 50 bytes in one segment, and 150 bytes in the next segment. Sometime later, this 50-byte segment will arrive at the recipient, which will process and remove the 50 bytes and once again return an offered window of 1,000 bytes. However, the sender will now compute that there are 950 bytes in transit in the network, so that the useable window is now only 50 bytes. Thus, the sender will once again send a 50 byte segment, even though there is no longer a natural boundary to force it.

In fact, whenever the acknowledgement of a small segment comes back, the useable window associated with that acknowledgement will cause another segment of the same small size to be sent, until some abnormality breaks the pattern. It is easy to see how small segments arise, because natural boundaries in the data occasionally cause the sender to take a computed useable window and divide it up between two segments. Once that division has occurred, there is no natural way for those useable window allocations to be recombined; thus the breaking up of the useable window into small pieces will persist.

Thus, SWS is a degeneration in the throughput which develops over time, during a long data transfer. If the sender ever stops, as for example when it runs out of data to send, the receiver will eventually acknowledge all the outstanding data, so that the useable window computed by the sender will equal the full offered window of the receiver. At this point the situation will have healed, and further data transmission over the link will occur efficiently. However, in large file transfers, which occur without interruption, SWS can cause appalling performance. The network between the sender and the receiver becomes clogged with many small segments, and an equal number of acknowledgements, which in turn causes lost segments, which triggers massive retransmission. Bad cases of SWS have been seen in which the average segment size was one-tenth of the size the sender and receiver were prepared to deal with, and the average number of retransmission per successful segments sent was five.

다행히도, SWS는 어렵지 않게 피할수 있다. 다음 섹션들은 SWS를 완벽하게 제거할 수 있는, 전송자에서 실행되는 것과 수신자에 의해 실행되는 2가지 알고리즘을 설명한다. 실제로, 양쪽모두 스스로 SWS를 방지하기에는 충분하다. 따라서 이 문제를 알맞게 다룰 수 없는 외부 구현으로부터 호스트를 방어해준다. The two algorithms taken together produce an additional reduction in CPU consumption, observed in practice to be as high as a factor of four.

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2010-10-28 12:42:54
Processing time 0.3197 sec