[하향식 접근 8판] Chapter 3 - 3.5 연결지향형 트랜스포트: TCP

※"컴퓨터 네트워킹 하향식 접근 8판" 책을 간단하게 정리한 내용의 글입니다.※

3.5 연결지향형 트랜스포트: TCP

3.5.1 TCP 연결

TCP의 특징은 다음과 같다.

• TCP의 특징

  • 데이터를 보내기 전에 두 프로세스는 핸드셰이크를 먼저 해야 하므로 연결지향형(connection-oriented)이다.
    TCP에서 연결의 양단은 TCP 연결과 연관된 많은 TCP 상태 변수를 초기화한다.
  • TCP에서 '연결'은 두 통신 종단 시스템의 TCP에 존재하는 상태를 공유하는 논리적인 것이다.
    TCP '연결'은 회선 교화 네트워크와 같은 TDM이나 FDM이 아니고 두 통신 종단 시스템의 TCP에 존재하는 상태를 공유하는 논리적인 것이다.
  • TCP 프로토콜은 오직 종단 시스템에만 존재한다.
    중간의 네트워크 요소(라우터, 링크 계층 스위치)에서는 동작하지 않고, 감지하지도 못한다.
  • TCP 연결은 전이중 서비스(full-duplex service)를 제공한다.
    TCP로 연결된 두 호스트 A, B는 동시에 서로 데이터를 전송할 수 있다.
  • TCP 연결은 항상 점대점(point-to-point)이다.
    TCP 연결은 항상 단일 송신자와 단일 수신자 사이에서 이루어진다. 멀티캐스팅(multicasting)은 불가능하다.

• 세 방향 핸드셰이크(three-way handshake)
  연결을 초기화하기를 원하는 프로세스가 클라이언트 프로세스(client process)이고, 다른 프로세스를 서버 프로세스(server process)이다.
  클라이언트의 트랜스포트 계층은 서버의 트랜스포트 계층과 TCP 연결 설정을 진행한다. 먼저 클라이언트는 특별한 TCP 세그먼트를 서버로 보내고, 서버도 두 번재 특별한 TCP 세그먼트를 클라이언트로 보내서 응답한다. 이 2개의 세그먼트에는 페이로드(애플리케이션 계층의 데이터)가 없다. 마지막으로 클라이언트는 세 번째 특별한 TCP 세그먼트를 보낸다. 이 세 번째 세그먼트에는 페이로드가 포함될 수 있다.
  총 3번의 세그먼트를 보내서 연결을 설정하기 때문에 흔히 세 방향 핸드셰이크(three-way handshake)라고 한다.

• 데이터 송신
  three-way handshake를 마치면 TCP 연결이 설정되고, 두 애플리케이션 프로세스는 서로 데이터를 보낼 수 있다.
  클라이언트 프로세느가 소켓을 통해 데이터의 스트림을 전달하면 이는 TCP에 맡겨지고, TCP는 three-way handshake 동안 전달받은 데이터를 송신 버퍼(send buffer)에 저장한다. TCP 명세서[RFC 793]에서는 TCP가 언제 버퍼된 데이터를 전송해야 하는지 기술하고 있지 않다.
  그리고 TCP 세그먼트는 수신 측에 도착했을 때 TCP 연결의 수신 버퍼에 위치하게 된다. 애플리케이션은 이 버퍼로부터 데이터의 스트림을 읽는다.
  TCP 연결은 한쪽 호스트와 다른쪽 호스트의 버퍼, 변수, 프로세스의 집합으로 이루어진다.

• 최대 세그먼트 크기(maximum segment size, MSS)
  세그먼트로 모아 담을 수 있는 최대 데이터의 양은 MSS로 제한된다. MSS는 링크 계층 프레임의 길이(최대 전송 단위(maximum transmission unit, MTU)에 의해 결정되고, TCP 세그먼트와 TCP/IP 헤더 길이(통상 40바이트)가 정해진다.
  이더넷과 PPP 링크 계층 프로토콜은 모두 1,500바이트의 MTU를 갖고, 따라서 MSS의 일반적인 값은 40을 뺀 1460바이트이다.
  MSS는 헤더를 포함하는 TCP 세그먼트의 최대 크기가 아니라 세그먼트에 있는 애플리케이션 계층 데이터에 대한 최대 크기이다.

3.5.2 TCP 세그먼트 구조

TCP가 큰 파일을 전송할 때 일반적으로 MSS 크기로 파일을 분절한다. 그러나 많은 대화식 애플리케이션은 MSS보다 작은 양의 데이터를 전송한다. 텔넷과 ssh 같은 원격 로그인에서는 데이터는 오직 1바이트이기 때문에 전체 세그먼트는 단지 21바이트 길이가 된다.

위의 그림은 TCP 세그먼트의 구조이다.

< TCP 헤더 필드별 설명 >

• 16비트 출발지 포트 번호와 16비트 목적지 포트 번호
• 체크섬 필드(checksum field)
• 32비트 순서 번호 필드(sequence number field)와 32비트 확인응답 번호 필드(acknowledgement number field)
  TCP에서 신뢰적인 데이터 전송 서비스를 위해 사용한다.
• 16비트 수신 윈도(receive window)
  흐름 제어에 사용된다. 수신자가 받아들이려는 바이트의 크기를 나타내는 데 사용된다.
• 4비트 헤더 길이 필드(header length field)
  32비트 워드 단위로 TCP 헤더의 길이를 나타낸다.(TCP 헤더는 옵션(option) 필드 때문에 가변적인 길이가 될 수 있다. 일반적으로는 옵션 필드 없이 20바이트이다.)
• 옵션 필드(option field)
  송신자와 수신자가 MSS(최대 세그먼트 크기)를 협상하거나 고속 네트워크에서 사용하기 위한 윈도 확장 요소로 사용된다.
• 6비트 플래그 필드(flag field) (CWR, ECE, URG, ACK, PSH, RST, SYN, FIN)
• 긴급 데이터 포인터 필드(urgent data pointer field)
  옵션 필드의 URG 비트는 송신측에서 긴급으로 표시하는 데이터임을 가리킨다. 이 긴급 데이터의 마지막 바이트의 위치는 16비트의 긴급 데이터 포인터 필드(urgent data pointer field)에 의해 가리켜진다.
  TCP는 긴급 데이터가 존재할 때 수신 측 상위 계층 개체에게 통지해야 한다.

< 순서 번호와 확인응답 번호 >

TCP 세그먼트 헤더의 순서 번호 필드와 확인응답 번호 필드는 TCP의 신뢰적인 데이터 전송 서비스의 중대한 부분이다.

• TCP는 순서 번호 필드와 확인응답 번호 필드를 무엇으로 채우는가?
  • 순서 번호 필드
    -> 세그먼트에 대한 순서 번호는 세그먼트에 있는 첫 번째 바이트의 바이트 스트림 번호이다.
    

    

    
    TCP에서는 데이터를 단지 순서대로 정렬되어 있는 바이트 스트림으로 본다.
    위의 예시에서 MSS는 1000바이트이고, 전체 데이터 스트림은 500,000바이트이다. 그리고 데이터 스트림의 첫 번째 바이트는 0으로 설정했다.
    여기서 첫 번째 세그먼트의 순서 번호는 0이고, 두 번째 세그먼트의 순서 번호는 1,000, 그리고 2,000, 3,000, ...이다
  • 확인응답 번호 필드
    확인응답 번호의 필드는 다음 수신받아야할 바이트 번호를 넣는다. 예를 들어서 0에서 535까지 번호가 붙은 모든 바이트를 A가 B로 부터 수신받았다면, A는 확인응답 번호로 536을 넣어서 B로 송신한다.
• TCP는 순서가 틀리게 도착한 세그먼트를 어떻게 처리하는가?
  TCP RFC는 여기에 대해 어떤 규칙도 부여하지 않았고, TCP 구현 개발자에게 맡기도 있다.
  GBN처럼 다음에 받기를 기대하는 번호가 아니면 버릴 수도 있고, SR처럼 다음 순서가 아닌 그 이후의 번호에 대해서는 버퍼에 저장해 둘 수도 있다.
  후자가 네트워크 대역폭 관점에서 효율적이고, 실제에서도 이 방법을 사용한다.
  (추가적으로 예시에서는 시작 순서 번호가 0이지만, 실제 TCP 연결에서 양쪽의 시작 순서 번호는 임의로 선택된다. 이는 이미 종료된 연결로부터 아직 네트워크에 나마 있던 세그먼트가 이전과 같은 두 호스트 간의 나중 연결에서 이를 유효한 세그먼트로 오인될 확률을 최소화한다.)

< 텔넷: 순서 번호와 응답확인 번호 사례연구 >

텔넷(Telnet)은 원격 로그인을 위해 사용되는 유명한 애플리케이션 계층 프로토콜이다.
이는 TCP상에서 실행되며, 한 쌍의 호스트들 사이에서 동작하도록 설계되었다. 텔넷은 대화형 애플리케이션으로, TCP 순서와 확인응답 번호를 설명하는 데 편하기 때문에 설명한다.

3.5.3 왕복 시간(RTT) 예측과 타임아웃

TCP의 확인 응답은 누적 확인응답이다.
→ ACK 손실되든 말든 ACK 하나가 도착하면 송신 측에서는 그 ACK의 확인 응답 이전의 모든 패킷이 정상적으로 도착했음을 안다.

TCP의 타임아웃 주기는 어떻게 혼잡 제어의 효과를 가져오는가?
→ TCP는 타임아웃 시에 이전 TimeoutInterval의 2배로 TimeoutInterval을 설정한다. 그래서 계속 손실될 때마다 지수적으로 늘어난다. 타임아웃이 난다는 것은 네트워크가 혼잡하다는 것이기 때문에 혼잡 제어가 필요하다는 것이다.

3.5.4 신뢰적인 데이터 전송

TCP에서 타임아웃이 일어나기 전에 어떤 경우에 송신자는 수신자가 어떤 패킷을 받지 못했다는 것을 알까?
→ 같은 확인 응답번호로 ACK가 여러 개 올 때이다. ACK가 온다는 것은 수신자가 패킷을 받았다는 소리인데, 100 이후에 보낸것도 계속 100으로 온다면 이는 100에 대한 패킷이 잘못된 것이다. 이를 빠른 재전송(fast retransmit)이라고 한다.

3.5.5 흐름 제어

흐름 제어와 혼잡 제어의 차이는?
→ 흐름 제어는 애플리케이션이 메시지를 읽는 속도와 데이터가 전송되는 속도를 맞추기 위해 송신자를 억제하는 것이고, 혼잡 제어는 IP 네트워크에서 혼잡 때문에 송신자를 억제하는 것이다.

흐름 제어에서 수신 버퍼가 0이 되면 송신 측은 어떤 데이터도 보내지 않게 된다. 송신 측이 데이터를 보내지 않으면 ACK를 받을 수 없어서 남은 수신 버퍼 크기(rwnd = 수신 윈도)를 알 수 없게 되고, 그렇게 때문에 계속 아무것도 보내지 않을 것이다. 이것을 어떻게 해결하는가?
→ rwnd가 0이더라도 1바이트 짜리 데이터를 주기적으로 계속 보내게 한다.

UDP에서의 흐름 제어는 어떻게 되는가?
→ UDP는 흐름 제어 서비스를 제공하지 않고, 버퍼가 가득 차면 오버플로가 일어나고 버려진다.

3.5.6 TCP 연결 관리

TCP에서 ESTABLISHED 상태가 무엇을 의미하는가?
→ three-way handshake로 연결 설정을 마치고 신뢰적인 데이터 전송(TCP 서비스를 제공할)을 할 준비가 되었다는 의미이다.

혼잡 제어는 크게 어떻게 나뉘는가?
→ 종단 간의 혼잡 제어 - 각 종단에서 관찰된 네트워크 동작(패킷 손실, 지연 등)에 기초 / 네트워크 지원 혼잡 제어 - 라우터에서 바로 송신자로 혹은 수신자를 통해 송신자로 알린다.