[컴퓨터 네트워크] Chap3. Transport Layer(1)

아래는 연세대학교 컴퓨터 네트워크 수업을 듣고 정리한 내용입니다.

(간략하게 정리하였기에 부족한 점이 있을 수 있습니다)

3.1 transport-layer services

• 서로 다른 host에서 실행되는 app process 사이에서 논리적인 의사소통 서비스를 제공한다.
• End system에 구현이 되어있다. → transport protocols run in end system
• 보내는 쪽의 transport layer
  • application layer에서의 메세지를 segments로 부수고, network layer로 넘겨준다.
• 받는 쪽의 transport layer
  • segments를 message로 다시 합치고, application- layer로 다시 던진다.
• 하나의 앱에는 여러 개의 transport protocols를 사용할 수 있다.
  • internet - TCP와 UDP를 둘 다 활용한다.

Transport VS network layer

• network layer
  • host간의 논리적인 의사소통
• transport layer
  • 프로세스 간의 논리적인 의사소통
  • network layer의 서비스에 의존한다.

예시

• host - 집
• 프로세스 - 집에 사는 애기들
• app message - 봉투에 들어있는 편지들
• transport protocol - 애기들에게 편지를 전달해주는 집 주인들
  • 따라서 router 사이에 존재할 필요가 없다. → end system에 구현이 되어있다.
• nework layer protocol - 우체국 사람들

 

Internet transport-layer protocols

• TCP와 UDP를 둘 다 활용한다.
• TCP
  • reliable → 중간에 없어지면 다시 보내기
  • in order → 순서를 보장해서 보낸다.
  • connection setup - sender와 receiver 사이의 연결을 하는 과정을 가진다.
  • congestion control - 망 내부의 체증이 심해지면 보내는 속도를 낮춘다.
  • flow control - 받는 쪽에서 부하가 크다면 보내는 쪽에서 보내는 속도를 조절한다.
• UDP
  • unreliable → 중간에 없어진다고 다시 보내지 않는다.
  • unorder → 순서를 보장하지 않는다.
• 할 수 없는 것들
  • delay guarantee → 딜레이가 적도록 보장할 수 없다.
  • bandwidth guarantee → 속도 유지를 보장할 수 없다.

3.2 multiplexing and demultiplexing

• multiplexing at sender
  • 여러 개의 socket에서 data를 받고, transport 헤더를 붙힌다.
  • kids에게 편지를 받아서 우체통에 넣기
• demultiplexing at receiver
  • header에 있는 정보를 통해서 받아온 segment를 알맞은 socket에게 전달하는 것.

Demultiplexing

• host는 network layer에서 올라온 IP datagrams를 받는다.
  • datagram은 source IP 주소, 목적지 IP 주소를 가지고 있다.
  • • 하나의 transport layer segment를 가지고 있다.
  • • 각각의 segment는 source, destination 포트 넘버를 가지고 있다.
  • 즉, IP 주소와 port 넘버를 가지고 있다.
• 호스트는 IP 주소와 port 넘버를 활용하여 segment를 알맞은 socket에 넣어준다.

 

Connectionless demultiplexing

• UDP의 demultiplexing
  • 생성된 socket은 host의 local 포트 넘버를 가지고 있다.
  • datagram을 만들어서 UDP 소켓에 넣어줄 때에 두 가지를 설정해야된다.
    • 목적지 IP 주소
    • 목적지 포트 넘버
  • 호스트가 UDP segment를 받을 때
    • segment의 목적지 포트 넘버를 확인한다.
    • 서로 다른 source IP 주소, source port number여도 같은 목적지 포트 넘버라면 같은 소켓으로 들어가게된다. → client가 여러 서버와 통신할 수 있다.
    • 즉, destionation port와 destination address만을 확인해서 어느 소켓에 올릴 지 정한다.

Connection-oriented demultiplexing

• TCP 소켓의 구성요소
  • 소스 IP 주소
  • 소스 포트 넘버
  • 목적지 IP 주소
  • 목적지 포트 넘버
• Receiver는 위의 네 개의 값들을 다 확인해서 알맞은 socket에 넣어준다.
  • 네 개 중에 하나라도 값이 다르다면 다른 socket에 들어가게됩니다.
• Host는 여러 개의 TCP socket을 가질 수 있다.
• 웹 서버는 각각의 클라이언트에 여러 개의 socket을 생성할 수 있다.
  • non-persistent HTTP는 각각의 request에 서로 다른 소켓을 가질 수 있다.

 

TCP demultiplexing example

• 4가지 요소를 다 확인하여 알맞은 socket에 들어가게된다.

즉, 결론을 내면 UDP 경우에는 데스티네이션 IP와 데스티네이션 포트 넘버만 가지고 어디로 올려보낼지에 대한 Demultiplexing을 하게 되고, TCP 같은 경우에는 소스 IP 그리고 소스 포트 그리고 데스티네이션 IP 그리고 데스티네이션 포트 4개 튜플을 가지고 Demultiplexing을 하게 돼 있습니다. 그래서 만약 하나라도 다르다면 서로 다른 socket으로 request를 받게 됩니다.

 

 

3.3 connectionless tranport: UDP

UDP: User Datagram Protocol

• 아무것도 하지 않는 transport protocol
• data가 중간에 없어질 수도 있고, 순서가 뒤바뀔 수도 있다.
• connectionless
  • UDP sender와 receiver간의 handshaking 과정이 없다.
  • 각각의 UDP segment들이 따로따로 처리가 된다.
• UDP Use
  • streaming 서비스를 하는 멀티미디어 앱
  • DNS
  • SNMP → sample network management protocol

UDP: segment header

• 소스 포트 넘버, 목적지 포트 넘버, UDP segment의 길이. checksum, data가 들어가게 된다.

UDP가 왜 필요할까?

• connection을 하는 시간이 절약된다.
• connection state를 유지할 필요가 없다. → 더 단순하다.
• header의 사이즈가 매우 작다.
• congestion control을 하지 않아도된다. → 그냥 최대한 빨리 데이터를 던지기만 하면 된다.
  • congestion control - 네트워크의 혼잡 상태를 파악하고 그 상태를 해결하기 위해 데이터 전송을 제어하는 것을 이야기한다.

UDP checksum

• 보내진 segment에 error가 있었음을 탐지하기 위해서 사용한다.

sender

• header 필드를 포함한 segment의 컨텐츠를 16 비트의 정수의 시퀀스로 다룬다.
• checksum: 바뀐 값들의 합
• sender는 UDP checksum field에 checksum 값을 담아서 보낸다.

receiver

• 받은 segment의 checksum을 확인한다.
• 계산된 checksum이 checksum 필드의 값과 같은 지를 판단한다.
  • 같으면 error가 없음
  • 다르면 error가 있음

 

Reliable data transfer

rdt_send()

• application layer에서 불리며, transport layer에 data를 던져준다.

udt_send()

• packet을 다른 channel로 넘긴다.

rdt_rcv()

• packet을 받을 때 호출이된다.

deliver_data()

• transport layer에서 불리며, data를 application layer로 올린다.

 

rdt 1.0: reliable transfer over a reliable channel

• bit error도 없고, packet의 유실도 없다고 가정한다.

•  

rdt 2.0: channel with bit errors

• checksum을 활용하여 bit error를 확인한다.
  • 확인해서 error가 없으면 ACKs, 있으면 NAKs를 던진다.
  • 만약 NAKs를 sender가 받으면 다시 패킷을 receiver에게 보낸다.
• 패킷을 보낼 때 (data, checksum)을 보낸다.

더 나아진 점

• 에러 검출
• ACK, NAK를 활용한 에러 검출

문제점

• 만약 feedback인 ACK, NAK가 문제가 생기면?

 

rdt 2.1: sender, handles garbled ACK/NAKs

• sender가 feeback인 NAK, ACK를 제대로 받지 못하면 패킷을 다시 보낸다.
• sender는 각각의 패킷에 시퀀스 #를 붙힌다.
  • 시퀀스 #를 통해서 receiver가 전에 받았던 것인지 판단할 수 있다.
  • 만약 전에 받았던 것이라면 receiver는 해당 패킷을 무시한다.
• 패킷을 보낼 때 (sequence number, data, checksum)을 보낸다.(sender → receiver)
• receiver → sender (ACK or NAK, checksum) 을 보낸다.
• stop and wait
  • sender는 하나의 패킷을 보내고, receiver의 response를 기다린다.
• states는 두 개면 충분하다.

 

rdt2.2: a NAK-free protocol

• rdt2.1과 동일하지만, NAK를 활용하지 않고 ACKs만을 활용한다.
  • receiver는 패킷을 보낼 때 sequence number를 같이 넣어서 보내야된다.
  • sender에게 동일한 ACK가 오게 된다면, sender는 다시 패킷을 재전송하게 된다.

예시

• Sender
  • sequence number, data, checksum을 담은 packet을 receiver에게 보낸다.
  • 0에대한 패킷을 기다리고 있을 때, 다시 0에 관한 패킷을 전송해야되는 경우
    • receiver에게 받은 ACK가 부서졌거나, ACK인데 sequence가 1을 받은 경우 ( sender는 0에대한 packet을 보냈는데!)
  • 그 다음으로 넘어갈 경우 sequence 1로 넘어갈 경우
    • receiver에게 ACK를 받았는데, 부서지지 않았고, sequence가 0인 경우!..
• Receiver
  • 1을 기다리고 있는 데, sender에게 1에 관한 packet을 받았을 경우
    • data를 뽑아서 app layer로 넘긴다.
    • sender에게 (ACK1, checksum)을 담아서 보낸다.
  • 0을 기다리고 있는데
    • sender에게 받은 packet이 불완전하거나, 1에 관한 packet을 받았을 경우
      • 그전에 보냈던 다시 1을 받았다는 ACK를 보낸다.

문제점

• 그러나, 이렇게 보내는 packet들에도 loss가 생길 수 있다.

rdt3.0: channels with errors and loss

• 그전의 문제점은 ACK나 sequence등과 관련된 loss가 생길 수 있다.
  • sender가 ACK에 관해서 기다리는 time out value를 설정한다.
  • 만약 해당 기간안에 ACK가 들어오지 않는다면, 패킷을 다시 보낸다.
  • countdown timer가 추가되었다.

예시

• sender
  • (sequence(0), data, checksum) packet을 receiver에게 보낸다.
  • 그리고 타이머를 시작한다.
  • 만약, 받은 packet이 부서졌거나, 1에 관한 ACK를 받았다면?
    • 아무것도 하지 않는다. → time out 될 때까지 기다리는 것
  • 타임 아웃이 생겼다면?
    • 패킷을 다시 보낸다.
    • 그리고 타이머를 다시 시작한다.
  • 만약, 받은 ACK가 0이라면?(+ 온전하고)
    • 정상적인 response이므로 timer를 종료한다.
  • 만약 app-layer에게 data를 받길 기다리는 데 packet을 받으면 무시한다.
  • app-layer에게 1 받고, (sequence(1), data, checksum) packet을 receiver에게 보낸다.
  • 그리고 타이머를 시작한다.
  • 만약 packet이 부서졌거나, 0에 관한 ACK를 받았다면?
    • 아무것도 하지 않는다.
  • timeout이 일어났다면?
    • 패킷을 다시 보내고, timer를 시작한다.
  • 만약 1에관한 ACK를 정상적으로 받았으면, 타이머를 종료한다.
• packet loss
  • 만약 sender에게 보낸 패킷이 없어졌다면, receiver는 아무것도 못한다.
  • time out 이 일어나면 sender는 해당 패킷을 다시 보낸다.
• ACK loss
  • 만약, receiver에게 보낸 ACK가 중간에 유실이 된다면
  • sender는 time out이 되고, 다시 똑같은 패킷을 보내게 된다. 그러면 receiver는 해당 패킷이 중복되었음을 알게되고, ACK를 다시 보내게 된다.
• premature timeout/delayed ACK
  • ACK를 받기 전에 time out이 일어나게 된다면?
  • 일단, 경우에 따라서 다르긴 하지만 두 가지만 기억하자!
    • sender는 time out이 될 때까지 기다린다. (내가 기다리는 정보가 아닌 것이 들어오면 무시한다.)
    • receiver는 내가 원하는 packet이 들어오지 않는다면, 해당 packet에 대한 ACK를 보내준다.

Performance of rdt3.0

• rdt3.0은 정확하지만, 퍼포먼스가 그렇게 좋지는 못하다.
  • Utilization = (L/R) / (RTT + L/R)
    • RTT = Propagation delay * 2
    • L/R → transmission delay

rdt3.0: stop-and-wait operation

• Utilization = (L/R) / (RTT + L/R)
  • RTT = Propagation delay * 2
  • L/R → transmission delay

 

즉 정리해보자면

- rdt 1.0: loss가 없다. 따라서 그냥 보내고 받기만 하면 된다.

- rdt 2.0: loss가 있을 수 있기에 NAKs와 ACKs를 활용한다. 그리고 loss 판단은 sender -> receiver로 갈 때 (data, checksum)을 넘기기에, checksum을 활용해서 corrupt이 되었는 지 아닌 지를 판단한다.

- rdt 2.1: ACK와 NAKs가 제대로 들어오지 않을 수 있다. 따라서 sender는 보낼 때 sequence를 같이 넣어서 패킷을 보낸다. sender는 (sequence, data, checksum)을 보내고, receiver는 자신에게 해당되는 sequence를 받을 때만 ACK를 던진다. 만약 corrupt된 패킷이 receiver에게 왔다면, receiver는 NAK를, 만약 맞지 않는 sequence가 왔다면, 그 전 패킷을 ACK로 보낸다. sender는 그저, ACK, NAK로만 판단을 해서 패킷을 보낸다.

- rdt 2.2: NAK를 활용하지 않는다. 대신에 sender도 ACK를 받을 때, sequence 값을 통해서 값을 판단하게 된다. sender는 (sequence, data, checksum)을 보내게 되고, receiver는 자신이 기다리고 있는 sequence에 맞는 패킷이 들어오면, 해당 sequence를 담은 ACK를 보내게된다. 만약 sequence가 맞지 않거나, corrupt된 패킷이 들어온다면, 다시 전 단계의 패킷의 ACK 패킷을 던지게 된다. sender도 자신이 기다리고 있는 ACK가 들어와야지, 다음 단계 넘어가고, 만약 자신이 기다리고 있는 sequence가 아닌 패킷이 들어오게 된다면, 그 전 단계의 패킷을 보내게 된다.

- rdt 3.0: 그러나, 패킷 ACK 패킷 자체가 누락이 될 수가 있다. 따라서 timeout 값을 설정할 수 있다. seneder는 (sequence, data, checksum)을 담은 패킷을 보낸다. 그리고 timer를 시작한다. 만약 corrupt된 ACK나, 나의 sequence에 맞지 않는 ACK가 들어오게 된다면, 그냥 아무것도 하지 않고 기다리다가, timeout이 될 경우, 다시 패킷을 보내게 된다. 만약 자신의 sequence에 맞는 ACK가 들어오게 된다면 그러면 timer를 멈추게 된다. 그리고, app layer에게 data를 받길 기다린다. 만약 이 시기에 패킷이 들어온다면 그냥 무시한다. 만약 receiver는 이미 처리한 packet이 들어오게 된다면, 그 전의 ACK를 다시 보내게 된다. 

 

 

 

Pipelined protocols

pipelining: ACK 패킷을 받기 전에 sender가 여러 개의 패킷을 보내는 것

→ Utilization을 높힐 수 있다.

• sequence number가 0, 1 뿐만 아니라 더 늘어나야된다.
• sender나 receiver의 buffer가 필요하다.

두 가지의 protocol이 존재한다.

• go-Back-N
  • N개의 unacked pakcet를 가질 수 있다. → 응답받지 않은 패킷이 N개여도 된다.
  • Culmulative Ack
    • receiver는 만약 받은 패킷들의 갭이 존재하면 들어오는 패킷을 버린다.
  • sender는 가장 오래된 unacked packet에대해서 timer를 가지고 있다.
    • 만약 timer가 끝나면, Ack를 못 받은 패킷부터 차례대로 packet을 다시 보낸다.
• selective repeat
  • N개의 unacked pakcet를 가질 수 있다. → 응답받지 않은 패킷이 N개여도 된다.
  • receiver는 중간의 갭이 있어도 일단 ACK를 던진다.
  • sender는 각각의 unacked packet에대해서 timer를 가지고 있다.
    • 만약 timer가 끝나면, 해당 패킷만을 다시 보낸다.

 

Go-Back-N: sender

• Packet header에 k-bit의 시퀀스 넘버가 들어간다.
• window
  • N개의 (unacked + 아직 보내지 않은 패킷)들이 들어가있다.
• send_base: 보냈지만, 아직 ack가 되지 않은 것들
• nextseqnum: 보낼 수 있지만, 아직 보내지 않은 것들
• sender는 가장 오래된 unacked packet에대해서 timer를 가지고 있다.
  • 만약 timer가 끝나면, Ack를 못 받은 패킷부터 차례대로 packet을 다시 보낸다.

 

GBN: sender extended FSM

• sender는 receiver에게 (sequence, data, checksum)을 담아서 보낸다.
• 만약 timeout이 일어나게 된다면
  • base부터 nextseqnum-1까지의 패킷을 싹 다 보낸다.
  • 왜냐하면 culmulative ack이므로 receiver는 아무것도 받지 않았을 것이다!… 그래서 다시 싹 다 보내줘야된다.
• 만약 제대로된 ACK를 받았다면,
  • 받은 ACK sequence + 1을 베이스로한다.
  • 그리고 만약 base == nextseqnum이면 타이머를 멈춘다.
  • 만약 다르다면 타이머를 시작한다.
• 만약 제대로된 ACK가 아니라면 아무것도 하지 않는다.

 

GBN: receiver extended FSM

• 만약 기다리던 packet이 왔다면
  • 방금 받았던 (expectedseqNumber, ACK, checksum)을 sender에게 보낸다.
  • 그리고 expectedNumber +1한다.
• 만약 기다리던 Packet이 아니라면
  • 그 전에 보냈던 패킷을 다시 보낸다.

즉, 순서대로 패킷이 도착해야된다.

• ACK 패킷을 복제하여 여러 번 보낼 수 있다.
• expectedSeqNum만을 잘 기억하고 있으면 된다.

만약 순서대로 패킷이 도착하지 않는다면

• receiver의 buffer가 존재하지 않기에 무시한다.
• 순서대로 받은 ACK들 중에 sequence가 가장 높은 패킷을 재 전송한다.

 

 

Selective repeat

• Receiver는 각각의 패킷들을 다 받는다.
  • Receiver는 buffer를 가지고 있어서 안온게 오면 순서대로 app-layer에 올리게된다.
• Sender는 ACK를 받지 못한 패킷만을 다시 재 전송하다.
  • 각각의 unACKed 패킷에 대해서 타이머를 가지고 있다.

Selective repeat: dilema

• receiver가 sender 쪽을 보지 못하기 때문에 생기는 문제점이 있다.
• seq number(0, 1, 2, 3) = window size(3)이면 안된다.
• 그래서 sequence number ≥ window size *2 로 하는 것이 이상적이다.