네트워크 - 3. Transport Layer (1)

cyw320712·2022년 4월 14일
1

3. Transport Layer


이번에도 역시 이번 챕터의 목표를 먼저 확인하자

  • transport layer services의 원리 이해:
    • multiplexing, demultiplexing
    • reliable data transfer
    • flow control
    • congestion control
  • internet transport layer protocol 이해
    • UDP: connectionless transport
    • TCP: connection-oriented reliable transport
    • TCP congestion control



Transport-layer service


Transport services and protocols

  • 서로 다른 host들에서 실행중인 application process들 사이에서의 logical communication 제공
    • Logical communication: network의 수많은 path를 고려하지 않고 end-to-end communication만 고려하는 것
  • transport protocol들은 end system에서 작동한다.
    • sender: application message를 segment로 쪼개고 network layer로 보낸다.
    • receiver: segment들을 재조립해서 message로 만든 후 application layer로 보낸다.
  • Internet application들에서 사용가능한 두 가지 transport protocol
    • TCP, UDP
  • 참고로 Network layer는 host간의 logical communication을 제공하고, transport layer는 process간의 logical communication을 제공한다.

Transport Layer Actions

Sender

  • Application layer에서 message를 전달 받음
  • segment header field들의 값을 결정함
  • segment를 생성
  • segment를 IP로 보냄

Recevier

  • IP로부터 segment를 받음
  • header 값을 확인
  • application-layer message를 추출함
  • socket을 통해 message를 app으로 demultiplex

Two principal Internet transport protocols

TCP: Transmission Control Protocol

  • reliable, in-order delivery
    • error 발생시 recovery 실시
    • out-of-order packet은 rearrange함.
  • Congestion control
    • network 상에서 buffer overflow가 발생하지 않도록 Sender는 보내는 속도를 조절하는 것.
  • Flow control
    • receiver 또한 받아온 packet을 transport layer의 buffer에 저장하는데, 이때 해당 버퍼에서 buffer overflow가 발생하지 않도록 sender가 보내는 속도를 조절함(throttle)

UDP: User Datagram Protocol

  • Unreliable, unordered delivery

    • Packet은 loss 될 수 있음
  • "Best effort": no-frills extension (불필요한 서비스가 없음)

  • 두 서비스 모두 delay guarantee나 bandwidth guarantee가 없다.

    • network나 link 자체에서 제공할 수 있는 거지, transport layer가 제공하는 것이 아님



Multiplexing and demultiplexing


  • 두 작업 모두 transport layer에서 발생한다. (다른 layer에서도 발생하나, 여기서는 transport layer에서의 것을 다룬다.)
  • Multiplexing은 sender측에서 여러 Socket에서 오는 data들에 transport header를 추가해서 packet으로 보내는 작업
  • Demultiplexing은 receiver가 해당 segment의 header 정보를 이용해 적절한 socket으로 보내는 작업이다.
    • Port 번호를 통해 Data를 목적 process에게 전달하는 작업

Demultiplexing

  • Host가 IP datagram을 받음
    • 각 datagram은 source IP 주소와 destination IP 주소를 가짐
    • 각 datagram은 transport-layer segment를 운반
    • 각 segment는 demultiplexing을 위해 source,destination port number를 가지고 있음
      • TCP/UDP 둘다
  • Host는 IP 주소와 port번호를 사용해서 segment를 적절한 socket에 보낸다.

UDP에서의 demultiplexing

  • Socket을 만들 때 반드시 host-local port번호를 명시해야 한다.
    ex) DatagramSocket javaSocket = new DatagramSocket(12345);
  • UDP socket에 넣을 datagram을 만들 때 destination IP 주소와 포트 번호를 명시해야 한다.
    • 심지어 모든 packet에 붙여야 함.. (connection이 없으니까..)
    • header로 추가됨
  • Host가 UDP segment를 받으면 segmetn의 destination port 번호를 확인한다.
    • demultiplexing을 위해 오직 destination port 번호만 사용한다
    • 해당 port 번호의 socket에 UDP segment를 전달한다.
    • IP는 이미 Host를 가릴 때 사용했기 때문에 여기선 상관 x (한 host 안에선 다 같은 IP)
  • 여기서 가장 중요한 점은 Source IP 주소나 port가 다르더라도, destination port가 같으면 같은 socket에 연결된다는 것 이다.
  • 1대 다 통신이 가능함. (하나의 socket이 여러 process와 연결될 수 있다..)

TCP에서의 demultiplexing

  • TCP socket은 4가지 tuple들에 의해서 구분된다. (Source IP, port / Destination IP, port)
    • demux: receiver는 segment를 올바른 socket에 연결시키기 위해서 4가지 정보를 모두 사용한다.
    • server는 동시에 여러 TCP socket을 지원할 수 있음.
      • each socket은 그것의 4-tuple들에 의해서 식별됨
      • 각 socket은 서로 다른 client 하나씩 연결됨
      • socket은 1대 1 통신만 가능
    • 아래 그림에서 destination ip는 B로, port는 80으로 같지만, source IP나 port번호가 다르기 때문에 서로 다른 socket들로 demultiplex됨

Demultiplexing 요약

  • Multiplexing과 Demultiplexing은 segment, datagram의 header field의 값을 기반으로 처리됨
  • UDP: 오직 destination port 번호만 사용해서 demultiplexing
  • TCP: 4-tuples(source and destination IP and port num)을 모두 사용해서 demultiplexing
  • Multiplexing과 Demultiplexing은 모든 layer에서 발생한다!



Connectionless transport: UDP


UDP: User Datagram Protocol

What UDP?

  • port를 사용해서 datagram을 application layer에 전달만 함
  • no frills, bare bones internet transport protocol
  • "best effort" service
    • UDP의 segment는 loss될 수 있고, out-of-order로 전달될 수 있음
  • connectionless
    • UDP sender와 receiver사이엔 handshaking 과정이 없다.
    • 각 UDP segment들은 다른 segment와 독립적으로 처리된다. (Packet은 individual, independent함)

Why UDP?

  • Connectionless: RTT delay가 적다
  • Simple: sender, receiver에 connection state가 없다.
  • small header size
  • no congestion control
    • congestion시 TCP는 보내는 양을 줄임
    • UDP는 그런거 없고 원하는 만큼 빠르게 보낼 수 있다.
      • congestion을 직면해도 기능할 수 있다.

Where UDP?

  • Streaming multimedia apps (loss 감내, rate가 중요)
  • DNS
  • SNMP
  • HTTP/3
  • 만약 HTTP/3처럼 UDP를 쓰면서도 reliable transfer를 원한다면, application layer에서 reliability를 구현해줘야 된다.
  • congetsion control 또한 application layer에서 구현 가능.
  • 아무튼 뭔가 기능이 필요하면 application layer에서 추가해줘야 한다.

How UDP?

  • UDP Sender Action
    • Application layer message를 받는다
    • UDP Segment header file 값들을 설정한다
    • UDP Segment를 생성한다
    • IP로 segment를 넘긴다
  • UDP Receiver Action
    • IP에서 segment를 받는다
    • UDP checksum header값을 확인한다
    • Application layer의 message를 추출한다
    • socket을 통해 application에 message를 demultiplexing한다. (port number 사용)

UDP Segment Header

  • Source port, dest port, length, checksum은 각 16bit (2byte)
  • Header 뒤에 application data(payload)가 온다.
  • length는 header포함 segment의 길이
  • checksum은 전달된 데이터의 correctness 확인 용도로 사용된다.

UDP checksum

  • Goal: 전송된 segment에서 flipped bit등의 error를 찾아내는 것
  • Sender
    • hedaer를 포함한 UDP segment를 16-bit integer의 sequence로써 contents handle
    • checksum: segment content의 합
    • checksum value는 UDP header의 checksum field에 들어감
  • receiver
    • 받은 segment의 checksum을 계산한다
      • segment의 모든 field를 word 단위로 다 더한다. (c0ff + ff32 + ... + 7374)
      • 더할 때 carryout을 result에 더해준다.
      • 모든 bit에 대해서 보수 연산을 취해준다. (0101 -> 1010)
    • 위 과정을 통해 계산된 checksum 값이 checksum field의 값과 같은지 확인한다
      • 만약 다르면 - error detected
      • 같으면 - 에러는 감지되지 않음. 그래도 에러가 생길 수 있지 않을까..?

checksum: weak protection

  • 두개의 16-bit 정수를 더한다고 할 때 마지막 두 자리가 원래 1 0이고 다른 하나는 0 1이라고 하자. 이 때 서로 바뀌어도 (0 1, 1 0으로) checksum에는 값의 변화가 없다...!
    • 해결 방법
      • CRC
      • 2-way checksum (2차원으로 검증)

UDP Discussion

  • UDP는 큰 데이터를 보낼 수 있다. 그럼 그냥 보내면 될까?
    • 어차피 link layer에 data size 제한이 있어 더 큰 사이즈의 data를 보내고 IP layer에서 쪼개진다..
      • 만약 IP fragmentation이 일어나 잘못돼도, UDP는 해당 상황을 handle하지 않는다
      • 사용자에게 작은 사이즈로 보내기를 권장
    • 만약 큰 데이터를 보냈다 하더라도, 그 중 일부에 문제가 생겼을 뿐인데(심지어 단 1개의 비트라도) checksum에 의해 에러가 잡힌다.
      • 만약 에러가 생기면 전체를 다시 보내야된다..
      • UDP는 에러가 난 부분만 care해주지 않는다.



0개의 댓글