컴퓨터네트워크 중간 전 정리

시험 전날 야매로 정리한거라 전체적인 내용 정리는 따로 해야된다

 

• chap 1

라우팅 : 출발 지점에서 목적지까지 경로를 결정

포워딩 : 포워딩 테이블을 보고 해당하는 포트로 패킷을 전달

패킷 스위칭 - 큐잉, 

서킷 스위칭 - tdm, fdm

스푸핑 - 패킷의 출발지 주소를 변조, 잘못된 정보를 주거나 공격

스니핑 - 패킷 도청

 

• chap2

http 1.0  - 비지속, 매번 새로운 걸 요청할때마다 tcp 연걸

http 1.1 - 지속, 한번 해둔 연결을 이어서 사용,  HOL 문제 발생

http 2.0 - http1.1은 FCFS 파이프라인이라 HOL(병목)이 일어나는걸, http 2.0은 패킷을 분할해서 RR 방식으로 병목을

없앰

 

쿠키/웹캐시 

쿠키는 클라이너트 측에 남는다

처음에 유저가 특정 http 요청을 보내면 서버의 데이터베이스에 유저 정보가 저장되고 서버가 쿠키를 클라에게 보내고

다음에 접속할때는 쿠키가 있으면 쿠키의 데이터를 읽는 방식으로 유저의 정보를 가져온다

웹 캐시 - 클라와 서버가 직접 연결하는게 아닌 클라와 더 가까이 있는 웹 캐시 서버에 요청을 하는 방식

처음에는 클라 - 서버가 연결되고 그 다음부터는 클라이언트가 캐시 서버에 데이터를 요청한다.

일정 date 이후로 바뀐 데이터가 있으면 바뀐 데이터만 가져온다

 

p2p tit - for - tat

4+1, 가장 전송률이 좋은 피어를 10초마다 4개 골라서 청크를 전송하고, 30초마다 랜덤 피어를 추가로 선택해서

청크를 보낸다

 

 

• DASH - 동적으로 비디오 전송률을 조정하는 방법

DASH에 대한 논문들 소개

• 유저 경험을 최적화 하기 위해서 비디오 퀄리티(720,480,1080)를 네트워크 상태에 따라 동적으로 조정하는 방법

핵심 - ABR 알고리즘, QOE 모델

MPEG-DASJ,HLS

• ABR 알고리즘

네트워크 처리량을 최적이 되게 계산하는 방법

• FESTIVE - 과거 20개 세그먼트의 85%

• BBA - 버퍼 레벨에 따라서 결정, 버퍼가 찰수록 처리량을 늘려서 버퍼를 빠르게 비우는 방식

• MPC - QOE를 정리 

QOE - 유저가 불쾌한 경험을 안하게 

QOE Metric = 화질퀄(높을수록 좋다) - 화질변경횟수합 - 버퍼링 횟수합 - 시작 딜레이(길면 화난다)

• FASTMPC - 테이블 형태로 미리 계산해두고 참조한다

• Pensieve 딥러닝으로 처리량, 처리율,버퍼로 이루어진 상태를 넣어서 어떤 화질이 좋을지, 유연함

MPC가 보수적으로 계산했다면, Pensieve는 데이터가 압도적이니 좀 더 낙관적으로 계산한다

• SENSEI - QOE 중심, 하이라이트 구간(슛할때 전송 끊기면 분노)

무작위 버퍼링이 있는 영상을 사람들이 보면서 QOE를 미리 계산하고 하이라이트까지 버퍼를 모아뒀다가

하이라이트에서 높은 전송률을 보여줌

 

•CDN

수많은 유저에게 컨텐츠를 제공하는 방법 2가지

1. 매우 큰 서버 하나 - 쓰지 않는다..

2. 각 지역에 서버를 복사해서 두고 그 복사본에 접근하게 한다

2-1 enter deep : cdn 서버를 곳곳에 분산

2-2 bring home : 큰 큐모의 클러스터를 적은 숫자로 배치, enter deep보다 처리율이 나쁘다

 

 

 

• Transport Layer

RTT

평균 rtt = 평균 rtt * (1-a) + a * 샘플 rtt  (a는 0.125)
DevRTT(RTT변화율) -> (1-b)* devrtt * b * ( 샘플 rtt - 평균rtt) (b는 0.25)

 

• 멀티플렉싱/디멀티플렉싱

멀티플렉싱 - 여러 소켓에서 온 데이터를 트랜스포트 헤더를 붙여서 네트워크 계층으로? 보낸다

디멀티플렉싱 - 받은 세그먼트를 헤더를 보고 적절한 소켓으로 전달한다.

네트워크 트래픽 - 가장 낮은 전송률이 된다
1kbps - 1초에 1000비트, 바이트 말고 비트다

tcp보다는 udp 상에서 애플리케이션 구동을 하는 이유

->tcp의 혼잡제어를 피하고 싶거나 신뢰성 있는 데이터 전송이 필요하지 않아서
멀티미디어 데이터를 종종 tcp로 보내는 이유?

->방화벽이 udp를막아서

 

tcp 세그먼트 크기 단위 - 바이트, 첫 세그먼트 90, 두번째 세그먼트 110이면 세그먼트의 데이터 양은 20

 

rdt 

1.0 신뢰성 있는 전송에서의 상황 - 완전히 믿을수 있는 전송이기에

송신자는 패킷을 보내고 수신자는 패킷을 받는 동작만 한다

-

 

rdt 2.0 

ack/nak, stop and wait, 한 패킷 보내고 응답 올때가지 기다림

세그먼트를 받았고, 세그먼트가 깨지지 않은거면 ack을 보낸다

-문제점

ack 이나 nak 응답 자체에 문제가 생기면 송신자는 무슨 일이 있는지 알 수 없음, 해결하기 위해서는 순서를 알수 있어야함

 

rdt 2.1 

패킷에 번호를 붙여서 전송

송신자 - 0번을 보내면 0 ack를 기다리는데 안오거나 nak이 오면 재전송

수신자 - 0번을 요청했을때 패킷이 안깨지고 제데로 0번으로 왔으면 ack 전송

깨지지 않았지만 1번이 오면 1번 ack을 전송

(송신자가 0번 ack을 기다리지만 1번 ack이 온거면 0이 제데로 안 간 걸 알 수 잇음)

패킷이 안깨지고, 0번이 제데로 오면 0의 ack을 전송한다

 

rdt 2.2

ACK만 사용하는 프로토콜이다

송신자 - 0번 패킷을 송신자가 보내고 0번 ack을 기다리는데 깨졋거나, 1번 ack이오면 데이터를 재전송한다

수신자 - 1이 오면 1 ACK을, 0이 오면 0 ACK을 보낸다

 

rdt 3.0 

타이머를 사용해 패킷이 손실/지연되는 상황을 검출한다

 

송신자

1. 0번 요청이 오기를 기다리고 요청이 오면 0번 패킷을 보내고 타이머를 시작해 ack 0을 기다린다

2-1. 응답이 변조되지 않고, ACK0이 제데로 오면 타이머를 멈추고 1번 요청이 오기를 기다린다

2-2. 응답이 깨지거나 1번 ACK이 오면 계속 대기하다, 타임아웃이 되면 데이터를 재전송하고 타이머도 다시 시작한다

ppt53~ 그림 보기

 

타임아웃이 일어나서 송신자가 패킷을 재전송할때, ACK이 딜레이되거나 premature timeout이면 수신자에게 같은 패킷이 두번 전송되고, sender에 같은 ack이 두번 도착하면 두번째 ACK은 무시한다

 

 

rdt 3.0

패킷 보내는데 걸리는 시간 = 패킷량/초당 전송량+rtt 일때 보통 rtt가 패킷/초당 전송양보다 훨씬 더 길기에

stop and wait로 성능을 생각해보면 (패킷양/전송량) / (패킷양/전송양) + RTT로 매우 효율이 낮게 나온다 

파이프라인을 이용해서 3개의 패킷을 보낸다고 하면 효율이 3배가 된다

 

GBN

슬라이딩 윈도우로 패킷을 보낸다

receiver가 패킷을 받고 ack을 보낼때는 연속된 N번째에 대해서 보낸다

ex) 0, 1, 2(패킷 사라짐), 3, 4 이렇게 오면 0ACK, 1ACK 까진 정상적으로 하고 2ACK가 버려졌기에 3은 온 패킷을 버리고 연속된게 0,1 까지니까 1ACK을 보냄, 4도 3처럼 온 패킷을 버리고 1ACK을 하고

패킷 2는 타임아웃이 되서 패킷 2부터 2,3,4를 재전송한다

 

중간에 누락되면 그 이후에 오는 ack들은 다시 그 패킷이 보내지기전까지 다 버려지고 전부 재전송된다

단점 - 한 패킷이 빠졌을때 많은 패킷을 재전송해야 될 수도 있다

ppt 65p

 

SR

SR은 빠진것만 보내준다 68p

0123 으로 올때 2가 누락되면 3,4는 버퍼에 넣고 ack3,ack4를 보낸다

pkt2가 타임아웃되서 재전송되면 pkt2,3,4를 보내고 ack2를 보낸다

SR에서 윈도우 사이즈는 seq의 크기/2 이하여야한다

그 이상이면 패킷을 재전송하는 것과 0,1,2,3,4... 다음 다시 0 이 됬을때 0을 구분할 수가 없다

SR 윈도우 크기 <= SEQ/2 !

 

tcp 흐름 제어

송신자는 infilght 데이터의 양을 rwnd를 이용해서 조절한다

 

• 버퍼의 크기

수신 버퍼에 마지막으로 들어온 패킷 - 수신 버퍼에서 마지막으로 읽은 값 =< RcvBuffer

 

• 수신 윈도우의 크기

송신측에서 마지막으로 보낸 값 - 마지막으로 수신측이 보낸 값 <= rwnd(수신 윈도우다)

rwnd는 버퍼가 넘치지 않는 것을 보장한다

 

tcp 연결을 종료할떄 

클라 -> 서버  finbit 보내고

클라 <- 서버 ack, finbit를 보내고

(이제 더 이상 데이터를 보낼 수가 없다)

클라 -> 서버 ack을 보낸다, 보내고 나서 2 * max segment만큼 클라가 기다린다

 

• 혼잡 제어 시나리오

 

• 무한 버퍼, 처리량이 R일때 1개의 라우터에 2개의 flow가 있는 경우

r/2가 처리량의 최대가 되고, 딜레이는 r/2에 근접할수록 커진다

 

• 유한 버퍼, 처리량이 R일때 1개의 라우터에 2개의 flow가 있는 경우

기존과 다르게 유한한 버퍼 사이즈를 넘기면 버퍼에 들어가지 못한 소실된 패킷이나, 타임아웃된 패킷을 재전송하게 된다

처리량이 재전송때문에 r/2에 도달하지 못하고, 불필요한 재전송되는 패킷도 생겨 패킷이 중복되고 처리량이 더 낮아진다

시나리오의 2개의 버퍼에서 모두 타임아웃이 발생하면 처리량이 r/4까지 떨어지게된다

 

• 4개의 송신자, 많은 숫자의 hop(경유지), 타임아웃/재전송

한쪽의 전송과 재전송이 늘어날수록 다른 쪽의 처리량이 줄어들게된다

그래프는 재전송이 일어나기 전까지 처리량이 증가하다, 재전송이 일어난후 부터 감소해서 r/2에 가까워지면 처리량이 0에 가까워진다

 

종단에서는 명확한 피드백이 오지 않는다, 라우터가 혼잡하다는 것을 알려준다

 

•AIMD - 톱니처럼 생긴 처리량 그래프, 처리량이 ssthresh에 도달하면 반깍 후 1씩 증가하다 다시 반깍을 반복..

 

• CWND <- inflight한 패킷 + 사용 가능한 공간의 양(윈도우 남은 공간 크기), 네트워크 혼잡에 따라 계속 동적으로 크기가 변한다

• tcp 전송률은 cwnd/rtt

 

• slow start - 1..2..4..8..2^n 형태로 패킷 로스가 날때가지 증가한다

• tahoe는 - ssthresh를 만나면 1씩 증가하다 timeout이나 3 duplicated ACK을 만나면 cwnd를 1로 줄여버린다

• Reno는 타호와 다르게 ssthresh를 만나면 1씩 증가하다 3 duplicated ACK를 만나면

  cwnd는 cwnd/2 +(중복 ACK의 갯수, 여기서는 +3)가 되고 선형적으로 증가하게 된다 

• tcp 큐빅 - 손실이 발생하면 윈도 크기/2 하고 시간이 지날수록

(Wmax(윈도 크기가 max가 되는 시간) - 현재 시간)^3 만큼 증가시킨다

• tcp 베가스 - 경로가 혼잡하지 않으면 rtt중 송신지에서 측정한 최소값을 찾아서

처리율을 cwnd/rtt중 최소값으로 만든다

 

•tcp가 공정한가?

2개의 tcp 세션이 있으면 결국 처리량이 원점에서 45도각도의 화살표를 따르게 된다

하지만 어느 어플리케이션이 다중 병렬 연결을 사용하면 전송률을 불평등하게 많이 가져가게 된다

 

 

•QUIC

1 핸드세이크로 연결

http/2(slim)+quic이 udp에서 동작, http3, 독립적으로 신뢰적인 데이터 전송