고정 헤더 영역
상세 컨텐츠
본문
chapter 3 outline
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
- segment structure
- reliable data transfer
- flow control
- connection management
3.6 principles of congestion control
3.7 TCP congestion control
3.1 transport-layer services
수송 계층의 서비스
Transport services and protocols
서로 다른 hosts에서 실행되는 app processes 간의 logical communication 제공
transport protocols run in end system > transport protocol은 end system에만 있다 core에는 없음
msg가 작으면 msg 앞에 header를 붙이면 되고 msg가 커서 segment로 분할하면 각각의 segment에 header를 붙여서 전송
send side: app messages가 크면 segments로 쪼개서 network layer로 보낸다
rcv side: reassembles segments into messages, passes to app layer (세그먼트를 메시지로 재조립하고 앱 계층으로 전달) ** rcv side에선 msg가 분할되어서 오면 어떤 msg가 어디에 속하는지 알아야 분할된 msg를 붙일 수 있음 인터넷은 신뢰성 있는 전송을 보장해주지 않기 때문에 분할된 msg가 순서대로 온다는 보장이 없음 sender가 1 2 3 순서로 segments를 전송한다고 하더라도 rcv 쪽에서 1 2 3 순서로 segments를 받는다는 보장이 없음 즉 sender side에서 app msg를 segment로 나눠서 보냈으면 rcv side에서는 순서를 알아내서 복원해야 함 이런 기능이 수송계층에 존재 = reassemble 과정 **
** 1 2 3 4 (sender) --> 2 4 3 1 (rcv) : 패킷 전송된 순서 바뀜 = out-of-order delivery
Transport vs network layer
network layer: logical communication between hosts -> network layer에서는 IP 주소가 쓰임
transport layer: logical communication between process -> transport layer에서는 port#가 쓰임
e.g., 택배를 보낸다고 가정
network = 택배 회사라고 생각
network layer에서는 집주소만 보고 보낸 장소(sender의 IP 주소)에서 택배를 받아서 택배를 받아야 하는 장소(rcv의 IP 주소) 즉 IP 주소만 사용 source IP address & dest IP address = 장소라 생각
transport = rcv 장소에 여러 명의 사람이 있다고 가정
transport layer에서는 port#가 쓰이는데 택배를 받은 장소에 사람들이 여러명 있으면 거기서 택배의 주인을 찾는 과정이다 택배 주인 = port# = process를 찾는 과정
Internet transport-layer protocols
** 발생할 수 있는 오류
- out-of-order delivery : network layer에서 IP는 전송 순서 보장 안해줌 순서 바뀌는 오류
- bit 오류 : ㄱ을 보냈는데 ㄴ 도착 -> bit에서 오류 내용이 바뀜
- loss : data를 보냈는데 dest까지 도착 안 함
- duplicated : 동일한 msg 여러번 받음 bit 오류, loss를 해결하기 위한 방안으로 구현하기도 함
**
- reliable, in-order delivery : TCP
** 신뢰성 <-> 오류 // 오류(위의 4가지 오류 중)가 발생하더라도 극복할 수 있는 기능이 존재 **
congestion control 혼잡 제어
-> ** 인터넷을 통해 data를 교환할 때 라우터에 input과 output이 있음
input > output
= queue에 data가 쌓이기 시작 = 혼잡 발생 = 기다리는 시간 길어짐 delay = 전송시간 증가(최악 : loss)
TCP가 혼잡 제어를 한다는 것 = input 조절
input이 많아지는 이유 = end system이 data를 보내기 때문 input을 줄이기 위해서 각각의 end system이
자신의 전송률을 낮추면 됨
망 내 교환 노드 문제 **
flow control 흐름 제어
-> end system process에서 문제
-> ** 수송계층은 process 간의 logical connection
if network capacity가 무한대 즉 혼잡 없을 시
sender가 rcv에 보내는 data의 양이 많아짐 rcv는 buffer에 쌓아둠 -> overflow 발생
즉 흐름제어는 종단 제어시스템에 있는 process들 간 전송속도를 맞추는 것(overflow가 발생하지 않게)
rcv 처리 용량만큼 데이터 보내기 **
connection setup 연결 제어
-> TCP UDP 큰 차이
- unreliable, unordered delivery : UDP
연결과정 없이 바로 전송 <-> TCPsms segment를 보내기전에 end system들 사이에서 (sender와 dest 사이에서) 연결과정을 거침
no-frills extension of "bes-effor" IP
** 목적지에서 어떤 프로세스에게 온 segment인지만 결정해주는 기능 제공 **
UDP에는 위 TCP의 기능이 모두 없음
- services not available: - TCP UDP가 제공하지 않는 서비스
delay guarantees 보내는 것이 목적지까지 어느 정도 시간 내에 반드시 도착한다는 것을 보장해주지 않음
bandwidth guarantees
(내가 데이터를 보낼 때 최소한 x bps 만큼은 보장해준다는 것을 인터넷에서 할 수 없다 bandwidth = 공유자원
사용자 많으면 느려짐)
3.2 multiplexing and demultiplexing
Multiplexing/demultiplexing
multiplexing at sender: multiple sockets의 data 처리, transport header 추가(나중에 demultiplexing에 사용)
demultiplexing at receiver: header info를 사용하여 socket을 수정하기 위해 수신된 segments를 전달
P3에서 보낸것이 Server에 도착 => network layer 담당(IP주소)
network layer에서 붙인 header에는 IP주소 source IP, dest IP
** process가 socket을 통해 transport layer에게 어떠한 service를 요청 e.g., 자신이 보내고자 하는 msg를 전달해달라
sender 쪽에서 보낸 msg 앞에 header를 적절하게 붙임 header에 쓰인 정보는 나중에 rcv가 demultiplexing에 사용할 정보를 담게 됨 **
How demultiplexing works
- host receives IP datagrams
each datagram has source IP address, dest IP address ** host가 data를 받으면 거기에 있는 port# 정보를 가지고서 app layer process에게 나눠준다 **
각 datagram은 하나의 transport-layer segment를 전달
각 segment는 source port#, dest port# 가지고 있다
- host uses IP addresses & port numbers to direct segment to appropriate socket
host는 IP adresses와 port numbers를 사용하여 segment를 적절한 socket으로 보냅니다.
Connectionless demultiplexing (연결 없이 demultiplexing)
- when host receives UDP segment:
checks dest port# in segment
directs UDP segment to socket with that port # / UDP segment를 해당 (dest) port #의 socket으로 보낸다
IP datagrams with same destination port number, but different source IP addresses and/or source port numbers will be directed to same socket at destination
= dest port #는 같지만 source IP address 및/또는 source port #가 다른 IP datagram은 dest의 동일한 socket으로 지정
= 다른 source IP/port#에서 왔어도 같은 dest port#로 오면 같은 socket으로 간다 = demultiplexing
Connectionless demux: example
source: 9157 dest port: 6428과 source port: 5775 dest port: 6428은 source의 IP 주소가 다르지만 dest port#가 같다 demultiplexing P1으로 간다
Connection-oriented demux
연결지향 demultiplexing
- TCP socket identified by 4-tuple:
source IP address
source port number
dest IP address
dest port number
- demux: receiver는 4가지 값을 모두 사용하여 segment를 적절한 socket으로 보낸다
- server host는 많은 many simultaneous TCP sockets을 지원할 수 있음
each socket identified by its own 4-tuple
- web servers have different sockets for each connecting client
non-persistent HTTP will have differnet socket for each request
Connection-oriented demux: example
TCP - source IP / source port # / dest IP / dest port #
UDP - dest port #
TCP의 경우 4가지 정보를 다 보고 UDP의 경우 dest port # 만 본다
three segments, all destined to IP address: B (3개 segments 모두 IP address B로 향함)
dest port: 80 are demultiplexed to different sockets
IP address: A port num: 9157
IP address: B port num: 80
IP address: C port num: 5575
첫번째 example - multi-process
1번 : P3 -> P4
2번 : P3 -> P5
3번 : P2 -> P6
2번 3번 >> source IP 주소 같고 1번과는 다름
2번과 3번은 source port #은 다름
두번째 example - multi-thread
Server를 구현하는 방식이 multi-thread 인지 multi-process로 구현했는지에 따라 다름
multi-thread: thread 여러 개 구분 각각의 thread 별로 서로 다른 socket 사용
3.3 connectionless transport: UDP
UDP: User Datagram Protocol [RFC 768]
- "no frills", "bare bones" Internet transport protocol
** IP 기능과 거의 유사 **
- "best effort" service, UDP segments may be:
** best effort : 중간에 손실이 있거나 전송 순서가 바뀌어서 도착을 하더라도 UDP는 특별한 작업을 하지 않는다는 의미 밑의 오류 외에 다른 오류도 포함 4가지 오류 **
loss 손실
delivered out-of-order to app 순서 뒤바뀜
- connectionless:
UDP sender, rcv 사이 no handshaking -> connection 연결이 없음 TCP는 연결해야 됨
각 UDP segment 서로 독립적으로 처리됨 -> stateless protocol 상태 저장 안함
** rcv 안의 process가 현재 동작하고 있는지 아닌지 생각하지 않는다 단지 sender가 보낼 data가 있으면 segment를 만들어서 전송할 뿐이다 이와 달리 handshaking이 있다는 것은 sender와 rcv에게 data를 보내기 전에 연결 설정하기 위한 절차를 거친다 (마치 전화거는 것)
TCP는 3-way-handshaking을 하는 반면 UDP는 하지 않는다 **
** handshaking 과정이 없으니까 UDP demux에서 봤던 것처럼 UDP는 dest port#만 가지고서 process 식별한다
그렇기 때문에 UDP segment는 서로 간 독립적 처리가 가능
동일한 sender에 동일한 process가 동일한 rcv의 동일한 process에게 UDP datagram을 연속적으로 몇 개를 보낸다고 하더라도 dest process는 연속적으로 들어오는 datagram(segment)를 독립적으로 처리한다 = 기억하지 못한다 **
- UDP use:
streaming multimedia apps(손실은 허용하고, 속도는 민감한 곳에서 사용됨)
** 스트리밍 > 예를 들어 video, audio 즉 속도에는 민감하고 손실은 허용하는 부분 잠깐 멈춘다고 큰 영향 없는 곳에서 사용 <-> 반대로 Email file 같은 경우는 속도에는 민감하지 않지만 손실이나 bit error가 날 경우 내용이 바뀌거나 손실되면 문제가 생기기 때문에 UDP를 사용하지 않는다 **
DNS
SNMP 망 관리 protocol
- reliable transfer over UDP (UDP를 통한 안정적인 전송)
add reliability at application layer
application-specific error recovery
UDP: segment header
** network 교환노드에서 혼잡(congestion)이 발생하면 문제가 된다 혼잡의 원인은 end system에서 data를 많이 보내기 때문 혼잡이 발생했을 때 지금 보내고 있는 전송률을 낮추자 = congestion control
그런데 UDP는 congestion control 작업을 하지 않음 (best effort - 중간에 error가 생기더라도 조치 취하지 않음)
그래서 multimedia apps를 보낼때 rate sensitive함 (UDP는 streaming multimedia를 보내는데 최적화 - 손실을 허용하고 전송률에 민감하기 때문)
congestion control 기능이 없기 때문에 내가 원하는 만큼 즉 혼잡이 생기거나 말거나 상관없이 data를 보내는 특성을 가짐 **
UDP header : 8bytes
source port # : 2bytes dest port # : 2bytes
length - header를 포함하는 UDP segment 길이 (byte로 나타냄)
checksum - UDP는 best effort 즉 4가지 오류를 검출하지 않는다고 했다 대신 checksum으로 오류를 검출한다
만약 checksum으로 오류를 검출했을 시 조치는 없다 그냥 segment를 버린다
why is there a UDP? UDP 사용하는 이유
- no connection establishment 그래서 delay 안됨
- 단순함: no connection state at sender, rcv
- small header size : UDP의 header size = 8bytes // TCP header size = 20bytes 작으면 작을수록 효율적
- no congestion control: UDP는 원하는 만큼 빠르게 전송될 수 있음
UDP checksum
목표: 전송된 segment에서 "erro"(e.g., : flipped bits 반전된 비트) 감지 // segment를 받았는데 오류가 있는지 없는지 검사 flipped bits : 컴퓨터 {0, 1} -> bit 0을 보냈는데 bit 1 도착
sender:
- header field를 포함한 segment 내용을 16-bit 정수 sequence로 처리
- checksum: segment 내용의 덧셈(addtion) (1의 보수 합)
- sender는 checksum 값을 UDP checksum field에 넣는다
receiver:
- 받은 segment의 checksum 계산
- 계산된 checksum이 checksum field와 같은지 확인:
segment를 받고 계산해보고 checksum field랑 비교해서 같으면 error 없음
NO - error detected
YES - no error detected
Internet checksum: example
3.4 principles of reliable data transfer
Principles of reliable data transfer
Principles of reliable data transfer
Principles of reliable data transfer
Reliable data transfer: getting started
Reliable data transfer: getting started
rdt 1.0: reliable transfer over a reliable channel
rdt 2.0: channel with bit errors
rdt 2.0: channel with bit errors
rdt 2.0: FSM specification
rdt 2.0: operation with no errors
rdt 2.0: error scenario
rdt 2.0 has a fatal flaw!
rdt 2.1: sender, handles garbled ACK/NAKs
rdt 2.1: receiver, handles garbled ACK/NAKs
rdt 2.1: discussion
rdt 2.2: a NAK-free protocol
rdt 2.2: sender, receiver fragments
rdt 3.0: channels with errors and loss
rdt 3.0 sender
rdt 3.0 in action
Performance of rdt 3.0
rdt 3.0: stop-and-wait operation
Pipelined protocols
Pipelining: increased utilization
Pipelined protocols: overview
Go-Back-N: sender
GBN: sender extended FSM
GBN: receiver extended FSM
GBN in action
Selective repeat
Selective repeat: sender, receiver windows
Selective repeat
Selective repeat in action
Selective repeat: dilemma
3.5 connection-oriented transport: TCP
TCP: Overview
TCP segment structure
TCP seq. numbers, ACKs
TCP seq. numbers, ACKs
TCP round trip time, timeout
TCP round trip time, timeout
TCP round trip time, timeout
3.6 principles of congestion control
3.7 TCP congestion control
