[네트워크] Transport layer (1)

2019. 7. 14. 21:33Network

Transport layer는 서로 다른 host내의 프로세스간의 통신을 담당한다. 

메시지를 보내는 host의 transport layer는 application process로부터 전달 받은 메시지를

segment로 새롭게 구성하여 network layer에 전달한다.

메시지 수신 host의 transport layer는 network layer로부터 전달 받은 segment를 처음 받은 메시지의 형태로  변경하여 application layer에 전달한다.

 

네트워크 계층. Application layer와 transport layer는 socket이라는 창구를 통해 통신을 한다
TCP/UDP segment

...더보기

Socket

프로세스는 메시지를 주고 받는 창구의 역할을 하는 구성요소. 프로세스는 소켓을 통해 하위 계층과 패킷을 주고 받는다

 

종류

TCP와 UDP

 

Transport layer의 대표적인 기능

공통

Multiplexing and demultiplexing (TCP/UDP)

Error checking (TCP/UDP)

   error가 발생한 packet은 상위 application으로 전달되지 않는다

* UDP도 error checking을 해준다

차이점

TCP UDP

Reliable data transfer

Unreliable data transfer

Flow control

Sending TCP (w/ buffer)과 Receiving TCP (w/ buffer) 모두 buffer에 데이터를 먼저 채우고 작업 진행. RTCP 처리 속도에 비해 STCP가 너무 속도를 빨리 보낼 경우 속도 조절

 

Flow control 없음

Congestion control

RTCP쪽 buffer가 아니라 네트워크 도중에 있는 경로에서 데이터 처리가 지연될 때도 마찬가지로 속도 조절

 

Congestion control 없음

Connection-oriented 

TCP (Sending TCP and Receiving TCP)간 연결이 되어 있는지 확인 (hand-shaking) 하고 시작

-> 연결 set-up 및 유지하는 overhead 有

 

프로세스-프로세스 조합 별로 다른 socket 사용

Connection-oriented x

 

Socket 공유

TCP / UDP 모두 초창기에 멀티미디어가 활성화되어 있지 않을 때 data integrity만을 위해 고안된 protocol이라

timing, minimum throughput, security 관련 기능을 제공하지 않는다

 

TCP가 더 reliable한데 왜 UDP를 사용할까?

1) 간단한 작업에서 TCP의 overhead를 감당하는게 부담될 수도 있다

2) Reliability가 중요한 메시지의 경우 application 자체에서 따로 체크할텐데 이 경우에는 reliable transport를 위한 작업은 중복작업일 수 있다

3) Minimum throughput이 중요한 경우 (멀티미디어) flow 또는 congestion control이 문제가 될 수 있다

 

Multiplexing and demultiplexing

Multiplexing (send-side):

   여러 socket에서 들어온 data를 처리하고 transport header를 추가하는 것

 

Demultiplexing (receive-side):

   transport header 정보를 바탕으로 맞는 socket에 segment를 전달하는 것

   receiver host는 IP address와 port number를 활용하여 segment를 맞는 socket에 전달한다

 

Reliable data transfer

Reliable data transfer를 방해하는 요인은 크게 패킷 에러 발생 또는 유실이 있다.

 

1) 패킷 에러

패킷 에러 발생을 감지하기 위해 checksum bitACK 신호를 활용할 수 있으며,

에러생시에 데이터를 다시 재전송한다.

추가로 고려해야할 부분은 수신자가 보낸 ACK 신호 또한 error가 발생할 수 있다는 점인데

이 경우 송신자는 재전송을 하게 되면 수신자 입장에서는 지금 받은 데이터가 새로 보낸 패킷인지

아님 다시 보낸 패킷인지 구분할 수 있는 방법이 없다.

이를 구분하기 위해 packet의 순서를 담은 sequence number를 활용한다.

ACK 메시지에 수신자가 가장 마지막으로 받은 sequence number를 포함시킴으로써

송신자가 재전송 여부를 판단할 수 있게 한다.

 

해결책

error detection(checksum bit),  feedback (ACK), retransmission, sequence #

 

 

2) 패킷 유실

패킷이 유실된다면 수신자가 ACK 신호를 보낼 수 없을 것이기에,

송신자는 timer를 활용하여 일정시간이 지나면 재전송한다.

대기 시간의 길이가 짧으면 유실에 대한 응답은 빨라지지만 불필요한 중복 메시지 전송으로 인한

오버헤드 발생이 가능하다. TCP에서는 timeout값을 RTT보다 긴 값으로 잡고 있다.

 

해결책

timer

 

 

실제 TCP에서는 성능을 위해 여러 개의 패킷을 segment에 담아 보내고,

segment에 대해 timer를 동작시킨다. 수신자에서도 보낸 ACK 내의 sequence 번호 또한

segment 제일 앞에 있는 패킷 기준으로 전송된다.

'Network' 카테고리의 다른 글

[네트워크] Link layer  (0) 2019.07.16
[네트워크] Network layer  (0) 2019.07.15
[네트워크] Transport layer (2)  (0) 2019.07.15
[네트워크] Application layer (1)  (0) 2019.07.11
[네트워크] Introduction  (0) 2019.07.10