IMT2000 3GPP - 전송제어 프로토콜

IMT2000 3GPP - 전송제어 프로토콜

프로토콜 스택
약칭	TCP
개발자	빈트 서프와 밥 칸
서론	1974
에 기반을 둔	변속기 제어 프로그램
OSI 계층	전송 레이어(4)
RFC	RFC 9293

전송 제어 프로토콜(TCP)은 인터넷 프로토콜 제품군의 주요 프로토콜 중 하나입니다.그것은 인터넷 프로토콜(IP)을 보완하는 초기 네트워크 구현에서 비롯되었습니다.따라서, 전체 제품군을 일반적으로 TCP/IP라고 합니다. TCP는 IP 네트워크를 통해 통신하는 호스트에서 실행되는 애플리케이션 간에 옥텟 스트림(바이트)의 신뢰성 있고 순서가 있으며 오류가 확인된 전달을 제공합니다.월드 와이드 웹, 이메일, 원격 관리 및 파일 전송과 같은 주요 인터넷 응용 프로그램은 TCP/IP 제품군의 전송 계층의 일부인 TCP에 의존합니다.SSL/TLS는 종종 TCP 위에서 실행됩니다.

TCP는 연결 중심이며, 데이터를 전송하기 전에 클라이언트와 서버 간의 연결이 설정됩니다.연결이 설정되기 전에 서버는 클라이언트의 연결 요청을 수신(passive open)해야 합니다.3방향 핸드셰이크(액티브 오픈), 재전송 및 오류 탐지 기능은 신뢰성을 높이지만 지연 시간을 늘립니다.신뢰성 있는 데이터 스트림 서비스를 필요로 하지 않는 애플리케이션은 신뢰성보다 시간을 우선시하는 무연결 데이터그램 서비스를 대신 제공하는 UDP(User Datagram Protocol)를 사용할 수 있습니다.TCP는 네트워크 혼잡 방지 기능을 사용합니다.그러나 TCP에는 서비스 거부, 연결 하이재킹, TCP 거부권 및 재설정 공격을 포함한 취약성이 있습니다.

인터넷 프로토콜 모음
응용 계층
BGP DHCP(v6) DNS FTP HTTP(HTTP/3) HTTPS IMAP IRC LDAP MGCP MQTT NNTP NTP OSPF 팝 PTP ONC/RPC RTP RTSP RIP SIP SMTP SNMP SSH 텔넷 TLS/SSL XMPP 더...
수송층
TCP UDP DCCP SCTP RSVP QUIC 더...
인터넷 계층
IP v4 v6 ICMP (v6) NDP ECN IGMP IPsec 더...
링크 계층
ARP 터널 PPP 맥 더...
v t

역사적 기원

1974년 5월, Vint Cerf와 Bob Kahn은 네트워크 노드들 간에 패킷 스위칭을 이용하여 자원을 공유하기 위한 인터워킹 프로토콜을 설명하였습니다.^[1]저자들은 프랑스 CYCLADES 프로젝트의 개념을 새로운 네트워크에 통합하기 위해 제라르 르 란과 함께 작업해 왔습니다.^[2]그에 따른 규약의 명세, RFC675(Specification of Internet Transmission Control Program)는 Vint Cerf, Yogen Dalal 및 Carl Sunshine에 의해 작성되었으며 1974년 12월에 출판되었습니다.그것은 인터넷 네트워크의 축약어로서 인터넷이라는 용어를 처음으로 증명한 것을 포함합니다.^[3]

이 모델의 중심 제어 요소는 호스트 간의 연결 지향 링크와 데이터그램 서비스를 모두 통합한 전송 제어 프로그램이었습니다.모놀리식 전송 제어 프로그램은 이후 전송 제어 프로토콜과 인터넷 프로토콜로 구성된 모듈형 아키텍처로 분할되었습니다.이것은 공식적으로는 DOD(Department of Defense) 모델, ARPANET 모델, 그리고 궁극적으로는 Internet Protocol Suite라고 불리는 다양한 형태의 네트워킹 모델을 만들어 냈습니다.

2004년, Vint Cerf와 Bob Kahn은 TCP/IP에 대한 기초 작업으로 튜링 상을 받았습니다.^[4][5]

네트워크 기능

전송 제어 프로토콜은 응용 프로그램과 인터넷 프로토콜 사이의 중간 수준의 통신 서비스를 제공합니다.인터넷 모델의 전송 계층에서 호스트 간 연결을 제공합니다.애플리케이션은 전송 매체의 최대 전송 단위를 수용하기 위해 필요한 IP 단편화와 같이 다른 호스트로의 링크를 통해 데이터를 전송하기 위한 특정 메커니즘을 알 필요가 없습니다.전송 계층에서 TCP는 모든 핸드셰이크 및 전송 세부사항을 처리하고 일반적으로 네트워크 소켓 인터페이스를 통해 애플리케이션에 네트워크 연결의 추상화를 제공합니다.

프로토콜 스택의 하위 레벨에서는 네트워크 혼잡, 트래픽 로드 밸런싱 또는 예측할 수 없는 네트워크 동작으로 인해 IP 패킷이 손실되거나 중복되거나 순서에 맞지 않게 전달될 수 있습니다.TCP는 이러한 문제를 감지하고, 손실된 데이터의 재전송을 요청하며, 순서에 맞지 않는 데이터를 재배치하고, 네트워크 혼잡을 최소화하여 다른 문제의 발생을 줄입니다.데이터가 여전히 전송되지 않은 상태로 남아 있으면 소스에 이 오류가 발생했음을 알립니다.TCP 수신기가 원래 전송된 옥텟의 시퀀스를 다시 조립하면, 그것들을 수신 애플리케이션에 전달합니다.따라서 TCP는 기본 네트워킹 세부 정보에서 응용 프로그램의 통신을 추상화합니다.

TCP는 WWW(World Wide Web), 이메일, 파일 전송 프로토콜, Secure Shell, P2P 파일 공유 및 스트리밍 미디어를 포함한 많은 인터넷 응용 프로그램에서 광범위하게 사용됩니다.

TCP는 시기적절한 전달보다는 정확한 전달에 최적화되어 있으며, 순서가 맞지 않은 메시지를 기다리거나 잃어버린 메시지의 재전송을 기다리는 동안 (초 단위로) 상대적으로 긴 지연을 초래할 수 있습니다.따라서 음성 over IP와 같은 실시간 응용 프로그램에는 특별히 적합하지 않습니다.이러한 애플리케이션의 경우, UDP(User Datagram Protocol)를 통해 동작하는 실시간 전송 프로토콜(RTP)과 같은 프로토콜이 일반적으로 권장됩니다.^[6]

TCP는 신뢰할 수 있는 바이트 스트림 전달 서비스로, 수신된 모든 바이트가 동일하고 전송된 바이트와 동일한 순서로 제공됩니다.많은 네트워크에 의한 패킷 전송은 신뢰할 수 없기 때문에, TCP는 재전송과 함께 긍정적인 확인으로 알려진 기술을 사용하여 이를 달성합니다.이를 위해서는 수신기가 데이터를 수신할 때 확인 메시지로 응답해야 합니다.송신자는 송신한 각 패킷의 기록을 유지하고 패킷이 송신된 때부터 타이머를 유지합니다.확인 응답을 받기 전에 타이머가 만료되면 송신자는 패킷을 다시 전송합니다.패킷이 분실되거나 손상될 경우 타이머가 필요합니다.^[6]

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

TCP 세그먼트 구조

전송 제어 프로토콜은 데이터 스트림에서 데이터를 받아 청크로 분할하고 TCP 헤더를 추가하여 TCP 세그먼트를 만듭니다.그런 다음 TCP 세그먼트는 IP(Internet Protocol) 데이터그램으로 캡슐화되어 피어와 교환됩니다.^[7]

TCP 패킷이라는 용어는 비공식적인 사용과 공식적인 사용에서 나타나는 반면, 좀 더 정확한 용어 세그먼트는 TCP 프로토콜 데이터 유닛(PDU), 데이터그램은^{[8]: 5–6} IP PDU, 프레임은 데이터 링크 계층 PDU를 나타냅니다.

프로세스는 TCP를 호출하여 데이터의 버퍼를 인수로 전달함으로써 데이터를 전송합니다.TCP는 이러한 버퍼의 데이터를 세그먼트(segment)로 패키징하고 인터넷 모듈을 통해 호출합니다 [예:IP] 각 세그먼트를 대상 TCP로 전송합니다.^[9]

TCP 세그먼트는 세그먼트 헤더와 데이터 섹션으로 구성됩니다.세그먼트 헤더에는 10개의 필수 필드와 선택사항인 확장 필드(Options, pink background in table)가 포함됩니다.데이터 섹션은 헤더를 따르며 응용 프로그램에 대해 전송되는 페이로드 데이터입니다.세그먼트 헤더에는 데이터 구간의 길이가 지정되어 있지 않으며, IP 헤더에 지정되어 있는 총 IP 데이터그램 길이에서 세그먼트 헤더와 IP 헤더의 합계 길이를 빼서 계산할 수 있습니다.

TCP 세그먼트 헤더

간격띄우기		0								1								2								3
옥텟	조금	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
0	0	소스 포트																대상 포트
4	32	서열번호
8	64	승인번호(ACK이 설정된 경우)
12	96	데이터 오프셋				예약된 0 0 0 0				CWR	ECE	URG	ACK	PSH	RST	SYN	FIN	창 크기
16	128	체크섬																긴급 포인터(URG가 설정된 경우)
20	160	옵션 (데이터 오프셋이 > 5인 경우, 필요한 경우 "0" 비트로 끝에 패딩)
⋮	⋮
56	448

소스 포트(16비트)

송신 포트를 식별합니다.

대상 포트(16비트)

수신 포트를 식별합니다.

시퀀스 번호(32비트)

1인 2역:

• SYN 플래그가 (1)로 설정되어 있는 경우, 이는 초기 시퀀스 번호입니다.실제 첫 번째 데이터 바이트의 시퀀스 번호와 해당 ACK에서 승인된 번호는 이 시퀀스 번호에 1을 더한 값입니다.
• SYN 플래그가 설정되지 않은 경우(0), 이는 현재 세션에서 이 세그먼트의 첫 번째 데이터 바이트의 누적 시퀀스 번호입니다.

승인번호(32비트)

ACK 플래그가 설정되어 있으면 이 필드의 값은 ACK 송신자가 기대하는 다음 시퀀스 번호가 됩니다.이것은 모든 이전 바이트(있는 경우)의 수신을 승인합니다.각 엔드가 전송한 첫 번째 ACK는 다른 엔드의 첫 번째 시퀀스 번호 자체를 인식하지만 데이터는 없습니다.

데이터 오프셋(4비트)

TCP 헤더의 크기를 32비트 워드로 지정합니다.헤더의 최소 크기는 5단어이고 최대 크기는 15단어이므로 헤더에서 최대 40바이트의 옵션을 허용하는 최소 크기는 20바이트, 최대 크기는 60바이트입니다.이 필드의 이름은 TCP 세그먼트의 시작부터 실제 데이터까지의 간격띄우기라는 점에서 따온 것입니다.

예약(4비트)

나중에 사용할 수 있도록 0으로 설정해야 합니다.

2003-2017년, 마지막 비트(헤더의 비트 103)는 실험적 RFC 3540, ECN-nonce에 의해 NS(Nonce Sum) 플래그로 정의되었습니다.ECN 논스는 한번도 널리 사용되지 않았고 RFC는 Historic 상태로 변경되었습니다.^[10]

플래그(8비트)

다음과 같이 8개의 1비트 플래그(제어 비트)를 포함합니다.

• CWR(1비트):CWR(Congestion Window Reduced) 플래그는 송신 호스트가 ECE 플래그가 설정된 TCP 세그먼트를 수신하고 혼잡 제어 메커니즘에서 응답했음을 나타내기 위해 설정됩니다.^[a]
• ECE(1비트):ECN-Echo는 SYN 플래그의 값에 따라 이중 역할을 수행합니다.다음을 나타냅니다.

• SYN 플래그가 설정(1)된 경우, TCP 피어는 ECN이 가능합니다.
• SYN 플래그가 설정되지 않은 경우(0), IP 헤더에 혼잡 경험 플래그 세트(ECN=11)가 있는 패킷이 정상 전송 중에 수신되었습니다.이는 TCP 송신자에게 네트워크 혼잡(또는 임박한 혼잡)을 나타냅니다.

• URG(1비트):긴급 포인터 필드가 중요함을 나타냅니다.
• ACK(1비트):Acknowledgement 필드가 중요함을 나타냅니다.클라이언트가 보낸 초기 SYN 패킷 이후의 모든 패킷에는 이 플래그가 설정되어 있어야 합니다.
• PSH(1비트):푸시 기능.수신 애플리케이션에 버퍼링된 데이터를 푸시하도록 요청합니다.
• RST(1비트):연결 재설정
• SYN(1비트):시퀀스 번호를 동기화합니다.각 끝에서 보낸 첫 번째 패킷에만 이 플래그가 설정되어 있어야 합니다.일부 다른 플래그와 필드는 이 플래그를 기반으로 의미가 변경되며, 일부 플래그는 설정된 경우에만 유효하며, 다른 플래그는 명확한 경우에만 유효합니다.
• FIN(1비트):보낸 사람의 마지막 패킷

창 크기(16비트)

수신 창의 크기 - 이 세그먼트의 보낸 사람이 현재 수신하려는 윈도우 크기 단위의 수를 지정합니다( § Flow control 및 § 윈도우 스케일링 참조).

체크섬(16비트)

16비트 체크섬 필드는 TCP 헤더, 페이로드 및 IP 의사 헤더의 오류 검사에 사용됩니다.의사 헤더는 소스 IP 주소, 대상 IP 주소, TCP 프로토콜의 프로토콜 번호(6), TCP 헤더 및 페이로드 길이(바이트 단위)로 구성됩니다.

긴급 포인터(16비트)

URG 플래그가 설정된 경우, 이 16비트 필드는 마지막 긴급 데이터 바이트를 나타내는 시퀀스 번호에서 오프셋됩니다.

옵션 (변수 0–320비트, 32비트 단위)

이 필드의 길이는 데이터 오프셋 필드에 의해 결정됩니다.옵션에는 최대 세 개의 필드가 있습니다.Optional-Kind(1바이트), Optional-Length(1바이트), Optional-Data(변수).Option-Kind 필드는 옵션 유형을 나타내며 옵션이 아닌 유일한 필드입니다.Option-Kind 값에 따라 다음 두 필드를 설정할 수 있습니다.Option-Length는 옵션의 총 길이를 나타내고 Option-Data는 해당되는 경우 옵션과 관련된 데이터를 포함합니다.예를 들어 Option-Kind 바이트가 1이면 패딩에만 사용되는 no operation 옵션이며 Option-Length 또는 Option-Data 필드가 뒤따르지 않음을 나타냅니다.Option-Kind 바이트가 0이면 옵션의 끝을 표시하며 1바이트만 됩니다.Option-Kind 바이트 2는 Maximum Segment Size(최대 세그먼트 크기) 옵션을 나타내는 데 사용되며, 그 다음에 Option-Length 바이트가 MSS 필드의 길이를 지정합니다.Option-Length는 Option-Kind 및 Option-Length 필드를 포함하여 지정된 옵션 필드의 총 길이입니다.따라서 MSS 값은 일반적으로 2바이트로 표시되지만 Option-Length는 4가 됩니다.예를 들어, 값이 0x05B4인 MSS 옵션 필드는 TCP 옵션 섹션에서 (0x02 0x04 0x05B4)로 코딩됩니다.

일부 옵션은 SYN이 설정된 경우에만 전송할 수 있으며, 아래에 .Option-Kind 및 표준 길이(Option-Kind, Option-Length)로 표시됩니다.

옵션-카인드	옵션-길이	옵션-데이터	목적	메모들
0	—	—	옵션 목록의 끝
1	—	—	작업없음	이를 통해 옵션 필드를 32비트 경계에 정렬하여 성능을 향상시킬 수 있습니다.
2	4	SS	최대 세그먼트 크기	자세한 내용은 § 최대 세그먼트 크기를 참조하십시오.
3	3	S	창저울	자세한 내용은 § 창 크기 조정을 참조하십시오.
4	2	—	선택적 승인 허용	자세한 내용은 § 선택적 승인을 참조하십시오.
5	N(10,18,26 또는34)	BBB, EEE, ...	선택적 ACK 확인(SACK)[12]: §3	처음 두 바이트 뒤에 32비트 시작/종료 포인터로 지정된 선택적으로 승인되는 1-4개 블록 목록이 이어집니다.
8	10	TTT, EEE	이전 타임스탬프의 타임스탬프 및 에코	자세한 내용은 § TCP 타임스탬프를 참조하십시오.

나머지 Option-Kind 값은 과거 값, 오래된 값, 실험 값, 아직 표준화되지 않은 값 또는 할당되지 않은 값입니다.옵션 번호 할당은 IANA에 의해 유지 관리됩니다.^[13]

패딩

TCP 헤더 패딩은 TCP 헤더가 종료되고 데이터가 32비트 경계에서 시작되도록 하는 데 사용됩니다.패딩은 0으로 구성되어 있습니다.^[9]

프로토콜운영

TCP 프로토콜 동작은 세 단계로 나눌 수 있습니다.연결 설정은 데이터 전송 단계에 들어가기 전에 연결을 설정하는 다단계 핸드셰이크 과정입니다.데이터 전송이 완료되면 연결 종료는 연결을 종료하고 할당된 모든 리소스를 해제합니다.

TCP 연결은 통신을 위한 로컬 엔드포인트인 인터넷 소켓을 나타내는 리소스를 통해 운영 체제에 의해 관리됩니다.TCP 연결 수명 동안 로컬 엔드포인트는 일련의 상태 변경을 겪습니다.^[14]

TCP 소켓 상태

주	엔드포인트	묘사
들어봐	서버	원격 TCP 끝점에서 연결 요청을 기다리는 중입니다.
SYN-SENT	고객	연결 요청을 보낸 후 일치하는 연결 요청을 기다리는 중입니다.
SYN 수신됨	서버	연결 요청을 수신 및 전송한 후 연결 요청 확인을 기다리는 중입니다.
설립된	서버 및 클라이언트	개방형 연결, 수신된 데이터를 사용자에게 전달할 수 있습니다.연결의 데이터 전송 단계에 대한 정상 상태.
FIN-WAIT-1	서버 및 클라이언트	원격 TCP로부터의 연결 종료 요청 또는 이전에 보낸 연결 종료 요청의 승인을 기다리는 중입니다.
FIN-WAIT-2	서버 및 클라이언트	원격 TCP에서 연결 종료 요청을 기다리는 중입니다.
클로즈-웨이트	서버 및 클라이언트	로컬 사용자의 연결 종료 요청을 기다리는 중입니다.
클로징	서버 및 클라이언트	원격 TCP에서 연결 종료 요청 승인을 기다리는 중입니다.
마지막 ACK	서버 및 클라이언트	원격 TCP에 이전에 전송된 연결 종료 요청의 확인을 기다리는 중입니다(연결 종료 요청의 확인을 포함함).
시간-기다림	서버 또는 클라이언트	연결에 남아 있는 모든 패킷이 만료되었는지 확인하기 위해 충분한 시간을 기다리는 중입니다.
닫힘	서버 및 클라이언트	연결 상태가 전혀 없습니다.

연결설정

클라이언트가 서버와 연결을 시도하기 전에 서버는 먼저 포트에 바인딩하여 포트를 열어 연결을 수신해야 합니다. 이를 수동적 개방이라고 합니다.패시브 오픈이 설정되면 클라이언트는 3방향(또는 3단계) 핸드셰이크를 사용하여 액티브 오픈을 시작함으로써 연결을 설정할 수 있습니다.

1. SYN: 활성 오픈은 클라이언트가 SYN을 서버로 전송하여 수행됩니다.클라이언트는 세그먼트의 시퀀스 번호를 랜덤값 A로 설정합니다.
2. SYN-ACK: 이에 응답하여 서버는 SYN-ACK으로 응답합니다.승인 번호는 수신된 시퀀스 번호보다 하나 더 많이 설정됩니다.A+1이고, 서버가 패킷을 위해 선택하는 시퀀스 번호는 또 다른 난수인 B.
3. ACK: 마지막으로 클라이언트는 서버로 ACK를 다시 보냅니다.시퀀스 번호는 수신된 승인 값으로 설정됩니다.A+1이며, 수신된 시퀀스 번호, 즉 B+1보다 하나 더 많은 수신 확인 번호가 설정됩니다.

1단계와 2단계는 한 방향(클라이언트에서 서버로)에 대한 시퀀스 번호를 설정하고 확인합니다.2단계와 3단계는 다른 방향(서버에서 클라이언트로)에 대한 시퀀스 번호를 설정하고 확인합니다.이러한 단계가 완료되면 클라이언트와 서버 모두 확인 응답을 받고 전이중 통신이 성립됩니다.

접속종료

연결 종료 단계는 연결의 각 면이 독립적으로 종료되는 4방향 핸드셰이크를 사용합니다.엔드포인트가 자신의 절반 연결을 중지하고자 할 때, 그것은 FIN 패킷을 전송하고, 다른 끝은 ACK로 이를 승인합니다.따라서 일반적인 해체에는 각 TCP 끝점에서 한 쌍의 FIN 및 ACK 세그먼트가 필요합니다.첫 번째 FIN을 보낸 측이 최종 ACK로 응답한 후, 최종적으로 연결을 닫기 전에 시간 초과를 기다립니다. 이 시간 동안 로컬 포트를 새로운 연결에 사용할 수 없습니다. 이 상태를 통해 TCP 클라이언트는 전송 중 ACK가 손실된 경우 최종 확인을 서버에 다시 전송할 수 있습니다.시간은 구현에 따라 다르지만 일부 일반적인 값은 30초, 1분 및 2분입니다.시간 초과 후 클라이언트는 CLOSED 상태로 들어가고 로컬 포트는 새로운 연결에 사용할 수 있게 됩니다.^[15]

호스트 A가 FIN을 전송하고 호스트 B가 FIN & ACK(두 단계를 하나로 결합)로 응답하고 호스트 A가 ACK로 응답하는 3-way 핸드셰이크에 의해 연결을 종료할 수도 있습니다.^[16]

Linux 및 HP-UX와 같은 일부 운영 체제는 반이중 근접 시퀀스를 구현합니다.^{[citation needed]}읽지 않은 수신 데이터를 사용할 수 있는 상태에서 호스트가 연결을 적극적으로 닫는 경우 호스트는 FIN 대신 RST(수신 데이터 손실) 신호를 보냅니다.이렇게 하면 TCP 응용 프로그램이 데이터 손실이 있었음을 알 수 있습니다.^[17]

연결이 반열린 상태일 수 있으며, 이 경우 한쪽은 연결을 종료했지만 다른 쪽은 종료하지 않았습니다.종료된 쪽은 더 이상 데이터를 연결로 보낼 수 없지만 다른 쪽은 전송할 수 있습니다.터미네이션 측은 다른 쪽도 터미네이션할 때까지 데이터를 계속해서 데이터를 읽습니다.^{[citation needed]}

자원사용량

대부분의 구현은 실행 중인 운영 체제 프로세스에 세션을 매핑하는 테이블의 항목을 할당합니다.TCP 패킷에는 세션 식별자가 없기 때문에 두 엔드포인트 모두 클라이언트의 주소와 포트를 사용하여 세션을 식별합니다.패킷이 수신될 때마다 TCP 구현은 대상 프로세스를 찾기 위해 이 테이블에 대한 조회를 수행해야 합니다.표의 각 항목은 TCB(Transmission Control Block) 또는 TCB(Transmission Control Block)여기에는 엔드포인트(IP 및 포트), 연결 상태, 교환 중인 패킷에 대한 실행 데이터 및 데이터 송수신을 위한 버퍼에 대한 정보가 포함됩니다.

서버 측의 세션 수는 메모리에 의해서만 제한되며 새 연결이 도착함에 따라 증가할 수 있지만 클라이언트는 첫 번째 SYN을 서버에 전송하기 전에 사용 후 삭제 포트를 할당해야 합니다.이 포트는 전체 대화 중에도 할당된 상태로 유지되며 클라이언트의 각 IP 주소에서 발신되는 연결 수를 효과적으로 제한합니다.응용프로그램이 불필요한 연결을 제대로 닫지 못하면 클라이언트는 리소스가 부족해지고 다른 응용프로그램에서라도 새 TCP 연결을 설정할 수 없게 됩니다.

두 엔드포인트 모두 승인되지 않은 패킷과 수신된(읽지 않은) 데이터를 위한 공간도 할당해야 합니다.

데이터전송

전송 제어 프로토콜은 사용자 데이터그램 프로토콜과 비교하여 몇 가지 주요 기능이 다릅니다.

• 순서 데이터 전송: 대상 호스트가 시퀀스 번호에^[6] 따라 세그먼트를 재정렬합니다.
• 손실된 패킷의 재전송: 인식되지 않은 누적 스트림이 재전송됩니다^[6].
• 무오류 데이터 전송: 손상된 패킷은 손실된 것으로 처리되어 재전송됩니다^[18].
• Flow control: 신뢰성 있는 전달을 보장하기 위해 송신자가 데이터를 전송하는 속도를 제한합니다.수신기는 송신자에게 얼마나 많은 데이터를 수신할 수 있는지를 지속적으로 알려줍니다.수신 호스트의 버퍼가 채워지면 다음 확인 응답은 전송을 일시 중단하고 버퍼의 데이터를 처리할 수 있습니다.^[6]
• 혼잡 제어(Congestion Control): 패킷 손실(Congestion로 인해 추정됨)은 데이터 전달률^[6] 감소를 유발합니다.

신뢰성있는 변속기

TCP는 시퀀스 번호를 사용하여 데이터의 각 바이트를 식별합니다.시퀀스 번호는 데이터가 순서대로 재구성될 수 있도록 각 컴퓨터에서 전송된 바이트의 순서를 나타냅니다.첫 번째 바이트의 시퀀스 번호는 SYN으로 플래그가 지정된 첫 번째 패킷에 대해 송신기에 의해 선택됩니다.이 숫자는 임의적일 수 있으며, 실제로 TCP 시퀀스 예측 공격을 방어하기 위해 예측할 수 없는 숫자여야 합니다.

승인(ACK)은 데이터 수신자가 지정된 바이트로 데이터가 수신되었음을 송신자에게 알리기 위해 시퀀스 번호와 함께 전송됩니다.ACK는 데이터가 애플리케이션에 전달되었다는 것을 의미하는 것이 아니라, 이제 데이터를 전달하는 것이 수신자의 책임이라는 것을 의미할 뿐입니다.

신뢰성은 송신자가 손실된 데이터를 감지하고 재전송함으로써 달성됩니다.TCP는 손실을 식별하기 위해 두 가지 주요 기법을 사용합니다.RTO(Retransmission Timeout) 및 중복 누적 승인(DupAccks).

TCP 세그먼트가 재전송될 때 원래 전송 시도와 동일한 시퀀스 번호를 유지합니다.이러한 전달과 논리적 데이터 순서의 결합은 재전송 후에 승인이 수신될 때 송신자가 원래 전송인지 재전송인지 여부를 알 수 없다는 것을 의미합니다. 이른바 재전송 모호성.^[19]TCP는 재전송 모호성으로 인해 복잡성을 야기합니다.^[20]

듀팩 기반 재전송

스트림에서 단일 세그먼트(예를 들어 세그먼트 번호 100)가 손실된 경우 수신기는 누적 ACK를 사용하므로 해당 세그먼트 번호(100) 이상의 패킷을 확인할 수 없습니다.따라서 수신기는 다른 데이터 패킷의 수신시에 패킷 99를 다시 확인합니다.이 중복 확인은 패킷 손실에 대한 신호로 사용됩니다.즉, 송신자가 세 번의 중복 승인을 받은 경우, 마지막으로 승인되지 않은 패킷을 재전송합니다.네트워크가 중복 승인을 야기하는 세그먼트의 순서를 바꿀 수 있기 때문에 임계값이 3으로 사용됩니다.이 임계값은 순서 변경으로 인한 허위 재전송을 방지하는 것으로 입증되었습니다.^[21]일부 TCP 구현에서는 수신된 세그먼트에 대한 명시적인 피드백을 제공하기 위해 선택적 승인(SACK)을 사용합니다.이렇게 하면 올바른 세그먼트를 재전송하는 TCP의 기능이 크게 향상됩니다.

재전송 모호성은 중복 승인 임계값을 초과하는 순서 변경이 있는 경우 가짜 빠른 재전송 및 혼잡 회피를 유발할 수 있습니다.^[22]

타임아웃 기반 재전송

발신자가 세그먼트를 전송할 때 수신 확인의 도달 시간에 대한 보수적인 추정치로 타이머를 초기화합니다.타이머가 만료되면 세그먼트가 재전송되며, 이전 값의 두 배의 새 시간 초과 임계값으로 인해 지수 백오프 동작이 발생합니다.일반적으로 초기 타이머 값은 ${\displaystyle \text{평활화 RTT}}$+ ${\displaystyle max}$ ${\displaystyle (G,}$ ${\displaystyle 4}$ ×${\displaystyle \text{RTT 변동})}$ ${\displaystyle {\text{smoothed RTT$}} $+\max (G,4\times {\text})$$RTT variation})}.$여기서 $G{\displaystyle }$ ${\displaystyle G}$은(는) 시계 세분화입니다.^{[23]: 2} 이렇게 하면 중간자 서비스 거부 공격자와 같이 오류가 있거나 악의적인 행위자로 인한 과도한 전송 트래픽을 방지할 수 있습니다.

정확한 RTT 추정치는 송신자가 충분한 시간이 경과한 후(즉, RTO 시간 결정)에 손실될 승인되지 않은 패킷을 가정할 수 있기 때문에 손실 복구를 위해 중요합니다.^[24]재전송 모호성은 송신자의 RTT 추정치를 부정확하게 만들 수 있습니다.^[24]가변적인 RTT가 있는 환경에서는 허위 타임아웃이 발생할 수 있습니다.^[25] RTT가 과소 추정되면 RTO가 발생하여 불필요한 재전송 및 느린 시작을 트리거합니다.허위재송신 후 원본송신에 대한 확인서가 도착하면 송신자는 재송신을 인정하는 것으로 믿고 원본송신과 재송신 사이에 송신된 분절이 상실되었다고 잘못 판단할 수 있으므로,링크가 정말로 혼잡해질 정도로 불필요한 재전송을 더 야기합니다.^[26][27] 선택적 승인은 이러한 효과를 줄일 수 있습니다.^[28]RFC 6298은 RTT를 추정할 때, 재전송된 세그먼트들을 사용해서는 안 된다고 명시하고 있습니다.[29] Karn의 알고리즘은 RTO를 조정하기 전에 명확한 승인이 있을 때까지 대기함으로써, 결국 좋은 RTT 추정치가 생성될 것을 보장합니다.^[30]그러나 허위 재전송 후에는 이러한 명확하지 않은 확인이 도달하기까지 상당한 시간이 소요되어 그 동안 성능이 저하될 수 있습니다.^[31]TCP 타임스탬프는 또한 RTO를 설정할 때 재전송 모호성 문제를 해결하지만,^[29] 반드시 RTT 추정치를 개선하는 것은 아닙니다.^[32]

오류감지

시퀀스 번호를 사용하면 수신기에서 중복 패킷을 삭제하고 순서가 맞지 않은 패킷을 적절히 시퀀스할 수 있습니다.승인을 통해 보낸 사람은 손실된 패킷을 재전송할 시기를 결정할 수 있습니다.

정확성을 보장하려면 체크섬 필드가 포함되어 있습니다. 자세한 내용은 § 체크섬 계산을 참조하십시오.TCP 체크섬은 현대 표준의 약한 체크섬이며 일반적으로 PPP나 이더넷 프레임에서 사용되는 것과 같이 TCP와 IP 아래의 계층 2에서 CRC 무결성 체크와 쌍을 이룹니다.그러나 CRC로 보호된 홉 사이에 패킷에 오류가 도입되는 것은 일반적이며 16비트 TCP 체크섬이 이러한 대부분을 차지합니다.^[33]

유량조절

TCP는 송신자가 TCP 수신자가 신뢰성 있게 데이터를 수신하고 처리하기 위해 너무 빨리 데이터를 전송하지 않도록 종단간 흐름 제어 프로토콜을 사용합니다.다양한 네트워크 속도의 기계들이 통신하는 환경에서 흐름 제어를 위한 메커니즘을 갖는 것은 필수적입니다.예를 들어, PC가 수신된 데이터를 천천히 처리하는 스마트폰으로 데이터를 보낸다면, 스마트폰은 데이터 흐름을 압도당하지 않도록 조절할 수 있어야 합니다.^[6]

TCP는 슬라이딩 윈도우 플로우 제어 프로토콜을 사용합니다.각 TCP 세그먼트에서 수신기는 연결을 위해 버퍼링할 추가 수신 데이터의 양(바이트 단위)을 수신 창 필드에 지정합니다.송신 호스트는 승인을 기다리고 수신 호스트로부터 윈도우 업데이트를 수신해야 하기 전에 그 정도의 데이터만 보낼 수 있습니다.

수신기가 윈도우 크기 0을 광고하면 송신기는 데이터 전송을 중지하고 지속 타이머를 시작합니다.지속 타이머는 수신기에서 후속 윈도우 크기 업데이트가 손실될 경우 발생할 수 있는 교착 상태로부터 TCP를 보호하는 데 사용되며, 송신기는 수신기에서 새로운 윈도우 크기 업데이트를 받기 전까지 더 많은 데이터를 보낼 수 없습니다.지속 타이머가 만료되면 TCP 송신자는 작은 패킷을 전송하여 복구를 시도하여 수신자가 새 창 크기를 포함하는 다른 확인을 전송함으로써 응답합니다.

수신기가 수신 데이터를 조금씩 처리하는 경우 작은 수신 창을 반복적으로 알릴 수 있습니다.TCP 헤더의 오버헤드가 상대적으로 크기 때문에 TCP 세그먼트에서 몇 바이트의 데이터만 전송하는 것은 비효율적이기 때문에 이를 우스꽝스러운 윈도우 신드롬이라고 합니다.

혼잡제어

TCP의 마지막 주요 측면은 혼잡 제어입니다.TCP는 높은 성능을 달성하고 네트워크 성능이 심각하게 저하되는 정체 상황인 혼잡 붕괴를 방지하기 위해 여러 가지 메커니즘을 사용합니다.이러한 메커니즘은 데이터가 네트워크에 들어오는 속도를 제어하여 데이터 흐름을 붕괴를 유발할 수 있는 속도 이하로 유지합니다.또한 흐름 간에 대략 최대 분의 공정한 할당을 산출합니다.

전송된 데이터에 대한 확인 응답 또는 확인 응답의 부족은 TCP 송신자와 수신자 간의 네트워크 상태를 추론하는 데 사용됩니다.타이머와 함께 TCP 송신기 및 수신기는 데이터 흐름의 동작을 변경할 수 있습니다.이를 혼잡 제어 또는 혼잡 회피라고 더 일반적으로 말합니다.

TCP의 최신 구현에는 느린 시작, 혼잡 방지, 빠른 재전송 및 빠른 복구라는 네 가지 서로 얽혀 있는 알고리즘이 포함되어 있습니다.^[34]

또한, 송신자는 송신자와 수신자 사이의 예상 왕복 시간(RTT) 및 이 왕복 시간의 변화에 기초한 재전송 시간(RTO)을 사용합니다.^[23]RTT의 추정에는 미묘한 부분이 있습니다.예를 들어, 재전송된 패킷에 대한 RTT 샘플을 계산할 때 송신자는 주의해야 합니다. 일반적으로 Karn's Algorithm 또는 TCP 타임스탬프를 사용합니다.^[11]그런 다음 Jacobson의 알고리즘을 사용하여 매끄러운 왕복 시간(SRTT)을 만들기 위해 이러한 개별 RTT 샘플을 시간에 따라 평균화합니다.이 SRTT 값은 왕복 시간 추정치로 사용됩니다.

매우 빠른 환경에서 손실을 안정적으로 처리하고 오류를 최소화하며 혼잡을 관리하고 신속하게 처리할 수 있도록 TCP를 강화하는 것은 지속적인 연구 및 표준 개발 분야입니다.이로 인해 TCP 혼잡 회피 알고리즘은 다양한 변형이 발생합니다.

최대 세그먼트 크기

MSS(Maximum Segment Size)는 TCP가 단일 세그먼트에서 수신하고자 하는 최대 데이터 양(바이트 단위)입니다.최상의 성능을 위해 MSS는 패킷 손실과 과도한 재전송으로 이어질 수 있는 IP 단편화를 피할 수 있도록 충분히 작게 설정되어야 합니다.이를 위해 일반적으로 MSS는 TCP 연결이 설정될 때 MSS 옵션을 사용하여 각 측에서 공지합니다.옵션 값은 송신자와 수신자가 직접 연결된 네트워크의 데이터 링크 계층의 MTU(Maximum Transmission Unit) 크기에서 도출됩니다.TCP 송신자는 경로 MTU 검색을 사용하여 송신자와 수신자 사이의 네트워크 경로를 따라 최소 MTU를 추론하고, 이를 사용하여 MSS를 동적으로 조정하여 네트워크 내의 IP 단편화를 방지할 수 있습니다.

MSS 발표는 MSS 협상이라고도 할 수 있지만 엄밀하게 말하면 MSS는 협상되지 않습니다.TCP 연결에서 데이터 흐름의 두 방향에 대해 완전히 독립된 두 개의 MSS 값이 허용되므로 양방향 연결을 위한 공통 MSS 구성을 합의할 필요가 없습니다.^[35][9]

선택적 승인

원래 TCP에서 사용하는 누적 확인 방식에만 전적으로 의존하면 패킷이 손실될 때 비효율성이 발생할 수 있습니다.예를 들어, 시퀀스 번호가 1,000 ~ 10,999인 바이트가 동일한 크기의 10개의 서로 다른 TCP 세그먼트로 전송되고 두 번째 세그먼트(시퀀스 번호 2,000 ~ 2,999)가 전송되는 동안 손실된다고 가정합니다.순수 누적 확인 프로토콜에서 수신기는 누적 ACK 값 2,000(수신 데이터의 마지막 시퀀스 번호 직후 시퀀스 번호)만 전송할 수 있고 바이트 3,000~10,999를 성공적으로 수신했다고 말할 수 없습니다.따라서 송신자는 시퀀스 번호 2,000으로 시작하는 모든 데이터를 다시 전송해야 할 수도 있습니다.

이러한 문제를 완화하기 위해 TCP는 RFC 2018에서 1996년에 정의된 선택적 확인(SACK) 옵션을 사용하여 수신자가 정확하게 수신된 패킷의 불연속 블록을 확인할 수 있으며, 연속적으로 수신된 마지막 연속 바이트의 마지막 시퀀스 번호 바로 뒤에 오는 시퀀스 번호뿐만 아니라,기본 TCP 승인에서와 같이.확인 응답에는 다수의 SACK 블록이 포함될 수 있으며, 여기서 각 SACK 블록은 블록의 왼쪽 에지(블록의 첫 번째 시퀀스 번호) 및 오른쪽 에지(블록의 마지막 시퀀스 번호 바로 뒤에 오는 시퀀스 번호)에 의해 전달되며, 블록은 수신기가 올바르게 수신한 연속 범위입니다.위의 예에서 수신기는 누적 ACK 값이 2,000인 ACK 세그먼트와 시퀀스 번호가 3,000 및 11,000인 SACK 옵션 헤더를 전송합니다.따라서 송신자는 시퀀스 번호가 2,000에서 2,999인 두 번째 세그먼트만 재전송합니다.

TCP 송신자는 순서가 맞지 않는 세그먼트 배달을 유실된 세그먼트로 해석할 수 있습니다.그러면 TCP 송신자는 순서가 맞지 않는 패킷 이전의 세그먼트를 재전송하고 해당 연결에 대한 데이터 전달 속도를 늦춥니다.RFC 2883에서 2000년 5월에 정의된 SACK 옵션의 확장인 dupply-SACK 옵션이 이 문제를 해결합니다.TCP 수신기는 세그먼트가 손실되지 않았음을 나타내기 위해 D-ACK을 전송하고, 그러면 TCP 송신기는 더 높은 전송률을 복원할 수 있습니다.

SACK 옵션은 필수 사항은 아니며, 양쪽이 모두 지원하는 경우에만 적용됩니다.이는 연결이 설정될 때 협상됩니다.SAK는 TCP 헤더 옵션을 사용합니다(자세한 내용은 § TCP 세그먼트 구조 참조).SACK의 사용은 널리 퍼졌습니다. 인기 있는 모든 TCP 스택이 이를 지원합니다.선택적 승인은 스트림 제어 전송 프로토콜(SCTP)에서도 사용됩니다.

선택적 승인은 '갱신'될 수 있는데, 여기서 수신자는 선택적으로 승인된 데이터를 일방적으로 폐기합니다.RFC 2018은 이러한 동작을 방지했지만, 수신기가 버퍼 공간이 부족한 경우 다시 실행하는 옵션을 허용하는 것을 금지하지는 않았습니다.^[36]갱신 가능성은 송신자와 수신자 모두에게 구현의 복잡성을 초래하며, 또한 송신자에게 메모리 비용을 부과합니다.^[37]

윈도우 스케일링

고대역폭 네트워크를 보다 효율적으로 사용하기 위해, 더 큰 TCP 창 크기를 사용할 수 있습니다.16비트 TCP 창 크기 필드는 데이터의 흐름을 제어하며 값은 65,535바이트로 제한됩니다.크기 필드를 이 한계를 초과하여 확장할 수 없으므로 스케일링 인자가 사용됩니다.RFC 1323에 정의된 TCP 윈도우 스케일 옵션은 최대 윈도우 크기를 1기가바이트로 늘리기 위해 사용되는 옵션입니다.TCP 조정을 위해서는 이렇게 큰 창 크기까지 확장해야 합니다.

창 스케일 옵션은 TCP 3-way 핸드셰이크 중에만 사용됩니다.윈도우 스케일 값은 16비트 윈도우 크기 필드를 해석할 때 왼쪽 시프트할 비트 수를 나타냅니다.윈도우 스케일 값은 각 방향에 대해 독립적으로 0(시프트 없음)부터 14까지 설정할 수 있습니다.양쪽 모두 SYN 세그먼트에서 옵션을 전송하여 어느 방향으로든 윈도우 스케일링을 활성화해야 합니다.

일부 라우터와 패킷 방화벽은 전송 중에 윈도우 스케일링 인자를 다시 씁니다.이로 인해 송신 측과 수신 측이 서로 다른 TCP 창 크기를 가정하게 됩니다.결과적으로 매우 느릴 수 있는 불안정한 트래픽이 발생합니다.문제는 결함이 있는 라우터 뒤의 일부 사이트에서 볼 수 있습니다.^[38]

TCP 타임스탬프

1992년 RFC 1323에 정의된 TCP 타임스탬프는 TCP가 어떤 순서로 패킷이 전송되었는지 결정하는 데 도움이 됩니다.TCP 타임스탬프는 일반적으로 시스템 클럭에 정렬되지 않으며 임의의 값으로 시작합니다.많은 운영 체제가 경과된 밀리초마다 타임스탬프를 증가시키지만, RFC는 틱이 비례해야 한다고만 명시하고 있습니다.

타임스탬프 필드에는 두 가지가 있습니다.

• 4바이트 보낸 사람 타임스탬프 값(나의 타임스탬프)
• 4바이트 에코 응답 타임스탬프 값(사용자로부터 받은 가장 최근의 타임스탬프).

TCP 타임스탬프는 Protection Against Wraped Sequence number 또는 PAWS로 알려진 알고리즘에 사용됩니다. PAWS는 수신 창이 시퀀스 번호 랩어라운드 경계를 넘을 때 사용됩니다.패킷이 재전송될 가능성이 있는 경우, "이 시퀀스 번호는 처음 4GB입니까, 아니면 두 번째입니까?"라는 질문에 답합니다.그리고 타임스탬프는 동점을 깨는데 사용됩니다.

또한 Eifel 탐지 알고리즘은 TCP 타임스탬프를 사용하여 패킷이 손실되었거나 단순히 정상적이지 않아 재전송이 발생하는지 여부를 판단합니다.^[39]

TCP 타임스탬프는 리눅스에서 기본적으로 실행되고 ^[40]윈도우즈 서버 2008, 2012 및 2016에서는 기본적으로 실행 중지됩니다.^[41]

최근 통계에 따르면 윈도우즈 서버 2008 이후 윈도우즈 서버의 지원 감소로 인해 TCP 타임스탬프 채택 수준이 ~40%로 정체되었습니다.^[42]

대역외 데이터

스트림이 완료되기를 기다리는 대신 대기 중인 스트림을 중단하거나 중단할 수 있습니다.이 작업은 데이터를 긴급한 것으로 지정하여 수행합니다.이는 전송을 OOB(Out-of-Band Data)로 표시하고 수신 프로그램에 즉시 처리하도록 지시합니다.완료되면 TCP는 응용 프로그램에 알려주고 스트림 큐를 재개합니다.예를 들어, 사용자가 원격 로그인 세션에 TCP를 사용할 경우, 프로그램이 현재 전송을 완료할 때까지 기다리지 않고 원격으로 실행되는 프로그램을 중단하거나 중단하는 키보드 시퀀스를 보낼 수 있습니다.^[6]

긴급 포인터는 원격 호스트의 처리만 변경할 뿐 네트워크 자체의 처리를 신속하게 처리하지는 않습니다.이 기능은 시스템마다 다르게 구현되거나 제대로 구현되지 않거나 지원되지 않을 수도 있습니다.사용 가능한 경우 OOB 데이터의 단일 바이트만 안정적으로 처리된다고 가정하는 것이 좋습니다.^[43][44]이 기능은 자주 사용되지 않기 때문에 일부 플랫폼에서 잘 테스트되지 않았으며 취약성(예: WinNuke)과 관련이 있습니다.

데이터 전송 강제화

일반적으로 TCP는 데이터의 전체 패킷이 전송될 때까지 200ms 동안 기다립니다(Nagle's Algorithm은 작은 메시지를 단일 패킷으로 그룹화하려고 함).이 대기는 파일 전송 중에 지속적으로 반복될 경우 작지만 심각한 지연을 초래할 수 있습니다.예를 들어, 일반적인 전송 블록은 4KB이고 일반적인 MSS는 1460이므로 TCP가 전체 버퍼를 대기하고 있으므로 10Mbit/s 이더넷에서 패킷 2개가 각각 ~1.2ms씩 소요되고 세 번째 패킷은 197ms 동안 일시 중지된 후 나머지 1176을 전송합니다.텔넷의 경우, 각 사용자 키 입력은 사용자가 화면에서 보기 전에 서버에 의해 다시 메아리쳐집니다.이 지연은 매우 성가신 일이 될 것입니다.

소켓 옵션 설정TCP_NODELAY는 기본 200ms 전송 지연을 재정의합니다.응용 프로그램에서는 이 소켓 옵션을 사용하여 문자 또는 문자 줄을 쓴 후 출력을 강제로 전송합니다.

RFC는 다음과 같이 정의합니다.PSH푸시 비트는 "이 데이터를 수신 애플리케이션으로 즉시 전송하기 위해 수신 TCP 스택에 보내는 메시지"입니다.^[6]Berkeley 소켓을 사용하여 사용자 공간에서 표시하거나 제어할 수 있는 방법은 없습니다. 프로토콜 스택에 의해서만 제어됩니다.^[45]

취약점

TCP는 다양한 방식으로 공격을 받을 수 있습니다.TCP에 대한 철저한 보안 평가 결과와 확인된 문제에 대한 가능한 완화 조치가 2009년에 발표되었으며,^[46] 2012년까지 IETF 내에서 추진되었습니다.^[47]주목할 만한 취약성으로는 서비스 거부, 연결 가로채기, TCP 거부권 및 TCP 재설정 공격이 있습니다.

서비스 거부

스푸핑된 IP 주소를 사용하고 의도적으로 조립된 SYN 패킷을 반복적으로 전송한 다음 많은 ACK 패킷을 전송함으로써 공격자는 서버가 허위 연결을 추적하면서 많은 양의 리소스를 소비하게 할 수 있습니다.이를 SYN 플러드 공격이라고 합니다.이 문제에 대해 제안된 해결책으로는 SYN 쿠키와 암호 퍼즐이 있지만, SYN 쿠키에는 고유한 취약점이 있습니다.^[48]양말 스트레스는 시스템 리소스 관리를 통해 완화될 수 있는 유사한 공격입니다.^[49]Phrack #66에서는 TCP 지속 타이머의 악용을 포함하는 고급 DoS 공격을 분석하였습니다.^[50] PUSH 및 ACK Floods는 다른 변형입니다.^[51]

커넥션 하이재킹

TCP 세션을 도청하고 패킷을 리디렉션할 수 있는 공격자는 TCP 연결을 가로챌 수 있습니다.이를 위해 공격자는 진행 중인 통신에서 시퀀스 번호를 학습하고 스트림의 다음 세그먼트처럼 보이는 거짓 세그먼트를 위조합니다.단순 하이잭은 한 쪽 끝에서 하나의 패킷이 잘못 받아들여질 수 있습니다.수신 호스트가 잘못된 세그먼트를 승인하면 동기화가 손실됩니다.^[52]하이재킹은 공격자가 TCP 연결을 영구적으로 제어할 수 있도록 하는 ARP 스푸핑 또는 기타 라우팅 공격과 결합될 수 있습니다.

초기 시퀀스 번호를 쉽게 추측할 수 있었던 RFC 1948 이전에는 다른 IP 주소를 가장하는 것이 어렵지 않았습니다.이전의 구현은 공격자가 ARP나 라우팅 공격을 통해 통신을 가로챌 필요 없이 수신자가 다른 IP 주소에서 왔다고 믿을 만한 일련의 패킷을 맹목적으로 보낼 수 있게 했습니다. 사칭된 IP 주소의 합법적인 호스트가 다운되었음을 보장하기에 충분합니다.아니면 서비스 거부 공격을 사용하여 해당 상태로 전환할 수도 있습니다.이것이 초기 시퀀스 번호가 이제 임의로 선택되는 이유입니다.

TCP 거부권

다음에 보낼 패킷의 크기를 도청하고 예측할 수 있는 공격자는 수신자가 기존 연결을 중단하지 않고 악의적인 페이로드를 받아들이게 할 수 있습니다.공격자는 다음 예상 패킷의 시퀀스 번호와 페이로드 크기를 가진 악성 패킷을 주입합니다.합법적인 패킷이 최종적으로 수신되면 이미 수신된 패킷과 동일한 시퀀스 번호 및 길이를 가지며 일반적인 중복 패킷으로 자동으로 삭제됩니다. 즉, 합법적인 패킷은 악의적인 패킷에 의해 거부권이 부여됩니다.연결 하이재킹의 경우와 달리 연결이 비동기화되지 않으며 악성 페이로드가 수락된 후에도 정상적으로 통신이 계속됩니다.TCP 거부권은 공격자에게 통신에 대한 통제력을 줄이지만 공격이 탐지에 특히 저항력을 갖게 합니다.수신자에게 잘못된 것이 있다는 유일한 증거는 IP 네트워크에서 정상적으로 발생하는 단일 중복 패킷입니다.거부권이 있는 패킷의 송신자는 공격의 증거를 전혀 보지 못합니다.^[53]

TCP 포트

TCP 연결은 소스 주소, 소스 포트, 대상 주소 및 대상 포트(또는 이와 동등하게 주소와 포트로 구성된 소스와 대상의 네트워크 소켓 쌍)의 4배로 구분됩니다.^[54][55]포트 번호는 서로 다른 서비스를 식별하고 호스트 간의 다중 연결을 허용하는 데 사용됩니다.^[56]TCP는 16비트 포트 번호를 사용하여 소스 및 대상 포트 각각에 대해 65,536개의 가능한 값의 공간을 제공합니다.^[57]주소에 대한 연결 ID 의존성은 TCP 연결이 단일 네트워크 경로에 바인딩되어 있음을 의미하며, TCP는 멀티홈 호스트가 사용 가능한 다른 경로를 활용할 수 없으며 엔드포인트의 주소가 변경되면 연결이 끊어집니다.^[58]

포트 번호는 잘 알려진, 등록된, 동적/비공개의 세 가지 기본 범주로 분류됩니다.잘 알려진 포트는 IANA(Internet Assigned Numbers Authority)에 의해 할당되며 일반적으로 시스템 수준 또는 루트 프로세스에서 사용됩니다.서버로 실행되고 수동적으로 연결을 수신하는 잘 알려진 응용프로그램은 일반적으로 이러한 포트를 사용합니다.FTP(20 및 21), SSH(22), TELNET(23), SMTP(25), HTTP over SSL/TLS(443) 및 HTTP(80) 등의 예가 있습니다.참고로 최신 표준인 HTTP/3에서는 TCP 대신 QUIC가 전송으로 사용됩니다.등록된 포트는 일반적으로 최종 사용자 응용 프로그램이 서버에 연결할 때 임시 사용자 소스 포트로 사용하지만, 타사에서 등록한 명명된 서비스를 식별할 수도 있습니다.동적/개인 포트는 최종 사용자 애플리케이션에서도 사용할 수 있지만, 일반적으로 사용하는 경우는 적습니다.동적/개인 포트는 특정 TCP 연결 외부에 어떤 의미도 포함하지 않습니다.

NAT(Network Address Translation)은 일반적으로 퍼블릭 네트워크와 프라이빗 서브네트워크 사이를 통과하는 트래픽 흐름을 명확하게 파악하기 위해 퍼블릭 네트워크 측의 동적 포트 번호를 사용합니다. 따라서 서브넷의 많은 IP 주소(및 해당 포트)를 단일 퍼블릭 페이싱 주소로 서비스할 수 있습니다.

발전

TCP는 복잡한 프로토콜입니다.그러나 수년에 걸쳐 상당한 개선이 이루어졌고 제안되었지만, 가장 기본적인 동작은 1974년의 첫 번째 사양 RFC 675와 1981년 9월에 발표된 v4 사양 RFC 793 이후 크게 바뀌지 않았습니다.RFC 1122, Host Requirements for Internet Hosts는 다수의 TCP 프로토콜 구현 요구사항들을 명확히 하였습니다.RFC 7414에는 8가지 필수 사양 및 20가지 이상의 강력한 개선 사항 목록이 나와 있습니다.이 목록 중에는 최근 가장 중요한 TCP 관련 RFC 중 하나인 RFC 2581이 있으며, 과도한 혼잡을 방지하는 업데이트된 알고리즘에 대해 설명합니다.2001년, 혼잡 회피 시그널링 메커니즘인 ECN(Explicit Congestion Notification)을 설명하기 위해 RFC 3168이 작성되었습니다.

원래의 TCP 혼잡 회피 알고리즘은 "TCP 타호"로 알려졌지만, 그 이후로 많은 대체 알고리즘이 제안되었습니다(TCP Reno, TCP Vegas, FAST TCP, TCP New Reno, TCP Hybla 등).

TCP Interactive(iTCP)는 응용 프로그램이 TCP 이벤트에 가입하고 응용 프로그램 지원 혼잡 제어를 포함하여 다양한 목적으로 응용 프로그램을 시작할 수 있는 핸들러 구성 요소를 등록할 수 있도록 하는 TCP 확장에 대한 연구 작업입니다.

MPTCP(Multipath TCP)는 자원 사용을 극대화하고 이중화를 증가시키기 위해 TCP 연결이 여러 경로를 사용할 수 있도록 하는 것을 목표로 하는 IETF 내의 지속적인 노력입니다.무선 네트워크의 맥락에서 다중 경로 TCP에 의해 제공되는 중복성은 다양한 네트워크의 동시 활용을 가능하게 하여 더 높은 처리량과 더 나은 핸드오버 기능을 제공합니다.다중 경로 TCP는 데이터 센터 환경에서도 성능상의 이점을 가져다 줍니다.^[62]다중 경로 TCP의 참조 구현은^[63] 리눅스 커널에서 개발되고 있습니다.^[64]다중 경로 TCP는 아이폰, 아이패드, 맥에서 시리 음성 인식 어플리케이션을 지원하는 데 사용됩니다.

tcpcrypt는 TCP 자체에서 전송 수준의 암호화를 직접 제공하기 위해 2010년 7월에 제안된 확장입니다.어떠한 구성도 요구하지 않고 투명하게 작동하도록 설계되었습니다.TLS(SSL)와 달리 tcpcrypt 자체는 인증을 제공하지 않지만 이를 위해 애플리케이션에 간단한 프리미티브를 제공합니다.2010년^[update] 현재, 최초의 tcpcrypt IETF 초안이 발표되었으며 여러 주요 플랫폼에 대한 구현이 존재합니다.

TCP Fast Open은 두 엔드포인트 간의 연속적인 TCP 연결의 개방 속도를 높이기 위한 확장입니다.이것은 암호화된 "쿠키"를 사용하여 3자 악수를 생략함으로써 작동합니다.보안 문제 때문에 널리 채택되지 못했던 T/TCP라는 이전 제안과 유사합니다.^[66]TCP 패스트 오픈은 2014년에 RFC 7413으로 출판되었습니다.^[67]

2013년 5월에 제안된 PRR(Proportional Rate Reduction)은 Google 엔지니어가 개발한 TCP 확장입니다.PRR은 복구 후 TCP 창 크기가 느린 시작 임계값에 최대한 근접하도록 보장합니다.^[68]이 알고리즘은 복구 속도를 향상시키도록 설계되었으며 Linux 3.2+ 커널의 기본 혼잡 제어 알고리즘입니다.^[69]

감가상각안

TCP Cookie Transactions(TCPCT)는 2009년^[70] 12월 서비스 거부 공격으로부터 서버를 보호하기 위해 제안된 확장 프로그램입니다.SYN 쿠키와 달리 TCPCT는 윈도우 스케일링과 같은 다른 TCP 확장과 충돌하지 않습니다.TCPCT는 서버가 많은 수의 단명 TCP 연결을 처리해야 하는 DNSSEC의 필요성 때문에 설계되었습니다.2016년, TCPCT는 TCP 패스트 오픈을 지지하면서 폐지되었습니다.원래 RFC의 상태가 "historic"으로 변경되었습니다.^[71]

하드웨어 구현

TCP의 처리 전력 요구 사항을 극복하는 한 가지 방법은 TCP 오프로드 엔진(TOE)으로 널리 알려진 TCP의 하드웨어 구현을 구축하는 것입니다.TOE의 주요 문제는 컴퓨터나 장치의 운영 체제에 광범위한 변화가 필요한 컴퓨팅 시스템에 통합하기 어렵다는 것입니다.그러한 장치를 개발한 한 회사는 Alacritech이었습니다.

와이어 이미지 및 골화

TCP의 와이어 이미지는 프로토콜 메타데이터가 명확한 텍스트로 전송되기 때문에 온 경로 관찰자에게 중요한 정보 수집 및 수정 기회를 제공합니다.^[72][73]이러한 투명성은 네트워크 운영자와^[74] 연구원들에게 유용하지만, 프로토콜 메타데이터로부터 수집된 정보는 최종 사용자의 프라이버시를 감소시킬 수 있습니다.^[75][76]이러한 메타데이터의 가시성과 유연성 때문에 TCP는 확장(프로토콜 골리제이션의 경우)이 어려워졌습니다. 중간 노드('중간 상자')는 메타데이터를 기반으로 결정을 내리거나 심지어 수정할 수 있기 때문에 엔드 투 엔드 원칙을 깨고 ^[77][78]말입니다.^[79]한 측정 결과, 인터넷을 통과하는 경로의 3분의 1이 TCP 메타데이터를 수정하는 하나 이상의 매개체와 마주치고, 6.5%의 경로가 매개체로 인한 유해한 골화 효과와 마주치는 것으로 나타났습니다.^[80]중개자의 확장성 위험을 방지하는 것은 MPTCP의 설계에 상당한 제약을 주었으며 ^[81][82]중개자로 인한 어려움은 웹 브라우저에서의 TCP Fast Open의 구축을 방해하고 있습니다.^[83]osisification의 또 다른 소스는 엔드포인트에서 TCP 기능을 수정하는 어려움으로, 일반적으로 운영 체제 커널 또는^[84] TCP 오프로드 엔진이 있는 하드웨어에서 발생합니다.^[85]

성능

TCP가 신뢰할 수 있는 바이트 스트림의 추상화를 응용 프로그램에 제공하기 때문에, 패킷이 순서가 바뀌거나 손실되어 재전송이 필요한 경우(따라서 순서가 맞지 않게 도착하는 경우), 순차적으로 나중에 스트림 부분의 데이터가 순차적으로 이전 부분보다 먼저 수신될 수 있지만, 나중에 데이터가 수신될 수 있습니다.일반적으로 이전 데이터가 수신될 때까지 사용할 수 없으므로 네트워크 지연 시간이 발생합니다.여러 개의 독립적인 상위 수준의 메시지가 단일 TCP 연결에 캡슐화되고 다중화되는 경우, 헤드 오브 라인 차단으로 인해 이전에 전송된 메시지의 전달을 대기하기 위해 나중에 전송된 완전히 수신된 메시지가 처리될 수 있습니다.^[86]웹 브라우저는 여러 개의 병렬 연결을 열어 선두 차단을 완화하려고 시도합니다.이로 인해 연결 설정 비용이 반복적으로 발생하고 엔드포인트에서 연결을 추적하는 데 필요한 리소스가 증가합니다.^[87]병렬연결은 또한 서로 독립적으로 동작하는 혼잡 제어 기능을 갖지만,정보를 함께 풀링하고 관측된 네트워크 상태에 보다 신속하게 대응할 수 있는 것보다,^[88] TCP의 공격적인 초기 전송 패턴은 다수의 병렬 연결이 개방될 경우 혼잡을 야기할 수 있으며, 연결당 공정성 모델은 이러한 접근 방식을 취하는 애플리케이션이 자원을 독점하게 합니다.^[89]

연결 설정은 웹 사용자가 경험하는 지연 시간의 주요 원인입니다.^[90][91]TCP의 3방향 핸드셰이크는 데이터를 전송하기 전에 연결 설정 중에 1개의 RTT의 지연 시간을 도입합니다.^[91]짧은 흐름의 경우, 이러한 지연은 매우 중요합니다.^[92]TLS(Transport Layer Security)는 연결 설정 시 키 교환을 위해 자체 핸드셰이크가 필요합니다.계층화된 설계로 인해 TCP 핸드셰이크와 TLS 핸드셰이크는 순차적으로 진행됩니다. TCP 핸드셰이크가 종료될 때까지 TLS 핸드셰이크를 시작할 수 없습니다.^[93]TCP를 통해 TLS 1.3과의 연결을 설정하려면 두 개의 RTT가 필요합니다.^[94]TLS 1.3은 상황에 따라 제로 RTT 연결 재개를 허용하지만, TCP를 통해 계층화된 경우 TCP 핸드셰이크를 위해 하나의 RTT가 여전히 필요하며, 이것은 초기 연결을 지원할 수 없습니다. 제로 RTT 핸드셰이크는 효율적으로 암호화 문제를 야기합니다.재생-안전하고 순방향 안전한 대화형 키 교환은 공개된 연구 주제입니다.^[95]TCP Fast Open을 사용하면 초기(즉, SYN 및 SYN-ACK) 패킷에서 데이터를 전송할 수 있으므로 연결 설정 중에 지연 시간의 1RTT를 제거할 수 있습니다.^[96]그러나 프로토콜 골화로 인해 TCP Fast Open을 배포하기가 어려웠습니다. 2020년에는 기본적으로 사용하는 웹 브라우저가 없었습니다.^[83]

TCP 처리량은 패킷 순서 변경에 영향을 받습니다.순서가 변경된 패킷은 중복 확인 응답을 전송하게 할 수 있으며, 패킷이 임계값을 넘으면 허위 재전송 및 혼잡 제어를 트리거합니다.전송 동작은 또한 범위 시작 시 순서가 변경된 패킷을 수신할 때 큰 범위를 한 번에 확인하므로(헤드 오브 라인 차단이 응용 프로그램에 영향을 미치는 방식과 유사한 방식으로) 매끄럽지 못하고 더 폭주할 수 있습니다.^[97]Blanton & Allman(2002)은 모든 재정렬이 허위 재전송을 유발하는 한계까지 처리량이 재정렬의 양과 반비례한다는 것을 발견했습니다.^[98]순서 변경을 완화하는 것은 송신자가 허위 재전송을 보냈다는 것을 결정하는 능력에 따라 다르므로 재전송 모호성을 해결하는 것에 달려 있습니다.^[99]재정렬로 인한 허위 재전송을 감소시키는 것은 실제 손실로부터 신속하게 복구되는 것과 맞먹습니다.^[100]

선택적 승인은 처리량에 상당한 이점을 제공할 수 있습니다. Bruyeron, Hemon & Zhang(1998)은 최대 45%^[101]의 이득을 측정했습니다.개선의 중요한 요소는 선택적 승인이 손실 후 느린 시작으로 가는 것을 더 자주 피할 수 있고 따라서 가용 대역폭을 더 잘 활용할 수 있다는 것입니다.^[102]그러나 TCP는 시퀀스 번호의 최대 3개 블록만 선택적으로 확인할 수 있습니다.이로 인해 재전송률이 제한되어 손실 복구가 제한되거나 특히 손실이 큰 환경에서 불필요한 재전송이 발생할 수 있습니다.^[103][104]

TCP는 원래 유선 네트워크를 위해 설계되었습니다.패킷 손실은 네트워크 혼잡의 결과로 간주되며 혼잡 윈도우 크기는 예방책으로 크게 줄어듭니다.그러나 무선 링크는 페이드(fading), 음영(shadowing), 핸드오프(handoff), 간섭 및 엄격하게 혼잡하지 않은 기타 무선 효과로 인해 산발적이고 일반적으로 일시적인 손실을 경험하는 것으로 알려져 있습니다.혼잡 윈도우 크기의 (오류) 백오프 이후, 무선 패킷 손실로 인해, 윈도우 크기가 보수적으로 감소하는 혼잡 회피 단계가 존재할 수 있습니다.이로 인해 무선 링크가 제대로 사용되지 않게 됩니다.이러한 폐해를 방지하기 위한 광범위한 연구가 진행되어 왔습니다.제안된 솔루션은 클라이언트 또는 서버에서 수정이 필요한 엔드 투 엔드 솔루션,^[105] 셀룰러 네트워크의 RLP(Radio Link Protocol)와 같은 링크 계층 솔루션 또는 엔드 노드를 수정하지 않고 네트워크에서 일부 변경이 필요한 프록시 기반 솔루션으로 분류할 수 있습니다.^[105][106]

무선 문제를 해결하기 위해 베가스, 웨스트우드, 베노, 산타크루즈와 같은 다수의 대체 혼잡 제어 알고리즘이 제안되었습니다.^{[citation needed]}

액셀러레이션

이 절에서는 출처를 언급하지 않습니다. 신뢰할 수 있는 자료에 인용문을 추가하여 이 부분을 개선하는 데 도움을 주시기 바랍니다. 출처가 밝혀지지 않은 자료에 이의를 제기하여 제거할 수 있습니다.(2022년 11월) (이 템플릿 메시지를 제거하는 방법 및 시기 알아보기)

TCP 가속기의 아이디어는 네트워크 프로세서 내부의 TCP 연결을 종료한 다음 엔드 시스템을 향해 데이터를 두 번째 연결로 중계하는 것입니다.송신자로부터 발생한 데이터 패킷은 가속기 노드에서 버퍼링되며, 이 노드는 패킷 손실 시 로컬 재전송을 수행하는 역할을 합니다.따라서, 손실이 발생할 경우, 송신자와 수신자 사이의 피드백 루프가 가속 노드와 수신자 사이의 피드백 루프로 단축되어 수신자에게 더 빠른 데이터 전달이 보장됩니다.

TCP는 속도 적응 프로토콜이기 때문에, TCP 송신자가 네트워크에 패킷을 주입하는 속도는 수신자의 처리 용량뿐만 아니라 네트워크 내의 일반적인 부하 조건에 정비례합니다.네트워크 내의 일반적인 조건은 송신자가 수신한 승인을 기준으로 판단합니다.가속 노드는 송신자와 수신자 사이의 피드백 루프를 분할하여 패킷당 더 짧은 RTT(Round Trip Time)를 보장합니다.RTT가 짧아지면 네트워크의 모든 변화에 대한 응답 시간이 빨라지고 이러한 변화에 대처하기 위한 송신자의 적응이 빨라지기 때문에 이점이 있습니다.

이 방법의 단점으로는 TCP 세션이 가속기를 통해 지시되어야 한다는 점이 있습니다. 즉, 라우팅이 변경되어 가속기가 더 이상 경로에 있지 않게 되면 연결이 끊어집니다.또한 TCP ack 메커니즘의 엔드 투 엔드 속성을 파괴합니다. ACK가 송신자에 의해 수신될 때 패킷은 수신자에게 전달되지 않고 가속기에 의해 저장됩니다.

디버깅

네트워크 링크에서 TCP 트래픽을 가로채는 패킷 스니퍼는 사용자에게 링크를 통과하는 패킷이 무엇인지 보여줌으로써 TCP를 사용하는 네트워크, 네트워크 스택 및 응용 프로그램을 디버깅하는 데 유용할 수 있습니다.일부 네트워킹 스택은 setsockopt를 사용하여 소켓에서 사용하도록 설정할 수 있는 SO_DEBUG 소켓 옵션을 지원합니다.이 옵션은 해당 소켓의 모든 패킷, TCP 상태 및 이벤트를 덤프하므로 디버깅에 도움이 됩니다.Netstat는 디버깅에 사용할 수 있는 또 다른 유틸리티입니다.

대안

많은 응용프로그램에서 TCP는 적합하지 않습니다.(적어도 정상적인 구현에서는) 한 가지 문제는 애플리케이션이 손실된 패킷의 재전송된 복사본이 수신될 때까지 손실된 패킷 후에 오는 패킷에 액세스할 수 없다는 것입니다.이로 인해 스트리밍 미디어, 실시간 멀티플레이어 게임, VoIP(Voice over IP)와 같은 실시간 애플리케이션에 문제가 발생합니다. 일반적으로 모든 데이터를 정렬하는 것보다 대부분의 데이터를 적시에 가져오는 것이 더 유용합니다.

대부분의 SAN(Storage Area Network)은 과거 및 성능 상의 이유로 FCP(Fibre Channel Protocol)를 사용합니다.

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

일반적으로 TCP가 부적합한 경우 UDP(User Datagram Protocol)를 사용합니다.이것은 TCP가 할 수 있는 응용 프로그램 다중화 및 체크섬을 제공하지만 스트림이나 재전송은 처리하지 않으므로 응용 프로그램 개발자가 상황에 적합한 방식으로 코드화하거나 순방향 오류 수정이나 보간과 같은 다른 방법으로 대체할 수 있습니다.

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

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

TCP는 고대역폭 환경에서도 문제가 있습니다.TCP 혼잡 방지 알고리즘은 데이터 송신자를 미리 알 수 없는 임시 환경에서 매우 잘 작동합니다.환경이 예측 가능한 경우, ATM(Asynchronous Transfer Mode)과 같은 타이밍 기반 프로토콜은 TCP의 재전송 오버헤드를 피할 수 있습니다.

UDP 기반 데이터 전송 프로토콜(UDT)은 대역폭 지연 제품이 많은 네트워크에서 TCP보다 효율성과 공정성이 우수합니다.^[107]

MTP/IP(Multipurpose Transaction Protocol)는 다양한 네트워크 환경, 특히 TCP가 비효율적이라고 인식되는 환경에서 적응적으로 높은 처리량과 트랜잭션 성능을 달성하도록 설계된 특허를 받은 독점 소프트웨어입니다.

체크섬 계산

IPv4용 TCP 체크섬

TCP가 IPv4를 통해 실행될 때 체크섬을 계산하는 데 사용되는 방법은 다음과 같이 정의됩니다.^[9]

체크섬 필드는 머리글과 텍스트에 있는 모든 16비트 단어의 16비트 단어의 보합을 나타내는 16비트 단어의 보합입니다.체크섬 계산은 합산되는 데이터의 16비트 정렬을 보장해야 합니다.세그먼트에 홀수 개의 헤더 및 텍스트 옥텟이 포함되어 있는 경우 체크섬 목적으로 16비트 단어를 형성하기 위해 오른쪽에 0이 있는 마지막 옥텟을 추가하여 정렬할 수 있습니다.패드는 세그먼트의 일부로 전송되지 않습니다.체크섬을 계산하는 동안 체크섬 필드 자체가 0으로 바뀝니다.

즉, 적절한 패딩 후에, 모든 16비트 단어들은 자신의 보산 연산을 사용하여 추가됩니다.그런 다음 합이 비트 단위로 보완되어 체크섬 필드로 삽입됩니다.체크섬 계산에 사용되는 IPv4 패킷 헤더를 모방한 의사 헤더가 아래 표에 나와 있습니다.

체크섬 계산을 위한 TCP 의사 헤더(IPv4)

비트 오프셋	0–3				4–7				8–15								16–31
0	출처주소
32	대상주소
64	영점								의전								TCP 길이
96	소스 포트																대상 포트
128	서열번호
160	접수번호
192	데이터 오프셋				예약된			깃발									창
224	체크섬																긴급지시자
256	옵션(옵션)
256/288+	데이터.

소스 및 대상 주소는 IPv4 헤더의 주소입니다.프로토콜 값은 TCP(cf)의 경우 6입니다.IP 프로토콜 번호 목록).TCP 길이 필드는 TCP 헤더 및 데이터의 길이(옥텟으로 측정)입니다.

IPv6용 TCP 체크섬

TCP가 IPv6를 통해 실행되면 체크섬을 계산하는 데 사용되는 방법이 변경됩니다.^[108]

IP 헤더의 주소를 체크섬 계산에 포함하는 전송 또는 기타 상위 계층 프로토콜은 32비트 IPv4 주소 대신 128비트 IPv6 주소를 포함하도록 IPv6를 통해 사용할 수 있도록 수정해야 합니다.

체크섬 계산을 위해 IPv6 헤더를 모방한 의사 헤더가 아래에 나와 있습니다.

체크섬 계산을 위한 TCP 의사 헤더(IPv6)

비트 오프셋	0–7								8–15								16–23								24–31
0	출처주소
32
64
96
128	대상주소
160
192
224
256	TCP 길이
288	영점																								다음 머리글 = 의전
320	소스 포트																대상 포트
352	서열번호
384	접수번호
416	데이터 오프셋				예약된				깃발								창
448	체크섬																긴급지시자
480	옵션(옵션)
480/512+	데이터.

• 소스 주소: IPv6 헤더에 있는 주소
• Destination address: 최종 destination; IPv6 패킷이 Routing 헤더를 포함하지 않는 경우 TCP는 IPv6 헤더의 destination address를 사용하고, 그렇지 않은 경우에는 원래 노드에서 Routing 헤더의 마지막 요소의 주소를 사용하고, 수신 노드에서는 IPv6 헤더의 destination address를 사용합니다.
• TCP 길이: TCP 헤더 및 데이터의 길이
• Next Header : TCP 의 프로토콜 값

체크섬 오프로드

많은 TCP/IP 소프트웨어 스택 구현에서는 네트워크로 전송하기 전에 또는 검증을 위해 네트워크로부터 수신할 때 하드웨어 지원을 사용하여 네트워크 어댑터의 체크섬을 자동으로 계산하는 옵션을 제공합니다.이렇게 하면 OS가 체크섬을 계산하는 귀중한 CPU 사이클을 사용하지 않게 될 수 있습니다.따라서 전체적인 네트워크 성능이 향상됩니다.

이 기능으로 인해 체크섬 오프로드 사용을 모르거나 불확실한 패킷 분석기가 아직 네트워크 어댑터에 도달하지 않은 아웃바운드 패킷의 잘못된 체크섬을 보고할 수 있습니다.^[109]이 문제는 네트워크 어댑터가 전송하기 전에 가로채는 패킷에 대해서만 발생합니다. 네트워크 어댑터가 유선으로 전송하는 모든 패킷에는 유효한 체크섬이 있습니다.^[110]이 문제는 동일한 호스트의 가상 시스템 간에 전송되는 패킷을 모니터링하는 경우에도 발생할 수 있으며, 가상 디바이스 드라이버가 체크섬 계산을 생략할 수도 있으며(최적화로) VM 호스트 커널이나 해당 물리적 하드웨어에서 체크섬이 나중에 계산된다는 것을 알고 있습니다.

RFC 문서

• RFC 675 – 인터넷 전송 제어 프로그램 명세, 1974년 12월 버전
• RFC 793 – TCP v4
• RFC 1122 – TCP에 대한 몇 가지 오류 수정 사항 포함
• RFC 1323 – 고성능을 위한 TCP 확장 [RFC 7323에 의해 폐지됨]
• RFC 1379 – 트랜잭션용 TCP 확장—개념 [RFC 6247에 의해 폐지됨]
• RFC 1948 – 시퀀스 번호 공격 방어
• RFC 2018 – TCP 선택적 승인 옵션
• RFC 5681 – TCP 혼잡 제어
• RFC 6247 – 미배포 TCP 확장 RFC 1072, 1106, 1110, 1145, 1146, 1379, 1644 및 1693을 Historic Status로 이동
• RFC 6298 – TCP의 재전송 타이머 계산
• RFC 6824 – 다중주소 다중경로 운용을 위한 TCP 확장
• RFC 7323 – 고성능을 위한 TCP 확장
• RFC 7414 – TCP 규격문서 로드맵
• RFC 9293 – 전송제어 프로토콜

참고 항목

메모들

참고문헌

서지학

• Allman, Mark; Paxson, Vern (October 1999). "On estimating end-to-end network path properties". ACM SIGCOMM Computer Communication Review. 29 (4): 263–274. doi:10.1145/316194.316230.
• Bhat, Divyashri; Rizk, Amr; Zink, Michael (June 2017). "Not so QUIC: A Performance Study of DASH over QUIC". NOSSDAV'17: Proceedings of the 27th Workshop on Network and Operating Systems Support for Digital Audio and Video. pp. 13–18. doi:10.1145/3083165.3083175. S2CID 32671949.
• Blanton, Ethan; Allman, Mark (January 2002). "On making TCP more robust to packet reordering" (PDF). ACM SIGCOMM Computer Communication Review. 32: 20–30. doi:10.1145/510726.510728. S2CID 15305731.
• Borman, David; Braden, Bob; Jacobson, Van (September 2014). Scheffenegger, Richard (ed.). TCP Extensions for High Performance. doi:10.17487/RFC7323. RFC 7323.
• Briscoe, Bob; Brunstrom, Anna; Petlund, Andreas; Hayes, David; Ros, David; Tsang, Ing-Jyh; Gjessing, Stein; Fairhurst, Gorry; Griwodz, Carsten; Welzl, Michael (2016). "Reducing Internet Latency: A Survey of Techniques and Their Merits". IEEE Communications Surveys & Tutorials. 18 (3): 2149–2196. doi:10.1109/COMST.2014.2375213. hdl:2164/8018. S2CID 206576469.
• Bruyeron, Renaud; Hemon, Bruno; Zhang, Lixa (April 1998). "Experimentations with TCP selective acknowledgment". ACM SIGCOMM Computer Communication Review. 28 (2): 54–77. doi:10.1145/279345.279350.
• Chen, Shan; Jero, Samuel; Jagielski, Matthew; Boldyreva, Alexandra; Nita-Rotaru, Cristina (2021). "Secure Communication Channel Establishment: TLS 1.3 (Over TCP Fast Open) versus QUIC". Journal of Cryptology. 34 (3). doi:10.1007/s00145-021-09389-w. S2CID 235174220.
• Cheng, Yuchung; Chu, Jerry; Radhakrishnan, Sivasankar; Jain, Arvind (December 2014). TCP Fast Open. doi:10.17487/RFC7413. RFC 7413.
• Corbet, Jonathan (8 December 2015). "Checksum offloads and protocol ossification". LWN.net.
• Corbet, Jonathan (29 January 2018). "QUIC as a solution to protocol ossification". LWN.net.
• Eddy, Wesley M., ed. (August 2022). Transmission Control Protocol (TCP). doi:10.17487/RFC9293. RFC 9293.
• Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690.
• Fairhurst, Gorry; Trammell, Brian; Kuehlewind, Mirja, eds. (March 2017). Services Provided by IETF Transport Protocols and Congestion Control Mechanisms. doi:10.17487/RFC8095. RFC 8095.
• Fairhurst, Gorry; Perkins, Colin (July 2021). Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. doi:10.17487/RFC9065. RFC 9065.
• Ghedini, Alessandro (26 July 2018). "The Road to QUIC". Cloudflare.
• Gurtov, Andrei; Floyd, Sally (February 2004). Resolving Acknowledgment Ambiguity in non-SACK TCP (PDF). Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN'04).
• Gurtov, Andrei; Ludwig, Reiner (2003). Responding to Spurious Timeouts in TCP (PDF). IEEE INFOCOM 2003. Twenty-second Annual Joint Conference of the IEEE Computer and Communications Societies. doi:10.1109/INFCOM.2003.1209251.
• Hardie, Ted, ed. (April 2019). Transport Protocol Path Signals. doi:10.17487/RFC8558. RFC 8558.
• Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). Are TCP extensions middlebox-proof?. HotMiddlebox '13. doi:10.1145/2535828.2535830.
• Iyengar, Jana; Swett, Ian, eds. (May 2021). QUIC Loss Detection and Congestion Control. doi:10.17487/RFC9002. RFC 9002.
• IETF HTTP Working Group. "HTTP/2 Frequently Asked Questions".
• Karn, Phil; Partridge, Craig (November 1991). "Improving round-trip time estimates in reliable transport protocols". ACM Transactions on Computer Systems. 9 (4): 364–373. doi:10.1145/118544.118549.
• Ludwig, Reiner; Katz, Randy Howard (January 2000). "The Eifel algorithm: making TCP robust against spurious retransmissions". ACM SIGCOMM Computer Communication Review. doi:10.1145/505688.505692.
• Ludwig, Reiner; Meyer, Michael (April 2003). The Eifel Detection Algorithm for TCP. doi:10.17487/RFC3522. RFC 3522.
• Marx, Robin (3 December 2020). "Head-of-Line Blocking in QUIC and HTTP/3: The Details".
• Mathis, Matt; Mahdavi, Jamshid; Floyd, Sally; Romanow, Allyn (October 1996). TCP Selective Acknowledgment Options. doi:10.17487/RFC2018. RFC 2018.
• Paasch, Christoph; Bonaventure, Olivier (1 April 2014). "Multipath TCP". Communications of the ACM. 57 (4): 51–57. doi:10.1145/2578901. S2CID 17581886.
• Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371.
• Paxson, Vern; Allman, Mark; Chu, H.K. Jerry; Sargent, Matt (June 2011). Computing TCP's Retransmission Timer. doi:10.17487/RFC6298. RFC 6298.
• Rybczyńska, Marta (13 March 2020). "A QUIC look at HTTP/3". LWN.net.
• Sy, Erik; Mueller, Tobias; Burkert, Christian; Federrath, Hannes; Fischer, Mathias (2020). "Enhanced Performance and Privacy for TLS over TCP Fast Open". Proceedings on Privacy Enhancing Technologies. 2020 (2): 271–287. arXiv:1905.03518. doi:10.2478/popets-2020-0027.
• Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170.
• Trammell, Brian; Kuehlewind, Mirja (April 2019). The Wire Image of a Network Protocol. doi:10.17487/RFC8546. RFC 8546.
• Zhang, Lixia (5 August 1986). "Why TCP timers don't work well". ACM SIGCOMM Computer Communication Review. 16 (3): 397–405. doi:10.1145/1013812.18216.

추가열람

• Stevens, W. Richard (1994-01-10). TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Pub. Co. ISBN 978-0-201-63346-7.
• Stevens, W. Richard; Wright, Gary R (1994). TCP/IP Illustrated, Volume 2: The Implementation. Addison-Wesley. ISBN 978-0-201-63354-2.
• Stevens, W. Richard (1996). TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. Addison-Wesley. ISBN 978-0-201-63495-2.**

외부 링크

• 로버트 E. 칸 구술사 인터뷰
• IANA 포트 할당
• IANA TCP 매개변수
• John Kristoff의 TCP 개요(TCP의 기본 개념 및 TCP가 두 엔드포인트 간에 데이터를 전송하는 데 사용되는 방법)
• 체크섬 예제