HTTP

개념
HyperText Transfer Protocol의 약자, 클라-서버 사이 데이터를 주고 받기 위한 프로토콜. 현대 네트워크 통신의 가장 기본적인 기술 중 하나이다.
동작
TCP/IP로 동작. 사용자가 웹 사이트를 방문하면 사용자 브라우저가 웹 서버에 HTTP 요청을 전송, 웹 서버는 HTTP응답으로 응답한다. (80번 포트 사용. )
OSI(Open Systems Interconnection)
네트워크 통신 모델의 애플리케이션 계층 프로토콜. HTTP 매서드를 이용해 정보를 요청하고 제공 받음.
- 마찬가지로 서버는 숫자 코드 및 데이터 양식으로 다양한 유형의 응답 전송.
숫자 코드 요약
- 1xx: 정보 제공. 현재의 클라이언트 요청까지는 처리되었으니 계속 진행하라는 의미이다. 1.1 버전부터 추가되었다.
- 2xx: 성공. 클라이언트의 요청이 성공적으로 처리되었다는 의미.
- 3xx: 리다이렉션. 완전한 처리를 위해서는 추가적인 동작이 필요하다는 의미. 주로 서버 주소나 URI의 웹문서가 이동되었으니 그 주소로 다시 시도하라는 의미로 많이 쓰인다.
- 4xx: 클라이언트 에러. 없는 페이지 요청 등 클라이언트의 요청 내용이 잘못되었을 때 뜨는 코드이다.
- 5xx: 서버 에러. 서버의 문제로 메시지를 처리하지 못한 경우 뜬다. 서버 부하, DB 오류, 서버익셉션 등의 경우가 있다.
→ 이런 응답은 사용자에게 보이지 않음. 브라우저와 웹 서버가 사용하는 방식으로 www는 모든 사용자에게 일관되게 작동.
주요 특징
- stateless: 서버가 클라이언트의 상태를 보존하지 않는다. → 요청과 응답이 독립적으로 주고받아진다. → 클라이언트와 서버가 정적으로 연결될 필요성이 없어지므로 서버 확장에 있어 자유롭다. → 클라이언트가 서버에 보내야 하는 데이터가 늘어난다. 클라이언트가 해당 주소에 관한 정보를 저장해야 하므로 브라우저에서 쿠키, 세션, 토큰 등을 이용해 상태를 유지해야 한다.
- connectionless: TCP 통신은 기본적으로 연결을 유지해야 하지만 위의 stateless 특성으로 인해 연결을 유지하고 있을 필요성이 없다. 따라서 요청마다 연결과 연결 종료를 반복하는 connectionless 특성을 띄게 구현되었다. → 서버의 자원 소모가 적다. 트래픽이 적을 때 빠른 응답이 가능해 효율적이다. → 결국 매번 연결을 해야 하기에 매번 핸드셰이크 과정이 필요하다. 이는 곧 자원을 반복적으로 다운로드 해야 한다는 것이기에 트래픽이 커지면 비효율적일 수 있다. → 이에 따라 지속 연결 기술이 등장했다.
- Method, Path, Version, Headers, Body 등으로 구성되어있다. 이와 관련한 내용은 다음 포스팅인 HTTP 메소드에서 자세하게 다룰 예정이다.
HTTP의 역사
HTTP/0.9
단일 라인 으로 구성된 요청, GET이 유일한 메서드. HTML 형식만 전송 가능.
- 이때부터서버는 연결 종료 후 요청에 대한 정보를 저장하지 말것을 명시해 stateless를 유지
HTTP/1.0
0.9의 제한적인 기능 때문에 대부분의 서버들은 자체 기능들을 구현해 사용. 이에 기존에 사람들이 구현해 사용하던 것들을 모아 새로문 버전을 발표. → 헤더 추가, HEAD(리소스 다운 없이 메타데이터 요청)와 POST(클라이언트가 서버에게 데이터 전송) 추가, HTTP 요청시 버전 명시(버전 없으면 0.9로 인식), 상태 코드가 추가(이전에는 HTML 문서 내부에 포함되어있어 알아보기 어려웠다. )
HTTP/1.1
HOST 요청 헤더 반드시 포함, 지속 연결 기능, 파이프라이닝, PUT, OPTIONS, DELETE 메서드 추가, 캐시 제어 메커니즘 추가, HTTP 쿠키 추가 등등 기능이 생김
- HOST 요청 헤더: HTTP 요청은 절대경로가 아닌 상대경로(도메인 주소의 뒤에 붙는 부분)로 요청을 보내는데 과거엔 서버 하나당 웹사이트 하나만 호스팅을 했지만 최근에 가상 호스팅으로 하나의 서버에서 여러개의 도메인을 호스팅 가능해짐에 따라 어떤 도메인으로 접속했는지에 대한 구분이 필요해졌다. 따라서 HOST 헤더에 도메인을 명시하도록 변경되었다.
- 지속 연결: 이전 버전에선 하나의 요청을 할 때 마다 연결과 종료를 반복했지만 요청이 잦아지고 많아짐에 따라 timeout을 설정, 이 시간동안 연결을 유지하다가 연결 요청이 없으면 연결해제를 하는 방식으로 연결 해제에 딜레이를 주는 방식으로 구현했다. (이 기능은 1.0에서도 지원하는 서버들이 많이 있었다고 한다. )
SPDY
- 1.1까지 존재했던 문제점.
- HOL문제: 요청과 그에 따른 응답이 순차적으로 진행되야 함에 따라 앞서 요청한 응답이 오래 걸리면 뒤의 요청들이 빨리 끝날 수 있다 하더라도 요청 자체가 늦어지는 문제.
- 연결 요청을 여러 번 할때 생기는 오버헤드와 데이터를 전송할 때 점차 전송량을 늘려가는 slow start 방식에서의 성능저하 발생
→ HTTP 요청을 SPDY 요청으로 변환해 서버에 전송하고 이 응답을 다시 HTTP로 변환.
- 주요 특징
- 멀티플랙싱 스트림
- 우선순위 설정
- 바이너리 프로토콜
- 헤더 압축: 1.1버전에서는 헤더가 일반 텍스트 형태로 전송되었다. 헤드는 결국 한정되어있는 문구들이기 때문에 데이터를 중복해서 전송과 송신을 반복하게 되므로 오버헤드가 발생한다. 이를 해결하기 위해 2버전에선 HPACK이라는 압축 기법으로 헤더를 압축해 전송한다.
- HPACK
- Huffman code를 사용해 헤더 쌍을 압축.
- 이렇게 압축해둔 헤더를 미리 정적 테이블에 저장.
- 서버와 클라이언트가 사용한 헤더를 공유하는 동적테이블에 저장. 중복된 요청시 이 테이블에서 데이터를 사용하므로 헤더의 중복 전송에 따른 오버헤드가 감소한다.
- 서버 푸시(클라이언트가 요청하지 않은 컨텐츠도 서버가 미리 전송해 지연 감소. ex: index.html을 요청하면 거기에 따른 css 파일도 같이 다운 받는다. )
→ 실제로 여러 사이트들의 로딩 속도가 크게 향상되어 다양한 브라우저에서 지원하였고 이에 따라 2버전으로 업그레이드 하며 반영됨.
HTTP/2
위의 SPDY를 기반으로 업그레이드. HTTP의 내용들을 차용했다. 결국 1.1에서 문제가 되었던 HOL을 해결했다. 또한 이진 프레이밍 레이어를 이용해 이진 프로토콜을 구현하였다.

HTTPS

개념
http에 Secure Socket Layer(SSL) 혹은 Transport Layer Security(TLS)를 추가한 버전(HyperText Transfer Protocol Secure) → 암호화된 통신을 제공
HTTP에서 이와 같이 바뀌면서 보안이 중요해진 만큼 중간에 데이터를 가로채도 해독할 수 없게 만들었다.
장점
암호화를 통해 사용자의 신뢰를 얻고 검색 엔진 최적화 면에서도 긍정적 영향을 미친다. (구글 같은 검색엔진들은 보안을 중요하게 생각하기 때문. )
암호화 방법(SSL/TLS)
공개 키 암호화 방식을 사용. 서버-클라 핸드셰이크 방식(서로 악수하듯)으로 암호화 키 교환. 이 키를 이용해 암호화/해독 하므로 중간에 데이터가 샌다 하더라도 해독 불가. → 핸드셰이크: 클라이언트와 서버가 통신할 때 서로 송신과 수신이 원활하게 되었는지 크로스체크 하는 과정이 담겨있는 방식. 사람이 악수를 요청하고 상대방이 이에 동의하며 악수를 하듯 서로 요청과 확인을 한다.
중요성
- 보안 수준을 높이는 가장 기본적이면서도 중요한 방법. 데이터 보호 및 사이버 공격으로부터의 사이트를 안전하게 유지하기 위해 필수적이다. 데이터 보호 뿐 만 아니라 인증 과정을 통해 보안을 강화.
- SEO(Search Engine Optimization. 검색 엔진 최적화) 측면의 중요성: 주요 검색 엔진은 SSL/TLS 보호를 검색 엔진 최적화의 순위 요소로 만들었습니다. SSL/TLS 보안 웹 사이트는 SSL/TLS 인증서가 없는 유사한 웹 사이트보다 검색 엔진에서 더 높은 순위를 차지할 것입니다. 이로 인해 검색 엔진에서 SSL/TLS로 보호되는 웹 사이트 방문자가 증가합니다.
→단순한 기술적 조치를 넘어 신뢰를 구축하고 웹사이트의 가치를 높이는 중요한 전략.
사용 이유
HTTPS는 결국 HTTP에 암호키를 주고 받는 과정과 암호화 과정이 추가되기 때문에 속도 저하를 야기할 수 밖에 없다. 따라서 개인 정보가 오가지 않고 단순한 정보만 오간다고 하면 HTTP를 사용해도 무방하다. 하지만 HTTPS라는 암호화 프로토콜 자체가 단순히 보안의 단계를 넘어서서 해당 도메인의 신뢰도에 대한 문제이기 때문에 HTTPS를 사용해서 사용자들의 신뢰를 얻는 도메인이 되는 것이 중요하다. 이런 점 때문에 HTTPS가 아닌 접근을 할 때 브라우저는 이를 의도적으로 접근하려 하는 것인지 한번 더 물어본다.
적용 방법
- SSL 인증서 구입, 웹 서버에 설치하는 과정 필요. SSL 인증서는 공인된 인증 기관(CA, Certification Authority)으로부터 구입 가능. 종류에 따라 가격과 보안 수준이 상이.
- 인증서 설치 후 설정 변경을 통해 HTTPS 활성화. 이 과정은 서버마다 다를 수 있으니 관련 문서를 확인하고 시행.
- 적용 후 사이트의 모든 페이지가 HTTPS를 통해 접근되도록 설정. 일부만 사용할 경우 보안성이 떨어짐.
→ HTTP 적용은 보안을 강화, 신뢰를 얻는 중요한 단계이므로 이 과정을 정확히 이해하고 적용해야 한다.
결론
- http의 개념과 문제점, 이에 따른 https의 등장과 동작 원리를 이해하고 이를 통해 얻을 수 있는 이점과 중요성을 알아봤다.
- https는 단순한 기술적 조치를 넘어서서 사용자와의 신뢰를 구축하고 사이트의 가치를 높이는 중요한 전략이므로 이를 잘 이해하고 적용해 보다 안전하고 신뢰 가능한 환경을 구축하고 제공해야 한다.