02_11_네트워크 프로그래밍_TCP vs UDP

요약: 지난 시간에는 서버와 클라이언트를 만들고 송수신 인터페이스를 구현했습니다. 이제 게임에서 문자열 대신 패킷을 사용해야 합니다. TCP 프로토콜을 사용하고 있지만, 패킷 분석과 전송에는 규약이 필요합니다. TCP와 UDP의 차이점을 알아야만 MMO를 만들 수 있습니다. TCP는 순서 보장과 분실 책임을 지지만 속도가 느리고, UDP는 순서 보장과 분실 책임이 없지만 속도가 빠릅니다. 일반적으로 MMO에서는 안정성이 중요하기 때문에 TCP가 많이 사용됩니다.

 

테스트 문제:

1. TCP 프로토콜을 사용하는 경우 어떤 특징이 있나요?
2. UDP 프로토콜의 장점은 무엇인가요?
3. MMO 게임에서 일반적으로 어떤 프로토콜이 많이 사용되나요? 왜 그렇게 사용되나요?

답변:

1. TCP 프로토콜은 순서 보장, 분실 책임 지기, 끊어서 보내기 등의 특징이 있습니다. 그러나 속도가 상대적으로 느리다는 단점도 있습니다.
2. UDP 프로토콜의 장점은 순서 보장과 분실 책임이 없기 때문에 속도가 빠르다는 것입니다. 또한, 연결 개념이 없어서 끊김이 없이 편리하게 작업할 수 있습니다.
3. MMO 게임에서는 일반적으로 TCP 프로토콜이 많이 사용됩니다. 이는 MMO 게임에서 안정성이 레이턴시보다 중요시되기 때문입니다.

지난 시간까지 세션 작업을 어느정도 완료 해가지고 라이브러리로 ServerCore를 뺀 다음에 걔네들을 사용해서 DummyClient랑 Server를 만들었었어. 이제는 어느정도 송수신 인터페이스가 잘 작동하는 거 까지 확인을 했어. 마지막까지 한 것을 보면

public override void OnRecv(ArraySegment<byte> buffer)
{
    string recvData = Encoding.UTF8.GetString(buffer.Array, buffer.Offset, buffer.Count);
    Console.WriteLine($"[From Server] {recvData}");
}

이렇게 문자열을 보냈는데 게임을 만들면 문자열이 아닌 패킷이라는 클라랑 서버가 서로 합의된 규약을 서로 보내기 시작야 한다.

예를 들어 가장 쉬운 게 이동패킷인데 보통 아래와 같은 식으로 구현이 될거야.

// 이동 패킷 (3,2 좌표로 이동하고 싶다!)

이 패킷을 우리가 만든다고 가정을 하면 이동하고 싶다라는 패킷의 번호가 있을거고, // 예를들면 이동하고 싶다는 패킷의 번호가 15번이라고 하면

좌표 3,2

// 15, 3, 2 이런 식으로 데이터가 들어가서 서버쪽에다가 쏴주면 서버에서는 이 패킷을 까봐서 15번이니까 클라이언트는 이동하고 싶어하는구나 하고

그리고 이 15번에 해당하는 규약은 다음에 정수 2개를 보내기로 합의를 했다고 가정을 하면

// 3, 2를 까서 그 좌표로 이동시키는 작업을 한다.

칼같이 규약된 프로토콜대로 서로 데이터를 주고 받고 분석을 해야 한다는 말이 된다.

그렇다면 이동 패킷이라는 15, 3, 2이렇게 숫자로 이루어졌다고 가정을 해보자.

15, 3, 2를 보내면 서버에서는 똑같이 15, 3, 2를 통째로 받아야지만 얘를 분석해서 실행시킬 수 있을거야. 만약 어떤 이유로 15랑 3까지만 짤려서 왔으면 당연히 얘는 실행을 하면 안될거야. 정보가 불충분하니까 당연히 말이 안될거야. 왜 지금 일부만 보내는 얘기를 하는걸까?

사실은 아직 얘기 안한게 있어. 간단히 문자열만 보내고 있었으니까 패킷 설계를 할 때 까지 미루고 있었는데

지금 TCP 프로토콜을 이용하고 있는데 TCP 프로토콜에서는 Send를 한다 가정을 했을 때 100바이트를 보내면 받는 쪽에서 반드시 100바이트를 받는다는 보장이 없다.

충격적이겠지만 이게 TCP의 특징이기도 하다.

TCP는 경우에 따라 혼잡이 일어나서 보내기가 부담이 된다면 설령 Send를 100바이트를 요청을 했더라도 일부분만 여유 되는 부분만 보내고 나머지는 조금 있다가 보내는 그런 작업도 할 수 있게 된다.

 

TCP로 mmo 만드려면 Tcp에 대한 이해도가 어느정도 있어야지만 앞으로 진행을 할 수 있다.

 

오늘은 패킷을 당장 만들지는 않고 TCP에 대한 이론에 대한 내용을 알아본다.

택배 배송 할 때 여러 단계를 거친다고 했어.

 

보내는 입장은 위에서 아래 순서로 차례대로 실행을 한다고 했어. 정보를 차곡차곡 쌓아서 전송을 하게 될거고,

 

반대로 받는 입장에서는 아래부터 위로 하나씩 까보게 될거야. 택배 운송이 왔으면 단지경로를 봐서 전달을 하고 최종주소가 맞는지 확인을 한 다음에 배송 정책에 따라 반송을 해야할지 말지 보고, 합격을 하면 마지막 단계인 상품 단계로 넘어가서 101호의 사람이 상품을 까보는 그런 단계를 거친다고 말했어.

TCP 프로토콜은 배송정책에 해당한다.

 

네트워크 쪽으로 다시 살펴보면, 스위치, 라우터로 용어가 바뀐 차이가 있을뿐 실제로 TCP 레이어로 보면 1,2,3,4,5단계로 이루어져 있는데 그 중에서 TCP는 4단계인 트랜스포트 레이어에 위치해있다. TCP할지 UDP할지를 여기서 정하고 있는거.

배송 정책은 다양한 용어를 포함하고 있어. 일반적 택배를 생각해보면 받는 사람의 사인 받아야 하나, 문 앞에 두고 갈지, 혹시 택배 분실시 보상을 해주는지 같은 여러가지 정책을 얘기한다.

면접에서도 정말 기본을 물어볼 때 TCP와 UDP의 차이를 물어본다.

이미지화 해서 기억하는게 정신 건강에 좋다.

TCP를 생각할 때는 오른쪽의 전화기 하나랑 왼쪽의 안전한 트럭을 생각하면 되고

UDP는 편지를 보낸다 생각하고 왼쪽의 총알배송 오토바이를 생각하면 된다.

연결 지향성이라는 용어가 나오는데 TCP같은 경우에는 연결형 서비스, UDP는 비연결형 서비스다.

 

전화를 할 때 상대방의 번호를 입력해서 상대방이 받을 때 까지 기다려. 연결이 된 다음에야 상대방에게 들리는 게 될텐데 그게 연결형 서비스라고 볼 수 있다. 나와 그 사람 사이에 연결되는 경로가 있다 생각하면 된다.

반대로 우편이나 편지를 보낼 떄는 연결이라는 개념이 없는거, 나는 누구고, 내가 무엇을 전달하고 싶은지 편지에 적어 우편함에 넣으면 언젠가는 전달이 될거야. 애당초 UDP는 연결이라는 개념이 없다.

전송순서 보장되냐도 중요한 개념이다. 전화기로 대화하면 순서가 보장이 되어 이어지게 된다. 안녕하세요, ~입니다 순서대로 듣는 사람에게 전달된다. 거꾸로 뒤바뀌어 들릴 가능성은 없다. 반면 편지를 보내면 우편물이 여러 경로로 보내질 수 있으니 두번째로 보낸애가 먼저 도착할 수도있다.

 

분실이 일어났을 때 책임을 질것이냐 안질것이냐가 첫번째 얘기. 속도도 연관성이 있어.

TCP는 안정적인 회사라 분실이 일어나면 택배 회사에서 책임지고 다시 전송해준다. 회사가 직접 수신하는 사람에게 전화해서 부재중이면 나중에 보낸다거나 홍잡 제어를 해주게 된다. 고려할게 많으니 속도 좀 떨어져.

UDP는 그냥 퀵으로 보내고 문앞에 두고 가는거. 책임 안지니 속도가 빨라.

 

비교 TCP 거꾸로 뒤집으면 UDP

 

파란색으로 표시된 부분이 게임 만들 때 핵심 요소가 될거야.

순서 보장 vs 순서 보장 안함

분실 책임 지기 vs 보내면 책임 안지기

끊어서 보내기 vs 전체 보내기

 

TCP가 느리다는 건 UDP에 비해 느리다는 거지 절대적으로 느린 건 아냐.

UDP 쓴다해도 TCP처럼 분실 일어날 때 재전송 한다거나 전송 순서를 보장하게 뭔가를 만들어 줘야 한다. reliable UDP라고 하는데 그걸 고려할 수도 있지만 조금 더 기술적으로 어렵게 된다.

또 일반적으로 UDP는 분실되어도 상관 없을 경우에 사용해 ex) FPS 게임(Ratency가 중요해), 이동하는 거(분실해도 다음 패킷이 갱신 가능), 언리얼 엔진에서 제공하는 데디케이트 서버도 UDP를 사용한다.

 

UDP의 또다른 장점은 연결이라는 개념이 없다는게 장점이기도 하다. 지하철 같은데서 모바일 게임 하다 보면 중간에 끊기기도 하는데 TCP는 끊기면 재연결 할 때 까지 통신을 못하는데, UDP는 연결 개념이 없어서 편리하게 작업할 수 있다. 모바일은 게임은 UDP고려도 나쁘지 않지만 그렇다고 TCP 요소를 아애 고려하지 않는 건 아니다. 선택의 여지가 있다.

일반적으론 MMO 는 ratency보다 안정성을 중요시 해서 TCP가 많이 쓰인다.

 

출처: https://inf.run/3uyY