3.1 전송계층 서비스

전송계층 서비스와 프로토콜

전송계층 프로토콜은 서로 다른 프로세스들 사이의 논리적 통신이다.

transport 프로토콜은 종단 시스템에서 수행된다.

전송계층 vs 네트워크 계층

네트워크 계층: 호스트들 사이의 논리적 통신

전송 계층: 프로세스들 사이의 논리적 통신

종단 시스템 내에서 전송계층 프로토콜은 응용 프로세스와 네트워크 경계까지 메시지를 운반하고, 역으로 네트워크 계층에서 응용 프로세스로 메세지들을 운반

중간 라우터들은 전송 계층이 응용 메시지에 추가한 어떤 정보도 인식하지 않음

인터넷 전송 프로토콜에서의 두가지 원리

TCP: Transmission Control Protocol

• 신뢰할 수 있는 순서대로 전달(reliable, in-order delivery)
• 혼잡 제어
• 흐름 제어
• 연결 지향적(connection setup)

UDP: User Datagram Protocol

• 신뢰할 수 없는 질서가 없는 전달(unreliable, unordered delivery)
• no-frills extension of “best-effort” IP (IP 프로토콜에 대한 단순 확장)

지연이나 대역폭에 대한 보장이 없음

3.2 다중화와 역다중화

호스트대 호스트 전달을 프로세스 대 프로세스 전달로 확장

다중화는 여러개의 소켓으로 부터 데이터를 처리하고 전송계층 헤더를 추가한다.

역다중화는 헤더의 정보를 이용해서 올바른 소켓에 세그먼트를 보내는 역할을 한다.

역다중화 과정

호스트는 IP datagram을 전달 받는다.

• 각각의 데이터그램은 소스 IP주소와 목적지 IP 주소를 가지고 있다.
• 각각의 데이터 그램은 하나의 전송계층 세그먼트를 운반한다.
• 각각의 세그먼트는 소스와 목적지의 포트번호를 가지고 있다.

호스트는 세그먼트를 적절한 소켓으로 전달하기 위해 IP주소와 포트번호를 사용한다.

비연결형 역다중화

호스트가 UDP 세그먼트를 수신

• 세그먼트의 목적지 포트 번호를 확인한다.
  • 같은 목적지 포트번호를 가졌지만 다른 소스 IP 주소나 포트번호를 가진 데이터그램은 목적지의 같은 소켓을 향한다.
• UDP 세그먼트를 그 포트번호의 소켓으로 향하게 한다.

연결형 역다중화

TCP 소켓은 4가지 튜플로 정의된다.

• 소스 IP 주소
• 소스 포트 번호
• 목적지 IP 주소
• 목적지 포트 번호

수신자는 세그먼트를 적절한 소켓으로 보내기 위해 4가지 값을 모두 사용한다.

서버 호스트는 수많은 동시의 TCP 소켓을 지원한다.

• 각각의 소켓은 그것들 고유의 4가지 튜플로 정의된다.

웹 서버는 각각의 연결된 고객에게 각각의 소켓을 가지고있다.

• 비지속적인 HTTP는 각각의 request에 대한 다른 소켓을 가지고 있다.

UDP와는 달리 같은 목적지 IP 주소와 포트번호를 가졌더라도 소스 IP주소와 포트번호가 다르면 다른 소켓으로 역다중화된다.

3.3 비연결성 전송: UDP

UDP: User Datagram Protocol

IP의 단순확장

최선의 서비스를 제공 노력

• 손실 발생 가능
• 순서대로 전달되지 않을 수 있음

비연결성

• UDP 송신자와 수신자 사이의 핸드셰이킹이 없음
• 각각의 UDP 세그먼트는 서로 독립적으로 처리되어야함

UDP 사용

• 스트리밍 멀티미디어 앱들에 종종 사용됨
  • loss에 관용적임
  • 속도에 민감함
• DNS
• SNMP

UDP의 신뢰적인 전송

• 응용계층에서 신뢰성을 추가
• 어플리케이션이 신뢰성을 보장

UDP: more

왜 UDP가 존재하는가

• 지연을 유발할 수 있는 연결 설정이 없음
• 간단함: 송신측과 수신측에 연결상태가 없음
• 작은 세그먼트 헤더
• 혼잡 제어가 없음: UDP는 자기가 전송할 수 있는 최고의 속도로 전송함

UDP checksum

goal: 전송된 세그먼트에서 오류를 감지

송신측

• UDP 세그먼트의 내용을 16비트 연속된 정수로 만든다.
• checksum: 세그먼트 내용을 더한 값
• checksum값은 UDP checksum 필드에 추가된다.

수신측

• 수신된 세그먼트의 체크섬 값과 실제로 계산해봤을 때의 체크섬 값이 같은지 확인

→ 같으면 오류 없음. 다르면 오류 발생

checksum 만드는 법

• 16비트 정수 다 더함 → 제일 위쪽에 carry가 발생되는데 그걸 다시 sum값에 더함 → 2의 보수 취함

checksum은 1비트 오류만 검출함 → 2비트 오류는 검출할 수 없음

UDP checksum (cont.)

UDP에서 오류 검사 이유

• 많은 링크 계층 프로토콜이 오류 검사를 제공하지만, 소스와 목적지 사이의 모든 링크들이 오류 검사를 제공한다는 보장이 없음

UDP는 오류 검사를 제공하지만 오류를 회복하기 위한 어떤 일도 하지 않음

• 손상된 세그먼트를 단순히 버리거나, 아니면 경고와 함께 응용에게 넘겨줌

3.4 신뢰성있는 데이터 전송의 원리

응용, 전송, 링크 계층에서 중요함

• 중요한 네트워크 주제중 top 10

신뢰성있는 데이터 전송 프로토콜의 복잡성은 신뢰할 수 없는 채널의 특성에 의존한다.

서비스 추상화를 구현하는 것은 신뢰적인 데이터 전송 프르토콜의 의무

비신뢰적인 채널의 특성이 rdt의 복잡도를 결정

Rdt 1.0

채널은 완벽하게 신뢰가능하다고 가정

• 비트 오류 없음
• 패킷 손실 없음

수신측은 송신측에 어떤 피드백도 제공할 필요가 없음

• 완전히 신뢰적인 채널 상에서 동작하기 때문

Rdt 2.0 : 비트 오류를 가진 채널

패킷에서 비트 오류가 발생하는 채널이라고 가정

어떻게 오류를 회복하는지

• ACKs : 수신측은 명시적으로 송신측에 패킷을 수신했다고 OK를 날림
• NAKs: 수신측은 명시적으로 송신측에 패킷이 오류를 가지고 있다고 알림
• 송신측은 NAK에 따라서 패킷을 재전송

rdt 2.0에서의 새로운 메커니즘(rdt 1.0)을 넘어서

• 오류 검출
• 수신측에서 피드백: 컨트롤 메세지(ACK, NAK) 수신측 → 송신측

송신측이 패킷을 보내면 수신측에서 응답이 올때까지 대기

Rdt 2.0 : 치명적 오류

ACK/NAK가 오류가 발생했을때

재전송 → 중복 문제 발생 → 각 패킷에 연속된 숫자 할당 → 수신측은 중복된 패킷은 버림

Rdt 2.1: 비트 문제 완벽 해결

송신측

• 패킷에 sequence number 추가
• 두가지 sequence (0,1)로 충분
• 수신된 ACK/NAK이 오류가 있는지 확인 해야함
• rdt 1.0의 두배의 상태

수신측

• 수신된 패킷이 중복되었는지 확인
  • 0번을 기다리는지 1번을 기억하는지

Rdt 2.2: a NAK-free protocol

ACK만 사용하는 rdt 2.1과 같은 기능

NAK 대신에 수신자는 정상적으로 수신된 마지막 패킷에 대한 ACK를 전송

• 수신자는 ACK 되어지는 패킷의 sequence number를 반드시 명시적으로 포함

전송측에서 중복된 ACK는 NAK와 같은 역할을 한다. → 전송자는 현재 패킷을 재전송

TCP에서 사용

Rdt 3.0: 오류와 손실이 있는 채널

패킷 손실이 발생할 수 있는 채널이라고 가정

timeout

파이프라인 프로토콜

송신측이 여러개의 ack가 되기전에 패킷을 전송하게함

• sequence number의 범위가 증가되어야함
• 송신측과 수신측에 버퍼링이 걸림

두가지 형태: N부터 반복(go -Back-N), 선택적 반복(selective repeat)

Go-Back_N

sender

• k-bit sequence number in pkt header
• 연이은 응답되지않은 패킷을 허용할 수 있는 window
  • 전송되었지만 아직 확인 응답되지 않음 패킷을 위해 허용할 수 있는 순서번호의 범위 → Ack 전에 전송할 수 있는 패킷
  • 슬라이딩 윈도우 프로토콜
• n번째 Ack를 받으면 그 전의 pkt은 모두 Ack를 받음 → window를 한칸 앞으로
• 가장 오래전에 전송되고 있는 패킷에 대한 타이머
• timeout: n번째 패킷과 더 높은 숫자의 패킷 재전송 (윈도우 안에서)

ACK-only

• 가장 높은 순서의 ACK를 보냄
• 중복된 ACKs 발생
• expectedseqnum만 기억함

순서가 맞지 않는 패킷

• 버림(don’t buffer)
• 가장 높은 번호의 순서대로 패킷 재전송

Selective Repeat

GBN 프로토콜은 stop-and-wait 프로토콜의 채널 이용률 문제를 개선 → 하지만 패킷 하나의 오류로 인해 많은 패킷들이 재전송됨

수신측은 모든 정확하게 수신된 패킷에 대한 개별의 ACK를 보냄

• 상위 계층에 순서대로 전달하기 위해 buffter 패킷이 필요할 수 있음
• ACK가 수신되지 않은 패킷만 재전송함
• ACK가 수신되지않은 패킷만 송신측 타이머

송신측 window

• N 연속적인 번호

순서대로 오지 않으면 버퍼에 저장해놓고 타임 아웃됐을때 다시 패킷이 순서대로 오면 data 추출해서 응용계층으로 보냄

윈도우 크기는 순서번호 공간 크기의 절반보다 작거나 같아야함

3.5 연결 지향형 전송: TCP

점대점(point-to-point)

• 하나의 송신측, 하나의 수신측

신뢰할 수 있는 순서대로의 바이트스트림

파이프라인

• TCP 혼잡과 흐름제어를 위해 윈도우 크기를 결정

송신측과 수신측은 버퍼를 가지고 있음

누적 ACKs

양방향 통신

• MSS: maximum segment size

연결 지향형

• 핸드셰이킹(제어 메시지 교환)
  • 데이터 교환 전에 송신측과 수신측의 상태를 초기 설정

흐름제어 지원

TCP sequence number and ACKs

TCP는 데이터를 구조화되어 있지 않고 순서대로 정렬된 바이트 스트림으로 본다.

Seq.#’s

• 세그먼트 데이터의 첫번째 바이트의 바이트 스트림 넘버

ACKs

• 수신측으로부터의 다음번으로 예상되는 바이트
• 누적된 ACK

TCP Round Trip Time and Timeout

EstimatedRTT = (1 - a) EstimtatedRTT + a sampleRTT

sampleRTT: measured time from segment transmission until ACK receipt

• ignore retransmissions

DevRTT: 얼마나 SampleRTT랑 EstimatedRTT가 차이나는지

• DevRTT = (1-B) DevRTT + B |SampleRTT - EstimatedRTT|

TimeoutInterval = EstimatedRTT + 4*DevRTT

3장 p3-2 slide 12쪽

빠른 재전송

타임 아웃 기간이 종종 상대적으로 길다

• 손실된 패킷의 재전송 전의 긴 딜레이

중복된 ACK를 통해 잃어버린 세그먼트를 확인한다.

• 송신측은 종종 많은 세그먼트를 계속 보낸다
• 세그먼트가 손실되면 많은 중복된 ACK가 있을것이다.

3개의 ACK를 받으면 재전송

TCP 흐름 제어

수신측이 송신측을 제어하여 송신측이 너무 많이, 빨리 전송함으로써 수신측의 버퍼에 오버플로우 하지 않도록 한다.

비어있는 버퍼의 크기를 receive window 필드에 세팅해서 전송 계층에 알려줌

space room in buffer = RcvWindow = RcvBuffer - (LastByteRcvd - LastByteRead)

송신측은 receive window에 따라서 unacked data의 양을 제한함

Connection management

송신측과 수신측 사이의 데이터를 교환 하기전에 handshake를 한다.

• 연결 설정을 동의 (서로가 연결을 원하는지 확인)
• connection parameter들에 대한 동의
  • sequence number, buffer, flow control 정보와 같은 TCP 변수들을 초기화

Three way handshake

• step 1: 클라이언트는 서버에 TCP SYN 세그먼트를 보낸다
  • 세그먼트 헤더의 SYN 플래그 비트를 1로 설정
  • 초기 sequence number를 설정한다
  • 데이터는 없다
• step 2: 서버는 SYN을 받고, SYNACK 세그먼트로 응답한다.
  • 서버는 버퍼를 할당한다
  • 데이터는 없고 헤더의 SYN 플래그 비트를 1로 설정한다.
  • 서버의 초기 sequence number를 설정한다.
• step 3: 클라이언트는 SYNACK를 받고, 데이터를 포함한 ACK segment로 응답한다.
  • 클라이언트는 버퍼를 할당한다
  • SYN 비트는 0으로 설정한다.

closing a connection

• 클라이언트와 서버는 각각 그들의 연결을 종료한다.
  • FIN bit = 1인 TCP 세그먼트를 보낸다.
• ACK를 이용해 수신된 FIN에 응답한다.
  • FIN을 수신하면 ACK는 FIN과 결합될 수 있음
• 동시의 FIN 교환이 처리될 수 있음

3.6 혼잡 제어의 원리

혼잡: 너무 많은 소스들이 너무 많은 데이터를 너무 빠르게 네트워크에 전송해서 발생하는 문제

cost of congestion

• 주어진 수신측의 전송률에 대해 더 많은 일(재전송)을 해야함
• 불필요한 재전송: 링크는 패킷의 여러 복사본을 운반해야함
  • 더 낮은 처리율을 가짐
• (손실 x) 지연된 패킷의 재전송은 람다_in’을 같은 람다 아웃보다 크게 만듬

causes/cost of congestion: insights

• 전송률은 용량을 넘어설 수 없다
• 전송률에 다가갈수록 지연은 높아진다
• 손실/재전송은 효율적인 전송률을 감소시킨다
• 불필요한 복사본은 효율적인 전송률을 감소시킨다.
• 업스트림 전송 용량/버퍼링은 다운스트림의 패킷손실에 따라 낭비된다.

Approaches towards congestion control

종단에서 종단으로의 혼잡 제어

• 네트워크로부터 명시된 피드백이 없다
• 혼잡은 관측된 손실과 지연으로 부터 유추된다
• TCP로부터의 접근

Network-assisted 혼잡 제어

• 라우터는 직접적인 피드백을 혼잡된 라우터를 통해 이동되는 흐름에 을 가진 송신 수신측에 제공한다
• 혼잡의 수준을 알려주거나 명시적인 전송률은 세팅해준다.

3.7 TCP congestion control

종단-종단 control (네트워크의 도움 없음)

송신측은 전송을 제한함

• LastByteSent - LastByteAcked ≤ cwnd
• rate = cwnd/RTT Bytes/sec
• cwnd는 동적이고, 인식된 네트워크 혼잡의 기능을 한다.

어떻게 송신측은 혼잡을 확인할까?

• 손실 이벤트 = 타임아웃 또는 3개의 중복된 acks
• TCP 송신측은 loss event 이후 속도(cwnd)를 줄임

additive increase, multiplicative decrease(AIMD)

손실을 발생하기 전까지 전송률을 선형적으로 증가

• additive increase: cwnd(전송률)을 매 RTT 마다 1MSS씩 증가(손실이 확인되기 전까지)
• multiplicative decrease: 손실이 발생하면 cwnd를 절반으로 줄임
• 단점: 초기 상태일때 1MSS라서 속도가 너무 느리고 대역폭을 1씩 증가시키는 것은 낭비

TCP Slow Start

매 RTT 마다 cwnd크기를 두배

Loss 발생시 cwnd를 절반으로 줄이고 선형적으로 증가

Refinement: inferring loss

손실을 구분

중복된 3개의 ACKs

• cwnd는 절반이됨
• window는 선형적으로 증가

타임아웃 이벤트

• cwnd를 1MSS로 세팅
• 경계선까지 cwnd 두배
• 이후엔 선형적으로 증가

하는 이유: timeout시 3개의 중복된 ACK보다 더 심한거

경계선은 어떻게 구분?

타임아웃 직전의 1/2 값

Tahoe vs Reno

• Taho는 3개의 중복된 ACK가 발생하면 1로 초기화
• Reno는 3개의 중복된 ACK 직전의 1/2값(경계선)으로 초기화

TCP 공정성

공정성 목표

• K개의 TCP 세션이 R대역폭의 같은 링크를 공유하고 있다면 각각은 R/K의 평균 속도를 가져야함