ECHO 를 주고받는 프로그램을 두 머신에서 돌린다고 할때에 200ms 의 nagle 알고리즘을 켠 상태에서는 초당 5회정도의 패킷 교환이 일어나겠지만 nagle 알고리즘을 끄게 되면 네트웍이 허용하는한 최대의 횟수만큼의 패킷 교환이 일어나겠죠. (테스트 해봤었는데 수치는 1:100... 정도랄까요) 간단하게 레이턴시를 희생해서 대역폭을 좀 더 확보하는 녀석이라고 이해하시면 될겁니다. 레이턴시가 중요하다면 무조건 끄세요. 그런데 사실 하려던 얘기는 이것도 아니고,혹시 -_-; nagle을 그고 테스트 해보신다면
얼마나 향상되는지 답글좀 부탁드립니다
혹시 UDP 로 reliable 한 TCP 같은것을 만들어 쓰시려거든 그냥 서버를 통해 TCP 중계를 해서 쓰시길 추천합니다. 성능이나, 안정성이나 모든 면에서 직접 구현한 reliable 프로토콜은 TCP 에 비해 뒤쳐질 것입니다.쌀밥 wrote:앞서 제가 언급한 책에 나오는 이야기이지만,
UDP 를 사용해서 기본 UDP 기능에는 없는 많은 기능들을 추가 할 수는 있습니다.
심지어 TCP 에서만 보장된다고 생각되는 reliable 속성도 UDP 에 추가 하드 코딩을 해서 얻어 내는게 가능하기는 합니다.
[...]
제 앞글의 의도는.... 게임에서도 신뢰도는 중요하고, reliable 하게 UDP 를 수작업으로 개량시키느니 TCP 가 낳지 않은가 하는 것이었는데... 그 밖의 고려할만한 내용이 있었던 거군요.. 공부가 되었습니다..
UDP 기반으로 무언가를 만들겠다는 것은 결국 "시스템콜" 로 뭔가를 만들겠 다는 이야기인데 이는 프로토콜 성능에 있어서 절대적인 영향을 끼치는 이벤트 감지, 타이머를 모두 OS 가 제공하는것으로 쓰겠다는 얘기입니다.
200ms 의 nagle 알고리즘을 만든다고 가정합시다. 그렇다면 200ms 가 지났다는것은 어떻게 감지해야 할까요? 폴링? 아니면 Windows Timer? 어떤 것이든 커널 내에서 IP 레이어 바로 위에서 동작하고 있는 TCP 코드보다 우수할 수는 없습니다.
참고로 이전에 UDP 로 reliable 한 stream 프로토콜을 만들어본 적이 있었습니다만 그때도 issue 는 "성능" 이 아니었습니다. 굉장히 특수한 상황이었지요. 입사 이전에 게임 로비가 이미 TCP 로 구현되어 있었고 그 위에 굉장히 많은 feature 들이 완성된 상태였기에 NAT 를 뚫기 위해서는 로비를 재작성 하기 보다 UDP 로 TCP 를 에뮬레이션 하는것이 비용이 더 적게 들었습니다. 이를테면 리펙토링의 수단이랄까요..