지난 포스팅에서 RDT 프로토콜에 대해 다루었습니다. 이번 포스팅에서는 TCP에 대해 살펴보겠습니다.
1. TCP : Connection-oriented transport
먼저, TCP의 특징부터 살펴보면 아래와 같습니다.
(1) Point-to-point
UDP와 달리 TCP는 소켓 한 쌍의 통신을 담당합니다. UDP가 하나의 서버 소켓에 여러 개의 클라이언트 소켓이 매핑되어 통신을 하는 반면, TCP는 한 서버 소켓에 무조건 하나의 클라이언트 소켓이 연결되는 것입니다. 즉, 하나의 sender에 하나의 receiver가 연결되는 것입니다.
(2) reliable, in-order byte stream
신뢰성이 보장되므로 데이터가 유실되거나 데이터에 에러가 발생하지 않는다는 것입니다. 그래서, 데이터가 순서대로 전송됩니다.
(3) pipelined
파이프라인 방법을 사용하여, 한 번에 데이터를 쏟아붓는 것입니다. ACK를 기다리지 않고 다음 데이터를 전송합니다.
(4) full duplex data
연결시 양방향으로 데이터를 전송할 수 있습니다. 다시 말해, 서버와 클라이언트 모두 서로에게 데이터를 전송할 수 있는 sender이자 receiver인 것입니다.
(5) sender & receiver buffer
연결 시 양방향 모두 sender이자 receiver이므로 모든 디바이스는 sender 버퍼와 receiver 버퍼를 갖습니다. sender는 전송할 데이터를 저장하기 위해 버퍼를 사용하고 receiver는 순서가 뒤바뀐 바이트를 올바르게 받기 위해 버퍼를 사용합니다.
(6) connections - oriented
데이터 통신 전, 3 way hand shake를 통해 connection을 생성합니다. 3 way hand shake은 다음 포스팅에서 다룰 것입니다.
(7) flow controlled
sender는 receiver나 네트워크가 받아들일 수 있는 만큼만 데이터 전달합니다.
이런 특징을 가진 TCP는 어떤 방식으로 구성되는지를 알아보기 위해, TCP를 통해 전송되는 세그먼트 구조를 살펴볼 수 있습니다.
2. TCP Segment structure
Data 부분은 애플리케이션이 전달하고자 하는 Message가 들어가는 부분입니다. TCP는 Segment의 헤더를 보고 동작합니다.
위 사진에서 세그먼트의 헤더에 들어가는 항목들과 용량을 볼 수 있습니다. 이 중, 유의미하게 살펴볼 것들에 대해 간략히 알아보겠습니다.
(1) 포트 번호 (source port# , dest port#)
TCP는 다중화와 역다중화 과정을 위해 출발지와 도착지의 포트 번호를 요구하게 됩니다. 다중화와 역다중화 과정은 쉽게 말해, 알맞는 프로세스에게 데이터를 전달하는 것입니다.
포트 번호는 각각 16비트씩 할당되어 총 32비트로 구성됩니다. 16비트를 사용하므로 2^16 -1(0~65536)개의 번호를 사용할 수 있습니다.
(2) 시퀀스 번호(sequence number)
세그먼트 Data의 첫 바이트의 바이트 스트림 번호(byte stream number)를 나타냅니다. 예를 들어 50바이트를 전송할 때, 첫 세그먼트는 0~9번 바이트, 두 번째 메시지는 10~29번 바이트까지를 전송한다고 해보겠습니다. 그러면 첫 메시지의 seq #= 0이고, 두 번째 메시지의 seq # = 10으로 나타내는 것입니다. 세그먼트의 시작점을 알려 구분을 해주는 용도입니다.
(3) Acknowledgement number
ACK 번호를 말합니다. TCP에서의 ACK는 '다음번에 받을 바이트의 seq #'입니다. 만약 seq # = 3이라면, TCP는 2번 세그먼트까지 받았고, 이제 3번을 받을 차례를 의미합니다. 누적(cumulative)한 방식입니다.
(4) Checksum
에러를 발견하기 위해 사용합니다.
(5) Receive window
수신자의 버퍼에 빈 공간이 얼마나 있는지를 알려줍니다. 현재 receiver가 수신할 수 있는 바이트의 수를 의미합니다.
3. 역할에 구분없는 전달
TCP에서 모든 클라이언트와 서버는 송신자(Sender)이자 수신자(Receiver)라고 했습니다. 송신자든 수신자이든, 메시지를 보낼 때마다 서로 시퀀스(Seq) 번호와 ACK 번호를 전송합니다.
위 그림을 통해 살펴보겠습니다. Host A가 B에게 send buffer에서 문자 'C'를 전송하면, Host B도 A에게 send buffer에서 문자 'C'를 전송하고, Host A가 또 B에게 같은 방식으로 데이터를 전송하는 그림입니다.
데이터와 함께 헤더에는 Seq와 ACK를 전송하는데, Seq 번호는 Send buffer에서 보내는 첫 바이트 번호입니다. 그리고 상대 send buffer에게서 받고자 하는 바이트 번호를 ACK 번호로 요청합니다.
한 바이트씩 보내기 때문에, Host B의 ACK는 A의 Seq의 다음 번호(Seq + 1)가 됩니다. 그래서 Host A가 Seq 42로 1바이트를 전송했으므로 Host B가 요구하는 바이트 스트림 번호는 42 + 1인 ACK 43이 됩니다
그리고 Host B가 다음에 A에게 보낼 데이터는 내가 ACK로 요구한 번호와 같습니다. Host A가 ACK 79로 79번 바이트를 요구했으므로, 다음에 Host B가 전송할 데이터는 79번이고 Seq 79로 메시지를 보내게 됩니다.
이렇게 서로가 송신자(Sender)이자 수신자(Receiver)이므로, 상대방에게서 받은 메시지에 ACK를 보내주는 것과 동시에 메시지를 보낼 수도 있다(Seq)는 것이 특징입니다.
4. Timeout : Fuction of RTT(Round Trip Time)
TCP의 타임 아웃을 어떻게 정할지 생각해볼 필요가 있습니다.
이론적으로는 RTT 정도로 설정하는 것이 좋겠지만, RTT값은 모든 세그먼트마다 다르다는 문제가 있습니다. 지나는 경로가 다르고, 같은 라우터를 지나더라도 그 때마다 queue상황이 달라 queueing delay가 달라지기 때문입니다.
위 그림에서도 볼 수 있듯이, RTT(남색 점)는 상황에 따라 값이 다른 것을 볼 수 있습니다.
그래서 EstimatedRTT를 사용하여 RTT를 추정하게 됩니다.
EstimatedRTT는 지수 가중 이동평균(Exponentially Weighted Moving Average)으로, 쉽게 말해 최근 RTT의 경향성을 통해 RTT를 추정한 것입니다. 대표할 수 있을 만한 SampleRTT값에 지금까지 축적되어온 값을 축적해서 구하여 판단하는 것입니다.
EstimatedRTT는 SampleRTT에 비해 훨씬 안정적인 변화 양상을 보이며, 이전에 나타난 RTT를 통해 다음 RTT를 추정할 수 있다는 특징이 있습니다.
그러나 그래프를 보면 알 수 있듯, EstimatedRTT는 SampleRTT에 비해 상대적으로 작거나 클 때가 있으므로, 이 값을 그대로 timeout 값으로 사용하기는 어렵습니다. EstimatedRTT가 SampleRTT보다 작을 경우 유실이 확실하지 않은 상황에서 timeout으로 처리될 수 있습니다. 따라서 EstimatedRTT에 특정한 수를 더하여 timeout을 판별합니다.
실제 TCP는 500ms 정도 기다렸다가 ACK를 보내라고 권고합니다. 그 이유는 Cumulative ACK를 사용하고, 추가로 보낼 메시지가 생길 수도 있기 때문입니다.
참고자료
[컴퓨터 네트워크 - 한양대학교 이석복 교수님]
http://www.kocw.net/home/cview.do?cid=6166c077e545b736
https://the-square-of-y.tistory.com/215
https://the-brain-of-sic2.tistory.com/52
https://dev-nicitis.tistory.com/26
'CS > Network' 카테고리의 다른 글
[네트워크] TCP Congestion Control (0) | 2024.02.17 |
---|---|
[네트워크] TCP의 Flow control, 3 / 4 - Way Handshake (0) | 2024.02.16 |
[네트워크] Pipelined Protocol (0) | 2024.02.12 |
[네트워크] RDT(Reliable Data Transfer) (0) | 2024.02.11 |
[네트워크] 전송 계층 : 다중화(Multiplexing)와 역다중화(Demultiplexing) (0) | 2024.02.10 |