Transport layer Service(Summary)
-
다른 호스트에서 실행중인 App 간, 논리적 상호작용을 담당
-
End System 에서 실행
Sender, App의 메시지를 Segment로 쪼개어서 Network Layer에 전달
Receiver, Segment를 다시 모아서 Message 완성, Application Layer에 전달
-
이 두개의 Transport 프로토콜은 TCP, UDP라는 인터넷 Application을 통해 이루어진다.
Transport vs Network Layer
- Transport, Process끼리의 상호작용을 담당
- NetWork, host끼리의 상호작용을 담당
Transport Layer Actions(Sender) - UDP
- 어플리케이션 계층에서 온 메시지를 전달
- Segment의 헤더 필드 값을 결정
- Segment 값 생성
- Segment를 IP에 전달
Transport Layer Actions(Receiver) - UDP
- IP로 부터 Segment를 받아옴
- 헤더 값을 확인
- 어플리케이션 계층의 Message를 확장
- 메시지를 demultiplex 하여 Socket을 통해 어플리케이션 계층 으로 전달
Two Principal Internet Protocol @ Transport Layers
- TCP
- 순서대로 진행, 신뢰할만함
- Congestion Control
- flow Control
- Connection Setup
- UDP
- 신뢰할만하지 않음, 순서대로 진행 X
- 최선형 서비스
두 프로토콜은 delay 보장, bandwidth 보장 불가
Multiplexing and Demultiplexing
- Multiplexing(as a Sender)
data가 어플리케이션 계층에서 Transport 계층을 거쳐갈때, Transport 헤더를 붙여서 전달하는 것.
예를 들어 톨게이트를 통과하여 8차선 고속도로로 차들이 모이는 것 같은 개념 - DeMultiplexing(as a Receiver)
받은 data의 헤더 정보를 활용하여 올바른 Socket에 segment를 전달하는 것
예를 들어 고속도로에서 차량들이 분기점에 도착하여 각자 제 갈길 가는 것
Connectionless Demultiplexing (UDP)
-
소켓을 만들때 반드시 host-local port 넘버를 특정하여 보내야함
-
Datagram을 만들어 UDP socket으로 보낼때 두가지를 특정해야함
- 목적지 IP 주소
- 목적지 포트 넘버
- host 가 UDP segment를 받을때
목적지 포트 넘버를 확인하고 포트 넘버의 UDP Socket으로 보냄
-> 목적지가 동일한 IP/UDP 데이터 그램 포트 번호, 그러나 다른 소스 IP 주소 및 소스 포트 번호는, 수신 호스트에서 동일한 소켓으로 지정
D의 source ports는 6428, dest Ports는 5775가 될 것임.
Connection-oriented Demultiplexing(TCP)
- TCP 소켓은 4개의 값을 사용
- 출발지 IP 주소
- 출발지 포트 넘버
- 목적지 IP 주소
- 목적지 포트 넘버
- demux : 받는 쪽 사용자는 4가지 정보 다 사용하여 맞는 소켓으로 segment를 보낸다
- 서버는 동시에 많은 TCP 소켓을 보내는 것이 가능함
-> 각 소켓마다 각자의 4가지 값이 있고, 각각의 소켓은 다른 연결 클라이언트와 연결되어있음
UDP vs TCP
Multiplexing, Demultiplexing 둘다 Segment, datagram의 헤더 필드에 기반하여 동작,
모든 계층에서 이루어짐
UDP
목적지 포트 넘버만 사용하여 Demultiplexing 진행
TCP
4가지 값(목적지의 아이피와 포트넘버, 출발지의 아이피와 포트넘버)를 사용하여 Demultiplexing 진행
UDP : User Datagram Protocol
no-frils, bare bones(essential) 인터넷 Transport 프로토콜
-> best-effort Service, UDP Segment는 손실되거나, 동작하지 않을 수도 있음
-
connectionless
UDP 송/수신측 간 handshaking 없이 진행되며, 각각의 UDP Segment는 독립적으로 실행됨 -
UDP 가 존재하는 이유
- no connection 환경 자체가 RTT 를 증가시킬 수 있기 때문
- 송/수신측간 연결 상태가 필요 없음
- 작은 헤더 크기
- Congestion Control 이 없기때문에, 원하는 만큼 빠르게 통신 가능
=> UDP는 스트리밍, DNS, SNMP, HTTP/3 에 사용
HTTP/3 같은 경우 UDP에 신뢰성 있는 통신이 필요한데, 신뢰성 혹은 혼잡 제어를 어플리케이션 계층에 더해야 함
UDP Segment Header
- 만약 에러 확인(비트가 뒤집혔다던지...)은 어떻게?
UDP Checksum
잘못된 숫자가 들어오는 것을 확인하기 위해 sum값을 활용.
수신측이 computed 한 checksum 과 송신측이 computed 한 checksum이 불일치하면 ERR!
Intermet checksum 활용 과정
-
Sender
UDP 새그먼트를 16비트 정수로 처리
1의 보수를 활용한 추가 checksum 비트 활용 -> UDP Checksum 필드에 집어넣기 -
Recevier
받아온 새그먼트의 checksum을 계산
만약 계산된 checksum과, checksum 필드의 값을 비교
결과가 다르면 에러 발생
-> 그런데, checksum 이 같다고 해서 100% ERR가 발생하지 않는 것은 아님.
맨뒤 비트 두자리가 다름에도 불구하고 checksum 의 결과는 동일
Summary
- no-frils protocol & best-service
- no setup & handshaking -> RTT 필요 없음
- checksum을 통한 신뢰성 확보
- 네트워크가 침해당해도 작동 가능
