Network - HTTP 살펴보기 (1) (Request / Response / Header)

 

updated 03/07/24

 

HTTP 프로토콜의 속성들을 두 포스팅으로 나눠 정리해보았다

오늘은 그 첫번째 포스팅이다. 공부해보도록 하자

 

 

1. HTTP 프로토콜의 구성요소인 요청 / 응답 / 헤더 의 이모저모 살펴보기

Network - HTTP 살펴보기 (1) (Request / Response / Header)

 

 

2. HTTP 프로토콜의 구성요소인 메소드 / 상태코드 이모저모 살펴보기

Network - HTTP 살펴보기(2) (Method / Status Code)

 

 

---

Network - HTTP 살펴보기 (1) (Request / Response / Header)

 

HTTP 는 HTML 과 같은 HyperText 문서를 주고 받기 위해 태어났다

그리고 HTML 뿐 아닌 api 통신에 이용되고 있는 네트워크 프로토콜이다

 

비연결성 → 연결이 계속 이어지는게 아닌 "요청보내고 응답 이후 연결 종료", 그래서 매 요청마다 연결을 맺는다
무상태성 → 프로토콜에서 클라이언트 상태를 기억하지 않음, 일단 넘기면 땡, 그래서 쿠키나 세션으로 데이터 저장

 

 

HTTP 통신을 할 때

클라이언트 🔛 서버가

요청(Request)과 응답(Response), 두 가지 방식으로 통신을 한다

 

편지를 주고 받을 때

편지봉투에 주소를 쓰는 양식이 있듯이 통신도 그들만의 양식을 따른다

통신 포맷은 Header - Body - Footer 의 구조로 보내줘야 한다

** 프로토콜 마다 다르지만 보통 (Body와 Footer를 빼놓더라도) Header는 꼭 보낸다.

 

 

내가 다시 눈여겨본 개념은

클라이언트는 요청만 보내고 서버는 반환값으로 응답을 돌려준다

 

그간 우리는 다양한 방법으로 API 테스트를 해왔는데 

포스트맨, 브라우저, curl (클라이언트가 서버에 요청을 보내는 명령어) 등을 관습적으로 사용해왔다

 

결국 HTTP 메소드 CRUD 이 녀석들은 ⭐️요 청⭐️ 을 위한 도구일 뿐이었다 (응답과는 전 - 혀 상관없음)

ARS 응답기처럼 번호를 누르면 응답이 나올 뿐

 

Request & Response

요청, 응답 메시지는  start-line + header + body  이렇게 구성되어있다

 

start-line

HTTP  메서드 / 프로토콜 버전 

으로 표시된다

 

header

요청 그 자체, 응답에 대한 요청, 인증, 접속 정보 등이 담겨 있다 

key와 value 로 구성되어 있다

 

body

메시지 전문이 들어간다

Header의 Content-Type 과 === body 의 타입을 맞춰야 한다(같은)

(GET과 DELETE 는 바디를 사용하지 ❎)

 

✔️ Request

curl -v https://devbirdfeet.tistory.com/

get 요청을 보냈을 때

post 요청을 보냈을 때

✔️ Response

다똑같은데 start-line 에 상태코드가 포함된다

 

curl -i https://devbirdfeet.tistory.com/

 

 

 

Header 살펴보기

General (일반 헤더)

• RequestURL : 클라이언트가 요청한 api 의 URL (이걸로 api 의 종류를 확인, param 값들이 맞게 들어가 있는지 확인)

• RequestMethod : 클라이언트가 요청한 통신 방식이 나온다. POST / GET / PUT / DELETE 

• Status Code : 통신 상태를 알 수 있다. (통신을 잘 주고 받았는지, 에러가 났으면 에러코드를 통해 어떤 종류의 에러인지 확인)

• Remote Address: 원격 주소를 말한다.

• Referrel Policy :  referrel policy 는 referrel url 이 어느정도까지 기록으로 남길지 노출 정책을 알수있다.

   ** referrel 은 링크로 웹 브라우저를 방문시 어디서 왔는지 남아있는 url 기록이다.

 

 

** Referrel Policy 의 종류 더 알아보기 (더보기클릭)

<meta name="referrer" content="no-referrer" />

referer를 남기지 않는 정책입니다.

 

<meta name="referrer" content="unsafe-url" />

조건 없이 주소를 남깁니다. 예를 들어: https://devbirdfeet.tistory.com/214 이라는 주소에서 다른 웹사이트로 이동한다면,  https://devbirdfeet.tistory.com/214 주소 전체를 남깁니다.

 

<meta name="referrer" content="origin" />

도메인 정보만 남깁니다. 예를 들어:  https://devbirdfeet.tistory.com/214 이라는 주소가 있으면https://devbirdfeet.tistory.com/ 까지만 전송합니다.

 

<meta name="referrer" content="strict-origin" />

이동하는 웹사이트의 주소가 https 일 때만 도메인 주소를 남깁니다. https://devbirdfeet.tistory.com/

 

<meta name="referrer" content="no-referrer-when-downgrade" />

이동하는 웹사이트 주소가 https 일 때 주소를 남깁니다.  https://devbirdfeet.tistory.com/214

 

<meta name="referrer" content="same-origin" />

웹사이트가 같을 때 주소를 남깁니다.

예를 들어: https://devbirdfeet.tistory.com/214 이라는 주소에서 다른 웹사이트로 이동한다면,  https://devbirdfeet.tistory.com/ 로 이동할 때만 주소를 남깁니다. https://naver.com 으로 이동한다면 주소를 남기지 않습니다.

 

<meta name="referrer" content="origin-when-cross-origin" />

웹사이트가 같을 때는 전체주소, 다를 때는 도메인 주소만 남깁니다.

 

<meta name="referrer" content="strict-origin-when-cross-origin" />

https를 사용하며 웹사이트가 같을 때는 전체주소, 다를 때는 도메인 주소만 남깁니다.

http를 사용하는 웹사이트에는 주소를 남기지 않습니다.

 

 

ref: https://scshim.tistory.com/entry/Referer-Policy%EC%9D%B4%EB%9E%80

 

 

Request Header (요청헤더)

클라이언트 → API 를 서버에 요청할때 보내주는 헤더이다

• Accept : 데이터를 어떤 타입으로 보내줬으면 좋겠는지

   ex) text/html(Html 텍스트), text/*(텍스트 와일드카드), application/json(json형식), image/*(이미지 와일드카드)

• Accept-encoding : 데이터를 어떤방식으로 압축할 건지

• Accept-language : 데이터를 어떤 언어로 보낼 건지

• Authorization : Beare(토큰 타입) + 토큰(사용자를 증명) 을 서버로 보낼때 사용한다.

  **Bearer OAuth나 JWT에 대한 접근을 위해 발급받는 자격증명 타입이다. 정보 교류나 회원인증을 위주로 사용

• Content-Length : 바이트 단위를 가지는 개체 본문의 크기 / 요청한 범위의 크기 (전체 이미지의 크기 x)

• Content-Range : 리소스의 전체 크기와 메시지가 어느 부분에 속하는지 알려 준다

• Content-Type : 리소스의 미디어 타입. 클라이언트가 서버에게 어떤 유형의 데이터가 실제로 전송했는지 알 수 있다.

• Origin : 클라이언트는 요청 헤더에 Origin이라는 필드에 요청이 시작된 url 를 보낸다. 

   **요청주소 !== 받는주소 다를 경우 CORS 에러가 발생한다.

   **서버에서 응답을 보내줄 때, 응답 헤더의 Access-Control-Allow-Origin에  “이 리소스를 접근하는 것이 허용된 URL”를

   내려주고, 이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교 후 유효한 응답인지 아닌지를 결정

 

• HOST: 서버의 도메인 네임이 들어간다

• Cookie: 클라이언트가 서버에게 쿠키를 보낼때 헤더에 담아보낸다. Cookie: key =  value 식으로 이루어져 있다.

• User-Agent: 현재 어떤 사용자가 어떤 운영체제와 브라우저를 이용해 요청을 보냈는지 알 수 있다.

• Referer: 바로 전에 있었던 페이지 주소가 담겨있다. 어떤 페이지에서 현재페이지로 이동했는지 알수있다.

• Cache-Control : 클라이언트와 프록시에 대한 HTTP 1.1 스펙에 따라 필요하다.

• Pragma : 오래된 클라이언트에 대한 HTTP 1.0 스펙에 따라 필요하다. no-cache 는 캐싱하지 않겠다는 의미이다

• X-Forwarded-For: 클라이언트의 IP 주소를 식별하는 데 사용

 

**Cache-Control (더보기 클릭)

클라이언트와 🔛 서버는 통신에시간과 에너지를 사용하며 데이터를 화면에 보여준다

BUT 이전에 받은 데이터와 새로 요청한 데이터가 같으면 이 과정은 낭비이다

낭비를 줄이기 위해 cache 정책을 사용하는데, 헤더에 Cache-Control을 사용하면 된다

Server는 부하를 줄이고, Client는 네트워크를 거치는 시간을 아낄 수 있다.

 

max-age

Cache-Control: max-age=604800 # 서버에서 응답 생성된 후의 시간
Age: 100 # 다른 루트에있는 캐시는 100초동안 응답을 저장, 브라우저 캐시는 100초를 뺌

 

no-cache

# 서버에서 보내준 데이터를 캐시에 저장하고, 원본 서버에서 연결이 끊어진 경우
# 원본 서버에서 응답의 유효성을 검사해야 재사용 가능하다
Cache-Control: no-cache

 

 must-revalidate

# 응답이 캐시에 저장되며, refresh(새로고침)을 해도 다시 사용가능, max-age 와 함께 사용
# HTTP는 서버와 연결이 끊기면 예전 데이터를 재사용할 수 있게 허용하는데 
# 이 친구를 사용하면 서버와 재검증해서 최신 데이터를 받아옴 (만약 실패하면 504 gateway timeout error가 발생)
Cache-Control: max-age=604800, must-revalidate

 

 

**X-Forwarded-For (더보기 클릭)

클라이언트의 IP 주소를 식별하는 데 사용된다

주로 프록시 서버나 로드 밸런서를 사용할 때 클라이언트의 원래 IP 주소를 전달하기 위해 사용된다

 

클라이언트가 서버에 직접 연결되면 클라이언트의 IP 주소가 → 서버로 전송된다

프록시 서버나 로드 밸런서를 거치며, 웹 서버는 클라이언트의 실제 IP 주소가 아닌 프록시 서버나 로드 밸런서의 IP 주소를 받게 됩니다.

 

# X-Forwarded-For: <클라이언트 IP 주소> <프록시1>, <프록시2>
# 요청이 여러 프록시를 통과하는 경우 각 연속 프록시의 IP 주소가 나열
# 가장 오른쪽 IP 주소는 가장 최근 프록시의 IP 주소이다 

X-Forwarded-For: client_ip, proxy1_ip, proxy2_ip

 

** User-Agent 자세히 알아보기 (더보기클릭)

요청 헤더에서 서버와 네트워크 피어가 요청하는 사용자 에이전트의 애플리케이션, 운영 체제, 공급업체 및/또는 버전을 식별할 수 있게 해주는 특성 문자열이다

 

아래와 같이 구성되어 있다

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

 

 

 

Response Header (응답 헤더)

얘는 좀더 심플하다

• Access-Control-Allow-Origin :  CORS 정책을 허용 여부를 알 수 있다. 요청헤더에서 Origin 을 보고 서버는 응답해준다.

  (* 이 들어가면 임의의 url 에서 접근이 가능하며 특정 url 을 명시하면 특정 url 에서만 접근 가능하다.)

• Content-Encoding : 아까 요청할때 Content-type 을 보고 서버는 파일을 인코딩해서 압축하여 다시 응답해준다.

• Content-Length : 바이트 단위를 가지는 개체 본문의 크기 / 요청한 범위의 크기 (전체 이미지의 크기 x)

• Content-Range : 리소스의 전체 크기와 메시지가 어느 부분에 속하는지 알려 준다

• Content-Type :  서버가 클라이언트에게 응답해준 컨텐츠의 유형이 실제로 무엇인지를 알려준다.

• Date : HTTP 메시지가 만들어진 시각

• Vary : 응답 헤더를 캐싱해놓고 다른 요청이 왔을 때 사용할 수 있는지 여부를 결정한다.

• Vary : Origin

  (* 이 들어가면 캐시할수없는  응답으로 간주  Cache-Control: no-store  가 더 명확하다. 헤더이름 이 들어가면 해당헤더를 캐시)

 

** Access-Control-Allow-Origin (더보기 클릭)

 

- Origin: 어떤 출처(도메인)에서 해당 리소스에 접근할 수 있는지를 지정한다.
- Methods: 실제 요청에 대해 허용된 HTTP 메서드(예: GET, POST)를 지정한다.
- Headers: 실제 요청에서 허용된 헤더를 지정한다.
- Credentials: 자격 증명이 요청에 포함될 수 있는지 여부를 나타낸다.

 

** Content-enoding 압축과정 알아보기 (더보기 클릭)

이 헤더는 미디어 타입을 압축하기 위해 사용한다. 그래서 어떤 컨텐츠의 인코딩이 적용될 지 값으로 넣어준다

Content-Type 의 미디어 타입을 얻도록 디코드하는 방법을 클라이언트가 알게 해준다

 

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

 

gzip 으로 압축하는 과정

1. 클라이언트는 헤더에 Accept-Encoding에 전송될 압축 스킴 목록을 넣어 서버로 보내준다

→ Accept-Encoding: gzip, deflate

 

2. 서버는 그걸 받아 Content-Encoding 응답 헤더에 표시하여 응답한다

→ Content-Encoding: gzip

 

** Content-Range 사용예제 (더보기 클릭)

Content-Range 는 서버에 특정 범위를 요청 할 때 사용한다 

Range 헤더를 사용하여 요청 범위를 지정할 수 있다. 그러면 서버는 문서의 일부분 만을 보내준다.

 

curl 로 테스트해본다

# curl을 사용하여 테스트
# "-H"는 HTTP요청의 헤더에 추가된다는 옵션 
# Range헤더로 첫 1024 바이트를 요청
curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"

 

 

요청을 보내면 아래와 같은 결과가 나온다 (일종의 영수증같은🤔)

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023 # 헤더에 옵션이 추가됨

 

 

서버에서 206 Partial Content 상태로 응답해준다

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515 # 응답 헤더에 포함되어 온다
Content-Length: 1024
...
(binary content)