CH3 : Transport Layer (1)

* 이 글에 관련된 모든 내용은 Computer Networking A Top-Down Approach 7th에서 가져온 내용이다. *

 

저번 챕터2에서는 Application Layer에 대해 공부했었다.

이번 챕터부터는 그 하위레이어 Transport Layer에 대해서 공부하겠당

 

Transport Services

---

 

 

트랜스포트 레이어는 app간의 논리적인 소통을 담당한다.

 

이 레이어는 end system에서 작동한다.

sender side : app의 메시지를 segment단위로 잘라 하위레이어인 network layer로 보낸다.

receiver side : segment단위의 데이터를 message로 합쳐 상위레이어인 application layer로 보낸다.

 

 

 

나중에 다시 배우겠지만 네트워크 레이어는 end system간의 데이터 전송을 담당한다.

트랜스포트 레이어는 process간의 데이터 전송을 담당한다.

 

이전에 TCP와 UDP에 대해 간략하게 소개했었다.

이 두 프로토콜은 트랜스포트 레이어의 대표적인 프로토콜이다.

 

1. TCP(Transmission Control Protocol)

 - 연결지향

 - Reliable, ordered delivery

 - congestion control

 - flow control

 - Multiplexing/demultiplexing

2. UDP(User Datagram Protocol)

 - 비연결지향

 - Unreliable, unordered delivery

 - no-friils extesion of "best-effort" IP

 - Multiplexing/demultiplexing

 

Multiplexing/Demultiplexing

---

많은 application들은 하나의 transport layer protocol을 사용한다.

 

Demultiplexing

목적지의 호스트는 도착한 segement를 target application process에게 전달한다. 

각 세그먼트는 src와 dst의 포트넘버를 가지고 있다.

이때, 이 포트넘버는 프로세스를 indetify하기 위해 존재하는데, 각 프로세스들은 소통을 위해 포트넘버와 관련이 되어있다.

클라이언트 프로그램은

 - 클라이언트 호스트에서 실행되고 있는 트랜스포트 레이어 소프트웨어에 의해 자신의 포트넘버를 임의로 지정한다.

 - 이렇게 랜덤으로 지정한 포트넘버를 ephemeral port number라고 한다.

서버 프로그램은

 - well-known 포트넘버를 사용한다. (wellk-known포트넘버는 자주사용되어서 굳이 포트넘버를 IP에 붙여주지 않아도 기본값으로 설정되어있는 포트넘버이다)

 

Port Number

---

well-known ports

 - 0~1023 까지 지정이 되어있다.

Registered ports

 - 1024~49,151 까지 지정이 되어있다.

 - IANA에 의해 control되지 않는다. (IANA : 인터넷 할당번호를 관리하는 기관)

 - 그러나 중복을 막기위할때만 IANA에 등록될 수 있다. 

 - RFCs에 지정되지 않은 TCP/IP 어플리케이션을 사용할 때 사용된다.

Dynamic(private) ports

 - 49,152~65,535 까지 지정이 되어있다.

 - control되지도, 등록되지도 않는다.

 - 어떤 프로세스에도 사용될 수 있다 (ephemeral ports 포함) 

 

서버와 클라이언트에서의 포트넘버

 

 

- TCP socket은 src와 dst의 IP와 포트넘버를 모두 알아야 한다.

 

- UDP는 dst쪽의 IP와 포트넘버만 알면 된다.

 

즉 한 호스트로 온 서로 다른 데이터그램이 같은 port넘버를 가리키고 있으면 UDP는 다 받아버리지만 TCP는 src의 IP와 포트넘버도 맞아야 받는다.  

 

 

 

UDP에서의 demux

 

 

TCP에서의 demux

 

 

 

UDP (User Datagram Protocol)

---

이제 지금까지 맛만보았던 UDP에대해서 자세하게 알아보자.

 

UDP는 simple하고 비연결지향적인 인터넷 프로토콜이다.

connection이 필요없기 때문에 3-handshaking과정 또한 필요없다.

각 UDP 세그먼트들은 독립적으로 처리된다.

 

또한 UDP는 reliability를 보장하지 않는다.

세그먼트가 전송중에 손실될 수 있고, order또한 보장해주지 않는다.

또한 리시버의 buffer overflow를 막아주는 flow control도 없고, 라우터/스위치 등 네트워크의 혼잡을 제어헤주는 congestion control또한 없다.

게다가 에러를 체크하는 기능은 있지만 찾은 에러에 대해서 control하는 mechanism또한 없다.

(application layer에서 error recovery를 지원하기도 한다)

 

그렇다면 왜 UDP를 사용하는가?

 - connection과정이 필요없기에 overhead또한 없다.

 - error에 대한 recovery가 없기 때문에 매우 간단하다.

 - congetsion control이 없기 때문에 빠른 전송이 가능하다.

 - 1:1통신이 아닌 여러 peer와 통신이 가능하다.

 

이러한 장/단점때문에 UDP는 다음과 같은 곳에 사용된다.

 - streaming multimedia apps (로스에 치명적이지 않고, rate에 민감함)

 - RIP(Routing Internet Protocol) : 주기적으로 업데이트

 - DNS(Domain Name System) : connection set-up overhead가 없기 때문

 - SNMP(Simple Network Management Protocol) : 적은 overhead

 

UDP의 Header

UDP의 헤더는 다음과 같은 형식을 갖는다.

total length 는 헤더+데이터만큼의 길이이다.

error recovery를 지원하지 않기 때문에 sequence와 ACK를 위한 field는 없다.(TCP에서 다룰 예정)

checksum : header, data, pseudo-header를 이용해 에러를 체크하는 기능이다. IPv4에선 optional이지만 IPv6에선 필수이다. 만약 checksum을 통해 error를 확인하면 다른 처리는 하지 않고 그냥 제거해버린다.

 

UDP의 Pseudo-Header

 

 

수도헤더는 checksum 계산에 사용된다. (전송되는 정보는 아니다.)

 

UDP에서의 checksum

 

 

 

chceksum은 header, data 그리고 pseudo-header의 bit을 모두 더한 후 1's complement(1은 0으로 0은 1로)를 취한뒤 전송한다.

 

리시버는 받은 데이터의 합과 checksum을 더해 모든 자릿수가 1로 채워지지 않으면 에러로 간주하고 해당 datagram을 버린다.