[모의 면접 CS 스터디] HTTP

정의

HTTP란 본래 웹을 통해서 문서를 전송하기 위해 사용되었던 어플리케이션 계층 프로토콜이다. 

 

특징

 

1. 요청-응답 모델

http는 기본적으로 서버-클라이언트 모델을 바탕으로 클라이언트가 요청을 서버에게 전송하면 서버가 이에 대해 응답하는 방식을 채택하고 있다. 달리 말하자면 클라이언트가 먼저 서버에게 요청을 보내지 않으면 서버는 클라이언트에게 요청을 보낼 수 없다. 이 방식은 클라이언트 입장에서 서버의 요청을 기다리는 동안 비동기적으로 다른 작업을 할 수 있다는 점에서 이점이 있다.

 

그렇다면 웹사이트에서 자주 보이는 푸시 알람은 어떤 방식으로 구현되는 것일까? 간단하게 생각하면 클라이언트에서 지속적으로 서버에게 푸시 알람이 있는지 요청을 보낼 수도 있겠지만 여러 클라이언트의 요청을 처리하는 서버 입장에서는 부담클 것이다. 따라서 이런 경우는 SSE나 WebSocket 방식을 사용하는 것이 일반적이다.

 

2. 무상태성(stateless)

stateless 즉 무상태성이란 하나의 http 메시지가 이전의 메시지에 대해서는 아무런 정보를 갖지 않는다는 것을 의미한다.

HTTP는 처음에는 단순히 문서를 주고 받는 용도로 개발되었기 때문에 이러한 특성을 가지고 있었다고 한다.

 

따라서 각각의 메시지는 비교적 적은 정보를 가지기에 오버헤드가 줄어들고, 각 메시지는 self-contained 하기 때문에 확장성이 높아지는 이점이 있다고 한다.

필자의 입장에서는 바로 이전 글에서 HTTP/1.1부터 3까지의 발전 과정을 보면 이 점이 더욱 크게 다가왔다. HTTP는 시간이 지남에 따라 많은 변화를 이룰 수 있었지만 안정적인 전송을 위해 이전 요청의 상태를 저장 (stateful)했던 TCP는 그렇지 못하였고, HTTP/3에서 stateless한 UDP 프로토콜을 확장한 QUIC으로 대체되었으니 말이다. 

 

다만 현대의 웹 어플리케이션은 사용자 인증을 위해 상태를 저장해야 하는 경우가 많다. 그러므로 현재도 stateless한가 싶은 의문이 들지만 상태는 메시지가 아니라 클라이언트나 서버에 저장되고, 각 요청과 응답은 여전히 독립적으로 그리고 병렬적으로 이루어지기 때문에 여전히 stateless한 특성을 가진다고 볼 수 있다.

 

3. 비연결성(connectionless)

HTTP의 또다른 특징으로는 비연결성, 즉 클라이언트와 서버가 연결을 계속 유지하는 게 아니라 각 한 번의 요청과 응답이 끝나면 연결을 끊는다는 점이다. 이는 서버의 입장에서 일시적으로 다수의 클라이언트와의 연결될 가능성을 줄여주는 이점이 있긴하다. 다만 매 요청-응답 사이클마다 TCP 연결을 재설정하는 오버헤드도 만만치 않기 때문에 HTTP/1.1부터 한 번 TCP 연결을 설정한 후 일정 시간 동안 연결을 유지하는 persistent connection이 도입되었다.

 

HTTP 메세지

 

1) HTTP 메소드

HTTP 메소드는 요청차 측에서 해당 요청이 어떤 종류의 요청인지 보여주는 일종의 색인이라고 할 수 있다.

메소드의 일반적으로 GET, POST가 가장 자주 쓰이고 이외에도 PUT, PATCH 등이 쓰인다.

 

- GET

클라이언트가 서버의 데이터를 조회하고자 할 때 사용한다. 기본 URL의 ? 뒤에 쿼리스트링이라는 것을 붙여서서 서버에게 각 파라미터에 맞는 정보를 보내주도록 요청한다.

 

- POST

클라이언트가 서버의 리소스에 무언가 변화를 일으키고자 할 때 사용한다.(이를테면 게시판에 글을 작성하거나 댓글을 작성하는 경우) GET과는 다르게 URL이 아닌 HTTP 요청 메시지의 바디(body)에 요청 파라미터를 넣는다.

다만 GET으로 요청을 할 때 쿼리스트링이 과도하게 길어지는 경우 로그를 볼 때 가독성이 심하게 안 좋아지기 때문에 POST를 이용해서 데이터를 조회하는 경우도 있다.

 

- PUT 

 

클라이언트가 서버의 특정 리소스를 수정하거나 혹은 리소스가 존재하지 않는 경우 새로 생성하고자 할 때 사용된다. 

 

-PATCH

 

클라이언트가 서버의 리소스의 일부분을 수정하고자 할 때 사용한다. 

 

여기서 중요한 건 반드시 각 메소드가 원래 의도대로 작동하지 않을 수 있다는 점이다. 어디까지나 해당 엔드포인트가 이러한 의도로 사용된다는 걸 보다 명확하게 표시하기 위해 사용될 뿐이다.

 

2) 상태코드(status code)

상태 코드란 서버 측에서 클라이언트에게 요청이 어떻게 처리되었는지 보여주는 용도로 사용된다. 상태코드는 세 자리 숫자로 표현되는데 맨 앞 숫자에 따라 어느 정도 카테고리 나뉜다.

 

1xx: 요청이 전달되었으나 처리에 시간이 걸릴 때 

2xx: 요청이 잘 처리 된 경우

3xx: 리다이렉션과 같이 요청을 끝내기 위해서 추가로 동작이 필요함을 나타낼 때 

4xx: 잘못된 요청을 보낼 때

5xx: 서버에 문제가 발생했을 때

 

자주 사용되는 걸 정리 해보면

• 200 OK: 성공적으로 처리했을 때 쓰인다. 가장 일반적으로 볼 수 있는 HTTP 상태.
• 201 Created: 요청이 성공적으로 처리되어서 리소스가 만들어졌음을 의미한다.
• 202 Accepted: 요청이 받아들여졌지만 처리되지 않았음을 의미한다.
• 301 Moved Permanently(영구 이동): 영구적으로 컨텐츠가 이동했을 때 사용된다.
• 302 Found: 일시적으로 컨텐츠가 이동했을때 사용된다
• 400 Bad Request(잘못된 요청): 요청 자체가 잘못되었을 때 사용하는 코드이다.
• 401 Unauthorized(권한 없음): 인증이 필요한 리소스에 인증 없이 접근할 경우 발생한다. ex) 로그인 필요할 때
• 403 Forbidden(거부됨): 서버가 요청을 거부할 때 발생한다. 관리자가 해당 사용자를 차단했거나 서버에 index.html 이 없는 경우에도 발생할 수 있다. 혹은 권한이 없을 때(로그인 여부와는 무관하다)에도 발생한다. 
• 404 Not Found(찾을 수 없음): 찾는 리소스가 없다.

3) 헤더

HTTP 메시지에서 부가적인 정보를 넣을 때 사용된다. 카테고리를 나누어 보자면

• General header: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더
• Request header: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
• Response header: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더
• Entity header: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더

자주 사용되는 헤더

 

• host: 서버의 도메인과 TCP 포트를 기입
• content-type: 바디에 있는 리소스의 종류에 대해 기술
• user-agent: user-agent의 버전, 서버 혹은 클라이언트의 애플리케이션, 운영 체제, 공급업체 및/또는 버전을 식별
• cookie: 클라이언트 측에 저장된 쿠키를 서버에 전달할 때 사용
• set-cookie: 클라이언트 측으로 서버가 쿠키를 전달할 때 사용
• connection: TCP 연결 유지 여부에 사용, keep-alive 옵션 사용시 요청-응답 사이클이 끝나도 일정시간 동안 유지

 

4) HTTP Body

HTTP body는 메시지에 포함되는 데이터를 저장하는 데에 사용된다. 항상 사용되진 않고 요청 시에는 POST, PUT, PATCH 등에서 사용되고, 응답 시에는 응답할 데이터가 존재할 때 바디가 사용된다. 

 

 

5) HTTP/2에서의 변경점

HTTP/2부터 HTTP 메시지는 텍스트가 아니라 바이너리 데이터로 압축/인코딩된 후 프레임으로 나뉘어 전송된다. 이는 바이너리 데이터가 텍스트에 비해 파싱 효율이 더 좋고, 오류 검출에 더 유리하며, 용량을 줄일 수 있기 때문이다.