컴퓨터 네트워크 - Chap 3. Transport Layer
rdt3.0 - stop-and-wait protocol
- 패킷을 보내고 stop
그리고 ack을 받을 때까지 wait - reliable 한 프로토콜
1.
- sender는 패킷을 보내고 바로 타이머 잼
- receiver는 패킷을 제대로 받았다면 받자마자 ack을 보냄
2.
- timeout이 날 경우 보낸 패킷 or ack이 loss가 났다고 판단
-> 재전 - 재전송할 때도 타이머 잼
3.
4.
- ACK이 delay 됐을 경우 메커니즘
- ack1이 안 왔으니 패킷 1번 재전송
-> akc1이 왔으니 다음 패킷 전송 - 패킷을 두 번씩 보내게 돼버림
Pipelined protocols
- ack 받기 전까지 보낼 수 있는 packet이 여러 개 있도록 하는 프로토콜
- 이것도 물론 reliable 한 프로토콜
- pipeline(window)의 크기: ack을 받기 전에 보낼 수 있는 packet의 개수
- stop and wait 프로토콜은 pipeline의 크기가 1이다.
1. Go-back-N
- sender는 ack을 받지 않은 패킷을 N개까지 가질 수 있다.
- receiver는 cumulative(누적) ack만 보낸다.
- 2번 패킷이 loss 돼서 receiver에게 도착하지 않았다
그 후 3번 패킷을 받았다.
-> 3번 패킷 폐기하고 ack1 재전송 - sender는 중복된 ack1 무시
- 2번 패킷에 대한 타이머가 timeout 되면 다시 순서대로 누적해서 2,3,4,5 패킷 보내기.
- 보낸 패킷에 대한 ack을 받을 때마다 window에서
보낼 패킷번호를 한 칸씩 민다.
-> 중복된 ack은 무시한다.
2. Selective Repeat
- sender는 ack을 받지 않은 패킷을 N개까지 가질 수 있다.
- receiver는 각 패킷에 대한 individual(개별) ack을 보낸다.
- 2번 패킷이 loss 되고 3번 패킷이 도착했다.
-> 3번 패킷은 buffer에 보관하고, ack3을 보낸다. - sender는 ack1을 받고 ack3을 받았다.
-> ack3을 받았다고 기록해 둔다. - 2번 패킷이 timeout 되면 2번 패킷만 재전송
- 2번 패킷을 받으면 buffer에 보관되어 있던 패킷들을 이제 deliever
TCP
- reliable, in-order byte
- pipelined
: TCP/IP를 사용하는 모든 호스트들은
송신하기 위한 것과 수신하기 위한 2개의 Window를 가지고 있다.
호스트들은 실제 데이터를 보내기 전에 3 way handshaking을 통해
수신 호스트의 receive window size에 자신의 send window size를 맞추게 된다 - full duplex data
: 양방향 전송가능 - 연결지향
: 연결할 때는 3-way handshaking
연결종료할 때는 4-way handshaking - flow controlled
: 송신 측과 수신 측의 데이터 처리 속도 차이를 해결하기 위한 기법.
-> 수신측보다 송신 측의 속도가 더 빠를 경우 문제가 생김.
수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있으므로,
packet을 지나치게 많이 받지 않도록 송신 측의 데이터 전송량을 조절하는 것.
(수신 측이 현재 자신의 상태를 feedback 함) - cumulative ACK: 누적응답
- timeout 값은 RTT보다 길게 설정
너무 짧으면 불필요한 재전송이 생기고
너무 길면 loss에 대한 reaction이 느리다.
- seq=42, ack=79, 문자 하나를 보내면
받은 사람은 seq=79, ack=43을 보낸다.
-> seq=상대 ack(n)
ack(n)=상대 seq(n)+ byte 수
TCP ACK generation
1. event at receiver
기대했던 세그먼트가 도착했고 이전까지 모든 데이터들은 ACK을 보낸 상태
receiver action
다음 세그먼트를 500ms까지 기다리고, 다음 세그먼트가 오지 않으면 ACK을 보낸다
2. event at receiver
기대했던 세그먼트가 도착했고, 다른 세그먼트는 ACK을 pending(기다리고 있음)
-> 첫 번째 건 ACK을 기다리고 있고, 두 번째 건 ACK이 도착함.
receiver action
순서대로 도착한 두 개 세그먼트 모두 수신응답이라는 의미로 누적 ACK 하나만 즉시 보내라
-> 각 패킷마다 모두 ACK을 보내면 2N개의 ACK이 소모됨.
그러나 패킷을 2개 받을 때 수신 ACK을 하나만 보낸다면 3N/2개만 필요하다
3. event at receiver
순서에 어긋나는 세그먼트가 도착하면 기다리고 있던 seq 번호보다 클 수밖에 없다.
-> gap이 생긴다.
receiver action
즉시 다음 ACK번호를 보낸다
-> 2번을 받고 5번을 받았다면 3번 ACK을 보내서 3번이 안 왔음을 알린다.
4. event at receiver
gap을 메꾸는 세그먼트 도착
receiver action
gap을 다 메꾸는 기다리는 걸 다 받았으면 다음번호 ACK을 보낸다.
TCP fast retransmit
중복된 ACK을 통해서 lost segment를 감지한다.
-> 같은 segment를 여러 번 받는다면 그 segment는 loss가 일어났을 확률이 높다.
-> 만약 같은 데이터에 대한 ACK이 3번 왔다면
timeout이 일어나기 전이라도 즉시 해당 패킷을 재전송한다.
따라서 재전송이 일어나는 조건은
1. timeout이 발생
2. 중복된 ack을 여러 번 받았을 경우
중복된 3개의 ACK이므로 total 4개를 받았을 때 재전송한다.
TCP congestion control
TCP Slow Start
: 연결을 처음 시작할 때나 RTO(retransmission timeout)가 발생했을 시 동작하며,
네트워크의 상태를 모르니 혼잡이 발생하지 않도록 cwnd를 천천히 증가시켜 보는 상태
1. 연결을 시작할 때, 초기 cwnd = 1 MSS(maximum segment size)
2. 매 RTT(Round Trip Time)마다 2배씩 증가해서 cwnd를 보낸다
-> UDP의 경우는 이러한 제약없이 처음부터 최대로 전송을 수행한다.
그러나 TCP는 상대적으로 느리게 경로의 상태를 확인해 가며 전송속도를 높인다.
3. timeout에 의해 loss가 발생 시
: cwnd를 1 MSS로 세팅한다
TCP Tahoe 버전은 timeout 발생하거나 3번 중복된 ACK을 받으면 loss가 발생한 것으로 간주
-> cwnd를 1로 줄이고 매 RTT마다 2씩 증가시킨다
- 2배씩 한없이 늘리면 너무 많아지기 때문에 threshold=ssthresh를 두어
이 구간을 넘으면 1씩 증가하도록 한다.
-> CA(congestion avoid) 구간이라 한다 - loss가 발생하면 ssthresh를 반으로 줄인다.
-> 12의 반=6으로
TCP RENO 버전은 3번 중복된 ACK을 받으면 loss가 발생한 것으로 간주
-> cwnd를 반으로 줄이고 매 RTT마다 1씩 증가시킨다
RTO가 발생했을 경우는
-> slow start 상태로 돌아가며 ssthresh를 cwnd/2로, cwnd를 1로 리셋한다.