컴퓨터 네트워크 9-1일차 : transport layer, UDP, (de)multiplexing, TCP

 

 

컴퓨터 네트워크 8일차 : DNS, P2P 어플리케이션, DASH, CDN

8일차에 이어 바로 9일차 공부 시작합니다 ㅠ

CHAPTER 3 TRANSPORT LAYER 시작이네요~!

 

---

1. transport layer service

 

1-1. logical communication

다른 호스트에서 수행되는 애플리케이션 프로세스 간의 logical communication을 제공합니다.

 

logical communication이란 서로 통신하는 프로세스들이 물리적으로 / 직접적으로 연결이 되어 있지는 않지만,(그 사이의 많은 라우터들이 있지만) 가까히 연결된 것과 같이 만드는 것을 말합니다.

 

즉, 프로세스 관점에서 마치 그들이 물리적으로 연결되 있는 것처럼 느끼게 한다는 것입니다.

마치 텔레컨퍼런스와 같죠. 멀리 떨어져있는 host들끼리 서로 커뮤니케이션 할 수 있도록 도와줍니다.

 

 

1-2. transport vs network layer 1

 

트랜스포트 레이어는 end to end layer 커뮤니케이션을 지원합니다. 또한 네트워크 레이어까지 탑재하고 있는 라우터에서는 구현되지 않습니다. 즉 라우터는 네트워크 레이어까지 역할을 수행하고, 네트워크 레이어에서 처리하는 IP주소를 처리해서 라우팅을 담당하고 있습니다.

 

트랜스포트 레이어는 프로세스 레벨까지 데이터를 전송하기 위해서 프로세스 간의 로지컬 커뮤니케이션을 담당하고 있습니다.

 

 

1-3. transport protocol

트랜스포트 프로토콜은 end system에서 작동합니다.

 

1) sender side

애플리케이션 레이어의 애플리케이션 메세지를 세그먼트(트랜스포트 레이어 데이터 단위)로 쪼갭니다. 그 후 세그먼트를 네트워크 레이어로 전달하는 역할을 합니다.

 

2) receiver side

세그먼트를 메세지로 재조합(reassemble)해서 애플리케이션 레이어로 전달합니다.

 

추가로 트랜스포트 레이어를 지원하는 프로토콜은 인터넷에서는 TCP와 UDP가 지원됩니다.

 

 

1-4. transport vs network layer 2

둘다 결국에는 데이터를 전달하는 역할을 합니다. 하지만 역할의 범위는 다릅니다.

 

둘다 물리적으로 떨어져있는 중간에 라우터들이나 스위치들 거쳐있는 end to end path가 존재하고, 멀리 떨어져 있는 host 간에 커뮤니케이션이 잘 되게끔 해주는 역할을 합니다. 

 

1) transport layer

transport layer에선 프로세스들 간의 로지컬 커뮤니케이션을 담당합니다. 애플리케이션으로부터의 메세지를 포트번호를 사용해서 식별이 가능합니다. 그리고 데이터를 전달을 할 때 데이터가 손실이나도 재전송을 해서 데이터가 100% 신뢰적으로 전달할 수 있는 reliability도 제공합니다. (=TCP 프로토콜)

 

2) network layer

network layer에선 host들 간의 로지컬 커뮤니케이션을 담당합니다. 라우터도 IP주소 가지고, 라우팅을 하는 것입니다. 즉, 포트번호는 고려 대상이 아닙니다. 또한 주요한 특징은 best-effort-delivery가 있습니다. 전달하는데 최선을 다한다. 하지만 전달 이외의 데이터의 손실 및 오류에 대한 처리(integrity 무결성)를 네트워크에서 하지 않습니다. 데이터 순서(order)도 고려대상이 아닙니다.

 

 

1-5. transport layer의 중요한 역할

multiplexing과 demultiplexing이 중요한 역할입니다.

여러 프로세스로부터의 데이터를 합쳐서 네트워크 레이어로 보내지고(=multiplexing), 리시버에서는 이 데이터가 포트 번호를 통해 프로세스로 분개하는 역할을 합니다.(=demultiplexing)

 

추가로 트랜스포트 레이어의 2가지 프로토콜로 TCP, UDP가 있습니다.

 

1) TCP

- reliable한 전송

- in-order-delivery : 데이터 순서가 차례대로 잘 전달되도록 관리합니다.

- congestion control : 네트워크 혼잡에 따라 전송속도를 제어합니다.

- flow control  : 리시버 단에 버퍼 사이즈에 맞게 전송 속도를 제어합니다.

- connection setup : 커넥션 기반 프로토콜이기 때문에 항상 커넥션을 셋업하는 절차를 거칩니다.

 

2)UDP

- unreliable 전송 : 데이터 손실이나도 손실난 채로 계속해서 전송됩니다.

- unordered-delivery

- no connection : 커넥션 기반이 아닙니다. 때문에 빠르게 메세지 전달이 가능합니다.

- congestion&flow control x

 

 

2. UDP (User Datagram Protocol)

RFC 국제표준입니다. RFC 768에 자세히 저술되어 있습니다.

UDP는 unreliable / unordered-delivery 이며, 포트넘버를 사용합니다.

그리고 아주 가벼운 에러 체킹 기능을 활용하고 있습니다. 에러 복원 기능을 갖추고 있는 것은 아니고, 에러가 발생했는지 안했는지 확인만 해줍니다.

또한 connectionless로 연결 없이 포트 번호를 통해서 데이터를 보내는 것에 집중하는 프로토콜 입니다. 때문에 sender와 receiver 사이에 handshaking 절차가 없습니다.

 

때문에 TCP는 자신이 상대방에게 데이터를 보낼거라고 예고하고 상대방이 데이터 보내라고 한 다음에 데이터를 보내는 것이고, UDP는 그러한 절차없이 목적지로 데이터를 보내는 방식입니다.

 

각 UDP 세그먼트는 unreliable 즉, independently하게 포트번호를 활용해 전달됩니다. 

 

UDP는 기본적으로 커넥션하는 시간이 필요 없기 때문에 빠르게 데이터를 전송하는 목적을 가지고 있습니다.

대표적인 어플리케이션은 스트리밍 어플리케이션, DNS에서 UDP를 사용합니다. 데이터 손실이 나도 허용할 수 있고, rate에 대해 예민하기 때문입니다.

 

만약 UDP에서 reliable하게 데이터 전송을 하고 싶다면, 이는 어플리케이션 레이어에서 reliability를 구현하게 됩니다. 결국 손실된 데이터를 복원하도록 해서 보완하게 합니다.

 

 

2-1. UDP 포맷

header : 소스 포트, 데스트 포트, 렝스, 체크썸이 들어가 있으며, 소스포트와 데스트 포트가 16bit씩 들어가 있습니다. 

length : payload(실제 데이터) + header 사이즈가 들어가 있습니다. 바이트 단위로 알려줍니다.

checksum : 수신단에서 데이터를 받았을 때 데이터에 에러가 있는지 없는지를 체크하기 위해 알려주는 비트입니다.

 

계속 반복되지만, 왜 UDP를 사용하냐면,

1) 커넥션 기반이 아니어서 빠르기 때문입니다.

2) 구현이 심플하기 때문입니다.

3) 커넥션 상태를 관리하지 않고, 맺지도 않기 때문입니다.

4) 복잡한 congestion control이나 flow control과 같은 네트워크 상황에 따라서 전송 속도를 제어하는 알고리즘도 구현되지 않기 때문입니다.

 

 

2-2. UDP for DNS

 

DNS 쿼리, DNS reply 할 때 UDP를 사용합니다. 그 이유는 DNS 작업은 자주 일어납니다. 매번 호스트네임과 IP주소를 전환시켜주는 작업이 자주 일어나요. 이 작업 시간을 최소화해주어야 인터넷 검색 속도가 늘어납니다. 때문에 DNS는 데이터 reliability 보다는 빠른 DNS 서비스를 지원하기 위해서 커넥션 셋업을 맺지 않는 UDP를 사용하게 됩니다.

 

만약 데이터 손실이 나면 어떻게 할까요?

 

UDP는 오류에 대해 어떠한 대처도 안해주지만, 다시 DNS 쿼리를 하면 된다는 겁니다. 이게 어쩌면 어플리케이션 레이어에서 reliability를 복원하는 방법이 될 수 있겠습니다.

 

 

2-3. UDP for QUIC

구글이 만든 트랜스포트 레이어 QUIC(Quick UDP Internet Connections)입니다. 그렇다고는 하지만 실제론 어플리케이션 레이어로 보셔야 합니다.

트랜스포트 레이어는 이미 TCP라는 국제 표준이 있기 때문에 구글이 마음대로 바꿀 수 없습니다. 그래서 구글이 채택한 방법은 아무 기능도 없는 UDP를 두고, 데이터 전송 속도를 잘 관리하는 알고리즘을 어플리케이션 레이어에서 구축하게 됩니다. HTTP 밑에 또다른 어플리케이션 레이어인 QUIC을 만들게 된 것입니다. UDP 기반으로 돌아갑니다.

 

이렇게 웹브라우저의 전송속도를 높이겠다는 취지로 QUIC이 등장하게 되었습니다.

 

 

2-4. UDP : checksum

UDP를 통해서 데이터를 전송할 때 에러가 발생한 거(flipped bits가 되었는지)를 알게끔 체크하도록 하는 기능입니다. 디지털 데이터를 아날로그 전파로 바꿔서 목적지까지 보내다보면 전파의 왜곡이나 노이즈에 의해서 원하는 데이터가 잘 전송이 안될 때가 있습니다. 

checksum은 UDP에서만이 아니라 여러 분야에서 사용이 되는 방식입니다. 대표적으로 신용카드에서 쓰입니다. 결제를 할 때 신용카드 번호를 넣는데 신용카드 번호를 아무 번호로 넣으면, invalid한 번호라고 뜹니다. 

그렇다면, 어떻게 신속하게 맞지 않는 번호를 판별했을까요?

바로 checksum 기능 덕분입니다.

최종 점수가 10으로 나누어 떨어지면 valid한 번호라고 합니다. (참고만)

 

sender

1) 헤더에 포함된 세그먼트 컨텐츠를 16bit로 취급합니다.

2) checksum은 세그먼트 컨텐츠를 더하게 됩니다. 그 후 더한 값이랑 checksum연산을 하게 됩니다.

 

receiver

1) sender가 보낸 checksum을 계산합니다.

2) 계산된 체크썸이 필드의 체크썸과 같은지 확인합니다. 다르면 에러! 같으면 에러가 감지가 되지 않았다고 인지합니다.

자리수가 넘어가게 되면 앞으로 더하면 됩니다. 이 때 체크썸에는 1과 0을 바꾼 것을 넣어주고, 둘을 더해주면 모두 1이라는 값이 나올겁니다. 리시버에 전달된 sum과 체크썸을 더했을 때 모두 1이면 에러가 없는 것이고, 1이 아니면 에러가 있는 것 입니다.

 

 

3. multiplexing /  demultiplexing

 

1) multiplexing

멀티플 데이터 스트림을 하나의 스트림 또는 하나의 시그널로 combined하는 과정입니다. 목적지 호스트의 IP주소 헤더를 붙은 데이터그램으로 전달하기 위함입니다. 하나로 합쳐진 스트림은 physical communication link로 전달되고 목적지 호스트로 전달되면 포트넘버를 활용해 프로세스를 맵핑되는 과정이 생깁니다.

 

2) demultiplexing

하나의 링크로 전달된 데이터를 포트 번호를 활용해 여러 프로세스로 맵핑하는 과정을 말합니다.

동작 방식은 아래와 같습니다.

 

1. 호스트는 네트워크 레이어에서 IP 데이터그램을 전달받습니다.

2. 각 데이터그램은 소스와 목적지 IP주소를 가지고 있습니다.

3. 각 데이터그램은 하나의 트랜스포트 레이어 세그먼트를 수송하게 됩니다.

4. 각 세그먼트는 소스와 목적지 포트번호를 가지고 있습니다.

 

데이터그램이 가지고 있는 IP주소와 세그먼트가 가지고 있는 포트번호를 가지고, 적절한 소켓에 세그먼트를 전달합니다.

 

 

3-1. 소켓 프로그래밍 맛보기

1) 소켓을 생성하기 위해 소켓 객체를 생성합니다. 12345와 같이 포트 번호를 지정해줍니다.

-> new DatagramSocket(12345);

 

2) 소켓을 만들 데이터그램을 생성할 때 UDP 소켓을 통해서 데이터그램을 생성할 때는 목적지 IP주소와 목적지 포트 번호를 반드시 지정합니다. 

 

3) 호스트가 UDP세그먼트를 받으면, 목적지 포트번호를 확인하고, 포트번호를 활용해서 UDP 세그먼트를 포트번호가 가르키는 소켓으로 전달하게 됩니다.

 

4) 다른 소스 IP주소와 소스 포트 넘버는 같은 소켓에 목적지로 전달됩니다.

 

UDP 예시

1) 각 소켓을 생성합니다.

 

 

2) 소켓을 통해서 데이터를 P3 -> P1으로 주는 것을 가정합니다. 그럼 소스포트 번호는 자신의 포트번호인 9157이고, 목적지 포트 번호를 6428로 지정됩니다.

 

 

4. TCP

 

4-1. TCP의 4-tuple

TCP 소켓은 4-tuple에 의해서 구분이 됩니다. 4-tuple은 다음과 같습니다.

1) 소스 IP 주소

2) 소스 포트 넘버

3) 목적지 IP주소

4) 목적지 포트 넘버

 

UDP가 3) 4)만 필요했던 것과는 차이가 있죠?

 

TCP는 동시에 여러개의 TCP 소켓을 지원하게 됩니다. 만약 웹서버일 경우 웹클라이언트들이 서버와 TCP 커넥션을 맺을 겁니다. 때문에 각각의 클라이언트들의 소켓을 관리해야하는데요. 4-tuple에 의해서 소켓이 구분됩니다.

이 그림에선 4가지 세그먼트 중 3가지 세그먼트는 목적지 B 80을 가지고 있지만 각 다른 소켓으로 demultiplexed가 되고 있는 것을 볼 수 있습니다.

 

---

50분 정리하는데 1시간이 금방가네요 ㅠㅠ