[컴퓨터 네트워크] TCP & UDP

UDP

UDP란

 

User Data Protocol의 약자로 인터넷에서 데이터를 보낼 때 쓰는 전송 계층 프로토콜 중 하나.

“빨리 보내지만, 잃어버리거나 섞여도 별 말 안하는 프로토콜”

장단점

장점

1. 빠르다(오버헤드가 적음)
   1. 연결 설정(3-way handshake 등)이 없다.
   2. 헤더가 작고, 추가 기능이 적어서 처리 비용이 낮다.
      1. 지연에 민감한 애플리케이션에 유리
2. 비연결형(Connectionless)
   1. 클라이언트-서버 간에 연결상태를 따로 유지하지 않음
   2. 서버 입장에서는 많은 클라이언트를 상대할 때도 상태를 덜 들고 있어서 리소스 부담이 적음.
3. 브로드캐스트, 멀티캐스트 지원
   1. 동일 네트워크에서 여러 호스트에게 한 번에 데이터를 보내기 좋음
   2. 예시: 게임 서버의 위치 정보 방송, 스트리밍, 로컬 네트워크 서비스 검색 등
4. 애플리케이션에서 자유로운 제어 가능
   1. 신뢰성, 재전송, 순서 보장 등을 애플리케이션 레벨에서 직접 구현할 수 있음
   2. TCP가 너무 무겁다, 우리 서브시에 맞는 규칙으로 커스텀하고 싶다고 할 때 선택할 수 있다.
5. 실시간 서비스에 적합
   1. 약간의 패킷 손실은 괜찮고 지연이 더 치명적인 서비스에 적합
      1. 인터넷 전화
      2. 화상 회의
      3. 온라인 게임
      4. 실시간 스트리밍

단점

1. 신뢰성이 없다.
   1. 패킷이 유실될 수 있음
   2. 패킷이 중복해서 도착할 수 있음
   3. 패킷이 순서가 뒤바뀌어 도착할 수 있다.
   4. 이걸 보장해주는 건 애플리케이션이 직접 처리해야 함.
2. 혼잡 제어/ 흐름 제어 없음
   1. TCP는 네트워크가 혼잡하면 전송 속도를 조절하지만, UDP는 그런게 없음.
   2. 잘못 쓰면 네트워크를 과부하 상태로 만들 수 있음.
3. 세션 개념이 없음
   1. 연결 상태를 유지하지 않으니 누가 언제 연결하고 상태가 어떤지 프로토콜 차원에서 알 수 없음
   2. 로그인/세션/상태 관리는 모두 애플리케이션 쪽에서 구현해야 함

체크섬

UDP는 checksum 헤더를 통해 수신된 데이터에 변조되지 않았는지 여부만 판단할 수 있다.(네트워크로 송신된 데이터는 네트워크의 물리적 구성요소에 의해 비트 오류가 발생할 수 있음)

UDP 세그먼트를 word(16비트)단위로 나눈다.

나누어진 각 word를 모두 더한 다음 1의 보수 연산을 수행하여 checksum을 만든다.

UDP 세그먼트 헤더의 checksum에 만든 checksum을 넣고 세그먼트를 송신한다.

수신측에서 세그먼트를 수신하면 그 세그먼트에 대해 checksum을 다시 만든 다음

수신된 checksum과 비교하면 오류 여부를 판단할 수 있다.

어떤 서비스에 활용?

• UDP는 빠르기 때문에 DNS와 SNMP등의 프로토콜에서 활용된다.
  • DNS의 목적은 단지 도메인 네임에 대한 IP주소를 얻는 것이다. 따라서 오버헤드가 적고 빠른 UDP 위에서 동작하는 것이 적합하다.
  • SNMP는 주기적으로 네트워크 장비에 대한 정보를 수집하고 관리하는 프로토콜이다. 네트워크 장비는 수백대 수천대가 될 수 있다. 따라서 오버헤드가 적고 빠른 UDP가 적합하다.
• UDP는 인터넷 전화 또는 스트리밍 서비스에 적합하다.
  • 인터넷 전화 또는 스트리밍 서비스는 최소한의 전송률이 보장되면서 약간의 데이터 손실을 허용한다.
  • 따라서 속도가 빠르지만 신뢰적인 데이터 전송을 보장하지 못하는 UDP가 적합하다.

신뢰적 데이터 전송의 원리

전송 후 대기 프로토콜(Stop and Wait Protocol)

 

전송 후 대기 프로토콜은 데이터를 전송한 후 수신자로부터 확인(ACK)을 받을 때까지 대기하는 방식이다.

이 프로토콜은 송신자가 한 개의 프레임을 전송하고, 수신자로부터 응답을 받을 때까지 기다리는 방식으로 동작한다. 수신자는 전송받은 프레임에 대해 ACK 또는 NAK(부정) 신호를 송신자에게 되돌려 보낸다. 송신자는 ACK 신호를 받으면 다음 프레임을 전송하고 NAK 신호를 받으면 같은 프레임을 재전송한다.

이 접근 방식은 안정적인 데이터 전송을 보장하는 데 도움이 되지만 특히 발신자와 수신자 사이에 상당한 왕복 시간이 있는 경우 속도가 느려지고 네트워크 링크 활용도가 낮아질 수 있다.

교육용, 개념 설명용, 단순 무선 통신 시스템에서만 사용됨.

파이프라인 프로토콜(Pipelined Protocol)

앞서 알아봤듯이 신뢰적 데이터 전송은 Stop-and-wait 프로토콜을 통해 이뤄진다.

즉, 데이터를 전송한 뒤 수신자로부터 데이터 전송에 대한 결과를 피드백 받은 후 다음 데이터를 전송하는 방식이다. 하지만 이러한 Stop-and-wait 방식은 송신자가 패킷을 전송하는데 오랜 시간이 걸린다. 송신자는 패킷이 올바르게 전송되었다는 수신자의 피드백(ACK)을 받고나서 다음 패킷을 전송하기 때문이다.

이러한 성능 이슈를 파이프라이닝(pipelining)을 통해 해결할 수 있다.

파이프라이닝은 전송된 패킷에 대해 피드백을 받지 않고도 다음 패킷들을 전송하도록 허용하여 링크 이용률을 높이는 기술이다.

파이프라이닝에서도 패킷 손상과 손실, 순서가 맞지 않는 전송이 발생하는데, 이러한 오류에 대해 두 가지 기본적인 접근 방법이 있다.

바로 GBN(Go-Back-N)과 SR(Selective Repeat)이다.

HTTP 파이프라이닝 ⊂ 파이프라인 프로토콜

→ HTTP에서 파이프라인 기법을 쓴 구체적인 기능 이름

→ “HTTP는 파이프라인 프로토콜이 될 수 있다”

TCP는 Sliding Window + 파이프라이닝 + ACK 누적 방식을 사용한다.

SR(Selective Repeat)

Selective Repeat 프로토콜은 손실되거나 손상된 패킷에 대해서만 재전송한다.

GBN처럼 윈도우 크기만큼 패킷들을 전송하지 않는다. 즉, 불필요한 재전송을 하지 않는다.

SR 수신자는 누적확인 응답을 하지 않는다. 순서번호가 앞서는 패킷이 도착하면 그대로 수신한다.

송신자의 행동

1. 패킷 송신하기
   1. 상위 계층에서 데이터를 받으면, 먼저 윈도우가 가득 찼는지 확인한다.
   2. 윈도우가 가득 차지 않았다면, 다음 순서 번호에 해당하는 패킷이 생성되고 전송된다.
   3. 윈도우가 가득 차 있다면, 상위 계층으로부터 받은 데이터를 반환하며 윈도우가 가득차서 전송을 할 수 없음을 나타낸다.(송신자는 나중에 다시 데이터를 보내서 전송을 시도할 것이다.)
2. ACK 수신하기
   1. ACK가 수신되었을 때, SR 송신자는 그 ACK가 윈도우에 있다면, 그 패킷을 수신된 것(초록색)으로 표기한다.
   2. 수신된 패킷의 순서번호가 윈도우의 send_base와 같다면
   3. 윈도우는 가장 작은 순서번호를 가지면서, 아직 확인응답이 되지 않은 패킷의 순서번호로 이동한다.
   4. 윈도우가 이동한 후 윈도우 내에 아직 전송되지 않은 패킷이 있다면 전송한다.
3. 타이머 동작시키기
   1. 각 패킷마다 논리 타이머가 존재한다.(하나의 하드웨어 타이머는 여러 개의 논리 타이머를 구현한다.)
   2. 특정 패킷의 타이머가 타임아웃되면 해당 패킷은 개별적으로, 선택적으로 재전송된다.

수신자의 행동

1. rcv_base ~ rcv_base + N - 1 범위(수신 윈도우 범위)의 순서번호를 가지는 패킷이 수신되는 경우
   1. 처음 수신한 패킷이라면 수신 버퍼에 저장되고, ACK를 보낸다.
   2. 만약 수신한 패킷의 순서번호가 rcv_base라면, 이 패킷부터 연속된 패킷들을 상위 계층에 보낸다.
   3. 윈도우는 앞으로 이동한다.
2. rcv_base -N ~ rcv_base - 1 범위(수신 윈도우 이전 범위)의 순서번호를 가지는 패킷이 수신되는 경우
   1. 이전에 확인 응답한 것이라도 ACK를 보낸다.(송신 측 윈도우 이동을 위해)
3. 이외의 경우(수신 윈도우 이후 범위)
   1. 수신된 패킷을 무시한다.

SR 동작 예시

 

 

• 송신, 수신 윈도우 크기가 4인 SR 프로토콜의 동작 예시다.
• 위 그림에서 수신자는 0, 1번 패킷을 수신했고, 2번 패킷을 수신하지 못했고, 3, 4, 5번 패킷을 수신했다.
• 2번 패킷에 대한 타임아웃이 발생하고 2번 패킷만 재전송된다.
• 수신자는 재전송된 2번 패킷을 수신하고 ACK2을 송신자에게 보낸다. 이때 2번 패킷은 수신 윈도우의 rcv_base와 일치하고
• 2번 패킷부터 연달아 수신이 된 패킷들을 상위 계층에 전송하고, 수신측 윈도우를 슬라이딩한다.
• 이제 수신 윈도우는 6,7,8,9번의 범위를 갖게된다.
• 수신자는 send_base에 해당하는 2번 패킷이 올바르게 수신했음을 ACK2로부터 알아내고, 송신 윈도우를 슬라이딩한다.
• 위 그림을 보면 송신자의 윈도우와 수신자의 윈도우가 항상 같지 않음을 볼 수 있다.

GBN(Go-Back-N)

GBN에서 송신자는 송신한 패킷에 대한 확인 응답 없이, 최대 N개의 패킷을 전송할 수 있다.

이를 크기가 N인 윈도우로 표현한다.(N은 흐름제어와 혼잡제어에 의해 조정된다.)

송신한 패킷이 올바르게 수신 측에 도착하여 확인 응답을 받으면, 윈도우는 앞으로 이동하고 다음 패킷을 전송한다.

이를 슬라이딩 윈도우 프로토콜(sliding-window protocol)이라고 부른다.

 

 

GBN 송신자의 행동

1. 패킷 송신하기
   1. 상위 계층에서 데이터를 받으면, 먼저 윈도우가 가득 찼는지 확인한다.
   2. 윈도우가 가득차지 않았다면, 다음 순서 번호에 해당하는 패킷이 생성되고 전송된다.
   3. 윈도우가 가득 차 있다면, 상위 계층으로부터 받은 데이터를 반환하며 윈도우가 가득 차서 전송할 수 없음을 나타낸다.
2. ACK 수신하기
   1. GBN 프로토콜에서 순서번호 N을 가진 패킷에 대한 확인 응답은 N까지의 순서번호를 가진 모든 패킷들에 대한 확인 응답이다. ⇒ 누적 확인 응답(cumulative acknowledgement)
   2. 예를들어 송신자가 수신자로부터 ACK 7을 받았다면 7번 패킷까지 올바르게 전송되었음을 의미한다.
   3. 확인 후 윈도우를 앞으로 이동시키고, 다음 패킷을 전송한다.
3. 타이머 동작시키기
   1. 패킷이 손실되거나 매우 긴 전송 지연으로 타임아웃이 발생한다면 해당 패킷부터 윈도우 크기 N만큼 패킷을 재전송한다. 그래서 Go back N이다.
   2. 송신자는 전송되었지만 아직 확인을 받지 못한 패킷 중 가장 오래된 것에 대한 단일 타이머를 사용한다.

GBN 수신자의 행동

1. 수신된 패킷의 순서가 올바른 경우
   1. 직전 수신한 패킷의 번호가 n-1이고 이번에 수신한 패킷의 번호가 n이라면 수신자는 n번 패킷에 대한 ACK를 송신자에게 전송하고 상위 계층에 n번 패킷의 데이터를 전달한다.
2. 수신된 패킷의 순서가 올바르지 않은 경우
   1. 수신자는 순서가 잘못된 패킷들을 버린다.
   2. 그리고 가장 최근에 올바르게 수신된 패킷에 대해 ACK를 보낸다.

GBN 동작 예제

 

위 그림은 윈도우 크기가 4인 경우에 대한 GBN 프로토콜의 동작과정이다.

윈도우의 크기가 4이기 때문에 송신자는 0, 1, 2, 3번 패킷을 확인 응답받지 않고 연속적으로 송신한다.

전송한 각 패킷에 대한 ACK을 받으면, 윈도우는 앞으로 이동하고 송신자는 다음 순서를 갖는 패킷을 송신한다.

위 그림에서 2번 패킷은 손실되었다. 수신자는 2번 패킷을 못받은 채로 3, 4, 5번 패킷을 수신한다.

하지만 수신자는 2번 패킷을 못받은 상태이므로 올바르게 수신한 3,4,5번 패킷을 버리고 ACK1을 송신한다.

위 예제에서 송신 측을 보면 타이머가 Time out 되는 것을 볼 수 있다. GBN에서 Time out이 되면 수신 확인이 되지 못한 가장 오래전에 전송한 패킷부터 N만큼 재전송한다.

GBN의 장단점

• GBN은 파이프라이닝을 가능하게 하여, 링크 이용률을 높여준다는 장점이 있다.
• 하지만, GBN에서 패킷이 손실되면 N개 만큼의 패킷을 불필요하게 재전송하는 단점이 있다.
• 네트워크에 손실이 많이 발생할수록 네트워크 파이프 라인(링크)는 불필요한 재전송 패킷으로 채워진다는 단점이 있다.

TCP

 

TCP란?

• TCP는 신뢰적인 데이터 전송을 보장한다.
• 연결지향형이다.(Connection-oriented)

3 way handshake(연결 설정)

 

3-way-handshake는 신뢰적인 데이터 전송을 보장하기 위해 3개의 패킷을 주고 받으며 사전 연결 설정을 수립하는 과정이다.

1단계: 클라이언트 → 서버(SYN)

• 클라이언트가 서버에게 연결 요청 메시지를 전송하는 단계다.
• SYN 플래그 비트를 1로 설정하고, 랜덤으로 Sequence Number를 지정한 세그먼트를 전송한다.
• 1단계 종료 후 포트 상태
  • 클라이언트: CLOSED(포트가 닫힌 상태)
  • 서버: LISTEN(포트가 열린 상태로 연결 요청 대기 중)

2단계: 서버 → 클라이언트(SYN + ACK)

• 서버가 클라이언트의 연결 요청을 수락하여, 클라이언트의 포트도 열어 달라는 메시지를 전송하는 단계다.
• SYN 플래그 비트를 1로 설정하고, ACK 플래그 비트를 1로 설정하고, Acknowledgement Number 필드를 “Sequence Number + 1”로 지정한 세그먼트를 전송한다.
• 클라이언트는 서버의 ACK를 통해 현재 서버가 alive 임을 확인한다.
• 2단계 종료 후 포트 상태
  • 클라이언트: CLOSED → ESTABLISHED(포트 연결 상태)
  • 서버: LISTEN → SYN_RCV(SYN 요청을 받고 상대방의 응답을 기다리는 중)

3단계: 클라이언트 → 서버(ACK)

• 마지막으로 호스트 클라이언트가 서버에게 확인 메시지를 전송함으로써 서버가 클라이언트를 확인하여 연결을 확립하는 단계다.
• 이때 전송할 데이터가 있으면 이 단계에서 데이터를 전송할 수 있다.
• 서버는 클라이언트의 ACK를 통해 현재 클라이언트가 alive 임을 확인한다.
• 3단계 종료 후 포트 상태
  • 클라이언트: ESTABLISHED
  • 서버: ESTABLISHED

4 way handshake(연결 해제)

 

4개의 특별한 패킷을 주고 받으며 TCP 연결을 해제하는 방법이다.

1단계: 클라이언트 → 서버(FIN)

• 클라이언트는 서버에게 연결을 종료하겠다는 FIN 플래그를 1로 설정한 세그먼트를 보낸다.
• 포트 상태
  • 클라이언트: FIN_WAIT_1
  • 서버: CLOSE_WAIT

2단계: 서버 → 클라이언트(ACK)

• 서버는 클라이언트에게 ACK를 보낸다. ACK를 받은 클라이언트는 FIN_WAIT_2로 포트 상태를 바꾼 뒤 서버의 FIN 패킷을 기다린다.
• 포트 상태
  • 클라이언트: FIN_WAIT_2
  • 서버: CLOSE_WAIT

3단계: 서버 → 클라이언트(FIN)

• 서버도 클라이언트에게 연결을 종료하겠다는 FIN 플래그를 1로 설정한 세그먼트를 보낸다.
• 포트 상태
  • 클라이언트: TIME_WAIT
  • 서버: LAST_ACK

4단계: 클라이언트 → 서버(ACK)

• 클라이언트는 서버의 종료 요청에 응답하며 마지막 ACK를 보낸다.
• 마지막 ACK를 수신한 서버는 포트를 닫는다.
• 포트 상태
  • 클라이언트: CLOSED
  • 서버: CLOSED

TCP 빠른 재전송

 

타임아웃에 의한 재전송의 문제점은 타임아웃의 주기가 때때로 길다는 점이다.

다행히도 송신자는 중복 ACK 수신을 통해 타임아웃이 일어나기 전에 송신된 패킷이 손실되었음을 인지할 수 있다.

수신자는 순서가 올바르지 않은 세그먼트를 수신하면, 마지막으로 올바르게 수신된 세그먼트에 대한 ACK를 송신측에 전송한다.

송신자가 만약 같은 세그먼트에 대해 3개의 중복된 ACK(원본과 합치면 총 4개)를 수신하게 되면 해당 ACK에 해당하는 세그먼트가 손실되었음을 인지하게 재전송을 하게된다.

이는 타임아웃에 상관없이 이루어지므로 빠른 재전송이라고 할 수 있다.

Congestion Control(혼잡 제어)

네트워크에 흘러들어오는 트래픽 양이, 네트워크가 처리할 수 있는 용량을 초과한 상태.

• 네트워크 혼잡을 줄이기 위해 패킷 송신 속도 즉, 송신 측의 윈도우 크기를 조절하는 것을 말한다.
• 네트워크가 혼잡해지면 지연이 커지고 패킷 손실이 발생한다.
• 패킷이 지연되거나 손실되면 재전송이 이루어지는데, 이렇게 되면 네트워크는 더욱 혼잡해진다.

Flow Control(흐름 제어)

송신자가 너무 빠르게 데이터를 보내서 수신자의 TCP 수신 버퍼가 넘쳐 흐르는 상황(버퍼 오버플로우)을 막기 위한 매커니즘

• 수신자는 자신의 빈 버퍼 크기를 ACK에 실어 송신자에게 알려준다.
• 송신자는 이 값에 맞춰 전송 속도를 조절하여 수신 버퍼가 감당할 수 있는 만큼만 데이터를 전송한다.

어떤 통신에 사용될까?

TCP는 신뢰성이 중요하고, 순서가 보장되야 하고, 데이터가 유실되면 안되는 통신에 사용된다.

• 파일 전송(FTP, HTTP/HTTPS 다운로드)
  • 파일은 1바이트도 틀리면 안됨
  • 중간에 패킷이 날아가면 재전송 필요
  • 순서 보장 필수
• 웹 브라우징(HTTP/HTTPS)
  • 네이버 접속, 유튜브 페이지 로딩 등
  • HTML/CSS/JS 파일이 깨지면 페이지가 망가진다.
  • HTTPS는 TLS Handshake 때문에 TCP 기반
• 데이터베이스 통신
  • 쿼리 응답이 유실되면 안됨
  • 순서도 매우 중요
  • 트랜잭션 처리 때문에 패킷 재전송 필요
• 이메일
• 메신저 / 채팅
  • 다만 일부 메신저는 알림/실시간 기능은 UDP도 함께 사용
• SSH/원격 연결