HTTP란 무엇인가?

HTTP란?

HTTP(HyperText Transfer Protocol)는 웹의 app-L 프로토콜이다.

 

HTTP의 특징

• client/server 모델이다.
• client: HTTP 프로토콜로 요청(request)을 보내고 응답을 받는 브라우저이다. 
• server: HTTP 프로토콜로 요청에 대한 응답(reponse)을 보낸다.

일반적으로, 사용자가 웹 페이지를 요청할 때 

(1) 브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메시지를 서버에게 전송한다.

(2) 서버는 요청을 수신하고, 객체를 포함하는 HTTP 응답 메시지로 응답한다.

 

HTTP의 TCP 사용

• 클라이언트가 서버에게 TCP connection을 보낸다. (이 때 소켓을 만든다.)
• 서버는 클라이언트로부터 온 TCP connection에 접속한다. (소켓 interface를 통해 TCP에 접속한다.)
• 브라우저(HTTP client)와 웹서버(HTTP server)는 서로 HTTP 메시지(request, reponse)를 교환한다.
• TCP connection이 종료된다.

이 때, 클라이언트가 보내는 모든 HTTP 요청 메시지는 서버에 도착한다. 이것은 TCP가 reliable data 전송 서비스를 제공하기 때문이다. 

 

HTTP is "stateless"

이것은 서버가 클라이언트의 요청에 대한 정보를 유지하지 않는 특성을 의미한다. 클라이언트로부터 HTTP request가 오면 그에 대한 reponse를 보내고 request를 지우는 것이다. 이렇게 하는 이유는 프로토콜이 "state"를 유지하는 것(= 모든 request를 저장하고 기억하고 있는 것)은 굉장히 복잡하기 때문이다. 그래도 혹시 모를 상황을 대비하여 백업 서버를 두고 서버 장애 시, 백업 서버를 통해 대응이 가능하다. 

• 장점: 서버의 확장성이 높다.
• 단점: 클라이언트에 대한 추가 데이터 전송을 요구할 수 있다.

만약 서버가 stateful하다면, 백업 서버가 없기 때문에 기존의 기록이 없어질 수 있다.

 

HTTP 연결

HTTP는 연결 상태를 유지하는지 아닌지에 따라 persistent HTTP와 non-persistent HTTP로 나뉜다.

 

non-persistent HTTP

모든 요청/응답 쌍이 분리된 TCP connection을 통해 전송된다. 클라이언트와 서버가 서로 요청/응답을 한 번씩 주고 받으면 TCP connection이 닫힌다. 즉, 한 번의 TCP connection을 통해 전송되는 오브젝트의 수가 최대 1개인 것이다. 만약 여러 오브젝트를 다운받으려면 그만큼 여러 connection이 필요하다.

 

예를 들어, 1개의 HTTP에 10개의 이미지 파일로 구성된 웹페이지가 있다고 가정하자.

클라이언트와 서버의 연결 과정은 다음과 같다.

1. 클라이언트가 서버로 TCP connection을 시도한다.
2. 서버는 TCP connection이 잘 이루어졌다는 응답을 클라이언트에게 전송한다.
3. 클라이언트는 서버에게 HTTP 페이지의 이미지 1개에 대한 request 메시지를 전송한다.
4. 서버는 클라이언트에게 HTTP response 메시지를 전송한다.
5. TCP connection이 종료된다.

이 때, 이 웹페이지에는 10개의 이미지가 있으므로 각각의 이미지에 대해 1~5번 과정이 10번 반복될 것이다.

 

non-persistent HTTP의 RTT (Round-Trip Time)

RTT란 패킷 하나가 클라이언트에서 서버로 전송되고, 다시 클라이언트로 돌아오는데 걸리는 시간을 의미한다.

첫 번째 RTT는 서버와 클라이언트가 맨 처음에 TCP connection을 시작하는 것이다. 두 번째 RTT는 HTTP request와 response를 주고받는 시간이다. 마지막은 파일 전송 시간이다. 따라서 non-persistent HTTP의 대략적인 응답 시간은 2RTT + file transmission time다. 여기서 포인트는 매번 2RTT가 필요하다는 것이다.

non-persistent HTTP의 단점

• 매번 2RTT가 필요하다.
• 각각의 TCP connection에 대한 오버헤드가 발생한다.
• 브라우저는 웹페이지에 참조된 개체를 가져오기 위해서 병렬 TCP connection을 시도한다.

 

persistent HTTP

각각의 요청/응답 쌍이 같은 TCP connection 내에서 이루어진다. 클라이언트와 서버가 여러 번의 reuqest와 response를 주고 받을 때 단 하나의 TCP connection만 사용되는 것이다. non-persistent HTTP보다 더 효율적이고, 보통 이 방식을 사용한다. 

• 서버는 TCP connection에 대한 응답을 보낸 뒤에 connection을 계속 열어둔다.
• 클라이언트와 서버는 이미 열려있는 connection 1개로 계속 HTTP 메시지를 주고 받는다.
• 1RTT로 모든 오브젝트를 전송한다.
• 열린 TCP connection은 일정 기간동안 사용하지 않으면 닫힌다.

 

URL 문법

• scheme://[userinfo@]host[:port][/path][?query]

URL 문법은 위와 같은 구조이다. 이해하기 쉽게 아래 예시 링크로 알아보자. 이것은 구글에 hello를 검색했을 때 링크이다.

• https://www.google.com/search?q=hello&hl=ko

- 프로토콜: 보통 https가 온다.

https는 http에 TLS가 적용된 것이다.

- [userinfo@]: 없다.

URL에 사용자 정보를 포함해서 인증하는 것인데, 거의 사용하지 않는다.

- 호스트명: www.google.com

IP주소로 입력할 수도 있다.

- 포트번호: 443

이것은 https의 포트번호이다. http는 80 포트를 사용한다. 포트번호는 생략이 가능하다.

- path: search

리소스의 경로이다. 주로 계층적인 구조로 구성된다. (e.g., /home/file.jpg, /members/100)

- 쿼리: ?q=hello&hl=ko

key=value 형태이다.

 

HTTP는 connectionless하다.

HTTP는 기본적으로 connection을 유지하지 않는 모델이다. 따라서 서버 자원을 효율적으로 활용할 수 있다. 하지만 지속적인 TCP/IP 3-way handshake로 오버헤드가 발생할 수 있다. 이러한 단점을 해결하기 위해 앞에서 언급한 persistent connection을 제공한다.

 

HTTP  메시지 구조

HTTP의 request 메시지는 위와 같은 구조를 가진다. 상태코드(response 메시지에 있다, 200, 403, 404, 502 같은 것들), GET, 링크 등은 메시지의 시작라인에 온다. HTTP 헤더에는 HTTP 전송에 필요한 부가정보가 온다.

 

HTTP 상태 코드

HTTP는 response 메시지의 status-line에 상태 코드를 통해 요청의 성공과 실패를 나타낸다. 2xx은 성공, 3xx은 리다이렉(요청 완료를 위한 추가적인 처리 필요), 4xx은 클라이언트 요청 오류, 5xx은 서버 내부 오류를 의미한다.

 

HTTP의 주요 메소드

• GET

리소스를 조회한다. 서버에 전달하고자 하는 쿼리를 전달한다.

• POST

클라이언트로부터 온 요청 데이터를 처리한다. 메시지 바디를 통해 서버로 요청 데이터를 전달한다. 주로 전달 된 데이터를 등록하고 처리할 때 사용된다.

• PUT

리소스를 대체한다. 만약 해당 리소스가 생성되지 않았다면 생성한다.

POST와 PUT의 차이: PUT은 클라이언트가 리소스 URI를 알고 있어야 한다. (PUT은 '대체' 기능이니까!!)

 

• PATCH: 리소스를 부분 변경한다.

• DELETE: 리소스를 삭제한다.