Transport Layer
Transport services and protocols
- 다른 호스트에서 동작 중인 어플리케이션 프로세스 간 logical communication을 제공
- Transport protocol은 종단 시스템에서 작동
- send side: app message를 segment로 쪼개어 network layer로 전달
- rcv side: segment를 재조립하여 message로 만들어 app layer로 전달
- 1가지 이상의 transport 프로토콜 사용 가능
Transport vs. network layer
- network layer: logical communication between hosts
- transport layer: logical communication between processes
Internet transport-layer protocols
- 순서가 있는 신뢰성 전달: TCP
- congestion control
- flow control
- connection setup
- 순서가 없는 비신뢰성 전달: UDP
Multiplexing/demultiplexing
- multiplexing at sender:
- 여러 socket으로 부터 온 data를 transport header에 추가(이후 demultiplexing에 이용됨)
- demultiplexing at receiver:
- header 정보를 이용하여 요청에 맞는 socket에 전달 받은 segment 전송
How demultiplexing works
- host가 IP datagram을 전송 받음
- 각각의 datagram은 source IP와 destination IP를 지님
- 각각의 transport segment는 source port와 destination port를 지님
- host는 IP 주소와 Port 번호를 이용하여 적합한 socket에 해당 segment 전송!
UDP(User Datagram Protocol)
- 'best effort' service UDP
- 데이터 유실 있을 수 있음
- 데이터 순서가 섞일 수 있음
-
connectionless: UDP Sender와 Receiver 간 handshaking 하지 않음
- 신뢰성 있는 전송을 위해서는 Application 계층에서 신뢰성을 추가해주어야 함
- 장점
- connection이 필요 없음(Overhead x)
- 간단하게 구성 가능
- header size가 작음
UDP checksum
- Sender
- 1의 보수로 구성된 checksum을 header의 checksum field에 더함
- Receiver
- 전송 받은 segment의 checksum을 연산
- 연산된 checksum이 field 값과 같은지 비교하여 오류 여부 판단
Reliable Data Transfer(RDT)
rdt 1.0: reliable transfer over a reliable channel
- 신뢰성 있는 채널 하에서의 데이터 전송을 가정
- no bit errors
- no loss of packets
- 송신자는 채널을 통해 데이터 전송
- 수신자는 채널을 통해 데이터 수신
rdt 2.0: channel with bit errors
- 비트 에러가 존재할 수 있음을 가정
- 에러를 어떻게 복구할 것인가? 'Stop and Wait'
- ACK: 송신자 -> 수신자. 패킷 잘 받았음!
- NAK: 송신자 -> 수신자. 패킷 못 받았음!
- 그러나 만약, ACK/NAK에 오류가 생긴다면?
- 송신자는 수신자의 상황을 알 수가 없음!
- 중복의 문제로 인해 재전송을 하기도 애매함
rdt 2.1
- 송신자는 ACK/NAK에 오류가 생기면 현재 패킷을 재전송
- 각각의 패킷에 'Sequence Number 부여'
- 수신자는 'Sequence number' 확인하여 중복된 데이터 폐기
- 0과 1의 두 가지 sequnce num이면 충분
- 수신자는 기대한 Sequnce number와 전송 받은 번호를 비교하여 중복 데이터 폐기 가능
- 수신자는 자신이 보낸 ACK/NAK가 송신자에게 제대로 전송되었는지 알 수 없음
rdt 2.2 NAK-free protocol
- ACK에 Sequence number를 추가함으로써 잘못된 데이터를 받은 것을 다시 송신할 수 있게 하는 프로토콜
rdt 3.0 channels with errors and loss
- channel에서 패킷도 유실될 수 있음을 가정
- 송신자가 ACK를 기다리는 '적당한' 시간 간격을 둠
- 이 시간 안에 ACK가 도착하지 않으면 패킷 재전송
- 만약 패킷이 유실된 것이 아니라 단순 지연으로 인해 늦어진 것이었다면
- sequnce number가 중복 데이터 처리
Pipelined protocols
Go-Back-N
- 송신자는 N개 만큼의 unacked packet을 파이프라인 통해 전송
- 수신자는 점증적 ACK만을 보냄
- 송신자는 가장 오래된 unacked packet에 timer 부착
- timer 만료되면, unacked된 모든 패킷을 재전송
Selective Repeat
- 송신자는 N개 만큼의 unacked packet을 파이프라인 통해 전송
- 수신자는 각각의 패킷에 대한 individual ack를 송신자에게 전송
- 송신자는 각각의 unacked packet에 대한 timer 유지
- timer 만료되면, 해당 unacked packet만 재전송
TCP
- 신뢰성 있는, 순서를 보장하는 전송
- Pipelined
- congestion, flow control이 window 크기 결정
- connection-oriented by handshaking
- TCP의 Sequence number와 ACK
- TCP의 timeout 설정 기준
- RTT 보다 길게!
- 너무 짧으면, 불필요한 재전송하게 됨
- 너무 길면, segment loss에 느린 대처하게 됨
TCP retransmission scenarios
TCP fast retransmit
- timeout 시간이 상대적으로 긴 경우가 있을 수 있음
- packet loss 이후에 재전송에 긴 지연이 생김
- 중복된 ACK를 통해 packet loss를 감지 가능
- 만약 송신자가 같은 데이터에 대한 ACK를 3번 받게 되면,
- 가장 작은 번호의 unacked packet부터 재전송
TCP flow control
- 수신자가 송신자를 제어하여, 수신자의 buffer가 overflow되지 않도록 하는 것
- 수신자는 TCP 헤더의 rwnd라는 값에 여유 버퍼 공간을 알려, 송신자가 너무 많은 데이터를 보내지 못하도록 함
Handshake
TCP: closing a connection
혼잡 제어의 원리
- "too many sources sending too much data too fast for network to handle"
- lost packets과 long delay를 초래
- 1번 시나리오
- 2번 시나리오의 이상적 해결안
- Perfect knowledge: 송신자는 router의 buffer에 공간이 있을 때만 패킷 전송
- Known loss: packet loss를 인지했을 때만 데이터 재전송
- 현실적 해결안
- duplicates: 송신자는 패킷의 loss와 drop을 고려하여, 2개의 복사본을 보냄
- 3번 시나리오
혼잡 제어의 2가지 접근법
- 호스트 간의 혼잡 제어
- 네트워크로부터 피드백 존재하지 않음
- 종단 시스템에서 loss와 delay의 발생을 보고 혼잡 발생 추론
- TCP와 같은 접근 취함
- 네트워크 지원 하의 혼잡 제어
- 라우터가 종단 시스템에게 피드백 제공
- 송신자의 송신 속도 제어
TCP congestion control
- 송신자는 전송 속도를 서서히 증가시킴
- loss 발생할 때 까지 증가시키며, 적정 bandwidth를 검증
- additive increase: loss 감지될 때 까지 매 RTT마다 전송 속도 증가
- multiplicative decrease: loss 발생 이후에 전송 속도 반으로 절감
- TCP Reno: loss 발생 이후, 전송 속도를 반으로 줄임
- TCP Tahoe: loss 발생 이후, 전송 속도를 1로 줄임
