전송 계층
네트워크 계층과 응용 계층 사이에 위치
- IP한계 보완: `신뢰`할 수 있는 통신과 `연결`형 통신 기능 제공
- 응용 계층의 프로세스 식별: 포트 번호 활용
IP 한계
- 신뢰할 수 없는 통신
- 패킷이 수신지까지 제대로 전송되었다는 보장X
- 통신 과정에서 패킷이 잘못 전송되어도 확인X, 재전송X, 순서대로 도착 보장X
- 비연결형 통신
- 송수신 호스트 간에 사전 연결 수립 작업X
- 그저 수신지를 향해 패킷을 보내기만 함
∴ IP 패킷의 전달 = 신뢰성이 없는 통신 + 비연결형 통신
IP는 왜 신뢰할 수 없는, 비연결형 통신을 하는가 ?
- 비연결형 통신이 나쁜 게 아님
👉 신뢰할 수 있는 연결형 통신 = `성능`에 악영향 - 신뢰성 있는 전송이 모든 경우에 필요한 게 아님
간단함 | 연결 유지 & 상태 저장X = 라우터가 가볍고 빠르게 작동 |
확장성 | 수십억 기기가 연결되는 환경에서도 유지비용X 동작 가능 |
장애 허용성 | 연결 상태 기억X, 중간 라우터가 꺼져도 우회 가능 |
계층 분리 | 신뢰성 보장은 TCP의 역할로 분리 → 책임 명확 |
📌
`TCP` :신뢰성 & 연결형 통신이 필요한 경우 사용
`UDP` :신뢰성 & 연결형 통신이 필요 없는 경우 사용
TCP (Transmission Control Protocol)
전송 계층에 위치, 신뢰할 수 있는 통신을 위한 연결형 프로토콜
UDP (User Datagram Protocol)
비연결형 프로토콜, 신뢰성 미보장, 최소한의 헤더로 빠른 통신 가능
주요 용도: 실시간 통신, 스트리밍, 게임, DNS
UDP 통신 특성
- 연결 과정 없음
- 핸드셰이크 없이 바로 데이터 전송
- 오버헤드가 작고 빠름
- 신뢰성 보장X
- 순서 보장 X
- 손실/중복 방지X
- 수신 확인, 재전송X
TCP 통신 단계
- 연결 설정
- 클라이언트 → SYN → 서버
- 서버 → SYN+ACK → 클라이언트
- 클라이언트 → ACK → 서버
- 데이터 전송
- 순서 보장 (Sequence Number)
- 수신 확인 (ACK)
- 재전송 (Timout or 중복 ACK)
- 흐름 제어 (Sliding Window)
- 혼잡 제어 (Slow Start, AIMD 등)
- 연결 해제
- FIN → ACK → FIN → ACK
MSS (Maximum Segment Size)
TCP로 한 번에 전송할 수 있는 `데이터 (payload)`의 최대 크기
- TCP 세그먼트에서 IP헤더와 TCP헤더를 제외한 순수 데이터 부분의 최대 크기
- TCP 연결을 설정할 때 협상됨
- MSS 값이 너무 큰 경우, 네트워크에서 IP 패킷이 분할되어 성능이 떨어질 수 있음
❓ MTU (Maximum Transmission Unit)
IP 계층에서 전송 가능한 전체 패킷의 최대 크기
= IP헤더 + TCP 헤더 + 페이로드
일반적인 이더넷 MTU =1500Byte
∴ 일반적인 MSS = 1500 - 20(IP 헤더) - 20(TCP 헤더) = 1460Byte
3 Way Handshake
TCP 프로토콜로 통신하기 위해 데이터 전송 전 상호 연결을 수립하는 과정
상대방과 논리적 세션을 맺는 `시작점`으로 해당 과정을 거친 후, 데이터들을 정상적으로 송수신
UDP는 이 과정이 없으므로 신뢰성이 없는 계층이라고 함
즉, 데이터를 전송할 준비가 되었음을 보장 & 데이터 전송 준비 확인 과정
3-Way handshake 과정에서 정상적으로 세션이 맺어지지 않으면 통신 종료
1. Closed
- 아직 연결 시도 전 Cliend, Server의 상태
- TCP 포트가 닫힌 상태
2. Listen
- TCP 포트가 열려 있고, 요청 대기 상태
3. SYN-SENT (Client)
- Client가 Server에게 연결을 요청하는 SYN 패킷 전송
- 자신의 ISN 을 보냄
4. SYN-RECEIVED
서버가 클라이언트의 SYN 패킷을 수신하고, SYN-ACK 응답을 보낸 후, 클라이언트의 최종 ACK를 기다리는 상태
- SYN 패킷을 받은 서버는 요청을 수락하게 되면, SYN+ACK 패킷을 전송하여 응답
- 임의의 ISN 값 전달
- 해당 패킷의 응답이라는 표시로 Client로 부터 받은 `seq(100)+1` 값인 ack 넘버 전달
5. Established (Client)
- 서버로부터 SYN+ACK 응답을 받아 클라이언트는 연결 수립 상태
- 다시 서버에게 ACK로 수립 완료 패킷 전달
- 이전에 보낸 `seq(100)+1` 하여 새로운 seq 넘버 전달
- 해당 패킷의 응답이라는 표시로 서버로 부터 받은 `seq(200)+1` 하여 ack 넘버 전달
5. Established (Server)
- 클라이언트로부터 ACK 패킷을 전달 받아 서버도 연결 수립 상태로 전환
- 서버와 클라이언트가 Established 모드가 된 후 데이터 송수신 이루어짐
❓ 용어 설명
- ISN (Initial Sequence Number)
TCP 연결 시작 (초기 네트워크 연결) 시 각 호스트가 임의로 생성하는 32bit 고유 시퀀스 번호
- SYN (SYNchronization): 연결 요청 플래그
- ACK (ACKnowledgement): 응답 플래그
4 Way Handshake
TCP는 양방향 통신이 가능하므로, 연결 종료도 양쪽이 각각 종료 의사를 명시해야 함
이를 위해 총 4단계 (FIN/ACK/FIX/ACK)의 통신과정을 거쳐 연결 종료
이 과정에서 각각의 방향에 대해 반이중식 종료(Half-close) 가능
1. 초기 상태: Established
연결이 완료 되어 데이터 송수신 중
2. FIN_WAIT-1 (클라이언트 종료 요청)
- 클라이언트가 데이터 전송을 끝내고 종료 의사를 보냄 (FIN)
- 클라이언트는 `FIN_WAIT-1` 상태 진입
3. 서버: CLOSE_WAIT, 클라이언트: FIN_WAIT-2
- 서버가 FIN을 수신하고 ACK 전송
- 클라이언트는 `FIN_WAIT-2` 상태 진입
- 서버는 `CLOSE_WAIT` 상태 (아직 데이터를 보낼 수 있음)
4. LAST_ACK (서버 종료 요청)
- 서버도 전송을 마치고 종료 요청 (FIN)
- 서버는 `LAST_ACK` 상태 진입
5. 클라이언트: TIME_WAIT & 서버: CLOSED
- 클라이언트가 FIN을 확인하고 ACK 응답
- 클라이언트는 `TIME_WAIT` 상태, 일정 시간 후 CLOSED
- 서버는 CLOSED 상태 진입
TIME_WAIT을 하는 이유?
TIME WAIT ?
소켓이 바로 소멸되지 않고 일정 시간 유지되는 상태를 말하며, 지연 패킷 등의 문제점을 해결하는 데 사용
우분투는 60초, 윈도우는 4분으로 설정 👉 OS 마다 다름
1) 지연 패킷이 발생할 경우 대비
패킷이 뒤늦게 도달하고, 이를 처리하지 않으면 `데이터 무결성` 문제 발생
ex) 전체 데이터가 100일때, 일부인 50만 들어오는 현상
2) 두 장치가 연결이 닫혔는지 확인하기 위함
`LAST_ACK` 상태에서 닫히게 된 경우,
다시 새로운 연결을 하려고 할 때 장치는 줄곧 LAST_ACK 상태이므로 접속 오류 발생
TCP의 기능
재전송을 기반으로 다양한 오류를 제어
흐름 제어를 통해 처리할 수 있을 만큼의 데이터 송수신
혼잡 제어를 통해 네트워크가 혼잡한 정도에 따라 전송량 조절
TCP 세그먼트 헤더 (UDP 데이터그램 헤더) 에는 `checksum`이라는 오류 검출 필드 존재
하지만, checksum 필드만으로는 충분한 오류 검출하기 어려움
∵ 데이터가 훼손 되었는지 여부만 알리기 때문에 자체가 유실된 경우에는 검출이 어려움
TCP 오류 검출과 재전송
TCP가 신뢰성을 제대로 보장하려면?
- 송신 호스트가 송신한 세그먼트에 문제가 발생했음을 인지해야 함
- 오류를 감지하면 해당 세그먼트를 재전송 해야함
TCP는 언제 오류를 검출하고 재전송 하는가?
- 중복된 ACK 세그먼트를 수신한 경우
- 타임 아웃이 발생한 경우
1) 중복된 ACK 세그먼트를 수신한 경우
호스트 B 입장에서는 n+1을 받지 못했으므로, 다시 n+1번의 ACK 세그먼트 수신
→ 호스트 A는 중복된 ACK 수신으로 n+1번의 세그먼트가 손실됐음을 확인
2) 타임아웃이 발생한 경우
호스트가 세그먼트를 전송할 때마다 `재전송 타이머`(retransmission timer) 시작
타임아웃이 발생할 때까지 ACK 세그먼트를 받지 못하면 재전송
📌 빠른 재전송 (fast retransmit)
재전송 타이머가 만료되기 전에 세 번의 동일한 ACK 세그먼트를 받으면 곧바로 재전송
= 타이머가 끝날 때까지 기다리는 시간 절약
오늘 날 TCP에선 대부분 활성화 돼있음
ARQ (Automatic Repeat Request, 자동 재전송 요구)
수신 호스트의 답변 (ACK) & 타임아웃을 토대로 문제를 진단하고,
문제가 생긴 메시지를 재전송함으로써 신뢰성을 확보하는 방식
ARQ는 전송 계층 이외에도 여러 계층과 프로토콜에서 사용하지만,
대표적인 계층이자 프로토콜은 전송계층의 TCP임
ARQ의 대표적 방식
- Stop-and-Wait ARQ
- Go-Back-N ARQ
- Selective Repeat ARQ
1) Stop-and-Wait ARQ
제대로 전달했음을 확인하기 전까지 새로운 메시지를 보내지 않는 방식
- 장점: 단순 & 높은 신뢰성 보장
- 단점: 네트워크 이용 효율 ↓ , 성능 저하
송신 호스트 (A): 확인 응답을 받기 전에는 더 보내고 싶어도 못 보냄
수신 호스트 (B): 더 많은 데이터를 처리할 수 있어도 하나씩만 확인 응답
문제 해결 방법
각 세그먼트에 대한 ACK 세그먼트가 도착하기 전이더라도 여러 세그먼트를 보낼 수 있어야 함
👉 `파이프라이닝(pipelining)`: 연속해서 메시지를 전송할 수 있는 기술
오늘날 실 TCP 환경의 전송 기법은 파이프라이닝 기법임
2) Go-Back-N ARQ
파이프라이닝 기반 ARQ 일종
여러 세그먼트 전송 중 오류가 발생하면 해당 세그먼트부터 전부 재전송
순서 번호 N번에 대한 ACK 세그먼트는 N번만의 확인 응답이 아닌 `n번까지의 누적 확인 응답`
∴ 누적 확인 응답 (Cumulatice Acknowledgement) 라고 불림
3) Selective Repeat ARQ
- 선택적 재전송, 각각의 패킷들에 대해 ACK 세그먼트를 보내는 방식
- Selective Repeat ARQ의 ACK 세그먼트는 개별 확인 응답(Selective Acknowledgement)임.
- 오늘날 대부분 호스트는 Selective Repeat ARQ 지원. (그렇지 않으면 Go-Back-N 으로 동작)