[컴퓨터 네트워크] 3장. Transport Layer

해당 게시물은 김정근 교수님의 '컴퓨터 네트워크' 강의를 수강하며
학습한 내용을 개인적으로 정리한 글입니다.

---

📌 목차 - 3장. Transport Layer

3-1. Transport-layer services
3-2. Multiplexing and demultiplexing
3-3. Connectionless transport: UDP
3-4. Principles of reliable data transfer
3-5. Connection-oriented transport: TCP
3-6. Principles of congestion control
3-7. TCP congestion control
3-8. Evolution of transport-layer functional

---

📌 3-1. Transport-layer services

* Transport services and protocols
- provide logical communication between application processes running on different hosts.

 

* TCP: Transmission Control Protocol
- reliable(패킷 손실x), in-order delivery
- congestion control, flow control, connection setup

 

* UDP: User Datagram Protocol
- unreliable, unordered delivery
- no-frills extension of "best-effort" IP

* not available
- delay guarantees
- bandwidth guarantees

---

📌 3-2. Multiplexing and demultiplexing

* Multiplexing and demultiplexing
- 특정 프로세스를 지칭하는 고유 ID: <host IP, Port #>
- multiplexing at sender
- demultiplexing at receiver

* Connectionless demultiplexing
- 목적지의 ip, port number를 사용하는 demultiplexing

* Connection-oriented demultiplexing
- 목적지의 ip, port number와 출발지의 ip, port number를 사용하는 demultiplexing

---

📌 3-3. Connectionless transport: UDP

* UDP segment header
- source port, dest port, length, checksum
- 정보가 적고 매우 간단하다.
- size는 한 폭이 32bit(4Byte)고 두 줄로 구성되어있어서 총 8Byte다.

* "best effort"

- segments를 전달만 하고 아무것도 하지 않는 서비스다.
- lost
- delivered out-of-order to app

* connetionless

- no handshaking between UDP sender, receiver

* Why is there a UDP?
- connection이 불필요한 매우 간단한 데이터 전송에 효율적이다.
- no congestion control

* UDP use
- Streaming multimedia apps
- DNS
- SNMP
- HTTP/3

* RFC (Request For Comment)
* UDP checksum: detect errors in transmitted segment
* CRC (Cyclic Redundancy Check)

---

📌 3-4. Principles of reliable data transfer

* Principles of reliable data transfer
- rdt_send() -> udt_send() -> [unreliable channel] -> rdt_rcv() -> deliver_data()

* 안정적인 데이터 전송을 방해하는 두 가지 장애
- Bit(channel) error: channel이 깨짐
- Packet loss

* rdt1.0 (Reliable Data Transfer)
- no bit errors
- no loss of packets
- sender: rdt_send(data)->packet = make_pkt(data)->udt_send(packet)
- receiver: rdt_rcv(packet)->extract(packet, data)->deliver_data(data)

* rdt2.0
- checksum to detect bit errors
- acknowledgements (ACKs): pkt received OK
- negative acknowledgements(NAKs): pkt had errors
- stop and wait: sender sends one packet, than waits for receiver response

* rdt2.1
- handling duplicates: sender adds sequence number to each pkt. 패킷에 일련번호를 붙여준다.

* rdt2.2
- NAK-free protocol
- cumulative ACK: NAK 대신에 ACK에 일련번호를 매겨서 잘 받은 pkt 번호를 넘겨준다.

* rdt3.0
- timeout: packet loss 감지. 출발된 데이터가 도착 예정 시간이 지나도 오지 않았음을 감지하고 데이터를 다시 전송한다.
- utilization: sender가 전체 시간 중 데이터를 전송하는데 사용한 시간 %
- throughput: 단위시간당 성공적으로 보내지는 데이터의 양

* rdt3.0 # stop and wait (SAW)
- pipelining: packet 하나 전송하고 오래 기다리기보다는 packet 여러개를 연속으로 전송하는 방법.
utilization이 향상된다.

* rdt3.0 # go back n (GBN)
- window size N: send_base(보냈는데 아직 수신확인을 못받은 애들 중 가장 오래된 아이)부터 nextseqnum(보낼 준비가 된 첫 번째 아이) + 보낼 준비가 된 애들 까지의 크기
- cumulative ACK: ACK(n)번 까지 잘 받았다고 receiver가 전송한다.
- timeout(n): n번 packet부터 전송 가능한 모든 packet까지 재전송한다.
- rcv_base: 아직 받지 못한 데이터
- out of order packet: rcv_base 보다 나중 순서 패킷이 먼저 도착한다. 폐기하거나 buffer에 저장할 수 있다.

*  rdt3.0 # selective repeat (SR)
- out of order packet을 buffer에 저장하고 ack을 보낸다.

* sender
- data from above: window 범위 내의 번호 packet은 바로 전송한다.
- timeout(n): n번 packet 하나만 다시 전송하고 timer를 다시 시작한다.
- ACK(n): n을 수신한 것으로 마킹한다. n이 send_base였다면 window 무빙을 진행한다.

* receiver
- send ACK(n): indivisual ack, 순서를 지키지 않고 가장 최근의 pkt 번호의 ack을 전송한다.
- out of order: buffer에 저장한다.
- in order: 수신 완료한 모든 패킷을 저장하고 receiver window 무빙을 진행한다.

* selective repeat: dilemma
- seq number의 크기가 너무 작으면 timeout된 pkt인지 새로운 pkt인지 구분을 못하는 상황이 생길 수 있다.
- solution: 마지막seq#의 크기 >= 2 Window size

---

📌 3-5. Connection-oriented transport: TCP

- 1:1 -> point-to-point
- 1:m -> multicast
- 1:every -> broadcast

* TCP (RFCs: 793, 1122, 2018, 5681, 7323)
- point-to-point: 1대1 통신
- reliable, in-order byte stream
- full duplex data: 하나의 TCP connection으로 양방향 데이터 전송
- cumulative ACKs
- pipelining: TCP congestion control window, TCP flow control window
- connection-oriented
- flow controlled

* TCP Segment Structure
- header part
- source port, dest port, length, checksum
- sequence number, acknowledgement number
- receive window: flow control
- C, E: congestion notification
- RST, SYN, FIN: connection management
- options(variable length): TCP options
- data part

* TCP Sequence numbers, ACKs
- Sequence numbers
- Acknowledgements

* TCP round trip time, timeout
- timeout 시간을 RTT보다 충분히 크게 설정해야 한다.
- too short: 불필요한 재전송이 이뤄진다.
- too long: 반응이 너무 느려진다.

* TimeoutInterval 수식
- TimeoutInterval = EstimatedRTT + 4 * DevRTT
- EstimatedRTT = (1 - a) * EstimatedRTT + a * SampleRTT
- DevRTT = (1 - B) * DevRTT + B * |SampleRTT - EstimatedRTT|
- SampleRTT: sender 입장에서 segment를 보내고 receiver로부터 ACK을 받기까지의 시간
- exponential weighted moving average (EWMA): 최근 SampleRTT에 가중치를 더 두어 계산하는 RTT 평균값. typical value: a = 0.125. (이전값 -> 최근값)의 가중치가 지수함수로 그려진다.
- typically, B = 0.25

* TCP sender (simplified)
- data received from application
- timeout
- ACK received

* TCP receiver: ACK generation
- Event at receiver
- 1. arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed.
- delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK.
- 2. arrival of in-order segment with expected seq #. One other segment has ACK pending.
- immediately send single cumulative ACK, ACKing both in-order segments.
- 3. arrival of out-of-order segment higher-tha-expect seq #. Gap detected.
- immediately send duplicate ACK, indicating seq #. of next expected byte.
- 4. arrival of segment that partially or completely fills gap.
- immediately send ACK, provided that segment starts at lower end of gap.

* TCP fast retransmit
- duplicate ACKs을 받으면 timeout 기다릴 필요없이 바로 재전송을 날린다.

* TCP flow control
- overflow(보내는 데이터의 양과 받는 데이터의 양이 불균형)가 나는 것을 방지한다.
- TCP receiver의 버퍼의 여유분 정보를 sender에게 보내준다.
- sender가 보내는 양과 receiver가 소화하는 양이 매치되도록 한다. (네트워크 환경과는 무관한 내용이다.)
- TCP header, receiver window: flow control. # bytes receiver willing to accept

---

📌 3-6. Principles of congestion control

* Top-10 problem
- congestion control: 혼잡제어
- packet loss: 패킷손실
- bandwidth congestion: 대역폭 부족
- network latency: 네트워크 지연
- reliable data transmission: 안정적인 데이터 전송
- security issues: 보안 문제
- DNS issues: DNS 문제
- wireless network issues: 무선 네트워크 문제

* Congestion
- 혼잡: queueing delay가 길어진 상황이다.
- 증상
- long delays (queueing in router buffers)
- packet loss (router에서 overflow된 데이터를 버려버리기 때문이다.)

* Causes/costs of congestion: scenario
- 도착하는 pkt의 불규칙성 때문에 delay가 발생한다.
- 람다in의 크기가 커질수록 delay는 매우 커진다.
- some perfect knowledge: 손실이 일어나서 재전송하는 경우 => throughput의 크기를 갉아먹는다.
- un-needed duplicates: 손실되지 않았음에도 timeout이 발생해서 재전송하는 경우 => throughput의 크기를 더 갉아먹는다.
- multi-hop paths: 네트워크가 복잡할수록 데이터가 손실됨에 따른 비용손실이 더욱 커진다.
- throughput can never exceed capacity
- delay increases as capacity approached
- loss/retransmission decreases effective throughput
- un-needed duplicates further decreases effective throughput
- upstream transmission capacity / buffering, wasted for packets lost downstream

---

📌 3-7. TCP congestion control

* Approaches towards congestion control
- 지능적 요소를 end-system에 모아두었기 때문에 host에서 네트워크 혼잡 제어를 담당한다.
- end-end congestion control: 증상을 통한 추론을 바탕으로 혼잡제어를 한다. = TCP
- network-assisted congestion control: 네트워크가 혼잡에 대한 최소한의 정보(현재 혼잡이 일어나는 라우터)를 알려준다. = TCP ECN

* TCP Congestion Control: AIMD(Additive Increase Multiplicative Decrease)
- Additive Increase: 시간에 따라 서서히 선형적으로 전송 데이터의 양을 증가시킨다. RTT 당 1씩 증가
- Multiplicative Decrease: 앞에서 증가하다가 혼잡이 발생하면 전송 데이터의 양을 확 줄여버린다. 현재 전송 데이터 양의 절반으로 감소

* TCP AIMD: more
- TCP Tahoe -> TCP Reno
- 혼잡의 증상: timeout(중증), 3 duplicate ACKs(경증)
- TCP Tahoe는 위의 두 증상을 구분하지 않고 혼잡에 반응한다. => 1부터 다시시작한다.
- TCP Reno는 위의 두 증상을 구분한다. => timeout은 1부터 다시시작. 3 duplicate ACKs은 AIMD처럼 1/2에서 다시시작한다.

* TCP congestion control: details
- congestion window: 혼잡 제어에서 사용하는 window.
- cwnd = LastByteSent - LastByteAcked
- 네트워크의 혼잡 여부에 따라 cwnd 사이즈를 키웠다 줄였다한다.
- TCP rate = cwnd/RTT => 일종의 throughput
- cwnd는 segment 단위, 1 segment = 1400 byte

* TCP slow start
- 시작은 1로 하지만 선형적으로 데이터 전송의 양을 늘릴 때 하나씩은 너무 느리기 때문에 기하급수적으로 사이즈를 확 늘린다.
- slow start threshold: 데이터 전송의 양을 올리다가 threshold 값에 도달하면 AIMD로 변환한다.
- timeout 또는 3 duplicate ACKs이 발생했을 때 threshold를 갱신한다. (발생 시점 양의 절반 만큼 설정)
- TCP: from slow start to congestion avoidance 페이지 그래프. TCP Tahoe, TCP Reno 각 상황
- MSS (Maximum Segment Size): ex. 1MSS 당 1024 byte

* TCP Cubic: TCP Reno의 다음
- Wmax: 혼잡 감지 cwnd size
- cwnd의 크기를 선형적으로 증가하기보다는 빠르게 증가하다가 Wmax 근방에서 서서히 증가하도록 하는 방법
- K: Wmax에 도달할 것으로 추정되는 시간
- cwnd = (현재시간 - K)^3
- Linux의 default TCP다.
- AIMD 부분을 제외하고 TCP Reno의 특성을 모두 물려받는다.

* TCP Vegas: TCP and the congested "bottleneck link"
- 기존 TCP들과 다르게 혼잡 제어를 병목 현상이 일어나는 router의 bottleneck에 초점을 맞춘다.
- RTTmin: 응답이 가장 빠른 상태
- Throughput <=> cwnd / RTTmin
- 혼잡 제어: RTTmin 값을 계속 측정하고 throughput의 값과의 차이를 비교해서 cwnd를 선형 증가/감소시킨다.

* TCP ECN: Explicit Congestion Notification
- 네트워크로부터 혼잡 정보를 받는 형식

* TCP fairness
- Fairness goal: bottleneck link의 bandwidth에 따라서 여러개의 TCP connection에 각 cwnd를 균등하게 할당한다.
- TCP는 fair하다.
- 하지만 모든 network app이 fair하지는 않다.
- multimedia apps은 TCP를 사용하지 않는 경우도 많다. = UDP는 혼잡 제어를 하지 않는다.
- 한 호스트 내에서 TCP connection 끼리는 fair하다고 볼 수 있지만 여러 호스트 끼리 비교했을 때는 각 호스트 내의 TCP connection의 개수가 다르므로 fair하다고 보기 어려울 수 있다.

---

📌 3-8. Evolution of transport-layer functional

* Evolving transpoprt-layer functionality
- 무선 네트워크는 bit-error가 빈번하게 발생하므로 유선 네트워크보다 불안정한 경우가 많다.
- 하나의 TCP 솔루션으로 여러 상황들을 모두 케어할 수는 없다.
- Long, fat pipes
- Wireless networks
- Long-delay links
- Data center networks
- Background traffic flows

* Quic: Quick UDP Internet Connections
- UDP보다는 성능이 더 필요하지만 TCP보다는 덜 복잡한 중간의 것
- 기본은 UDP를 사용하지만 추가적인 계층(기능)을 하나 더 붙인다.
- HTTP와 UDP 사이에 존재한다. (http에 최적화되어있다.)

---