Computer Network (3) : TCP (Transmission Control Protocol)
1. Transport Layer
Transport layer vs Network layer
■ Network layer: logical communication between hosts
■ Transport layer: logical communication between
processes
reliable data transfer
(in tranport & data link)
error / flow / congestion control
엔드시스템
IP , 어플리케이션: transport logical communication
3 way handshake + 3 control
transport 주요기능
multiplexing, demultiplexing (제공수단: 포트넘버)
= 하나의 인터넷 커넥션
1. 소스 아이피
2. 소스 포트넘버
3. 데스티네이션 아이피
4. 데스티네이션 포트넘버
UDP
- fire and forget
- UDP데이터 보내고, 보내는 데이터 속도를 TCP제어하는 방식
- 소캣 따라 TCP/UDP, sender: multi, receiver: demulti
- connection setup과정 없음
- elastic service
- LOSS처리 X handshake X
- checksum 에러 딕텍션
TCP
- connection oriented demultiplexing
- 서버 여러 소캣 열고 관리 / 처음 connection은 다른 포트넘버 (1대1 커넥션을 위함)
=-63dfiqas'23 reliable transmission
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
2. For reliable transmission
error control
ARQ (automatic repeat request) 에러 발생하면 ARQ 프로토콜에서 자동으로 사용자 어플리케이션 간섭없이 보냄
여러 알고리즘 (stop and wait / concurrent logical channel) (패킷 딜리버리 보장, out of order 발생 X), 하지만 data transmission에 필요한 capacity를 이용한다는 측면에서 부족
-> sliding window (go back n – 에러 발생하면 그 시점부터 끝까지 / selective repeat – 에러 발생한 놈만 다시 보냄)
+end to end = FEC적합 (멀리있는경우)
stop and wait
ack확실히 받고 보냄, 커넥션 열고 밴드위스 충분히 활용X
logical channel : 서브채널 여러 개 만들어 데이터 한꺼번에 보내고 에크 한번에 하지만 순서x -> 수신체에서 sequence packet number보면서 순서 맞춤
Sliding Window
리시버 벗어나는 양 받으면 버림
센더: 보냈지만 에크못받음 / 보내도되는 부분 / 상위 레이어 요청
리시버 : 상위 레이어 가져가지 않음 / 받을 수 있는 부분
stop and wait와의 비교
- 센더윈도 속해있는 데이터 한번에 보낼 수 있음,
- 애크 받아야 오른쪽 움직임 (reliable)
1) go back n : 받지 않은 것부터 쭉 보냄 -> 데이터 중복, 밴드위스 깎아먹음
2) selective repeat : 받지 못한 패킷만 다시 받게됨 (트랙킹 많아져 버퍼 커야함, 많은 메모리)
in order delivery (리시버 out of order 받더라도 슬라이딩 X 기다리고있는 패킷 도착해야 애크보냄)
cumulative ack 받은 패킷 중 가장 큰 패킷넘버 ack -> 이전 패킷 정상 수신이라고 생각
sequence number
max sequence >= send + rec window
send 사이즈가 rec 사이즈보다 큰 값을 가질 수 있도록 seq 설정
TCP dynamics
point to point connection
in order byte stream
full duplex : TCP 커넥션 통해 데이터
TCP에서 sliding control 구현
sener : index 사용, 보내지않은이유: receiver가 바이트스트림 알려줌
receiver : 내가 기다리는 부분 하양이라는 ACK보냄
cumulative ack 사용 -> 두번째 패킷와도 정상 처리
out of order인 경우 -> 첫번째 하양 index num 보냄
out of seg -> duplicated ack
out of order에서 정상적인 패킷 오면 -> immediate ack
RTT
estimated RTT = (1-a) X estimated RTT + a X sampleRTT
현재값 weight = 변화된 값 중시
과거값 weight = 축저값 중시
DevRTT = (1-b) X DevRtt + b X |sample – estimated|
변화량 / 크게 변하는 것 잘라내고 평균에 가깝게 변하는 것 유지
Timeout interval = estimated RTT + 4 X Dev RTT
TCP retransmission (error control)
loss / premature / cumulative
TCP segment의 sequence 넘버가 양쪽 합의 필요 TCP connection 맺고 head에 syn syn ack 보낼 데이터에 대해서 syn ack의 seq넘버 사용 syn ack (nogotiaion 끝을 센더 리시버 동일 인식)
Flow Control vs Congestion Control
■ Flow control
► Preventing senders from overrunning the capacity of the receivers
■ Congestion control
► Preventing too much data from being injected into the network, causing switches or links to become overloaded
■ TCP provides both
► Flow control based on advertised window
► Fongestion control
TCP Flow Control
rev Buffer의 앞부분은 TCP데이터 받은 부분, applicatin layer가 읽어가길 기다리는 부분
rev buffer에서 남아있는 부분(spare room_reciever window size, advertised window size): sender로부터 데이터를 더 수신할 수 있는 영역 = 리시버단에서 불필요한 손실없이 데이터받을수있는 최대크기
TCP ACK마다 지정해서 시스템이 허용하는 사이즈만큼 커질수있게끔 설정되어있어서 flow control이 동작거의 안하는것처럼 보이지만 작은 IT디바이스는 메모리 작기떄문에 특정 TCP커넥션에 버퍼사이즈크게할수없기 때문에 advertised window를 기반으로 flow control 진행
sender 와 receiver 잘 동작시키기위한 것 이 플로우컨트롤!!
(advertised window size 계산) = RcvWindow = advertisedwindow size = 전체 TCP커넥션사용 영역에서 application layer가 가져가지 않은 부분 / TCP receiver는 spare room을( advertised window사이즈)를 sender에게 알려주는 역할 센더는 무조건 receiver window사이즈보다 큰 사이즈의 데이터를 보내지않음
TCP congestion control
traffic jam = congestion이 발생했을 때 TCP send recei 어떻게 아는가?
1. 패킷 Loss :중간 노드에 많은 트래픽 몰려 버퍼가 꽉차면 뒤에 들어오는 패킷 다 잃어버림
2. 패킷스위칭 네트웤에서 각 노드마다 딜레이가 발생, transmission delay, propagation delay, processing delay =하드웨어로 구성(constant한 delay) 물리적 성질에 기반한 delay -> queiengi delay 만 늘어나게됨 / long delays
congestion avoidance = AIND algoritm
Host와 연결 / 두개의 커넥션이 하나의 링크 버퍼를 공유 / 링크가 처리할 수 있는 속도보다 많은 데이터를 host A,B가 함께 보낸다면 그 링크가 가지고있는 메모리에 많은 데이터 쌓여있음 = 큐잉딜레이 / 링크 버퍼가 무한대라면 무한개의 TCP seg가 쌓여있음/
두개의 커넥션이 하나의 바틀넥 링크 각 커넥션은 링크가 허용하는 밴드위스의 50퍼센트 정도까지 사용할 수 있음 (long term) , 50% 넘어가면 (람다 in 람다 out, 주고 받는 데이터)
바틀넷 capacity가 c일경우
람다 out은 1/2c보다 더 좋은 속도로 받을 수 없음 (람다인이 아무리 속도를 높여도 바틀넥 링크 캐파가 1/2c가 최대이기 때문에)
이전에는 congestion link가 무한대로 capa기 때문에 packet loss없음, 다음 예시는 c가 고정되어있기 떄문에 링크의 transmission speed보다 더 큰 속도로 도착하게되면 버퍼 꽉차고 뒤에 패킷은 잃어버리게되고 retransmission이 일어남
해당 상황을 그래프로
첫번쨰: congestion control이 완벽하게 이루어져 retransmission과 loss가 발생함에도 불구하고 receiver가 받느느 / reception rate가 R/2 =good put = effective transmission rate / TCP가 data transmission하느라 굉장히 바쁜데 대부분이 retransmission이나 packet loss나 딜레이로 인해서 retransmission때문에 바쁘다면, effective rate굉장히 떨어짐
두번째: loss 발생/ app이 TCP한테 보내라는 데이터가 두번 이상 보내게되는 상황 발생, 람다인이 R/2만큼 보내더라도 람다 아웃은 그보다 적을 수밖에 없음 (패킷로스로 인한 재전송) 그래서 그 차이 (R/2와 실제 람다아웃) = 패킷 로스로 인해 재전송한기위해 사용된 네트워크 밴드위스를 뜻함
세번쨰: 로스 뿐만 아니라 Timeout value잘못설정되어 딜레이된 패킷에 대한 전송과 그것에 대응되는 ack가 도착하기전에 타임아웃 발생해서 데이터 다시 보내게되는 상황
LOSS도 발생하고 delayed transmission이 발생해서 네트워크 밴드위스가 loss packet 재전송하기위해 낭비되고 동시에 delayed packet에 의해 낭비되는 상황
Causes / costs of congestion : Scenario 3
다른 인터넷 플로우와 섞인다는 사실 간과해서는 안됨
서킷 스위치 네트워크처럼 센더와 리시버 사이 데디케이트 된 커넥션 맺게되면, 다른 flow의 영향을 받진 않지만 현재 인터넷은 패킷단위 네트워크이고 컨제스쳔 일어나는 링크에서 영향을 미치게됨
빨 플로우 : 두개의 링크 오른쪽아래
녹 플로우 : 두개의 홉 지나 왼쪾아래
파 플로우(패킷) : 두개 거쳐 오른쪽위
핑 플로우 : ~
빨 플로우속도 높이면 위 오른쪽 컨제스티드 스위치가 됨 (큐렝스 늘어남) 딜레이 늘어남과 LOSS로 인한 retrnasmsision / 그리고 그것이 파랑색과 연두에 congestion
특정 플로우 증가시키면 good put이 좋아지다가 다른 플로우에 영향 미치면서 점점 낮아짐
TCP congestion control 잘 제어될 수 있도록
flow control: sender와 receiver 속도 맞지 않을 경우 receiver가 취할 수 있는 속도보다크지않게끔 advertised window 사용, advertised window보다 큰 TCP seg보낼 수 없게끔 하는 것 (리시버단의 상황을 설명하기위함, 이거보다 많이 보내면 안된다)
congestion control: (네트워크 상황을 설명하기 위함)
둘은 and조건! (둘 다 참이어야 함)
congestion window사이즈 늘어나면 많이 보내고 = congestion많이 일어나지 않아 많이 보내고
줄어들면 적게 보내고 = =congestion 많이 일어나서 보내면 안됨
어떻게 핸드링?
내가 지금 사용할 수 있는 밴드위스보다 더 사용할 수 있는지 없는지 확인할 수 있는 작업 필요
패킷 로스와 딜레이 발생했을 때 어떻게 해야하는가? 가급적이면 빠르게 속도를 줄이는 법이 필요함 congestion window(네트워크 상황)를 이용해서 속도조절 / 어떻게 congestion window를 줄이고 늘이냐 (줄이면 적게 보내고 늘이면 많이 보냄) -> contestion발생됐을 때 빠르게 줄이고 congestion발생 x지만 조금씩 밴드위스 늘이고싶을 때 늘임
specific strategy
logical한 시계를 가지고 congestion 조절 -> RTT이 하나의 logical 한 시계 / 모든 TCP 커넥션은 logical한 시계 만들수있고 이걸 이용해서 congstion 늘였다 줄였따 하는 것이 self clocking -> 데이터 보내고 ack받을 때 congestion window slicde를 늘릴건지 줄일건지 언제 실행할건지 결정하는 것이 clocking / ack받고 congestion이 일어나지 않았다고 생각하면 congestion window size에 추가로 하나의 max seg사이즈만큼 증가시킴 -> additive increase
증가시킬때는 조금씩 증가시키고 줄일때는 확줄임 AIMD 알고리즘이 네트워크상황에따라서 congestion window변경하는 알고리즘
end to end control
(중간에 congestion 발생했는지 알려주지않음)
한번에 보낼수있는 데이터 양은 congestion window size 보다 작거나 같다
같은건 이해하는데 작은건? -> flow control 사용했을때 advertised windwo 사이즈가 congestion window사이즈보다 작은경우 두 contorl모두 만족시켜야하기떄문에 두개의 advertised windwo와 congestion window 중 미니멈값이 현재 내가 보낼수있는 최대가 되는 것 (속도…?)
속도 / rate = RTT동안의 하나의 CongWIn보내기 때문에 = COngwin/RTT
Three mechanisms
1. AIMD -> congestion overhe…단계 오버헤던스 단계? (안정된 영역)
2. Slow start -> 처음 커넥션 열었을 때 일어나는 행동
3. Conservative after time out events -> TCP 가 congestion일너났는지 아닌지 확ㅇ니하기 위한 정보가 timeout & delay
time out의 경우 큰일이라 생각하고 다시 시작함 /
AIMD알고리즘
늘일때는 조금씩 줄일때는 확
복습 필기
TCP congestion control
gooput을 through put과 일치시키기 위한 멬니즘
end to end control은 어떻게 이루어지는가? flow control에서 windwo는 receiver가 받을 수 있는 데이터보다 큰 양을 보내지 않겟다는 것 / congestion cotrol은 네트워크가 허용하는 congestion window보다 더 많이 보내지 않곘다라는 것
congestion window는 어떻게 정하는가? 내가 사용할 수 있는 트래픽의 양 = conegstion window 그리고 그것의 사이즈를 조절함으로써 congestion control하겠따는 것이 매커니즘
그럼 어떻게 congestion windwo사이즈를 정할 것인가?
기본적으로 두가지의 알고리즘이 TCP congsetin control에 구현 / 그 두개의 알고리즘이 congestion windwo 사이즈를 결정
Three mechanisms: 순서 : 2 -> 1 -> 3
1. AIMD : 내가 데이터를 보내고 ack를 받는 순간이 스무스하고 time out일으키지 않았따면 조금씩 내가 보낼 수 있는 양을 늘이는 것,
AI (additive increase) : 내가 지금 사용할 수 있는 congstin size가 n개이고 n개 모두 정상적으로 ackf를 보냈다면 / n개의 tcp seg가 모두 최대길의 tcp seg라고하면 / 최대길이의 tcp seg사이즈만큼 추가 , 이전에 보낸게 n개라면 그 다음에는 n+1개 보내는 것
MD (Multiplicated decrease) :
2개의 시그널로 multiplicated decrase
1) timeout이 발생
congestion 일어난 신호 -> timeout 생기고 RTT 이 잘못된 것 = congestion windwo사이즈만큼 한번에 보내는데 그 데이터 모두 잃어버리게된 문제 -> 다시 시작해야됨 +
2)duplicated ack
내가 보낸 데이터 일부가 잃어버린 경우 out of order발생 tcp ack는 receiver기다리고있는 tcp seg중 제일 작은 seq num 가지고있는 tcp seg에 대해서 ack을 중복으로 보냄 = out of order reception발생 = 새로 보내야한다느 ㄴ의미
특히 duplicated ack이 발생했을 때 congestion window사이즈 m을 1/2m으로 확줄임
- Slow Start : 처음에 TCP connection 열렸을때 내가 사용할 수 있는 트래픽이 어느정도인지 빠르게 찾아내는 것.
- Conservative after timeout events
timeout 발생 = 모든 데이터 잃어버린 경우 처음부터 시작 = slow start부터 다시 시작… (3번 맞아? 몰름) 최악의 경우
AIMD 알고리즘
어떻게 congestion window size를 정할 것인지를 정하기 위함
1. congestion signal (duplicated ack or time out) 에 반응
2. 그런 신호가 오지 않았다면 더 사용할 수 있는 네트워크 밴드위스 사용할 수 있지 않은가 -> 그것을 proving
New TCP state variable
(리눅스에있는 TCP protocol 뒤져보면 congestion window size가 variable로 정의되어있음
receiver가 보내는 flow control 대상의 adevertised window size와 congestion windwo size 중 minimum한 것을 사용 / min값이 정해지면 지금당장 보낼수 있는 사이즈 (Effective window size)를 결정할 수 있음 , 현재 transmission data/ack를 제외한 나머지 영역이 Eff win사이즈가 되는 것
signal
가장 명확한 signal: time out (error control할 때 사용, erroro control에서 타임아웃 발생하면 e.c는 다시 transmission함) 벗, congetion 문제에서 timeout은 심각한 문제임 ! -> min값에서 이미 보낸 데이터 뺀 부분인데 아무것도 답이 않왔다면 심각한것
( 순서대로 도착하는 패킷은 delayed ack / out of order로 들어오면 immediately sending / out of order상황에서 빈홀 채우는 패킷 들어와도 바로 패킷을 보냄 = cumulative ack) 즉 데이터 받으면 ack을 전송하게되어잇는 것이 TCP인데 이 말은 sender가 rec부터 아무것도 답을 받지 못했다는 것이고 이것은 packet loss가 발생했다고 보고 congsetion window size를 restart 시킴 / congestion이 발생했을 때 발생하는 것은 아니지 않는가? -> 패킷 전송하다보면 오류나 에러일수도 있는데 초기에는 맞지만(Retransmission) 지금 유선 네트웤에서 에러는 거의 없기 때문에 (패킷 자체 전송에러 일어날 확률은 congestion error보다 훨씬 낮다) 때문에 심각한 congestion이 일어났다고 봐야함 (무선은 또 다른 문제임!)
AIMD 알고리즘 돌아가는 TCP window size 그래프 (Sawtooth trace)
증가되다가 반으로 줄이고~ (톱날같다고 해서 sawtooth trace)
1/2 줄이는 이유: 반으로 줄이는 것이 대부분 네트워크 상황에서 적절
connection 을 열고 congestion window사이즈 알고난 후 AIMD를 사용하는데, 그렇다면 최초에 congetstion size어떻게 결정?
AIMD그냥 사용할수도 있지만 100KB에서 늘리면 많은 시간이 사용됨, (너무 큰 overhead) 그래서 나온 것이 slow start -> (seg size1부터 시작되기 떄문에 이게 필요) 이름 잘못지음 (exponential이 더 적절) /
Slow start
처음 conwin size작게 출발 (내가 사용할 수 있는 밴드위스 적은데 처음에 크게 잡으면 데이터 다 잃어버리고 절반씩 줄어들게되면 0이 되어 데이터 보낼수없게됨) max seg 1개보낼 양만큼 cong win initialize하고 응답이 올때마다 x2개씩 늘이는 방식 (aggressive 한 알고리즘)
1. 언제사용? tcp 처음 열었을 때 어떤 것이 적합한값인지 모를 때 빠르게 proving하기 위해 사용
2. congestion signal 중 (duplicated-ack or time-out) duplicated ack은 congestion일 확률이 높기 때문에 congestion window size조절 = MD 를 통해 극복할 수 있지만 time-out은 내가 설정한 RTT가 완전히 잘못되었거나 데이터 다 잃어버렸다는의미이고 내가 트래킹하던 모든 파라미터들이 잘못된 것일 수 있기 떄문에 처음부터 다시 시작 이때 slow start실행
slow start 와 AIMD 를 구분하기 위한 parameter필요 -> slowstart threshold value (SSthresh -> linux커널 내에 존재) 그래서 현재 conges win size값이 threshold value보다 작으면 slow start / 크면 AIMD 진행
Threshold value 결정?
1. 처음에 maximum windwo size로 결정
2. time-out 발생하면 현재 congestion window size의 절반을 SSTHRES로 설정하고 -> slow start와 AIMD 페이스를 줄이게되는 것
그렇다면 maximum window size는 어떻게 결정?
초기에는 logical하게 무한대로 둠
과거에 성공했던 value를 기반으로 default 값으로 설정
timeout 발생후 slow start -> 그떄의 slow threshold value는 어떻게 결정 ? -> time out 발생 직전 congestion window size의 절반을 지정
TCP 버전
1. TCP tahoe
2. TCP reno
3. TCP new reno
(2,3 = default TCP)
(1,2,3 = TCP congestion control의 뼈대를 만듦)
앞의 설명은 reno기준
TCP taboe -> (휴양지 이름) AIMD 페이스가 없음, congestion signal은 모두 slow start부터 시작 / 부담 크기 때문에 손해 /
time out 과 d.a구분하여 duplicated ack일 때 AIMD를 사용하자 -> reno
new reno -> duplicated ackㄹ여러번 왔을 때 congestion windowo size 너무 작아지니까 한번한 작아지는 것
Fast Retransmit
- time out이 심각한 문제
- duplicated ack는 packet switch network에서는 일반적인 일, out of delivery 있을 수 있지만 만약 비어잇는 TCP seg를 잃어버릴 수도 있지 않느냐? time out 발생하기 전에 빨리 보내는 것이 좋음 (원래 error control 은 time out 발생해야만 다시 패킷 보내느거였음) + time out value 자체가 RTT 에 weighted average하고 margin집어넣어 만든 값이라 크기도 하고 다른 패킷 도착했는데 그것만 안온거면 그것만 다시 전송하면 되는 문제 – packet hole이 발생했을 때 그것만 retransmission하면되겠따 -> 그럼 몇번의 duplicated ack받았을 때 재전송? -> 3duplicated ack -> fast retransmission (그것보다 적은 개수는 packet swiching net에서는 out of delivery있을 수 있기 때문에 허용, 3개부터 fast retransmission)
Fast Recovery (TCP Reno에서 처음 들어온 것)
3 d.a 과 timout 구분해서 3.d.a는 속도만 줄이면 되지 않을까라는 아이디어에서 옴
slow start 거치지 않고 congestion window size 절반 줄여서 보내는 것 (이때 SS threshold value도 같이 반으로 낮춤) -> congestion control 이 할 수 있는 일은 AIMD (congestion avoidance) 알고리즘임
3 d.a 만나면
fast retransmission + fast recovery
긴시간동안 TCP conection 유지된다면 AI 증가하다 반으로 떨어지고 반복
사다리꼴 하나당 로스가 발생
thoughput 을 예측할 수 있음
(참고만)
TCP Fairness : 공정함, 하나의 congestion link를 통과하는 TCP flow가 여러 개일경우 각 flow가 동일한 밴드위스를 가진다라는 것 / TCP는 기본적으로 fair함 /
밴드위스 R인 보틀넥 통과하면 각 TCP flow는 밴드위스 R/K을 받음
graphical 설명 (긴시간동안 TCP 커넥션 진행될 때 두개의 커넥션이 어떤식으로 equal 한 밴드위스 찾아가는지를 설명하는 그림)
파란색: 각 커넥션이 다 사용할 경우 /
붉은선: 최대 보낼수있는 네트웤밴드위스 초과하는 순간 congestion 발생, 반으로 줄어듦
3개이상 표현할 수 없고 두 개가 동일한 RTT가질때에만 가능
UDP는 fair하지 않음
공격적인 트래픽,
