Transport Layer

Transport Layer?

서로 다른 호스트에서 동작하는 프로세스 간의 논리적 의사소통을 제공한다.

transport 프로토콜들은 말단에서 작동한다.

• 송신 측에서는 앱 메세지를 세그먼트로 나누어 network 레이어로 보낸다.
• 수신 측에서는 세그먼트들을 메세지로 합쳐 어플리케이션 레이어로 보낸다.

network layer : 호스트들 간의 논리적 연결

tranport layer : 프로세스들 간의 논리적 연결

Multiplexing & Demultiplexing

Multiplexing at sender

여러개의 소켓들 부터의 데이터를 처리하고, transport 헤더를 추가한다. 이는 후에 demultiplexing을 위해 쓰인다.

Demultiplexing at receiver

받은 세그먼트들을 헤더 정보를 통해 올바른 소켓에 보낸다.

보낼 때는 데이터를 합쳐서 보내고 (multiplexing), 받을 때는 데이터를 나누어 알맞는 곳에 보낸다. (demultiplexing)

이것은 port 번호를 통해 가능하다. port 번호가 같은 프로세스끼리 연결해준다. (src port#, dest port#)

Connectionless Transport : UDP

필수적인 기능만 수행하는 Internet Transport Protocol

최선을 다하는 서비스이다. UDP 세그먼트는 잃어버릴 수 있고, 순서 없이 전송될 수 있다.

비연결형이다.

• UDP 송수신측 간의 handshaking이 없다.
• 각 UDP 세그먼트는 독립적으로 처리된다.

연결이 성립되지 않는다.

간단하다 : 송수신측에 연결 상태가 없다.

세그먼트 헤더가 작다.

UDP를 사용한 신뢰성 있는 전송

• 어플리케이션 층에 신뢰성을 구현하다.
• 어플리케이션이 오류 회복을 해야한다.

혼잡제어가 없다. : DUP는 필요한 만큼 빠르게 연속적으로 보낸다.

• 스트리밍 멀티미디어 (손실을 용납하고, 수신률이 중요한 서비스)
• DNS, SNMP

UDP checksum

목적 : 전송된 세그먼트에 있는 오류를 발견한다. (뒤바뀐 비트들)

송신자

세그먼트 내용물을 16비트 정수의 연속으로 취급하고 더한다 (1's의 보수 합)

수신자는 체크섬 값을 UDP 체크섬 필드에 넣는다.

수신자

받은 세그먼트의 체크섬을 확인한다.

체크섬 필드의 값과 연산한 체크섬이 같다면 에러가 없고, 같지 않다면 에러가 있다고 판정

연산방법

일단 더한다

wraparound를 끝으로 보내 다시 더해 sum을 만든다.

sum의 1의 보수가 체크섬이다.

Reliable Data Transfer

Stop And Wait

rdt1.0

오류없는 채널에서의 신뢰성 있는 연결

rdt 2.0

수신측에서 체크섬으로 bit 에러를 확인

에러가 있다면 NAK, 없다면 ACK 송신측으로 보냄

송신측에서 NAK를 받으면 이전 패킷을 다시 보낸다.

송신측에서 ACK를 받으면 다음 패킷을 보낸다.

패킷을 하나씩 하나씩 주고 받는다. (Stop and Wait)

rdt 2.1

NAK 또는 ACK에 문제가 있을 수 있다면?

특히 ACK가 문제가 생겨 NAK로 인식한다면 송신측에서 중복되는 패킷을 보내게 된다.

이를 위해 패킷이 이전의 패킷인지, 아닌지 알아야 한다.

이를 위한 Seq#이 필요

이를 한 비트로 표현할 수 있는데 그냥 이전의 패킷인지 아닌지만 알면 되기 때문, 제대로 보낸다면 0,1,0,1,0,1 ... 이런식으로 seq#를 송신하게 된다.

수신측은 이 seq#를 보고 중복되는 패킷은 그냥 버리고 ACK를 보낸다.

rdt 2.2

NAK, ACK를 ACK 0, ACK 1로 바꿈

rdt 3.0

채널이 패킷을 아예 잃어버릴 수 있다.

이 때문에 수신측에서 ACK를 기다리는 timer를 추가하여 응답대기시간을 초과하면 (timeout) 패킷을 다시 보내게 된다.

Pipelined protocols

송신측이 수신측의 ACK를 기다리지 않고 연속적으로 세그먼트 패킷을 보낸다.

이 때문에 동일한 시간에 Stop and Wait 방식보다 더 많은 패킷을 송신할 수 있다.

Go-Back-N과 Selective Repeat 프로토콜이 있다.

Go-Back-N

송신자는 파이프라인에 N개의 ack되지 않은 패킷을 보낼 수 있다. N사이즈의 윈도우 안의 처리해야할 패킷을 보낸다.

수신자는 연속적인 ack 만을 보낸다. 즉 중간에 비는 패킷이 있다면 그 다음 패킷은 받지 않는다.

송신자는 ack되지 않은 가장 오래된 패킷에 대한 타이머가 있고, timeout이 일어나면 오래된 패킷부터 다시 전송한다.

Selectvie Repeat

송신자는 N개의 ack되지 않은 패킷을 보낸다.

수신자는 각각의 패킷에 대해 ack를 보내지 않는다. 즉 ack는 연속적일 필요가 없다.

송신자는 unack된 패킷에 대한 타이머를 유지하고, timeout이 일어나면 unacked된 패킷을 다시 송신한다.

SR dillema

SR은 패킷번호의 범위가 유한할 때 문제가 생긴다.

(b) 상황에서 수신측은 두 번째 0 패킷이 필요하지만, 송신측은 첫 번째 0 패킷을 보내고 수신측은 이를 구분하지 못하고 받아들인다.
이는 해결하기 위해서는 윈도우 사이즈가 패킷 숫자 범위의 반 이하의 사이즈여야 한다.

Connection-Oriented Transport : TCP

TCP?

• point-to-point : 송신자에서 수신자로
• 신뢰성있고, 바이트 스트림을 전송하는데 패킷 간의 순서가 있다. 메세지에 국한되지 않는다.
• 파이프라인으로 패킷을 송신한다 : TCP 혼잡 및 흐름 제어가 윈도우 사이즈를 결정한다.
• 송신, 수신 버퍼가 있따.
• 전이중 통신 방식 (full duplex data) : 같은 연결에서 양방향 통신이 가능하다.
• 연결 지향 (connection-oriented) : 데이터 교환 이전에 핸드쉐이킹을 통하여 송,수신 측간의 연결을 수립한다.
• 흐름이 제어된다 : 송신 측은 수신측이 감당할 수 있는 양을 초과해서 패킷을 보내지 않는다.

TCP seq# 와 ACK

• Seq# : 세그먼트 데이터에 있는 첫 번째 바이트의 바이트 스트림 번호
• ACK : 수신 측에서 예측하는 다음 seq#, 연속적인 ACK이어야 한다.

Reliable Data Transfer

TCP는 Internet 프로토콜의 신뢰성 없는 서비스 상에서 아래의 방식들을 통해 신뢰성 있는 데이터 통신을 만들어 낸다.

• 파이프라인된 세그먼트들
• 연속적인 acks
• TCP는 하나의 재송신 타이머를 씀

재송신은 아래와 같은 이벤트에 의해 실행된다.

• timeout
• duplicate acks

TCP Sender Events

앱으로부터 데이터를 받으면 seq#와 세그먼트를 생성하고 전송한다.

타이머가 돌아가지 않는 중이라면 타이머를 실행한다.

타이머는 가장 오래된 unacked packet을 위한 것이다.

타임아웃이 일어나면 타임아웃을 일으킨 세그먼트를 다시 전송하고 타이머를 다시 시작한다.

ack를 수신받으면 ack를 업데이트 한다. 아직 unacked packet이 있다면 그 패킷에 대한 타이머를 시작한다.

TCP Fast Restransmit

타임아웃의 기간은 보통 상대적으로 길어 오래 기다려야 하는 경우가 많다.

효율성을 위해 중복되는 Acks를 사용하여 잃어버린 패킷을 찾아낼 수 있다.

송신자는 보통 연달아 많은 세그먼트를 보내는데 이때 잃어버린 패킷이 있다면 수신자는 잃어버린 패킷에 대한 ACK를 연달아 보내게 된다.

위 사례의 경우 seq#100 패킷을 잃어버리면 수신자측에서는 이후의 ACK에서 100번 ACK를 계속해서 보내게 된다.

임계점에 도달하면 송신자는 100번 패킷을 다시 보내게 된다.

TCP Flow Control

TCP는 TCP 소켓의 receiver 버퍼에 들어온 데이터를 담고 어플리케이션이 이 버퍼에서 데이터를 가져가게 된다.

flow control은 receiver가 sender를 통제하여 sender가 너무 많은 정보를 너무 빠르게 보내 buffer가 넘치게 하지 않는 것을 말한다.

이는 speed-matching 서비스이다.

수신자의 버퍼는 이미 버퍼링된 정보가 점유한 공간과 아직 점유되지 않은 공간으로 나눠볼 수 잇다. 수신자는 수신자에서 송신자로 보내는 세그먼트의 TCP 헤더에 이 점유되지 않은 공간의 크기를 실어서 보낼 수 있다.

송신자는 이 공간의 크기에 맞추어 데이터를 실어서 보낸다. 이는 수신자의 버퍼가 오버플로우가 나지 않도록 보장해준다.

Connection Management

데이터를 교환하기 전에, 송신자와 수신자는 "handshake", 즉 연결을 수립한다.

2-way handshake가 안되는 이유

먼저 클라이언트가 연결 시도를 다시하는 경우이다. 서버는 이미 연결을 수립하고 데이터를 송신하고 연결을 끊어버렸지만, 클라이언트는 연결을 재수립하여 자신이 현재 기대하는 패킷번호를 가진 패킷을 받지 못하고 연결이 끊어진다.

다음은 클라이언트가 재연결시도를 하고 데이터를 재송신하는 경우이다. 이 경우에도 각각 자신이 기대하는 패킷번호가 아니기 때문에 온 모든 패킷을 버리게 된다.

2-way handshake가 안되는 이유는 한측의 연결만 성립되어서이다.

TCP에서 송신자가 seq로 임의의 시작번호를 보내고 수신측이 잘 받았다면 수신측은 ack로 다음에 받아야 할 seq번호를 보낸다. 즉 seq와 ack의 한 쌍이 각각 목적지에 잘 수신된 것이 확인되면 연결이 성립하는 것이다. 송신측과 수신측의 한 연결이 성립되는 과정이 2-handshake라고 보면 된다.

근데, TCP는 양방향 연결 통신 프로토콜이다. 그렇다면 TCP는 2-way handshake를 초과하는 handshake를 해야 양방향 연결을 할 수 있다.

따라서, 2-handshake는 TCP에 맞지 않는 통신 기법이다.

3-way handshake

Open Connection

클라이언트가 seq#x를 고르고 TCP SYN 메세지를 보낸다.

서버는 seq#y를 고르고, TCP SYNACK 메세지를 보내고, SYN을 ACKNUM x+1하여 ack한다. client에서 server로의 연결이 성립된다.

클라이언트는 synack(x)즉, 자신으로부터 서버의 연결이 수립되었다는 메세지를 받았다. SYNACK에 대한 ACK를 ACKNUM y+1하여 보낸다.

서버는 클라이언트로부터 ACK(y)를 받아 서버로부터 클라이언트로의 연결이 수립되었음을 알게된다. server에서 client로의 연결이 성립된다.

Closing Connection (4-Way Handshake)

클라이언트가 seq#x로 연결 종료 요청을 서버로 보낸다.

서버는 ACKNUM#x+1로 수신확인을 알리고 클라이언트는 서버로부터 서버종료 요청을 기다린다.

서버는 seq#y로 연결 종료 요청을 클라이언트로 보낸다.

클라이언트는 서버로 ACKnum#y+1을 보내고 서버는 메세지 수신후 연결을 닫는다. 이후 클라이언트도 연결을 닫는다.

이렇게 서로의 연결를 끝내는 이유는 통신이 연결됬는지 끊어졌는지 모르는 상황을 방지 하기 위해서 이다.

예를 들어, 송신측에서 FIN을 날리고 연결을 끊었는데 이 패킷이 유실되면 수신 측은 계속해서 송신측을 기다려야 하는 상황이 된다. 결국 송신측이 연결이 의도해서 끊어졌는지 아닌지를 모르는 상황이 되기에 신뢰성 있는 연결이라고 할 수 없다. 이 때문에 4-way handshake를 수행하게 된다.

Principles of Congestion Control

"혼잡"은 너무 많은 송신자가 네트워크가 처리할 수 없을 정도로 너무 많은 데이터를 너무 빨리 보내는 것을 말한다.

이로 인해 라우터의 버퍼에 오버플로우가 발생해 패킷로스가 일어날 수 있고, 라우터 버퍼에서 너무 많이 대기해 '긴 딜레이'가 일어날 수 있다.

혼잡제어를 위한 접근 방법에는 end-end congestion control과 network-assisted congestion control이 있다.

end-end 혼잡제어는 말단 시스템에서 패킷 손실과 딜레이를 관리하는 것이다. TCP가 이 방식을 사용한다.

network-assisted congestion control은 라우터가 말단 시스템에 피드백을 제공하는 것이다. 라우터가 송신자에게 명시적으로 송신률을 알린다.

TCP Congestion Control

TCP 혼잡제어는 additive increase, multiplicative decrease한 특성을 가진다.

유효한 대폭역을 찾기 위해 손실이 발생할 때까지 송신률 (window size)을 늘린다.

• additive increase : CongWin을 손실이 감지될 때 까지 1 MSS 씩 늘린다.
• multiplicative decrease : 손실이 일어나면 CongWin를 반으로 줄인다.CongWin은 동적인 값을 가진다.
• 어떻게 송신자는 혼잡을 감지하는가?
• 송신자는 전송을 통제한다.
• loss event : timeout or 3 duplicate acks
• loss event 이후에 송신자는 송신률을 줄인다.Congwin이 Threshold 위라면, 송신자는 congestion-avoidance 단계에 있으며 window는 선형적으로 상승한다.timeout이 일어나면, Threshold는 CongWin/2로 설정되고, CongWin은 1MSS로 설정된다.
• 3-duplicate ACK가 일어나면, Threshold는 Congwin의 반으로 설정되고 CongWin은 Threshold로 설정된다.
• Congwin이 Threshlod 아래이면, 송신자는 slow-start phase에 있으며, window는 지수적으로 상승한다.