TCP vs UDP

smc2315·2024년 3월 20일
0

Network

목록 보기
1/4

TCP와 UDP는 전송계층에서 사용되는 프로토콜이다.
전송계층은 프로토콜 내에서 송신자와 수신자를 연결하는 통신 서비스를 제공하는 계층인데,
ip에 의해 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당한다.
이러한 전송계층에서는 TCP와 UDP 프로토콜이 사용된다.
각 프로토콜에 대해 살펴보고 그 둘의 차이점에 대해 살펴보자.

1. TCP(Transmission Control Protocol)

TCP는 네트워크 계층 중 전송 계층에서 사용하는 프로토콜로서, 장치들 사이에 논리적인 접속을 성립하기 위하여 연결을 설정하여 신뢰성을 보장하는 연결형 서비스 이다. TCP는 네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟(데이터, 메세지, 세그먼트라는 블록 단위)를 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다.

1-1. TCP의 특징

TCP는 다음과 같은 특징이 있다.

  • 연결형 서비스
    연결형 서비스로 가상 회선 방식을 제공

  • 흐름제어(Flow control)
    데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지

  • 혼잡제어(Congestion control)
    네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지

  • 신뢰성이 높은 전송(Reliable transmission)
    Sequence Number, Ack Number를 사용하여 ACK 가 중복으로 오거나 안올 경우 패킷 이상을 감지하여 해결

  • 전이중, 점대점 방식
    전이중 (Full-Duplex): 전송이 양방향으로 동시에 일어날 수 있다.
    점대점 (Point to Point): 각 연결이 정확히 2개의 종단점을 가지고 있다.

1-2. TCP Segment

TCP는 데이터를 Segment 단위로 쪼개서 전송한다.
TCP Segment가 무엇으로 이루어져 있고, 각각의 역할을 알아보자.

TCP SEGMENT = TCP 헤더 (세그먼트 헤더) + 데이터

TCP Header 10개의 필수 필드 및 옵션 확장 필드들을 포함한다.

데이터 섹션의 내용은 애플리케이션의 페이로드(payload) 데이터이다. 

페이로드 전송의 근본적인 목적이 되는 데이터의 일부분으로 그 데이터와 함께 전송되는 헤더와 메타데이터와 같은 데이터는 제외한다.

TCP Header에 대해 좀 더 자세히 살펴보자.

1. Source port address, Destination port address

Transport Layer는 하나의 Application 안에 여러 process에 대한 구분을 짓기 위해 port 넘버를 부여한다. 각 16bit 공간에 Source와 Destination의 포트 주소를 저장한다.

2. Sequence number

TCP 세그먼트 안의 데이터의 송신 바이트 흐름의 위치를 가리킨다. 
다른 호스트로 전달되는 패킷은 여러 개의 서로 다른 경로를 거치면서 전달되다 보니 패킷의 순서가 뒤바뀔 수 있다. 
이를 수신 측에서는 재 조립해야 할 필요가 있는데 이 때 Sequence Number를 이용하여 조립하게 된다.

  • SYN Flag 1: 초기 시퀀스 번호 
  • SYN Flag 0: 현재 세션의 세그먼트 데이터의 누적 시퀀스 번호

3. Acknowledgment number

ACK 플래그가 설정된 경우 이 필드의 값은 수신자가 예상하는 다음 시퀀스 번호이다. 
한쪽이 보낸 최초의 ACK는 반대쪽의 초기 시퀀스 번호 자체에 대한 확인응답이 되며, 데이터에 대한 응답은 포함되지 않는다.

4. HLEN / Reserved / Control field(Flags)

HLEN : 32-bit 워드 단위로 나타낸 TCP 헤더 크기값이다. 
헤더의 최소 크기는 5 워드이며 (TCP Option이 없는 경우) 최대 크기는 15 워드이다. 

  • 최솟값: 20byte
  • 최댓값: 60byte

Reserved : 미래를 위해 예약된 필드

Control field : 기존의 6개의 Flag와 RFC 3168, 3540에 의해 추가된 3개의 Flag로 총 9개의 Flag로 이루어져 있다.

5. Window Size

수신하고자 하는 윈도우의 크기이다.
받을 수 있는 최대 크기는 2의 16승으로 65535까지를 받을 수 있다.

6. Checksum

오류 검출을 위해 사용되는 필드이다.
헤더 및 데이터를 16bit 단위로 분할하여 비트 합을 구한 뒤 여기에 1의 보수를 취한 값이다.
송신자는 이 알고리즘에 의해 계산된 체크섬을 이 필드에 삽입하고, 송신자는 같은 알고리즘으로 계산해서 동일한지 확인한다.

1-3. TCP의 연결 및 연결 해제

TCP는 연결 지향적인 프로토콜로, 데이터를 전송하기 전에 두 호스트 간에 연결을 설정해야 한다.
이 과정에서 3-way Handshaking과 4-way Handshaking이 사용된다.

PORT 상태 정보

  • CLOSED: 포트가 닫힌 상태
  • LISTEN: 포트가 열린 상태로 연결 요청 대기 중
  • SYN_RCV: SYNC 요청을 받고 상대방의 응답을 기다리는 중
  • ESTABLISHED: 포트 연결 상태

Flag 정보

  • SYN(Synchronize Sequence Number)
    • Connection을 생성할 때 사용하는 Flag
    • Sequence Number를 랜덤으로 생성하여 세션을 연결하는 데 사용
  • ACK(Acknowledgement)
    • 패킷을 받았다는 것을 의미하는 Flag
    • Acknowledgement Number 필드가 유효한지 나타낸다.
  • FIN(Finish)
    • 세션 연결을 종료시킬 때 사용하는 Flag
    • 더 이상 전송할 데이터가 없음을 의미한다.

1-4. 3-Way Handshaking


TCP의 연결 과정은 위의 그림과 같다.
일반적으로 Client와 Server 모두 연결 요청을 먼저 할 수 있다.

3-Way Handshaking은 양쪽 모두 데이터를 전송할 준비가 되어있다는 것을 보장하고, 실제로 데이터 전달이 시작하기 전에 다른 한쪽이 준비되었다는 것을 알 수 있도록 해준다.

3-Way Handshaking의 동작 과정을 살펴보면 다음과 같다.

Step 1. Client -> SYN -> Server

Client가 Server에게 접속을 요청하는 SYN Flag를 보낸다.

  • 송신자가 최초로 데이터를 전송할 때 랜덤 생성된 Sequence Number를 지정하고, SYN Flag bit를 1로 설정한 Segment를 보낸다.
  • PORT 상태
    • Client: SYN_SENT
    • Server: LISTEN

Step 2. Server -> SYN + ACK -> Client

Server는 Listen 샅애에서 SYN이 들어온 것을 확인하고 SYN + ACK Flag를 Client한테 전송한다.

  • ACK Number 필드를 Sequence Number + 1로 지정하고 SYN과 ACK Flag bit를 1로 설정한 Segment 전송
  • PORT 상태
    • Client: ESTABLISHED
    • Server: SYN_RCV

Step 3. Client -> ACK -> Server

SYN + ACK 상태를 확인한 Client는 서버에게 ACK를 보내고 연결 성립이 된다.

  • PORT 상태
    • Client: ESTABLISHED
    • Server: ESTABLISHED

1-5. 4-Way Handshaking

4-Way Handshaking은 TCP 연결을 종료하는 프로세스다.
4-Way Handshaking은 연결이 안전하게 종료되고 데이터 손실 및 혼란을 방지하기 위해 사용된다.

Termination의 종류

TCP는 두 가지의 연결 해제 방식이 존재한다.

  1. Abrupt connection release(예기치 못한 연결 해제)
    RST(TCP reset) Flag가 설정된 Segment가 전송되면 갑작스러운 연결 해제가 수행되는데, RST 세그먼트는 다음과 같은 경우에 전송된다.

    • 존재하지 않는 TCP 연결에 대해 SYN이 아닌 Segment가 수신된 경우
    • 열린 커넥션에서 일부 TCP 구현은 잘못된 헤더가 있는 세그먼트가 수신된 경우
      • RST 세그먼트를 보내, 해당 커넥션을 닫아 공격을 방지한다.
    • 일부 구현에서 기존 TCP 연결을 종료해야 하는 경우
      • 연결을 지원하는 리소스 부족할때
      • 원격 호스트에 연결할 수 없고 응답이 중지되었을때
  2. Graceful connection release(정상적인 연결 해제 방식)
    연결 종료 요청도 일반적으로 클라이언트와 서버가 모두 먼저 요청을 할 수 있다.
    정상적인 연결 해제는 4-Way Handshaking을 통해 이루어 진다.
    4-Way Handshaking의 동작 과정을 살펴보면 다음과 같다.

Step 1. Client -> FIN -> Server

Server와 Client가 연결된 상태에서 Client가 close()를 호출하여 접속을 끊는다.

  • PORT 상태
    • Client: FIN-WAIT-1
    • Server: ESTABLISHED

Step 2. Server -> ACK -> Client

Server는 FIN Flag를 받고, 확인했다는 ACK를 Client에게 보내고 자신의 통신이 끝날때까지 기다린다.(남은 데이터를 마저 전송)

  • PORT 상태
    • Client: FIN-WAIT-2
    • Server: CLOST-WAIT

Step 3. Server -> FIN -> Client

데이터를 모두 보내 Close 준비가 다 된 후 Server는 Client에게 FIN Flag를 전송한다.

  • PORT 상태
    • Client: FIN-WAIT-2
    • Server: LAST-ACK

Step 4. Client -> ACK -> Server

Client는 FIN Flag를 받고, 확인했다는 ACK Flag를 Server에게 보내고 TIME-WAIT 상태로 들어간다.

TIME-WAIT 상태는 의도치않은 에러로 인해 연결이 데드락으로 빠지는 것을 방지하기 위해 변경 되는 것인데, 만약 에러로 인해 종료가 지연되다가 타임이 초과되면 CLOSED 상태로 변경된다.

  • PORT 상태
    • Client: TIME-WAIT -> CLOSED
    • Server: CLOSED

1-6. 흐름 제어(Flow Control)

  • 수신측과 송신측 사이의 데이터 처리 속도 차이(흐름)을 해결하기 위한 기법
  • 송신측의 전송 속도가 수신측의 처리 속도보다 빠를 경우 전송된 패킷이 수신측의 버퍼를 넘어서 손실될 수 있기 때문에 송신측의 패킷 전송량을 제어한다.

Stop and Wait

  • 상대방이 응답을 하면 데이터를 보내는 방식
  • 패킷을 하나씩 보내기 때문에 비효율적이다.

Sliding Window(Go Back N ARQ)

  • 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 수신 측의 데이터 처리 상황을 송신 측에 알려주어 데이터의 흐름을 제어하는 방식
  • 송신 측과 수신 측은 각각 데이터를 담을 수 있는 버퍼를 가지고 있고, 별도로 윈도우라는 일종의 마스킹 도구를 가지고 있다.
  • ACK를 일일히 보내지 않아도 Sliding Window 내의 데이터를 연속적으로 보낼 수 있다.
  • 송신 측의 윈도우 크기는 맨 처음 TCP의 연결을 생성하는 과정인 3 Way Handshake 때 수신 측의 버퍼 크기를 기반으로 결정된다.

동작 방식

  • 먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 이 윈도우를 옆으로 옮김으로써 다음 패킷들을 전송한다.

1-7. 혼잡 제어(Congestion Control)

  • 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡 제어라고 한다.
  • 흐름제어가 송신 측과 수신 측 사이의 전송 속도를 다루는 데 반해, 혼잡 제어는 호스트와 라우터를 포함한 보다 넓은 관점에서 전송 문제를 다루게 된다.

AIMD(Additive Increase / Multiplicative Decrease)

  • 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
  • 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄인다.
  • 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형상태로 수렴하게 되는 특징이 있다.
  • 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

Slow Start

  • AIMD 방식은 처음에 전송 속도를 올리는데 시간이 오래 걸리는 단점이 존재
  • Slow Start 방식은 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 한 주기가 지나면 window size가 2배로 된다.
  • 전송속도는 AIMD에 반해 지수 함수 꼴로 증가한다. 대신에 혼잡 현상이 발생하면 window size를 1로 떨어뜨리게 된다.
  • 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있다.
  • 그러므로 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킨다.

Fast Retransmit (빠른 재전송)

  • 빠른 재전송은 TCP의 혼잡 조절에 추가된 정책이다.
  • 패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
  • 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.
  • 중복된 순번의 패킷을 3개 받으면 재전송을 하게 된다. 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 window size를 줄이게 된다.

Fast Recovery (빠른 회복)

  • 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다.
  • 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.

혼잡 제어 정책

TCP 회피 방식들을 활용한 다양한 혼잡 제어 정책이 존재하고, 정책들은 AIMD, Slow Start를 적절히 섞어서 사용하되 네트워크 혼잡 상황이 발생했을 때 어떻게 대처하는지에 따라서 나뉘게 된다.

TimeOut

송신측이 수식측에 데이터를 보낸 이후,여러가지 요인으로 인해서 보낸 데이터가 유실되었다거나 수신측이 데이터를 받고 전송한 ACK 응답이 유실되어 송신측이 일정 시간동안 응답받지 못하는 경우

ssthresh

  • slow start threshold
  • 여기까지만 slow start 를 사용하겠다는 의미

TCP Tahoe

  • 처음에는 동일하게 Slow Start 방식으로 윈도우를 증가시키다가 ssthresh 시점 이후부터는 AIMD 방식을 사용한다.
  • TimeOut 이나 3 ACK Duplicated가 발생할 때마다 윈도우는 1로, ssthresh는 이전 혼잡 상황 발생시 윈도우 크기의 절반으로 줄어든다.

TCP Reno

  • TCP Tahoe 정책과 동일하지만 차이점은 바로 3 ACK Duplicated 와 TimeOut 을 구분해 대응한다.
  • 3 ACK Duplicated가 발생하면 윈도우 크기를 1로 초기화 하지 않고 AIMD 처럼 윈도우 크기를 절반으로 줄이며 ssthresh 값 역시 줄어든 윈도우 값으로 설정한다.
  • TimeOut이 발생한다면 윈도우 사이즈를 1로 줄이고 Slow Start 를 시작하지만 ssthresh 값은 변경하지 않는다.

2. UDP

UDP는 비연결형 프로토콜로 보안과 신뢰성보다 전송 속도와 효율성이 더 중요한 경우 데이터를 전송하기 위해 IP과 함께 오래 사용된 프로토콜이다.

2-1. UDP의 특징

  • UDP는 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. 
  • 따라서 내용이 전송 중에 손실 될 수 있고, 전송되는 세그먼트의 순서가 바뀔 수 있다.
  • UDP는 TCP보다 간단하고 빠르다.
  • 작은 header size를 가지고 있다.
  • 흐름제어를 하지 않기 때문에 전송 속도를 최대한 빠르게 할 수 있다.
  • 수신자와 송신자 간의 handshaking이 없는 connectionless 성질을 가진다.

2-2. UDP Header

UDP의 Header는 TCP의 Header에 비해 상당히 간결하다.
soutce port number, destination port number, checksum과 UDP의 Header와 Data의 크기를 합친 length로 이루어져 있다.

TCP와 UDP의 차이점

참고

TCP와 3-Way, 4-Way Handshake란? (개념/ 동작 방식)

profile
개발일지

0개의 댓글