3. 전송 계층
Transport Layer
TCP, UDP 두 가지 방식
Multiplexing and Demultiplexing
- Multiplexing: 애플리케이션 계층의 여러 소켓에서 전송되는 데이터를 하나로 모으는 것 (발신)
- Demultiplexing: 하나로 들어오는 데이터를 적절한 소켓으로 분배하는 것 (수신)
UDP: Connectionless transport / TCP: Connection-oriented transport
Segment
transport layer에서 multiplexing을 통해 만들어진 데이터
Segment = Header + Data
- Header: 전송 측의 포트 번호, 목적지 포트 번호 등
- Data: 메시지
Demultiplexing시 포트 번호를 통해 전달해야 할 소켓 결정
일반적으로 헤더 크기 <<< 데이터 크기
UDP
UDP는 신뢰성이 낮은 프로토콜로 TCP보다 단순
- 서버는 하나의 소켓만으로 모든 클라이언트와 자유롭게 통신 가능
- destination IP, destination port로 데이터 전송할 소켓을 구분
destination IP, destination port가 같으면 동일한 소켓으로 전송 - Header - source port 번호, destination port 번호, length, checksum
TCP
UDP보다 높은 신뢰성 보장
- 하나의 클라이언트 소켓에 하나의 서버 소켓 매핑 → 네트워크 자원 소비 큼
- source IP, source port, destination IP, destination port 사용
destination IP, destination port가 같아도 source IP, source port가 다르면 다른 소켓으로 전송
RDT (Reliable Data Transfer)
TCP에서는 RDT 보장, UDP에서는 보장하지 않음
- rdt 1.0 - error, loss 없이 데이터 완벽하게 전송됨
- rdt 2.0 - error 발생
- error detection: checksum 사용
- feedbadk: ACK / NAK
- retransmission
- rdt 2.2 - ACK 대신 sequence number로 판단
- rdt 3.0 - error, loss 발생
error detection + feedbadk + sequence number + timer
Pipeline Protocol
RDT는 신뢰성이 보장되지만 데이터를 하나씩 주고 받기 때문에 효율이 좋지 않음
Pipeline을 이용하면 여러 데이터를 한꺼번에 주고 받을 수 있음
Go-Back-N
- window: 한 번에 보낼 수 있는 패킷의 양
- ACK(n): n번까지 잘 받았다는 feedback
- timeout(n): n번 패킷이 유실되었을 경우, n번 패킷부터 윈도우 내의 모든 패킷을 재전송
문제점: 정상 전송된 패킷이 버려지고 재전송되어 비효율적
Selective Repeat
Go-Back-N의 비효율 개선
receiver가 buffer 역할을 해 들어오는 데이터 순서가 맞지 않더라도 모두 저장해 놓고 있음 → 현재 window에 해당하는 데이터를 모두 받을 때까지 기다림
dilemma: Seqence #(시퀀스 번호)가 무한하지 않음
window size가 N이면 시퀀스 번호는 N*2 정도 필요
TCP
reliable data transfer - pipeline 방식 사용
feedback을 통해 loss를 파악하고 재전송
Flow Control
sender가 receiver의 용량을 고려해서 segment를 전달하는 방식
receiver window(RWND): receiver buffer에 남아있는 빈 공간
RWND를 헤더에 담아서 알려줌 - 오버플로우 발생 x
receiver buffer에 자리가 없으면 sender는 계속해서 작은 데이터를 보내고 feedback을 받으면서 자리가 생기는지 확인
TCP 3-way Handshake
2-way handshake - 보내는 쪽은 데이터가 잘 전송되었는지 확인이 가능하지만 받는 쪽은 확인할 수 없음
TCP SYN - SYNbit = 1
SYN/ACK - 헤더의 SYNbit, ACKbit = 1
ACK - ACKbit = 1
연결 종료 - FINbit = 1
timed wait
클라이언트에서 ack을 보내고 close 했지만 loss가 발생하면 server에서 ack을 받지 못해 계속 기다리게 되기 때문에 약간의 시간을 두고 buffer close
Principles of Congestion Control
TCP에서 segment loss가 일어날 경우 데이터 재전송
- Network-assisted congestion control 라우터에서 현재 네트워크 상황 피드백 - 현실적으로 불가능
- End-end congestion control TCP를 통해 segment를 보냈을 때 반응으로 네트워크 상황 판단
TCP congestion control
congestion control 과정은 3 main phases로 구성됨
- Slow Start: 병목 현상을 막기 위해 0부터 시작해서 빠르게(지수적) 증가
- Additive increase: threshold(임계점)를 만나면(수용량에 가까워지고 있음) 천천히 증가
- Multiplicative decrease: 병목현상이 발생하면 절반으로 줄임
- timeout을 통해 loss를 감지하면 slow start로 돌아감
- duplicated ACK을 통해 Error를 감지하면 절반으로 줄임
MSS(Maximum Segment Size)
window size(buffer)를 1MSS부터 시작해서 증가/감소
TCP Fairness
네트워크를 먼저 사용하고 있던 사람이 처음에는 더 높은 속도를 가질 수 있음
후발주자가 들어오면서 loss가 발생하면 Multiplicative decrease를 통해 모두가 속도를 절반으로 감소시킴 → 계속 반복하며 공평해짐
TCP 각각에게는 공평하지만 사용자 단위로 TCP Connection을 많이 가지고 있는 사용자에게 유리함
