UDP와 TCP

• 해당 기능을 제공하기 위해서 transfort 계층에서 제공하는 가장 기본적인 기능은 Multiplexing/De-Multiplexing
• 보내는 측에서는 여러 소켓에서 오는 메세지를 받아야하고
• 받는 측에서는 네트워크를 통해서 오는 메세지를 목적시 소켓으로 배달해줘야함

Connection-oriented demux (커넥션 지향 디멀티플렉싱)#

• 각 애플리케이션들은 도어소켓을 열고있고, 클라이언트가 접속하면 별도의 소켓을 열어서 소통
• Receiver에서 demux를 하기 위해 4가지 정보가 다 필요함

  • source IP address
  • source port number (특정 클라이언트를 위한 포트)
  • dest IP address
  • dest port number (도어소켓 포트번호)
• 서버쪽 어플리케이션은 자식 proccess를 fork해서 해당 포트만을 담당하도록 함

  • 혹은 threaded server를 통해서 이용할 수 도 있음

UPD: User Datagram Protocol#

• connectionless한 transfort

  • no handshaking
  • 각 UDP 세그먼트를 독립적으로 주고받음
• 네트워크계층에서 post delivery 이외의 추가적 기능을 제공하지 않음
• best effort 서비스를 제공함

  • best effort = 증권사가 팔 수 있는 한도(매도한도)까지 증권발행을 하는 형식. (출처: 네이버 백과사전)
  • 네트워크가 중간에 데이터가 소실되어도 UPD는 파악이 안되고 알려주지도 않음
  • 최선의 서비스를 제공
• UDP를 이용하는 어플리케이션

  • 멀티미디어 스트리밍 어플리케이션 (유실에 관대함, 지연에 예민함)
  • DNS
  • SNMP (네트워크 관리 프로토콜)

    • 네트워트 토폴로지 같이 그룹에 묶인 여러 장치들이 중앙의 장치에게 정기적으로 자신의 상태를 REPORT함
• reliable transfer over UDP = 신뢰성 있게 UDP 보내기

  • 아이러니 하게도 데이터의 무결성이 매우 중요한 어플리케이션의 경우 UDP를 이용하는 경우가 있음

    • 어플리케이션 스스로가 신뢰도를 체크하기 위해서
    • 에러가 발생했을때 리커버 할수있는 방법을 가지고있기 때문에

UDP: segment header#

• 커넥션이 없기 때문에 오버헤드가 적음
• 단순함 = sender나 receiver에 대한 커넥션 정보가 없음
• UDP 세그먼트의 헤더 사이즈가 작음

  • UDP는 멀티플렉싱/디멀티플렉싱만 하기때문에 그 정보만 있으면 됨
• 혼잡도를 컨트롤하지 않음 = 때문에 어플리케이션이 생성하는 속도로 데이터를 내보낼 수 있게됨

UDP checksum#

• Sending UDP는 헤더를 포함한 세그먼트를 16bit integer 의 연속으로 인지함 ⇒ 이걸 다 더함

  • 이걸 checksum 필드에 넣어주게 됨
• Recevier 측도 동일한 방법으로 더함 그게 Sender측 checksum과 일치하는지 확인함

  • 일치하면 데이터에 문제가 생기지 않았다고 가정할 수 있음
  • 일치하지 않으면? 오는동안 데이터 변형이 발생됨

    • 아예 다르면 슬그머니 드랍함
• 아주 단순한 방식의 checksum 방식이기 때문에 모든 에러를 검출할 수는 없음

principles of reliable data transfer#

• Checksum

  • Recevier가 세그먼트를 받았을 때 오류를 판단할 수 있어야 한다
• Acknowledgement

  • 일반적으로 Sender에게 패킷을 잘 받았다는것을 알려주기 위함
  • 해당 응답은 individual 혹은 cumulative일 수도 있음
• Negative acknowledgement

  • Sender에게 어떤 패킷이 잘못됬다 라는것을 알려주기 위함
  • 통하지 않을 수도 있음 = Recevier가 일단 패킷을 받는 경우엔 동작하지만 drop될 경우 받을 수 없음
• Timer

  • Sender측에서 데이터를 보냈는데 Ack/Nack이 오지 않을 경우 네트워크에서 drop되었다 생각하고 재전송을 함
  • 근데 불필요한 재전송이 발생할 수도 있음 = Recevier는 잘 받고 Ack/Nack을 보냈는데도 응답이 없어질 수도 있음
• Sequence number

  • 타이머가 보낸걸 또 보낼수도 있기 때문에 시퀀스 넘버가 필요함
• Window, pipelining

  • 센더와 리시버 사이의 파이프가 있다고 가정 다만 한개의 파이프 라인을 통해서 패킷을 주고받을 경우에 하나를 보내고 하나를 받고 하면 파이프에 하나의 패킷만이 왔다갔다함
  • 파이프의 효율성을 높이기 위한 작업이 파이프라이닝
  • Ack을 받지않은 상태에서 집어넣을 수 있는 최대 데이터량을 윈도우라 함

Connection-oriented transport: TCP#

Reliable, in-order byte stream#

• TCP는 자신이 전송하는 데이터를 byte stream으로 봄
• TCP는 일단 어플레이션에서 내려오는 데이터를 자신의 버퍼에 담음

  • 해당 버퍼에서 데이터를 뽑을때 순서/혼잡도에 맞게 데이터를 뽑아옴
  • 유저의 메세지 바운더리는 인식하지 않고 바이트의 연속으로 인식함

Point to Point transfer#

• 단 멀티캐스팅의 경우 Recevier가 여럿일 수 있음

Full duplex data#

Pipelined#

TCP Segment structure#

• UPD와 마찬가지로 크게 헤더와 페이로드로 나누어짐
• header에서 options를 제외한 나머지 헤더는 모두 고정

  • TCP의 총 헤더 길이는 가변적임!
  • 때문에 header length 필드가 필요함
• 고정헤더의 길이는 20byte 크기를 가짐 (32 bit * 5 line)
• process to precess 를 제공하기 위한 source/dest port를 가짐
• receive window는 flow control을 위한 필드임

  • 리시버가 받을 수 있는 버퍼사이즈임
• U, A, P, R, S, F = 6개의 flag 비트

  • A(Acknowledgement와 연관된 필드) = Acknowledgement에 너에대한 정보가 포함되었다는 의미
  • connection estab

    • R(커넥션 리셋)
    • S(커넥션을 맺자는 요청을 보낼때)
    • F(커넥션을 끝낼때)
  • U, P ⇒ 두 플레그는 실제로는 활용되지 않고 잇음

    • P : Push data now

      • 데이터를 내려보내며 소켓 인터페이스에게 해당 데이터를 푸시해달라고 요청이 가능하게 하는 필드
        ⇒ 그러면 모든 버퍼에 있는 데이터와 지금온 데이터 모두를 즉시 내보내야 한다.
        ⇒ 해당 필드가 활성화 되어오면 리시버는 자신의 모든 버퍼를 플러쉬함
    • U : Urgent data

      • 소켓 인터페이스에 Urgent 한 데이터라는걸 표시해주는 플래그
      • P와 마찬가지로 모든 버퍼를 쏴버림
      • Urgent data pointer 필드에 Urgent한 데이터가 어디있는지 표시해서 보내줌

TCP seq, numbers, ACKs#

• sequence numbers

  • 세그먼트 페이로드에 실려있는 첫번째 바이트의 번호
• acknowledgements

  • 누적 ACK을 사용함
  • 다음에 받을 seq를 기대한다!는 의미

TCP round trip time, timeout#

• RTT를 너무 짧게 잡으면? ACK이 오는 중임에도 불구하고 데이터를 다시 보냄
• RTT를 너무 길게 잡으면? 타이머가 너무 늦게 알아게됨
• ACK이 들어올때마다 round trip time의 샘플을 구하게 됨 ⇒ 다음번 RTT의 시간을 예측

  • 샘플 하나로는 예상하지 못함
  • 때문에 평균을 내는데, 이때 재전송된 RTT의 시간은 빼고 구함
• 평균을 이용함에도 불구하고 실제와 차이가 많이남

  • EstimatedRTT에 Safety margin을 더함