본문 바로가기

컴퓨터 네트워크

3.2 TCP & UDP

Connectionless demultiplexing

connectionless ⇒ UDP (at receiver)

demux는 destination에서 실행중인 여러 개의 프로세스들 중 소켓 찾기

by sender가 붙인 dest port number (destination에 도착해 layer를 올라갈 때 발생) ⇒ 같은 port number를 가진 패킷은 같은 소켓으로 도착

Client 끼리 통신하는 게 X. Client끼리는 같은 서버와 통신함

UDP에서는 여러 클라이언트가 서버의 같은 소켓으로 통신 하기 때문에 UDP segment 헤더에 있는 dest의 IP주소와 port 번호로 클라이언트를 구분해야 함

→ TCP는 서버가 두 클라이언트를 위한 각각의 전용 소켓을 하나씩 갖고 있음

→ UDP는 서버가 두 클라이언트를 위한 하나의 소켓을 가짐

(DNS 서버는 클라이언트를 위한 소켓이 하나 열림)

Connectionless demux: UDP

각 프로세스는 자신의 IP주소와 port #를 넣은 socket을 연다.

P3가 P1에게 보낸 데이터의 UDP Segment에서 source port는 9157, dest port는 6428.

6428 port를 연 P1 서버는 port #만으로 자신에게 온 메시지인지 확인할 수 없기 때문에 (같은 port를 연 다른 서버일 수 있음) IP주소를 transport 계층까지 올려 IP주소와 port #로 소켓을 찾는다. (Layering이 완벽히 이루어지지 않음)

IP주소는 network 계층만 보는 것이 아니라, 보고 한 계층 더 올려줌

= socket을 identify하는데 3계층 파라미터를 사용

P1 서버는 자신에게 온 데이터에서 source IP와 source port #를 보고 응답.

UDP: ONLY ONE SOCKET at Server for multiple clients (DNS)

Connection-oriented demux

TCP는 각 클라이언트 만의 dedicated된 socket을 열기 떄문에 return port #를 알고 있음. return 주소를 socket에게 알려줄 필요가 X

  • TCP socket identified by 4-tuple
    • source IP address
    • source port number
    • dest IP address
    • dest port number
  • server host may support many simultaneous TCP sockets:
    • each socket identified by its own 4-tuple

Connection-oriented demux: TCP

(가운데의 서버에는 항상 연결을 대기하는 welcome socket이 안 그려져 있음)

서버는 Client process들 당 전부 다른 소켓을 갖고 parallel하게 처리

Client process는 모두 같은 destIP, dest port #를 갖고 있을지라도, source 정보가 다르기 때문에 다른 소켓으로 처리 가능

UDP: User Datagram Protocol

UDP(User Datagram Protocol)는 transport layer에서 포트 번호를 이용해서 application layer에서 전송된 데이터를 multiplexing해 세그먼트로 만들어 network layer로 보내고, 반대로 network layer에서 올라온 패킷을 demultiplexing해 application layer로 보낸다.

UDP 세그먼트는 다음과 같은 특징을 가진다.

  • "best effort" - 아무것도 보장하지 않는다.
    • lost
    • out-of-order to app
    • : 내용이 전송 중에 손실 될 수 있고, 전송되는 세그먼트의 순서가 바뀔 수 있다.
  • segments may be:
  • connectionless:each UDP segment handled independently of others세그먼트에 추가되는 헤더가 적어 오버헤드가 적고, 빠르다
  • : 연결 상태를 만들지 않는다. (connectionless)
  • no handshaking btw UDP sender, receiver ⇒ fast
  • UDP use: (loss보단 throughput에 민감한 app들)DNS
  • SNMP
  • streaming multimedia apps (loss tolerant, rate sensitive)
  • UDP: segment header

no connection = no conn. setup delay → fast

small header = small function

no congestion control → good for rate sensitive applications

UDP checksum (e2e checksum)

detect "errors" in transmitted segment in edge (host)

체크섬은 전송된 데이터가 변형이 되지 않았는지 확인하는 값이다.

전송하려는 세그먼트의 값들을 이용해 체크섬을 만들어서 세그먼트에 담아 전송한다. 세그먼트를 받은 상대는 세그먼트의 값들을 이용해 다시 체크섬을 계산하고 세그먼트에 저장된 체크섬 값과 비교한다.

  • sender
  • 16bit 단위로 segment contents를 끊어 더한 후 (오버플로 돼서 캐리된 값들을 다시 더함) 1의 보수를 취한다.
  • receiver
  • sender와 같은 행위를 한 후 sender가 보낸 checksum과 다른지 비교한다
  • 다르다면: error detected → drop or report
  • 같다면: no error detected

(2 bits in 16-bit distance flip → 못 찾음)

e2e checksum을 하는 이유?

  1. All 2-layer protocol cannot do checksum
  2. error can happen at NW routers' buffer

Reliable Data Transfer Mechanism

TCP의 목적: receiver가 loss(= Gap)없이, in order로 메시지를 받는 것

→ error checking 필요

  • Acknowledgement: ~까지 받았어. 다음부터 보내줘 (TCP)
  • Negative acknowledgement: # 못 받았어. (UDP)
  • Sequence number: TCP는 byte단위로 data numbering.
    number의 gap이 생기면 loss가 생긴 것

  • timer: 안 오면 언제까지 기다려야 하나? 시스템의 오버헤드

timeout = 잃어버렸다고 판단 → retransmit

Timer의 비효율성

  1. premature timeout → retransmit, duplicated data
  2. ACK loss → retransmit, duplicated
  • Pipelining & Window

Pipelining: 한 번에 여러 개 보낼 수 있다.

TCP sliding window, cumulative ACK : ACK을 받지 않아도 w만큼 data 전송

cf. TCP는 full-duplex comm.를 support (보내면서 받기)


TCP: Overview

point-to-point:

one sender, one receiver

단일 송신자와 단일 수신자를 가짐, 멀티캐스팅(단일→여럿) 불가능.

reliable, in-order byte stream:

byte 단위로 numbering

connection-oriented:

handshaking (exchange of control msgs) inits sender, receiver state before data exchange

full duplex data:

bi-directional data flow in same connection

MSS: Maximum Segment Size

flow controlled:

sender will not overwhelm receiver, window size 결정

congestion controlled:

sender will not overwhelm network, window size 결정

pipelined:

window size안에서 여러 개의 TCP segment가 ACK없이 전송 되는 것

TCP segment structure

20 bytes의 TCP 헤더

'컴퓨터 네트워크' 카테고리의 다른 글

3.4 TCP Congestion Control  (0) 2021.06.12
3.3 TCP Flow Control & 3-way handshake  (0) 2021.06.12
3.1 Transport Layer  (0) 2021.06.12
2.6 CDN & Socket Programming  (0) 2021.06.12
2.5 P2P & CDN & DASH  (0) 2021.06.12