comnet-06

Chapter 03. Transport layer(1)

Transport layer services

Transport Layer는 서로 다른 호스트(컴퓨터)에서 실행 중인 애플리케이션 프로세스 간에 논리적 통신을 제공한다.

송신자(Sender)는 애플리케이션 메시지를 세그먼트로 쪼개서 네트워크 계층으로 전달한다.
수신자(Receiver)는 받은 세그먼트를 다시 조립하여 원래 메시지로 복원하여 애플리케이션 계층에 전달한다.

Sender
응용 계층(application layer)에서 메시지를 받는다.ex) 웹 브라우저가 보낸 HTTP 요청
세그먼트의 헤더 필드 값(포트 번호 등)을 결정한다.
헤더와 데이터를 결합하여 세그먼트(segment)를 생성한다.(encapsulation)
세그먼트를 네트워크 계층(IP)에 전달한다.

Receiver
IP 계층으로부터 세그먼트를 받는다.
헤더 정보를 확인하여 (포트 번호 사용) 어떤 응용 프로그램에 전달할지 결정한다.
세크먼트에서 헤더를 제거하고 응용 계층 메시지만 추출한다.(decapsulation)
포트 번호 기반으로 메시지를 알맞은 응용 프로그램의 소켓으로 전달한다.(demultiplexing)

<두 가지 주요 인터넷 전송 계층 프로토콜>

1) TCP
reliable(신뢰성), in-order delivery(순서 보장), congestion control(혼잡 제어), flow control(흐름 제어), connection setup(3-way handshake와 같은 연결 설정 필요)
속도보다 신뢰성이 우선이므로, 속도는 보장이 안된다.
2) UDP
unreliable(신뢰성 없음), unordered delivery(순서 뒤바뀔 수 있음), no-frills(추가 기능이 없는 간단한 구조), best-effort delivery(최선을 다해 데이터 전달)

두 가지 모두 전송 계층이지만 지연 시간(delay)과 대역폭(bandwidth) 보장이 없다.

Multiplexing and demultiplexing

Multiplexing(다중화): 여러 어플리케이션에서 오는 데이터를 모아서 각각 전송 계층 헤더를 붙여 IP로 내려보내는 것, 보내기 위한 준비
Demultiplexing: 수신한 데이터의 헤더 정보(포트 번호 등)를 바탕으로 알맞은 소켓(애플리케이션)으로 데이터를 전달하는 것, 누구한테 줄지 결정

Demultiplexing

IP 데이터그램을 받으면, 그 안에는 TCP/UDP 세그먼트가 들어있는데, 그 세그먼트는 source port와 destination portf를 16bit씩 갖고 있다. 이 포트 번호를 보고 어떤 소켓에 연결해야 할지 판단한다.

1) Connectionlass demultiplexing (UDP)
소켓을 만들 때 destination port 번호 하나만 사용한다.
여러 (source IP/source port가 다른, host-local port #를 가진) 송신자로부터 같은 destination port로 오는 세그먼트를 하나의 소켓으로 전달한다.

서버가 DatagramSocket mySocket1 = new DatagramSocket(12534); 포트로 열려있는 상황
클라이언트가 목적지 IP와 포트 번호를 지정해서 UDP 세그먼트를 보낸다.
수신자는 해당 destination port를 보고 그 포트 번호를 가진 소켓으로 세그먼트를 전달한다.
즉, UDP는 connectionless라서 송신자 정보(source IP, port)는 무시하고 오직 destination port만으로 수신 소켓을 결정한다.

2) Connection-oriented Demultiplexing (TCP)
TCP 소켓은 4가지 정보(튜플)로 식별된다.
source IP address, source port number, destination IP address, destination port number

TCP는 연결지향이기 때문에 여러 클라이언트가 동일한 서버 IP/port로 접속해도 각 클라이언트의 source IP/port가 다르기 때문에 모두 다른 연결로 취급이 가능하다. 따라서 서버는 각 요청을 다른 소켓으로 처리한다.

비유로 이해하자면,
UDP는 문 앞에 택배 박스를 여러 개 두고 가면, 박스를 보며 누가 보냈는지 나중에 확인하는 것이다.
TCP는 문을 열고 들어와 손님마다 좌석을 배정해주는 것이다.

Connectionless transport: UDP

no frills, bare bones: 꾸밈없고 단순한 최소 기능만 제공하는 프로토콜
best effort: 최선은 다하지만 보장은 없음, 데이터가 손실되거나 순서가 섞여 도착할 수 있다.
connectionless: 연결 설정이 없으며 매 세그먼트를 독립적으로 처리한다.
no handshake: 송신자와 수신자 간의 연결 협상이 없이 바로 전송이 가능하다.
즉, 간단하고 가볍지만 신뢰성이 없음

그렇다면 왜 UDP가 존재할까?
no connection setup: TCP는 연결 설정에 왕복 시간(RTT)이 걸리지만, UDP는 그런 거 없이 바로 전송이 가능하다.
simple 구조: 상태(state)를 저장하지 않아서 메모리 부담이 적다.
작은 헤더: TCP보다 훨씬 작고 단순한 구조
no congestion control: TCP는 혼잡 제어 때문에 속도가 제한되지만, UDP는 제한 없이 막 보낼 수 있다.(장점이자 단점)

UDP는 스트리밍 앱, DNS, SNMP, HTTP/3 등에 사용된다.
UDP 자체는 신뢰성이 없기 때문에 필요한 경우에는 애플리케이션 계층에서 직접 처리해야 한다.

UDP Segment Header
크게 헤더와 데이터(payload)로 구성된다.

length: 전체 UDP Segment 길이 (헤더 + 데이터 포함)
checksum: 데이터가 중간에 손상되었는지 확인하는 오류검출값

UDP Checksum
데이터를 보내는 도중 비트가 뒤집히는 등 오류가 생겼는지 감지하기 위한 값이다.

계산된 값이 다르면 수신자는 데이터가 손상되었음을 인식하고 세그먼트를 폐기할 수 있다.

Internet Checksum
데이터가 전송 중 손상되었는지 감지

송신자(Sender)측
1. UDP 세그먼트 전체를 16비트 단위로 쪼갠다.
2. 1의 보수 덧셈으로 더한다.
3. 마지막 결과에 1의 보수를 취한다. 이것이 checksum
4. 계산한 값을 UDP 헤더의 checksum 필드에 넣는다.

수신자 측
1. 도착한 UDP 세그먼트에서 checksum 포함해서 모든 16비트 단위들을 더함
2. 합이 0이 아니면 에러 발생