TCP/UDP 란

박태현·2025년 3월 29일

면접 cs 웹

Web & Network

목록 보기

5/6

TCP란 ? ( Transmission Control Protocol )

종단간 통신 ( 송신자와 수신자 간에 직접 데이터를 주고받는 방식 )에서 신뢰성을 보장하는 연결 지향형 프로토콜로, 데이터가 순서대로, 오류 없이 전달

프로토콜 : 컴퓨터나 네트워크 장치들이 데이터를 원활하게 주고받기 위해 정한 통신 규칙 및 약속 ( 데이터 전송 방식 정의, 데이터 순서 및 오류 제어 , 네트워크 흐름 및 혼잡 제어 )

TCP의 특징

3-way handshaking 과정을 통해 연결을 설정
4-way handshaking 과정을 통해 연결을 해제
데이터 전송 전 호스트 간의 연결이 필요
데이터의 전송 순서를 보장
데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지
네트워크 내의 패킷 수가 과도하게 증가하지 않도록 방지
신뢰성이 높은 전송을 하기 때문에 UDP보다 속도가 느림
전이중(Full-Duplex) : 전송이 양방향으로 동시에 일어날 수 있다.
점대점(Point to Point) : 각 연결이 정확히 2개의 종단점을 가지고 있음
3-way handshaking 과정

TCP 프로토콜로 통신하기 위해 데이터 전송 전 상호 연결을 하는 과정

발신자와 수신자 사이의 논리적인 접속 ( 세션 )을 성립하는 과정

SYN : 연결 확인을 보내는 무작위의 숫자 값

ACK : Client 혹은 Server로부터 받은 SYN에 1을 더해 응답하는 ACK

CLOESD : 연결 수집 전 기본 상태 ( 연결 x )

LISTEN : 포트가 열린 상태로 연결 요청 대기

SYN_SENT : SYN을 전송한 상태

SYN_RECEIVED : SYN 요청을 받고 상대방의 응답을 기다리는 상태

ESTABLISHED : 연결 수립이 완료된 상태 , 서로 데이터를 교환할 수 있는 상태

먼저 OPEN 한 클라이언트가 SYN(n)을 보내고 SYN_SENT 상태로 전환
SYN(n)을 받은 서버는 SYN_RECIEVED로 전환하고 SYN(m)과 응답 ACK(n+1)를 Client로 전송
SYN(m)과 응답 ACK(n+1)를 받은 Client는 ESTABLISHED로 전환하고 서버에 ACK(m+1) 응답
응답 ACK를 받은 서버는 ESTABLISHED 상태로 전환

4-way handshaking 과정 TCP를 통해 데이터 전부 전송한 후 연결을 해제하는 과정 ( 즉 데이터 전송을 위해 열어 놓았던 포트를 닫는 과정 )

`FIN-WAIT-1 : 자신이 보낸 FIN에 대한 ACK를 기다리거나 상대방의 FIN을 기다림`

`FIN-WAIT-2 : 자신이 보낸 FIN에 대한 ACK를 받았고, 상대방의 FIN을 기다림`

`CLOSE-WAIT : 상대방의 FIN(종료 요청)을 받은 상태, 상대방 FIN에 대한 ACK를 보내고 어플리케이션에 종료를 알림`

`LAST-ACK : COLSE-WAIT 상태를 처리 후 자신의 FIN 요청을 보낸 후 FIN에 대한 ACK를 기다리는 상태`

`TIME-WAIT : 모든 FIN에 대한 ACK를 받고 연결 종료가 완료된 상태. 새 연결과 겹치지 않도록 일정 시간 기다린 후 CLOSED로 전이`

1. 먼저 close를 실행한 Client가 FIN을 보내고 FIN-WAIT-1 상태로 대기
2. 서버는 CLOSED-WAIT으로 바꾸고 응답 ACK를 전달 후 해당 포트에 연결된 APP에게 close 요청
3. ACK를 받은 Client는 상태를 FIN-WAIT-2로 변경
4. close 요청을 받은 서버 애플리케이션은 종료 프로세스를 진행 후 FIN을 Client로 전송 후 LAST_ACK 상태로 전환
5. FIN을 받은 Client는 ACK를 서버에 전송 후 TIME-WAIT 상태로 전환

`(TIME-WAIT: 먼저 연결을 끊는 쪽에서 생성되는 소켓으로, 혹시 모를 전송 실패에 대비하기 위해 존재하며, TIME-WAIT이 없다면, 패킷의 손실이 발생하거나 통신자 간 연결 해제가 제대로 되지 않을 수 있음)`

TCP에서 사전의 연결이 필요한 이유 연결을 맺는 과정은 논리적인 하나의 회선을 생성하는 과정으로 볼 수 있으며 , 이 회선을 통해 데이터를 순서대로 전달하면 자연스럽게 데이터의 도착 순서가 보장되지만 , 연결을 맺었다고 해서 항상 데이터의 전송 순서가 보장되는 것은 아님 네트워크 환경에 따라 패킷 손실, 지연, 손상 등의 요인이 발생할 수 있으며 , 이러한 문제를 해결하기 위해 TCP는 재전송, 오류 검출, 흐름 제어 등의 기능을 제공

TCP 연결과 TCP 연결 해제의 단계가 차이나는 이유 TCP 연결을 끊을 때는 수신자가 보낼 데이터가 남아 있을 가능성을 고려하기 때문에 , FIN을 보내기 전 ACK를 응답하여 남아있는 데이터 전송

TCP의 신뢰성 보장 네트워크 내에서 다양한 요인에 의해 패킷이 유실되거나 손상될 수 있기에, TCP는 신뢰성 보장을 위해 다양한 방법을 제공
- TCP Flag
  
  송신자와 수신자가 데이터를 주고받을 때 패킷의 순서와 무결성을 유지하는 데 중요한 역할
  - 시퀀스 넘버(Sequence Number)
    - 해당 패킷이 전체 데이터 중 몇 번째인지를 나타냄
    - 수신자는 시퀀스 넘버를 보고 패킷이 순서대로 도착했는지 확인 가능
  - ACK 넘버(Acknowledgment Number)
    - 수신자가 다음에 받을 패킷의 시퀀스 넘버를 송신자에게 알려줌
    - 이를 통해 송신자는 어떤 패킷이 정상적으로 도착했는지 확인 가능
- 패킷이 손상된 경우
  
  수신자는 손상된 패킷의 시퀀스 넘버를 포함한 ACK을 송신자에게 전송
  
  송신자는 ACK을 확인한 후, 손상된 패킷부터 다시 재전송하여 데이터의 무결성을 보장
  
  이미 다음 패킷들이 전송되었더라도, 문제가 생긴 패킷부터 다시 전송하여 올바른 순서로 데이터를 전송
```
송신자가 Seq: 1000, Seq: 2000, Seq: 3000 패킷을 차례로 전송
Seq: 2000 패킷이 손상됨
수신자는 "ACK 2000"을 송신자에게 보냄
송신자는 이미 Seq: 3000까지 보냈더라도, 다시 Seq: 2000부터 재전송
```
- 패킷이 유실된 경우
  
  라우터의 버퍼 오버플로우 또는 네트워크 장애로 인해 완전히 유실되는 경우
  
  패킷이 유실되면 수신자는 ACK을 보낼 수 없는데, 이때 송신자는 일정 시간 동안 ACK를 받지 못하면 타임 아웃 ( timer exception )을 발생 후 해당 패킷부터 다시 재전송
```
송신자가 Seq: 1000, Seq: 2000, Seq: 3000 패킷을 차례로 전송
seq: 2000 패킷이 유실됨
수신자는 Seq: 2000을 받지 못했기 때문에 "ACK 2000"을 보낼 수 없음
송신자는 일정 시간이 지나도 "ACK 2000"을 받지 못하면, Seq: 2000부터 다시 재전송
```
- TCP의 흐름 제어 방법
  
  송신자가 패킷을 보내는 속도보다 수신자의 패킷 처리 속도가 느리면 수신자 측의 받음 패킷
  
  을 저장하는 버퍼 공간의 크기를 초과해 패킷이 유실 될 수 있음
  - Stop and Wait
    
    매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
    
    ( 성능 문제 발생 )
  - Sliding Window
    
    수신자가 정한 Window Size ( 일반적으로 수신자의 버퍼 크기 )만큼 ACK 없이 패킷을
    
    연속으로 전송하는 방식
    
    송신자는 윈도우 크기만큼 패킷을 보내고 ACK을 받으면 윈도우를 이동하여 다음 패킷을 전송
    
    장점: 한 번에 여러 개의 패킷을 전송할 수 있어 데이터 전송 효율이 향상됨
```
Ex (윈도우 크기 = 4)
송신자: 1, 2, 3, 4번 패킷을 전송
수신자: ACK 1을 보냄 → 윈도우 이동 가능!
송신자: 5번 패킷을 추가로 전송
수신자: ACK 2, ACK 3, ACK 4를 보냄 → 윈도우 계속 이동 가능!
송신자: 6, 7, 8번 패킷을 추가로 전송
```
  - Go-Back-N (GBN)
    
    Sliding Window를 기반으로 오류 발생시 특정 방식으로 패킷을 재전송하는 프로토콜
    - 패킷 전송 & ACK 처리
      - 수신자는 받아야 하는 패킷의 시퀀스 넘버를 알고 있으며, 패킷을 정상적으로 받으면 해당 패킷에 대한 ACK을 보냄
      - 만약 순서가 맞지 않는 패킷을 수신하면, 마지막으로 정상적으로 받은 패킷의 시퀀스 넘버에 대한 ACK을 다시 전송
    - 송신자의 동작
      - 송신자는 윈도우 크기 내에서 패킷을 연속 전송하고, ACK을 순차적으로 받으면 문제가 없다고 판단하고 윈도우를 이동
      - 만약 중복된 ACK을 받으면 이를 무시하고, 가장 오래된 패킷이 타임아웃되면 해당 윈도우 내 모든 패킷을 다시 전송
    - 특징
      - 오류가 발생하면 윈도우 내의 모든 패킷을 재전송하므로 Stop & Wait보다 성능이 좋지만, 오버헤드가 존재
  - Selective Repeat ( 선택적 재전송 )
```
Go-Back-N과 다르게 특정 패킷만 재전송하여 불필요한 데이터 전송을 줄이는 방식

1. 송신자 & 수신자 모두 버퍼를 가짐
    - 수신자는 순서가 맞지 않는 패킷도 버퍼에 저장하고, 순서가 맞는 경우 상위 계층으로 전달
    - 송신자는 각 패킷마다 개별 타이머를 관리 ( 오버헤드 발생 가능 )
2. 개별 패킷의 타임아웃 관리
    - 송신자는 모든 패킷에 대한 타이머를 가짐
    - 특정 패킷만 유실되면 해당 패킷만 재전송 ( Go-Back-N보다 효율적 )
3. ACK을 순서대로 받지 않아도 됨
    - 수신자는 순서가 맞는 패킷만 상위 계층으로 전달
    - 순서가 맞지 않는 패킷은 버퍼에 저장하고 기다림
4. 송신자의 동작
    - ACK을 순서대로 받지 못하면 윈도우 이동을 멈추고 대기
    - 타임아웃이 발생한 특정 패킷만 선택적으로 재전송
    - 해당 패킷의 ACK을 받으면 윈도우 이동 후 다음 패킷 전송
5. 윈도우 크기 제한
    - 시퀀스 넘버 크기의 절반보다 윈도우 크기가 크면 문제가 발생할 수 있음
    - 시퀀스 넘버가 겹치는 경우, 패킷 순서를 잘못 해석할 가능성이 생김
    
```
    Sliding Window : 한 번에 여러 개의 패킷을 전송하여 전송 효율을 높이는 방식
    
    Go-Back-N : 오류 발생 시 윈도우 내 모든 패킷을 재전송하는 방식으로, Stop & Wait보다는 성능이 좋지만 불필요한 재전송이 발생할 수 있음
    
    Selective Repeat : 불필요한 패킷 재전송을 방지하지만, 구현이 더 복잡하고 오버헤드가 발생할 수 있는 방식
- TCP의 혼잡 제어 : 안정적인 네트워크 구축을 위해 필요한 기능
  
  네트워크 환경에 따라 패킷 유실 또는 ACK의 지연이 발생하면 송신자는 손실된 패킷을
  
  재전송 하게 되는데 이러한 재전송이 지속되면 네트워크 부하가 증가하여 성능 저하 발생 ..
  
  Go Back N 기법에서는 오류가 발생한 패킷 이후의 모든 패킷을 다시 전송하므로, 혼잡 상황에서는 오버헤드가 커질 수 있음
  
  이를 해결하기 위해 윈도우 크기( 단위 시간당 패킷 전송량 )를 조절하여 혼잡을 제어
  
  즉, 혼잡 제어는 Go Back N의 기본 개념을 활용하여 **네트워크 상태에 따라 패킷 전송량을 조절**함으로써 성능 저하를 방지하고 네트워크의 안정성을 유지하는 역할을
  - AIMD ( Additive Increse/Multicative Decrease )
    
    합 증가 / 곱 감소 방식
    
    초기에 패킷을 하나씩 보내고 문제가 없다면 윈도우의 크기를 1씩 증가시키며 전송
    
    만약 전송에 실패할 경우 윈도우의 크기를 반으로 줄임
    
    윈도우의 크기를 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 시간이 오래 걸림
    
    혼잡이 발생한 후에 대역폭을 줄이는 방식
  - Slow Start
    
    윈도우의 크기를 2배수로 늘려가며 증가시키는 방식
    
    단, 문제 발생 시 윈도우 크기를 1로 초기화
    
    한번 문제가 발생할 경우 혼잡이 발생하는 지점을 예측할 수 있기에 혼잡이 발생한 윈도우 크기에 도달하면 1씩 윈도우 크기를 증가시킴
  - Fast Retransmit
```
TCP에서 패킷이 순서대로 도착하지 않는 경우 , 수신자는 마지막으로 정상적으로 받은 패킷의 다음 순번( 시퀀스 넘버 )을 ACK 패킷에 담아 전송

같은 ACK ( 중복 ACK )가 3개 이상 연속으로 수신되면, 송신자는 해당 패킷이 손실된 것으로 판단하고 즉시 재전송( Fast Retransmit )을 수행

일반적인 재전송은 타임아웃(Timeout)이 발생한 후에 이루어짐 → 전송 속도가 느려짐

하지만 Fast Retransmit을 사용하면 타임아웃을 기다리지 않고 더 빠르게 재전송 가능

즉, 결과적으로 전송 속도를 유지하면서 네트워크 성능을 향상시킬 수 있음

```llvm
    송신자가 1, 2, 3, 4, 5번 패킷을 보냄
    수신자가 1, 2번 정상 수신 , 3번 패킷이 손실됨
    
    4, 5번 패킷이 도착했지만, 3번이 없으므로 정상적으로 처리 불가
    
    수신자는 마지막으로 받은 정상 패킷(2번)의 다음 패킷(3번)을 요청하는 ACK(ACK 3)를 
    반복해서 보냄
    
    송신자는 중복된 ACK 3개(ACK 3, ACK 3, ACK 3)를 받으면, 3번 패킷이 유실된 것으로 판단
    
    타임아웃을 기다리지 않고 3번 패킷을 즉시 재전송
```
```
    만약 타임아웃이 발생하면, TCP는 네트워크가 혼잡한 것으로 판단하고 혼잡 제어를 수행
    
    하지만, Fast Retransmit은 혼잡 때문이 아니라 단순한 패킷 유실로 판단하여, 타임아웃 없이 재전송만 수행
    
    즉, Fast Retransmit은 혼잡 회피보다는 빠른 복구를 위한 메커니즘 이를 통해 네트워크 지연을 줄이고 전송 속도를 유지하는 효과를 얻을 수 있음
- TCP의 혼잡 제어 방식
```
`TCP의 혼잡 제어 방식은 기본적으로 **Slow Start**(지수 증가)와 **AIMD**(선형 증가 & 배수 감소)를 조합하여 윈도우 크기를 조절`

ssthresh( Slow Start Threshold ) : Slow Start와 혼잡 회피의 경계를 결정하는 임계값

즉, 윈도우 크기가 ssthresh보다 작으면 slow start , 크면 혼잡 회피로 동작

```llvm
  초기 상태
  TCP 연결이 시작될 때, 윈도우 크기(cwnd)는 1이고 ssthresh는 초기값( 대체로 큼 )으로 설정
  
  Slow Start(지수 증가) 방식으로 윈도우 크기 증가
  
  1. ssthresh 도달 후 혼잡 회피
  
  윈도우 크기(cwnd)가 ssthresh 이상이 되면 → 증가 속도를 조절하기 위해 혼잡 회피(선형 증가)로 전환
  
  2. 혼잡 발생 시 ssthresh 조정
  
  타임아웃 발생: 네트워크 혼잡으로 판단 → ssthresh = 현재 cwnd의 절반으로 설정, 윈도우 
  크기는 1로 리셋 (TCP Tahoe 방식)
  
  중복 ACK 3개 수신: ssthresh를 절반으로 줄이고, 윈도우 크기를 ssthresh로 설정 (TCP Reno 방식)
```

**TCP Tahoe**

- 혼잡 발생 시(타임아웃 또는 3중 중복 ACK 발생) 윈도우 크기를 1로 초기화하고
    
    , ssthresh를 기존의 절반으로 줄임
    
- 이후 다시 Slow Start(지수 증가)로 윈도우 크기를 증가시키므로 오버헤드가 큼

**TCP Reno**

- 3중 중복 ACK 발생 시 ssthresh를 절반으로 줄이고 현재 윈도우 크기를 ssthresh 값으로 설정한 후 AIMD 방식으로 증가
- 타임아웃 발생 시 ssthresh를 절반으로 줄이고 윈도우 크기를 1로 초기화하여 다시 Slow Start로 증가

`Tahoe는 항상 윈도우 크기를 1로 초기화하지만, Reno는 3중 중복 ACK일 경우 AIMD 방식으로 윈도우 크기를 유지하며 증가`
```
  TCP의 단점
  
  데이터 전송을 위해 신경쓸 것이 많기에 전송속도가 느림

UDP란 ? ( User Datagram Protocol )

빠른 전송 속도를 목표로하는 비연결형 신뢰성 없는 전송 프로토콜

( 실시간 방송이나 온라인 게임 등에서 사용 )

UDP의 특징

비연결형, 신뢰성 없는 전송 프로토콜
수신 여부를 확인하지 않음 ( 3 way handshake 안함 )

checksum 필드를 통해 최소한의 오류만 검출 ( 데이터 전송 중 오류가 발생했는지 확인하기 위한 오류 검출 기법, 오류 수정은 불가 )

[ 송신 측 ]

전송할 데이터의 값을 일정한 규칙(예: 모든 바이트를 더한 값)으로 계산하여 Checksum 값을 생성
데이터와 함께 Checksum 값을 전송

[ 수신 측 ]

받은 데이터로 다시 Checksum 값을 계산한 후, 송신 측이 보낸 Checksum 값과 비교
만약 두 값이 다르면 데이터가 손상되었음을 의미
UDP의 경우 오류가 검출되면 그냥 폐기(재전송 요청 없음)

TCP에 비해 빠른 속도
1 : N , 단방향 통신

TCP보다 용량도 적고 속도도 빠르지만 데이터 전송의 신뢰성이 없고 때문에 데이터가 유실되거나

순서가 바뀔 위험이 존재가 있기에 데이터가 일부 유실되어도 서비스 이용에 큰 문제가 되지 않는

온라인 게임이나 실시간 방송에서 사용

UDP는 TCP 처럼 연결을 하지도 않고, 재전송 제어, 윈도우 제어, 혼잡 제어와 같은 기능이 x

또한 도중에 데이터의 순서가 바뀐다 하더라도 다시 정렬하지 x

그저 데이터를 전달하는 것이 UDP의 목적