2014년 7월 30일 수요일

전송 제어 프로토콜(TCP) 원리와 일반 동작

TCP 데이터 취급과 처리
  • 애플리케이션 데이터 처리의 유연성 향상: TCP의 스트림 동작
    • TCP는 애플리케이션에서 오는 데이터를 스트림으로 간주한다
    • 그래서 TCP를 스트림 중심(stream-oriented) 프로토콜이라 한다.
    • 각 애플리케이션은 전송하고자 하는 데이터를 옥텟(바이트) 스트림으로 송신한다.
    • 즉, 애플리케이션은 데이터를 블록 크기에 맞추거나 스트림의 길이를 걱정할 필요가 없다.
    • 단지 TCP에 바이트를 "던져 주면" 된다.
  • TCP 데이터 패키징: 세그먼트
    • TCP 세그먼트
      • TCP는 애플리케이션에서 오는 스트림을 IP에서 보낼 수 있는 분리된 메시지로 나눈다. 이 메지시를 TCP 세그먼트라 함
    • TCP에서는 최대 세그먼트 크기(MSS)라는 인자가 크기를 제한한다.
      • MSS는 연결 수립 과정에서 결정된다.
    • TCP에서는 일단 연결이 수립되면 각 장비가 어떤 시간에든지 받을 수 있는 데이터의 크기를 상대방에게 알리도록 설계돼 있다.
      • 만약 크기가 MSS값보다 작다면 장비는 MSS보다 작은 세그먼트를 송신해야 한다.
  • TCP 데이터 식별: 순서 번호
    • TCP는 분리된 메시지가 아닌 개별 데이터 바이트를 다루기 때문에 데이터 송신과 추적 시스템을 구현하기 위해 바이트 수준의 식별 방법을 사용해야한다.
    • 이를 위해 TCP는 처리하는 각 바이트에 순서 번호를 할당한다.
  • 애플리케이션의 데이터 구분 필요
    • 애플리케이션은 TCP로 미리 패키징된 메시지가 아닌 바이트 스트림을 송신한다.
    • 그래서 각 애플리케이션은 한 데이터 요소가 어디에서 끝나고 어디에서 시작하는지를 결정하기 위한 고유한 방법을 사용해야 한다.

TCP 슬라이딩 윈도우 승인 체계
데이터 관리는 TCP의 다음 두 요구 사항을 충족시키기 위해 꼭 필요하다

  • 신뢰성
    • 송신한 데이터가 실제로 목적지에 도달한다는 것을 보장하고 만약 도달하지 않을 경우 그 사실을 탐지하여 재송신한다.
  • 데이터 흐름 제어
    • 데이터를 수신하는 장비가 처리할 수 있는 속도로 데이터 송신율을 관리한다.
이를 위해 TCP는 슬라이딩 윈도우 승인체계를 사용한다.

  • 신뢰할 수 없는 프로토콜의 문제: 피드백이 없음
    • IP와 같은 프로토콜에서는 메시지가 목적지에 도달하면 좋겠지만 만약 도달하지 못할 경우 아무도 그 사실을 알지 못한다.
  • 재전송을 사용하는 긍정 승인(PAR)을 통한 기본적인 신뢰성 제공
    • 통ㅅ니의 신뢰성을 보장하기 위한 기본적인 방법으로 장비가 메시지를 수신할 때마다 승인을 보내는 방법을 생각할 수 있다.
    • 만약 특정 시간 동안 승인이 오지 않을 경우 송신자는 메시지를 재전송할 수 있다.
    • 이 방법을 재전송을 사용하는 긍정 승인(PAR, positive acknowledgment with retransmission)이라 부른다.
    • 단점은 첫 메시지에 대한 승인을 받기 전까지 둘째 메시지를 보낼 수 없다는 것이다.
  • PAR 개선
    • 송신하는 각 메시지에 식별 정보를 추가하여 여러 메시지를 동시에 송신함으로써 기본 PAR 방법을 개선할 수 있다.
    • 그리고 송신 제한값을 사용하면 다른 장비가 데이터를 송신하는 비율을 제한하여 흐름 제어 기능도 제공할 수 있다.
  • TCP의 스트림 중심 슬라이딩 윈도우 승인 체계
      • 속도 저하 때문에 TCP는 바이트를 개별적으로 보내지 않고 세그먼트로 묶어서 보낸다.
    • TCP 전송 스트림의 개념적 구분(4가지)
      • 송신했고 승인이 완료된 바이트
      • 송신했지만 아직 승인되지 않은 바이트
      • 아직 송신하지 않았지만 수신자가 받을 준비를 마친 바이트
      • 아직 송신하지 않았고 수신자가 받을 준비가 안된 바이트
    • 순서 번호 할당과 동기화
      1. 송신했고 승인이 완료된 바이트는 1에서 31까지
      2. 송신했지만 아직 승인되지 않은 바이트는 32에서 45까지
      3. 아직 송신하지 않았지만 수신자가 받을 준비를 마친 바이트는 46에서 51
      4. 아직 송신하지 않았고 수신자가 받을 준비가 안된 바이트는 52에서 95
    • 송신 윈도우와 사용 가능 윈도우
      • 슬라이딩 윈도우 체계의 동작에서 핵심이 되는 것은 송신자가 승인받지 않은 데이터를 한 시점에 얼마나 가질 수 있도록 수신자가 허용하는지다.
      • 허용 가능한 승인받지 않은 데이터 수 - 윈도우(or 송신윈도우)
      • 윈도우
        • 송신자가 전송하도록 허용되어 있는 바이트 수를 결정
        • 범주 2와 범주 3에 속한 바이트 수의 합과 같다
        • 범주 3과 범주 4를 구분하는 지점은 스트림의 맨 처음 승인받지 않은 바이트 번호에 윈도우를 더해서 구할 수 있다.
    • 사용 가능 윈도우의 바이트를 송신한 뒤 TCP범주와 윈도우 크기 변화
    • 승인 처리와 송신 위도우 슬라이딩
      • TCP의 선택적 승인(selective acknowledgment)이라는 기능은 불연속적인 데이터 블록도 승인할 수 있도록 한다.
      • 특정 바이트 범위에 대한 승인을 받은 장비는 목적지 장비가 바이트들을 성공적으로 수신했다는 것을 인지할 수 있다.
      • 그래서 장비는 송신했지만 아직 승인되지 않은 바이트를 송신했고 승인이 완료된 바이트 범주로 이동시킬 수 있다.
      • 그러면 송신 윈도우는 오른쪽으로 이동하고 장비는 더 많은 데이터를 송신할 수 있다.
    • 빠진 승인 처리
      • TCP 승인은 누적되며 송신자에게 수신 장비가 순서 번호까지의 모든 바이트를 성공적으로 수신했다는 사실을 알린다.
      • 그래서 만약 수신 장비가 순서 번호가 뒤바뀐 바이트들을 받았따면 이전 바이트를 모두 수신하기 전까지는 승인을 보낼 수 없다.

TCP 포트, 연결, 연결 식별
  • 장비는 하나 이상의 장비에 있는 여러 프로세스로 많은 TCP 연결을 동시에 맺을 수 있다.
  • 연결이 맺어진 장비의 소켓 번호(연결의 종단이라고 부름)는 연결을 식별한다.
  • 각 종단은 장비의 IP 주소와 포트번호로 구성되기 때문에 클라이언트 IP 주소와 포트번호, 서버 IP 주소와 포트번호가 연결을 식별하게 된다.

TCP 범용 애플리케이션과 서버 포트 할당

포트 # 키워드 프로토콜 설명
20과 21 ftp-data/ftp 파일 전송 프로토콜(FTP)의 데이터와 제어 대형 파일을 송신하는 데 쓰이기 때문에 TCP에 매우 적합하다.
23 telnet 텔넷 프로토콜 대화형 세션 기반 프로토콜. TCP의 연결 기반 특성을 필요로 한다.
25 smtp 단순 메일 전송 프로토콜 명령을 교환하고 장비 간에 대형 파일을 보낼 수도 있다.
53 domain 도메일 네임 서버(DNS) UDP와 TCP를 모두 사용하는 프로토콜이다.
단순한 요청과 응답의 경우 DNS는 UDP를 사용한다.
대형 메시지(특히 구역 전달)의 경우에는 TCP를 사용한다.
70 gopher 고퍼 프로토콜 WWW로 대부분 대체된 메시징 프로토콜
80 http 하이퍼텍스트 전송 프로토콜 TCP 기반 메시징 프로토콜의 전통적인 예제
110 pop3 포스트 오피스 프로토콜(POP) 버전 3 이메일 메시지 수신 프로토콜로 TCP를 이용하여 명령과 데이터를 교환한다.
119 nntp 유즈넷 뉴스 전송 프로토콜 유즈넷 메시지를 전달하는 데 쓰인다. 이 메시지는 매우 길 수도 있다.
139 netbios-ssn NetBIOS 세션 서비스 세션 프로토콜로 UDP 보다는 TCP에 적합하다.
143 imap 인터넷 메시지 접근 프로토콜 또 다른 이메일 메시지 수신 프로토콜
179 bgp 경계 경로 프로토콜 RIP와 OSPF 같은 내부 라우팅 프로토콜은 UDP나 IP를 직접 사용하지만 BGP는 TCP 위에서 동작한다.
그래서 bGP는 원거리에 있는 장비와도 안정적으로 통신할 수 있다.
194 irc 인터넷 릴레이 채팅 IRC는 클라이언트와 서버 간의 지속적 연결에 기반한 대화형 프로토콜이라는 점에서 텔넷과 유사하다
2049 nfs 네트워크 파일 시스템 NFS는 원래 성능 문제로 UDP로 구현됐다. 하지만 NFS는 대형 파일을 전달해야 하며 UDP는 신뢰할 수 없는 프로토콜이기 때문에 NFS 개발자들은 TCP 버전을 새로 개발했다. 최신 버전의 NFS는 오직 TCP만을 사용한다.
6000-6063 TCP x11 X 윈도우 그래픽 시스템에 쓰인다. 다수의 세션을 위한 다수의 포트가 예약돼 있다.