[네트워크] TCP와 UDP의 차이란?

TCP와 UDP의 차이는 무엇일까요?

1. TCP(Transmission Control Protocol)란? IP 규칙으로만 통신하기에 부족하거나 불안정하던 여러 단점들(패킷 순서가 이상하거나 패킷이 유실)을 커버해, 패킷 전송을 제어하여 신뢰성을 보증하는 프로토콜로 보면 된다. 원활한 통신을 위해 전송흐름을 제어하는 기능을 프로토콜 자체에 포함되어 있다. 
   • IP규칙은 목적지까지 도착했을 때 적용(배달지)
   • TCP 규칙은 올바르게 도착했는지, 정확히 누구에게 전달되어야 하는지 세세하게 살펴보는 것이다.(부가 정보)
   • 예시: 수신자 정보를 받아야하는 은행 업무나 메일

IP란? 인터넷 프로토콜로서 복잡한 인터넷 망 속에서 클라이언트와 서버 간에 통신할 수 있게 IP주소와 패킷과 같은 규칙을 통해 통신을 하게 하는 것

프로토콜이란? 클라이언트와 서버가 정보를 교환할 수 있도록 하는 메시지 형식에 대한 규칙

패킷이란? 더 큰 메시지의 작은 세그먼트입니다. 

- 전송되는 데이터는 패킷으로 나뉜다 -> 패킷을 수신하는 컴퓨터 또는 장치에서 재결합됩 된다.

• 전송 데이터 포장 과정
  1. 전송 데이터를 TCP 포장한다.
  2. 포장한 전송 데이터를 IP 포장한다.
  3. 포장한 전송 데이터를 이더넷 포장한다.
  4. 인터넷을 통해 상대 컴퓨터 서버에 도달하여 포장된걸 하나씩 풀며 전송데이터를 받게 된다.

2. UDP(User Datagram Protocol)란? 데이터그램 방식을 사용하는 프로토콜이기 때문에 애초에 각각의 패킷 간의 순서가 존재하지 않는 독립적인 패킷을 사용한다.

• 데이터 그램 방식은 패킷의 목적지만 정해진다면, 어떤 경로를 타도 상관이 없기 때문에 TCP 과정을 거치지 않아서 속도가 더 빠르다.
• 예시: 실시간 영상 스트리밍과 같은 고용량 데이터를 다루는 곳에 이용된다.

왜 HTTP는 TCP를 사용하나요?

클라이언트와 서버 간의 정확한 패킷 통신이 필요하기 때문에 신뢰성을 보장 받아야하기 때문에, TCP를 사용하였습니다.

그렇다면, 왜 HTTP/3 에서는 UDP(QUIC) 를 사용하나요? 위에서 언급한 UDP의 문제가 해결되었나요?

• 계속된 잘전으로 인해 클라이언트와 서버가 동시 다발적으로 여러 개 파일의 데이터 패킷을 교환하게 되면서 문제가 발생하였습니다. 또한, TCP는 신뢰성을 위해 무조건 순서대로 처리되고, 중간에 패킷이 손실되게 되면 패킷을 다시 보내야한다는 점과 패킷 파싱 속도가 느려서 통신에 병목현상이 나타나게 되면 UDP를 채택하게 되었습니다.
• 기존의 UDP는 신뢰성이 없는게 아니라 탑재를 안했을 뿐이며, 커스터 마이징이 가능합니다. 그래서 이번에 HTTP/3는 UDP 기반으로 TCP+TLS+HTTP 기능을 모두 구현하는 프로토콜인 QUIC(Quick UDP Internet Connections)을 채택하였습니다.

본인이 새로운 통신 프로토콜을 TCP나 UDP를 사용해서 구현한다고 하면, 어떤 기준으로 프로토콜을 선택하시겠어요?

많은 데이터 전송이 일어나는 경우에는 UDP를 이용하여 프로토콜을 사용하겠습니다. 많은 데이터 전송의 경우에는 속도가 중요하다고 생각이 들었으며, 위에 내용처럼 커스터 마이징이 가능하기 때문에 충분히 신뢰성도 보장할 수 있다고 생각하여 선택하였습니다.

Checksum이 무엇인가요?

• 간단하게 에러 검출을 하는 방법으로, 중복 검사의 한 형태입니다.
• 전송되는 헤더 및 데이터의 무결성을 보장하기 위해 사용되며, 기본적으로 데이터의 합으로 계산됩니다.
• 방법
  • 송신측에서, 전송할 모든 데이터를 16 비트 워드 단위로 구분하고, 
  • 1의 보수를 취하고, 그 합에 대한 결과를 전송하면,
  • 수신측에서, 같은 합을 해보아서 오류를 검출하는 방식

TCP와 UDP 중 어느 프로토콜이 Checksum을 수행할까요?

UDP가 수행하며, UDP 헤더의 CheckSum 필드를 통해 최소한의 오류만 검출합니다.

오류 검출을 제공하며, 세그먼트가 출발지로부터 목적지로 이동 했을 때, UDP 세그 먼트 안의 비트에 대한 변경사항이 있는지 검사합니다.

그렇다면, Checksum을 통해 오류를 정정할 수 있나요?

CheckSum의 경우에는 오류를 찾는 것으로 오류를 정정할 수 없습니다.

그러면 오류를 정정하기 위해서는 어떻게 해야하나요?

해밍코드를 사용하면 됩니다. 해밍코드의 경우 하나의 데이터 단위에 대해 충분한 패리티 비트를 추가해 오류를 검출하고, 수정까지 할 수 있는 방식입니다.

TCP가 신뢰성을 보장하는 방법에 대해 설명해 주세요.

1. TCP는 배달하기 전에 목적지가 무사한지 미리 확인하고 배달 끝나고도 또 확인해주는 프로토콜입니다.

• 즉, 통신을 시작할 때와 종료할 때 서로 준비가 되어있는지 반드시 미리 먼저 물어보고 패킷 전송할 순서를 정하고 통신 시작합니다(매우 계획적이다)
• 이 과정이 3 Way Handshake(통신을 시작할 때)와 4 Way Handshake(통신을 마칠때)과정이다.
  • 처음 서버와 통신하기 위해 TCP연결을 생성할 때 SYN와 ACK 패킷을 주고 받는다.
  • 통신을 종료하는 과정에서 FIN 패킷을 주고 받는다.

2. Flag 종류

3-way handshake 과정

1. 클라이언트는 접속을 요청하느 SYN 패킷을 보냅니다. 이때 클라이언트는 응답을 기다리기위해 SYN_SENT 상태로 변화합니다.

2. LISTEN 상태였던 서버는 SYN 요청을 받으면, 클라이언트에게 요청을 수락하는 ACK패킷과 SYN 패킷을 보냅니다.

그리고,SYN_RCVE(SYN_RECEIVED)상태로 변하여 클라이언트가 ACK패킷을 보낼 때까지 기다린다.

3. 클라이언트는 다시 서버에 ACK 패킷을 보내고, 이 후 ESTABLISHED 상태가 되어 데이터 통신이 가능하게 된다.

데이터 통신 과정

1. Established 된 상태에서 서버에게 데이터를 보낸다.

2. 서버는 잘 전송받았다고 ACK 플래그를 넣어 응답한다.

3. 만약 클라이언트가 서버로부터 ACK를 못받았으면 제대로 송신하지 못한 걸로 판단하고 데이터를 재전송한다.

4-way handshake 과정

1. 서버와 클라이언트가 TCP 연결이 되어있는 상태에서 클라이언트가 접속을 끊기 위해 CLOSE()함수를 호출한다.

그러면 FIN 플래그를 보내게 되고 클라이언트는 FIN_WAIT1상태로 변한다.

2. 서버는 클라이언트가 CLOSE()한다는 것을 알게되고 CLOSE_WAIT 상태로 바꾼 후 ACK 플래그를 전송한다.

만일 서버에서 클라이언트로 보낼 남은 데이터가 있을 경우 이때 나머지를 모두 전송시킨다.

3. ACK를 받은 클라이언트는 FIN_WAIT2로 변환되고, 이때 서버는 CLOSE()함수를 호출하고 FIN 플래그를 클라이언트에게 보낸다.

서버도 연결을 닫았다는 신호를 클라이언트가 수신하면 ACK 플래그를 보낸 후 TIME_WAIT 상태로 전환된다. 이 후 모든 것이 끝나면 CLOSED 상태로 변환된다.

8. TCP의 혼잡 제어 처리 방법에 대해 설명해 주세요.

• 네트워크가 불안정하여 데이터가 원활히 통신이 안되면 제어를 통해 재전송을 하게 되는데, 재전송 작업이 반복되면 네트워크가 붕괴될 수도 있다. 따라서 네트워크 혼잡 상태가 감지되면 송신 측의 전송 데이터 크기를 조절하여 전송량을 조절한다.
• TCP에는 Tahoe, Reno, New Reno, Cubic, Elastic-TCP 등 다양한 혼잡 제어 기법이 존재한다.

참고

https://www.cloudflare.com/ko-kr/learning/network-layer/what-is-a-packet/

🌐 아직도 모호한 TCP / UDP 개념 ❓ 쉽게 이해하자

 

체크섬(Checksum)

 

체크섬

 

[네트워크] UDP와 TCP

 

오류 검출 방식(패리티 검사, CRC, 체크섬, 해밍코드)::네트워크

 

오류 정정 코드 - 나무위키