http://www.dslreports.com/drtcp에 가셔서 drtcp를 한번 실행해 보시기
바랍니다.

TCP receiving windows가 작게 설정되 버려져 있는경우가 있는데
충분히 늘여 주시면 원할한 downlink data throughput을 가질수 있습니다.

많은 수의 비교적 작은 크기의 파일들을 자주 받는다면 initial window size가 작을 경우 영향이 크겠지만 (html page load같은 경우나 thumb nail http put 같은 것), 적은 수의 큰 파일을 받을 때는 상관이 없지 않나요? p2p로 무비같은 것을 받으시는데 maximum throughput으로 가는데 시간이 좀 더 걸리겠지만, 최고치가 그렇게 현저히 낮아지지는 않을텐데요.

“http://msdn.microsoft.com/en-us/library/ms819736.aspx”
참고가 되었으면 좋겠습니다.

작은 크기의 파일들을 자주 받는거랑 큰 파일 하나를 MTU만큼 잘라서 여러번 자주 보내는거랑
별로 차이를 모르겠네요. 결국 TCP/IP stack 에서 봤을땐 거기서 거기일듯 합니다.

처음 글올린 사람인데요. 그냥 drtcp.exe 파일을 실행하고 그냥 save만 누르면 되는건가요? 그럼 optimal한 값을 찾아서 저장해주게 되는 건지요?
하여튼 이렇게 했더니… 이제 속도가 wired로 하듯 빨라졌네요. 너무너무 감사드립니다. 꾸벅~

저의 얄팍한 지식이 도움이 되서 저도 왠지 기분이 좋네요.
세상에 있는 이유가 가끔은 있군요 제가.

와~~ 딱 맞았네요.

제가 생각한 것은 작은 파일들의 경우 window scaling으로 window size가 커지기 전에 세션이 끝나버리니 전체적 throughput이 떨어질 것이며, 큰 파일의 경우 충분히 window size가 조정될 기회를 갖게 되지 않는가 하는 것이었습니다. 저는 initial window size에 관련없이 converge하는 곳은 같을거라고 생각한 거였거든요. 보통 TCP에서 slow start 때문에 문제된다면 그런거라고 여겨져서요. 음.. 제가 네트웍 쪽이 확실히 딸리는군요. 한 15년 전에는 버틸만 했었는데요 ^^ 그러고 보니 예전에 인터뷰 질문에서도 버벅거렸던 기억이 새록새록.

0xd055//님 이제 이해 했습니다.

사실 저 값은 initial window size가 아니라 maximum일때 값입니다.
slow start해서 converge할때 upperbound에 영향을 주는 값이지요.
님이 말씀하신것 처럼 사실 작은 data traffic같은 경우는 data throughput을
비교하는것 자체가 별로 의미가 없으니까요.

아마 원글님도 두 인터페이스를 놓고 비교해 봤을때
consistent downlink data traffic일때 rate을 보셨을꺼라고 멋대로 해석했습니다.

저도 네트워크쪽이랑은 아주 약간만 다리를 걸치고 있습니다.
사실 별로 상관 없는 엔지니어입니다.