[ Network ] Transport layer ( Multiplexing ~ Flow control)

 

네트워크 ,트랜스포트 레이어가 각자 할 수 있는 역할을 명확히 이해해야지 멀티플렉싱과 디멀티플렉싱을 활용 할 수 있다.

 

네트워크 레이어는 호스트들간의 논리적인 연결고리 이고, 트랜스포트레이어는 프로세스들간의 논리적인 연결고리 라고 할 수 있다.

 

즉, 데이터를 보내고 각 host의 박스까지 보내주는 것이 Network의 임무이고, 들어온 정보를 알맞은 Application에 뿌려주는게 Transport layer's multiplexing & demultiplexing 이다. ( = 중요 ! )

 

 

 

- Multiplexing ( 1명의 Sender가 여러명의 Receiver 에게 보내면 퍼지는 느낌 -> 멀티 플렉싱 )

 

Socket ( 어플리케이션 레이어와 전송 레이어 사이에 있는 것 , 문과 같은 역할을 한다.) 을 통해 데이터+Transport header를 붙여서 송출

 

 

- Demultiplxing ( 여러명의 센더의 데이터가 한명의 Receiver로 들어오게 되면, 여러개가 한곳에 모이는 느낌 ! )

 

1) Connectionless Demultiplexing

UDP를 통해 Source (보내는 사람) + Destination(받는 사람) 의 Port 주소만을 확인하여 데이터를 받는다.

즉, 하나의 소켓으로 모든 정보를 받는다는 의미이다.

대표사진 삭제

사진 설명을 입력하세요.

 

2) Connection Demultiplexing

TCP를 통해 Source (보내는 사람) + Destination(받는 사람) IP 및 Port number를 확인하여 데이터를 받는다.

데이터 별로 다른 소켓으로 데이터가 Demultiplexing이 된다. 만약, port number를 모른다면 데이터가 receiver까지는 들어가지만 어떤 소켓으로 들어가야하는지 모르기 때문에 Loss 발생.

대표사진 삭제

사진 설명을 입력하세요.

 

<UDP segment Structure >

the port numbers allow the destination host to pass the application data to the correct process running on the destination end system (that is, to perform the demultiplexing function).

 

사진 삭제

사진 설명을 입력하세요.

 

 

<Reliable Data transfer >

RDT 1.0 ~ 3.0 까지는 모두 Stop & Forwarding 방식으로 이루어 졌다.

 

GBN 부터는 Pipelined 방식으로 멈춤없이 전송을 하면 window를 미는 형식을 바뀌었다.

하지만, timout & 3 duplicate => 알아차리면 오류난 부분부터 다시 보내야 됬기 때문에, retransmit이 많다는 단점이 있다.

 

- Selective repeat protocol

GBN의 단점을 지적하면서 나온, SR protocol은 수신자 입장에서 발생된 오류 패킷에 대한 재전송만을 한다.

수신자도 buffer을 만들어서 저장한다.

 

단점

1) Sender & receiver가 synchronization이 되지 않았기 때문에 4개의 패킷을 보낸다고 가정했을 때, 3사이즈의 윈도우를 가지고 있다면 3,0,1 와 같은 재전송이 일어 날 수 있다. 왜냐하면 0,1이 새로운 것인지 재 전송된지 알 수 없기 떄문이다.

 

2) 0,1,2가 다 로스되어서 다시 보내졌을 떄, 이 데이터가 재전송인지 첫번쨰로 보낸것인지 알 수 없다.

 

3) 위에서 언급했던 것 처럼 1차례의 전송이 완료되고, 3,0,1을 보냈다 하지만 3 패킷이 가진 seq#번호를 잃어버렸는데 0이 도착했다. 수신자 입장에서는 보낸 것을 볼 수 없고, 오직 받은 데이터의 seq#만 보기 떄문에 분별 할 수 없다.

 

즉, 송신자 입장을 수신자가 볼 수 없기 때문에, seq이 잘못되거나 같은 내용이 계속오면 수신자는 무슨 데이터인지 정확히 분별 할 수 없다.

 

해결책

윈도우 사이즈를 조절한다. seq# num의 총 개수를 반으로 나눠서 sender,receiver의 윈도우 사이즈로 지정한다.

 

사진 삭제

사진 설명을 입력하세요.

* sender와 reciver의 window slide가 다르다 !

 

1) 4사이즈의 윈도우를 가지고 있기 떄문에, 0,1,2,3을 전송

2) 0,1,3만 오고 2는 loss가 되었다.

3) 송신자는 입장에서는 0,1에 대한 ACK만 받았기 때문에 4,5를 전송 한다.

4) 이 다음 3에 대한 AKC을 받지만, 슬라이드는 움직이지 않고 4와 5까지 다 받으면 2빼고 모두 받았기 때문에 2를 다시 전송한다.

5) 다시 2를 받게 되면 한번에 2,3,4,5가 슬라이딩 된다.

 

 

 

< TCP OverView >

 

- TCP의 특징

Point to Point : one sender & receiver

reliable, in-order byte stream

pipelined / send & receive buffer / full-duplex / flow control

 

- TCP segment structure

사진 삭제

사진 설명을 입력하세요.

Sequence num : 순서를 통해, ACK과 NAK을 구별하는 용도 ( 원했던 seq#이 아니면, NAK)

Ack number : ACK도 순차적으로 숫자가 향상한다.

U ( Urgent Data ) : 서버가 클라이언트에게 (반대도 참) TCP flow와 관계 없는 일을 시킬 때 쓰이는 flag.

A (Ack Valid ) : SYN(연결)이 된 이후의 모든 패킷에는 ACK Valid가 붙어서 가야한다.

P(Push data) : 급한 데이터를 보내야 할 때, 패킷을 다른 계층을 거치지 않고 최하단으로 보낸다.

R(Restart) : 커넥션 리셋

S ( Synchronization ) : TCP연결이 되어있으면 1, 안되있으면 0

F ( Finish ) : TCP 연결을 끊으려고 하면 1로 전환

 

 

2) Flow Control

Sender가 Receiver의 cwnd의 양을 고려해서 속도 조절을 하는 것

 

<Receiver side - cwnd 설정 >

Lastbyted Rcvd - LastbytedRead <= RcvBuffer

받는 사람의 윈도우 크기보다 작거나 같게 전송해서 Not Overflow 되도록 한다.

그 이후, rwnd = RcvBuffer - [ Rcvd - Read] 로 계속 사이즈를 조절

 

<Sender Side - how to know ? >

최초에는 rwnd (리시브 사이드의 윈도우 크기) = Rcvbuffer로 설정한다.

이후, LastbySent - LastbyAcked <= rwnd 으로 꾸준히 조정해가며, over flow하지 않게 한다.

 

<Flow control이 가진 문제점>

만약, 수신자의 버퍼가 가득차면 rwnd =0으로 된다. 그 이후 송신자에게 rwnd는 0이라고 말하는것 외에는 다른 것을 보낼 수 없기 때문에 만약 비워지는 상황이 와도 알 수 없게되는 문제가 발생한다.

 

그러한, 문제를 해결하기 위해 송신자는 수신자에게 끊임없이 one byte만큼의 데이터를 보내서, ACK을 다시 받게 된다면 비었다는 사실을 확인하고 다시 보낼 수 있게 된다.

 

 

3 ) Set RTT (Round trip time) Timeout Value

Sample RTT : Segment(=Data) 를 보내는데 걸리는데 걸리는 평균적인 시간 (= Average RTT)

 

Esitiamated RTT : ( 1- A ) * Estimated RTT + A* Sample RTT

 

DevRTT (= Estimated RTT의 변화 정도 ) = ( 1- b) DevRTT + b ( Sample RTT - Estimated RTT )

 

Timeout = Estimated RTT + 4 * DevRTT

 

<how does the connection use the rwnd to provide the flow-control? >

B -> A = how much spare room it has in the connection buffer by placing rwnd in every segment

처음에는 rwnd = rcvbuffer(전체) 크기로 부여한다. 그리고 보내는 쪽은 계속해서 SENT-ACK = NAK의 크기를 Connection을 통해 보낸다.

 

 

4) Tcp Reliable Data Transfer

트랜스포터 레이어에서 내려온 segment는 -> IP로 보내진다.

각각의 Segment는 seq#를 가지게 된다. 타이머가 움직이지 않으면, IP를 지나갈 때 타이머를 작동 시킨다.

 

TCP는 타임아웃을 유발한 segment를 다시 전송함으로써, 타임아웃에 응답한다.

 

TCP는 compare y with sendbase와의 비교를 한다.

sendbase = seq# of the oldest unack byte. => sendbase -1 = 순서대로 온 마지막 ACK

그래서 y가 sendbase보다 크다는 것은, 승인되지 않은 1개이상의 segment가 있다는 소리!

sendbase를 다시 조정 후, 타이머를 다시 킨다.

 

1) scenario1

 

사진 삭제

사진 설명을 입력하세요.

 

A->B에게 보냈지만 ACK이 오지 않아 타임 아웃이 발생 후 재전송을 한다.

B는 이미 가지고 있는 seq을 가지고 있기 때문에, 재전송에서 받은건 폐기한다.

 

2) scenario2

사진 삭제

사진 설명을 입력하세요.

 

A->B에게 100, 120을 보냈지만 두개 다 ACK이 오지 않았다. 그러한 이유로, 92를 다시 보내고 타이머를 다시 켰을 때 ACK이 돌아오게 되면 2번째를 다시 보내지 않는다.

 

사진 삭제

사진 설명을 입력하세요.

 

A->B에게 두개의 세그먼트를 보냈을 때, 첫번째 세그먼트는손실되었지만, 시간 초과 이전에 120을 보냈다면 119바이트를 통해 첫번째 세그먼트를 수신 받은 거라는 걸 확인 할 수 있다.