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

Overview

1. Transport services and Protocols

• 서로 다른 호스트들의 실행중인 앱 프로세스 간의
  logical communication을 제공한다
• Transport protocols in end sides
  • Sender : 메시지를 부분(segments)로 잘라서 network layer에게 넘겨줌
  • Receiver : 흩어져있는 조각들을 모아 메시지로 만들어서 app layer에 넘겨줌

Internet Transport-Layer Protocols

1. TCP
   • Reliable, in-order delivery
   • 혼잡 제어 (Congestion control)
   • 흐름 제어 (Flow control)
   • Connecition setup 필요
2. UDP
   • Unreliable, unordered delivery
   • "best-effort" IP 의 기능 확장이 없다

둘 다

• 지연에 대한 보장 X (No delay guarantees)
• 대역폭 보장 X (No bandwidth guarantees)

2. Multiplexing and demultiplexing

Multiplexing at sender

: 여러 소켓에서 data를 관리하고, transport header을 추가한다
이 때 추가한 헤더를 receiver에서 demultiplexing 하는데 사용한다.

Demultiplexing at receiver

: 헤더의 정보를 활용해서 적절한 소켓으로 segments를 전달한다.

Demultiplexing 의 작동 방법

1. 호스트는 IP datagrams을 받는다.
   • 각 datagram은 source IP와 dest IP 주소, 포트넘버를 가지고 있다
   • 또 그들은 하나의 transport-layer segment를 가지고 있다
2. 호스트는 IP 주소와 포트 넘버를 이용해서 이 segment를 적절한 소켓으로 보내준다.

Connectionless Demultiplexing // 연결 없는 디멀티플렉싱 (UDP)

Recall

• 만들어진 소켓은 호스트의 로컬 포트 넘버를 가지고 있다.
  DatagramSocket mySocket1 = new DatagramSocket(12534);
• datagram을 만들어서 UDP 소켓으로 보내려면 Destination IP 주소와 포트 넘버를 지정해줘야 함.
• 호스트가 UDP segment를 받으면 일단 segment에 있는 목적 포트 넘버를 체크하고
• UDP segment를 그 포트 넘버를 가진 소켓으로 보낸다

-> 만약 IP datagram이 같은 목적 포트 넘버를 가지고 있다면 source IP address나 source port #가 다르더라도 같은 소켓에 들어간다.

Connection-Oriented Demux // 연결 지향 디먹스 (TCP)

1. TCP 소켓은 "source IP address, source port #, dest IP address, dest port #" 로 구별된다
2. demux : receiver는 이 4개의 값을 적절한 소켓을 찾는데 전! 부 ! 이용한다!
3. 서버 호스트는 동시에 여러개의 TCP 소켓을 감당할 수 있다.
4. 웹 서버는 연결하는 클라이언트에 따라서 다른 소켓을 가진다.
   (non-persistent HTTP는 request마다 소켓이 다르다)

목적지가 같아도 source가 다르면 다른 socket으로 감

여러개의 소켓을 동시에 처리하기 위한 threaded server ! (multiple process 사용)

UDP : User Datagram Protocol [RFC 768]

1. Protocol

• 꾸밈 없음, 그저 맨 뼈 (No frills, bare bones)
  쓸데 없는 기능 싹 빼고 진짜 필요한 것만 있는 Internet Transport Protocol
• "Best effort" service
  • UDP segments는 lost, delivered out-of-order to app
• Connectionless
  • sender와 receiver간의 Handshaking 과정이 없음
  • 각 UDP segment는 서로서로에게 독립적으로 관리된다.
• UDP 사용하는 것들 : Streaming multimedia apps (손실 허용,속도에 민감) , DNS, SNMP 등...
• UDP로 신뢰성 있는 전송을 하고싶다면?
  • application layer에서 신뢰성을 줄 수 있다.
  • application-specific error recovery. (특정 application에 한한 에러 발견..)

UDP Segment Header

* length : Header를 포함한 UDP segment 전체의 길이(bytes)

UDP 왜 씀?

1. 연결 설정이 필요 없음 (여기서 딜레이 감소)
2. 간단하다. sender과 receiver간의 연결 상태가 없다
3. 헤더의 크기가 작다
4. 혼잡 제어가 없다 : UDP는 원하는 만큼 빠르게 보낼 수 있다.

2. Checksum : for detect "error" in transmitted segment

• Sender
  1. header fields를 포함한 모든 segment content를 16-bit 정수로 취급한다
  2. Checksum : segment contents를 더한 값(보수 합)
  3. sender는 이 checksum 값을 UDP checksum field에 넣어서 보낸다.
• Receiver
  1. 받은 segment의 checksum을 계산을 한다
  2. 계산한 checksum이 받은 checksum field 값과 같은지를 확인한다.
  3. 같다면 오류가 없다, 다르다면 오류가 있다. (물론 같다고 에러가 100퍼센트 없는건 아님)

receiver는 맨 위의 두 segment를 정수화 한 것과 checksum 값을 받게 된다.
두 segment를 더한 뒤 carryout되는 숫자 1은 sum result에 더한다
그 더한 값과 checksum을 더했을 때 111...1 이 나오면 성공적으로 받은 것!

Reliable data Transfer

Reliable data Transfer의 원리

• application, transport, link 계층의 중요성
  • 가장 중요한 networking topics TOP 10 중 하나!!
• application layer는 reliable channel로 서비스를 제공하지만,
  transport layer는 unreliable channel임.
  따라서 이 갭을 함수들로 채워줘야함
• 이렇게 채널이 unreliable하다는 특성이 reliable data transfer protocol(rdt)의 복잡성을 결정하게 됨..

Getting Started

• Sender
  1. rdt_send() : app에 의해 불려진다. data를 전송하기 위해 아래로 넘겨준다.
  2. udt_send() : rdt에 의해 불려진다. unreliable channel을 통해 패킷을 receiver한테 보낸다.
• Receiver
  1. rdt_rcv() : 패킷이 rcv-side에 도착했을 때 불려진다.
  2. deliver_data() : rdt에 의해서 불려진다. 데이터를 위 계층로 올리려 한다.
• reliable data transfer protocol (rdt)는 sender와 receiver 양 쪽을 점차 발전시켜 나감!
• 단방향 데이터 전송만 생각한다. (그러나 control info는 양쪽 방향으로 흐른다!)
• sender와 receiver를 명시하기 위해서 finite state machines (FSM)을 사용할 것이다!

어떤 액션이 있을 때 state가 변하거나 유지되거나 한다.

1. rdt1.0 : Reliable Transfer over a Errorless channel(Reliable Channel)

• 이 channel은 완벽하게 reliable 할 것을 가정한다. (No bit errors, no loss of packets)

• sender는 계속 기다리다가 rdt_send(data)가 불리면 packet을 만들어서 udt_send(packet)으로 receiver한테 패킷을 보낸다.
• receiver는 계속 기다리다가 rdt_rcv(packet)이 불리면 패킷이 도착했다는 것이므로 packet을 분해해서 data를 뽑아서 deliver_data(data)로 상위 계층에게 전달한다.

2. rdt2.0: Channel with Bit errors

1. 이 channel은 패킷의 bits가 뒤집힐 수 있는 곳!
   • 우리는 이 bit errors을 찾기 위해 checksum을 쓸 것!
2. 어떻게 ERROR를 recover할건데?
   • Acknowledgements (ACKs) : sender에게 pkt 잘 받았다고 대답해줌
   • Negative acknowledgements (NAKs) : sender에게 pkt에 문제가 있다고 말해줌
   • sender는 NAK를 받으면 다시 보낸다

1. sender는 위에서의 call을 기다리다가 rdt_send(data)가 호출되면 udt_send(sndpkt)을 보낸다.

2. 그리고 ACK 또는 NCK를 기다리는 상태로 전환된다.
.

3. receiver는 rdt_rcv(rcvpkt)으로 패킷을 받고 notcorrupt(rcvpkt)으로 패킷에 이상이 없는지 확인한다.

4. 이상이 있다면 udt_send로 NAK를 반환하고, 이상이 없다면 data를 deliver_data(data)로 위로 올린다음에 ACK를 보낸다.

.

5. sender는 rdt_rcv(rcvpkt)으로 어떤 패킷이 왔음을 확인하고 만약 이 패킷이 NAK이면 문제가 있는거니까 다시 udt_send(sndpkt)해준다.

6. 만약 NAK가 아니라 ACK라면 정상적으로 간거니까 다시 대기 상태로 전환된다.

2-1. rdt2.1 : receiver, Handles Garbled ACK/NAKs

Fatal Flaw!!!!

만약 ACK/NAK가 중간에 사라지면 ????

• sender는 대체 이 receiver한테 무슨 일이 벌어진 건지 알 수 없음 !!
• 그냥 다시 보내?
  • 만약 receiver가 처음 보낸 것과 다시 보낸 것 두개를 다 받으면 이게 재전송된 패킷인지, 아니면 동일한 내용을 가진 새로운 패킷인지 알 수가 없음
  • 이렇게 중복 위험성 때문에 무조건 retransmit 할 수 없음!!

Handling Duplicates

1. Sender가 ACK/NAK를 받지 못할 경우 다시 패킷을 재전송 한다.
2. 대신 이 때 이 패킷에 sequence number를 추가한다!
3. receiver는 이 seq. no.를 기준으로 중복된 패킷을 없애버린다.

stop and wait : sender가 하나의 패킷을 보내면 receiver의 response를 기다린다.

복잡해보이지만 이전것과 달라진 것은 Sequence number를 검사한다는 것!
seq0 패킷을 받았을 때 1을 기다리는 상태였다면 데이터를 저장하지 않고 ACK를 다시 보내준다. (이미 받아서 ACK 보냈었는데 그 ACK가 실종된거니까!)
seq0 패킷을 받았을 때 원래대로 0을 기다리는 상태였다면 데이터를 위로 전송해주고 1을 대기하는 상태로 전환한다.

seq1 패킷도 마찬가지!

Discussion

• Sender

1. 패킷에 seq #가 추가되었음
2. 근데 0, 1이면 충분해??? 왜?
3. 왜냐면 확인해야 할 것은 ACK/NAK가 잘 갔는지 안갔는지니까
4. sender는 예상 패킷이 0일지 1일지만 기억하면 됨

• Receiver

1. 수신된 패킷이 중복인지 아닌지 확인한다
   • state가 가리키는 0또는 1은 예상 패킷의 seq #
2. 참고로 receiver는 마지막 ACK/NAK가 sender에게 잘 도착했는지 알 수 없다.

2-2. rdt2.2 : a NAK-free Protocol

• 기능적으로는 2.1과 같은데 이건 NAK 없이 ACK만 사용함
• NAK 대신에, receiver는 마지막 패킷이 잘 도착했는지에 대한 ACK 응답만 받음
  (ACK 패킷 안에는 seq # 가 포함되어야 겠쥬)
• Sender에게 ACK가 중복되면 NAK와 동일한 결과가 나온다.
  Sender는 현재 패킷을 다시 재전송한다.

1. 앞에까진 다 똑같다. 1 대기상태에 있을 때 receiver가 pkt seq1을 정상적으로 받으면 데이터를 저장하고 ACK1, chksum을 전송한다.
2. 만약 이미 보내서 0 대기상태에 왔는데 seq1 패킷을 받거나 패킷이 corrupt했으면 데이터가 중복됐거나 잘못됐다는 것이므로(ACK 실종) 다시 udt_send(sndpkt)을 보내준다. (sndpkt 은 ACK1, checksum 값)
   .
3. 패킷을 보내고 대기하고 있던 sender는 현재 ack0을 기다리고 있다.
4. ack1이 오면 ack0이 안 간거니까 ack0을 재전송한다. 또는 ack가 뭔가 잘못됐어도 다시 재전송한다.
5. 정상적인 ack0이 오면 ack1을 기다리는 상태로 이동한다.

3. rdt3.0: Channel with error and "loss"

New Assumption
채널에서 data와 ACKs 를 담는 패킷도 실종될 수 있지 않을까??

• checksum, seq.#, ACKs, retransmissions 이 도움은 되겠지만.. 완벽하진 못해!
• Sender/receiver는 ACK나 패킷 받을걸 기다리는데 아무것도 못 받을수도 있다.(예를 들면 버퍼 오버플로우로 인한 손실)

Approach : sender는 패킷을 보내고 ACK를 "reasonable"한 시간동안 기다려본다!

1. 만약 ACK가 그시간 안에 안오면 retransmits!
   • 이 시간을 세줄 countdown timer가 필요하다!
2. ACK나 패킷이 분실된게 아니라 단순히 지연된 걸 수도 있는데,
   • sender은 timeout에 의해서 중복되는 패킷을 retransmit 하지만 receiver는 seq.#로 중복을 방지할 수 있다!!
   • 따라서 Receiver는 무조건 ACKed를 받을 패킷의 seq.# 을 지정해서 보내야 한다.

1. sender는 rdt_rct(rcvpkt) 명령이 떨어지면 pkt0을 보내고 타이머를 키고 ACK0 을 기다리는 상태로 전환한다.
2. 만약 ACK0이 오고 정상적이라면 1을 보내라는 명령이 떨어질 때까지 대기하는 상태로 전환한다.
3. 만약 ACK가 1이 오거나 잘못되거나 하면 가만히 있는다.
4. 그러다 timeout이 되면 다시 패킷을 재전송하고 타이머를 킨다.
5. rdt_rcv(rcvpkt) 명령이 다시 떨어질 때까지 대기하다가 pkt1 에 대해서도 반복작업!

Stop-and-Wait Operation

• 패킷의 첫 번째 bit 가 전송 시작되는 시간 t = 0

      마지막                            t = L/R

• 마지막 bit까지 receiver에 도착하면 ACK를 전송함
• 이 때 마지막 bit를 보내고 ACK를 받을 때 까지의 시간 = RTT (Round Trip Time)
• ACK가 도착하고 다음 패킷을 전송할 때까지의 시간 t = RTT + L/R

ex. 1 Gbps link, 15ms props. delay, 8000 bit packet:

D_trans = L/R = 8000bits/10^9 bits/sec = 8 microsecs
U_sender : utilization (fraction of time sender busy sending) 이 뭘까...
= L/R / (RTT+ L/R) = 0.008/30.008 = 0.00027

RTT = 30 msec : 매 30초마다 1kB 패킷을 전송함
-> 이것은 1 Gbps link의 대역폭에서 33kB/sec을 보낼 수 있음을 의미함

rdt 3.0 은 정확한 대신 성능이 안좋다.