대학원부터 시작한 첫번째 블로그

TCP (Transmission Control Protocol) 란?

       OSI 참조 모델의 제4계층인 전송 계층에 해당되는 프로토콜.

       인터넷 프로토콜(IP)과 함께 TCP/IP를 구성한다.

       패킷의 도착 순서대로 배열이나 오류 수정 등이 행해지므로

       전송 제어 프로토콜(Transmission Control Protocol)보다 상위층에서 보았을 때는

       2대의 컴퓨터가 신뢰성이 높은 전용선으로 연결된 것같이 보인다.

1. TCP (Transmission Control Protocol)의 특징

(1)   데이터 단위는 세그먼트 (Segment)이다.

(2)   UDP와 같은 인터넷 계층(IP)을 이용한다.

(3)   UDP와는 다른 서비스를 응용 계층에 제공한다.

(4)   연결지향의 신뢰성 있는 바이트 스트림 서비스를 제공한다.

(5)   흐름 제어 (Flow Control)와 에러 제어 (Error Control)를 제공한다.

 ※   바이트 스트림 (Byte Stream)

       한번에 한 바이트씩 연속적으로 전송되는 데이터의 흐름과 같이

       끊임없이 연속되는 바이트 열.

2. TCP (Transmission Control Protocol)의 서비스

(1)  연결 지향 서비스 (Connection-Oriented Service)

       연결된 두 시스템간에 반드시 TCP 연결을 만들어야만 한다.

       이는 전화 연결과 비슷하다.

       한쪽이 전화를 걸고 다른 쪽에서 응답이 온 후에야 전화 통화를 할 수 있는 것처럼,

       TCP도 연결이 확인된 이후에야 전송을 시작할 수 있다.

       이는 전송 데이터의 신뢰성과 무결성을 보장하기 위한 것이다.

(2)  전이중 서비스 (Full-Duplex Service)

 ①   데이터를 동시에 양방향으로 전송한다.      

 ②   피기배킹 (Piggybacking)

  -   수신한 패킷에 대한 확인 응답을 송신하는 패킷에 포함하여 전송한다.

  -   전송 데이터 없이 확인 응답 전송도 가능하다.

(3)  스트림 데이터 서비스 (Stream Data Service)

 ①   TCP는 상위 계층으로부터 데이터 스트림을 수신한 후,

       세그먼트(Segment)라고 하는 적절한 패킷 단위로 스트림을 나눈다.

 ②   세그먼트들은 네트워크를 통해 전송되어 목적지 TCP에 의해 재조립된다.

 ③   스트림 전달을 위해서 송신과 수신 TCP는 버퍼를 이용한다.

 ※   버퍼 (Buffer)

       입출력 데이터 등의 정보를 전송할 때 일시적인 데이터 저장 장소로 사용되는 기억 장소.

(4)  신뢰성 서비스 (Reliability Service)

       TCP는 UDP와는 달리 신뢰성을 보장한다.

       TCP 연결로를 통하여 데이터를 전송하고 이에 대한 응답(ACK)를 받음으로서

       그 데이터가 올바르게 전송되었음을 보장한다.

       만일 응답이 오지 않으면 그 데이터가 손상되었다고 판단하고 TCP는 재전송을 하게 된다.

 ①   정보 단위인 세그먼트를 IP로 전송한다. 

 ②   TCP는 세그먼트를 보낼 때 타이머를 설정한다.

  -    수신측으로부터 확인 응답 메시지를 기다린다.

  -    확인 응답이 오지 않을 경우 세그먼트를 재전송한다. 

 ③   TCP가 연결의 상대편으로부터 데이터를 받으면 확인 응답을 보낸다.

       일반적으로 수 초 정도 지연된 후에 보내진다. 

 ④   TCP는 헤더와 데이터에 검사합을 이용한다.

  -    데이터가 전송 중에 변화되었는지 검출하는 것이 목적이다.

  -    오류가 난 세그먼트는 버리고 확인 응답을 보내지 않는다.

  ⑤  TCP 세그먼트는 IP 데이터그램으로 전송한다.

  ⑥  TCP는 중복된 데이터를 제거한다.

  ⑦  TCP는 흐름 제어를 제공한다.

3. TCP (Transmission Control Protocol)의 헤더 구조

 (1)  소스 포트 주소 (Source Port Address) 

        송신측(발신지)의 포트번호. 전체 길이는 16bit 길이를 갖는다.

 (2)  목적지 포트 주소 (Destination Port Address)

        수신측(목적지)의 포트 번호. 전체 길이는 16bit 길이를 갖는다.

 (3)  순서 번호 (Sequence Number)

  ①   32bit의 필드.

  ②   자신이 전송하는 데이터의 각 Byte마다 고유한 번호를 부여한다.

  ③   데이터 스트림의 순서, 중복된 세그먼트에 대한 구분, 데이터 수신 확인 등의

        기능도 한다.

 (4)  확인 응답 번호 (Acknowledgement Number)      

  ①   32bit의 필드.

  ②   수신측에서 송신측으로부터 받은 세그먼트에 대한 응답.

 (5)  헤더 길이 (Header Length)     

  ①   4bit의 필드.

  ②   32bit 워드 단위로서 헤더의 길이를 지정한다.

  ③   옵션 필드가 가변 길이이기 때문에 필요하다.

  ④   20Byte ~ 60Byte

 (6)  예약 (Reserved)

        차후의 사용을 위해 예약된 6bit 필드.

 (7)  제어 (Control)

        제어 Code 필드는 TCP 패킷의 종류를 나타내기 위한 필드로서

        총 6개의 필드가 있고, 각각은 1bit 씩 차지한다.

  ①   URG (Urgent)

        현재 Urgent Pointer에 명시된 항목이 기존의 바이트 스트림 즉, 데이터 교환 혹은

        어플리케이션 프로세스의 제어를 위해 전송할 메시지나 데이터임을 나타낸다.

  ②   ACK (Acknowledgement)  

        이 항목이 1로 설정되면

        확인 응답 번호 항목에 ACK 번호 값이 입력되어 있다는 것을 의미한다.

  ③   PSH (Push)

        이 항목이 1로 설정되면

        TCP에게 수신된 데이터를 즉시 상위 계층의 프로세스에 넘겨주라는 것을 의미한다.

  ④   RST (Reset)

        TCP의 연결을 특정 에러 혹은 사용자의 명령에 의해 재설정하기 위해 사용한다.

  ⑤   SYN (Synchronize)

        이 항목이 1로 설정되면 TCP 연결을 위한 요청을 한다.

  ⑥   FIN (Finish)

        연결의 종료에 대한 요청을 나타낸다.

 (8)  윈도우 크기 (Window Size)

  ①   16bit의 필드.

  ②   수신자의 입장에서 현재 자신의 가용 버퍼 (Available Buffer)의 크기를 알려준다.

  ③   윈도우 크기를 이용하여 양종단 간의 흐름 제어를 수행한다.

 (9)  검사합 (Checksum)

  ①   대부분의 TCP/IP 프로토콜에 의해 사용되는 오류를 검출한다.

  ②   데이터의 전달 중에 발생할 수 있는 오류에 대한 보호를 수행한다.

  ③   데이터, 헤더 그리고 의사 헤더에 대하여 검사합을 수행한다.

  ④   프로토콜의 값 : 6

 (10) 긴급 포인터 (Urgent Pointer)

  ①   URG 플래그가 설정되었을 때만 유효하다.

  ②   송신측이 상대편에게 긴급한 데이터를 보내는 방법

  ③   긴급 데이터를 포함하고 있는 경우 URG 플래그를 1로 설정한다.

(11) 옵션 (Option)

  ①   목적지에게 부가 정보를 전달하거나 다른 옵션의 정렬을 맞추기 위해 사용한다.

  ②   최대 40Byte까지 가능.

  ③   옵션의 두 종류에는 단일 바이트 (Single Byte)와 다중 바이트 (Multiple Byte)가 있다.

   ●   옵션의 끝 (End of Option)

   -   옵션 필드의 끝에 패딩을 위하여 사용되는 단일 바이트 옵션

   -   마지막 옵션으로만 사용 가능하며, 한개의 옵션만 사용한다.

    ※  패딩 (Padding)

        고정된 길이의 블록 또는 레코드의 사용하지 않는 기억 장소를

        특정한 정보 - 공백(blank) 등의 문자로 채우는 기법이다. 

  ●   무동작 (No Operation)         

   -   옵션 사이를 채우는 기능.

   -   옵션 정렬에 사용한다.

   ●   최대 세그먼트 크기 (MSS : Maximum Segment Size)   

   -   TCP 세그먼트의 목적지에서 수신할 수 있는 데이터 세그먼트의 최대 크기

   -   연결을 설정하는 세그먼트에서만 사용한다.

   -   Default = 536 

  ●   윈도우 확장 인자 (Window Scale Factor)

   -   슬라이딩 윈도우 (Sliding Window)의 크기를 정의한다.

  ●   타임 스탬프 (Timestamp)

   -   왕복시간 (RTT : Round Trip Time)을 결정하기 위해 사용하는 필드.

   -   발신지와 목적지가 타임스탬프 필드에 저장한 시간 값을 비교하여

        왕복시간(RTT)을 계산한다.

   -   10Byte 길이 옵션      

  ※   왕복시간 (RTT)

        발신지를 출발한 패킷이 목적지에 도착했다가 다시 발신지로 돌아오기까지의 시간.

오늘은 Windows Server 2008과 Windows Vista의 TCP 네트워크에 대해서 논해볼까 합니다.

다소 어려운 주제일 수 있으나, 꼭 아셔야할 필요성이 있다고 생각합니다.

네트워크를 사용하는 응용 프로그램 성능의 주요 팩터는 바로 네트워크 처리량입니다. 응용 프로그램에 대한 네트워크 처리량에 따라 응용 프로그램의 응답성 및 사용자가 느끼는 성능에 차이가 발생할 수 있습니다.

이 러한 네트워크 처리량에 영향을 줄수 있는 팩터는 여러가지가 있습니다. 그중 첫번째는 바로 네트워크의 물리적인 특징입니다. 네트워크 자체를 파이프라고 생각하시면, 대역폭(Bandwidth)는 바로 파이프의 지름이라고 볼 수 있습니다. 지연(Latency), RTT(Rount Trip Time)은 파이프의 길이라고 해야할까요? 만약 여러분께서 1GB의 데이터를 전송하고자 한다면, 더 굵고, 짧은 파이프가 길고 얇은 파이프보다 빠르게 데이터를 전송할 수 있습니다. 높은 대역폭과 낮은 지연은 높은 처리량에 대한 필수 팩터라고 볼 수 있습니다.

네 트워크의 사용량은 두번째 팩터가 되게 됩니다. 사용자/응용 프로그램이 주어진 네트워크 링크를 공유해서 사용하기 때문에, 응용 프로그램의 처리량 증가는 자연스럽게 링크의 감소로 이어지게 됩니다. 링크 대역폭은 TCP 프로토콜을 사용하는 응용 프로그램간에 공평하게 나누어서 사용하기 때문에, TCP 연결의 대역폭에 대해 응용 프로그램 연결을 제한하지 않는다면, 해당 링크는 혼잡(Congestion)이 발생하게 됩니다. 당연한 이야기죠? 혼잡이 발생하면 패킷의 누락과 전체적인 처리량의 감소가 생기는 것도 너무 당연하죠. 이러한 것을 막기 위해, TCP 프로토콜은 혼잡을 방지하고, 감지할수 있는 메커니즘을 가지고 있고 이를 통해 대역폭을 공평히 나누어 쓰게 됩니다.

세 번째 팩터는 네트워크 프로토콜로부터 발생하게 됩니다. TCP는 두가지 메커니즘을 통해 연결에 대한 처리량을 제한합니다. 한가지가 혼잡 제어(Congestion Control), 또하나가 흐름 제어, 흔히 이야기하는 Receiving Windows입니다. 혼잡 제어는 TCP 프로토콜에 네트워크내 혼잡을 발생시키지 않고, 공평하게 네트워크를 나눠 사용할 수 있도록 하며, Receiving Windows는 수신자가 처리할 수 있는 데이터량보다 많이 송신자가 전송하는 것을 막아줍니다. 이러한 제어는 TCP 프로토콜에 대한 이야기이며, UDP는 이러한 처리를 하지 않습니다.

조 금 난해한 이야기인가요? Windows Vista, Windows Server 2008의 Network Auto Tuning을 아시려면 배경지식으로 꼭 필요한 이야기입니다. 자 다음 편에 이제 실제 이야기를 쓰도록 하겠습니다. :)

어제 21편에서는 Network, TCP에 대한 기본적인 사항을 알아보았습니다. 꼭 Windows뿐만 아니라, 모든 네트워크 관련 사항을 진행할 때, 반드시 아셔야할 내용이었습니다. 자 그럼 어제에 이어서...

TCP Receive Window 제한은 TCP 연결시 사용할 수 있는 처리량에 제한을 가하게 됩니다. 이론적으로 Receive Window를 R이라고 하고, 양 종단간의 RTT(Rount Trip Time)을 T라고 했을 때...

Throughput =  R/T

가 되게 됩니다. 저도 처음에 잘 이해가 안가는 공식이었지만(Bandwidth-Latency 기술을 공부할 때 봤었던 공식이었습니다.), 조금 이해를 돕기 위해.. 다시 공식을 바꿔 써보면..

Throughput X T = R

최대 처리량은 초당 전송량이기 때문에, 실제 전송되기 까지의 지연(시간이죠)을 곱해주면 상대방이 받을 수 있는 한번에 수신할 수 있는 최대 처리량.. = TCP가 받을 수 있는 최대 Window 크기가 되게 됩니다.

예를 들어, Windows Server 2003, XP의 TCP Receive Window 기본 크기는 64KB였었습니다. 양단간의 RTT가 100ms 일 때, 최대 처리량은 64KB/100ms = 5.12Mbps가 되게 됩니다. 사용 응용 프로그램이 어떠한 제한 사항도 없다면, TCP 송신자는 네트워크에 가용할 수 있는 최대 대역폭을 다 사용할 수 있습니다.

이미 언급한 데로, 기존의 Windows는 전체 시스템에 대해서 TCP Receive Window가 64KB로 고정되어져 있었습니다. 이러한 접근 방식은 대역폭이 점점 커져가는 현실에, 처리량을 제한하는 요소중 하나였습니다. 레지스트리 키중에 TCPWindowSize가 원하는 값으로 Receive Window 크기를 입력할 수 있었지만, 이러한 입력은 시스템 전체에 영향을 주었기 때문에, 특정한 TCP 연결, 다시 말해, 무선에 대한 설정, 유선에 대한 설정은 할 수 없었습니다.

위의 그림은 Receive Window 크기와 RTT값에 따른 최대 처리량을 보여주는 그래프입니다. 보시는 데로, 기본 크기인 64KB로 Receive Window 크기를 사용했을 경우, RTT 값이 커질 수록(다시 말해, 거리가 멀어질 수록) 사용가능한 최대 처리량이 줄어들어는 것을 볼 수 있습니다. 거의 5Mbps 밑이죠. 두 지점간 대역폭이 아무리 좋더라도 실제 사용 가능한 대역폭은 5Mbps이상을 쓰기가 어려웠다는 것입니다. 그렇다고 무조건 Receiving Window 크기가 커야 한다는 의미는 아닙니다. 시스템간이 단일 스위치, 다시 말해, 매우 거리가 가까운 경우에는 RTT값이 매우 작으므로, 무조건 크기를 키우는 것이 능사만은 아닙니다.

이에, Windows Server 2008, Windows Vista에서는 Receive Window 크기에 대해 자동으로 튜닝하는 기능이 추가되었습니다. 모든 연결시, 환경을 파악하여, TCP가 Receive Window 크기를 조절합니다. 이러한 기능을 통해, 네트워크로 더 많은 양의 데이터를 전송하고, 이를 통해 사용자는 빠른 처리 시간을 기대할 수 있습니다. 높은 대역폭, 높은 지연률을 가진, 대륙간, 지역간 네트워크일수록 Windows Server 2008, Windows Vista의 네트워크 튜닝 기능이 매우 유용해질 수 있습니다. Receive Window가 커져서, 네트워크에 문제가 발생할 수 있지 않냐는 질문을 하시지만, 이미 이전 포스팅에 언급드린 데로, TCP는 Congestion Control도 역시 메커니즘의 하나로 가지고 있었습니다.

TCP의 Receive Windows 제어는 송신자가 수신자에게 데이터를 보낼때, 얼마나 많은 양의 확인되지 않은(Unacknowledged) 데이터를 보낼 수 있느냐의 의미입니다.

응답이 빠르다면(거리가 가깝다면), 구지 Receiving Window 크기를 키울 필요가 없다는 것도 이제는 이해가 되실 것입니다. 그러나, RTT가 커졌을 경우, 데이터를 보냈을 때, 이에 대한 확인을 받는 시간이 오래걸리므로, 그만큼 송신자는 네트워크 파이프를 채울 수 있는 많은 시간이 남게 됩니다, 이 경우, Receiving Window 값이 네트워크 파이프를 다 사용하지 못하는 팩터가 된다.. 는 의미입니다. 헥헥..

가장 최적의 크기는 송신자가 네트워크가 유지되는 한도에서 보낼 수 있는 크기라고 볼 수 있습니다. Windows Vista에서부터 해당 기능은 이미 사용중에 있습니다. 이러한 자동 튜닝이 적용되기 위해서는 아래의 몇가지 사항이 만족되어야 합니다.

1. 연결에 대한 지연 > 10ms (RTT)
2. Bandwidth * Latency > 64KB
3. 응용 프로그램에 수신 버퍼 크기가 지정되지 않은 경우
4. 응용 프로그램이 보내주는 데이터의 크기에 상관없이 처리가 되는 경우

이제 또하나의 문제를 제기해야 합니다. TCP의 Receive Window 크기를 지정하는 레지스트리는 16비트입니다. 2에 16승이 65535.. 64KB이므로, Window 크기를 더 늘리려면 레지스트리의 비트가 늘어나던지, 무언가 다른 방법론이 취해져야 합니다. 이에 Windows는 TCP Receive Window Scailing에 관련된 레지스트리를 추가적으로 사용합니다. Window Scailing 옵션을 Windows Vista, Windows Server 2008은 기본적으로 사용합니다.

TCP 연결 시도를 하는 동안, 송신자와 수신자는 Scailing 옵션을 상호 교섭합니다. 만약 원격지에서 이를 지원한다면, Window Scailing 옵션이 사용되게 됩니다, Windows Vista는 Scale 팩터로 8 (2에 8승 = 256)을 사용합니다. 256배가 된다는 뜻이죠.. 64KB X 256 = 16MB의 Receiving Window가 되죠.. 기존값에 비하면 매우 높은 값이며, 이러한 값을 무작정 사용하는 것이 아니라, 원격지 시스템, 네트워크 상태에 따라 자동으로 조절하게 된다는 뜻입니다.

1. Retransmission Timer : 기본적으로 정해진 재전송 타이머 안에 다음 데이터가 오지 않으면, 전송실패로 인지함
2. Estimation of RTT : Round-Trip-Time 즉 송신 후 ACK 수신까지 걸리는 시간이 유일한 재전송 메커니즘의 척도
3. Granlarity of RTO : Retransmission Time-Out 즉, 재전송 타임아웃을 어떻게 설정하는 지가 가장 중요