2020 12 02
Cookie와 Session을 공부하면서 계속 모르는 용어들이 나오고, HTTP에 대해서 조금 깊게 공부해야겠다고 느꼈다. 네트워크를 공부하면서 맨 처음에 가장 이해가 가지 않았던 것이, OSI 7 계층에서 같은 레이어끼리 정보를 주고받는데, 그 정보는 맨 하위 레이어로 내려간대.. 이게 뭔말일까.. 싶었는데 최근에 이해가 가면서 학습에 속도가 붙은 것 같다. HTTP는 웹 개발자라면 무조건적으로 알아야할 내용이다.
개요
Hyper Text Transfer Protocol
www상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다. 주로 TCP를 사용하고 HTTP/3 부터는 UDP(QUIC)을 사용하며, 80번 포트를 사용한다
- HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜
- 클라이언트인 웹브라우저가 HTTP를 통하여 서버로부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다.
- TCP/IP를 이용하는 Application Layer 프로토콜
- HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜 -> Cookie와 Session이 등장.
네이버로 들어가서 크롬 개발자모드를 켜고 Application에 들어가면 Cookies나 여러 가지를 볼 수 있기도 하다.
요청 메시지
클라이언트와 서버 사이 소통은 평문(ASCII) 메시지로 이루어진다. 클라이언트가 서버로 보내는 요청 메시지는 다음과 같다.
- 요청 내용
- GET /images/logo.gif HTTP/1.1
- 헤더
- Accept-Language: en
- 빈 줄
- 기타 메시지
등을 포함하여 요청메세지를 보내며, 요청 내용과 헤더는 CRLF로 끝나야 한다.
응답 메시지
-
상태표시 행(Status Line): 상태 코드와 reason message를 포함한다.
- HTTP/1.1 200 OK
-
응답 헤더 필드
- Contenty-Type: text/html
-
HTTP 상태 코드는 IANA에서 관리를 하고 있다.
HTTP 진화
1. HTTP/0.9 - 원라인 프로토콜
-
HTTP 초기 버전에는 버전 번호가 없었다.
-
요청은 단일 라인으로 구성되며, 리소스에 대한 경로로 GET 메서드만 가능
GET /login.html -
응답 또한 파일 내용 자체로 구성되었다.
2. HTTP/1.0 - 확장성
-
버전 정보가 요청에 같이 전송됨
-
Status 코드 또한 응답의 시작 부분에 붙어 전송 -> 요청에 대한 성공/실패 결과를 알 수 있었음
-
평범한 HTML 파일 외에 json, text 등 다른 문서들을 전송하는 기능 추가
GET /login.html HTTP/1.0 User-Agent: NCSA_Mosaic/2.0 200 OK Date: Thu, 20 Dec 1995 09:22:11 GMT Server: ... ...
3. HTTP/1.1 - 표준
1995년 부터 다양한 HTTP/1.0 구현이 진행되고, 1996년 까지 표준화가 진행중에 있었는데, HTTP의 첫 번째 표준인 HTTP/1.1은 HTTP/1.0이 나온지 몇 달 되지 않은 1997년 초에 공개되었다.
- 한 Connection 당 하나의 요청을 처리하도록 설계가 됨. 하지만 재사용될 수 있게 하여, 사용된 커넥션을 다시 열어 시간을 절약하게 함
- 파이프라이닝을 추가하여, 첫 번째 요청에 대한 응답이 전송되기 전, 두 번째 요청 전송을 가능하게 함.
- 캐시 제어 메커니즘 도입
- Host 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능하게 함.
- 코로케이션의 사전적 의미는 직접 서버를 관리를 하지 않고 인터넷 서비스를 제공하는 IDC 업체가 보유한 초고속 네트워크 망으로 서버를 연결하여 관리하는 서비스
그 후 15년 넘게 HTTP/1.1은 매우 안정성을 유지해 왔다.
1.보안 전송을 위한 HTTP
- TCP/IP 스택을 통해 HTTP를 전송하는 대신에 SSL을 추가해서 HTTPS라는 프로토콜 개발
- SSL -> TLS로 됨
2.복잡한 애플리케이션을 위한 HTTP
- REST API 패턴이 2000년도에 고안됨.
- API에 의해 유도되는 액션들은 기초적인 HTTP 메서드를 이용한 특정 URI 접근에 의해서도 전달되지 않음.
3.웹의 보안 모델
- CORS, CSP 등
- Same origin 정책
4. HTTP/2.0 - 더 나은 성능을 위한 프로토콜
HTTP/1.1 커넥션은 올바른 순서로 전송되는 요청을 필요로 한다. 많은 양의 오버헤드와 복잡도가 남아 있다. 2010년 초에 구글은 SPDY 프로토콜을 구현하여, 클라이언트와 서버 간의 데이터 교환을 대체할 수단을 만들었다.
-
최적화 기술 구현
-
동일한 Connection 상에서 병렬 요청 가능. (Multiplexed Streams)
-
한 커넥션으로 동시에 여러 개의 메세지 주고받음.
-
응답 순서는 상관 없음.
-
-
순서 제거(Stream Prioritization)
- 리소스간 의존관계 (우선순위 설정)
-
클라이언트 캐시를 서버 푸쉬라고 불리는 매커니즘으로 필요하게 될 데이터로 채워넣도록 허용.
2015년 5월에 표준화가 되었고, 큰 성공을 거두었다.
HTTP/1.1 단점
- HOL Blocking
- 첫 번째 요청에 대한 응답이 지연되면 다음번째 요청에 대한 응답은 첫 번째 응답처리가 완료되기 전까지 대기
- RTT 증가
- 하나의 Connection에 하나의 요청을 처리하기 때문에 매 요청별로 Connection을 만들게 됨
- 3way handshake가 반복적으로 일어나고, 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 저하 시킴
- 무거운 Header 구조
- 매 요청마다 중복된 Header 값 전송
- Domain에 설정된 cookie 정보도 매 요청마다 헤더에 포함하여 전송
HTTP/3.0 & QUIC
HTTP 3 에 대한 내용과 QUIC 에 대한 내용은 다음 번에 큰 주제로 다뤄 볼까 한다. 내가 학교 과목 중에 하나에서 QUIC으로 NS-3에서 시뮬레이션을 돌리는 작업을 하면서 QUIC을 공부하긴 했지만 다시 공부해 보는 것도 좋을 것 같다.
참조
