[Network] #2 HTTP

오늘은 OSI 7계층과 TCP/IP 4계층 양쪽 모두에서 최상위 계층에 있는 Application Layer, 그 중에서도 HTTP에 대해 정리해보려고 한다! Application Layer에서는 SMTP나 FTP 같이 메일이나 파일을 전송할 수 있는 프로토콜을 개발자에게 제공하기 때문에 네트워크 엔지니어가 아니더라도 (특히 웹 개발을 하는 나는) 이 계층에 대해 좀 더 알 필요가 있다고 생각했다.

 

 

HTTP란 뭘까?

Hyper Text Transfer Protocol의 약자로, HTML이나 TEXT를 전송할 수 있는 프로토콜...을 의미하지만 최근에는 이미지나 미디어, 파일, JSON, XML 등등도 모두 전송하는 프로토콜을 통칭한다.

 

HTTP의 특징

1. 클라이언트 서버 구조

클라이언트는 요청을 보내고 서버는 요청에 대한 결과를 응답하는 구조다. 따라서, OSI 7계층이나 TCP/IP 처럼 클라이언트와 서버는 자신의 역할에만 충실하면 되는 구조다.

 

2. Stateless(무상태성) Protocol이다.

가장 중요한 특징이다. 위 특징과도 연결되는데, 서버가 클라이언트의 상태를 저장할 이유가 없다. 객체지향 원칙 중 단일 책임 원칙과 마찬가지로 클라이언트와 서버를 하나의 클래스라고 생각하면, 각 클래스, 즉 클라이언트와 서버는 자신의 책임에만 집중하면 되기 때문이다.

 

따라서, 클라이언트와 서버의 결합도가 매우 낮고, 중간에 서버를 변경해도 되기에 수평 확장(Scale-Out)이 매우 편리하다.

 

3. Connectionless(비연결성) Protocol이다.

클라이언트와 서버는 클라이언트가 요청을 보낼 때만 연결이 되며, 그 이외에는 연결을 유지하지 않는다.

 

HTTP의 단점, 어떻게 극복할까?

위 특징 중 3번의 이유 때문에, 요청이 필요할 때마다 연결을 해야 한다. 따라서 비용이 많이 드는데, 이 문제를 해결하기 위해서 HTTP 지속 연결(Persistent Connections)를 사용한다.

 

HTTP 지속 연결을 지원하는 대표적인 방법 중 HTTP Keep-Alive 라는 방법이 있는데, 클라이언트와 서버 사이에서 동일한 TCP Connection을 이용해서 여러 번 요청과 응답을 주고 받을 수 있게 하는 방법이다.

 

비연결성 Protocol인 HTTP의 단점을 극복하기 위한 또 다른 방법으로는 HTTP 파이프라이닝이 있다. HTTP 파이프라이닝은 HTTP에서 요청과 응답을 처리하는 방식 중 하나로, 연속된 요청을 일괄적으로 보내고 응답을 일괄적으로 받는 방식이다. 따라서, 대역폭으로 효율적으로 사용할 수는 있으나, 요청의 순서가 중요한 경우에는 사용하지 않는다.

 

HTTP 메시지는 어떤 형태로 전송될까?

HTTP 메시지 구조

그렇다면 HTTP의 요청과 응답은 어떤 구조로 되어 있을까?

HTTP 메시지 구조

크게 4개로 나눌 수 있다.

 

1. Start Line은 요청이나 응답의 자원이 작성되는 공간이다.

2. Header는 클라이언트와 서버 간의 통신에서 필요한 모든 부가정보(Message Body의 내용 및 크기, 인증)의 내용를 담아 교환하기 위해 사용한다.

3. CRLF는 단순히 Header와 Message Body를 구분하는 역할을 하는 빈 줄이다.

4. Message Body에는 실제 전송할 데이터가 담긴다.

 

그렇다면 요청 메시지와 응답 메시지의 구조도 같을까?

다르다. 일단 4개로 나뉜다는 것은 똑같지만, 내용이 조금 다르다.

HTTP 요청 메시지의 예시

 

요청 메시지의 예시는 위와 같다. 요청 메시지도 body 본문을 가질 수 있다.

 

HTTP 응답 메시지의 예시

 

응답 메시지의 예시는 위와 같다. Start-Line과 Header 부분이 다르다는 것을 알 수 있다.

 

요청의 Start-Line에는 [HTTP Method] [요청 대상] [HTTP 버전] 에 대한 정보가 들어간다. 반면, 응답의 Start-Line에는 [HTTP 버전] [HTTP 상태코드]에 대한 정보가 포함된다.

 

Header의 경우도 살짝 다르다. 요청의 경우 Host(요청이 전송되는 서버의 도메인 이름과 포트 번호), 응답의 경우 Content-Type(응답 본문의 미디어 타입)과 Content-Length(응답 본문의 크기를 바이트 단위로 나타낸 것)가 있다.

 

HTTP Header

이 중 HTTP Header에 대해 더 자세히 알아보았다. 출처에 따르면, Header의 종류는 아래와 같이 크게 4개로 나눌 수 있다.

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

HTTP Method

HTTP 메서드의 종류 (출처: https://ko.wikipedia.org/wiki/HTTP)

 

API를 요청했을 때 반환되는 응답을 분석할 때는 보통 HTTP 메서드의 종류와 상태 코드가 많이 쓰인다. 따라서 HTTP 메서드의 종류와 상태 코드를 분석하는 것은 당연히 중요하다.

 

주요 HTTP 메서드는 다음과 같다.

1. GET: 리소스를 조회하는 메서드이다. 요청에 Body를 포함하지 않고, 대신 Query Parameter(Query String)을 통해 서버에 전달하고 싶은 데이터를 전달한다. (다만, Query Parameter를 사용할 경우 정보가 그대로 드러난다는 보안 상의 이슈가 있다.)

2. POST: 요청 데이터를 처리하는 메서드로, Body를 통해 서버로 요청을 보내 새로운 데이터를 등록하거나 요청한 데이터를 처리할 때 사용한다.

3. PUT: 리소스를 완전히 대체하는 메서드이다. 요청 데이터에 해당하는 리소스가 존재하면 대체하고 없다면 새로 생성한다. 주로 수정 요청을 보낼 때 사용하며, 따라서 어떤 데이터를 수정할 지에 대한 정보를 요청에 포함해야한다.

4. PATCH: 리소스를 부분적으로 대체하는 메서드이다. 이외에는 PUT과 같으나, 중요한 차이점이 하나 있다. 이 차이점은 밑에서...^^

5. DELETE: 리소스를 삭제하는 메서드이다.

 

HTTP의 멱등성(Idempotent)

멱등성? 예전에 공학수학에서 배운 용어였던 걸로 기억하는데... 정확히 기억이 나지 않는다. 위 HTTP 메서드 표 그림을 보면 PUT과 PATCH의 유일한 차이점임을 알 수 있다. 그렇다면 멱등성은 무엇일까?

 

HTTP 멱등성을 만족하려면, HTTP 요청을 한 번 보내는 것과 여러 번 보내는 것이 같은 효과를 가져야 하고, 서버의 결과도 동일해야한다.

 

PUT의 경우는 수정 요청을 보내면 값이 수정되는 필드만 요청 후에 반환되기 때문에 멱등성이 보장되지만, PATCH의 경우에는 수정 요청이 들어오지 않은 필드더라도 요청 후에 반환된다.

 

HTTP Status Code

앞에서 HTTP Method에 대해 알았으니, 이제 Status Code, 즉 상태 코드만 알면 된다. HTTP 상태 코드는  클라이언트가 서버로 요청을 보내면 HTTP 응답 메시지에서 요청의 성공 여부를 알려주는 역할을 한다.

 

주요 상태 코드는 아래와 같다.

 

1. 1XX(Informational): 요청이 수신되어 처리 중이다.

2. 2XX(Successful): 요청이 정상적으로 처리되었다.

3. 3XX(Redirection): 요청을 완료하기 위해 추가 행동(Redirection)이 필요하다. 응답 메세지 Header에 Location 필드가 존재하는 경우, 해당 값으로 redirect 한다.

4. 4XX(Client Error): 클라이언트에서 잘못된 값을 보냈거나 인증/인가가 제대로 되지 않은 경우의 상태 코드이다.

5. 5XX(Server Error): 서버에서 에러가 발생하여 요청을 정상적으로 처리할 수 없는 경우의 상태 코드이다.

 

주요 HTTP Status Code

수많은 Status Code 값이 있지만, 자주 쓰이는 코드는 다음과 같다.

1. 200 OK: 요청 및 응답 성공

2. 400 Bad Request

3. 401 Unauthorized: 인증 되지 않은 클라이언트가 접근할 경우

4. 403 Forbidden: 인증은 되었으나, 해당 리소스에 접근할 권한이 없는 경우

5. 404 Not Found

6. 500 Internal Server Error

7. 502 Bad Gateway

8. 503 Service Unavailable

 

HTTP/1.1, HTTP/2, HTTP/3 의 차이

1. 우선 현재 대부분 쓰이는 것은 HTTP/1.1이지만, HTTP/2나 HTTP/3도 점차 증가하는 추세이다.

2. 또, HTTP/1.1과 HTTP/2는 TCP 기반이지만, HTTP/3은 UDP 기반이다. 따라서, 3 way handshake를 사용하는 TCP의 특성 때문에 HTTP/3의 속도가 나머지 둘에 비해서 더 빠르다.