Shine's dev log
TCP의 개념 (Transmission Control Protocol) 본문
1. TCP (Transmission Control Protocol)
Transport Layer 프로토콜들의 대표적인 사례로는 UDP와 TCP가 있다.
비교적 간단하고 빠른 UDP에 비해 TCP는 더 복잡하고 느리지만, 보다 신뢰성있는 연결이 가능해진다.
기본적으로 TCP 프로토콜이 가지는 특징에 대해 먼저 살펴보자.
1) Full duplex data transfer
- 데이터 통신을 할 때 양방향(bi-directional) 으로 데이터가 흐른다.
2) Connection-oriented
- 통신을 하기 앞서 Hanshaking 과정을 통해 sender와 receiver의 상태를 확인한다.
3) Flow controlled
- sender는 receiver의 능력을 살펴보며 전송량을 조절한다.
4) Point-to-point
- 하나의 sender는 하나의 receiver와 통신한다.
5) Reliable, in-order byte stream
- 데이터는 순서대로 application layer로 넘겨지며, 데이터를 그냥 byte로 처리하기 때문에 application message의 맥락을 신경쓰지 않는다.
6) Pipelined
- TCP congestion, flow control이 pipeline을 위한 윈도우 사이즈를 결정한다.
2. TCP의 pipelining
TCP는 패킷을 보낼 때 pipeline을 통해 전송한다.
앞서 살펴보았듯이, pipeline 방식으로는 Go-Back-N과 Selective repeat 방식이 있다.
TCP의 경우 두가지 방법을 혼합하여 사용하는 형태이다.
Go-Back-N의 cummulative ack 방식처럼 중간에 패킷 하나가 빠지면 계속해서 빠진 패킷에 대한 ack을 전송하며, retransmission timer는 하나만 설정한다. 하지만, selective repeat 방식처럼 순서에 맞지 않게 온 패킷들도 버퍼에 다 보관해 놓는다.
3. TCP의 sequence number
TCP에서 sequence number는 application data의 양 만큼 증가한다.
만약 하나의 패킷(segment)의 크기가 8bytes 라면, sequence nubmer는 1, 9, 17, 25, ... 이런 식으로 증가하는 것이다.
4. TCP의 ACK
TCP에서 ACK 번호는 "내가 너로부터 받기로 예상하는 sequence number" 이다.
아래 그림에서 알 수 있듯이, ack 번호를 받으면 바로 다음 턴에 ack에 해당하는 패킷을 보내주어야 한다.
5. TCP header
TCP header의 경우 아래 그림과 같이 생겼다.
딱 봐도 UDP에 비해 굉장히 복잡한 형태를 가지고 있음을 알 수 있다.
특히 acknowledgement number와 receive window 값은 receiver로써 필요한 정보를 실어 보내는 것이고, 나머지 부분은 sender 로써 필요한 정보를 실어 보내는 것이다.
6. TCP rount trip time (RTT)
Round Trip Time(RTT)는 특정 패킷을 전송하고 다시 응답을 받기까지 걸린 시간을 의미한다.
TCP에서는 기본적으로 retransmission timer를 사용하므로, 예상 RTT를 계산하는 것이 아주 중요하다.
만약 retransmission timer를 RTT보다 너무 짧게 설정하면, 패킷이 유실되지도 않았는데 재전송을 하는 경우가 생길 것이다.
반대로 retransmission timer를 RTT보다 너무 길게 설정하면, 패킷이 유실되는 경우에 너무 늦게 반응하여 속도 저하가 생길 수 있다.
그렇다면, 어떻게 RTT를 추정할까?
바로 sample RTT를 활용하여 추정한다. 가장 많이 사용되는 추정 방법으로는 Exponential Weighted Moving Average (EWMA) 방식이 있는데, 식은 다음과 같다.
Estimated RTT = { (1-a) * Estimated RTT } + { a * sample RTT }
여기서 sample RTT의 비중을 관리하는 변수인 a는 보통 0.125로 설정한다.
만약 a의 값이 작으면, 최근에 관찰한 sample RTT에 비중을 많이 주고, a의 값이 커지면, 최근에 관찰한 sample RTT에 비중을 적게 두는 것이다.
위와 같이 추정한 Estimated RTT를 바로 retransmission timer에 적용하면 안된다. 왜냐하면 추정값은 언제까지나 평균 값인 것이기 때문에 estimated RTT보다 높게 측정되는 경우가 많을것이기 때문이다. 따라서 아래 식과 같이 어느정도 완충구역을 추가해줘야 한다.
Timeout Interval = Estimated RTT + 4 * (Dev RTT)
7. TCP fast retransmit
TCP에서 패킷이 유실된 것을 의심해볼 수 있는 경우는 딱 두가지가 있다.
하나는 중복된 ack이 계속해서 오는 경우이고, 다른 하나는 timeout이 발생한 경우이다.
만약 유실이 된 것으로 의심이 되면, 빠르게 재전송을 해야 하는데, 타이머의 timeout을 기다리는 것은 굉장히 답답하다. 왜냐하면, TCP의 경우 타이머를 window에서 가장 베이스가 되는 패킷에 하나만 설정해놓기 때문이다. 따라서 한번에 여러 패킷을 보냈다고 하더라도 가장 첫 패킷에 대한 ack이 오고 나서야 다음 패킷에 대한 타이머가 시작되어 굉장히 느리다.
이에 대한 해결책으로 TCP fast retransmit 방식이 사용되곤 하는데, 이는 재전송을 timeout에 의지하는 것이 아니라 중복된 ack 메시지가 올 경우에 패킷이 유실된 것으로 추정하고 바로 재전송 하는 방식이다.
8. TCP 예시
앞서 글로 설명했던 TCP의 통신 과정을 다양한 예시를 통해 살펴보자.
1) sequence number, ack 관련 예시
example 1에서 볼 수 있듯이, ACK은 다음턴에 받기로 고대하는 sequence number이다.
example 2에서 볼 수 있듯이, pipelined 되기 때문에 ACK 번호와, 다음턴에 전송되는 sequence 번호는 일치하지는 않는다. 위 그림에서 왜 ACK이 50인지, 그다음에 sequence 번호가 왜 74번인지 잘 생각해보자.
2) 패킷이 유실된 경우
example 3과 같이 중간에 패킷이 유실된 경우 TCP는 cummulative ack이기 때문에 계속해서 ACK 92를 보낸다. timeout이 발생하고 나면 유실된 패킷이 재전송된다.
3) ACK이 유실된 경우
example 4와 같이 중간에 ACK이 유실된 경우, timeout이 발생하면 재전송 한다. receiver측은 이미 받은 패킷이므로 버리고 다시 ACK을 전송해준다.
4) cummulative ACK의 특징을 나타내는 경우
example 5 상황은 seq 92번 패킷의 ACK 메시지가 돌아오기 전에 timeout이 발생하여 재전송이 된 상황이다. receiver 측은 다시 seq 92번 패킷을 받았을 경우, 이미 중복된 것이므로 버리고 cummulative ack의 특징을 살려 앞으로 받아야 할 ACK 120번을 전송한다.
위 내용을 정리해보면,
1. TCP는 Transport layer 프로토콜의 하나로 굉장히 복잡하지만 신뢰성있는 통신을 가능하게 해준다.
2. RTT를 추정하기 위해 sample RTT를 활용하며, EWMA 를 활용해 계산한다.
3. 더 빠른 재전송을 위해 timeout이 아니라 중복된 ack을 활용하는 fast transmission을 사용하기도 한다.
위 내용은 공부하며 정리한 것으로, 오류가 있을 수 있습니다.
'컴퓨터 네트워크' 카테고리의 다른 글
| TCP 연결 (3 way-handshake) (0) | 2021.02.25 |
|---|---|
| TCP Flow Control (2) | 2021.02.24 |
| UDP의 개념 (User Datagram protocol) (0) | 2021.02.18 |
| 패킷 pipelining (go-Back-N, selective repeat) (3) | 2021.02.09 |
| Reliable data transfer (rdt 1.0/3.0) (2) | 2021.02.04 |
