[네트워크] 5. Transport Layer (1)

3.1 트랜스포트 계층 서비스 및 개요

 

트랜스포트 계층 프로토콜은 → 서로 >>다른<< 호스트의 애플리케이션 프로세스들 간의 논리적 통신 제공

애플리케이션의 관점에서 프로세스들이 동작하는 호스트들이 직접 연결된 것처럼 보이는 것을 의미

네트워크 레이어 - 호스트들 사이의 논리적 통신 제공

트랜스포트 레이어 - 프로세스 사이의 논리적 통신 제공

트랜스포트 계층은 네트워크 라우터가 아닌 종단시스템에서 구현됨

라우터에서는 오로지 데이터그램의 네트워크 계층 필드에 대해서 동작함..

 

((sender))

송신 애플리케이션 프로세스로부터 소켓을 통해 수신한 ‘메시지’를 ’세그먼트‘로 쪼개서 각각의 조각에 헤더를 덧붙임

그리고 캡슐화하여 IP로 전송

 

((receiver))

수신 측 네트워크 계층에서는 데이터그램으로부터 → 트랜스포트 계층의 세그먼트 추출하고 트랜스포트로 전송

소켓을 통해 역다중화하여 프로세스로 전송

 

 

3.1.2 인터넷 트렌스포트 계층의 개요

tcp

transport control protocol

연결 지향형 connection-oriented

신뢰적인 서비스

3-way 핸드쉐이킹

혼잡 제어 ( tcp 커넥션이 과도한 양의 트래픽으로 인해서 모든 통신하는 호스트들 사이의 스위치와 링크 폭주를 막는 것)

flow 제어

역다중화 할 때 소켓에 destination IP + address

같은 ip 주소에서 여러 프로세서 작동 (≠ udp)

 

udp

user datagram protocol

비연결형

비 신뢰적인 서비스

순서보장 x

best-effort delivery service model

소켓에 source ip + adderess , destination IP + address (4 -tuple)

가장 기본적인 기능은 - 종단 시스템 사이의 IP 전달 서비스를 종단 시스템에서 동작하는 두 프로세스 간의 전달 서비스로 확장하는 것… 즉 호스트-호스트 전달을 프로세서-프로세스로 확장하는 것

오류검출비트 제공

 

 

 

3.2 다중화와 역다중화 multiplexing demultiplexing

 

소켓이 udp인지 tcp인지에 따라 식별자의 포맷이 달라짐

다중화 → 출발지 호스트에서 소켓으로부터 데이터를 모으고 이에 대한 세그먼트를 생성하기 위해 각 데이터에 헤더 정보로 캡슐화하고 … 네트워크 레이어로 전달하는 작업

(헤더 정보는 역다중화 할 때 어떤 프로세스가 보냈는지 알게 하기 위해 붙임)

• 소켓은 유일한 식별자를 가진다
• 각 세그먼트는 전달될 적절한 소켓을 가리키는 특별한 필드를 가진다.

→ 수신 측 트랜스포트 레이어는 수신 소켓을 식별하기위해 필드를 검사함 (세그먼트의 필드)

그리고 이 세그먼트를 해당 소켓으로 보냄

트랜스포트 레이어 세그먼트의 데이터를 올바른 소켓으로 전달하는 작업 = 역다중화

우편서비스 예시…에서

봉투 안의 편지 = 애플리케이션 메시지

앤과 빌 (우편물 나눠줌) = 트렌스포트 레이어 프로토콜

우편 서비스(우편집배원 포함) = 네트워크 레이어 프로토콜

사촌 형제 = 프로세스

집 = 호스트(또는 종단시스템)

 

역다중화 과정

tcp는 세그먼트

udp는 datagram (근데 네트워크 레이어도 datagram 이라서 네트워크 레이어에선 헷갈리지 않게 ip 붙임)

헤더의 크기 (tcp - 20바이트.. udp - 8바이트)

호스트는 source 포트 번호와 destination 포트 번호를 갖고 역다중화를 한다.. 각각 16비트

udp 문제 상황 → 다른 소스 포트 번호/ 소스 ip주소여도 같은 destination.. 소켓에 도착하므로 순서 섞이고(in-order)

 

 

 

3.3 비연결형 트랜스포트 : UDP

 

유일한 기능 : 비트오류 검사… checksum

no frill, bare bone

세그먼트 손실 가능성

순서 엉망

→ best effort service

connectionless - 핸드쉐이킹 없음

 

그래도 사용하는 이유?

커넥션 설정은 rtt 지연을 불러옴..

간단함 (커넥션 설정 없어서)

헤더 사이즈 작음 8바이트 (↔ 20바이트)

혼잡제어 없음 (항상 빠르게 전송 가능… 혼잡 상황에서도 그냥 전송 가능)

→ HTTP 3.0, DNS, SNMP(네트워크..)

http3.0 QUIC의 기반이 되었다… (신뢰성과 혼잡제어 기능 추가? 기억 안 남..)

 

checksum

세그먼트에서의 오류 비트 검출

보내는 값과 그 합 값 같이 전송

만약 받아봤는데 보내온 값과 받아본 값이 다르다면 오류!

 

인터넷 checksum

약간의 신뢰성 제공…

sender :

세그먼트 안의 모든 16비트 워드 단위로 더함 → 1의 보수로 전환 → 오버플로우 나면 끝에 1 더함

receiver :

받은 세그먼트의 체크섬 계산

똑같으면 ? 오류 없음 : 오류 있음

→ 근데 안 바뀌었어도 오류일 수도 있음.. ㅇㅣ건 문제임..

 

 

 

3.4.1 신뢰적인 데이터 전달 프로토콜 reliable data transfer (RDT)

완벽하게 신뢰적인 채널 상에서의 신뢰적인 데이터 전송 : rdt 1.0

FSM (finite-state machine, 유한상태 머신) 사용… 송신자와 수신자 구별을 위해… (유한상태이므로 state가 더 중요함

비트에러.. 패킷 로스 아무것도 없는 완벽한 신뢰적인 상황이라고 가정

 

 

비트오류 있는 채널 상에서의 신뢰적 데이터 전송 : rdt 2.0

→ checksum 사용… 이건 오류 검출이라면

오류 복구는? > ACK와 NAK를 사용

• ACK (acknowledgrment) : 패킷을 잘 받았음을 의미
• NAK (nagative acknowledgement) : 패킷에 에러 있음을 의미
• → 송신자는 재전송함

stop and wait <<

반응이 날아올 때까지 기다림

새로운 문제 : ACK나 NAK가 손상될 수도 있다.

→ 그냥 재전송 ? 안됨! 중복 가능성

sequence 넘버를 추가하자!

<2.1>

 

비트오류와 손실 있는 채널 상에서의 신뢰적 데이터 전송 : rdt 3.0