HTTP/HTTPS 더 알아보기 with MDN

YTT.erica·2025년 3월 10일

MDN http https

HTTP

HTTP는 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜
웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜
⇒ 수신자 측에 의해 요청이 초기화되는 프로토콜

특징

간단함 - 사람이 읽을 수 있으며 간단하게 고안
확장 가능함 - HTTP 헤더는 확장 가능
상태는 없지만 세션은 존재 - 상태를 저장하지 않지만, HTTP 쿠키가 상태가 있는 세션을 만들도록 함
TCP 연결
- HTTP/1.0 - 각 요청/응답에 대한 별도의 TCP 연결
- HTTP/1.1 - 파이프라이닝 개념과 지속적인 연결의 개념 도입
- HTTP/2 - 연결을 좀 더 지속되고 효율을 유지하도록 단일 연결 상에서 메시지를 다중 전송
- 구글은 QUIC(UDP 기반) 시도중..

HTTP 진화 과정

1991 Tim Berners-Lee
인터넷을 통한 하이퍼텍스트 시스템을 만들기 위한 제안을 작성

초기에 Mesh라고 불리던 것을 1990년 구현 과정에서 WWW웹으로 이름 변경
4가지 요소로 이루어짐 - HTML / HTTP / WWW 브라우저 / 문서 접근 서버(httpd 초기버전)
- 1990년 말에 완료되어, 1991년 8월 6일에 공식적으로 출발

HTTP/0.9 - 원-라인 프로토콜

단일 라인으로 구성
오로지 GET 요청만 가능, URL 포함 X

요청
```
GET /mypage.html
```
응답
```
<html>
  A very simple HTML page
</html>
```
HTML 헤더가 없음 → HTML 파일만 전송 상태/오류 코드 존재 X → 문제가 발생한 경우, 특정 HTML이 만들어지고 사람이 처리할 수 있도록 HTML 파일에 설명이 추가됨

HTTP/1.0 - 확장성

1996년 11월 RFC 1945에서 공개

각 요청 안에 버전 정보가 포함되어 전송 상태 코드 라인 추가 HTPP 헤더 개념 도입 → 메타데이터 전송 가능, 프로토콜이 유연하고 확장성이 높아짐 Content-Type으로 인해 HTML 파일 외의 문서들을 전송할 수 있음

요청

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

응답

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

HTTP/1.1 - 표준 프로토콜

1997년 1월 RFC 2068에서 공개

연결 재사용
파이프라이닝 추가 → 첫 번째 요청에 대한 응답이 완전히 전송도기 전에 두번째 요청 전송을 가능
청크된 응답 지원
캐시 제어 메커니즘 도입
언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상 도입
Host 헤더로 인해, 동일 IP 주소에 다른 도메인을 호스트하는 기능

요청

GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

응답

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

HTT의 계속되는 개선...

1999년 6월 - RFC 2616
2014년 6월 - RFC 8230, RFC 7235

HTTP/2 - 더 나은 성능을 위한 프로토콜

이진 프로토콜 - 읽을 수도 수동으로 만들 수 없음
Cookie 헤더에 보안 관련 접두사 도입
클라이언트 힌트 도입 클라이언트가 요구사항이나 서버의 하드웨어 제약사항에 관한 정보를 미리 알 수 있음
Alt-Svc 지원 - CDN 메커니즘을 따라 신분 증명의 개념과 주어진 자원의 위치를 분리
서버가 서버 푸시라는 메커니즘으로 클라이언트 캐시에 데이터 저장
헤더 압축 - 요청 집합 간에 유사한 경우가 많아, 전송된 데이터의 중복과 오버헤드 제거
다중화 프로토콜 - 동일한 연결을 통해 병렬 요청 수행

웹 페이지가 복잡해짐으로써, 더 많은 시각적 미디어가 표시되고 상호작용을 위한 스크립트 코드의 양과 크기가 증가 → HTTP 요청 증가
⇒ HTTP/1.1 연결에 복잡성과 오버헤드가 많이 발생

구글 - 2010년 SPDY 프로토콜 구현

응답성 증가를 정의하고 중복 데이터 전송 문제를 해결
HTTP/2 프로토콜의 기반

HTTP/3 - QUIC

RFC 9114
이전 버전의 HTTP와 동일한 의미를 가지지만, 전송 계층에서 TCP 대신 QUIC를 사용

HTTP 연결에 대해서 훨씬 낮은 대기시잔 제공
UDP를 통해 여러 스트림을 실행, 각 스트림에 대해 독립적으로 패킷 손실 감지 및 재전송 구현

HTTP/1.X의 커넥션 관리

HTTP내 커넥션 관리는 end-to-end가 아닌 hop-by-hop인 두 개의 연속된 노드 사이의 커넥션에 적용

주로 TCP 전송 프로토콜을 주로 이용

단기 커넥션
영속적인 커넥션
HTTP 파이프라이닝

단기 커넥션

각각의 HTTP 요청은 각각의 커넥션 상에서 실행
TCP 핸드 셰이크는 각 HTTP 요청 전에 발생하고, 직렬화 됨
(TCP 커넥션은 지속적으로 연결됐을 때 부하에 맞춰 더욱 예열되어 더욱 효율적으로 작동)

단점

새로운 연결을 맺는데 드는 시간이 상당함
TCP 기반 커넥션 성능은 커넥션이 예열된 상태일 때 나아지기 때문에, 단기 커넥션에서는 성능 저하 발생

영속적인 커넥션

얼마간 연결을 열어놓고 여러 요청에 재사용 (Keep-Alive 헤더 사용해 연결 시간 설정)

새로운 TCP 핸드셰이크 비용 아낌
TCP 성능 향상 기능 활용

단점

유휴 상태일때에도 서버 리소스를 소비
과부하 상태에서 DoS 공격 발생

HTTP 파이프라이닝

기본적으로 HTTP 요청은 순차적이어서, 현재의 요청에 대한 응답을 받고 나서야 다음 요청을 실시
→ 네트워크 지연과 대역폭 제한에 걸려 다음 요청을 보내는 데까지 상당한 딜레이가 발생할 수 있음

영속적인 커넥션을 통해서, 응답을 기다리지 않고 요청을 연속적으로 보냄 → 커넥션 지연 회피
(이론상, 두 개의 HTTP 요청을 하나의 TCP 메시지 안에 넣어 성능을 향상시킬 수 있다는..?)

GET, HEAD, PUT, DELETE 메서드와 같은 idempotent aptjemaks rksmd
실패시 단순히 파이프라인 컨텐츠를 다시 반복

HTTP에서의 압축

웹 사이트의 성능을 높이는데 압축은 중요한 방법

파일 포맷 압축

각각의 데이터 타입은 몇 가지 중복을 가지고 있음
미디어 타입들은 중복 비율이 많고, 저장하는데 많은 공간을 차지함
⇒ 낭비된 공간을 되돌려놓기 위해 최적화 압축 알고리즘 설계

무손실 압축
- 압축-비압축 과정에서 데이터가 변경되지 않음
- 원래의 데이터와 복원 데이터가 일치
- ex) gif, png
손실 압축
- 사용자가 인지하기 힘든 방법 내에서 원래의 데이터를 변경
- ex) 비디오 포맷, jpeg

종단 간 압축

서버에서 HTTP 파일을 압축하여 전송하고, 클라이언트가 압축을 풀어서 사용자에게 제공하는 압축 방식

클라이언트에서 Accept-Encoding 헤더로 압축 알고리즘 지정 (ex gzip)
서버는 해당 헤더를 보고 그에 맞는 압축 알고리즘으로 데이터 압축, 응답에 Content-Encoding 헤더 로 해당 파일이 어떤 알고리즘으로 압축되었는지 명시

Hop-by-hop 압축

압축, 압축 해제가 서버, 클라이언트에서 일어나지 않고, HTTP 커넥션 중간의 노드 사이에서 일어나는 압축 방식

요청 전송 노드에서 TE 헤더에 압축 기술 명시
서버에서 압축 없는 데이터를 담아 응답하고, 응답 측의 노드가 이전에 TE 헤더에 기술한 방식으로 데이터를 합축 후 다음 노드에게 전달
요청 측 노드가 응답을 받으면 원래 데이터로 복원한 후 클라이언트에게 전달

YTT.erica

'◡'✿ 꿈을 찾아가보자고~ '◡'✿

이전 포스트