Chapter 3. Transport Layer

Transport 계층의 주 목적은 end system의 process to process 전송 역할을 수행한다. 부가적으로 streaming을 위한 서비스, 신뢰성 기반의 데이터 전달을 위한 flow control 등도 제공한다.

프로세스 사이의 전송을 위해 sender에서는 multiplexing을 수행하고 receiver에서는 demultiplexing을 수행한다.

1. User Datagram Protocol

Process to Process 전송을 위한 multiplexing, demultiplexing만을 제공한다.

 

UDP와 같이 비연결형 네트워크에서는 목적지 IP, Port만으로 소켓을 식별한다. TCP와 같이 소켓에 대해 1:1 통신을 하지 않고 여러 유저가 보낸 데이터를 하나의 소켓에서 받아들이므로 Resource 소모량은 적지만 Application이 모든 데이터를 받아들이므로 프로세스의 과부화 위험이 있다.

 

header의 길이가 8 byte로 매우 작은 크기를 갖는다. 왜냐하면 UDP는 패킷이 손실되거나 순서가 바뀌는 등의 데이터 신뢰를 신경 쓰지 않아 추가적인 header가 필요 없기 때문이다.

데이터의 손실을 중요시 여기지 않기 때문에 Connectionless로 handshaking 과정이 없고 각 segment를 독립적으로 처리한다. 따라서 데이터 처리속도가 빨라 작은 사이즈의 패킷을 전달할 때 유용하다.

Network Congestion이 심한 경우 TCP는 패킷을 버퍼에 담고 대기한다. 하지만 UDP는 Network Congestion을 무시하고 무조건 패킷을 네트워크에 실어서 보내 Steaming이나 telephone에 유용하다.

 

[DNS, DHCP, SNMP, Streaming, Telephone]

2. Transmission Control Protocol

Transport Layer에서 할 수 있는 최소한의 기능 즉 multiplexing, demultiplexing 뿐만아니라 Reliable Transfer를 위한 다양한 기능을 제공한다.

 

연결형 네트워크에서는 통신이 1:1로 이루어진다. 즉, 서로 다른 두 사용자가 서버의 같은 프로세스와 통신하고자 할 때 프로세스가 포크되어 각각 소켓을 열어 1:1 통신을 수행한다.

하지만 여러 Process를 관리하면 OS에서 overhead가 커지므로 한 프로세스에서 threaded server를 이용한다. TCP에서는 socket이 다음 4가지 항목을 필요로 한다.

3. Communication of TCP

Connection of 3 way handshaking

TCP 프로토콜에서 클라이언트와 서버 사이의 정확한 데이터 전송을 위해, 통신 전 connection을 확정짓는 작업이다. 간단하게 비유를 들어 설명하자면 a가 b에게 1. b야 내말 잘 들리니?  b가 a에게 2. 응 잘들려 a야 너도 내말 잘 들리니? 3. 응 잘들려! 과 같은 방법으로 서로 의사소통이 할 환경이 잘 구성 되었는지, 즉 연결이 잘 되었는지 확인하는 과정이다.

 

초기 클라이언트 상태는 CLOSED 상태이고 서버의 열려있는 포트의 상태는 LISTEN 상태이다. 먼저 클라이언트가 서버에게 SYN 신호를 보내면 서버에서는 SYN_RCV 상태로 변경된다. 다시 서버는 클라이언트에게 SYN 에 대한 응답으로 ACK 를 보내는데 이때 클라이언트의 포트도 열어달라는 요청으로 SYN 를 같이 보낸다. ACK 와 SYN 를 받은 클라이언트는 ESTABLISHED 로 변경되고 응답신호로서 ACK 를 서버에게 보낸다. 마지막으로 서버가 ACK 신호를 받으면 ESTABLISHED 상태가 되면서 클라이언트와 서버간 연결이 성공한다.

이후 클라이언트가 서버에게 데이터를 요청하고, 수신한다.

Finishing connection of 4 way handshaking

TCP 프로토콜에서 클라이언트와 서버 사이의 정확한 종료를 위한 작업이다. 어느쪽이든 FIN 신호를 보낼 수 있고 여기서는 클라이언트가 먼저 종료를 요청한다고 가정한다.

 

클라이언트가 종료하겠다는 신호인 FIN 을 서버에 보내고 자신은 FIN_WAIT_1 상태로 변경한다. FIN 을 받은 서버는 ClOSE_WAIT 상태로 변경되고 응답으로 ACK 를 보낸다. ACK 를 받은 클라언트는 다시 FIN_WAIT_2 상태로 변경된다. 이때 서버는 남은 데이터를 모두 전송하고 전송을 다하면 연결을 종료한다는 신호로 FIN 을 클라이언트에 보며 LAST_ACK 상태로 변경된다. FIN 을 받은 클라이언트는 TIME_WAIT 상태로 변경되면서 응답으로 ACK 를 서버에 보내고, 자신은 일정시간이 지난 후 CLOSED 상태로 변경된다. 마지막으로 응답신호를 받은 서버는 CLOSED 상태로 변경되면서 포트를 닫게 된다.

 

서버가 마지막에 FIN 을 보내는 이유는 서버가 아직 클라이언트에 보낼 데이터가 남아있을 경우 때문이다.

클라이언트가 마지막에 FIN 신호를 받고 바로 종료하지 않고 TIME_WAIT 상태로 일정 시간을 기다리는 이유는 서버로 보낸 ACK 신호의오류가 있을 수 있기 때문이다.

TCP Handshake 동작 과정

Window : 데이터를 보내기 전 3 way-handshaking 을 통해 수신측이 데이터를 받을 수 있는 버퍼양과 송신측이 데이터를 보낼 양을 맞추게 되는데 이 데이터 양을 window size라고 한다.

CWND : 송신할 수 있는 패킷의 양으로 Congestion Control에 필요하다.

RWND : 수신할 수 있는 패킷의 양으로 Flow Control에 필요하다. 

4. Reliable Data Transfer [RDT]

메시지 전송 중에 패킷 에러, 손실을 처리하는 프로토콜이다.

 

Acknowledge Number [ACK]

수신측에서 송신측으로 전달하며 패킷이 잘 왔는지 여부를 알려준다. 즉, 가장 최근에 잘 받은 패킷 넘버를 말한다.

Sequence Number [Seq]

송신측에서 수신측으로 전달하며 전송할 데이터의 고유 번호를 알려준다.

 

RDT 1.0

하위 채널을 완전히 신뢰할 수 있는 경우로 통신 중 데이터 변경, 손실이 없는 상황으로 가정한다.

 

RDT 2.0

하위 채널에 비트 오류가 일어날 수 있다. 해결책으로 Checksum을 통해 오류를 검출한다. 이후 오류를 복구하는 기능으로 ACK, NAK가 있고, 오류가 있으면 재전송 하는 메커니즘이다. ACK로 "패킷이 잘 도착했음"을 알려주고, NAK로 "패킷의 오류"를 알려준다.

하지만 ACK, NAK에서도 오류가 발생할 수 있다. 즉, 송신측에서 오류 여부를 모르고 패킷을 재 전송하지 않는다. 또한 송신 측에서 중복 패킷을 전송 할 경우 수신측은 중복 처리한다. 이에 따라 비효율적인 링크 처리가 소요된다.

 

RDT 2.1

각 패킷에 순서번호[SEQ]를 추가한다. 여기서는 방금 전송한 패킷에만 관심이 있어 0과 1로 구성된다. 그러면 수신측에서 수신번호가 같은 패킷[중복 패킷]을 버리게 되므로 중복 수신이 방지된다. 즉, 동일한 Sequence Number의 패킷이 수신되면 중복 패킷으로 인식한다.

 

RDT 2.2

Nak을 보내는 대신, 가장 최근에 잘 받은 패킷의 ACK을 보낸다. 따라서 ACK에는 패킷의 순서번호가 포홤되어야 한다. 또한 Seq의 넘버가 0 또는 1이 아닌 더 많은 수를 가질 수 있어야 한다.

RDT 2.0	RDT 2.1
성공 수신 - ACK 중복 수신 or 수신 실패 - NAK	성공 수신 or 중복 수신 - ACK

 

RDT 3.0

이전까지는 패킷의 에러 처리를 했다. 만약 패킷이 손실되면 어떤 이벤트도 일어나지 않는 단점이 있다. 이를 'Timer'를 이용하여 해결한다. 합리적 시간을 재서 그 시간동안 응답이 오지 않으면 다시 패킷을 전송한다.

5. Flow Control

송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 방법이다. 수신측이 송신측보다 속도가 빠른 것은 문제가 없지만 송신측이 수신측보다 속도가 빠르면 문제가 발생한다. 이 경우 수신측에서 제한된 저장용량[일반적으로 큐]을 초과하여 이후에 도착하는 데이터의 손실이 발생한다.

Stop and Wait

패킷을 하나 보내고 응답이 올때까지 기다리는 방식으로 window size가 1인 pipelining이라고도 한다. 만약 매우 먼 거리에 패킷을 보낼 때, 패킷이 왔다 갔다 하는 RTT가 커져 전송속도가 느려진다.

 

Pipelining

확인 응답을 기다리지 않고 다중 패킷을 전송한다. 추가적인 패킷 처리를 해야하지만 성능이 좋다. 패킷 처리를 하는 방식에 따라 GBN, SR이 존재한다.

1. 각각의 패킷이 서로 다른 SYN을 가져야 하므로 SYN이 증가해야 한다.

2. 수신측의 버퍼는 하나 이상의 패킷을 저장할 수 있어야 한다.

Go Back N [GBN]

파이프라이닝을 이용하여 누적 ACK, 단일 타이머를 사용한다. 만일 3번 패킷까지만 성공적으로 수신 했고, 4번 패킷이 도착 하지 않았다면 수신측은 4번부터 날아오는 패킷들을 모두 버리고 4번 패킷이 날아오길 기다린다. 순서가 낮은 패킷이 손실되면 이후의 모든 프레임을 재전송해야 하는 단점이 있다.

Selective Repeat [SR]

파이프라이닝을 이용하여 개별 ACK, 개별 타이머를 사용한다. 잘못된 순서의 패킷을 받았더라도 버퍼에 저장하고 중간에 수신을 실패한 패킷만 재전송 한다. 이후 패킷을 재정렬하는 cost가 필요하다. 실패한 패킷만 재전송하므로 성능이 좋지만 구조가 복잡하고 재정렬하는 단점이 있다.

6. Congestion Control

인터넷의 혼잡을 피하기 위해 송신자의 전송속도를 줄이는 방법이다. 만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없다. 이 경우 호스트들은 다시 재전송하고 이는 오버헤드로 이어진다. 따라서 송신측의 데이터 전송 속도를 강제로 줄이는것을 말한다.

AIMD [Additive Increase / Multicative Decrease]

패킷을 하나씩 보내고 문제없이 도착하면 window 크기를 1씩 증가시켜가며 전송하는 방법이다. 만약 패킷 전송을 실패하거나 일정 시간을 넘으면 패킷을 보내는 속도를 절반으로 줄인다.

여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형상태로 수렴하는 공평한 방식이다.

하지만 초기에 네트워크의 높은 대역폭을 사용하지 못해 오랜 시간이 걸리고, 네트워크가 혼잡해지는 상황을 미리 감지 못한다.

Slow Start

AIMD는 네트워크 수용량 근처에서 효율적으로 동작하지만, 처음에 전송 속도를 올리는데 오랜시간이 걸리는 단점이 있다. Slow Start는 ACK 패킷마다 window size가 1씩 증가하므로, 한 주기가 지나면 window size가 2배로 증가한다. 즉, 전송 속도는 지수 함수 꼴로 증가한다. 대신에 Congestion이 발생하면 window size를 1로 떨어트린다. 처음에는 네트워크의 수용량을 예상할 수 없지만 한번 혼잡 현상이 발생하면 네트워크 수용량을 어느 정도 예상할 수 있다.

 

Fast Recovery

Slow Start 처럼 window size를 증가시키다가 혼잡상태를 만나면 window size를 1이 아닌 절반으로 감소시킨 후 선형적으로 증가시키는 방법이다.

 

Fast Retransmit

재전송 타이머 값이 종종 상대적으로 길어, 손실된 패킷의 재전송 전에 지연시간이 길어진다. 이 문제를 해결하고자 중복 ACK를 통해 손실된 패킷을 검출한다.

순서대로 잘 도착한 마지막 패킷의 다음 순번을 ACK을 통해 표현하는데, 중간에 패킷 하나가 손실되면 중복된 ACK 패킷을 수신한다. 중복된 ACK을 3번 수신하면 오류로 판단하여 해당 패킷을 재전송 요청한다. 이때 ACK 신호는 아래 사진에서 보듯 이전것과 합쳐진 형태로 보내진다.

UDP / TCP Format