안녕하세요. HTTP는 현대 개발에서 가장많이 사용하는 프로토콜 중에 하나입니다. 주로 이 프로토콜을 기본으로하여 유저와 서버간 서버와 서버간의 데이터를 주고 받습니다. 오늘은 이런 HTTP의 구조에 대해서 개괄적으로 분석해보는 시간을 가져보도록 하겠습니다.
http 통신의 구성
http 통신은 요청과 응답이 하나의 세트로 이루어집니다. 즉, 요청(Request)에 대해서 응답(Resonse)이 오는 구조인데요. 이때 http의 프로토콜 구조는 세부 내용은 다르지만 요청(Request), 응답(Resonse) 모두 동일한 구성을 가집니다. 바로 시작줄(Start Line)과 헤더(Headers)와 바디(Body)로 구성된다는 것입니다.
아래 이미지는 제 블로그(sabarada.tistory.com)을 접속했을 때 제일 처음 일어나는 http 통신을 스냅샷 뜬 부분입니다. Chrome 브라우저를 통해서 스냅샷을 찍었습니다. 아래를 보시면 헤더 부분의 첫줄에 시작줄이 있는것을 확인할 수 있었습니다.
아래 부터는 이 메시지를 기본으로하여 내용을 알아보도록 하겠습니다.
시작 줄(Start Line)
모든 Http 메시지는 시작줄(Start Line)으로 시작합니다. 요청 시작줄은 서버에 무엇을 해야할지, 응답 시작줄은 그 결과가 어땠는지 알려줍니다.
요청
GET / HTTP/1.1
- 메서드(Method)
- 요청의 제일 처음 나오는 부분으로 서버에 어떤 행동을 하라는 것을 요청 하는 것인지 명시하는 부분입니다. Restful API를 사용한다면 대부분 GET은 읽기, POST는 쓰기, PUT은 업데이트 그리고 DELETE는 삭제를 의미할 것입니다. 그렇지만 이는 서버와의 인터페이스에 따라 달라집니다.
- 요청 URL
- Host 헤더를 기준으로 요청하는 url의 path를 명시하는 부분입니다. 전체 URL, 상대 URL을 사용할 수 있으며 상대 URL을 사용할 경우에는 base URL을 Host 헤더에 명시해주어야합니다.
- Http 버전 번호
- Http 버전 번호는 요청과 응답에 모두 명시됩니다. 클라이언트 또는 서버가 상대방에게 자신의 http 프로토콜 버전을 알려줌으로써 버전에 따라 사용할 수 있는 기능과 사용하지 못하는 기능을 알려주는 역할을 합니다.
응답
HTTP/1.1 200 OK
- Http 버전 번호
- 요청의 HTTP 버전 번호와 동일
- 상태 코드(Status Code)
- 클라이언트에게 서버로 요청한 일이 어떻게 마무리되었는지 알려주는 코드입니다. 상태코드는 3자리의 숫자로 나타내며 종류는 아래와 같습니다.
- 사유 구절(Reason-phrase)
- 숫자로 된 상태 코드를 설명해주는 짧은 문구입니다. 사람이 읽기 위한것으로 상태 코드에 논리적인 영향은 주지 않습니다.
헤더(Headers)
시작줄(Start Line) 다음줄 부터는 헤더가 나타나는것을 확인할 수 있습니다. 헤더 필드는 메시지에 추가적인 정보를 더해줍니다. 헤더는 헤더이름, 콜론(:), 공백(선택적), 값, 엔터(Line Wrrapper)가 순서대로 나타납니다.
일반 헤더
일반 헤더는 요청 메시지와 응답 메시지에 모두 사용되는 헤더를 말합니다. 아래에 대표적인 헤더 몇가지를 예를 들어보겠습니다.
- Connection
- 클라이언트와 서버의 연결(Connection)을 지속할 것인지 마무리 할 것인지에 관한 정보
- Date
- 메시지의 생성날짜에 대한 날짜와 시간
- Via
- 메시지가 어떤 Proxy, Gateway를 통해 전달됬는지 명시
요청 헤더
// 요청 헤더
Host: sabatada.tistory.com
Connection: keep-alive
Cache-Control: max-age=0
...하략
요청 메시지에서만 의미를 가지는 헤더입니다. Accept 관련 헤더, 조건부(Condition) 요청 해더, 요청 보안 헤더, 프록시 헤더가 대표적입니다. 아래에 대표적인 헤더 몇가지를 예를 들어보겠습니다.
- Host
- 요청 대상이되는 서버의 호스트명과 포트 번호를 명시
- Accept
- 서버에거 클라이언트가 받을 수 있는 Content-Type을 명시
- If-None-Match
- 리소스의 ETag가 동일하지 않다면 신규 리소스를 전달 해달라는 요청, 동일하다면 304
- Authorization
- 클라이언트가 서버에 제공하는 인증 정보
- Max-Forwards
- 클라이언트로부터 시작하여 서버까지 넘어갈 수 있는 최대 홉(Hop) 수
응답 헤더
// 응답 헤더
Content-Type: text/html; charset=utf-8
Content-Length: 14058
Set-Cookie: TSSESSION_KEEP=1; ...
Vary: Accept-Encoding
...하략
응답 메시지에서만 의미를 가지는 헤더입니다. 협상(Negotiation) 헤더, 응답 보안 헤더, 캐시 관련 헤더가 대표적입니다. 아래에 대표적인 헤더 몇가지를 예를 들어보겠습니다.
- Server
- 서버의 어플리케이션의 버전과 이름
- Vary
- 서버가 확인해봐야할 클라이언트에 주는 메시지에 영향을 줄 수 있는 헤더의 목록
엔터티 헤더
엔터티 헤더는 본문(Body)과 관련된 헤더입니다. Body에 대한 정보를 기술하기 때문에 요청과 응답에 모두 올 수 있는 헤더입니다. 콘텐츠 헤더와 캐싱 헤더가 포함됩니다. 아래에 대표적인 헤더 몇가지를 예를 들어보겠습니다.
- Allow
- URL에 대해서 수행 가능한 HTTP Method를 나열
- Location
- 엔티티가 실제로 위치하고 있는 곳을 나타냄
- Content-Length
- 리소스의 길이나 키기
- Content-Encoding
- 본문에 적용된 인코딩
- ETag
- 엔터티를 통해서 만들어진 MD5 해싱 값
- Expired
- 엔터티가 더 이상 유효하지 않아 원본을 다시 받아와야하는 일시
본문 (Body)
본문은 http 메시지가 가지고 있는 실제 구체적인 내용입니다. text, json 메시지 뿐만 아니라 이미지, 비디오, HTML 문서 등 다양한 형식이 들어올 수 있습니다.
마무리
오늘은 이렇게 HTTP 메시지에 대해서 분석해보는 시간을 가져보았습니다.
다음 포스팅에서도 여러분들과 저에게 도움이되는 포스팅을 준비하도록 하겠습니다.
감사합니다.
참조
HTTP 완벽 가이드
'infra > network' 카테고리의 다른 글
[gRPC + java or kotlin] gRPC를 직접 구현재보자 - 공통 모델편 (0) | 2021.07.31 |
---|---|
[gRPC] protocol buffer3를 실제로 사용해보자 (0) | 2021.07.25 |
[gRPC] gRPC에 대해서 알아보자 - 기본 컨셉편 (0) | 2021.07.24 |
[HTTP] HTTP Cache - 프로세스와 기본 헤더 (2) | 2021.02.04 |
[REST API]REST를 사용할 때 주의해야할 점 (0) | 2019.08.04 |
댓글