CH3-3

charrrming·2022년 6월 3일
0

Computer Network

목록 보기
6/10

TCP flow control (rwnd 사용)

- sender가 receiver의 버퍼를 오버플로우 시키지 않을 만큼만 보내도록 하는 것
- tcp 헤더의 receive window에 버퍼의 빈 공간 크기가 들어감

TCP connection management (3-way handshake)

데이터를 교환하기 전에, sender와 receiver는 handshake 해야함
state, seq#, rcvBuffer size들을 주고 받으면서 서로의 상태 정보를 교환함

* 2-way로는 부족함
- accept connection이 늦게 도착하면 timeout이 발생해 재전송을 함 
  -> 커넥션이 끝난 뒤에 request가 도착한다면 서버는 ESTAB, 클라이언트는 CLOSE인 경우 발생

* 3-way handshake
1) client가 Seq #를 임의로 지정하고, SYN 플래그 비트를 1로 설정한 segment를 전송
SYNbit=1, Seq=x // 클라이언트는 SYN을 보내고 SYN/ACK를 기다리는 SYN_SENT 상태

2) 서버는 클라이언트에게 요청을 수락(ACK)했으며 너도 포트를 열어달라는(SYN) 메시지 전송
x값을 확인하고 ACKnum=x+1로 지정, 서버측 Seq #인 y를 생성하여 segment 전송
SYNbit=1, Seq=y, ACKbit=1, ACKnum=x+1 // 서버는 SYN 응답을 받은 상태이니까 SYN_RECEIVED

3) 클라이언트는 서버에게 ACK를 보내고 연결이 완료됨
클라이언트는 서버의 응답을 받았다는 의미로 ACKnum=y+1로 설정한 segment 전송
이후 실제 데이터를 전송할 수 있는 상태인 ESTABLISHED가 됨
ACKbit=1, ACKnum=y+1	

서버도 ACK를 전달받고 ESTABLISHED 상태로 변함

상태 종류: CLOSED, LISTEN, SYNSENT, SYNRCVD, ESTABISHED

* Closing a TCP connection
- 클라이언트와 서버는 각각 자기쪽 연결을 닫음
- FIN bit를 1로 설정한 segment를 전송함	

Principles of Congestion Control

- flow control은 일대일이었지만 congestion control은 multiple TCP pair들에게 영향
- congestion: 너무 많은 데이터를 너무 빠르게 보내는 경우

* End-end congestion control (이 방법 사용)
- 명시적으로 호스트에게 혼잡이 발생했음을 알려주지 않음
- loss, dealy로 추측했어야 함

* Network-assisted congestion control
-  라우터가 직접적인 피드백을 해줌 ex) TCP의 ECN필드

* CWND(congestin winodw, 요 크기만큼 inflight segment 보낼 수 있음)
- Last byte sent - Last byte acked <= cwnd
- cwnd는 네트워크 혼잡에 의해 동적으로 조절됨
- cwnd만큼의 바이트를 보내고 RTT만큼 ACK를 기다림 -
	-> rate = cwnd/RTT (byte/sec)

AIMD

- packet loss가 발생할 때까지 전송 속도를 높이고 loss가 발생하면 속도 감소

- additive increase: loss가 발생할 때까지 매 RTT마다 1MSS씩 증가
- multiplicative decrease: loss가 발생하면 속도를 반으로 줄임
	-> 3개의 중복 ack가 발생하면 반으로 줄인다 (TCP Reno)
    -> timeout이 발생하면 1MSS로 줄인다 (TCP Tahoe)

TCP slow start (cwnd = 1MSS에서 시작)

AIMD 방식은 cwnd 값이 너무 천천히 증가한다는 단점이 있음 -> slow start는 이를 보완
초기 속도는 느리지만 loss가 발생할 때까지 급격하게 속도를 올림

- 처음 cwnd = 1MSSS, 매 RTT마다 2*cwnd
- congestion avoidance: sshthresh를 넘어가면 선형적으로 증가함
	cwnd + MSS * (MSS/cwnd) <- cwnd 1 증가시키겠다는 소리
- loss가 발생하면 sshthresh를 cwnd의 1/2로 감소시킴

최종 TCP congestion control 😎

* slow start
1) 초기화를 하고 (cwnd = 1MSS, ssthresh = 64KB)
2) 새로운 ack를 받으면 cwnd를 증가시킴
	2-1) cwnd를 2^n만큼 증가, dupAckCount = 0
    2-2) 새로운 segment 전송
3) 중복된 ack를 받으면 dupAckCount++
4) dupAckCount가 3이 되면 fast recovery로 보냄
    4-1) ssthresh를 cwnd/2, cwnd는 ssthresh+3, dupAckCount=0
    4-2) missing segment 재전송
5) cwnd가 ssthresh를 넘어가면 congestion avoidance로 넘겨서 선형적으로 증가

* congestion avoidance
1) 새로운 ack를 받으면 
	1-1) 1MSS만큼 증가, dupAckCount = 0
    1-2) 새로운 segemnt 전송
2) 중복된 ack를 받으면 dupAckCount++
3) dupAckCount가 3이 되면 fast revoery로 보냄
	3-1) ssthresh를 cwnd/2, cwnd는 ssthresh+3
    3-2) missing segment 재전송
4) timeout이 발생하면 slow start로 보냄
	4-1) sshthresh는 cwnd/2, cwnd는 1MSS, dupAckCount = 0
    4-2) missing segment 재전송
    
* fast recovery (fast retransmit 수행 후 congestion avoidance 수행)
1) dup Ack가 오면 
	1-1) cwnd = cwnd + MSS (선형 증가)
    1-2) 새로운 segment 전송
2) 새로운 ack를 받으면 congestion avoidance로 이동
	2-1) cwnd = ssthresh, dupAckCount=0
3) timeout이 발생하면 slow start로 보냄
	3-1) ssthresh는 cwnd/2, cwnd는 1MSS, dupAckCount=0
    3-2) missing segment 재전송

TCP CUBIC (AIMD를 좀 더 효율적으로 쓰자)

Wmax: congestion loss가 발생하는 시점의 sending rate
- 초기에는 급격하게 속도를 올리다가 Wmax와 가까워지면 천천히 보내자 -> x^3 그래프처럼 생김
- Linux에서 사용
- delay 기반의 congestion control (네트워크의 congestion 수준을 delay로 파악해보자)
- 길어진 RTT를 통해서 congestion을 감지

-> RTTmin을 구해두고, cwnd/RTTmin(throughput)을 해서, 이 값과 현재의 측정값을 비교
-> 차이가 많이 나면 cwnd 감소, 가까우면 cwnd 증가

ECN (explicit congestion notification)

ip와 tcp가 협업하여 혼잡이 발생했음을 명시적으로 알려줌

- 헤더 Tos에 01 또는 10을 마킹 <- ECN 사용하겠다는 뜻 (00이면 사용 안함)
- 혼잡을 감지하면 IP packet ECN에 11을 마킹함 
- destination은 ack의 ECE 비트에 1을 설정하여 sender에게 혼잡을 경험했음을 알림

Fairness

- Fairness and UDP: 치팅 가능 (혼잡 상황에섣 보낼 수 있음)
- parallel TCP connections
	data를 10개의 커넥션으로 나눠서 보냄 (꼼수)

QUIC: Quick UDP Internet Connections (HTTP3.0)

TLS, TCP에서 구현하던 보안/신뢰성을 QUIC이 제공해야함
- 하나의 QUIC 커넥션에는 여러 application-level의 stream이 multiplex 됨
- rdt와 security를 분리했고 얘네는 stream 단위
- congestion control은 single QUIC conenction 단위
- HOL Blocking
	1.1: 3개가 동일한 tcp 커넥션을 통해 전달되어서 하나가 잘못되면 재전송될 때까지 기다림
    3.0: 하나의 QUIC 커넥션 안에 여러 stream이 mux 됨 -> 에러 발생해도 다른 애들을 안 막음

0개의 댓글