TCP와 UDP의 목적과 특징

포트를 통한 프로세스 식별

• 패킷의 최종 송수신 대상은 호스트가 아니라, 호스트가 실행하는 프로세스
• 호스트가 실행하는 프로세스 식별 : 포트 PORT 번호를 통해 식별
• 네트워크 패킷을 주고 받는 프로세스에는 포트 번호가 할당됨
• IP주소와 포트 번호의 조합으로 "특정 호스트가 실행하는 특정 프로세스"를 식별
• 포트를 통한 프로세스 식별은 전송 계층의 주된 목적
• 전송 계층의 핵심 프로토콜인 TCP와 UDP는 모두 포트를 통해 프로세스를 식별할 수 있음
  • TCP와 UDP 헤더에는 송신지 포트와 수신지 포트를 포함하고 있음
• 포트 번호의 종류
  • 잘 알려진 포트 0 ~ 1023
    • 범용적으로 사용되는 프로토콜이 주로 사용하는 포트 번호 목록
    • HTTP 80, HTTPS 443
  • 틍록된 포트 1024 ~ 49151
    • 덜 범용적이지만, 흔하게 사용되는 애플리케이션 프로토콜 할당
    • MYSQL 3306, REDIS 6379
  • 사설 포트 49152 ~ 65535
    • 클라이언트로서 동작하는 프로그램의 경우, 사설 포트 번호가 할당
    • 대표적인 예시 웹 브라우저
• NAT와 NAPT
  • 네트워크 내부에서 사설 IP 주소를 사용하는 호스트가 네트워크 외부에 있는 호스트와 패킷을 주고받기 위해서는 공인 IP 주소와 사설 IP 주소 간 변환이 필요
  • 이 때, 사용되는 기술이 NAT (Network Address Translation)
  • 사설 IP 주소와 공인 IP 주소를 1대1 대응시키지 않고, 다수의 사설 IP 주소를 적은 수의 공인 IP 주소로 변환
  • 어떻게? "포트"를 이용하여!
  • 이처럼 IP 주소 변환 과정에서 IP 주소의 쌍과 더불어 포트 번호도 함께 고려하는 포트 기반의 NAT를 NAPT라고 함
  • NAPT는 사설 IP와 공인 IP 주소를 N:1로 관리할 수 있다는 점에서, 공인 IP 주소의 부족 문제를 개선하는 기술로 간주

(비)신뢰성과 (비)연결형 보장

• TCP는 신뢰할 수 있는 프로토콜이자 연결형 프로토콜이고,
• UDP는 신뢰할 수 없는 프로토콜이자 비연결형 프로토콜
• 신뢰할 수 있는 연결형 송수신에는 시간과 연산이 소요되기에 일반적으로 TCP가 UDP에 비해 송수신 속도가 느림

UDP 헤더의 필드들

• 송신지, 수신지 포트 : 송수신 프로세스가 할당된 포트 번호
• 길이 : 헤더를 포함한 UDP의 바이트 크기
• 체크섬 : 송수신 과정에서의 데이터그램 훼손 여부를 알 수 있는 정보

TCP 헤더의 필드

• 순서 번호, 확인 응답 번호, 제어 비트
• 순서 번호 필드
  • TCP 패킷의 올바른 송수신 순서를 보장하기 위해 매겨진 번호
  • 이를 통해 현재 주고받는 TCP세그먼트(TCP 패킷)가 송수신하고자 하는 데이터의 몇 번째에 해당하는지 알 수 있음
• 확인 응답 번호 필드
  • 상대 호스트가 보낸 세그먼트(패킷)에 대한 응답으로, 다음으로 수신하길 기대하는 순서 번호
  • 올바르게 수신한 순서 번호에 1이 더해진 값
  • 이 때, 상대 호스트에게 "이 세그먼트는 확인 응답 번호를 포함하고 있음"을 알리기 위해 ACK 플래그를 1로 설정해야 함
• 제어 비트
  • "ACK 플래그"는 제어 비트에서 "승인"을 나타내는 비트
  • 확인 응답 번호 값을 보내기 위해선 제어 비트의 "ACK 플래그"가 1로 설정되어 있어야 함
  • "제어 비트"는 현재 세그먼트에 대한 부가정보를 나타내는 정보
  • ACK : 세그먼트의 승인을 나타내기 위한 비트
  • SYN : 연결을 수립하기 위한 비트
  • FIN : 연결을 종료하기 위한 비트

TCP의 연결부터 종료까지

• TCP는 UDP와 달리 송수신 이전에 연결을 수립하고, 송수신 이후에는 연결을 종료

TCP의 연결 수립

• TCP의 연결 수립은 "쓰리 웨이 핸드셰이크"를 통해 이루어짐
• 호스트 A가 호스트 B에게 연결 요청을 보내는 과정

1. [송수신방향 A->B] SYN 세그먼트 전송
   • 호스트 A는 SYN 비트가 1로 설정된 세그먼트를 호스트 B에게 전송
   • 이 때, 세그먼트의 순서 번호에는 호스트 A의 순서 번호가 포함
2. [송수신방향 B->A] SYN + ACK 세그먼트 전송
   • 1에 대한 응답
   • 호스트 B는 ACK비트와 SYN비트가 1로 설정된 세그먼트를 호스트 A에게 전송
   • 세그먼트의 순서 번호에는 호스트 B의 순서 번호와
   • 1에서 보낸 세그먼트에 대한 확인 응답 번호가 포함
3. [송수신방향 A->B] ACK 세그먼트 전송
   • 세그먼트의 순서 번호에는 호스트 A의 순서 번호와
   • 2에서 보낸 세그먼트에 대한 확인 응답 번호가 포함

• SYN 비트는 연결을 수립하기 위한 비트

  • TCP 연결 수립 과정에서 SYN 비트가 설정된 패킷을 처음으로 보내는 호스트가 곧 처음으로 연결 요청을 보내는 호스트

• 호스트 A처럼 처음 연결을 시작하는 과정은 "액티브 오픈"이라고 함

• 호스트 B처럼 연결 요청을 수신한 뒤 그에 대한 연결을 수립하는 과정은 "패시브 오픈"이라고 함

TCP의 오류, 흐름, 혼잡 제어

• TCP는 신뢰성을 보장하기 위해 3가지 기능을 제공

1. 재전송을 통한 오류 제어

• 송수신 과정에서 잘못 전송된 세그먼트가 있을 경우, 이를 재전송하여 오류를 제어
• "언제 잘못 전송된 세그먼트가 있음을 인지할까?"

1. 중복된 ACK 세그먼트를 수신하는 상황
   • 순서 번호 혹은 확인 응답 번호가 중복되는 상황
2. 타임아웃이 발생한 상황
   • TCP 세그먼트를 송신하는 호스트는 모두 "재전송 타이머"라는 값을 유지
   • 호스트는 세그먼트 전송할 때마다 이 재전송 타이머를 실행
   • 이 타이머가 끝난 상황을 "타임아웃" 상황

2. 흐름 제어

• 수신 호스트가 한 번에 받아 처리할 수 있을 만큼만 전송하는 것을 의미
  • 즉, 송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게 맞추는 기능
• 송신 호스트는 수신 호스트가 한 번에 처리할 수 있는 양을 어떻게 알까?
  • TCP 헤더의 "윈도우 필드"
  • 수신 호스트가 한 번에 처리할 수 있는 "수신 윈도우"크기가 명시됨
  • 수신 호스트는 윈도우 필드를 통해 송신 호스트에게 한 번에 처리 가능한 양을 알려주고, 송신 호스트는 이에 맞게 세그먼트를 전송

3. 혼잡 제어

• 혼잡이란 많은 트래픽으로 인해 패킷의 처리 속도가 느려지거나, 유실될 수 있는 상황을 의미
• 송신 호스트가 얼마나 네트워크가 혼잡한지를 판단할 수 있어야 함. 그래야 혼잡의 정도에 따라 세그먼트 전송량을 조절할 것임
• "어떻게 송신 호스트는 네트워크의 혼잡도를 판단할까?"
  • 중복된 ACK 세그먼트가 도착했을 때
  • 타임아웃 상황이 발생했을 때
• 위 2가지 상황이 발생하면 송신 호스트는 "혼잡없이 전송할 수 있는 정도의 양"만큼만 송신
  • "혼잡없이 전송할 수 있는 정도의 양"의 값을 "혼잡 윈도우"라고 함
• 혼잡 윈도우의 경우, 송신 윈도우에서 자체적으로 계산해야 함
  • 혼잡 윈도우의 크기를 연산하는 방법, 혼잡 제어를 수행하는 일련의 과정을 "혼잡 제어 알고리즘"이라고 함
  • 기본적인 혼잡 제어 알고리즘은 "AIMD"
  • 패킷을 보내고 그에 대한 응답이 수신되기까지의 시간을 "RTT"라고 함
  • AIMD는 RTT마다 혼잡 윈도우의 크기를 조정

TCP의 종료

• 송수신 호스트가 각자 한 번씩 FIN과 ACK를 주고받으며 이루어짐
• 호스트 A가 호스트 B에게 처음 연결 종료 요청을 보낸다고 가정

1. [송수신방향 A->B] FIN 세그먼트
2. [송수신방향 B->A] ACK 세그먼트

• 1에 대한 응답

3. [송수신방향 B->A] FIN 세그먼트

• 이번엔 호스트 B가 호스트 A에게 FIN 세그먼트 전송

4. [송수신방향 A->B] ACK 세그먼트

• 3에 대한 응답

• 호스트 A처럼 먼저 연결을 종료하려는 호스트에 의해 수행되는 동작을 "액티브 클로즈"

• 반대로 연결 요청을 받아들이는 호스트에 의해 수행되는 동작을 "패시브 클로즈"

• TCP의 연결 종료 과정은 4개의 단계를 거친다는 점에서 "포 웨이 핸드셰이크"라고 함

TCP의 상태 관리

• TCP의 또 다른 중요한 특징은 상태를 유지한다는 점
  • 상태를 유지하고 관리하는 프로토콜이라는 점에서 "스테이트풀 프로토콜"이라고 부름
  • 여기서 상태란? "현재 어떤 통신 과정에 있는지를 나타내는 정보"
  • 이를 통해 TCP의 송수신 현황을 판단할 수 있고, 디버깅의 힌트로도 활용 가능