[Network] TCP와 UDP의 특징과 차이점

갑자기 TCP와 UDP는 어디서 나왔을까?

=> OSI-7 레이어 모델에서 나왔당.

 

OSI-7 Layer Model이 뭔데? 

 

쉽게 말하자면! 컴퓨터와 컴퓨터가 네트워크를 통해 데이터를 공유할 때 통신이 일어나는 과정을 7단계로 나눈 것을 의미한다.

 

 

왜 굳이 계층을 나눴을까?

그야 ... ... 통신이 일어나는 과정을 단계별로 파악하기 위해서가 아닐까?!

이렇게 말하니 질문과 동시에 뱅글뱅글 도는 답변을 하는 것 같지만, 조금 더 서술하여 답변해 보자면,

네트워크의 계층을 나눈 이유는 흐름을 한눈에 알아보기 쉽고 특정한 곳에 이상이 생기면 이상이 생긴 단계만 빠르게 고치기 위해서라고 생각한다.

 

OSI-7 Layer Model은 컴퓨터와 컴퓨터가 네트워크를 통해 데이터를 공유할 때 통신이 일어나는 과정이라고 했다.

통신이 일어나게 된다면 통신을 보내는 client측이 7계층인 Application Layer부터 시작하여 Presentation Layer, Session Layer, Transport Layer, Network Layer, Data Link Layer, Physical Layer 순서로 쭉쭉 내려간다. (7 -> 1) 

 

일단! 여기서는 OSI-7 Layer Model이 메인이 아니니까 간단히 설명해 보자면~~~

7, 6, 5계층, 넓게 말해 Application 계층이라고 불리는 친구들은 우리가 보내는 데이터를 포장하고 압축하여 통신을 보내기 위한 토대를 만들어 준다고 보면 된다.

왜, 우체국에서 등기를 보낼 때도 우리가 보내기 전에 포장하고 접수하는 과정을 거쳐야 하듯이! 이게 그 포장~접수 과정이라고 보면 된당.

4계층인 Transport Layer의 경우에는 통신을 보내기 위한 계층이다! 우체국에 가면 등기 / 우편을 골라야 하듯이 컴퓨터는 여기서 TCP / UDP 프로토콜을 사용하는 것이다.

 

... ... 근데 프로토콜이 먼디요? 
-> 장치들간에 통신을 하기 위해 절차나 관례를 미리 정의해 놓은 것을 말한다! 장치들간에 주고받는 데이터는 어떤 형식을 갖추어야 하고 어떤 순서로 전달되어야 하는지에 대한 약속이 되어 있다.
... ... 왠지 메일 보내는 것과 비슷한 것 같당. 왜, 보통 메일 보낼 때는 인사 -> 본인이 누구인지 밝힘 -> 본론 -> 끝인사 -> 누구올림. 이런 식으로 가지 않은가? 보통 안 그럴 수도 있기는 하지만, 만약 이력서를 넣은 회사에 냅다 면접 언제 봐요? 하고 묻고 자기가 누구인지 밝힌다면 매우 실례일 것이다. 내가 원하는 정보를 얻기 위해서 메일을 작성하고자 한다면, 적절한 형식과 순서를 맞춰서 메일을 작성해야 하듯이 네트워크에서 특정한 정보를 주고받는 프로토콜 또한 올바른 정보를 주고받기 위해서는 적절한 형식과 순서가 필요한 것이당.

 

 

아무튼 말이 길어졌다!

 

이후 3계층에서는 보내는 경로(ip 주소)를 설정하고, 2계층에서는 물리적으로 해당 데이터를 보내는 경로를 관리한다.(MAC). 

이후, 1계층에서는 네트워크의 물리적 주소로 정보를 직접적으로 보내게 된다.

 

 

아무튼! TCP와 UDP는 앞서 말한 4계층에서, 통신을 보내기 위해서 어떤 절차나 관례가 필요한지에 대해 미리 정의해 놓은 것이다.

 

앞서 등기와 우편을 예로 들었지 않은가?

미리 말하자면 TCP는 등기와 같고, UDP는 우편과 같당.

 

 

 

자세한 건 아래에서!!! ^__^

 

 

 

TCP

특징 

• 우체국의 등기와 비슷하다.
• 패킷으로 데이터를 관리하며, 일반적이고 신뢰성 있는 통신을 말한다.
  • 이때, 신뢰성 있는 통신이란 보낼 때의 순서를 보장하며, 데이터에 대한 무결성을 보내는 쪽에서 보장해 준다.
  • 이후, 데이터를 받은 쪽에서 유실이 되었다면 다시 데이터를 전송해 준다. (유실 방지!!)
• 느리지만 믿을만하다.
  • 하지만, 매번 보낼 때의 순서를 확인하고 / 무결성을 보장하며, 유실을 방지하기 때문에 불필요한 데이터 전송이 많이 일어날 수 있다.
  • 왜, 사진을 전송할 경우 한 픽셀 정도가 오지 않았다고 해서 큰 문제가 되지는 않을 것이다. 하지만, 사진의 경우에 TCP를 사용한다면? 겨우 1픽셀이 안 왔는데 다시 모든 데이터를 재전송해야 하므로 낭비가 심할 것이다.
  • 근데 글을 전송한다면?!
    • Hello. Nice to meet you. 라는 글을 전송했을 때, TCP를 사용하지 않고 UDP를 사용하여 전송했다면 ... ...
      Hell             to          you. < 이딴 식으로 전송될 수도 있다.
    • 그렇기 때문에 유실이 되면 안 되는 정보의 경우 주로 TCP를 이용한다.
• 일반적으로 IP와 함께 사용되며, IP는 배달을, TCP는 패킷의 추적과 관리를 하게 된다.
• 흐름 제어 및 혼잡 제어를 한다.
  • 이게 멀까 싶다... ... 자자 들어보자
  • 데이터 통신 시, 수신측이 송신측보다 데이터처리 속도가 빠르면 문제가 없지만, 송신측의 속도가 빠를 경우 문제가 발생한다. 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있으며, 이 경우에는 불필요한 데이터 전송과 응답이 많이 발생할 것이다.
  • 따라서!!!!!! 이런 위험을 줄이기 위해 송신측 데이터 전송량을 수신측에 따라 조절해야 한다.
    • 예시를 들어보자면 ... ... 이런 거다. 공장에서 가와 나가 짝지어서 일을 한다고 하자. 가 -> 나로 일을 진행하며, 가가 일을 마치면 나가 그 일을 받아서 처리한다.
      만약 나가 유능하다면? 가가 얼마나 느리게 주든 별로 상관하지 않을 것이다. 왜냐면 가가 주는대로 일을 처리하면 되니까! 이 경우, 물품들은 모두 적절한 품질을 유지하며 판매할 수 있을 것이다.
      ... ... 근데 가가 너무너무너무 유능하다면? 뒤에서 나는 죽을 노릇일 것이다. 가가 일을 정말 잘해서 해야 할 일이 할 수 있는 일보다 과분하게 쌓이기 시작한다. 그럼 나는 어떻게 될까? 아~ 몰라몰라 일을 대충대충 처리할 것이다.
      근데 문제가 있다! 그렇게 된다면 물품의 품질이 떨어져서 해당 물품들은 팔 수 없고, 재제작을 해야 한다 ... ...
    • 위와 같은 경우, 가가 TCP의 송신측, 나가 TCP의 수신측이라고 볼 수 있다. ^__^ 
• 3-way handshake 과정을 통해 연결을 설정하고, 4-way handshake 과정을 통해 해제한다.

 

구현 방식

TCP의 경우 구현 방식은 3-way handshake / 4-way handshake 두 가지로 나뉜다.

• 3-way handshake
  • 3-way handshake의 경우 세션 연결 시에 시행되며, 양쪽 모두 데이터를 전송할 준비가 되어 있다는 걸 보장하고, 실제로 데이터 전달이 시작되기 전에 다른쪽이 준비되었다는 걸 알 수 있도록 해준다.
  • 해당 방법은 다음과 같다.
    • 먼저 client가 서버에게 접속을 요청한다. (이를 SYN 플래그를 보낸다구 한다.)
    • 이후 서버는 client에서 요청이 들어온 것을 확인 후 SYN 플래그에 ACK 플래그를 더불어 클라이언트에게 전송한다.
    • 그럼 보낸 SYN 플래그 + ACK 플래그를 확인한 client는 서버에게 ACK를 보내고 연결을 성립한다.
• 4-way handshake
  • 4-way handshake의 경우 세션을 종료할 때 수행되는 절차를 의미한다.
  • 해당 방법은 다음과 같다.
    • client가 연결을 종료하겠다는 FIN 플래그를 전달한다.
    • FIN 플래그를 받은 서버는 확인 메세지인 ACK를 client에게 보내준다. 이후, client는 서버에서 받게 될 플래그를 기다린다.
    • close 준비가 됐다면 서버는 client에게 FIN flag를 전송한다.
    • client는 ACK 플래그를 서버에 보내 해지 준비가 되었다고 알린다. 이때, client는 TIME-WAIT 상태로 변경되는데... ...
      • TIME-WAIT 상태는 의도치 않은 에러로 인해 연결이 데드락으로 빠지는 것을 방지하기 위해 변경된다. 만약 에러로 인해 종료가 지연되다가 타임이 초과되면 CLOSED 상태로 변경된다.
  • 근데 왜 세션이 종료될 때 한 번 더 단계를 수행할까?
    • 왜냐하면 client가 데이터 전송을 마쳤다고 하더라도 서버에서 보낼 데이터가 아직 남아있을 수도 있기 때문에 이를 확인하기 위함이다!
  • 이후, 궁금한 질문들은 있지만 아직 이해하지 못했기 때문에 ... ... ^__^ 처음 네트워크 공부이기 땜에. 가볍게 훑고 다시 TCP / UDP 개념을 공부할 일이 생겼을 때 더욱 깊게 파고들어 보려고 한다. 정리해 놨으니 모두 다 까묵지는 않겠지~~!!

 

UDP

• UDP는 TCP와 달리, 우체국 우편이라고 보면 된다.
• TCP는 연결할 때와 연결 후에 확인하는 과정을 거쳤다면, UDP는 거치지 않는다. 조금 더 빠르고 러프한 전달이라고 보면 된다!
  • 네트워크 통신 시 연결/해제가 필요한 TCP와 달리, UDP는 연결이 필요하지 않다.
  • 또한, 신뢰도가 낮다.
    • 신뢰도가 낮다는 건, 메세지가 제대로 도착했는지 확인하지 않는다. (TCP는 확인함)
    • 수신된 메세지의 순서 또한 다를 수 있다. (TCP는 순서 제어를 통해 순서대로 감)
    • 흐름 제어를 하지 않는다. (TCP는 함)
    • 오류 제어 기능이 거의 없다. (따라서, 사용하는 프로그램측에서 오류제어 기능을 갖춰야 한다.)
• 요청과 응답이 빠르다.
  
  • 다수 지점에 전송 또한 가능하다!
• 헤더가 단순하여 헤더 처리에 걸리는 시간이 적다.

 

 

 

 

근데 UDP는 왜 나왔을까?

굳이 기능만 본다면 나는 UDP가 왜 존재하는지 이해가 잘 안 됐다. -. -))

 

하지만, TCP가 먼저 나오고 그 불편함 때문에 UDP가 나온 걸 생각하면 UDP가 왜 나왔는지 이해가 된다.

물론 그 예시를 보면 이해가 되기도 하지만!

 

그 이유에 대해 설명해 보자면, TCP가 신뢰성 있게 전송하는 것도 좋고, 뭐 흐름 제어를 하는 것도 좋다구 하자. 근데 너무너무너무 과도할 정도로 빡빡하다.

 

앞서 예시를 들었던 것처럼, 큰 이미지의 경우에는 1px 정도 전송이 되지 않았다고 해서 크게 문제가 되지 않을 것이다. 동영상은 또 어떤가? 100분짜리 영화를 다운로드 받으려고 할 때, 만약에 한 장면의 1px이 어그러져서 100분을 다시 다운받아야 한다면?

 

그만큼 낭비가 또 없을 것이다.

 

이러한 경우에 TCP가 너무너무너무 답답해서~ UDP라는 프로토콜이 등장한 것이다. TCP와 달리, 빠르고 단순하게 일단 전달! 을 목적으로 삼기에 연결/해제도 하지 않고, 제대로 도착했는지 확인하지도 않으며 순서 제어도 하지 않는다. 그냥 일단? 보내기만 하면 OK인 것이다.

... ... 나는 왜케 UDP 하면 유튜브가 떠오를까? 안 그래도 영상 매체를 예를 들어서 더 그런 것 같다. 유튜브도 딱 이와 같다. 왜, 네트워크가 안 좋으면 HD는 커녕 맨날 480* ... ... 으로 나오지 않는가? :3

 

 

반면, TCP가 꼭 필요한 경우는 있다. 이 경우도 앞서 예시를 들었던 것처럼 긴 글을 보낼 경우, 글은 한 자라도 빠지면 문맥이 이상할 수도 있고, 제 의미를 전달하지 못할 수도 있기 때문에 꼭! TCP로 전달해야 할 것이다.

 

 

처음에 공부를 하고도 잘 이해가 안 돼서 여러 곳을 많이 찾아보고 유튜브로 영상도 보면서 공부를 하니 이제 좀 이해가 되는 것 같다 ^__^ b

 

러프하게 이해하고 거기서 이건.. 왜? 라는 생각이 들 때 더 파고들어서 찾아보면 너무 즐겁고 지식을 깨달았을 때 뿌듯함도 두 배인 것 같다.

 

 

 

 

아휴휴 짧게 쓰고 자려고 했는데 또 길어졌지만~~~!!!!!! 그래두 오래 붙잡고 있던 글인 만큼 정리해서 작성한 글이 꽤 뿌듯하다 ㅎ-ㅎ 다음에는 OSI-7 Layer Model이나 HTTP/HTTPS를 주제로 써봐야겠다.

 

아! 이전에 미뤄놨던 앱의 생명 주기나 뷰컨의 생명 주기도 다시 정리하고 싶당.

 

수료했으니 미뤄놨던 글을 하루에 죽죽 작성해 버릴 테다 ... ..............