컴퓨터 네트워크 03 전송 계층 | KOCW 한양대 이석복

protect-me·2021년 8월 23일

📝 CS Study

목록 보기

4/37

KOCW | 컴퓨터네트워크 | 한양대학교 | 2015-2 | 이석복
KOCW | 컴퓨터네트워크 | 한양대학교 | 2018-2 | 이석복

위 강의를 수강하며 정리한 내용임을 밝힙니다.
네트워크 계층을 Top-Down 방식으로 위에서부터 한 겹씩 까보면서 디테일하게 알아보는 강의

이미지 출처

3.1 Transport-layer

TCP / UDP 두 가지 방식이 있음

3.2 Multiplexing and Demultiplexing

프로세스에서 메세지를 보낼 때 알맞은 목적지 프로세스에 보내는 방식
발신자: 수많은 인터페이스를 가지고 있지만 나가는 곳은 하나이기 때문에 Multiplexing
수신자: 들어오는 곳 하나에서 수많은 인터페이스에 뿌려주는 것이 Demultiplexing

TCP/UDP 모두 Multiplexing/Demultiplexing을 하지만 방식에서 차이가 있음
UDP: Connentionless transport
port 번호만 보고 주고 받음. 커넥션이 없음.
TCP: Connection-oriented transport
수신자 소켓과 발신자 소켓이 1:1 관계임(고유함)

각 소켓은 고유의 포트번호를 가지는 것이 아님.

TCP에서 source IP / source Port / dest IP / dest Port가 모두 일치하는 소켓을 찾아감

즉, 위 4가지 중 한가지만 달라도 다른 소켓으로 Demultiplexing을 함.

하나의 프로세스는 여러개의 소켓을 가질 수 있음

3.3 Connentionless transport: UDP

UDP Segment
header / data
header: source port / dest port / length / checksum(에러 판단)

3.4 Principles of RDT

RDT: Reliable Data Transfer
RDT는 TCP 에서는 보장하지만, UDP에서는 보장하지 않음

rdt 1.0

error도 loss도 없는 상황

rdt 2.0

error는 있는 상황
error detection + feedback + Sequence number

error detection: checksum
feedback : ACK(acknowledge) / NAK(negative acknowledge)
client는 segment를 보내고 feedback으로 ACK을 받으면 다음 segment를 전송, NAK을 받으면 재전송
fatal flaw(치명적 결함) : feedback 자체가 에러일 경우에는 어떻게 할까?
=> 원래는 ACK인데, NAK을 받았을 경우 재전송.
=> server는 중복된 데이터를 다시 받게 됨. 이전에 받은 데이터를 지우고 이걸 써야할지. 아니면 원래 같은 데이터가 중복되는 상황인지 판단할 수 없음
=> 중복된 메세지인지 새로운 메세지인지 판단하기 위해 등장한 것이 Sequence number. 넘버링을 하면 중복 체크가 가능
Sequence number의 크기를 ++시키면 header의 크기는 무한대로 늘어나기 때문에 0과 1로 구분

rdt 2.2

feedback은 무조건 ACK을 하는데, Sequence number로 ACK NAK을 판단함

rdt 3.0

error도 loss도 있는 상황
error detection + feedback + Sequence number + Timer

client는 segment를 보내면서 timer를 작동 시키고 timeout이 발생하면 loss로 인식해서 재전송

Pipeline protocols

위의 rdt는 신뢰성은 보장이 되나 효율이 매우 좋지 못함
(데이터를 하나씩 주고 받으며 확인하는 절차이기 때문)
따라서 여러 데이터를 한꺼번에 주고 받을 수 있는 Pipeline이 등장.

go-Back-N

window 크기 만큼의 데이터를 한 번에 주고 받음
ACK(n): n번까지 잘 받았다는 feedback
receiver의 역할이 없음

ex) window size = 4,
1~4까지 보내고, window는 전진하다가 window가 4~7을 전달.
중간에 4를 전송하다 유실이 있었을 경우,
데이터 4, 5, 6, 7을 전달 받았을 때 모두 drop하고 feedback은 모두 ACK(3).
따라서 4~7을 다시 보내야하는 비효율 발생.
n만큼 다시 돌아온다고 해서 go-Back-N이라 명명함

Selective repeat

go-Back-N의 비효율을 개선
receiver가 buffer 역할을 해주기 때문에 중복되는 데이터를 보내지 않음
receiver는 들어오는 데이터가 순서가 맞지 않더라도 drop시키지 않고 가지고 있음
현재 window에 해당하는 데이터를 모두 받을 때까지 기다렸다가 한번에 이동.
Selective repeat: dilemma
header의 크기를 줄여야하는데 0과 1로만은 표현이 되지 않음. window크기와 같아도 문제가 발생. 따라서, seq는 window size의 2배 이상이어야함

3.5 Connection-oriented transport: TCP

TCP 특징

point-to-point
: 1:1 매칭

reliable, in-order byte stream
: 신뢰할 수 있으며, 순차적인 바이트 스트림

pipelined
: window size를 가변적으로 설정함(congestion과 flow control을 고려)

send & receive buffers
: 전달, 수신 버퍼가 존재함

full duplex data
: 양방향 데이터 통신

connections-oriented
: 데이터 통신이 일어나기 전에 3 way hand shake를 통해 connection을 맺음

flow controlle
: receiver 혹은 네트워크가 받아들일 수 있는 만큼만 전달(둘 중 최소값을 따름)

segment structure

포트번호 하나에 16bit씩 쓰기 때문에 2^16-1개의 포트번호 사용 가능
ACK(n): n-1번까지 잘 받았다는 feedback. 즉, 이제 n이 올 차례라는 의미
receive window는 지금 receiver buffer에 얼마나 빈 공간이 있는가를 알려줌
setting the timeout
: 데이터를 보내면서 timer를 설정하는데, 타이머의 시간을 어떻게 설정할지
: RTT(round trip Time = 패킷 왕복 시간)의 편차가 시시각각 편차가 크기 때문에 종합적으로 판단

reliable data transfer

TCP는 pipeline 방식이다.
timer expired => 해당하는 segment를 재전송
segment보내고 feedback으로 ack를 받음
feedback을 통해 loss를 파악하고 재전송, 따라서 신뢰할 수 있음

flow control

sender가 receiver의 용량을 고려해서 segment를 전달(receivr-driven)
빈 공간이 얼마나 있는지 정보를 segment에 담아서 전달
처음 sender가 보넀을때 receiver가 버퍼에 자리가 없다고 응답을 보내면 sender는 계속해서 아무것도 보내지 않는 상황이 발생할 수 있기 때문에, 아주 작은 데이터를 계속해서 보내고 feedback을 받으면서 receiver buffer의 동향을 살핀다.

connection management: TCP 3-way handshake

SYN 비트에 1을 담아 보내면 연결을 맺자는 의미.
3번째에는 client에서 segment도 함께 보냄.
closing TCP Connection

timed wait이 있는 이유
ack를 보내고 client에서는 close를 했는데, loss로 인해 server에서 ack를 받지 못할 경우 server에서는 계속해서 ack를 기다리게 됨. client는 이미 close를 했기 때문에 ack를 보낼 수 없는 상황. 따라서 약간의 여유를 두고 close를 함.

3.6 Principles of congestion control

TCP에서 segment loss가 일어날 경우, timer expire => 데이터 재전송이 일어남.
즉, 네트워크 상태가 좋지 않아서 막혀 있는데, 거기에 계속해서 재전송을 하면서 상태는 더욱 악화 됨.
네트워크 상황이 어떤지 어떻게 알아낼까.

Network-assisted congestion control

라우터에서 현재 네트워크 상황을 계속해서 피드백 해준다(?)
라우터에서는 데이터를 주고 받는 것만으로도 힘에 부치기 때문에 현실적으로 불가능함

End-end congestion control

TCP를 통해 segment를 보냈는데 반응이 느리면 네트워크 상황이 좋지 않다고 유추함.
TCP는 현재 이 방식을 채택함

3.7 TCP congestion control

x: MSS(Maximum Segment Size)
y: congestion window size

1. Slow start

병목현상이 있을 지도 모르니, 0부터 시작해서 빠르게(지수적) 증가

2. Additive increase

threshold를 만나면(수용량에 가까워지고 있으니), 보수적이고 천천히 증가

3. Multiplicative decrease

문제가 생기면 한 번에 확 낮춤. 공유 자원이기 때문에 각자 조금씩 줄인다고 해결되지 않기 때문
CASE 1. timeout을 통해 Loss를 감지하면 slow start로 돌아감
CASE 2. 3 duplicated ACK를 통해 Error를 감지하면 반으로 떨어뜨림
(다 잘 가고 있는데 하나만 문제인 상황)

여기서 말하는 갯수는 MSS(Maximum Segment Size)
window size(buffer)를 1MSS부터 시작해서 늘렸다 줄였다 한다는 의미
네트워크 상황에 따라 전송속도가 달라지고,
사용자 각각이 네트워크 상황에 영향을 미치기 때문에 서로 영향을 미치는 관계에 있음

TCP Fairness

TCP는 개개인들에게 형평성을 어떻게 보장할까?
먼저 쓰고 있던 사람이 처음에는 더 높은 속도를 가질 수는 있음
후발주자가 들어오면서 loss가 발생하면 Multiplicative decrease를 통해 모두가 속도를 반으로 줄임(MSS를 반으로 줄임)
늘리고 줄이고를 반복하다보면 결국 공평해짐

TCP 각각에게 공평하지만 사용자 단위로 TCP Connection을 많이 여는 사용자가 더 많이 가져가는 맹점이 있음