Notice
Recent Posts
Recent Comments
Link
«   2025/01   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Archives
Today
Total
관리 메뉴

과거의 내가 미래의 나에게

HTTP 학습 (3) - HTTP 메시지 본문

CS

HTTP 학습 (3) - HTTP 메시지

양바삭 2023. 10. 27. 22:12

HTTP 프로토콜의 동작 원리에서 클라이언트가 HTTP 요청(리퀘스트) 메시지를 먼저 보내고, 서버가 그에 따른 결과(리스폰스)메시지를 보내준다고 했다. 이 때, 클라이언트와 서버는 서로 어떤 내용이 담긴 메시지를 보내주는 것일까? 오늘은 HTTP 메시지에 대해서 공부해보겠다.

 



0. 메시지 헤더 원문을 보기 위한 여정: 와이어샤크

 

HTTP 메시지를 살펴보기 앞서, 책이나 각종 글에 나와있는 HTTP 헤더 메시지 원문을 보고 싶었는데 개발자 도구로는 원문이 아니라 일부 요약된 듯한 내용만 있어서 이 원문을 찾느라 방황했다. 원래라면 이런 내용은 글의 주제에 벗어날 수 있으니 생략해야했지만 싸돌아다닌 시간이 억울해서 기록 겸 적어놓는다.

언급했 듯 개발자 도구에서는 대부분의 웹사이트에서는 헤더 메시지 원문을 볼 수 없었다. 그러나 HTTP 책에 있는 주소(http://hackr.jp)를 통해 보면 개발자 도구의 헤더 쪽에 raw를 체크하는 곳이 있어서 볼 수 있는게 아니겠는가! GPT로 그 이유를 물으니 개발자 도구 버젼, 서버 응답 구조 등등의 여부로 Raw Headers 옵션이 제공될 수도, 안될 수도 있다 한다. (여기까지 너무 깊게 파고들면 도저히 글을 시작할 수가 없어서 GPT에 한 번 물어보고 땡쳤다) 

 
세상 모든 통신에는 원시 헤더가 존재해야만 마땅한 것인데 그럼 이걸 내가 어떻게 볼 수 있느냐? 찾아보니 통신 패킷을 볼 수 있는 프로그램, 와이어샤크를 통해서 헤더 원문을 살펴볼 수 있었다.
와이어 샤크는 네트워크 패킷 캡처 및 분석 소프트웨어인데 각종 다양한 일을 할 수 있지만 나는 오로지 메시지 헤더의 원문을 보기 위함이었으니 다 관심없고(적어도 지금은) 어떻게든 설정을 맞춰 HTTP 헤더 메시지 원문을 얻어내는데 성공한다.

글의 중요 내용은 아니니 간단하게 리스트로 그 여정을 기록하고 넘어가도록 하겠다.

  1. 와이어샤크를 설치하고 무선이면 와이파이, 유선이면 유선에 따라 인터넷을 연결한다. 설치는 타 글을 살펴보는 것을 더 추천한다.
  2. 메뉴바의 Capture에서 Option을 선택한 뒤, 가장 아래  Capture filter~~interfaces를  "TCP or UDP port 80(HTTP):port 80"을 선택한 후 start를 눌러 패킷 감지를 시작한다
* 여러 패킷을 다 볼 수 있는데 HTTP(HTTPS가 아니다)과 관련된 패킷만 볼 수 있게끔 하는 필터 설정인 듯 하다.
  3. 아이콘 바에 있는 돋보기를 클릭하여 "tcp.stream eq 0"라는 필터를 적용시킨다.
  4. http 주소(사용한 거:http://kostat.go.kr)를 웹 브라우저에 검색하여 관련 패킷을 캡쳐해낸다.
  5. 프로토콜이 HTTP이고 클라이언트에서 요청한 패킷을 찾아서 클릭한다.
* 참고로 TCP의 3 handShake후 HTTP 프로토콜이 전달되는 모습도 다 보여서 후에 또 다시 와이어샤크를 찾아올 것 같다.
  6. 아래에 Hypertext Tranfer Protocal을 클릭하여 헤더 원문을 본다!
  6-1. 혹은 패킷을 오른쪽 클릭하여 Follow > HTTP Stream을 클릭하면 리퀘스트, 리스폰스 메시지를 모두 볼 수 있다.

 

http://kostat.go.kr 통계청 주소를 쳐서 나온 결과


기껏 와이어샤크로 메시지 원문을 찾았지만 원활한 학습을 위해 http://hackr.jp의 메시지 원문을 보며 진행할 것이다.

 

 

1. HTTP 메시지 구조

 

 [ 메시지 헤더(시작 라인 ,헤더) ] 

엔티티 헤더라고 하며 이곳에 메시지 바디의 내용을 해석할 때 필요한 모든 부가 정보가 담긴다.
 [ 개행 문자 ] 

 HTTP 메시지는 여러 줄의 데이터로 구성된 텍스트 문자열인데 이를 크게 구분하자면 헤더와 바디로 구성되어있고, 최초로 나타내는 개행 문자를 통해 이 헤더와 바디를 구분할 수 있다.
 [ 메시지 바디 ]

 메시지 바디 안에 엔티티 본문을 넣어 보낸다.

 

< 참조 >
엔티티라는 단어를 쓰는 것은 1999년에 나왔던 RFC2616까지 였다. 2014년에 RFC7230~7235가 등장하면서 RFC2616은 폐기됨으로 몇가지 용어가 바뀌었다. (엔티티 헤더->표현 헤더/엔티티 바디->표현 데이터/메시지 본문->페이로드...)
그렇지만 이 글을 서론글에서 말했던 책을 기준으로 하기에 계속해서 엔티티라는 표현을 할 것이다.

 

 

 

2. 시작 라인

 

모든 HTTP 메시지의 첫 줄은 시작 라인으로 구성되어있으며 실행되어야 할 요청 또는 요청 수행에 대한 성공 또는 실패가 기록되어있다. 이 줄은 항상 한 줄로 끝나게 된다.

 

1. 요청 메시지에서의 시작 라인

GET /resource HTTP/1.1

HTTP Method, 요청 URL, HTTP 버전으로 이루어져 있고 리퀘스트 라인이라고 부른다.

 

■ HTTP Method: 서버에 특정 행동을 요청한다고 알려주는 부분으로 주어진 리소스에 수행하길 원하는 행동을 나타낸다. 예를 들어 GET Method는 리소스를 클라이언트로 가져다 달라는 것을 뜻하며, post는 데이터가 서버로 들어가야함을 의미한다. 상세한 내용은 따로 글을 정리해서 올릴 예정이다.


■ 요청 URL: 요청 대상 리소스를 가리키는 경로를 나타낸다. 형식으로는 Origin 형식, absolute 형식,  authority 형식, asterisk 형식이 있다.

< 참조 >
Origin 형식: GET /resource HTTP/1.1
-> 상대 경로 정보를 사용하여 보내는 형식으로 가장 일반적인 형식이다. 여러 method와 같이 쓸 수 있다.

absolute 형식: GET http://example.com:80/resource HTTP/1.1
-> 절대 URL을 사용하여 보내는 형식이다. 이 형식을 사용하는 것은 프록시 서버가 중간에 있는 경우에 사용된다는데 이 경우 주로 GET Method와 같이 쓰인다.

authority 형식: GET example.com:80 HTTP/1.1
-> 도메인 이름과 포트번호로 이루어져있으며, 이는 특정 서버를 가리킴으로서 웹 서버의 위치를 나타내는 데 사용한다.

asterisk 형식: OPTIONS * HTTP/1.1
-> OPTION Method와 함께 사용되며 별표(*)를 사용하여 서버 전체를 나타낸다.


■ HTTP 버젼: 사용하는 HTTP 버젼을 알려주는 것으로 응답 메시지에서 써야할 HTTP 버젼을 알려주는 것이다.

 

 

2. 응답 메시지에서의 시작 라인

HTTP/1.1 200 OK

HTTP 버젼, 상태 코드, 상태 텍스트로 이루어져있고 상태 라인이라고 부른다.

 

■ HTTP 버젼: 사용한 HTTP 버젼을 알려준다.


■ 상태 코드: 클라이언트가 서버로 요청한 일이 어떻게 마무리 되었는지 알려주는 코드이다. 코드는 3자리의 숫자로 나타내며 종류에 대해서는 추후 따로 정리해서 글을 올릴 예정이다.


■ 상태 텍스트: 사람이 HTTP를 이해할 때 도움이 될 수 있도록 상태코드에 대한 정보를 제공해주는 텍스트이다.

 

 

 

3. HTTP 헤더 필드

 

1. 헤더 필드 개요

리퀘스트 시, 요청에 대한 설명 그리고 리스폰스 시, 메시지 본문에 대한 설명이 들어가며 중요한 정보를 전달하는 역할을 한다. 
헤더 필드는 [헤더 필드 명: 필드 값]으로 구성되어 있으며 하나의 필드에는 여러 개의 필드 값이 들어갈 수 있다.
또한 각 헤더 필드는 end to end 혹은 hop by hop 형태로 구분된다. 

 

■ end to end 

end to end 형태의 헤더 필드는 클라이언트와 서버 사이를 이동하는 과정에서 거쳐야 하는 각 중간 단계(프록시 서버, 게이트웨이, 캐시 서버 등 다양한 네트워크 요소)에서 수정되지 않고, 있는 그대로 최종 목적지에 도달하는 것으로, 정보 전달을 그 목적으로 한다.

< 참조 >
HTTP는 클라이언트와 서버 사이에 프록시 서버나 캐시 서버같은 중간에 껴들어간 서버가 놓이는 것을 허락한다. HTTP 메시지는 이 중간 서버들을 거치면서 전달되는 것이다.


hop by hop 
hop by hop 형태의 헤더 필드에서 hop은 각 중간 단계들 그 자체를 의미하며, 이 형태의 헤더 필드는 홉과 홉 사이에서만 전달되고 다음 홉으로 전달되지 않는다. 즉, 이는 중간 단계에서만 활용되고 최종 목적지에서는 전달되지 않는 필드인 것이다. 

< 참조 >
Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, Trailer, TE, Transfer-Encoding, Upgrade 외의 모든 헤더 필드는 end to end 형태이다.

 

 

2. 헤더 필드 종류

헤더 필드는 4가지 종류로 구분된다.

 

1) 일반적인 헤더 필드

리퀘스트 메시지와 리스폰스 메시지 둘 모두에서 사용되는 헤더이다. 요청과 응답에 상관없이 메시지 전체에 영향을 주는 헤더이다.

→ 헤더 종류: https://yangstorage.tistory.com/69

 

2) 리퀘스트 헤더 필드

리퀘스트 메시지에 사용되는 헤더로, 리퀘스트의 부가적 정보와 클라이언트의 정보, 리스폰스의 콘텐츠에 관한 우선 순위 등을 부가한다.

헤더 종류: https://yangstorage.tistory.com/71

 

3) 리스폰스 헤더 필드

리스폰스 메시지에 사용되는 헤더로, 리스폰스의 정보와 서버의 정보, 클라이언트의 추가 정보 요구 등을 부가한다.

헤더 종류https://yangstorage.tistory.com/72

 

4) 엔티티 헤더 필드

리퀘스트 메시지와 리스폰스 메시지에 포함된 엔티티에 사용되는 헤더로, 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가한다.

헤더 종류https://yangstorage.tistory.com/74

 

 

 

3. 메시지 바디

HTTP 메시지가 가지고 있는 실체 구체적인 내용이다. 
HTTP 메시지 바디의 역할은 리퀘스트 혹은 리스폰스에 관한 엔티티 바디(실제 정보)를 운반하는 일이다. 기본적으로 메시지 바디와 엔티티 바디는 일치하지만, 전송 방식에 대한 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 대문에 메시지 바디와 달라진다고 한다.


엔티티 바디는 서버에서 데이터를 가져와 그대로 실어나를 수도 있지만, 통신 효율을 높이거나 더 다양하고 많은 데이터를 전송할 수 있기 위해 다양한 기법을 사용하여 그 성능을 향상시키고 있다.
예를 들어 전송 효율을 높여주는 Encoding이나 Range request, Content Negotiation같은 기술이 있고, 여러 유형의 데이터를 하나의 메시지로 포함시키기 위해 Multi-part 기법이 있기도 하다.

 

 

 

 

 


참고 문서

 

 

 



 

'CS' 카테고리의 다른 글

HTTP 학습 (3-2) - 요청 헤더 필드  (0) 2023.11.18
HTTP 학습 (3-1) - 일반 헤더 필드  (0) 2023.11.01
HTTP 학습 (2) - 동작 과정과 특징  (0) 2023.10.22
HTTP 학습(1)  (0) 2023.10.15
Domain Name System 학습(3)  (0) 2023.08.12
Comments