[기술 공부] 웹 통신 -TCP · TLS · HTTP 1.1 / 2 / 3 (1편)

ParkJunHa·2025년 6월 2일

기술공부-API

목록 보기

3/3

TCP

Transmission Control Protocl은 인터넷에서 데이터를 전송하는 주요 프로토콜임. 신뢰성을 보장한다는 것이 가장 큰 특징임.

계층	이름	역할
전송 계층	TCP	컴퓨터 둘이 “신뢰할 수 있는” 데이터 통로를 만든다.
보안 덮개	TLS	그 통로 위에 자물쇠를 씌워 엿보지 못하게 한다.
애플리케이션	HTTP 1.1 / 2 / 3	그 통로를 이용해 웹페이지·API 요청/응답을 주고받는다.

TCP 헤더 구조

필수 필드 : 데이터를 잃지 않고 순서 그대로 받았는지 확인하고자 함.
Src/Dst Port(16b) · Seq · Ack · Data Offset · Flags(SYN/ACK/FIN/RST/PSH/URG/ECE/CWR) · Window Size · Checksum · Urgent Ptr.
동작
- 3-Way Handshake : TCP 연결을 초기화 할 때 사용
  - SYN (x) → SYN+ACK (x+1,y) → ACK (y+1)
- 데이터 흐름
  - 슬라이딩 윈도우 + 시퀀스 / ACK 번호
- 4-Way 종료 : 세션을 종료하기 위해 수행
  - FIN → ACK → FIN → ACK, TIME_WAIT 2 × MSL.

TCP 신뢰성 매커니즘

TCP는
- 데이터를 잃어버리지 않음
- 보낸 순서 그대로 도착함
- 망이 혼잡하거나 상대가 느려도 자동으로 조절함.
방법

슬라이딩 윈도우 : 송신 측이 최대 어느 바이트까지 미리 보낼 수 있는지 표시함.
흐름 제어 : 수신 애플리케이션이 데이터를 처리하지 못하면 창 크기 (rwnd)를 줄여 속도를 줄임 → rwnd가 0이 되면 전송이 잠시 멈춤
혼잡 제어 : 패킷 손실 / 지연이 늘어나면 네트워크가 막혔다는 신호로 해석하고 혼잡 창 (cwnd)를 줄임.
- AIMD : 절반으로 줄였다가 선형으로 다시 키운다.
재전송 : 손실을 감지하면 같은 세그먼트를 다시 보냄.
- RTO 만료 : 일정 시간 안에 ACK가 없으면 타이머가 울림
- Fast Retransmit : 같은 ACK번호가 3번 연속 오면 손실이라 판단하고, 즉시 재전송 (재정렬 등 일시적 지연 고려 / 경험적 판단으로 3이 가장 효율적인 연구라는 판단 - RFC5681)
SACK (Selective ACK)
- 수신 측이 이 구간은 받았고, 이 구간은 못받았다를 세밀하게 알려줌. Go-Back-N처럼 이미 받은 데이터를 또 보내지 않아도 됨.
예시

세그먼트 #100이 손실된다.
그 뒤 세그먼트는 정상적으로 도착하므로 수신 측은 ACK 100만 반복해서 보낸다.
송신 측이 세 번 연속 같은 ACK를 보면 #100을 바로 재전송한다. (Fast Retransmit)
동시에 cwnd를 절반으로 깎고, 그 뒤 한 번의 전체 ACK가 오면 선형 증가 모드로 돌아간다. (Fast Recovery)

혼잡제어 알고리즘

알고리즘	성장 패턴	감속 기준	특징
Tahoe	Slow-Start → AIMD	패킷 Loss	초기 고안(1988)
Reno	Fast Recovery 도입	3 DupACK / RTO	장수 표준
Cubic	Cubic 함수	패킷 Loss	Linux 기본, 고-B/W
BBR v2	Model-based (최대 B/W, 최소 RTT 추정)	Queue Delay 증가	저지연·고율, Google 배포

인터넷 초창기 혼잡 붕괴(congestion collapse) 문제가 자주 발생함
- 네트워크 혼잡이 심해져 처리량이 급격히 감소하고 네트워크가 안정적인 상태를 유지하지 못하는 상황을 의미
Van Jacobson(당시 LBL 연구원)이 이를 해결하기 위해 BSD TCP 스택에 단계적으로 넣은 알고리즘이 Tahoe → Reno입니다. 둘 다 오늘날 AIMD(Additive Increase/Multiplicative Decrease) 라는 기본 철학을 공유하지만, 손실을 다루는 세부 전략이 다름

용어

이름	주체	의미
rwnd	수신 측	“내 애플리케이션 버퍼에 여유가 이만큼 있으니 그 이상은 잠깐 멈춰 줘.”
cwnd	송신 측	“망이 감당할 만하다고 추정하는 한도 내에서 이만큼까진 날려도 되겠다.”
ssthresh	송신 측	“cwnd가 이 값을 넘으면 더 이상 지수 증가하지 말고 선형으로 천천히 늘려라.”

왜 세 개의 “윈도”가 생겼는가?

rwnd (수신 창) – “내 버퍼가 이만큼 비었으니 그 이상은 잠깐 멈춰.”
- 이미 1970 년대 TCP 초안에 들어 있던 흐름 제어(flow control) 장치입니다.
- ↳ 문제: 네트워크-쪽이 막혀도, 수신 버퍼만 넉넉하면 송신자는 계속 밀어 넣을 수 있습니다.
  ⇒ 혼잡과 수신 오버플로를 구분할 방법이 없음.
cwnd (혼잡 창) – “망이 감당할 수 있다고 내가 ‘추정’한 최대치.”
- 1986–87 년에 백본이 무너진 후 Van Jacobson이 새로 추가.
- 손실이나 지연 상승을 혼잡의 신호로 보고 스스로 전송량을 제한합니다.
ssthresh (슬로스타트 임계값) – “여기부터는 조심해서 늘려.”
- Slow Start(지수 성장)와 Congestion Avoidance(선형 성장)를 가르는 경계선.
- 손실 직전의 cwnd 절반 값을 기억해 두었다가 “이 이상은 혼잡에 가까웠다”고 표시합니다.

덕분에 다음 번엔 지수 성장이 ssthresh 까지만, 그 이후는 선형 성장으로 변합니다.

TCP Tahoe

손실이 났으면 처음부터 다시 함.

회복 속도는 느리지만 혼잡 붕괴 재발을 막음.

Slow Start
- 연결을 맺으면 cwnd = 1MSS
- 매 ACK마다 cwnd += 1MSS → RTT마다 2배 증가
- sshthresh(slow-start threshold) 값에 도달하면 Congestion Avodance로 전환됨.
Congestion Avoidance
- RTT마다 cwnd += 1MSS

TCP Reno

Tahoe + Fast Recovery

손실은 있었지만 망이 완전히 막힌게 아니면 속도를 절반을 줄이고 계속 선형 증가.

Slow Start & Congestion Avoidance
- 초기 동작과 AIMD 증가는 Tahoe와 동일
Fast Retransmit
- 중복 ACK 3회가 들어오면 타이머(RTO)만료를 기다리지 않고 즉시 잃어버린 세그먼트를 재전송함.
Fast Recovery
- 재전송 직후 cwnd = ssthresh = 현재 cwnd / 2로 줄임.
- 그 상태에서 선형증가 단계로 바로 진입.
- 이후 손실구간을 메운 ACK가 오면 cwnd를 ssthresh 값으로 복원하고 Congestion Avoidance를 계속함.

Q. 혼잡이 발생한 근처의 크기로 cwnd를 조절하면 되는데, 왜 절반으로 줄이는가?

A1. 손실은 라우터 큐가 꽉 찬 결과지만,
“얼마나 꽉 찼는지”·“다른 송신자도 얼마나 보내고 있는지”는 알 수 없습니다.
A2. 큐를 빠르게 비우면서도 ‘처리량 0’까지 떨어지지 않는 경험적 최적점
A3. 여러 송신자가 같은 링크를 쓸 때 동시에 손실을 겪으면 동시에 ½ 로 줄여야
각자 차지하던 비율 이 유지
A4. cwnd를 아주 조금만 내리고 금세 다시 올리면 오버슈트-언더슈트가 계속되어 그래프가 발진함. (과도현상)

TCP 최적화

Nagle

1980년대 링크는 느리고 라우터 버퍼가 작았음. + 키 입력 하나마다 각각의 40바이트정도의 TCP 헤더와 데이터 1바이트 감. tinygram flood 발생함.
동작
- 소켓 버퍼에 새 데이터가 MSS보다 작고,
- 아직 이전 세그먼트의 ACK를 받지 못했다면
- 송신자는 대기. ACK가 오거나 버퍼가 MSS만큼 차면 한 번에 밀어냄
장점
- 헤더/인터럽트 수가 감소하므로 CPU/네트워크 효율이 높아짐
- 주식이나 실시간 게임에서는 작은 ms 지연도 사용자가 체감하므로 꺼야함.
- HTTP/1.1 파이프라이닝에서 HOL 지연 발생
HOL 지연
- 앞선 요청이 DB/쿼리/IO로 오래걸리면 그 뒤의 요청들도 TCP 버퍼에 묶여 연쇄적으로 지연됨.

Delayed ACK

ACK도 패킷임. 큰 파일 하나 내려받을 때 ACK만 수천개 날아감. 이를 줄이기 위해 ACK도 묶어서 보내자는 아이디어
동작
- 수신측은 데이터 수령 후 40 - 200 ms 내에서
  - 이미 보낼 데이터가 있으면 거기에 ACK 동승
  - 없으면 타이머 만료 직전 단독 ACK wjsthd
효과
- 왕복 ACK 수가 30-50% 감소로, 링크/CPU 부하 감소
- 일부 혼잡제어(Reno 등)에서 cwnd 급팽창 속도 늘려줌

SACK(Selective ACK)

TCP 통신에서 중간에 하나가 빠지면 그 뒤 블록도 모조리 재전송하는 GO-Back-N 방식으로, 10MB 링크에서 딱 1KB 빠져도 다시 10MB를 다시 보내는 낭비가 발생함.
동작
- 수신측이 ACK 옵션에 받은 범위 리스트를 담아 보냄
- 송신측은 빈 구간만 골라 재전송
효과
- 대용량 전송(백업, DB 복제), 고 BDP 회선에서 복구 속도가 향상되어 대역폭 낭비가 줄음.

TCP Fast Open (TFO)

모바일 앱 / CDN 썸네일처럼 짧은 연결 수백 번을 만드는 경우 SYN - SYN/ACK - ACK - DATA로 2RTT
프로토콜 흐름
- 첫 연결시 : 서버가 SYN-ACK 옵션에 쿠키 발급
- 다음 연결 : SYN + 쿠키 + 첫 데이터 ➡️ 서버는 ACK 없이 데이터를 바로 앱에 전달 (0-RTT)
- 쿠키 유효기간 안에만 동작
효과
- 모바일 페이지 TTFB 10-30% 단축
- 동시 팔로 권한 체크 / 쿠키 유효성만 끝나면 즉시 GET 처리
주의
- 일부 방화벽이 SYN에 데이터를 보내는것을 의심할 수 있음 -> 전소 ㅇ실패
- TLS 1.3 0-RTT와 중첩되어 대형서비스에서도 TFO ON 이익 < 운영 비용 이슈로 제한적 사용

TFO는 “SYN 안에 첫 HTTP 요청 데이터까지 실어 보낸다” → 연결 RTT를 아낀다.

서버는 쿠키·권한만 즉석 확인 후 TCP 완료를 기다리지 않고 응답 생성에 들어가므로 TTFB 가 크게 준다.

모바일·짧은 다중 연결 환경에서 실제로 10 ~ 30 % TTFB 단축이 반복 검증됐다.

TCP 대안

기존 TCP를 대체한 새로운 전송층 또는 아키텍처로 갈아타는 방식.

목표는 “TCP가 주는 호환성과 신뢰성은 유지하면서, 단점 — HOL 블로킹·긴 핸드셰이크·고정 헤더 등 — 을 덜어 보자” 입니다.

QUIC (UDP 기반, HTTP/3 표준 전송층)

핵심 아이디어	구체적 장치
1-RTT(재접속 0-RTT) 암호화	TLS 1.3 핸드셰이크를 전송층과 합침
멀티스트림 & HOL 제거	패킷이 아니라 프레임 단위 재전송
연결 지속성	IP 바뀌어도 `ConnectionID`로 세션 유지
유저 공간 구현	커널 패치 없이 라이브러리 교체만으로 업그레이드

사용처
- 웹·API: 모든 주요 브라우저·CDN이 HTTP/3 지원.
- 모바일: 지연·망 전환에 민감, 0-RTT + Connection Migration 효과 큼.
- 보안 요구: 암호화 내장(옵트아웃 불가) → L7 프록시 체인 단순화.

2. SCTP (Stream Control Transmission Protocol) — 멀티스트림·멀티홈 특화

특징	설명
멀티스트림	하나의 연결에 여러 논리 메시지 → HOL 블로킹 최소
멀티홈	연결 생성 후 다른 IP(인터페이스)로 투명 Fail-over
메시지 경계 유지	“Datagram + 신뢰성” 하이브리드

사용처
- 5G RAN·시그널링 (LTE S1-AP, NGAP)
- WebRTC DataChannel: 실제로는 SCTP over DTLS over UDP.
- 제약: 방화벽 / NAT 통과성이 약해 대규모 공용 인터넷 서비스엔 드뭄.

RUDP / FEC + UDP

Twitch Low-Latency, Zoom, CitiStreamer…

선택 방식	얻는 것
애플리케이션이 직접 ACK / 재전송 / FEC	TCP보다 지연 예측 가능 (필요 패킷만 재송)
UDP 헤더 그대로	NAT 친화성, 커스텀 헤더 설계의 자유

단점

프로토콜 설계·테스트 비용 ↑.
중간 장비가 패킷 모양을 모르면 QoS 분류·트래픽 관측이 어려움.

출처

https://www.geeksforgeeks.org/tcp-tahoe-and-tcp-reno/

ParkJunHa

PS린이

이전 포스트