HTTP와 URL, 그리고 앱 커스텀 스킴 경험

1. HTTP란?

2. HTTP 기본 요소

리소스 : http로 전송할 수 있는 어떠한 종류의 콘텐츠 소스.

트랜잭션 : HTTP 트랜잭션 = 요청 명령 + 응답 결과

- HTTP 메시지라고 불리는 정형화된 데이터 덩어리를 이용해 이루어짐

HTTP 메서드 : 모든 요청 메시지는 한 개의 메서드를 가짐. 서버에게 어떤 동작을 취해야하는지 알려줌.

- (GET,POST,PUT,DELETE,HEAD)

상태코드 : 클라이언트에게 요청이 성공했는지 추가조치가 필요한지 알려주는 숫자

- (200,302,404,500)

HTTP 메시지 : 메시지는 단순한 줄 단위의 문자열 (시작줄, 헤더, 본문 으로 구성)

3. HTTP 버전별 특징

HTTP/0.9 (1991) : GET만 존재, 헤더 없음, HTML 문서만 전송 가능

HTTP/1.0 (1996) : 헤더 개념 도입, GET,POST,HEAD 지원, 요청마다 새로운 TCP 연결

HTTP/1.1 (1997) : 지속연결(keep-alive) 지원, PUT, DELETE .. 지원, 파이프라이닝 (여러 요청을 동시에 보내되 응답은 순서대로)

HTTP/2 (2015, IETF 표준화) : 멀티플렉싱 (여러 요청 + 여러 응답 → HOL 문제 해결), 헤더 압축(HPACK), 서버 푸시 (클라이언트 요청 전 필요한 리소스 보내줌 → 요즘은 preload 방식을 사용)

HTTP/3 (2022, IETF 표준화) : *QUIC(UDP) 기반 프로토콜, HOL 문제 해결, TLS 1.3 내장 → 모바일 환경 최적화

4. TCP/IP와 HTTP 요청 과정

www.google.com/index.html 주소창 입력

1. URL에서 호스트 명을 추출

2. DNS로 호스트 명을 IP로 변환

3. 포트번호 확인

4. 브라우저는 IP와 포트번호를 통해 웹서버와 TCP 커넥션을 맺음

5. 브라우저 → 서버 : HTTP 요청 전송

6. 서버 → 브라우저 : HTTP 응답 반환

7. 브라우저가 문서 렌더링

5. URL과 리소스

URL : 애플리케이션이 리소스에 접근할 수 있는 방법을 제공

scheme://username:password@host:port/path;params?query#fragment
// 스킴://사용자이름:비밀번호@호스트:포트/경로;파라미터?질의#프래그먼트

scheme : 웹 클라이언트가 리소스에 어떤 프로토콜을 사용하여 서버에 접근하는지 알려줌
- http : 웹 프로토콜
- mailto : 이메일 주소
- ftp : 파일서버
username:password (사용자 정보, userinfo) – username:password@
- 브라우저 UI에서 감춤/무시되는 경우 많고, 보안·로그 유출 리스크 큼.
- 자격증명은 Authorization 헤더·쿠키·OAuth로 처리
host/port : 리소스를 호스팅하는 서버의 호스트명이나 IP주소
path : 서버 내 리소스의 위치 (RESTful 설계 → /products/123/reviews 같은 리소스 중심)
parameter : 세그먼트 단위 메타데이터 (거의 안씀)
query string : 리소스 전체에 대한 질의 (대부분 사용)
fragment : 리소스의 조각 중 일부분을 가리키는 이름. 클라이언트에서만 사용, 서버에는 전달안됨. SPA 라우팅(/#/path)에서 SEO 이슈와 연결

6. 실무경험 : URL을 이용한 앱 커스텀 스킴 개발

사례 : 앱 내 웹뷰에서 "myapp://close" 같은 커스텀 스킴 구현 → 웹뷰 닫고 앱 화면으로 복귀
동작방식
- FE : <a href="myapp://close">홈버튼 클릭</a> → 단순히 URL 호출
- 웹뷰 : URL 로딩 이벤트 발생
- 네이티브 : URL 로딩 이벤트 감시 → myapp:// 인지 확인 → 정의된 동작 실행 (웹뷰 닫기)
느낀점
- 커스텀 스킴은 새로운 기술이 아니라, URL의 scheme 개념을 앱 전용으로 확장한 것
- http://가 서버와 통신하는 규칙이라면, myapp://은 앱이 네이티브 동작을 수행하는 규칙
- 내가 한 실무 경험도 결국 URL 구조와 원리의 실제 적용

*QUIC = UDP 위에 TCP + TLS 기능을 올려놓은 차세대 전송 프로토콜
- 빠르고 안전하며, 손실·모바일 환경에 강함.

- TCP의 3-way handshake, HOL Blocking 한계를 극복하기 위해 UDP 사용

- 한 스트림에서 패킷 손실 발생해도 다른 스트림은 영향 없음 (TCP HOL 문제 해결)

- 암호화가 기본(TLS 1.3 내장) → 항상 HTTPS 수준의 보안 제공

- 추가 Handshake 과정 없음 → 연결 수립이 더 빠름 (1-RTT, 심지어 0-RTT도 가능)

- TCP+TLS 대비 초기 연결 시간이 단축됨 → 모바일·불안정 네트워크에서 장점

- 연결이 IP/포트에 묶이지 않음 → 네트워크 전환(와이파이 ↔ LTE) 시에도 연결 유지 가능

29살 아저씨의 코딩 일상