2. Socket Programming

발표자: 김성연

chevron-right 💫hashtag
  • Socket: 애플리케이션과 네트워크 사이의 인터페이스

  • sock_stream 타입: TCP, reliable한 전송, 순서가 보장

  • sock_dgram 타입: UDP, reliable X, 순서 보장X

  • Reliable한 통신: 메세지가 유실없이 전달되도록 하는 것

  • 유한 상태 기계(Finite State Machines, FSM): 유한한 State가 존재하면서 특정 상황에 어떤 이벤트가 발생하냐에 따라 State와 Output을 변화시키는 시스템이다.

Principles of reliable data transfer

각 레이어는 상위 레이어에게 서비스를 전달하고, 하위 레이어로부터 서비스를 제공

  • TCP: Reliable한 통신 가능 → 애플리케이션에서 내려오는 데이터가 유실 없이 통신 가능

  • UDP: MultiplexingError checking(에러가 있으면 올려보내지 않음) 제공

전달 과정에서 어떤 라우터의 큐가 가득 차 있으면 유실이 발생할 수 있기 때문에 실제적인 네트워크는 unreliable

  • Unreliable Channel는 패킷 에러(Packet error / Message error) 패킷 유실(Packet loss / Message loss)을 일으킨다.

  • 이 문제들을 해결한다면 reliable한 통신을 제공할 수 있다.

RDT(Reliable Data Transfer) Protocol

하위 계층에서 상위 계층에 데이터를 전송할 때 전송된 데이터가 손상되거나 손실되지 않게 보장하는 개념이다. Transport Layer에서 신뢰성 있는 데이터 교환을 위해 RDT 프로토콜을 이용한다. 신뢰 가능한 환경에서의 rdt 1.0 모델과, 신뢰 불가능한 환경에서의 rdt 3.0 모델이 있다.

  • 패킷을 1개씩 전송한다.

  • 리시버가 받았는지 확인한다.

  • 다음 패킷을 전송한다.

  • 위 과정으로 높은 신뢰성을 가진다.

RDT Protocol

RDT1.0: Data Transfer over a Perfect Channel

  • 완전히 신뢰적인 채널 상에서의 데이터 전송 → 즉, 하위 채널을 완벽히 신뢰할 수 있다고 가정

  • 비현실적

RDT 1.0 FSM
  • Sender(rdt_send)

    • 상위 계층의 데이터 수신

    • 데이터를 포함한 패킷을 생성 → make_pkt(Data)

    • 데이터를 패킷에 송신 → udt_send(packet)

  • Receiver(rdt_rcv)

    • 하위의 채널로부터 패킷을 수신

    • 패킷에서 데이터 추출 → extract(packet_data)

    • 데이터를 상위 계층으로 전달 → deliver_data(data)

RDT2.0: channel with packet errors (no loss)

  • 에러가 발생할 가능성을 고려 (유실은 고려하지 않음)

  • 송신자는 수신 확인하기 전까지 새로운 데이터를 전달하지 않기 때문에 전송-후-대기(stop-and-wait)프로토콜 이라고도 한다.

오류 처리를 위해 요구되는 3가지 기능들은 아래와 같다.

  • Error Detection(오류 검출): Add checksum bits → 패킷(헤더)에 부가정보(에러 유무 판단)를 추가하여 전송

  • Feedback(수신자 피드백, receiver → sender)

    • Acknowledgements(ACKs , 긍정 ): receiver explicitly tells sender that packet received correctly

    • Negative acknowledgements(NAKs , 부정 ): receiver explicitly tells sender that packet had errors

  • Retransmission(재전송): sender retransmits packet on receipt of NAK

RDT 2.0 FSM

  • Sender: 파일 전송 후 수신자의 피드백에 따라 행위

    • ACK(Error X): 상위 계층에서 데이터를 기다리는 상태로 돌아감

    • NAK(Error O): 데이터 재전송 후 피드백을 기다림

  • Receiver

    • 패킷 손상 여부에 따라 응답 한다.

RDT2.1: sender, handles garbled ACK/NAKs

피드백(ACK, NCK) 의 손상 가능성 을 배제한 RDT2.0의 단점을 보완

순서번호(Sequence Number)를 부여 → 해당 패킷이 새로운 데이터를 전송하는지, 재전송하는 것인지를 구분할 수 있는번호를 추가하는 것 (중복 구분 가능)

RDT2.1 의 문제

circle-info

퀴즈🧐 Sequence Number를 순차적으로 부여하면 필드 크기도 커지므로 헤더의 크기도 커져 부담스러워진다. 그렇다면 Sequence Number의 필드크기를 최소화할 수 있는 방법 은 무엇일까?

RDT2.1 예

  • Sender

    • Sequence Number를 패킷에 추가한다.

    • Error Check

    • NAK이면 재전송한다.

  • Receiver

    • 패킷의 중복 여부를 판별 한다.

    • 패킷에 에러가 있으면 NAK을 보내고, 그게 아니라면 ACK을 보낸다.

RDT2.2: a NAK-free protocol

NAKs을 사용하지 않고 ACKs(+ Seq Num)만 사용하는 방식

  • 수신자는 가장 마지막에 받은 Seq Num을 리턴한다.

  • 송신자는 ACKs을 통해 중복 여부를 판단한다.

RDT3.0: channel with loss & packet errors

Error & Loss를 모두 고려

  • Timer: 데이터가 유실되면 피드백이 없을 것이기 때문에 타이머를 이용

    • 시간은 Reasonable"하게 설정 → Trade off

    • 짧은 시간: 빠른 회복 가능, 중복 패킷 발생으로 네트워크 오버 헤드 가능성 높음

    • 긴 시간: 유실 극복이 느림, 오버헤드 가능성 낮음

  • 만약 패킷 전송이 늦어지면 중복으로 재전송 되겠지만 Seq Num을 사용하기 때문에 이미 처리 됨

(a) loss 미발생 (b) 패킷 소실

(c) ACK 소실 (d) 성급한 timeout

정리

  • Unreliable channel은 Packet errorPacket loss를 발생시킨다.

  • Packet error 대처 방법: error detection, feedback, retransmission, sequence#

  • Packet loss 대처 방법: timeout

참고 자료

Last updated