네트워크 5. 전송 계층

transport services and protocols

여러 호스트에서 동작하는 프로세스 사이의 논리적 통신을 제공함

 

종단시스템에서 전송프로토콜의 동작

Sender 에플리케이션 메시지를 세그먼트로 나누도 네트워크 계층으로 전달

Receiver 세그먼트 메시지로 재조립하고, 애플리케이션 게층으로 전달

인터넷에서는 TCP, UDP 두 가지 프로토콜을 사용함

 

 네트워크 계층

호스트 사이의 논리적인 통신

종단간 통신

 

전송계층

프로세스 사이의 논리적 통신

내부 통신

 

Sender 

애플리케이션 게층의 메시지를 전달함

세그먼트 헤더 값을 결정

세그먼트 생성

세그먼트를 ip로 전달

 

reciver

ip로부터 세그먼트 수신

헤더값 확인

응용계층 메시지 추출

소켓을 통해 메시지를 애플리케이션 까지 역다중화

 

TCP

신뢰성 있고 순서대로 전달함

혼잡제어, 흐름제어, 연결설정

 

UDP

신뢰성 없고 순서 없이 전달

 

둘 다 지연/대역폭 확장은 보장 받을 수 없음

 

다중화

다중 소켓으로 부터 데이터를 다루고, transport header을 추가

transport -> network -> link -> physcial 순으로 헤더가 붙는것

 

역다중화

헤더 정보를 바탕으로 수신된 세그먼트를 정확한 소켓으로 전달함

해더정보를 하나씩 떼보면서 정확한 소켓으로 전달하는 것

 

역다중화 작동

1. 호스트는 IP 데이터그램을 수신함 데이터그램은 손신IP, 목적지 IP주소를 가짐

2. 각 데이터 그램은 하나의 전송 계층 세그먼트를 전달

3. 각 세그먼트는 송신/목적지 포트 넘버를 가짐

4. 호스트는 IP주소, port넘버를 이용해 세그먼트를 적적한 소켓으로 전송함

데이터그램은 네트워크 계층, 세그먼트는 전송계층에서 이요된다.

따라서 역다중화는 반대로 데이터그램 헤더, 세그먼트 헤더 순으로 벗겨낸다

 

비연결성 역다중화 UDP

소켓 생성 시 local host port를 구체화해야 함

데이터그램 생성 후 소켓으로 전송 시 목적지 IP주소, 목적지 portnumber 구체화

수신 시 UDP 세그먼트를 받을 때

세그먼 트 내 portnumber확인 -> 해당 portnumberfmf 가진 소켓으로 전송

 

동일한 목적지 포트 넘버를 가지지만 다른 IP주소, source port number을 가진 UDP데이터그램은

수신 호스트에 동일한 소켓으로 전송된다

즉 목적지 포트만 본다는 의미

 

연결성 역다중화

4-tuple에 의해 구별됨

소스 Ip주소, 소스 포트 넘버, 목적지 ip주소, 목적지 포트 넘버

수신자는 위 4값을 모두 사용하여 세그먼트를 적적한 소켓으로 전송함

많은 TCP 소켓을 동시에 지원 가능

다른 세그먼트가 모두 동일한 목적지 IP주소, 포트넘버를 가지고 있더라도 receiver의 각기 다른 소켓으로 감

 

UDP특징

오류 있을 수 있음, 순서 없이 전송, 비연결형(연결과정 없음), UDP세그먼트는 독립적으로 작동, 

작은 헤더사이즈와 연결설정이 없어 빠르다는 장점이 있음

손실보다는 속도가 중요한 스트리밍 등에 유용

애플리케이션 계층에서 신뢰성, 혼잡제어를 할 수는 있음

 

UDP 세그먼트 헤더

소스 포트, 목적지 포트, 길이, 체크섬

 

UDP 체크섬

송신된 세그먼트에서 에러를 검출하는 방법 중 하나

송신 할 때 내용과 내용의 합에 대한 정보를 보냄

전달 받은 내용을 더한 값과 합의 값이 같은지 비교하면 잘 왔는지 알 수 있음.

약한 보호 - 숫자가 일부 변하더라도 같은 결과가 나오는 한계가 있음

sender 16비트 로 UDP 콘텐츠 취급, 체크섬 =. 세그먼트 콘텐츠의 합(합이 1인 보수합) 체크섬 필드에 값을 입력

receiver 수신된 세그먼트 체크섬 계산, 계산된 체크섬이 체크섬 필드와 같은제 계산, 같으면 에러 검출 안됨, 다르면 에러

 

신뢰성 있는 데이터 전송

sender이 보내는 정보가 reliable channel을 통과해 receiving로 가는 것

 

하지만 현실에서는 unreiable함 임의로 바꿀 수 없다

신뢰성 있는 데이터 전송 프로토콜은 비신뢰적인 채널의 특성에 강한 영향을 받음(손실, 오염, 순서 변환 등)

sender과 reveiver은 메시지가 전달되지 않는 . 한서로의 상태를 알지 못함

그래서 수신단이 송신단에게 알려주어야 함

 

rdt (reliable data transfer) 신뢰성 있는 데이터 전송

오직 단방향 데이터 전송만을 고려함

FSM을 사용하여 sender, receiver을 지정함

 

rdt 1.0

기본적인 채널은 완벽하게 신뢰성 있음(비트에러, 패킷 손실 없음)

 

rdt 2.0

기본적인 채널이 패킷 내 비트를 바꿀 수 있음. 

비트에러를 거물할 체크섬이 필요함

ACK receiver은 패킷이 ok를 받았다고 명시적으로 sender에게 말함

NAK reveiver은 패킷이 에러가 있다고 명시적으로 sender에게 말함

sender은 nak를 수신시 패킷을 재전송함

sender이 하나의 패킷을 보내고 reveiver의 응답을 기다림

결함

ACK/NCK신호도 손상될 수 있음.

sender은 reveiver이 어떤일이 일어났는지 모름 -> 재전송 할 . 수없음

해결 -> rdt2.1

반복을 활용함 ACK/NCK가 손상되었으며 sender은 현재 패킷을 재전송함

sender은 각 패킷에 시퀀스 넘버를 부여함

 

rdt 2.1 왜곡된 ACK/NCK를 다루는 경우

왜곡된 ACK/NCK를 받을 경우 sender은 패킷을 재전송

다시 동일한 패킷을 받을 경우 ack오류가 있다는 것은 receiver가 앎

하지만 이 경우 수신단은 송신단이 ack/nck를 받았는지 알수 없기에 어떤 패킷이왔는지 모름

이 문제를 해결하기 위해 패킷에 시퀀스 넘버를 부여해 어떤 패킷인지를 구별함

 

rdt 2.2

2.1과 같은 기능을 하고 ACK만 사용함

NAK대신 receiver이 마지막 패킷에 대한 ACK를 전송함(시퀀스 넘버도 포함)

sender 입장에서는 중복된 ack가 오면 nck로 간주

 

rdt 3.0

재전송 만으로는 충분하지 않을 수 있음

sender은 ack를 위한 합리적인 시간을 기다림

어떤 ack도 안오면 재전송

패킷이나 ack가 딜레이 된다면 재전송 중복은 시퀀스넘버로 해결

 

rdt3.0의 성능

이용률

송신자가 채널을 통해 부주하게 비트를 전송하는데 걸리는 시간

링크 1gb, 전송 딜레이 15ms, 8000bit

전송시간: 8000bits/ 1gb/s = 8밀리초

 

총 시간 = 데이터 왕복시간 +. 딜레이 시간

 

이용률 = 전송딜레이 / 왕복시간+전송딜레이  0.008/30.008 = 0.00027

이용률이 매우 낮아 rdt3.0은 성능이 좋지 않음

이에 추가적인 pipelining을 도입

여러개의 진행중인 패킷을 허용함

파이프라이닝을 통해 증가한 이용률 (3개라 가정할 경우)= 3L/R  /  RTT+L/R = 0.00081

3배 증가

 

GO Back N Sender

타임 아웃이 발생한다면?

여러개의 패킷을 보낼 경우 보내고 ack수신함, 보내고 ack수신못함, 아직못보냄, 아직사용 불가로 구분

송신자는 가장 오래된 전송했지만 아직 ack확인안된 패킷에 대한타이머를 적용함

타임아웃 발생 시 이전에 전송했지만 아직 확인응답되지 않은 모든 패킷을 재전송

 

순서가 잘못된 패킷을 수신한다면?

해당 패킷을 버리고, 최근 제대로 수신된 순서의 패킷에 대한 ack전송

 

4개씩 패킷을 전송할 때 2번 패킷이 잘못온다면 

3,4번 도 버리고 2번부터 다시 받음

 

 

SR (selective repeat)

GO Back N sender은 하나가 잘못되면 뒤에오는 전송을 모두 버리는 문제가 있음

Receiver이 올바르게 수신된 모든 패킷을 개별적으로 확인함

상위 계층으로 이동을 위해 필요에따라 패킷을 버퍼링

ACK되지 않은 패킷에대해 개벌적으로 시간초과/재전송을 함