[ Network ] Ch03. Transport Layer

38A·2023년 10월 13일

네트워크

목록 보기

3/3

Overview

Understand principles behind transport layer services:
- multiplexing, demultiplexing
- reliable data transfer
- flow control → prevent RX buffer overflow
- congestion control → network 처리용량 이상 traffic이 발생하면 control
Learn about Internet transport layer protocols:
- UDP: connectionless transport
- TCP: connection-oriented reliable transport
- TCP congestion control
Evolution of Transport Layer Functionality:
- QUIC

3.1 Transport-layer services

Provide logical communication between application processes running on different hosts
Transport protocols actions in end systems:
- sender: breaks application messages into segments, passes to network layer
- receiver: reassembles segments into messages, passes to application layer
Two main transport protocols available to Internet applications
- TCP, UDP

Transport vs. network layer services and protocols

Transport vs. network layer services
- Network layer: logical communication between hosts
- Transport layer: logical communication between processes → 하나의 host에 여러개의 process 가능
  - relies on, enhances, network layer services
Underlying IP(network) layer: best-effort delivery service
- Packet loss
- Out-of-order sequence
- Duplicate packets
- An arbitrarily delay

Transport Layer Actions

EncapsulationDecapsulation

Two principal Internet transport protocols

TCP: Transmission Control Protocol
- Connection-oriented
- Reliable, in-order delivery
- Congestion control
- Flow control
- Multiplexing / demultiplexing
UDP: User Datagram Protocol
- Connectionless
- Unreliable, unordered delivery
- Error check → IPv4에서 Option, v6에서 필수
- Multiplexing / demultiplexing
- No-frills(장식, 추가기능) extension of “best-effort” IP
Services not available:
- delay guarantees
- bandwidth guarantees

3.2 Multiplexing and demultiplexing

How demultiplexing works

Host receives IP datagrams
each datagram has source IP address, destination IP address, and a protocol number → for network layer demultiplexing (ex_ TCP / UDP)
each datagram carries one transport-layer segment
each segment has source, destination port number
Host uses IP address & protocol number & port number to direct segment to appropriate socket(service interface)

Port Number

Use port number to identify processes
- 16 bit integer: 0 ~ 65535 (2 $^{16}$ -1)
- Each application process is associated with ports for communication
Client process → port # 몰라도된다.
- Defines itself with a port number chosen randomly(→ by OS. 사용하지 않는 #) by the transport layer software running on the client host
- these are called ephemeral(임시) port #
Server process
- Use well-known port # → for well-known services
Listed in RFC1700 => RFC 3232
- http://www.iana.org/number.html
Well-known ports :
- ranging from 0 to 1,023
Registered ports :
- ranging from 1,024 to 49,151
- They are not controlled by IANA. But they can only be registered with IANA to prevent duplication.
- Used for TCP/IP applications that are not specified in RFCs
Dynamic (private) ports : → 충돌이 일어날 수 있다
- ranging from 49,152 to 65,535(2 $^{16}$ -1)
- neither controlled nor registered
- can be used by any process.
- can be used for ephemeral ports

Connectionless demultiplexing

When host receives UDP segment:
Checks destination port # in segment
directs UDP segment to socket with that port #

➡️ IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same packet at dest
→ dest.에 도착했을 때 dest. IP addr는 확인 X ( cf. TCP )
→ dest port #가 같으면 src와 무관하게 다 받아드린다.

Connection-oriented demultiplexing

⭐️ TCP : reliable, byte stream service 키워드로 설명할 수 있어야함!

TCP socket identified by 4-tuple:
- source IP address & source port number
- dest IP address & dest port number
When host receives TCP segment:
- uses all four values to direct segment to appropriate socket
  - SrcIP & port
  - Dest IP & port

➡️ Even when IP datagrams with same dest. port #, they are delivered to different processes when the source IP addresses or source port numbers are different.

Summary

Multiplexing, demultiplexing: based on segment, datagram header field values
UDP: demultiplexing using dest. port # (only)
TCP: demultiplexing using 4-tuple
Multiplexing / demultiplexing happen at all layers

3.3 Connectionless transport: UDP

“no frills,” “bare bones” Internet transport protocol
No reliability
- UDP segments may be lost or delivered out of order to app
- No flow control / no congestion control
  - No error recovery mechanism except for error detection by the checksum
Connectionless:
- no handshaking between UDP sender, receiver
Why UDP?
- No connection establishment (which can add RTT delay)
- Simple: no connection state at sender, receiver
- Small header size (8B) → cf. TCP 20B
- No congestion control
  - UDP can blast away as fast as desired
  - can function in the face of congestion (RFC4340: DCCP(Congestion Control))
- Not restricted to a point-2-point communication → conference service 가능 (1:다)
- TCP has much overhead
  - Finer application-level control
Streaming multimedia apps
- loss tolerant, rate sensitive
DNS: connection set-up / release overhead(가 없는 UDP 사용)
SNMP: low overhead → 네트워크가 잘 안될때 TCP 사용하면 더 부담을 줌
RIP(Routing Info. Protocol): periodically updated → 바로 옆과 통신 : 에러 rate⬇️. 30초마다 update해서 error가 있어도 바로 update
HTTP/3: QUIC + UDP
- if reliable transfer needed over UDP (e.g., HTTP/3):
  - add needed reliability at application layer (?)
  - add congestion control at application layer (?)
    → transport layer 기능도 가지고 있기 때문에 (?)

Transport Layer Actions

Segment Format

Total length
- header + data
Data (payload)
- data to/from application layer
Checksum → Internet checksum, error check 방식 TCP, UDP, IP 동일
- To detect error over the entire user datagram ( header + data + pseudo-header )
- Optional in IPv4 → IPv4에서 error check하기 때문
- Mandatory with IPv6 → error check X
- if it is not used, the field is filled with 0’s
- if an error is detected, the segment is usually discarded
Pseudo-header
- Checksum is the 16-bit one's complement of the one's complement sum of the header , the data, and the pseudo-header
- Pseudo-header is used in checksum calculation, but not transmitted.
- Protocol layering violation(위반) (part of IP header) → 다른 layer 정보를 봐서 위반, L4에서 L3 정보를 봄

Checksum

→ 계산량을 단순화시키기 위해서 성능이 안좋아도 사용. L2: 성능이 좋은 error check(CRC) 있기 때문에 단순하게만 계산

Goal: detect errors in transmitted segment by using Internet checksum
Internet checksum
- Consider the data as a sequence of 16-bit integers
- Generation rule of checksum
  - Add data using 16bit 1's complement addition, and then
  - Take the 1's complement of the result
- Error checking rule
  - Add all the data including checksum using 16bit 1's complement addition
  - Check if the result is all ones(no error), that is, - 0 (1’s complement arithmetic). Otherwise, assume that an error has occured.