반응형

UDP와 TCP는 둘 다 전송 계층 프로토콜로, 데이터를 네트워크를 통해 보내는 방식을 정의한다.

 

✅  UDP (User Datagram Protocol)

: 신뢰성 없는 비연결형 프로토콜

 

📍특징

  • 비연결성: 연결 설정 없이 데이터를 보냄 
  • 신뢰성 없음: 순서가 바뀌거나, 중간에 데이터가 사라질 수 있음
  • 빠른 속도: 연결 설정 없이 데이터가 전송되고, 헤더가 간단하여 처리 시간이 짧음
  • 낮은 오버헤드: 간단한 프로토콜 구조로, CPU와 메모리 자원 소모가 적음
    • TCP는 20Byte의 헤더 오버헤드를 갖지만, UDP는 8Byte의 오버헤드를 가짐
  • 멀티캐스트 및 브로드캐스트 지원: 여러 수신자에게 데이터를 동시에 전송 가능
  • 혼잡 제어 미지원: 네트워크 상태에 관계없이 데이터를 전송

 

속도가 빠르고, 멀티캐스트 및 브로드캐스트를 지원하기 때문에 실시간 스트리밍 서비스에 적합하다.

하지만, 데이터 전송의 신뢰성이 없다는 단점이 있다.

 

 

📍활용

  • 실시간 스트리밍
  • 온라인 게임
  • 화상 통화
  • DNS 조회

 

✅  TCP (Transmissioin Control Protocol)

: 신뢰성 있는 연결형 프로토콜

 

📍특징

  • 연결형: 데이터를 보내기 전에 연결(3-way handshake) 필요
  • 신뢰성 있음: 데이터가 순서대로, 정확하게 도착하는지 확인
  • 흐름 제어 & 혼잡 제어: 네트워크 상황에 따라 속도 조절 가능
  • 전이중(full-duplex), 점대점(point to point) 방식 사용
    • 전이중: 전송이 양방향으로 동시에 일어날 수 있음
    • 점대점: 각 연결이 정확히 2개의 종단점을 가짐
  • 멀티캐스팅이나 브로드캐스팅을 지원하지 않음 

 

📍3 way handshake

: TCP의 연결 성립 과정 (Connection Establishment)

 

TCP는 논리적인 접속을 성립하기 위해서 3 way handshake를 사용한다.

 

즉, 정확한 전송을 보장하기 위해 서버와 클라이언트가 세션을 수립하는 과정이다.

= 양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장

 

 

SYN(synchronize sequence number) : 연결 요청 플래그
ACK(acknowledgement) : 응답

 

  1. 클라이언트는 서버에 접속을 요청하는 `SYN(M)` 패킷을 보낸다. 클라이언트는 이를 보내고 `SYN/ACK` 응답을 기다리는 `SYN_SENT` 상태가 된다.
  2. 서버는 클라이언트의 요청인 `SYN(M)`를 받고, 클라이언트에게 요청을 수락한다는 `ACK(M+1)`과 `SYN(N)`이 설정된 패킷을 보낸다. 이때 서버는 `SYN_RECEIVED` 상태가 된다.
  3. 클라이언트는 서버의 수락 응답인 `ACK(M+1)`와 `SYN(N)` 패킷을 받고 `ACK(N+1)`를 서버로 보내면 연결이 성립된다. 서버는 `ESTABLISHED` 상태가 된다.

 

 

📍4 way handshake

: TCP의 연결 해제 과정 (Connection Termination)

 

클라이언트와 서버 사이에 세션을 종료하기 위해 수행되는 절차이다.

 

  1. 클라이언트가 연결을 종료하겠다는 `FIN` 플래그를 전송한다
  2. 서버는 클라이언트의 요청인 `FIN`을 받고, 확인 메시지로 `ACK`를 보낸다
    1. 그리고, 데이터를 모두 보낼 때까지 `TIME_OUT` 상태가 된다
  3. 데이터를 모두 보내고 통신이 끝났으면 연결이 종료됐다고 클라이언트에게 `FIN` 플래그를 전송한다
  4. 클라이언트는 확인 메시지 `ACK`를 보낸다. 이를 받은 서버는 소켓 연결을 `close`한다.
    1. 클라이언트는 아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 일정 시간 동안 세션을 남겨 놓고 `TIME_WAIT` 상태에서 잉여 패킷을 기다린다.

 

 

📍SYN Flooding

: TCP 연결 과정에서 발생하는 3-Way Handshake의 취약점을 악용한 대표적인 DoS(Denial of Service) 공격

 

  • 공격자가 접속을 요청하는 다수의 SYN 패킷만 보내고, 의도적으로 서버의 SYN+ACK에 대한 응답은 생략하여 서버의 세션 큐를 가득 채우는 방식
  • 서버는 연결을 확립하려고 SYN+ACK를 보내고 일정 시간 동안 응답을 기다리지만, ACK가 오지 않으면 연결이 완성되지 않음
  • 이로 인해 서버의 연결 대기 큐가 가득 차고 정당한 사용자 요청도 처리하지 못하게 되어 서비스 거부 상태에 빠짐

 

💡 흐름

  1. 공격자는 서버에 대량의 SYN 패킷을 전송
  2. 서버는 각 SYN에 대해 SYN+ACK를 응답하고 메모리에 연결 상태를 저장
  3. 클라이언트가 ACK를 보내지 않으면 연결이 완료되지 않음
  4. 서버의 반쯤 열린 연결(Half-open connection)이 계속 유지되면서, 연결 큐가 가득 차고 정상 사용자는 접속 불가

 

 

💡 방어법

  1. SYN Cookies: 서버가 메모리에 연결 상태를 저장하지 않고도 TCP 연결 요청을 처리할 수 있도록 하는 방법
    1. 서버는 SYN을 받으면 연결 정보를 저장하지 않고, SYN + ACK 패킷의 초기 시퀀스 번호(ISN)에 쿠키 값을 암호화하여 포함시킴
    2. 이 쿠키는 SYN 패킷의 출발지/목적지 IP, 포트 번호, 비밀키 등을 해시하여 생성
    3. 클라이언트가 ACK를 보내면, 서버는 그 안의 시퀀스 번호로 쿠키를 복호화하여 검증
    4. 검증에 성공하면 메모리에 연결 상태를 저장하고 연결을 확립
  2. 방화벽: 특정 IP 또는 포트에 대해 짧은 시간 내에 비정상적으로 많은 SYN 패킷이 도달하면 공격으로 간주
    1. SYN Rate Limiting: 일정 시간 내 SYN 요청 수를 제한
    2. IP 차단: 의심스러운 IP 주소를 일시적으로 블랙리스트 처리

 

 

1️⃣ TCP의 Flow Control(흐름 제어)

: 송신 측과 수신 측의 데이터 처리 속도 차이를 조절해 주는 것

 

 

송신 측의 속도가 수신 측보다 빠를 경우, 수신 측에서 제한된 저장 용량을 초과하여 데이터 손실이 발생할 수 있다.

이를 해결하기 위해 필요한 것이 "흐름 제어"이다.

 

  • 수신자가 처리 가능한 만큼만 데이터를 보내도록 함
  • 수신 측에서 받을 수 있는 윈도 사이즈는 rwnd(receive window)를 이용하여 계산
  • 수신자가 rwnd 값으로 자신이 수용 가능한 버퍼 크기를 송신자에게 알려줌
    • TCP 헤더(윈도 필드)를 통해 송신 호스트에게 이를 알린다
  • 송신자는 rwnd만큼만 데이터를 전송 가능

 

 

📍 예시

  1. 초기 설정
    1. 클라이언트 -> 서버: SYN
    2. 서버 -> 클라이언트: SYN+ACK (rwnd 초기값 = 500)
    3. 클라이언트 -> 서버: ACK
  2. 첫 번째 데이터 전송
    1. 클라이언트가 0~200 byte 전송
    2. 서버는 이를 수신해 rwnd = 300(500-200)으로 ACK를 응답
  3. 두 번째 데이터 전송
    1. 클라이언트가 200~400 byte 전송(+200)
    2. 서버는 100 byte 처리 완료(-100)
    3. rwnd = 200(300-100)으로 ACK 전송
  4. 세 번째 데이터 전송
    1. 클라이언트가 400~500 byte 전송(+100)
    2. 서버가 데이터 모두 처리 완료(-400)
    3.  rwnd = 500으로 ACK 전송

 

 

2️⃣ TCP의 Congestion Control(혼잡 제어)

: 데이터 전송량을 조절하여 네트워크가 혼잡해지지 않게 조절하는 것

 

cwnd(Congestion window size)라는 변수로 전송 가능한 데이터 양을 제한한다.

아래 네 가지 주요 알고리즘을 사용해 cwnd를 동적으로 조절한다.

 

  1. Slow Start: 처음엔 천천히 보내다가 점점 전송량 증가 (cwnd를 지수적으로 증가)
    1. 시작 시 `cwnd = 1 MSS` (MSS = 최대 세그먼트 크기)
    2. 1 ACK마다 `cwnd += 1 MSS`
    3. 즉, RTT마다 cwnd가 2배씩 증가 (지수 증가)
    4. 혼잡이 감지되면 종료되고 Congestion Avoidance로 전환
  2. Congestion Avoidance: 혼잡이 감지되기 전까지 서서히 증가 (선형 증가)
    1. cwnd가 임계값(`ssthresh`)에 도달하면 선형 증가로 전환
    2. 1 RTT마다 `cwnd += 1 MSS`
  3. Fast Retransmit: 타임아웃을 기다리지 않고 중복 ACK 3개만 받아도 손실로 간주하고 즉시 재전송
    1. 기본적으로 TCP는 ACK를 못 받으면 timeout 후에 재전송하는 방식이지만, 타임아웃을 기다리면 너무 느리고 비효율적
    2. 그래서 중복 ACK가 3번 오면 손실 됐다고 판단하고 바로 재전송
  1. Fast Recovery: 혼잡 발생 후에도 Slow Start로 돌아가지 않고, 일정 수준의 cwnd를 유지하며 회복
    1. 중복 ACK 수신 후
      • `ssthresh = cwnd / 2` (임계값 낮춤)
      • `cwnd = ssthresh + 3 MSS`로 조절
    2. 이후 중복 ACK 1개마다 `cwnd += 1 MSS`
    3. 정상적인 ACK 수신 시 Congestion Avoidance로 전환

 

 

3️⃣ TCP의 Error Control(오류 제어) : 재전송

: 패킷 손상이나 손실이 발생해도 데이터가 정확하게 수신되도록 하는 메커니즘

 

패킷 손상이 발생하는 네트워크 / 패킷 손실이 발생하는 네트워크에서 어떻게 신뢰적인 데이터를 전송할 수 있을까?

 

  • 패킷 손상: 송신한 패킷 내부 비트들이 하위 계층에서 손상되는 경우 (체크섬으로 감지)
  • 패킷 손실: 전송한 패킷이 손실되는 경우 or 전송한 패킷에 대한 확인 응답 패킷이 손실되는 경우 (타이머 기반 재전송)

 

 

📍 TCP의 재전송 시나리오

출처: 컴퓨터 네트워크 하향식

 

📍 Lost ACK scenario

  • 세그먼트는 수신 측에 정상적으로 도착
  • ACK가 손실됨
  • timeout 발생
  • 세그먼트 재전송
  • 재전송된 세그먼트를 받은 수신 측은 이미 수신했으므로 그냥 버림

 

 

📍 Premature Timeout (조기 타임아웃 시나리오)

  • 송신자가 세그먼트 전송
  • 수신자는 세그먼트를 올바르게 수신 후, ACK 전송
  • 그런데 네트워크 지연 등으로 인해 ACK가 도착하기 전에 송신자의 타이머가 만료
  • 송신자는 타이머가 만료되었다고 판단하고 재전송 수행

 

 

📍 Cumulative ACK (누적 확인 응답)

  • 수신자는 여러 개의 세그먼트를 연속적으로 수신 후, 각 세그먼트에 대한 ACK 전송
  • 첫 번째 세그먼트에 대한 ACK 손실
  • 하지만 송신자는 두 번째 세그먼트에 대한 ACK는 올바르게 수신
  • 송신자는 첫 번째 세그먼트도 올바르게 전송됨을 알 수 있으므로, 재전송하지 않음

 

TCP의 재전송 기법에는 대표적으로 ARQ(Automatic Repeat reQuest) 계열 프로토콜인 Stop-and-Wait, Go-Back-N, Selective Repeat가 있다.

 

 

📍Stop-And-Wait 프로토콜 

: 송신자가 하나의 패킷을 전송한 후, 그 패킷에 대한 ACK(긍정 응답) 또는 NAK(부정 응답)을 받기 전까지는 다음 패킷을 전송하지 않는 방식

 

🏷️ 특징

  • 수신자 피드백: 수신자는 패킷을 올바르게 받으면 긍정확인 응답(ACK)을, 아니면 부정확인 응답(NAK)을 보냄
    • 순서가 올바르지 않은 패킷을 수신하면, 가장 최근에 올바르게 수신한 패킷에 대한 ACK를 보냄
  • 송신자의 재전송: 비트 오류가 있는 패킷을 수신하면 NAK를 송신자에게 보내고, 송신자는 이를 보고 해당 패킷을 재전송
    • 송신자는 수신자가 패킷을 정확하게 수신했다는 것을 확인받기 전까지 새로운 데이터를 전송하지 않음
    • 수신자가 보낸 ACK 또는 NAK 패킷 또한 손상된 경우도 송신자가 패킷 재전송
  • 순서번호(squence number): 송신자와 수신자는 패킷을 구별하기 위해 패킷에 순서번호를 매김
    • ARQ에서 송신자는 어떤 패킷을 송신하는지 알아야 하고, 수신자는 어떤 패킷을 수신했는지 알아야 함

 

🏷️ 장점

  • 구현이 간단하다.
  • 수신자가 과부하되는 것을 방지할 수 있다.

 

🏷️ 단점

  • 링크 이용률이 낮다.
  • 전송 속도가 느리다.

 

 

📍파이프라인 프로토콜

: 여러 개의 프레임을 연속으로 전송하고, 수신자의 ACK를 나중에 받아 처리하는 방식

 

 

  • Stop-and-Wait의 낮은 링크 이용률을 극복하기 위한 방식
  • 대표 프로토콜: Go-Back-N, Selective Repeat

 

 

 

1️⃣ SR(Selective Repeat)

: 수신자는 순서에 상관없이 도착한 패킷을 버퍼에 저장, 오류 난 패킷만 선택적으로 재전송 요청

 

  • 슬라이딩 윈도 사용
  • 수신자는 순서에 상관없이 도착한 패킷을 버퍼에 저장
  • 오류 난 패킷만 선택적으로 재전송
  • 각 패킷마다 개별 타이머 사용
  • 장점: 가장 효율적인 방식 (오류 있는 것만 재전송)
  • 단점: 구현 복잡도 높음 (수신 버퍼, 개별 ACK 필요)

 

 

2️⃣ GBN(Go-Back-N)

: 송신자는 최대 N개의 패킷을 연속으로 전송, 수신자는 순서가 맞는 패킷만 수용

 

  • 슬라이딩 윈도 사용
  • 수신자는 순서대로 도착한 패킷만 수용
  • 중간에 하나라도 오류 나면 그 이후 모든 패킷을 버리고 재전송 요구
  • 송신 측 타이머 1개만 필요
  • 장점: 구현이 비교적 간단
  • 단점: 패킷 하나 오류 나면 이후 전부 재전송 (비효율)

 

 

✅ TCP의 신뢰적인 데이터 전송 메커니즘

 

오류 제어 데이터 손상 및 손실 감지, 복구
흐름 제어 수신자의 처리 능력에 맞춰 전송 속도 조절
혼잡 제어 네트워크 과부하 방지, 안정적 전송
순서 번호 전송 데이터의 순서 보장, 중복 및 손실 탐지
체크섬 데이터 손상 여부 검증

 

✅ 체크섬(checksum)

: 전송된 패킷 안의 비트 오류를 검출하는 데 사용

 

기본적인 데이터 무결성을 보장하기 위해 체크섬을 사용한다.

체크섬은 전송된 데이터그램이 손상되지 않았는지 확인하는 데 사용된다.

 

데이터 무결성: 데이터가 변경되거나 손상되지 않도록 보장하는 것

 

 

📍계산 과정

[송신자]

  1. 송신하는 데이터그램을 16 비트의 데이터 단위로 나눈다.
  2. 모든 16비트 단위를 1의 보수 덧셈 방식으로 더한다.
  3. 합의 1의 보수를 체크섬으로 생성하고, 데이터그램에 추가하여 전송한다.

 

[수신자]

  1. 수신된 데이터그램 전체(데이터 + 체크섬)를 16비트 단위로 나눈다.
  2. 모든 16비트 단위를 1의 보수 덧셈 방식으로 더한다.
  3. 합의 모든 비트가 1이면, 데이터그램의 무결성이 보장된 성공적 수신을 의미한다. 한 비트라도 0이면, 비트에 오류가 발생한 것이다.

 

1의 보수 덧셈: 오버플로가 생기면 캐리를 다시 더하면서 누적하는 방식

 

 

🚨 한계

체크섬은 기본적인 오류 검출만 제공한다.

 

패킷 손실, 순서 왜곡 같은 문제는 검출할 수 없다.

또한, 각 데이터 단위에서 발생하는 오류의 합이 0이 되는 오류도 검출할 수 없다.

 

✨ 추가 질문

 

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

두 프로토콜 모두 Checksum을 사용한다.

단, TCP에서는 필수적이고 UDP에서는 IPv4일 때 선택적이고 IPv6일 때는 필수적이다.

 

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

정정할 수 없다.
Checksum을 통해 오류의 발생 여부는 검출 가능하지만,  오류가 어디서 어떻게 발생했는지는 확인할 수 없다.

 

[ TCP의 keep-alive와 HTTP의 keep-alive의 차이는 무엇인가요? ]

TCP Keep-Alive는 “연결이 살아 있는지” 확인하는 하부 레벨의 생존 체크이다.
  - 유령세션 구분: 연결된 두 호스트 중 한쪽 호스트 연결이 끊어져있는데도 연결이 된 줄 알고 계속 살아있는 세션 구분
  - 네트워크 비활성화로 인한 연결 해제 방지

HTTP Keep-Alive는 “연결을 재사용할지” 결정하는 애플리케이션 레벨의 성능 최적화이다.

 

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

사용 목적에 따라 선택할 것이다.
신뢰성 있는 데이터 전송이 중요할 때는 TCP를, 빠른 전송이 더 중요할 때는 UDP를 사용하겠다.

 

[ ACK, SYN 같은 정보는 어떻게 전달하는 것일까요? ]

TCP 헤더 안의 Flags 필드(제어 비트)를 통해 1비트 플래그 형태로 전달된다.

Flags (8비트): CWR, ECE, URG, ACK, PSH, RST, SYN, FIN
Flags 필드는 각종 제어 신호를 1비트로 표현한다.

 

[ 2-Way Handshaking를 하지 않는 이유에 대해 설명해 주세요. ]

2 way만으로는 통신 양측의 수신 가능 상태를 알 수 없으므로 신뢰성을 보장할 수 없다.

1. 클라이언트가 SYN 패킷을 서버로 보낸다.
2. 서버는 이에 대한 ACK와 SYN 패킷을 보낸다.

만약 여기서 끝난다면, 서버는 클라이언트가 응답 가능한 상태인지 확실히 알 수 없다.
클라이언트가 SYN + ACK 패킷을 받지 못해도 서버는 연결이 완료된 줄 알고 데이터를 전송하게 될 수 있다.

이처럼 양측 모두의 수신 가능 상태를 확실히 확인하지 못하면 데이터 손실이나 통신 오류가 발생할 수 있으므로
TCP는 이를 방지하기 위해 3-Way Handshaking 절차를 사용한다.

 

[ 두 호스트가 동시에 연결을 시도하면, 연결이 가능한가요? 가능하다면 어떻게 통신 연결을 수행하나요? ]

이 상황은 'Simultaneous Open (동시 열기)'라고 부르며, 이론적으로 연결이 가능하다.

1. A가 B에게 SYN 전송, B도 A에게 SYN 전송 (동시에)
2. A와 B는 상대의 SYN을 받고, 이에 대해 SYN + ACK 응답 전송
3. A와 B는 상대의 SYN + ACK을 받고, ACK 응답을 보내면서 연결이 확립

이 과정을 거치면 결국 정상적인 3-way handshake가 양방향으로 완료된다.

 

[ 3-Way Handshake의 속도 문제 때문에 이동 수를 줄이는 0-RTT 기법을 많이 적용하고 있습니다. 어떤 방식으로 가능한 걸까요? ]

0-RTT(Zero Round Trip Time)는 클라이언트가 과거에 연결한 적 있는 서버와의 재연결 시
3-Way Handshake가 완료되기 전에 데이터를 먼저 전송하는 기술이다.

초기 연결이 아닌 재연결에만 적용되므로 SYN Flooding과 직접 충돌하지는 않는다.

 

[ 패킷이 4-way handshake 목적인지 어떻게 파악할 수 있을까요? ]

TCP 헤더 플래그를 통해 알 수 있다.
FIN 플래그가 설정된 패킷이면 4-way handshake에 포함된 패킷이다.

 

[ 빨리 끊어야 할 경우엔, (즉, 4-way Handshake를 할 여유가 없다면) 어떻게 종료할 수 있을까요? ]

RST(Reset) 패킷을 보내면 된다.
TCP 헤더의 제어비트 중 RST 비트를 1로 설정하여 보내면, 이를 받은 상대방은 즉시 연결을 종료합니다.

 

[ 4-Way Handshake 과정에서 중간에 한쪽 네트워크가 강제로 종료된다면, 반대쪽은 이를 어떻게 인식할 수 있을까요? ]

응답 없이 일정 시간이 지나면 타임아웃이나 TCP keep-alive 등을 통해 연결 종료를 감지한다.

 

반응형

'⚙️ CS > 네트워크' 카테고리의 다른 글

[네트워크] 소켓  (0) 2025.05.14
[네트워크] IP 주소 & 서브넷  (1) 2025.04.10
[네트워크] XSS & CSRF & SQL Injection  (1) 2025.03.28
[네트워크] HTTP 상태유지 기술  (2) 2025.03.28

티스토리툴바