전송 계층

네트워크 통신에서 송신지와 수신자 간의 데이터 전송을 관리하고, 신뢰성과 정확성을 보장하는 역할 수행
TCP/IP 4계층 모델과 OSI 7계층 모델에서 공통적으로 정의되며, 데이터가 손실 없이 정확히 전달되도록 다양한 메커니즘을 제공함

TCP & UDP

TCP (Transmission Control Protocol)

신뢰성 있는 연결, 데이터 순서 보장, 흐름/오류 제어
웹 브라우징(HTTP), 파일 전송 (FTP)

UDP (User Datagram Protocol)

비연결형, 신뢰성 낮음, 빠른 데이터 전송
동영상 스트리밍, 온라인 게임

특징	TCP	UDP
연결 방식	연결 지향적: 3-way handshake	비연결 지향적: 연결 설정 없이 데이터 전송
신뢰성	데이터 손실, 중복, 순서 오류 방지	신뢰성 보장하지 않음
속도	느림(연결 설정, 오류 제어로 인한 오버헤드)	빠름(단순 데이터 전송)
오류 제어	데이터 전송 중 오류 감지 및 복구	오류 제어 없음
순서 보장	데이터 순서 보장 (시퀀스 번호 사용)	보장 X
헤더 크기	20~60바이트 (복잡한 구조)	8바이트 (간단한 구조)
흐름 제어	수신자의 데이터 처리 속도에 맞게 흐름 제어	흐름 제어 없음
사용 사례	신뢰성이 중요한 애플리케이션	속도가 중요한 애플리케이션

TCP 커넥션 생성

3-Way Handshake

TCP 프로토콜에서 송신자와 수신자 간 신뢰성 있는 연결을 설정하기 위한 과정을 말함
데이터 전송 전에 양측이 통신 준비가 되었는지 확인하고, 초기 연결 상태를 설정함으로써 데이터 전송의 신뢰성을 보장함

3-Way Handshake 과정

• SYN (Synchronize)
  송신자(클라이언트)는 연결을 요청하기 위해 수신자(서버)에게 SYN 패킷을 전송
  내용: 클라이언트의 초기 시퀀스 번호

• SYN-ACK (Synchronize-Acknowledge)
  서버는 연결 요청을 받고, 클라이언트의 요청을 승인하는 ACK와 함께 자신의 연결 요청인 SYN을 포함하여 응답
  내용: 클라이언트의 시퀀스 번호에 대한 ACK + 서버의 초기 시퀀스 번호

• ACK (Acknowledge)
  클라이언트는 서버의 응답을 확인한 뒤, 최종적으로 ACK 패킷을 보내 연결이 완료되었음을 알림
  내용: 서버의 시퀀스 번호에 대한 ACK

• 이후 송신자, 수신자 사이에 커넥션 생성

TCP 커넥션 해제

4-Way Handshake

TCP 프로토콜에서 송신자와 수신자 간의 연결을 종료하기 위한 과정
데이터 전송이 완료된 후, 양측이 연결을 종료하기 위해 FIN(종료) 패킷을 교환하며, 네트워크 자원을 해제하고 연결을 정리함

4-Way Handshake 과정

• FIN (Connection Termination Request)
  송신자가 연결 종료를 요청하며 FIN 패킷을 보냄

• ACK(Acknowledge for FIN)
  수신자가 FIN 패킷을 받고 이를 확인했다는 ACK 패킷을 송신자에게 보냄

• FIN (Receiver's Termination Request)
  수신자도 연결 종료를 요청하며 FIN 패킷을 송신자에게 보냄

• ACK (Acknowledge for Receiver's FIN)
  송신자가 수신자의 FIN 패킷을 받고, 종료를 확인하는 ACK 패킷을 수신자에게 보냄

• 이후 연결이 완전히 종료됨

RDT (Reliable Data Transfer)

신뢰성 있는 데이터 전송을 위한 프로토콜을 설명하는 개념적인 모델,
데이터를 송신 측에서 수신 측으로 오류, 손실 없이 순서대로 전달하기 위해 설계

• RDT 1.0
  : 전송되는 모든 데이터가 유실 없고 에러도 없는 이상적인 상황
  데이터 전송 중 오류가 발생하지 않는 완벽한 환경에서 동작
  송신자는 데이터를 전송하고, 수신자는 이를 문제없이 받음
  문제점: 오류 검출, 복구, ACK 등이 필요 없음, 이상적인 환경에만 적용 가능

• RDT 2.0
  : 전송되는 데이터가 유실은 없으나 에러가 생길 수 있음
  에러가 발생할 수 있는 환경에서 동작
  데이터 손상 여부를 감지하기 위해 체크섬과 같은 오류 검출 메커니즘 사용
  수신 측은 데이터를 수신한 후:
  ACK: 데이터가 제대로 수신되었음을 확인
  NAK: 데이터가 손상되었음을 송신 측에 알림 -> 송신 측은 데이터를 재전송
  문제점: ACK/NAK 패킷이 손실되거나 손상되면 문제가 발생할 수 있음

• RDT 2.1
  : 만약 리시버가 보내는 ACK, NAK에 에러가 생긴다면?
  sender가 응답으로 에러 패킷을 받으면 이게 ACK인지 NAK인지 구별 불가능
  그래서 sender는 무조건 보낸 데이터를 재전송함
  문제는 receiver가 새 데이터인지 중복 데이터인지 구별 불가
  구별을 위해 데이터 패킷의 헤더에 시퀀스 번호 추가
  이제 receiver는 시퀀스 번호를 통해 중복 데이터를 감지하고 처리 (시퀀스 넘버 확인후 순서 맞으면 받고 안 맞으면 버림)

• RDT 2.2
  : NAK 없애고 ACK만으로 동작하게
  시퀀스 번호가 추가되니 NAK가 불필요
  MAK를 제거하고, ACK만을 사용하여 신뢰성 보장
  receiver는 에러 데이터의 경우 ACK를 보내되 같은 시퀀스 번호로 전송
  sender는 시퀀스 번호를 보고 다음 데이터를 보낼지 동일 데이터를 다시 보낼지 결정
  즉, 시퀀스 번호만으로 NAK, ACK를 판단

• RDT 3.0
  : 전송되는 데이터가 에러, 유실 둘 다 발생할 수 있음
  데이터 유실이 발생하는 경우를 대비하여 sender는 receiver로부터 일정 시간 응답을 받지 못하면 데이터를 재전송
  그래서 sender는 타이머를 사용하게 됨
  타이머의 시간을 잘 설정하는 것이 중요
  시간이 짧으면 유실이 발생하지 않았는데도 유실로 판단할 수 있고, 길면 유실 발생 시 복구가 느림

GBN, Selective Repeat

GBN (Go-Back-N)

RDT 3.0의 구현 방식 중 하나
sender는 N개의 데이터 패킷(슬라이딩 윈도우)을 동시에 전송할 수 있음
하지만, 수신 측에서 오류가 발생한 패킷 이후의 모든 패킷을 무효화하고 해당 패킷부터 다시 전송함
특징

• 단순함: 손실된 패킷 이후의 모든 데이터를 다시 전송하기 때문에 구현이 간단함
• 낭비: 손실된 하나의 패킷 때문에 이후의 모든 패킷이 다시 전송되므로 네트워크 대역폭 낭비될 수 있음

동작 방식
sender는 N개의 패킷을 전송하고, 각 패킷에 대해 ACK를 기다림
ACK가 도착하지 않으면, 타임아웃 발생 후 해당 패킷부터 다시 전송

Selective Repeat

RDT 3.0의 구현 방식 중 하나
sender는 N개의 데이터 패킷을 동시에 전송할 수 있음
손실되거나 오류가 발생한 패킷만 선택적으로 재전송함

특징

• 효율적: 손실된 패킷만 다시 전송하므로 네트워크 대역폭을 절약
• 복잡함: 각 패킷을 개별적으로 확인하고 저장해야 하므로 구현이 더 복잡

동작 방식
sender는 각 패킷에 대해 개별적으로 ACK를 확인함
손실된 패킷만 재전송하고, receiver는 버퍼를 사용하여 순서가 맞지 않는 패킷을 저장했다가 재조립

TCP의 RDT

TCP는 RDT 3.0 기반의 신뢰성 있는 데이터 전송 프로토콜

• 오류 감지 및 복구
  - 체크섬: 데이터가 손상되었는지 감지
  - ACK: receiver가 데이터를 정상적으로 받았음을 sender에게 알림
  이때 시퀀스 넘버는 해당 넘버 이전 데이터까지 잘 받았으니 이 넘버부터 데이터를 보내라는 의미
  예: ACK = N: N번 이전까지 잘 받았으니 N번부터 보내라
  - 재전송: 오류가 발생한 패킷을 재전송

• 데이터 손실 및 재전송
  - 타이머 기반 재전송
  sender는 일정 시간 내에 ACCK를 받지 못하면 데이터가 손실된 것으로 간주하고 재전송
  - 빠른 재전송 (Fast Retransmit)
  3번 이상의 중복 ACK를 받으면, 타이머를 기다리지 않고 즉시 재전송

• 순서 보장
  - 시퀀스 번호" 패킷이 순서대로 도챡했는지 확인
  (순서가 어긋난 패킷은 receiver 측 버퍼에 저장 후 올바른 순서대로 조립)

TCP의 흐름제어

흐름 제어(Flow Control)
송신자가 수신자의 데이터 처리 속도에 맞춰 데이터 전송 속도를 조절하는 메커니즘
수신자가 데이터를 너무 빠르게 받으면 버퍼가 가득 차고 데이터가 손실될 수 있기 때문에, TCP는 흐름 제어를 통해 데이터 전송을 조절

방법
TCP는 윈도우 크기를 조절하여 흐름 제어를 수행
윈도우 크기는 수신자가 현재 받을 수 있는 데이터 크기를 의미하며, 송신자는 이 크기를 초과하지 않도록 데이터를 보냄

Zero Window 문제
숫니자의 버퍼가 가득 차면 윈도우 크기를 0으로 설정하여 더 이상 데이터를 받을 수 없음을 송신자에게 알림
송신자는 새로운 윈도우 크기를 받을 때까지 데이터 전송을 멈춤
하지만, 만약 이 정보(윈도우 크기 0)가 네트워크에서 손실되면 송신자는 무한 대기에 빠질 수 있음
이를 방지하기 위해 TCP는 주기적으로 "윈도우 크기 확인 패킷"을 전송하여 수신자의 상태를 확인함

TCP의 혼잡 제어

혼잡 제어(Congestion Control)
네트워크의 트래픽 과부하를 방지하기 위해 송신자가 데이터 전송 속도를 조절하는 기법
한 사용자가 너무 많은 데이터를 보내면 다른 사용자에게 불이익이 발생할 수 있으므로 혼잡 제어를 통해 공정하게 네트워크를 사용할 수 있도록 함

혼잡 제어 메커니즘

1. Slow Start
   초기 패킷 전송량을 매우 작게 설정하고 2배씩 늘려가면서 네트워크 상태를 점검

2. Congestion Avoidance
   패킷 전송량이 일정 threshold에 도달하면 증가 속도를 선형 증가로 변경

3. Fast Recovery
   패킷 손실이 발생했을 경우 대처
   - 동일 ACK를 3번 받은 경우(일부 패킷 손실)
   네트워크 과부하 직전으로 판단 => Congestion Avoidance부터 재시작
   threshold는 현재 전송량의 절반 값으로 설정
   - 타이머에 의한 타임 아웃
   네트워크 과부하 상황으로 판단 => Slow Start부터 재시작
   threshold는 현재 전송량의 절반 값으로 설정