예전에 2cpu에서 본 김윤술님의 글 중에서 '무작위 세션 UDP를 처리할 수 있는 NAT 칩은 존재하지 않는다'는 이야기를 봤는데, 그 이유가 궁금합니다.
NAT는 IP레이어에서 동작하면서 지나다니는 패킷의 Src Addr, Dst Addr, Port를 덮어씌워주고, 경우에 따라 ALG를 수행하면 되는 거 아닌가요? 굳이 UDP라고 해서 차별할 이유는 없어 보입니다. 프로토콜 스펙 때문에 Seq number등을 조작해줘야하는 TCP가 구현상으로 더 복잡하면 복잡했지..
도대체 무슨말인지...
UDP 를 처리할수 있는 용량은 제한적입니다. 즉 UDP 패킷은 단순한 인증이나 텍스트 기반 데이터만을 사용하는것이 메뉴얼인데 TCP에 속도좀 높여보겠다고 UDP 패킷을 사용하는 프로그램들이 많은겁니다. UDP는 받아줄수 있는 캐쉬값이 있습니다. 그걸 오바하면 네트워크단에 캐쉬가 오버풀 되서 부하가 걸리게 되고 실제 데이터를 받지 않는데 무작위로 날려주다 보니 그냥 뻗는 현상이 발생합니다.
한번 네트워크 단에서 그리드 다운로드를 TCP만 사용하는거랑 UDP만 사용하는거랑 테스트를 해보시기 바랍니다. 핑이 아주 들쑥날쑥 끊기고 난리나는게 UDP 때문이고 TCP만 사용했을때는 아무리 고용량을 붙고 세션이 많이 붙더라도 네트워크에 크게 영향을 주지 않습니다.
즉 공유기 NAT로는 이걸 처리해줄수 있는게 거이 없다는게 지금의 현실입니다. 게이트웨이 장비가 아무리 좋다고 해도 스위치단에서 아예 먹통이 되는경우도 간혹 있습니다.
'무작위 세션 UDP를 처리할 수 있는 NAT 칩은 존재하지 않는다'는 말씀은, 아마도 UDP 플로딩 발생시 제대로 처리할 수 있는 칩을 만드는것은 상업성이 떨어진다. 라는 의미로 해석하시면 되지 싶습니다.
아시다시피 UDP는 핸드쉐이크없이 날릴 수 있기 때문에, 네트웍의 대역폭이 허락하는 만큼 날릴 수 있고 그걸 다 받아서 처리하기란 불가능하지는 않지만, 일어나지도 않는(정확히는 일어나지 않기를 바라는) 일을 염두에 두고 고가의 장비를 개발하기는 채산성이 맞지 않기 때문입니다.
UDP Flooding은 가장 단순하면서도 효과적이었던 DoS, dDoS공격방법이었고, 대부분의 통신사에서 UDP를 차단하기는 하지만... 아직까지도 효과적인 방법의 하나 입니다.
말씀하신대로, 프로토콜 스펙상 TCP의 구현이 더욱 복잡하고, 그 복잡성 때문에 양끝단의 단말에서 약간의 지연(??)이 발생하며, 어느정도 예측할 수 있는 수준의 트래픽이 발생하므로 그 수준에 맞는 장비를 개발하기가(정확히는 성능의 최대치 산정) 수월합니다. 반대로 UDP의 경우에는 크기가 작은 패킷을 동일 시간에 훨~~~씬 많이 발생시킬 수 있기 때문에 TCP를 기준으로 개발된 NAT장비가 자신이 처리할 수 있는 한계치를 넘어버리게 됩니다.
뭐... 돈에 신경쓰지말고 개발하라면 개발이야 하겠지만, 시장에 내다팔 수도 없는 비싼장비는 회사측면에서 봤을때 아무 소용이 없는 물건이 되겠지요..
nat가 udp를 처리하기 어려워서 그런 게 아니라 udp 데이터그램은 tcp와 달리 회선혼잡과 수신측 호스트의 속도에 관계없이 보내고 싶은만큼 보낼 수 있어서 그런 겁니다. tcp는 rtt와 패킷 손실을 분석하면서 속도를 조절해나가는데 udp는 그런 거 없이 보내는 만큼 전달되기 때문에 그렇습니다.
nat가 tcp기준으로 개발되어서 udp를 처리하기에 성능이 낮다기보다는 정확히 말하면 tcp건 udp건 무관하게 line rate의 속도로 패킷을 포워딩할 성능이 안돼서 그런 것입니다. 똑같이 1000Mbps를 전달한다고 해도 64바이트 패킷이 넘어올 때랑 1500바이트 패킷이 넘어올 때랑은 그 패킷 수가 다릅니다. 당연히 전자가 더 높은 성능을 요구하는 것이고요.
하지만 tcp는 mtu로부터 mss를 계산해서 최대 패킷 크기로 전송하려고 합니다. 따라서 웬만하면 ip헤더 크기를 포함해서 1500바이트의 패킷으로 보내려고 하겠지만 udp는 그 크기도 마음대로 잘라서 보낼 수 있다는 것입니다.
다시 말해서 딱히 udp가 특수한 게 아니라 그냥 tcp udp 무슨 프로토콜이건 무관하게 nat나 라우터의 pps 능력이 낮아서 그런 것뿐입니다.
송주환
UDP 를 처리할수 있는 용량은 제한적입니다. 즉 UDP 패킷은 단순한 인증이나 텍스트 기반 데이터만을 사용하는것이 메뉴얼인데 TCP에 속도좀 높여보겠다고 UDP 패킷을 사용하는 프로그램들이 많은겁니다. UDP는 받아줄수 있는 캐쉬값이 있습니다. 그걸 오바하면 네트워크단에 캐쉬가 오버풀 되서 부하가 걸리게 되고 실제 데이터를 받지 않는데 무작위로 날려주다 보니 그냥 뻗는 현상이 발생합니다.
한번 네트워크 단에서 그리드 다운로드를 TCP만 사용하는거랑 UDP만 사용하는거랑 테스트를 해보시기 바랍니다. 핑이 아주 들쑥날쑥 끊기고 난리나는게 UDP 때문이고 TCP만 사용했을때는 아무리 고용량을 붙고 세션이 많이 붙더라도 네트워크에 크게 영향을 주지 않습니다.
즉 공유기 NAT로는 이걸 처리해줄수 있는게 거이 없다는게 지금의 현실입니다. 게이트웨이 장비가 아무리 좋다고 해도 스위치단에서 아예 먹통이 되는경우도 간혹 있습니다.
아시다시피 UDP는 핸드쉐이크없이 날릴 수 있기 때문에, 네트웍의 대역폭이 허락하는 만큼 날릴 수 있고 그걸 다 받아서 처리하기란 불가능하지는 않지만, 일어나지도 않는(정확히는 일어나지 않기를 바라는) 일을 염두에 두고 고가의 장비를 개발하기는 채산성이 맞지 않기 때문입니다.
UDP Flooding은 가장 단순하면서도 효과적이었던 DoS, dDoS공격방법이었고, 대부분의 통신사에서 UDP를 차단하기는 하지만... 아직까지도 효과적인 방법의 하나 입니다.
말씀하신대로, 프로토콜 스펙상 TCP의 구현이 더욱 복잡하고, 그 복잡성 때문에 양끝단의 단말에서 약간의 지연(??)이 발생하며, 어느정도 예측할 수 있는 수준의 트래픽이 발생하므로 그 수준에 맞는 장비를 개발하기가(정확히는 성능의 최대치 산정) 수월합니다. 반대로 UDP의 경우에는 크기가 작은 패킷을 동일 시간에 훨~~~씬 많이 발생시킬 수 있기 때문에 TCP를 기준으로 개발된 NAT장비가 자신이 처리할 수 있는 한계치를 넘어버리게 됩니다.
뭐... 돈에 신경쓰지말고 개발하라면 개발이야 하겠지만, 시장에 내다팔 수도 없는 비싼장비는 회사측면에서 봤을때 아무 소용이 없는 물건이 되겠지요..
nat가 tcp기준으로 개발되어서 udp를 처리하기에 성능이 낮다기보다는 정확히 말하면 tcp건 udp건 무관하게 line rate의 속도로 패킷을 포워딩할 성능이 안돼서 그런 것입니다. 똑같이 1000Mbps를 전달한다고 해도 64바이트 패킷이 넘어올 때랑 1500바이트 패킷이 넘어올 때랑은 그 패킷 수가 다릅니다. 당연히 전자가 더 높은 성능을 요구하는 것이고요.
하지만 tcp는 mtu로부터 mss를 계산해서 최대 패킷 크기로 전송하려고 합니다. 따라서 웬만하면 ip헤더 크기를 포함해서 1500바이트의 패킷으로 보내려고 하겠지만 udp는 그 크기도 마음대로 잘라서 보낼 수 있다는 것입니다.
다시 말해서 딱히 udp가 특수한 게 아니라 그냥 tcp udp 무슨 프로토콜이건 무관하게 nat나 라우터의 pps 능력이 낮아서 그런 것뿐입니다.