맨위로가기

전송 제어 프로토콜

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

전송 제어 프로토콜(TCP)은 인터넷 프로토콜(IP) 네트워크에서 신뢰성 있는 데이터 전송을 위한 통신 프로토콜이다. 1974년 빈트 서프와 밥 칸에 의해 개발되었으며, 연결 지향 방식과 데이터그램 서비스를 모두 제공한다. TCP는 데이터의 순서 보장, 손실된 패킷의 재전송, 흐름 제어, 혼잡 제어 등의 기능을 통해 안정적인 데이터 전송을 지원한다. TCP 세그먼트 구조, 주요 제어 플래그, 3-way 핸드셰이크를 통한 연결 설정, 4-way 핸드셰이크를 통한 연결 종료, 신뢰성 있는 전송, 오류 감지, 흐름 제어, 혼잡 제어 등의 메커니즘을 통해 작동한다. TCP는 다양한 보안 취약점에 노출될 수 있으며, 서비스 거부 공격, 연결 하이재킹, TCP 거부 공격 등이 발생할 수 있다. TCP는 웹, 이메일, 파일 전송 등 다양한 인터넷 응용 프로그램에 사용되지만, 실시간 애플리케이션에는 UDP와 같은 다른 프로토콜이 사용되기도 한다.

더 읽어볼만한 페이지

  • 전송 계층 프로토콜 - 사용자 데이터그램 프로토콜
    사용자 데이터그램 프로토콜(UDP)은 연결 설정 없이 데이터를 전송하는 비연결형 전송 프로토콜로, 메시지 전달 보장은 상위 계층에 맡기지만 속도가 중요한 애플리케이션에서 널리 사용된다.
  • 전송 계층 프로토콜 - 점대점 터널링 프로토콜
    점대점 터널링 프로토콜(PPTP)은 VPN 구축을 위해 개발되었으나 보안 취약점으로 인해 사용이 권장되지 않으며 대한민국에서는 정부 및 공공기관에서 사용이 금지된 프로토콜이다.
  • 인터넷 표준 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
  • 인터넷 표준 - IPv6
    IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다.
  • 인터넷 프로토콜 - IPTV
    IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다.
  • 인터넷 프로토콜 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
전송 제어 프로토콜
개요
프로토콜 이름전송 제어 프로토콜 (Transmission Control Protocol)
약칭TCP
개발자빈트 서프와 밥 칸
개발일1974년
기반전송 제어 프로그램 (Transmission Control Program)
OSI 모델 계층전송 계층 (4)
포트해당 사항 없음
RFC9293
하드웨어해당 사항 없음
IP 스택
응용 계층BGP, DHCP, DNS, FTP, HTTP, IMAP, IRC, LDAP, MGCP, MQTT, NNTP, NTP, SNTP, TIME, POP, RIP, OSPF, ONC RPC, RTP, SIP, SMTP, SNMP, SSH, Telnet, TFTP, TLS/SSL, XMPP
전송 계층TCP, UDP, DCCP, SCTP, RSVP, QUIC
인터넷 계층IP (IPv4, IPv6), ICMP, ICMPv6, NDP, IGMP, IPsec
링크 계층ARP, SPB, 터널링, L2TP, PPP, MAC (이더넷, IEEE 802.11, DSL, ISDN)

2. 역사

1974년 5월 전기 전자 기술자 협회(IEEE)는 “''A Protocol for Packet Network Intercommunication.''”[96]이라는 제목의 논문을 발표했다. 이 논문에서 빈트 서프와 밥 칸은 노드 간의 정보 공유를 위한 패킷 스위칭 방식의 망간 프로토콜을 제안하였다. 이들은 연결 지향 링크와 호스트 간의 데이터그램 서비스를 모두 포함하는 ''전송 제어 프로그램''을 제시했다. 초기에는 단일 구성 요소였던 이 프로그램은, 이후 연결 지향 계층의 ''전송 제어 프로토콜(TCP)''과 망간(데이터그램) 계층의 ''인터넷 프로토콜(IP)''로 나뉘는 모듈식 구조로 변경되었다. 이 모델은 ''TCP/IP''로 널리 알려졌으며, 공식적으로는 ''인터넷 프로토콜 스위트''라고 불린다.

TCP는 1980년 1월에 로 표준화되었다.

2004년, 빈트 서프와 밥 칸은 TCP/IP에 대한 기본적인 연구로 튜링상을 수상했다.[10][11]

2. 1. 기원

1974년 5월 전기 전자 기술자 협회(IEEE)는 ''A Protocol for Packet Network Intercommunication.''이라는 제목의 논문을 발표했다.[96] 이 논문의 저자인 빈트 서프와 밥 칸은 노드 간의 정보 공유를 위해 패킷 스위칭 방식의 망간 프로토콜(internetworking protocol)을 제안했다. 이 모델의 핵심 제어 요소는 연결 지향 링크(connection-oriented links)와 호스트 간의 데이터그램 서비스를 모두 포함하는 ''전송 제어 프로그램''(Transmission Control Program)이었다. 당시 단일 구성 요소였던 통신 제어 프로그램은 이후 연결 지향 계층의 ''통신 제어 프로토콜''(TCP)과 망간(데이터그램) 계층의 ''인터넷 프로토콜(IP)''로 나뉘어 모듈식 구조로 변경되었다. 이 모델은 흔히 편의상 두 가지를 합쳐 ''TCP/IP''라고 부르며, 공식적인 명칭은 ''인터넷 프로토콜 스위트''이다.

2. 2. 발전 과정

1974년 5월, 빈트 서프와 밥 칸은 네트워크 노드 간의 패킷 교환을 사용하여 자원을 공유하기 위한 인터네트워킹 프로토콜을 설명했다.[2] 이들은 프랑스 CYCLADES 프로젝트의 개념을 새로운 네트워크에 통합하기 위해 제라르 르 란과 협력했다.[3] 1974년 12월, 빈트 서프, 요겐 달라르, 칼 선샤인에 의해 결과 프로토콜의 규격인 RFC 675영어(''인터넷 전송 제어 프로그램 규격'')가 출판되었다. 이 문서에는 ''인터넷''이라는 용어가 ''인터네트워크''의 약어로 처음 사용되었다.

초기 전송 제어 프로그램은 호스트 간 연결 지향 링크와 데이터그램 서비스를 모두 통합했다. 이후 버전 4에서 모듈식 아키텍처로 나뉘면서 ''전송 제어 프로토콜''과 ''인터넷 프로토콜''로 구성되었고,[4][5] 이로 인해 ''TCP/IP''로 널리 알려진 네트워킹 모델이 탄생했다.[6][7][8]

TCP는 1980년 1월에 표준화되었다. 2004년, 빈트 서프와 밥 칸은 TCP/IP에 대한 기본적인 연구로 튜링상을 수상했다.[10][11]

TCP는 복잡한 프로토콜이지만, 기본적인 작동 방식은 1981년 9월에 발표된 v4 규격 RFC 793영어 이후 크게 바뀌지 않았다. 1989년 10월에 발표된 RFC 1122영어는 여러 TCP 프로토콜 구현 요구 사항을 명확히 했다.

최근 몇 년 동안 가장 중요한 TCP 관련 RFC 중 하나인 RFC 2581영어은 과도한 혼잡을 방지하는 업데이트된 알고리즘을 설명하는 TCP 혼잡 제어를 다룬다. 2001년에는 혼잡 회피 신호 메커니즘인 명시적 혼잡 알림(ECN)을 설명하기 위해 RFC 3168영어이 작성되었다.

원래 TCP 혼잡 회피 알고리즘은 ''TCP Tahoe''로 알려졌지만, 그 이후로 TCP Reno, TCP Vegas, FAST TCP, TCP New Reno, TCP Hybla 등 많은 대체 알고리즘이 제안되었다.

다중 경로 TCP(MPTCP)는 IETF 내에서 진행 중인 노력으로, TCP 연결이 여러 경로를 사용하여 리소스 사용을 최대화하고 중복성을 높이는 것을 목표로 한다.[39] 다중 경로 TCP의 참조 구현[40]은 리눅스 커널에서 개발되었다.[41]

TCP Fast Open은 두 종단점 간의 연속적인 TCP 연결을 빠르게 열기 위한 확장 기능으로, 2014년 RFC 7413영어으로 발표되었다.

2013년 5월에 제안된 비례 속도 감소(PRR)는 Google 엔지니어들이 개발한 TCP 확장 기능으로, 복구 속도를 개선하도록 설계되었다.[45]

TCP 쿠키 트랜잭션(TCPCT)은 2009년 12월에 제안된 확장 기능으로 서비스 거부 공격으로부터 서버를 보호하기 위한 것이다. 2016년, TCPCT는 TCP 패스트 오픈을 선호하여 사용 중단되었다.

tcpcrypt는 TCP 자체에서 전송 수준 암호화를 직접 제공하기 위해 2010년 7월에 제안된 확장 기능이다. 2019년 5월 IETF에서 tcpcrypt RFC가 발표되었다.[43]

3. 기능

TCP는 IP 네트워크 상에서 사용되며 다음과 같은 기능을 제공한다. 이러한 기능을 실현하는 기구는 #프로토콜 조작을 참조한다.[12]


  • 신뢰성 있는 전송: TCP는 '재전송을 통한 긍정적 응답' 기술을 사용하여 데이터가 손실 없이, 순서대로, 정확하게 전달되도록 보장한다. 수신자는 데이터를 받을 때마다 응답 메시지를 보내고, 송신자는 응답을 받지 못하면 데이터를 재전송한다.
  • 연결 지향: IP는 통신 확인 없이 패킷을 전송하지만, TCP는 소켓 쌍을 기반으로 하는 커넥션(가상 회선)을 정의하여 연결 지향 통신을 제공한다. 이를 통해 단일 애플리케이션이 여러 커넥션(대상 애플리케이션)을 독립적으로 처리할 수 있다.
  • 흐름 제어: TCP는 송신자와 수신자 간의 데이터 전송 속도를 조절하여 수신자가 처리할 수 있는 만큼의 데이터만 받도록 한다.
  • 혼잡 제어: TCP는 네트워크 혼잡을 감지하고 데이터 전송 속도를 조절하여 네트워크 혼잡을 완화한다.
  • 다중화: TCP는 여러 애플리케이션이 동시에 하나의 TCP 연결을 공유할 수 있도록 한다.


IP가 데이터의 실제 전달을 처리하는 동안, TCP는 ''세그먼트''를 추적한다. 세그먼트는 네트워크를 통해 효율적인 라우팅을 위해 메시지가 분할되는 개별 데이터 전송 단위이다. 예를 들어, 웹 서버에서 HTML 파일이 전송될 때, 해당 서버의 TCP 소프트웨어 계층은 파일을 세그먼트로 분할하여 네트워크 스택의 인터넷 계층으로 개별적으로 전달한다. 인터넷 계층 소프트웨어는 대상 IP 주소를 포함하는 헤더를 추가하여 각 TCP 세그먼트를 IP 패킷으로 캡슐화한다. 대상 컴퓨터의 클라이언트 프로그램이 이를 수신하면 전송 계층의 TCP 소프트웨어가 세그먼트를 다시 조립하고 파일 내용을 수신 응용 프로그램으로 스트리밍하면서 올바른 순서와 오류가 없음을 보장한다.

4. 특징

TCP는 신뢰성 있는 바이트 스트림 전달 서비스로, 전송된 바이트와 동일하고 순서가 보장된 데이터를 애플리케이션에 제공한다.[12] 패킷 전송이 신뢰할 수 없는 네트워크 환경에서 TCP는 '재전송을 통한 긍정적 응답' 기술을 사용하여 신뢰성을 확보한다. 즉, 수신자가 데이터를 받을 때 응답 메시지를 보내고, 송신자는 각 패킷의 기록과 타이머를 유지하여 응답이 오지 않으면 패킷을 재전송한다.[12]

TCP는 속도보다 완전성을 중요하게 여긴다. 패킷 도착이 보장되고 데이터 순서가 올바르게 정렬되지만, 메시지 순서가 바뀌거나 손실된 메시지의 재전송을 기다릴 때 비교적 긴 지연(수 초)이 발생할 수 있다. 따라서 데이터 오류가 허용되지 않는 파일 전송 등에 주로 사용되며, VoIP처럼 실시간성이 중요한 애플리케이션에는 적합하지 않다. 이러한 경우에는 사용자 데이터그램 프로토콜(UDP) 기반의 실시간 전송 프로토콜(RTP) 등이 권장된다.[56]

TCP는 월드 와이드 웹(WWW), 전자 메일, 파일 전송 프로토콜, Secure Shell, 파일 공유, 일부 스트리밍 등에 사용된다.

TCP는 지연 차단의 영향을 받을 수 있다. 패킷 재정렬이나 패킷 손실로 인해 재전송이 필요할 때, 스트림에서 순서상 나중 데이터가 먼저 도착해도 앞선 데이터가 올 때까지 기다려야 하므로 네트워크 지연 시간이 발생한다.

5. TCP 세그먼트 구조

TCP 세그먼트는 헤더와 데이터 두 부분으로 구성된다.[97] TCP 헤더는 10개의 필수 필드와 옵션 확장 필드를 포함한다. 헤더 뒤에는 데이터 섹션이 따라오며, 이는 애플리케이션을 위한 페이로드 데이터를 담고 있다. 데이터 섹션의 길이는 TCP 세그먼트 헤더에 명시되지 않지만, 전체 IP 데이터그램 길이에서 TCP 헤더와 IP 헤더 길이를 뺀 값으로 계산할 수 있다.[97]

TCP 헤더의 구조는 다음과 같다.

TCP 헤더
오프셋옥테트0123
옥테트비트 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0 0송신 포트수신 포트
432시퀀스 번호
864확인 응답 번호 (ACK 설정시)
1296데이터 오프셋예약
0 0 0		N
S		C
W
R		E
C
E		U
R
G		A
C
K		P
S
H		R
S
T		S
Y
N		F
I
N		윈도우 크기
16128체크섬긴급 포인터 (URG 플래그가 설정된 경우)
20
...		160
...		옵션 (data offset > 5인 경우. 필요시 끝부분에 "0" 바이트로 패딩 됨.)
...


  • 송신 포트 (16비트): 송신 측 포트 번호.[97]
  • 수신 포트 (16비트): 수신 측 포트 번호.[97]
  • 시퀀스 번호 (32비트): 송수신측의 데이터 순서를 맞추기 위한 번호.
  • 확인 응답 번호 (32비트): 수신측에서 예상하는 다음 시퀀스 번호.
  • 데이터 오프셋 (4비트): TCP 헤더 크기를 32비트 워드 단위로 나타낸 값.
  • 예약 (3비트): 미래 사용을 위해 예약된 필드.
  • 플래그 (9비트): 제어 비트.
  • 윈도우 크기 (16비트): 수신 윈도우 크기.
  • 체크섬 (16비트): 헤더 및 데이터 오류 확인.
  • 긴급 포인터 (16비트): 긴급 데이터 위치.
  • 옵션 (가변 0–320 비트, 32의 배수): 최대 세그먼트 크기, 윈도우 스케일링, 선택적 확인응답 등 지원.


TCP 헤더 패딩은 TCP 헤더의 종료 지점과 데이터의 시작 지점을 32 비트 단위 길이에 맞추기 위해 사용되며 값은 0이다.[105]

5. 1. TCP 헤더 필드

0 0 0N
SC
W
RE
C
EU
R
GA
C
KP
S
HR
S
TS
Y
NF
I
N윈도우 크기16128체크섬긴급 포인터 (URG 플래그가 설정된 경우)20
...160
...옵션 (data offset > 5인 경우. 필요시 끝부분에 "0" 바이트로 패딩 됨.)
...



옵션 종류옵션 길이옵션 데이터목적참고 사항
0옵션 목록 끝
1연산 없음이는 성능 향상을 위해 32비트 경계에서 옵션 필드를 정렬하는 데 사용할 수 있습니다.
24SS최대 세그먼트 크기[SYN]
33S윈도 조정[SYN]
42선택적 확인응답 허용[SYN]
5N (10, 18, 26, 또는 34)BBBB, EEEE, ...선택적 ACK(SACK)이 처음 두 바이트 뒤에는 선택적으로 확인되는 1–4개의 블록 목록이 있으며, 32비트 시작/끝 포인터로 지정됩니다.
810TTTT, EEEETCP 타임스탬프
14,3,S (24 비트)–TCP Alternate Checksum Request[SYN]
15,N,... (가변 비트)–TCP Alternate Checksum Data.

5. 2. 주요 제어 플래그

TCP는 데이터의 각 바이트를 식별하기 위해 ''순서 번호''를 사용한다. 순서 번호는 각 컴퓨터에서 전송된 바이트의 순서를 식별하여, 순서가 뒤바뀐 전달에 관계없이 데이터를 순서대로 재구성할 수 있도록 한다. 첫 번째 바이트의 순서 번호는 SYN 플래그가 설정된 첫 번째 패킷에 대해 전송자가 선택한다. 이 번호는 임의로 지정될 수 있으며, TCP 순서 예측 공격으로부터 방어하기 위해 예측 불가능해야 한다.

수신자는 데이터 수신자로서 지정된 바이트까지의 데이터가 수신되었음을 전송자에게 알리기 위해 순서 번호와 함께 승인(ACK)을 보낸다. ACK는 데이터가 응용 프로그램에 전달되었음을 의미하지 않으며, 단지 데이터를 전달하는 책임이 현재 수신자에게 있음을 의미할 뿐이다.

신뢰성은 전송자가 손실된 데이터를 감지하고 이를 재전송함으로써 달성된다. TCP는 손실을 식별하기 위해 재전송 시간 초과(RTO)와 중복 누적 승인(DupAcks)의 두 가지 주요 기술을 사용한다.

TCP 세그먼트가 재전송될 때, 원래 전송 시도와 동일한 순서 번호를 유지한다. 이러한 전달과 논리적 데이터 순서의 혼합은 재전송 후에 승인이 수신될 때, 전송자가 원래 전송과 재전송 중 어느 것이 승인되는지 알 수 없다는 것을 의미하며, 이를 ''재전송 모호성''이라고 한다.

6. 프로토콜 작동

전송 제어 프로토콜(TCP) 프로토콜 작동은 크게 연결 생성, 자료 전송, 연결 종료의 세 단계로 나뉜다.

TCP는 인터넷 모델의 전송 계층에서 호스트 간 연결을 제공한다. 최대 전송 단위를 고려한 IP 단편화 등 복잡한 과정은 TCP가 추상화하여 제공하므로, 응용 프로그램은 이를 알 필요 없이 네트워크 연결을 이용할 수 있다.[12]

TCP는 네트워크 정체, 로드 밸런싱 등으로 인한 IP 패킷 문제를 감지하고, 손실 데이터 재전송, 순서 재정렬 등을 수행한다. 수신된 데이터는 재조립되어 응용 프로그램에 전달된다.[12]

월드 와이드 웹(WWW), 이메일, 파일 전송 프로토콜 등 많은 인터넷 응용 프로그램이 TCP를 사용한다. TCP는 정확한 전달에 최적화되어 있어 VoIP와 같은 실시간 응용에는 사용자 데이터그램 프로토콜(UDP) 기반의 실시간 전송 프로토콜(RTP) 등이 더 적합하다.[12]

간략화된 TCP 상태 다이어그램.


TCP 연결은 인터넷 소켓을 통해 운영 체제에서 관리되며, 연결 동안 아래 표와 같은 여러 상태를 거친다.

TCP 소켓 상태
상태종단점설명
LISTEN (리스닝)서버원격 TCP 종단점으로부터의 연결 요청 대기
SYN-SENT (SYN-보냄)클라이언트연결 요청 후, 일치하는 연결 요청 대기
SYN-RECEIVED (SYN-받음)서버연결 요청 수신 및 전송 후, 연결 요청 확인 대기
ESTABLISHED (설정됨)서버 및 클라이언트연결된 상태. 수신 데이터는 사용자에게 전달 가능
FIN-WAIT-1 (FIN-대기-1)서버 및 클라이언트원격 TCP의 연결 종료 요청 또는 이전 종료 요청에 대한 확인 대기
FIN-WAIT-2 (FIN-대기-2)서버 및 클라이언트원격 TCP로부터의 연결 종료 요청 대기
CLOSE-WAIT (닫힘-대기)서버 및 클라이언트로컬 사용자로부터의 연결 종료 요청 대기
CLOSING (닫힘)서버 및 클라이언트원격 TCP의 연결 종료 요청 확인 대기
LAST-ACK (최종-ACK)서버 및 클라이언트이전의 원격 TCP 연결 종료 요청에 대한 확인 대기
TIME-WAIT (시간-대기)서버 또는 클라이언트연결에 남아 있는 패킷 만료를 위한 충분한 시간 대기
CLOSED (닫힘)서버 및 클라이언트연결 상태 없음


6. 1. 연결 설정

TCP는 클라이언트와 서버 간의 연결을 설정하기 위해 3-웨이 핸드셰이크를 수행한다.[67]

3-웨이 핸드셰이크에서의 전형적인 상태 변화. 상태 변화에 사용되는 소켓 호출을 부기했다.


클라이언트가 서버에 연결하기 전에, 서버는 연결을 위해 포트를 바인딩하고 수신 대기(listen)해야 한다. 이를 수동 열기(passive open)라고 한다. 서버 측에서 수동 열기가 설정되면, 클라이언트는 능동 열기(active open)를 시작하여 연결을 설정할 수 있다. 연결 설정은 다음과 같은 3단계 (3-웨이 핸드셰이크)로 이루어진다.

# '''SYN''': 클라이언트가 서버에 SYN 메시지를 보낸다. 이 메시지에 포함된 시퀀스 번호는 클라이언트가 임의로 설정한 값 A이다.

# '''SYN-ACK''': 서버가 클라이언트에게 SYN-ACK 메시지로 응답한다. 이 메시지에 포함된 시퀀스 번호는 서버가 임의로 설정한 값 B이며, 응답 번호는 (A + 1)이다.

# '''ACK''': 클라이언트가 서버에게 ACK 메시지를 보낸다. 이 메시지에 포함된 응답 번호는 (B + 1)이다.

1단계와 2단계는 클라이언트에서 서버로의 시퀀스 번호를 설정하고 승인한다. 2단계와 3단계는 서버에서 클라이언트로의 시퀀스 번호를 설정하고 승인한다. 이 단계들이 완료되면 클라이언트와 서버 모두 연결이 설정되었음을 확인받고, 양방향 통신(full-duplex communication)이 가능해진다.

6. 2. 연결 종료

연결 종료 단계는 4-way 핸드셰이크를 사용하며, 연결의 각 측면이 독립적으로 종료된다. 엔드포인트가 연결의 절반을 중단하려 할 때 FIN 패킷을 전송하며, 다른 쪽 끝은 ACK로 이를 승인한다. 따라서 일반적인 연결 종료에는 각 TCP 엔드포인트에서 FIN 및 ACK 세그먼트 쌍이 필요하다.[16]

연결 종료


먼저 FIN을 보낸 측이 최종 ACK로 응답한 후에는 연결을 최종적으로 닫기 전에 타임아웃을 기다리며, 이 시간 동안 로컬 포트는 새 연결에 사용할 수 없다. 이 상태는 TCP 클라이언트가 ACK가 전송 중에 손실된 경우 서버에 최종 승인을 다시 보낼 수 있도록 한다. 시간 지속 시간은 구현에 따라 다르지만, 일반적인 값은 30초, 1분 및 2분이다. 타임아웃 후 클라이언트는 CLOSED 상태가 되고 로컬 포트는 새 연결에 사용할 수 있게 된다.[16]

호스트 A가 FIN을 보내고 호스트 B가 FIN & ACK로 응답하고 (두 단계를 하나로 결합) 호스트 A가 ACK로 응답하는 3-way 핸드셰이크로 연결을 종료할 수도 있다.[17]

연결은 반 열림 상태가 될 수 있으며, 이 경우 한쪽은 연결을 종료했지만 다른 쪽은 그렇지 않다. 종료된 쪽은 더 이상 연결로 데이터를 보낼 수 없지만, 다른 쪽은 가능하다. 종료 측은 다른 쪽도 종료할 때까지 데이터를 계속 읽어야 한다.

6. 3. 데이터 전송

TCP는 순서 번호와 확인 응답 번호를 사용하여 데이터의 순서와 신뢰성을 보장한다. 송신 측은 전송한 각 패킷의 기록을 유지하고 타이머를 사용하여 패킷 손실을 감지하며, 필요시 재전송을 요청한다. 수신 측은 데이터를 수신할 때 응답 메시지로 확인한다.[12]

TCP는 흐름 제어 및 혼잡 제어를 통해 네트워크 상황에 맞춰 데이터 전송 속도를 조절한다. 흐름 제어는 수신 측의 버퍼 용량에 따라 송신 측의 전송 속도를 제한하고, 혼잡 제어는 네트워크 혼잡을 감지하여 전송 속도를 줄인다.[12]

월드 와이드 웹(WWW), 이메일, 파일 전송 프로토콜, 보안 셸, P2P 파일 공유, 스트리밍 미디어 등 많은 인터넷 응용 프로그램에서 TCP를 사용한다.[12] TCP는 정확한 전달에 최적화되어 있어, 순서가 바뀌거나 손실된 메시지의 재전송을 기다리는 동안 비교적 긴 지연이 발생할 수 있다. 따라서 VoIP와 같은 실시간 응용 프로그램에는 사용자 데이터그램 프로토콜(UDP)을 사용하는 실시간 전송 프로토콜(RTP)과 같은 프로토콜이 더 적합하다.[12]

6. 3. 1. 신뢰성 있는 전송

TCP는 순서 번호를 사용하여 각 바이트를 식별한다. 순서 번호는 각 컴퓨터에서 전송된 바이트의 순서를 나타내어, 순서가 뒤바뀐 전달이 발생하더라도 데이터를 순서대로 재구성할 수 있게 한다. 첫 바이트의 순서 번호는 SYN 플래그가 설정된 첫 패킷에서 전송자가 선택하며, TCP 순서 예측 공격을 막기 위해 예측 불가능해야 한다.[12]

수신자는 데이터 수신을 알리기 위해 순서 번호와 함께 확인 응답(ACK)을 보낸다. ACK는 데이터가 응용 프로그램에 전달되었음을 의미하는 것이 아니라, 수신자가 데이터 전달 책임을 갖게 됨을 의미한다.[12]

TCP는 손실된 데이터를 감지하고 재전송하여 신뢰성을 확보한다. 손실을 식별하는 주요 기술은 재전송 타임아웃(RTO)과 중복 누적 응답(DupAcks)이다.[12]

TCP 세그먼트 재전송 시, 원래 전송과 동일한 순서 번호를 유지한다. 이러한 전달과 데이터 순서의 혼합은 재전송 후 응답 수신 시, 전송자가 어느 전송이 승인되는지 알 수 없게 하여 ''재전송 모호성''을 야기한다. TCP는 재전송 모호성으로 인해 복잡성이 발생한다.

6. 3. 2. 오류 감지

정확성을 보장하기 위해 체크섬 필드가 포함되어 있다. TCP 체크섬은 현대적인 기준으로는 약한 검사이며, 일반적으로 CRC 무결성 검사와 계층 2에서 함께 사용된다. TCP와 IP 모두 데이터 링크 계층 아래에 위치하며, PPP 또는 이더넷 프레임에서 사용되는 것과 같다. 그러나 CRC로 보호되는 홉 사이의 패킷에서 오류가 발생하는 것은 흔하며, 16비트 TCP 체크섬은 이러한 오류의 대부분을 감지한다.[23] 이는 종단간 원칙이 기능하는 예이다.

IPv4 상의 TCP의 경우, 체크섬 계산법은 RFC 793에 정의되어 있으며, 계산 시 IPv4 패킷 헤더를 모방한 가상 헤더도 포함한다. 가상 헤더를 포함한 체크섬 계산 범위는 아래와 같다.

체크섬 계산용 TCP 가상 헤더 (IPv4)
비트 오프셋0–34–78–1516–31
0송신 IP 주소
32목적지 IP 주소
640프로토콜 번호 (6)패킷 길이
96송신 포트수신 포트
128시퀀스 번호
160확인 응답 번호
192헤더 길이예약플래그군윈도우 크기
224체크섬긴급 포인터
256옵션 (있을 경우)
256/288+ 
데이터
 



위 표에서 핑크색 부분은 IPv4 헤더의 일부이다. 프로토콜 번호는 TCP에서 6이다. 패킷 길이는 TCP 헤더와 데이터의 합계 길이이다.

IPv6 상의 TCP의 경우, 체크섬 계산법은 RFC 2460에서 제시하는 바와 같이 변경되었다. 체크섬 계산에 사용하는 IPv6 헤더를 흉내낸 의사 헤더는 다음과 같다.

체크섬 계산용 TCP 의사 헤더 (IPv6)
Bit offset0 - 78–1516–2324–31
0송신 IP 주소
32
64
96
128수신 IP 주소
160
192
224
256패킷 길이
2880다음 헤더
320송신 포트수신 포트
352시퀀스 번호
384확인 응답 번호
416헤더 길이예약플래그윈도우 크기
448체크섬긴급 포인터
480옵션 (있으면)
480/512+ 
데이터
 


6. 3. 3. 흐름 제어

TCP는 슬라이딩 윈도우 흐름 제어 프로토콜을 사용한다. TCP는 각 세그먼트의 "윈도우 크기" 필드를 통해 수신 측이 받을 수 있는 데이터의 양(바이트 단위)을 나타낸다. 송신 측은 수신 측이 지정한 윈도우 크기만큼의 데이터만 보낼 수 있으며, 새로운 확인 응답을 받을 때마다 윈도우 크기를 확인하여 추가로 보낼 수 있는 데이터 양을 갱신한다.[56]

수신 측이 윈도우 크기를 0으로 설정하면 송신 측은 데이터 전송을 중지하고 지속 타이머(persist timer)를 시작한다. 이 타이머는 수신 측의 윈도우 크기 갱신 세그먼트가 손실되어 데드락이 발생하는 것을 방지한다. 타이머가 만료되면 송신 측은 작은 패킷을 보내 수신 측의 윈도우 크기가 복구되었는지 확인한다.[56]

수신 측의 데이터 처리 속도가 느리면 윈도우 크기가 작게 유지되는 현상이 발생할 수 있다. 이를 silly window syndrome|실리 윈도우 증후군영어라고 하며, 이 경우 송신 측은 한 번에 몇 바이트의 데이터만 보낼 수 있어 전송 효율이 매우 낮아진다. 이러한 상황을 방지하기 위한 윈도우 알고리즘은 RFC 813에 기술되어 있다.[56]

TCP 시퀀스 번호와 수신 윈도우 크기는 시계와 같이 움직인다. 수신 윈도우는 새로운 세그먼트의 데이터를 수신했을 때와 확인 응답을 반환했을 때 이동한다. 시퀀스 번호는 최대값에 도달하면 0으로 돌아간다.

6. 3. 4. 혼잡 제어

TCP는 네트워크 혼잡을 방지하기 위해 여러 메커니즘을 사용한다. 이러한 메커니즘은 네트워크에 들어오는 데이터의 속도를 제어하여 데이터 흐름이 붕괴를 유발할 수 있는 속도 이하로 유지하도록 돕는다.

TCP의 최신 구현에는 다음 네 가지 알고리즘이 포함되어 있다.[12]

이러한 알고리즘들은 송신자와 수신자 간의 네트워크 상태를 추론하기 위해 송신 데이터에 대한 응답 또는 응답 부족을 사용한다. 타이머와 함께 TCP 송신자와 수신자는 데이터 흐름의 동작을 변경하여 혼잡 상황에 대응한다.

또한 송신자는 송신자와 수신자 간의 추정된 왕복 시간(RTT)과 이 왕복 시간의 분산을 기반으로 하는 ''재전송 타임아웃''(RTO)을 사용한다. RTT 추정에는 미묘한 점이 있으며, 일반적으로 Karn의 알고리즘 또는 TCP 타임스탬프를 사용한다. 이러한 개별 RTT 샘플은 Jacobson의 알고리즘을 사용하여 평활 왕복 시간(SRTT)을 생성하기 위해 시간에 따라 평균화된다. 이 SRTT 값이 왕복 시간 추정으로 사용된다.

TCP는 손실을 안정적으로 처리하고 오류를 최소화하며 혼잡을 제어하고 매우 빠른 환경에서 빠르게 작동하도록 개선하기 위한 연구 및 표준 개발이 지속적으로 이루어지고 있다. 그 결과, 여러 TCP 혼잡 회피 알고리즘 변형이 존재한다.

6. 4. 최대 세그먼트 크기 (MSS)

최대 세그먼트 크기(MSS)는 TCP가 단일 세그먼트에서 수신할 수 있는 최대 데이터 양을 바이트 단위로 지정한 값이다. 최상의 성능을 위해서는 IP 단편화를 방지할 수 있을 만큼 MSS 값을 작게 설정해야 한다. IP 단편화는 패킷 손실과 과도한 재전송을 유발하여 성능 저하를 초래할 수 있다.[70]

일반적으로 TCP 연결을 설정할 때 MSS 옵션을 사용하여 각 통신 주체는 자신의 MSS 값을 알린다. 이 값은 송신자와 수신자가 직접 연결된 네트워크의 최대 전송 단위(MTU) 크기에서 IP 및 TCP 헤더 크기를 제외한 값으로 결정된다. 또한, TCP 송신자는 경로 MTU 검색을 사용하여 송신자와 수신자 간의 네트워크 경로에서 가장 작은 MTU 값을 추론하고, 이를 기반으로 MSS 값을 동적으로 조정하여 네트워크 내에서 IP 단편화를 방지할 수 있다.[70]

MSS 알림은 ''MSS 협상''이라고도 불리지만, 엄밀히 말하면 양측이 값을 합의하는 '협상'은 아니다. TCP 연결에서 데이터 흐름의 두 방향에 대해 서로 다른 MSS 값을 설정할 수 있다. 즉, 양방향 연결에서 공통 MSS 값을 합의할 필요가 없다. 예를 들어, 한쪽 장치의 메모리 용량이 작아 수신 버퍼 크기를 크게 할 수 없는 경우, 해당 장치는 더 작은 MSS 값을 설정할 수 있다.[70]

6. 5. 선택적 확인 응답 (SACK)

에서 정의된 선택적 확인 응답(Selective Acknowledgement, SACK)은 TCP의 성능 향상을 위한 기능이다. SACK는 수신 측이 불연속적인 데이터 블록을 성공적으로 수신했음을 송신 측에 알릴 수 있게 해준다. 이를 통해 패킷 손실 시 재전송 효율성을 크게 높일 수 있다.

초창기 TCP는 누적 확인 응답 방식만을 사용했는데, 이는 패킷 손실 시 비효율성을 초래할 수 있었다. 예를 들어, 10개의 세그먼트 중 특정 세그먼트가 손실된 경우, 수신 측은 손실된 세그먼트 이전까지만 수신했음을 알릴 수밖에 없었다. 이 때문에 송신 측은 손실된 세그먼트 이후의 모든 데이터를 재전송해야 하는 문제가 발생했다.

SACK는 이러한 문제를 해결하기 위해 도입되었다. SACK 옵션을 사용하면 수신 측은 누적 확인 응답과 함께, 추가적으로 수신에 성공한 불연속적인 블록들을 송신 측에 알릴 수 있다. SACK 옵션은 TCP 헤더에 포함되며, 여러 개의 SACK 블록을 가질 수 있다. 각 SACK 블록은 수신에 성공한 연속적인 데이터 범위의 시작점(블록의 왼쪽 가장자리)과 끝점(블록의 오른쪽 가장자리)을 나타낸다.

예를 들어, 10개의 세그먼트 중 2번째 세그먼트(순서 번호 2000-2999)가 손실된 경우, 수신 측은 누적 ACK 값으로 2000을 보내고, SACK 옵션에 3000-11000 범위를 포함시켜 3000-10999 바이트를 성공적으로 수신했음을 알릴 수 있다. 이를 통해 송신 측은 2000-2999 바이트만 재전송하면 되므로 효율성이 향상된다.

에서 정의된 중복 SACK(D-SACK)는 SACK의 확장 기능이다. D-SACK는 순서가 뒤바뀐 세그먼트가 도착했을 때 발생할 수 있는 불필요한 재전송을 방지한다. 수신 측은 D-SACK를 통해 중복된 패킷을 받았음을 알리고, 송신 측은 이를 통해 전송 속도를 유지하거나 복구할 수 있다.

SACK 옵션은 필수가 아니며, TCP 연결 설정 시 양측이 모두 지원하는 경우에만 사용된다. SACK는 현재 널리 사용되고 있으며, 대부분의 TCP 스택에서 지원된다. 또한, 스트림 제어 전송 프로토콜(SCTP)에서도 선택적 확인 응답이 사용된다.

6. 6. 윈도우 스케일링

TCP 윈도우 크기 조절 옵션은 고대역폭 네트워크를 보다 효율적으로 사용하기 위해 더 큰 TCP 윈도우 크기를 가능하게 하는 기능이다. 16비트 TCP 윈도우 크기 필드는 데이터 흐름을 제어하며, 최대 65,535바이트로 제한된다. 크기 필드를 이 한계 이상으로 확장할 수 없으므로, 스케일링 팩터가 사용된다. TCP 윈도우 크기 조절 옵션은 최대 윈도우 크기를 1기가바이트까지 확장할 수 있게 해준다. 이러한 더 큰 윈도우 크기로의 확장은 TCP 튜닝에 필수적이다.

윈도우 크기 조절 옵션은 TCP 3방향 핸드셰이크 중에만 사용된다. 윈도우 크기 조절 값은 16비트 윈도우 크기 필드를 해석할 때 왼쪽으로 시프트할 비트 수를 나타낸다. 윈도우 크기 조절 값은 각 방향에 대해 독립적으로 0(시프트 없음)에서 14까지 설정할 수 있다. 양쪽 모두에서 윈도우 크기 조절을 활성화하려면 SYN 세그먼트에 옵션을 보내야 한다.

일부 라우터와 패킷 방화벽은 전송 중에 윈도우 크기 조절 팩터를 다시 쓴다. 이로 인해 송신 측과 수신 측은 서로 다른 TCP 윈도우 크기를 가정하게 된다. 그 결과 불안정한 트래픽이 발생하여 매우 느려질 수 있다. 이 문제는 결함이 있는 라우터 뒤의 일부 사이트에서 나타난다.[24]

일부 라우터나 방화벽은 이 스케일 팩터를 전송 시에 변경하는 경우가 있다. 그러면 송신 측과 수신 측에서 윈도우 크기의 인식이 달라져 트래픽이 불안정해지고 매우 느려지는 경우가 있다[71]。

6. 7. TCP 타임스탬프

에 정의된 TCP 타임스탬프는 TCP가 패킷 전송 순서를 결정하는 데 도움을 준다. TCP 타임스탬프는 시스템 클럭과 동기화되지 않고 임의의 값으로 시작한다. 많은 운영 체제는 경과된 밀리초마다 타임스탬프를 증가시키지만, RFC는 틱이 비례해야 한다고만 명시한다.

타임스탬프 필드는 다음과 같다.

TCP 타임스탬프는 순서 번호 래핑 방지(PAWS, Protection Against Wrapped Sequences) 알고리즘()에 사용된다. PAWS는 순서 번호가 한 바퀴 도는 경우(최대 4GB)에 사용된다. 최근 고속 네트워크에서는 순서 번호가 1분 이내에 한 바퀴 돌 수 있는데, 재전송 시 현재 회전인지 이전 회전인지를 식별하는 데 타임스탬프를 사용한다.

의 2.2절에서는 윈도우 크기를 1GB까지로 규정하여, 많은 구현에서 스케일 옵션의 최댓값을 14로 설정하고 있다.

또한, Eifel 감지 알고리즘()은 TCP 타임스탬프를 사용하여 재전송 원인이 패킷 손실인지, 순서가 뒤섞인 것인지 판단한다.

7. 보안 및 기타 문제점

TCP는 다양한 방식으로 공격받을 수 있으며, 2009년에 보안 평가 결과와 완화책이 발표되었다.[31] IETF에서는 2012년까지 이와 관련된 논의를 진행했다.[32] PUSH 및 ACK 플러드는 서비스 거부 공격의 또 다른 변형이다.[36]

7. 1. 취약점

TCP는 다양한 공격에 취약하다. 2009년에 TCP의 보안 평가 결과와 식별된 문제점에 대한 완화책이 발표되었고,[31] 2012년까지 IETF에서 관련 논의가 진행되었다.[32] 주요 취약점으로는 (DoS), 연결 하이재킹, TCP 거부, TCP 재설정 공격 등이 있다.

7. 1. 1. 서비스 거부 (DoS) 공격

IP 주소 변조를 사용하고, 많은 ACK 패킷 다음에 의도적으로 조작된 SYN 패킷을 반복적으로 전송하여 공격자는 서버가 가짜 연결을 추적하는 데 많은 양의 리소스를 소비하도록 할 수 있다. 이는 SYN 플러드 공격으로 알려져 있다.[33] 이 문제에 대한 제안된 해결책으로는 SYN 쿠키와 암호화 퍼즐이 있지만, SYN 쿠키는 자체적인 취약점을 가지고 있다.[33] Sockstress는 유사한 공격이며, 시스템 리소스 관리로 완화될 수 있다.[34] TCP ''지속 타이머''의 악용과 관련된 고급 DoS 공격은 Phrack No. 66에서 분석되었다.[35]

7. 1. 2. 연결 하이재킹

TCP 연결 가로채기는 공격자가 TCP 세션을 도청하고 패킷을 리디렉션할 수 있는 공격이다. 공격자는 진행 중인 통신에서 시퀀스 번호를 학습하고 스트림의 다음 세그먼트처럼 보이는 위조된 세그먼트를 위조한다. 간단한 가로채기는 한쪽 끝에서 하나의 패킷이 잘못 수락되는 결과를 초래할 수 있다. 수신 호스트가 잘못된 세그먼트를 승인하면 동기화가 손실된다.[37] 가로채기는 공격자가 ARP 스푸핑 또는 기타 라우팅 공격과 결합될 수 있으며, 이를 통해 공격자는 TCP 연결을 영구적으로 제어할 수 있다.

RFC 1948영어 이전에는 초기 ''시퀀스 번호''를 쉽게 추측할 수 있었기 때문에 다른 IP 주소를 가장하는 것이 어렵지 않았다. 이전 구현에서는 공격자가 ARP 또는 라우팅 공격을 통해 통신을 가로챌 필요 없이, 수신자가 다른 IP 주소에서 온 것으로 믿는 일련의 패킷을 맹목적으로 보낼 수 있었다. 가장된 IP 주소의 합법적인 호스트가 다운되었는지 확인하거나 서비스 거부 공격을 사용하여 해당 상태로 만드는 것만으로 충분했다. 이러한 이유로 초기 시퀀스 번호는 이제 무작위로 선택된다.

7. 1. 3. TCP 거부

TCP는 다양한 방식으로 공격받을 수 있다. TCP의 철저한 보안 평가 결과와 식별된 문제에 대한 가능한 완화책은 2009년에 발표되었으며,[31] 2012년까지 IETF 내에서 추진되었다.[32] 주요 취약점으로는 서비스 거부, 연결 하이재킹, TCP 거부 및 TCP 재설정 공격 등이 있다.

공격자는 도청을 통해 다음에 전송될 패킷의 크기를 예측할 수 있으며, 기존 연결을 방해하지 않고 악성 페이로드를 수신자에게 수락하게 할 수 있다. 공격자는 다음 예상 패킷의 시퀀스 번호와 페이로드 크기를 가진 악성 패킷을 주입한다. 정상적인 패킷이 최종적으로 수신되면 이미 수신된 패킷과 동일한 시퀀스 번호와 길이를 갖는 것으로 확인되어 정상적인 중복 패킷으로 조용히 삭제된다. 즉, 정상적인 패킷은 악성 패킷에 의해 "거부"된다. 연결 하이재킹과 달리, 연결은 결코 비동기화되지 않으며 악성 페이로드가 수락된 후에도 통신이 정상적으로 계속된다. TCP 거부는 공격자에게 통신에 대한 통제력을 덜 부여하지만, 공격을 탐지하기 어렵게 만든다. 수신자가 이상함을 감지할 수 있는 유일한 증거는 단일 중복 패킷으로, 이는 IP 네트워크에서 일반적인 현상이다. 거부된 패킷의 송신자는 공격의 증거를 전혀 볼 수 없다.

7. 2. TCP 포트

TCP에서 '''포트'''는 "호스트 내 주소"이다.[81]

단일 호스트에서는 여러 프로세스(≒ 애플리케이션)가 동작하고 있다. TCP는 호스트 내의 "방 번호"에 해당하는 '''포트'''[81]와 포트, 인터넷 주소의 조합인 '''소켓'''(socket영어)을 정의하고,[82] 이 소켓 간 통신을 수행한다. 단일 호스트 내에 복수 포트가 존재함으로써, 단일 호스트 상에서 복수의 프로세스가 동시에 TCP 통신을 할 수 있다(다중화).[83] 각 포트는 '''포트 번호'''라는 포트 식별자가 설정되어 있으며,[84] 프로세스와 포트를 연결함으로써 해당 프로세스로의 통신을 가능하게 한다.[85][86] 포트 번호는 16비트 부호 없는 정수 (0-65535)의 범위를 갖는다.

'''커넥션'''(connection)은 한 쌍의 소켓으로 식별되는 논리적 통신로이다.[87] "소켓 172.16.0.0:1024과 소켓 192.168.0.0:80을 연결하는 논리적 통신로"와 같은 형태로 식별되는 것이 커넥션이다. 수신된 TCP 세그먼트는 특정 커넥션에 속한다고 식별된다.

포트 번호는 크게 웰노운(well-known), 레지스터드(registered), 다이내믹/프라이빗(dynamic/private)의 3가지로 분류된다. 웰노운 포트 번호는 IANA이 할당을 수행하며, 주로 시스템 레벨이나 중요한 프로세스에서 사용된다. 서버로 동작하는 유명한 애플리케이션은 해당 포트를 사용하여 커넥션 확립 요구를 대기한다. 예를 들어, FTP(20, 21), SSH(22), TELNET(23), SMTP(25), HTTP(80) 등이 있다. 레지스터드 포트 번호는 일반적으로 엔드 유저용 애플리케이션이 송신측 에페머럴 포트로 서버에 접속하는 데 사용하지만, 서드 파티가 등록한 이름을 가진 서비스 식별에도 사용된다. 다이내믹/프라이빗 포트 번호도 엔드 유저 애플리케이션에서 사용할 수 있지만, 일반적으로 그런 사용법은 적다. 다이내믹/프라이빗 포트 번호는 그것을 사용하고 있는 특정 TCP 커넥션에서만 의미를 갖는다.

8. 대안 프로토콜

TCP는 많은 응용 분야에 적합하지 않다. 일반적인 구현에서 손실된 패킷의 재전송된 복사본을 받을 때까지 응용 프로그램이 손실된 패킷 이후에 도착하는 패킷에 접근할 수 없다는 점이 문제이다. 이는 스트리밍 미디어, 실시간 멀티플레이어 게임 및 IP 음성(VoIP)과 같은 실시간 응용 프로그램에서 문제가 되는데, 이러한 응용 프로그램에서는 모든 데이터를 순서대로 얻는 것보다 대부분의 데이터를 적시에 얻는 것이 일반적으로 더 유용하다.[12]

역사적, 성능상의 이유로 대부분의 스토리지 영역 네트워크(SAN)는 파이버 채널 연결을 통해 파이버 채널 프로토콜(FCP)을 사용한다.

또한, 임베디드 시스템, 네트워크 부팅, 그리고 엄청난 수의 클라이언트로부터 간단한 요청을 처리하는 서버(예: DNS 서버)의 경우, TCP의 복잡성이 문제가 될 수 있다. NAT 뒤에 있는 두 호스트 간의 데이터 전송(STUN 또는 유사한 시스템 사용)과 같은 몇 가지 트릭은 TCP와 같은 비교적 복잡한 프로토콜이 없는 것이 훨씬 간단하다.

일반적으로 TCP가 부적합한 경우, 사용자 데이터그램 프로토콜(UDP)이 사용된다. UDP는 TCP가 제공하는 애플리케이션 멀티플렉싱 및 체크섬을 제공하지만 스트림 또는 재전송을 처리하지 않아, 애플리케이션 개발자가 상황에 적합한 방식으로 코딩하거나 순방향 오류 정정 또는 보간법과 같은 다른 방법으로 대체할 수 있는 기능을 제공한다.

스트림 제어 전송 프로토콜(SCTP)은 TCP와 유사한 신뢰할 수 있는 스트림 지향 서비스를 제공하는 또 다른 프로토콜이다. TCP보다 새롭고 훨씬 더 복잡하며 아직 널리 배포되지 않았다. 그러나 신뢰성과 거의 실시간 고려 사항이 중요한 상황에서 사용하도록 특별히 설계되었다.

벤투리 전송 프로토콜(VTP)은 무선 데이터 전송과 관련된 인식된 비효율성을 극복하기 위해 TCP를 투명하게 대체하도록 설계된 특허 독점 프로토콜이다.

TCP는 또한 고대역폭 환경에서 문제가 있다. TCP 혼잡 회피 알고리즘은 데이터 송신자를 미리 알 수 없는 임시 환경에서 매우 잘 작동한다. 환경이 예측 가능하다면 비동기 전송 모드(ATM)와 같은 시간 기반 프로토콜은 TCP의 재전송 오버헤드를 피할 수 있다.

9. 하드웨어 구현

TCP 오프로드 엔진(TOE)은 TCP 처리 부하를 줄이기 위한 하드웨어 구현이다. 그러나 컴퓨팅 시스템에 통합하기 어렵고, 컴퓨터나 장치의 운영 체제에 광범위한 변경이 필요하다는 주요 문제점이 있다.[1]

대부분의 TCP/IP 스택 구현은 네트워크 카드를 통한 자동 체크섬 계산을 보조적으로 사용하는 옵션을 제공한다. 이를 통해 CPU 사이클을 체크섬 계산에 소비하는 비용을 줄여 네트워크 성능을 향상시킬 수 있다.[1]

한편, 전송 시 체크섬 계산을 네트워크 카드에 맡기면 LAN 분석기에서 체크섬 오류를 감지할 수 있다.[1]

10. 성능

TCP는 애플리케이션에 신뢰성 있는 바이트 스트림을 제공하지만, 지연 차단의 영향을 받을 수 있다. 패킷 재정렬이나 패킷 손실이 발생하여 재전송이 필요해지면, 스트림의 순차적으로 나중 데이터가 먼저 수신되어도 앞선 데이터가 수신될 때까지 대기해야 하므로 네트워크 지연 시간이 발생한다.[12] 여러 개의 병렬 연결을 열어 지연 차단을 완화할 수 있지만, 연결 설정 비용이 반복적으로 발생하고 엔드포인트에서 해당 연결을 추적하는 데 필요한 리소스가 증가한다.

연결 설정은 웹 사용자가 경험하는 지연 시간의 주요 원인 중 하나이다. TCP의 삼원 핸드셰이크는 데이터를 전송하기 전에 연결 설정 중에 1 RTT의 지연 시간을 유발한다. 전송 계층 보안(TLS)은 자체 핸드셰이크가 필요하며, TCP 핸드셰이크와 순차적으로 진행되어 추가 지연 시간을 유발한다. TLS 1.2 over TCP를 사용하여 연결을 설정하려면 2 RTT가 필요하다. TLS 1.3은 일부 상황에서 제로 RTT 연결 재개를 허용하지만, TCP 위에 계층화된 경우 TCP 핸드셰이크에 여전히 1 RTT가 필요하다. TCP Fast Open은 초기 패킷으로 데이터를 전송하여 연결 설정 중 1 RTT의 지연 시간을 제거할 수 있지만, 프로토콜 경화로 인해 배포가 어렵다.

TCP 처리량은 패킷 재정렬의 영향을 받는다. 재정렬된 패킷은 중복 확인 응답을 전송하게 하여 잘못된 재전송 및 혼잡 제어를 트리거할 수 있다. 선택적 확인 응답은 처리량에 상당한 이점을 제공할 수 있지만, TCP는 최대 세 개의 시퀀스 번호 블록만 선택적으로 확인할 수 있어 재전송 속도를 제한할 수 있다.

TCP는 원래 네트워크 혼잡을 패킷 손실의 원인으로 간주하고 혼잡 윈도우 크기를 줄이도록 설계되었지만, 무선 링크는 페이딩, 간섭 등으로 인해 일시적인 손실이 발생할 수 있다. 무선 패킷 손실로 인한 혼잡 윈도우 크기 감소는 무선 링크를 과소 사용하게 만들 수 있으며, 이를 방지하기 위한 연구가 진행 중이다. 제안된 솔루션은 클라이언트 또는 서버에서 수정을 필요로 하는 종단 간 솔루션, 무선 링크 프로토콜과 같은 링크 계층 솔루션, 또는 엔드 노드를 수정하지 않고 네트워크에서 일부 변경을 필요로 하는 프록시 기반 솔루션으로 분류할 수 있다.

참조

[1] 서적 Location-Based Information Systems Developing Real-Time Tracking Applications CRC Press
[2] 논문 A Protocol for Packet Network Intercommunication http://ece.ut.ac.ir/[...] 1974-05
[3] 웹사이트 Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate https://www.itif.org[...] Information Technology and Innovation Foundation 2017-09-11
[4] 학위논문 "'Industrial Legislatures': Consensus Standardization in the Second and Third Industrial Revolutions" http://jhir.library.[...] 2008
[5] 기타 Comments on Internet Protocol and TCP https://www.rfc-edit[...] 2016-06-11
[6] 웹사이트 Final Report of the Stanford University TCP Project https://www.rfc-edit[...] 1980-04-01
[7] 논문 The DoD internet architecture model 1983-10
[8] 웹사이트 The TCP/IP Guide – TCP/IP Architecture and the TCP/IP Model http://www.tcpipguid[...] 2020-02-11
[9] 웹사이트 Internet Experiment Note Index https://www.rfc-edit[...] 2024-01-21
[10] 웹사이트 Robert E Kahn – A.M. Turing Award Laureate https://amturing.acm[...] 2019-07-13
[11] 웹사이트 Vinton Cerf – A.M. Turing Award Laureate https://amturing.acm[...] 2019-07-13
[12] 서적 Internetworking with TCP/IP: Principles, Protocols, and Architecture Prentice Hall
[13] 웹사이트 Change RFC 3540 "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" to Historic https://datatracker.[...] 2023-04-18
[14] 웹사이트 Protection of BGP Sessions via the TCP MD5 Signature Option https://datatracker.[...] IETF 2023-12-30
[15] 웹사이트 Transmission Control Protocol (TCP) Parameters: TCP Option Kind Numbers https://www.iana.org[...] IANA 2017-10-19
[16] 서적 Computer networking : a top-down approach https://www.worldcat[...] 2017
[17] 서적 Computer Networks https://archive.org/[...] Prentice Hall 2003-03-17
[18] 논문 The macroscopic behavior of the TCP congestion avoidance algorithm
[19] 논문 An Overview of Packet Reordering in Transmission Control Protocol (TCP): Problems, Solutions, and Challenges https://ieeexplore.i[...] 2007
[20] 학위논문 Investigate reordering in Linux TCP http://urn.nb.no/URN[...] University of Oslo 2015
[21] 컨퍼런스 RACK: a time-based fast loss detection for TCP draft-cheng-tcpm-rack-00 https://www.ietf.org[...] IETF 2015
[22] 컨퍼런스 RACK: a time-based fast loss recovery draft-ietf-tcpm-rack-02 https://datatracker.[...] IETF 2017
[23] 컨퍼런스 Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication 2008-04-28
[24] 웹사이트 TCP window scaling and broken routers https://lwn.net/Arti[...] 2016-07-21
[25] 웹사이트 IP sysctl https://www.kernel.o[...] 2018-12-15
[26] 웹사이트 TCP timestamp is disabled https://web.archive.[...] Microsoft 2018-12-15
[27] 웹사이트 An Analysis of Changing Enterprise Network Traffic Characteristics http://profiles.murd[...] The 23rd Asia-Pacific Conference on Communications (APCC 2017) 2017-10-03
[28] 웹사이트 On the implementation of TCP urgent data http://www.gont.com.[...] 73rd IETF meeting 2009-01-04
[29] 서적 Computer Networks https://archive.org/[...] Morgan Kaufmann
[30] 서적 TCP/IP Illustrated. Vol. 1, The protocols https://archive.org/[...] Addison-Wesley 2011-11
[31] 웹사이트 Security Assessment of the Transmission Control Protocol (TCP) http://www.cpni.gov.[...] 2010-12-23
[32] 문서 Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations https://tools.ietf.o[...]
[33] 웹사이트 Quick Blind TCP Connection Spoofing with SYN Cookies http://www.jakoblell[...] 2014-02-05
[34] 웹사이트 Some insights about the recent TCP DoS (Denial of Service) vulnerabilities https://web.archive.[...] 2010-12-23
[35] 웹사이트 Exploiting TCP and the Persist Timer Infiniteness http://phrack.org/is[...] 2010-01-22
[36] 웹사이트 PUSH and ACK Flood https://f5.com/gloss[...] 2017-09-27
[37] 웹사이트 Simple Active Attack Against TCP https://www.usenix.o[...] 1995
[38] 간행물 2013 IEEE PES Innovative Smart Grid Technologies Conference (ISGT)
[39] 학술지 Improving datacenter performance and robustness with multipath TCP https://web.archive.[...] 2011-06-29
[40] 웹사이트 MultiPath TCP – Linux Kernel implementation http://www.multipath[...] 2013-03-24
[41] 학술지 How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP https://www.usenix.o[...] 2013-03-24
[42] 학술지 Multipath TCP Deployments https://www.ietfjour[...] 2017-01-03
[43] IETF Cryptographic Protection of TCP Streams (tcpcrypt) 2019-05
[44] 뉴스 TCP Fast Open: expediting web services https://lwn.net/Arti[...] LWN.net 2012-08-01
[45] 서적 High-performance browser networking O'Reilly 2013
[46] 웹사이트 TCP performance over CDMA2000 RLP https://web.archive.[...] 2010-08-30
[47] 서적 Fourth International Conference on Information Technology (ITNG'07)
[48] 웹사이트 TCP Acceleration https://web.archive.[...] 2024-04-18
[49] 웹사이트 An Analysis of AIMD Algorithm with Decreasing Increases http://udt.sourcefor[...] 2016-03-05
[50] 웹사이트 Wireshark: Offloading https://wiki.wiresha[...] 2017-02-24
[51] 웹사이트 Wireshark: Checksums https://www.wireshar[...] 2017-02-24
[52] IETF RFC Transmission Control Protocol (TCP) ... TCP provides a reliable, in-order, byte-stream service to applications. ... TCP is connection oriented
[53] 학술지 A Protocol for Packet Network Intercommunication http://ece.ut.ac.ir/[...] 1974-05
[54] IETF RFC TCP uses port numbers to identify application services and to multiplex distinct flows between hosts.
[55] IETF RFC The application byte-stream is conveyed over the network via TCP segments
[56] 서적 Internetworking with TCP/IP:Principles, Protocols, and Architecture Prentice Hall
[57] IETF RFC a TCP segment is the unit of data transferred between a pair of TCP modules.
[58] 웹사이트 TCP (Linktionary term) http://www.linktiona[...]
[59] 웹사이트 RFC 791 - section 2.1 https://datatracker.[...]
[60] IETF RFC
[61] IETF RFC
[62] 웹사이트 RFC 1323, TCP Extensions for High Performance, Section 2.2 https://datatracker.[...]
[63] 웹사이트 RFC 2018, TCP Selective Acknowledgement Options, Section 2 https://datatracker.[...]
[64] 웹사이트 RFC 2018, TCP Selective Acknowledgement Options, Section 3 https://datatracker.[...]
[65] 웹사이트 RFC 1323, TCP Extensions for High Performance, Section 3.2 https://datatracker.[...]
[66] 웹사이트 RFC 1146, TCP Alternate Checksum Options https://datatracker.[...]
[67] IETF RFC
[68] 웹사이트 TCP Definition http://www.linfo.org[...] 2011-03-12
[69] 학술지 When The CRC and TCP Checksum Disagree http://dl.acm.org/ci[...]
[70] IETF The TCP Maximum Segment Size and Related Topics Internet Engineering Task Force 1983-11
[71] 웹사이트 TCP window scaling and broken routers http://lwn.net/Artic[...]
[72] 웹사이트 On the implementation of TCP urgent data http://www.gont.com.[...] 73rd IETF meeting 2008-11
[73] 서적 Computer Networks Morgan Kaufmann
[74] 서적 TCP/IP Illustrated. Vol. 1, The protocols https://books.google[...] Addison-Wesley 2011-11-14
[75] 서적 Computer Networks Prentice Hall 2003-03-17
[76] 웹사이트 Security Assessment of the Transmission Control Protocol (TCP) http://www.cgisecuri[...]
[77] 웹사이트 Security Assessment of the Transmission Control Protocol (TCP) http://tools.ietf.or[...]
[78] 문서 Some insights about the recent TCP DoS (Denial of Service) vulnerabilities http://www.gont.com.[...]
[79] 웹사이트 Exploiting TCP and the Persist Timer Infiniteness http://phrack.org/is[...]
[80] 웹사이트 Simple Active Attack Against TCP http://www.usenix.or[...] 1995
[81] IETF RFC TRANSMISSION CONTROL PROTOCOL IETF RFC
[82] IETF RFC Glossary ... socket ... An address that specifically includes a port identifier, that is, the concatenation of an Internet Address with a TCP port. IETF RFC
[83] IETF RFC To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. IETF RFC
[84] IETF RFC To identify the separate data streams that a TCP may handle, the TCP provides a port identifier. IETF RFC
[85] IETF RFC Since a process may need to distinguish among several communication streams between itself and another process (or processes), we imagine that each process may have a number of ports through which it communicates with the ports of other processes. IETF RFC
[86] IETF RFC uniquely allocating a group of ports to a given process IETF RFC
[87] IETF RFC Glossary ... connection A logical communication path identified by a pair of sockets. IETF RFC
[88] 웹사이트 RFC 6182 Architectural Guidelines for Multipath TCP Development https://datatracker.[...]
[89] 웹사이트 RFC 8684 TCP Extensions for Multipath Operation with Multiple Addresses https://datatracker.[...]
[90] 웹사이트 TCP with feed-forward source coding for wireless downlink networks http://portal.acm.or[...]
[91] 간행물 Improving datacenter performance and robustness with multipath TCP http://inl.info.ucl.[...]
[92] 웹사이트 MultiPath TCP - Linux Kernel implementation http://mptcp.info.uc[...]
[93] 간행물 MultiPath TCP: From Theory to Practice http://inl.info.ucl.[...]
[94] 웹사이트 TCP performance over CDMA2000 RLP http://academic.rese[...] 2010-08-30
[95] 간행물 TCP Congestion Window Optimization for CDMA2000 Packet Data Networks http://www.computer.[...]
[96] 저널 A Protocol for Packet Network Intercommunication http://ece.ut.ac.ir/[...] 2013-08-20
[97] 웹인용 TCP (Linktionary term) http://www.linktiona[...] 2013-08-20
[98] 웹사이트 RFC 791 – section 2.1 http://tools.ietf.or[...]
[99] 문서 RFC 793
[100] 웹사이트 RFC 1323, TCP Extensions for High Performance, Section 2.2 http://tools.ietf.or[...]
[101] 웹사이트 RFC 2018, TCP Selective Acknowledgement Options, Section 2 http://tools.ietf.or[...]
[102] 웹사이트 RFC 2018, TCP Selective Acknowledgement Options, Section 3 http://tools.ietf.or[...]
[103] 웹사이트 RFC 1323, TCP Extensions for High Performance, Section 3.2 http://tools.ietf.or[...]
[104] 웹사이트 RFC 1146, TCP Alternate Checksum Options http://tools.ietf.or[...]
[105] 문서 RFC 793 section 3.1


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com