[웹을 지탱하는 기술] chapter 06. HTTP의 기본

 

[목차]
chapter 01. 웹이란 무엇인가?
chapter 02. 웹의 역사
chapter 03. REST 웹의 아키텍처 스타일
chapter 04. URI의 스펙
chapter 05. URI의 설계
chpater 06. HTTP의 기본

 

HTTP는 TCP/IP를 베이스로 한 프로토콜이다. 이 장에서는 TCP/IP 기초 지식과 HTTP의 간단한 역사를 알아본다. 그리고 HTTP의 메시지 구조와 프로톸로로서의 HTTP를 특정짓는 스테이트리스성 등에 대해서도 알아본다.

 

HTTP의 중요성

• RFC 2616에서 규정된 프로토콜.
• 1.1 버전이 규정되어 있음. 현시점에서는 최신 버전이며, 현재의 웹에서는 이 버전의 HTTP가 제일 많이 사용됨 → 확인 필요
• 이름과 다르게 HTML과 XML 같은 하이퍼텍스트 뿐만 아니라, 컴퓨터에서 다룰 수 있는 데이터라면 무엇이듯 전송할 수 있다.
• REST의 중요한 특징인 Uniform 인터페이스, 스테이트리스 서버, 캐시 등을 구현하고 있는 Web의 기반이 되는 프로토콜이다.

 

TCP/IP란 무엇일까?

HTTP가 기반하고 있는 TCP/IP는 무엇일까?

계층형 프로토콜

• 인터넷의 네트워크 프로토콜은 계층 구조를 가지고 있다.
• 각 계층별로 추상화하여 구현했기 때문에 하위 계층의 구체적인 사항에 좌우되지 않고 상위 계층을 구현할 수 있다.

네트워크 인터페이스 계층

• 가장 아래의 계층으로, 물리적인 케이블이나 네트워크 어댑터에 해당하는 부분이다.

인터넷 계층

• 네트워크 인터페이스 계층 위에 존재하는 계층.
• 네트워크에서 데이터를 실제 주고받는 일을 담당하는 계층으로 IP(Internet Protocol)가 여기 해당된다.
• IP에서는 데이터의 기본적인 통신 단위를 ‘패킷(paket)’이라고 부른다.
• 지정한 IP 어드레스와 패킷 단위로 데이터를 주고받으면서 통신한다.

트랜스포트 계층

• 인터넷 계층 위에 존재하는 계층
• IP가 하지 않았던 데이터의 무결성을 보증하는 역할을 하는 계층으로, TCP가 여기에 해당한다.
• TCP는 목적지의 상대에 대해서 커넥션을 연결하고, 이 커넥션을 이용해 데이터의 누락을 체크하고, 데이터의 도달을 보증한다.
• TCP로 접속된 커넥션에서 전송하는 데이터가 어느 애플리케이션으로 전달될지 결정하는 것이 포트번호다. (포트 번호는 1~65535까지 사용. 서버에서 자주 사용하는 번호에는 디폴트 번호가 할당되어 있으며, HTTP는 디폴트로 80번 포트를 사용함.)

애플리케이션 계층

• 트랜스포트 계층 위에 존재하는 계층.
• 구체적인 인터넷 애플리케이션, 가령 메일이나 DNS, HTTP를 실현하는 계층
• TCP로 프로그램을 만들 때는 소켓(socket)이라 불리는 라이브러리를 사용하는 것이 일반적.
• 소켓은 네트워크에서의 데이터 교환을 추상화한 API로 접속, 송신, 수신, 절단 등의 기본적인 기능을 갖우고 있다.
• 대부분의 프로그래밍 언어에는 HTTP 구현 라이브라리가 있음. 하지만, 세세한 동작과 설정, 파라미터 등이 프로토콜 수준에서 어떻게 동작하는지 파악해둘 필요는 있음.

→ 책에서의 설명은 TCP/IP 4계층을 설명한 것으로, OSI 7계층을 기반으로 상업적이고 실무적으로 이용될 수 있도록 단순화된 모형이다. (네트워크 전송 시 데이터 표준을 정리한 것이 OSI 7계층, 이 이론을 실제 사용하는 인터넷 표준이 TCP/IP 4계층)

[개발자 인터뷰] TCP/IP 4계층

 

HTTP의 버전

HTTP 0.9 - HTTP의 탄생

• 버너스 리가 1990년에 웹을 발명했을 때 사용하던 프로토콜을 0.9버전이라고 함.
• HTTP의 헤더가 없었음.
• HTTP 메서드로는 GET 뿐이었음.

HTTP 1.0 - HTTP 최초의 표준화

• IETF에서 표준화가 이루어진 최초의 버전
• 브라우저 전쟁이 가장 치열했던 시기에 스펙의 책정작업이 이뤄졌기 때문에(스펙 책정이 되기도 전에 기능 구현이 이뤄짐), RFC 1945는 인터넷 표준이 아니라 Informational(인터넷 전체에 주지가 필요한 정보)로서 공개 → 기존 구현을 기반한 스펙이므로, 여전히 상호운용성이 확보되어 있다고 말하기 어려운 상황
• 헤더의 도입, GET 이외의 메서드 추가 등 HTTP 1.1로 이어지는 기본적인 요소들이 도입됨.

HTTP 1.1 - HTTP의 완성

• RFC 2068로서 1997년에 책정. 이후 개정을 거쳐 1999년 RFC 2616 발행되었으며 현재 1.1의 스펙임.
• 채널 전송, Accept 헤더에 의한 콘텐트 네고시에이션, 복잡한 캐시 컨트롤, 지속적 연결 등의 기능 추가

→ 책에서는 HTTP 1.1 버전까지 설명되었지만, 개발자 모드의 network로그만 확인해봐도 네이버를 접속할때는 h2, 구글을 들어갈 때는 h3가 찍히는 것을 확인할 수 있었다.

HTTP의 진화 - HTTP | MDN

간단히 정리하자면 HTTP 2에서는 텍스트 프로토콜이 아닌 이진 프로토콜로 변경하여 최적화를 진행하였고, 반복적인 헤더 정보를 압축시킨다는 점. HTTP 3는 TCP가 아닌 UDP 기반의 프포토콜인 QUIC을 사용하여 통신을 한다. TCP는 신뢰성 있는 통신을 하기 때문에 느리다는 단점이 있고, TCP를 더 건드리기엔 이미 제한 사항이 많기 때문에 빠르고, 비교적 깨끗한 UDP에서의 통신을 택했다.

 

클라이언트와 서버

• 웹은 아키텍처 스타일로 클라이언트/서버를 채용하고 있음. → 요청-응답 구조
• HTTP1.1를 규정한 RFC 2616에는 클라이언트와 유사한 용어로 유저 에이전트(User Agent)라는 용어가 등장함.
• RFC 정의로는 요청을 송신할 목적으로 서버와의 커넥션을 확립하는 프로그램이 클라이언트, 서버에 대해 구체적인 요청을 발행하는 것이 유저 에이전트라고 구별 → 큰 차이가 없어 본서에서는 같은 의미로 사용

 

요청과 응답

서버에서 처리 시간이 많이 걸리는 경우라도 요청을 보낸 클라이언트는 응답이 돌아올 때까지 대기한다. → HTTP는 동기형 프로토콜임을 알 수 있음

클라이언트에서 일어나는 일들

1. 요청 메시지 구축
2. 요청 메시지 송신
3. (응답이 돌아올 때까지 대기)
4. 응답 메시지 수신
5. 응답 메시지 해석
6. 클라이언트의 목적을 달성하기 위해 필요한 처리

→ 이미지와 스타일시트로의 링크를 바르게 랜더링하기 위해 재요청이 필요한 경우도 있다.

서버에서 일어나는 일들

1. (요청을 대기)
2. 요청 메시지 수신
3. 요청 메시지 해석
4. 적절한 애플리케이션 프로그램으로 처리를 위임
5. 애플리케이션 프로그램으로부터 결과를 취득
6. 응답 메시지 구축
7. 응답 메시지 송신

 

HTTP 메시지

요청 메시지와 응답 메시지를 합해서 HTTP 메시지라고 부른다.

요청 메시지

요청 라인(Request-Line)

• 요청 메시지의 첫번째 라인.
• 메서드, 요청 URI, 프로토콜 버전으로 구성
• 메서드 : URI로 식별하는 서버상의 리소스에 대해 수행하고자 하는 처리 지정
• 요청 URI: 경로 이후의 문자열 혹은 절대 URI. 절대 URI를 사용한 경우에는 Host 헤더 생략 가능

헤더(Header)

• 요청메시지의 둘째 줄부터 시작.
• 메시지의 메타 데이터를 가짐. ‘이름:값'의 구성.

바디(Body)

• 헤더 뒤에 이어짐
• 메시지를 나타내는 본질적인 정보가 들어감.

응답 메시지

스테이터스 라인(Status Line)

• 응답 메시지의 첫째 줄
• 프로토콜 버전, 스테이터스 코드, 텍스트 구문으로 구성됨
• 스테이터스 코드 : 요청의 결과를 프로그램으로 처리 가능한 수치 코드로 표현

헤더(Header)

• 응답 메시지의 둘째 줄부터 시작.

바디(Body)

• 헤더와 바디는 빈 줄(헤더 맨 마지막의 줄 끝에 연속하는 CRLF)로 구분됨.

HTTP 메시지의 구성요소

• 스타트 라인 : 요청 메시지의 경우 요청 라인, 응답 메시지의 경우 스테이터스 라인
• 헤더 : 헤더 각 행의 주 바꿈은 CRLF. 헤더의 종료는 빈 줄로 식별. 생략 가능
• 바디 : 텍스트 뿐 아니라 바이너리 데이터도 들어갈 수 있음. 생략 가능

 

HTTP의 스테이트리스성

HTTP는 스테이트리스(Stateless)한 프로토콜로 설계되어 있음. 스테이트리스란 ‘서버가 클라이언트의 애플리케이션 상태를 보존하지 않는다'는 제약을 말한다.

책에 언급된 햄버거 가게 예를 통해 알 수 있는 사실

• 스테이트풀한 대화는 간결함
• 스테이트리스한 대화는 장황함
• 스테이트풀한 대화에서 서버는 클라이언트의 주문 내역을 기억함
• 스테이트리스한 대화에서 클라이언트는 매번 모든 주문을 반복함

애플리케이션 상태

스테이풀한 대화에서 서버는 클라이언트가 그때까지 한 주문을 계속 기억하고 있다는 것을 전제로 진행됨. 이 ‘햄버거 세트에 포테이토를 주문하고 있다’는 정보를 가리켜 애플리케이션 상태라고 한다.

애플리케이션 상태는 다른 이름으로 **‘세션 상태(Session Sate)’**라고도 한다.

스테이풀의 결점

• 서버가 클라이언트의 애플리케이션 상태를 기억하는 것은 클라이언트의 수가 증가함에 따라 여려워지게 됨.
• 하나의 서버가 동시에 상대할 수 있는 클라이언트 수는 한계가 있기 때문
• 서버를 복제한다고 하더라도 복수의 서버 간에 애플리케이션 상태를 동기화하는 오버헤드를 무시할 수 없음

→ 스테이트풀한 아키텍처로는 클라이언트의 수가 증가했을 경우에 규모를 확장하기 어려움

스테이트리스의 이점

• 요청을 처리하는 데 필요한 정보가 모두 포함되어 있는 메시지를 ‘자기 기술적 메시지(self descriptive messge)라고 한다.
• 서버가 애플리케이션의 상태를 기억하는 대신에 클라이언트가 자신의 애플리케이션 상태를 기억하고 모든 요청을 자기 기술적 메시지로 송신

→ 스테이트리스한 서버는 애플리케이션 상태를 기억할 필요가 없기 때문에 서버 시스템이 단순해진다. 즉, 서버 확장이 쉬워짐.

스테이트리스의 결점

퍼포먼스의 저하

• 송신할 데이터의 양이 많아진다
• 인증 등 서버에 부하가 걸리는 처리를 반복한다

통신 에러에 대한 대처

• 네트워크 트러블이 발생했을 때 그 요청이 처리되었는지 알 수 없다

 

심플한 프로토콜의 강점

HTTP의 가장 큰 특징은 심플함이다. 심플함 덕분에 PC 뿐만아니라 다양한 디바이스에서도 구현될 수 있게 되었고, 웹 서비스와 웹 API가 같은 프로토콜로 실현될 수 있게 되었다.