프론트엔드Explorer

HTTP에 보안처리(SSL)가 된 버전이 HTTPS이다. (요즘은 HTTPS가 웹의 기본 스펙이라고 봐도 무방함)

HTTPS는 기존 HTTP 레이어에서 SSL 또는 TLS 프로토콜을 얹어 평문 데이터를 암호화하고,  

암호화, 인증, 그리고 무결성 보장을 통해 더 안전히 만들어주는 프로토콜이다. 

SSL과 TLS

SSL(Secure Sockets Layer)은 TLS(Transport Layer Security)의 과거 명칭이라고 봐도 무방하다. 

TLS는 SSL 3.0을 기초로 해서 IETF가 만든 프로토콜이다. 

TLS는 SSL 3.0을 보다 안전하게 하고, 프로토콜의 스펙을 더 정확하게 안정성을 높이는 목적으로 고안하였다. 

SSL이나 TLS를 통해 평문을 암호화하고, 복호화할 때,

대칭키나 공개키 방식을 사용하는데 이에 대해 알아보자. 

대칭키

대칭키 암호화 방식은 집 열쇠와 같다고 생각하면 된다. 

대칭키를 가지고 데이터를 암호화하고, 또 대칭키로 데이터를 복호화한다. 

예를 들어 'abc'라는 키로 데이터를 암호화했다면, 데이터를 복호화하기 위해서는 반드시 'abc' 키가 필요하다. 

즉, 클라이언트와 서버가 대칭키 방식으로 통신을 한다면, 클라이언트도 키를 가지고 있어야 한다. 

그런데 대칭키 방식은 치명적인 단점이 있다. 

암호를 주고 받는 사이에서 대칭키를 전달하는 것이 어렵고, 

만약, 중간에 대칭키가 탈취 또는 유출되면 그 키로 암호화 되었던 데이터들은 모두 유출된다. 

즉, 원거리에서 대칭키를 안전하게 전달하는 것은 매우 어렵다. 

이러한 대칭키의 단점을 극복하고자 나온 방식이 공개키 방식(PKI, Public Key Infrastructure)이다.

공개키(비대칭키)

공개키 방식은 공개키와 개인키(비밀키)라는 2가지의 비대칭키를 가진다. 

만약, A키로 암호화하면 B키로 복호화 가능하며, 반대로 B키로 암호화하면 A키로 복호화가 가능하다. 

A와 B 중 하나는 공개키(public key)가 되고, 나머지 하나는 비공개키(private key)가 된다. 

비공개키는 소유자, 즉, private한 사용자가 가지고 있게 되며, 

공개키는 소유자와 타인에게 공개되는 키이다. 

타인이 공개키를 이용하여 데이터를 암호화해 소유자에게 전달하면, 

소유자는 비공캐기로 복호화하여 그 데이터를 얻을 수 있게 된다. 

이 방식은 안전하게 데이터를 주고받을 수 있게 만들어주지만, 속도가 느리다는 단점이 있다. 

전자서명

비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 한 후에 공개키와 함께 암호화된 정보를 전송한다. 

정보와 공개키를 획득한 사람은, 공개키를 이용해 암호화된 정보를 복호화한다. 

이 과정에서 공개키가 유출된다면 의도하지 않은 공격자에 의해 데이터가 복호화될 위험이 있다. 

이런 위험에도 불구하고 비공개키를 이용해 암호화를 하는 이유가 뭘까? 

비공개키는 데이터를 보호하는 것이 목적이 아니다. 

암호화된 데이터를 공개키를 가지고 복호화할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화되었다는 것을 의미한다. 

즉, 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것이다. 이러한 것을 전자서명이라고 부른다.

SSL 인증서와 CA(Certificate Authority)

SSL을 적용하기 위해서는 인증서가 필요하다. 

SSL 인증서는 아래의 2가지를 제공한다. 

• 클라이언트가 접속한 서버가 신뢰 있는 서버임을 증명(인증서 발급 CA, 도메인 등)한다. 즉, 클라이언트가 접속한 서버가 클라이언트가 목적한 서버가 맞는지 확인한다. 
• SSL 통신에 사용될 공개키를 클라이언트에 제공(서버 공개키)한다. 서버와 클라이언트가 통신할 때 사용될 공개키와 공개키 암호화 방법들의 정보가 있다. 

CA는 이 SSL 인증서를 발급해주는 기업이다. 

인증서가 보안에 관련된 것인만큼 CA는 신뢰할 수 있는 기업에서만 가능하다. 

SSL 인증서 및 내용은 CA에 의해서 암호화된다. 이때 CA는 자신의 비공개키로 서버가 제출한 인증서를 암호화한다. 

CA의 비공개키는 절대로 유출되어서는 안되며, 실제로 디지노타라는 회사에서 CA의 비공개키가 유출된 사례가 있어 CA 자체가 파산된 경우도 있다고 한다. 

브라우저와 CA

브라우저는 내부적으로 CA의 리스트를 미리 알고 있다. 

즉, 브라우저 소스 안에 CA 리스트가 존재한다는 말이다. 

CA 리스트 뿐만 아니라, 각 CA의 공개키도 이미 브라우저 안에 내장되어 있다. 

브라우저가 서버에 접속할 때, 서버는 클라이언트에게 인증서를 제공한다. 

브라우저는 서버에서 받은 인증서가 자신이 가지고 있는 CA 리스트에 있나 확인을 한다. 

비교 후 정상적인 인증서이면, 해당 CA의 공개키(브라우저 안에 있는)를 이용하여, 인증서를 복호화한다. 

복호화가 됐다면, 그 인증서는 CA의 비공개키로 암호화된 것을 의미한다.

즉, 해당 CA에 의해 정상적으로 발급된 인증서라는 의미가 되며, 그것은 클라이언트가 접속한 서버에서 제공한 인증서가 해당 CA에 의해 정상적으로 발급됐다는 의미이다. 

=> 클라이언트가 접속한 서버에서 받은 인증서가 CA에서 정상적으로 발급된 인증서이다. 

다음 포스팅에서는 HTTPS의 동작 원리에 대해 알아보도록 하자. 

https://dolphinsarah.tistory.com/53

HTTP 2.0이라고도 불리는 HTTP/2는 Hypertext Transfer Protocol Version 2의 약자이다. 

2015년 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구, 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 작업 기구)에 의해 공식적으로 발표된 HTTP/1.1(기존 표준)의 차기 버전이다. 

HTTP/1.x이 느린 이유

HTTP/1.x이 느린 이유, 바꿔 말하면 HTTP 2.0이 등장하게 된 배경은 아래와 같다. 

위의 사진만 봐도 알 수 있듯, HTTP 1.0버전대만 하더라도, Request를 날릴 때마다 Connection을 새로 생성했다. 

Short-lived connections는 너무 비효율적이어서, HTTP 1.1에서는 Persistent Connection이라는 개념과 HTTP Pipelining이라는 개념이 만들어졌다. 

커넥션을 재사용할 수 있고, request를 미리 여러 개 서버에 날릴수도 있게 되었다. 

그러나 이러한 개선에도 불구하고, request를 보낸 순서대로 response를 받을 수 있다는 지점에서 문제가 발생했다. 

HOL(Head of line) blocking (특정 응답 지연)

만약, 처음에 요청한 request에 문제가 발생해 응답이 늦어질 경우, 

2번째, 3번째에 요청한 request의 응답도 같이 늦어진다는 문제점이 발생한다. 

RTT(Round Trip Time) 증가 (양방향 지연) 

Round Trip Time은 네트워크 시작 지점에서 대상 지점으로 이동하고 시작 지점으로 다시 이동하는 데 걸리는 시간이다. 

앞서 말한 것처럼 매 요청별로 connection을 만들게 되고, TCP 상에서 동작하는 HTTP의 특성상 3-way-Handshake가 반복적으로 일어나게 되며, 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 저하시키게 된다. 

무거운 헤더(특히 쿠키)

HTTP 1.x의 헤더에는 많은 메타 정보들이 저장되어 있다. 

사용자가 방문한 웹페이지는 다수의 http 요청이 발생하게 되는데, 이 경우 매 요청마다 중복된 헤더 값을 전송하게 되며, 각 도메인에 설정된 쿠키 정보도 매 요청마다 헤더에 포함되어 전송된다. (전송값보다 헤더가 더 큰 경우도 있다) 

문제점들을 해결하기 위한 UI & 프론트엔드 개발자의 노력

• 이미지 스프라이트 
  • 여러 개의 이미지를 하나의 이미지로 합쳐서 관리하는 이미지(사용할 때는 좌표 범위로 구분해 사용)

• 도메인 샤딩
  • 리소스를 여러 개의 도메인으로 나누어 저장하여, 페이지 로드 시간을 빠르게 하는 일종의 트릭 혹은 방법
  • 여러 개의 도메인으로 나누어진 리소스를 다운받기 때문에 브라우저는 더 많은 리소스를 한 번에 받을 수 있다. 
  • 최신 브라우저들은 보통 한 도메인에 약 6개의 동시 다운로드를 제공한다. 
  • 이 개수를 초과하는 페이지의 경우, 초과하는 개수를 6으로 나눈 도메인에 리소를 뿌려두면, 병렬적으로 리소스들을 다운 받을 수 있다. 

• CSS/JavaScript 압축
• Data URI

HTTP 2.0의 등장 

SPDY

구글은 더 빠른 WEB을 실형하기 위해 Latency 관점에서 HTTP를 고속화한 SPDY라 불리는 새 프로토콜을 만들었다. 

SPDY는 HTTP를 대치하는 프로토콜이 아니라, HTTP를 통한 전송을 재정의하는 형태로 만들어졌다. 

SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고, 이는 HTTP/2.0 초안의 참고 규격이 되었다. 

HTTP 2.0은 완전히 새로운 프로토콜이 아니라 SPDY의 개선사항을 적용해 성능 향상에 초점을 맞춘 프로토콜이라고 생각하면 될 것 같다. 

HTTP 2.0이 빠른 이유 

1. Multiplexed Streams - 한 커넥션에 여러개의 메시지를 동시에 주고받을 수 있고, 응답은 순서에 상관없이 stream으로 주고 받는다. 
2. 요청이 커넥션 상에서 다중화되므로 HOL(Head Of Line) Blocking이 발생하지 않음 
3. Stream Prioritization(요청 리소스 간 의존관계를 설정) - 클라이언트가 요청한 HTML 문서 안에 CSS 파일 1개와 Image 파일 2개가 존재하고, 이를 클라이언트가 각각 요청한 후, Image 파일 보다 CSS 파일의 수신이 늦어지는 경우, 브라우저의 렌더링이 늦어지는 문제가 발생한다. HTTP/2의 경우 리소스 간 의존 관계(우선 순위)를 설정해 이런 문제를 해결했다. 
4. Header Compression(Header 정보를 HPACK 압축 방식을 이용하여 압축 전송) - HTTP/2에서는 Header에 중복값이 존재하는 경우, Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고, 중복된 Header는 index 값만 전송하고 중복되지 않은 Header 정보의 값은 Huffman Encoding 기법으로 인코딩 처리하여 전송한다. 
5. Server Push(HTML 문서 상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음) - 클라이언트가 HTML 문서를 요청하고 해당 HTML에 여러 개의 리소스(CSS, Image,...)가 포함되어 있는 경우, HTTP/1.1에서는 클라이언트는 요청한 HTML 문서를 수신한 후, HTML 문서를 해석하면서 필요한 리소스를 재요청하는 반면, HTTP/2에서는 Server Push 기법을 통해 클라이언트가 요청하지 않은 리소스를 push해주는 방법으로 클라이언트의 요청을 최소화하여 성능 향상을 이끌어냈다. PUSH_PROMISE라고 부르며, PUSH_PROMISE를 통해 서버가 전송한 리소스에 대해서 클라이언트는 요청하지 않는다. 
6. 프로토콜 협상 메커니즘 - 프로토콜 선택. like HTTP / 1.1, HTTP / 2 또는 기타 
7. HTTP / 1.1과의 높은 수준의 호환성 - 메소드, 상태코드, URI 및 헤더 필드
8. 페이지 로딩 속도 향상

하지만, HTTP/2는 여전히 TCP를 이용하기 때문에 HandShake의 RTT(Round Trip Time)로 인한 Latency(지연 시간), TCP의 HOL Blocking은 해결할 수 없다. 

그래서 HTTP/3가 등장했다. 

다음 포스팅에서는 HTTP/3에 대해 알아보자. 

이번 포스팅에서는 X-로 시작하는 헤더에 대해 알아보자. 

X-로 시작하는 헤더들은 어떤 의미를 가지고 있을까? 

예전에는 사용자가 임의로 헤더를 정의할 때, 사용자가 정의한 헤더라는 것을 알려주고자

앞에 X-를 붙이곤 했다. 하지만 2012년에 임의라는 의미는 이미 사라졌다. 

이제는 사용자 정의 헤더도 X-를 앞에 붙이지 않아도 된다. (하지만 많은 사람들, 심지어 구글마저 습관적으로 X를 앞에 붙인다고 한다) 

지금은 아니라도 예전에 규칙이었기 때문에 X-를 붙인 헤더들을 많이 볼 수가 있다. 

그 중 몇 헤더들은 너무 널리 쓰여서, 사실상 표준 헤더가 되어 버렸다. 

X- 규칙은 사라졌지만, X-가 앞에 붙은 헤더들 중 유명한 것들은 알아두는 게 좋다. 

X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto

요청이 어디서부터 건너왔는지 알려주는 헤더이다. 

실제 세상에서는 클라이언트(요청)-서버(응답)와 같은 2단 구조보다는,

클라이언트(요청)-중개 서버-중개 서버- ... -최종 서버(응답) 과 같은 다단 구조가 더 많다. 

이 때, 중개 서버를 거치면서 헤더들이 변조되고, 요청을 누가 보냈는지 애매해지기도 한다. 

X-Forwarded 헤더 시리즈는 원래 요청이 누구였는지를 밝혀준다. 

(물론 이것도 조작할 수 있으니 완전히 믿어서는 안 된다.)

X-Forwarded-For: 1.2.3.4, 5.6.7.8, 9.10.11.12
X-Forwarded-Host: www.abc.com
X-Forwarded-Proto: https

For는 현재까지 거쳐온 서버의 IP에 대한 정보를 가지고 있다. 

1.2.3.4가 원래 서버 IP라면 나머지는 중개 서버 IP가 된다. 

Host는 원래 서버의 호스트 명이고, Proto는 원래 서버의 프로토콜이 된다. 

사실, Forwarded 헤더가 표준 헤더이다. 위 세 가지를 모두 처리할 수 있다. 

Forwarded: for=1.2.3.4; host=www.abc.com; proto=https; by=5.6.7.8, 9.10.11.12

X-Frame-Options

frame, iframe, object 태그 안에서 페이지를 렌더링하는 것을 막을 수 있다. 

내 사이트가 frame, iframe, object를 안 쓴 다면 아래처럼 막아두는 게 보안에 좋다. 

클릭재킹(내가 무언가를 눌렀는데, 실제로는 그게 아니라 다른 게 눌리는 해킹 방법)을 막을 수 있다고 한다. 

X-Frame-Options: DENY

만약, 내 사이트 자체를 iframe 등으로 불러오는 경우에는 아래처럼 자신의 페이지를 불러오는 것은 허용할 수 있다. 

X-Frame-Options: SAMEORIGIN

특정한 사이트를 불러오는 것만 허용하고 싶다면 아래와 같이 명시해주면 된다. 

X-Frame-Options: ALLOW-FROM https://www.zerocho.com

X-Content-Type-Options

서버에서 보내온 Content-Type 헤더가 잘못 설정되었다고 생각하는 경우, 

브라우저는 자체적으로 컨텐츠 타입을 추론한다. 

예를 들어, 분명히 css 파일인데 Content-Type 헤더가 text/html인 경우, 

브라우저가 text/css로 추론할 수도 있다는 뜻이다. 

하지만 이런 임의적 행동은 예상치 못한 행동이기 때문에 위험할 수 있다. 

그럴 때는 아래와 같은 헤더를 서버에 보내주어, 브라우저가 서버가 보낸 컨텐츠 타입을 따르게 강제할 수도 있다. 

X-Content-Type-Options: nosniff

이 포스팅은 아래 링크를 참고하여 작성하였습니다.

https://www.zerocho.com/category/HTTP/post/5b611b9e33b4636aa8bb1fc4

이번 포스팅에서는 쿠키와 캐시 헤더만 따로 알아보도록 하자. 

웹 자원을 효율적으로 사용하기 위해서는 캐싱이 중요하다. 

똑같은 데이터를 계속해서 내려 받을 필요는 없다. 

쿠키는 클라이언트(프론트)와 서버 간에 데이터를 주고받는 가장 간단한 방법 중 하나이다. 

이것들에 대한 설정을 헤더를 통해 할 수 있다. 

쿠키나 캐시에 대한 정보는 개발자 도구의 Application 탭에서 쉽게 확인할 수 있다. 

캐시

여기서 말하는 캐시는 개인 캐시를 뜻한다. CDN 같은 공유 캐시가 아니라. 

내 브라우저에 응답으로 온 HTML이나 JSON 같은 데이터가 저장되어, 나중에 서버에 요청을 보내지 않고도 브라우저에 저장된 응답을 사용할 수 있다. 

보통 캐싱은 GET 요청에만 한다. 가져온 데이터를 저장해두고 두고두고 쓰는 것이다. 

일반적으로 200(가져오기 성공), 301(다른 주소로 이동 후 가져옴), 404(가져올 게 없음) 상태 코드로 온 응답을 캐싱할 수 있다. 

Cache-Control

많은 옵션들이 있지만, 자주 쓰이는 옵션만 알아보자. 

먼저, 아무것도 캐싱하지 않으려면 아래처럼 하면 된다. 

Cache-Control: no-store

아래는 가장 많이 헷갈려하는 헤더 설정이다. 

Cache-Control: no-cache

no-cache지만 cache하지 말라는 뜻이 아니다! 

모든 캐시를 쓰기 전에 서버에 이 캐시 써도 되는지 물어보라는 뜻이다. 

must-revalidate는 만료된 캐시만 서버에 확인받도록 하는 것이다.

Cache-Control: must-revalidate

public이면 공유 캐시(또는 중개 서버)에 저장해도 된다는 뜻이고, 

private이면 브라우저 같은 특정 사용자 환경에만 저장하라는 뜻이다. 

Cache-Control: public 또는 private

max-age로 캐시 유효시간을 줄 수 있다. 초 단위이므로 아래 예제는 1시간이다. 

1시간이 지나면 이 응답 캐시는 만료된 것으로 여겨진다. 

Cache-Control: public, max-age=3600

참고로, 위의 옵션들은 혼합해서 써도 된다. 

no-store, no-cache, must-revalidate처럼 콤마로만 구분하면 된다. 

Cache-Control을 응답 헤더라고 생각할 수도 있는데, 요청 헤더로도 사용할 수 있다. 

프론트 - 중개 서버 - 진짜 서버와 같은 구조인 경우에, 중개 서버에 있는 캐시를 가져오지 않도록 하려면

요청 시부터 Cache-Control을 헤더로 넣어주곤 한다. 

Age

Age 헤더는 캐시 응답 때 나타나는데, max-age 시간 내에서 얼마나 흘렀는지를 초 단위로 알려준다. 

위 예제에서 max-age=3600을 설정한 경우, 1분이 지나면 아래와 같이 캐시 응답 헤더에 포함된다. 

Age: 60

Expires

Cache-Conrol과 별개로 응답에 Expires라는 헤더를 줄 수도 있다. 

응답 컨텐츠가 언제 만료되는지를 나타내며, Cach-Control의 max-age가 있는 경우,

이 헤더는 무시된다. 

Expires: Thu, 28 May 2021 07:28:00 GMT

ETag

HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그이다. 

같은 주소의 자원이더라도, 컨텐츠가 달라졌다면 ETag가 다르다. 

예를 들어, GET www.abc.com의 응답 본문이 안녕 html이고, ETag 헤더 값이 12345라 하자. 

만약, 서버 컨텐츠(응답 본문)가 동일하다면 매번 www.abc.com을 할 때마다 ETag는 12345다. 

그런데 안녕 html에서 안녕 javascript로 컨텐츠가 바뀌었다면 ETag 헤더 값도 34567로 바뀐다. 

그러면, 서버가 클라이언트의 응답 내용이 달라졌구나를 깨닫게 되어, 

캐시를 지우고 새로 컨텐츠를 내려받을 수 있게 된다. 

Etag: W/"3bf2-wdj3VvN8/CvXVgafkI30/TyczHk"

If-None-Match

서버에게 ETag가 달라졌는지 검사해 ETag가 다를 경우에만 컨텐츠를 새로 내려주라는 뜻이다. 

만약, ETag가 같다면 서버는 304 Not Modified를 응답해서 캐시를 그대로 사용하게 된다. 

If-None-Match: W/"3bf2-wdj3VvN8/CvXVgafkI30/TyczHk"

쿠키

쿠키는 브라우저에 저장되는 작은 데이터 조각으로, 임시 데이터 보관 또는 웹페이지 개인화 등에 사용된다. 쿠키를 주기적으로 지우지 않으면 브라우저에 엄청나게 많은 쿠키들이 쌓여있는 것을 볼 수 있는데, 이것들이 우리를 추적하고 있는 것이다. 

Set-Cookie

서버에서 클라이언트(브라우저)한테 xx 쿠키를 저장하라고 명령하는 응답 헤더이다. 

Set-Cookie: 키=값; 옵션들

Set-Cookie: hello=dolphin이면 hello라는 키에 값을 dolphin으로 해서 보낼 수 있는 것이다. 

옵션도 몇 개 알아보자. 

• Expires: 쿠키 만료 날짜를 알려줄  수 있다.
• Max-Age: 쿠키 수명을 알려줄 수 있다. Expires는 무시된다. 
• Secure: https에서만 쿠키가 전송된다. 
• HttpOnly: 자바스크립트에서는 쿠키에 접근할 수 없다. XSS 요청을 막으려면 활성화해두는 것이 좋다.
• Domain: 도메인을 적어주면, 도메인이 일치하는 요청에서만 쿠키가 전송된다. 가끔, 도메인이 다른 쿠키들이 있는데, 이런 쿠키들은 써드 파티 쿠키로 우리를 추적하고 있는 쿠키다. 구글이나 페이스북 같은 곳은 써드 파티 쿠키를 적극적으로 사용한다. 
• Path: path를 적어주면 이 path와 일치하는 요청에서만 쿠키가 전송된다. 

예를 들면, 다음과 같이 가능하다. 

Set-Cookie: dolphin=sarah; Expires=Wed, 2 June 2021 07:28:00 GMT; Secure; HttpOnly

쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에, HttpOnly 옵션을 켜두고, 

쿠키를 사용하는 요청은 서버 단에서 검증하는 로직을 꼭 마련해두는 게 좋다. 

Cookie

반대로 클라이언트가 서버에게 쿠키를 보내줄 때는 이 요청 헤더에 담아 보낸다. 

Cookie: 키=값; 키=값;

서버는 이 쿠키 헤더를 파싱해서 사용한다. 

아까도 언급했듯, CSRF 공격 같은 것을 막기 위해서 서버는 반드시 쿠키가 제대로 된 상황에서 온 것인지 확인하는 로직을 갖춰야 한다. 

이렇게 캐시와 쿠키에 관련된 헤더를 알아보았다. 

보통은 알아서 세팅하는 캐시와 쿠키를 사용하지만, 직접 수정해야 할 때도 있으니 그 때 참고하면 좋을 것 같다. 

이 포스팅은 아래 링크를 참고하여 작성하였습니다.

https://www.zerocho.com/category/HTTP/post/5b594dd3c06fa2001b89feb9

이번 포스팅에서는 HTTP 응답 헤더에 대해 알아보자. 

(지난 HTTP 공통 헤더, 요청 헤더 포스팅과 이어집니다.)

2021.05.27 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 공통 헤더와 요청 헤더

응답 헤더 

Access-Control-Allow-Origin

프론트엔드 개발자들이라면 많이 보았을 헤더이다. 프론트 주소와 백엔드 주소가 다르면 CORS 에러가 발생하는데,

이때 서버에서 응답 메시지 Access-Control-Allow-Origin 헤더에 프론트 주소를 적어줘야 에러가 나지 않는다. 

프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다. 

만약, 주소를 일일이 지정하기 싫다면 위처럼 *으로 모든 주소에 CORS 요청을 허용하면 된다.

단, 그만큼 보안이 취약해진다. 

유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다. 

CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다.

이때, Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고, 

Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다. 

Allow들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다.

Request와 Allow가 일치하면 CORS 요청이 이루어지는 것이다. 

Allow

Allow 헤더는 Access-Control-Allow-Methods와 비슷하지만, CORS 요청 외에도 적용된다는 것에 차이가 있다.

즉, GET은 되고, POST는 허용하지 않는 경우, 405 Method Not Allowed 에러를 응답하면서 헤더로 아래와 같이 보내면 된다. GET 요청만 받겠다는 뜻이다. 

Allow: GET

Content-Disposition

응답 본문을 브라우저가 어떻게 표시해야 할지 알려주는 헤더이다. 

inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드된다. 

Content-Disposition: inline
Content-Disposition: attachment; filename='filename.csv'

다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있다. 

Location

300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려주는 헤더이다. 

HTTP/1.1 302 Found
Location: /

위와 같은 응답이 왔다면, 브라우저는 / 주소로 리다이렉트한다. 

Content-Security-Policy

다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 여기에 명시할 수 있다. 

하나의 웹 페이지는 다양한 외부 소스들을 불러온다. 이미지도 불러오고, script 태그로 자바스크립트 파일들도 불러온다. 폰트나 스타일, 아이프레임도 불러온다. 

하지만 해커들에 의해 원하지 않는 파일을 불러오게 될 수도 있다. 

악성코드가 담겨있는 파일이라면 문제가 발생할 것이다. XSS 공격 같은 것이 하나의 예시이다. 

이럴 때, Content-Security-Policy로 허용할 외부 소스만 지정할 수 있다. 

Content-Security-Policy: default-src 'self'
Content-Security-Policy: default-src https:
Content-Security-Policy: default-src 'none'

self로 지정하면 자기 도메인의 파일들만 가져올 수 있다. www.abc.com에서는 www.abc.com/logo.jpg를 가져올 수 있지만, www.def.com/logo.jpg는 가져올 수 없다.  

https://로 지정하면 https를 통해서만 파일을 가져올 수 있게 된다. 

'none'으로 지정하면 가져올 수 없다. 

default-src는 모든 외부 소스에 대해 적용된다. 각각 따로 지정할 수도 있다. 두 개나 세 개로만 추려서 지정할 수도 있다. 

Content-Security-Policy: font-src 'self'; script-src https://www.zerocho.com 'unsafe-inline'; 
img-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none'

font-src, script-src, img-src, style-src, object-src 등이 있고, 소스 옵션으로는 도메인이나, https://, 'unsafe-inline'(인라인 태그 허용), 'unsafe-eval'(eval 함수 허용) 등이 있다. 

옵션은 매우 다양하므로 아래 링크를 참고해보자. 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

이 외에도 다양한 응답 헤더들이 있다. 오늘은 유명한 응답 헤더들만 정리해보았다. 

다음 포스팅에서는 쿠키와 캐시 헤더에 대해 알아보도록 하자. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 쿠키, 캐시 헤더

이 포스팅은 아래 링크를 참고했습니다. 

https://www.zerocho.com/category/HTTP/post/5b4c4e3efc5052001b4f519b

앞 내용을 잠시 복습해보자면, 서버의 역할은 클라이언트로부터 요청을 받아 응답을 보내는 것이다. 요청과 응답은 메세지 형식으로 오고, 이게 바로 HTTP 메시지! HTTP 메시지는 시작줄, 헤더, 본문으로 구성되어 있다. 

HTTP에 대해 알고싶다면, 아래 포스팅을 클릭해보자. 

https://dolphinsarah.tistory.com/38

HTTP 메소드에 대해 알고 싶다면, 아래 포스팅을 클릭해보자. 

https://dolphinsarah.tistory.com/39

이번 시간에는 헤더에 대해 알아볼텐데, 헤더 종류가 매우 많기 때문에, 알아두면 유용한 HTTP 공통 헤더와 요청 헤더에 대해 먼저 알아보도록 하자. 

헤더는 개발자도구(F12)의 네트워크 탭에서 확인할 수 있다! 

공통 헤더 

요청과 응답 모두 사용되는 헤더이다. 

Date

HTTP 메시지가 만들어진 시각이다. 자동으로 만들어진다. 

Connection

HTTP/2를 사용하지 않는다면 보통 HTTP/1.1을 사용한다. 

Connection은 기본적으로 keep-alive로 되어 있는데 사실상 아무런 의미도 없다. 

HTTP/2에서는 아예 사라져버렸다. 

Cache-Control

매우 중요하고, 꼭 알아둬야 하는 헤더이기 때문에 아래 포스팅에 따로 정리했다. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 쿠키, 캐시 헤더

*Content 시리즈는 엔티티 헤더라고 불린다. 

Content-Length

요청과 응답 메시지의 본문 크기를 바이트 단위로 표시해준다.

메시지 크기에 따라 자동으로 만들어진다.

Content-Length: 52

Content-Type

컨텐츠의 타입(MIME)과 문자열 인코딩(UTF-8 등)을 명시할 수 있다. 

조금 뒤에 나오는 Accept 헤더, Accept-Charset 헤더와 대응된다. 

 위의 예시 헤더는 현재 메시지 내용이 text/html 타입이고, 문자열은 utf-8 문자열임을 알려준다. 

Content-Language

사용자의 언어를 뜻한다. 요청이나 응답이 무슨 언어인지와는 관련 없다. 

예를 들어, 한국인에게 일본어를 가르치는 사이트일 경우, 페이지 언어는 일본어일지라도

Content-Language는 ko-KR일 수 있다. 

Content-Encoding

Content-Encoding은 컨텐츠의 압축된 방식이다. 

응답 컨텐츠를 br, gzip, deflate 등의 알고리즘으로 압축해서 보내면, 브라우저가 알아서 해제해 사용한다. 

이외에도 다양한 압축 알고리즘이 존재한다. 컨텐츠의 용량이 줄어들기 때문에 압축을 권장한다. 

요청이나 응답 전송 속도도 빨라지고, 데이터 소모량도 줄어들기 때문에 가능하면 압축해두는 게 좋다. 

요청 헤더

Host

서버의 도메인 네임이 나타나는 부분이다. (포트 포함) 

Host 헤더는 반드시 하나가 존재해야 한다. 

User-Agent

Host보다 더 유명한 헤더는 User-Agent다. 

현재 사용자가 어떤 클라이언트(운영체제와 브라우저 같은 것)를 이용해 요청을 보냈는지 나온다. 

아래의 이미지를 보면 내 클라이언트가 무엇인지 알 수 있다. (나는 LG gram 크롬으로 접속했다)

물론, User-Agent를 믿어서는 안된다. 헤더를 변경할 수도 있으니까. 

하지만 대부분의 사람들이 User-Agent를 조작하지 않고 그대로 보내기 때문에,

User-Agent 헤더를 활용해서 접속자 통계 등을 내곤 한다. 

또, 이를 활용해 IE로 접속한 사람들을 찾아내고, IE는 지원하지 않으니 크롬으로 접속해달라는 메시지를 표시하기도 한다. 

Accept

이제, Accept 시리즈를 알아보자. 

Accept 헤더는 요청을 보낼 때 서버에, 이런 타입(MIME)의 데이터를 보내줬으면 좋겠다고 명시할 때 사용한다. 아래처럼 콤마로 여러 타입을 동시에 적어줄 수도 있다. 

위와 같이 요청 헤더를 보낸다면, html 형식, xhtml+xml 형식 등등의 응답을 처리하겠다는 뜻이다. 

Accept 시리즈라고 한 것은, Accept-Encoding, Accept-Charset, Accept-Language 등도 있기 때문이다. 

공통 헤더의 Content 시리즈와 대응된다. 

Accept로 원하는 형식을 보내면, 서버가 그에 맞춰 보내주면서 응답 헤더의 Content를 알맞게 설정할 것이다. 

Accep-Charset: utf-8
Accept-Language: ko, en-US
Accept-Encoding: br, gzip, deflate

Charset은 문자 인코딩(UTF-8 등)을 명시하는 부분이고, Language는 원하는 언어, Encoding은 원하는 컨텐츠 압축 방식이다. 

뭘 적어야할지 모르겠다면 *를 적거나, 그냥 브라우저가 알아서 설정해서 보내는 Accept를 사용하면 된다.

Authorization

Authorization 헤더는 인증 토큰(JWT든, Bearer 토큰이든)을 서버로 보낼 때 사용하는 헤더이다. 

API 요청 같은 것을 할 때 토큰이 없으면 거절당하기 때문에, 이때 Authorization을 사용하면 된다. 

Authorization: Bearer XXXXXXXXXXXXX

보통 Basic이나 Bearer 같은 토큰의 종류를 먼저 알리고, 그 다음에 실제 토큰 문자를 적어 보낸다. 

Origin

POST 같은 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지를 나타낸다. 

여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 문제가 발생하기도 한다. 

Referer

이 페이지 이전의 페이지 주소가 담겨 있다. 

이 헤더를 사용하면 어떤 페이지에서 지금 페이지로 들어왔는지 알 수 있기 때문에 애널리틱스 같은 곳에 많이 사용된다. 재밌는 사실은, Referer은 오타다. Referrer가 표준어인데 실수로 Referer로 만들었다고 한다. 

다음 포스팅에서는 응답 헤더에 대해서 알아보자. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 응답 헤더

이 포스팅은 아래 링크를 참고하였습니다. 

https://www.zerocho.com/category/HTTP/post/5b3ba2d0b3dabd001b53b9db

HTTP는 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다. 

(*HTTP에 대해 알고 싶다면 아래 포스팅을 읽어보세요)

https://dolphinsarah.tistory.com/38

이번 포스팅에서는 HTTP 메소드에 대해 알아보고자 한다. 

HTTP 메소드는 HTTP 요청을 할 때 사용하는 메소드이다. 

데이터를 가져오고 싶으면 GET 메소드를, 데이터를 새로 만들고 싶으면 POST 메소드를, 데이터를 삭제하고 싶으면 DELETE 메소드를, 데이터를 수정하고 싶으면 PATCH 메소드를, 이외에도 PUT, HEAD, OPTIONS, CONNECT, TRACE 등이 있다. (자주 사용되는 것은 GET, POST, DELETE, PATCH, PUT 정도이다.)

이 메소드들을 필요에 맞게 요청 시 사용하면 된다. 

요청만 보낸다고 그대로 되는 것은 아니고, 서버가 요청을 검증한 후 유효하면 실행된다. 

HTML을 배웠다면 다들 form을 한 번씩 만들어보았을텐데, 아래와 같은 HTML form에 데이터를 입력하고 새로운 form을 만들고자 할 때는 method를 POST로 설정하고, action을 명시해주어야 한다. action은 form 데이터를 서버로 보낼 때 해당 데이터가 도착할 URL이다. 

<form action="/examples/media/action_target.php" method="post">
    이름 : <input type="text" name="st_name"><br>
    학번 : <input type="text" name="st_id"><br>
    학과 : <input type="text" name="department"><br>
    <input type="submit">
</form>

HTML form만 사용해보았다면, 메소드로 GET과 POST만 사용해보았겠지만, 실제로 요청을 보낼 때는 PUT, DELETE, PATCH 등 더 자세한 동작을 정의할 수 있다. 

보통 PUT은 전체 수정(대체), PATCH는 부분 수정, DELETE는 제거 요청 시 사용한다. 

이처럼 주소를 자원이라 보고, 메서드를 동사라고 보는 개발 방식이 바로 REST이다.

예를 들어, GET /user라고 요청을 보내면, 사용자들의 정보를 가져오겠다는 의미이고, DELETE /user/5라고 요청을 보내면, id가 5인 사용자를 제거하겠다는 의미가 된다. 

GET과 DELETE를 제외한 POST, PUT, PATCH는 요청을 보낼 때 본문을 같이 보낼 수 있다.  

GET과 DELETE도 본문을 넣어 보내는 것이 불가능한 것은 아니지만, GET과 DELETE의 본문은 어떻게 처리해야 한다는 정의가 없기 때문에(서버가 본문을 무시하는 것이 권장된다고 한다), GET이나 DELETE 요청 시에는 본문을 같이 보내지 않는다. 

아래는 내가 만든 웹사이트의 회원가입 요청 시의 POST 메소드를 사용한 예다. 

Request Payload 부분이 본문 부분(헤더 다음에 들어가는 부분)이다.

서버는 저 본문을 받아 파싱(해석)한 후 사용하게 된다. 

나머지 HEAD, OPTIONS, TRACE, CONNECT에 대해서도 알아보자. 이 메소드들은 쓰는 사람들을 제외하고는 자주 보기 힘든 메서드들이다. 

HEAD는 요청에서 헤더만 가져올 때 사용한다. 단, 헤더가 GET 요청의 헤더이다. 

HEAD https://www.dolphinSarah.com HTTP/1.1 요청을 보낸다면, GET https://www.dolphinSarah.com HTTP/1.1 요청을 보내고 헤더만 가져오는 것과 동일하다는 뜻이다. 

OPTIONS는 CORS 문제에서 본 적이 있을 것이다. OPTIONS는 서버가 어떤 메서드를 지원하는지 알아볼 때 사용한다. 

아래와 같이, OPTIONS를 통해 서버가 OPTIONS, GET, HEAD, POST 메서드를 지원한다는 사실을 알 수 있다. 

또한, CORS 상황에서는 다른 도메인 서버에 먼저 OPTIONS 요청을 날린 뒤, 그 서버가 요청을 허용하면 실제 요청(GET, POST 등)을 날린다. 

즉, OPTIONS 요청은 서버에게 실제 요청을 보내기 전에 서버를 테스트하는 용도라고 보면 된다.

TRACE와 CONNECT는 진짜 쓰이는 곳에서만 쓰인다고 한다. 나는 아직까지 한 번도 써본 적은 없지만, TRACE는 핑퐁 테스트 같은 곳에 쓰이고, CONNECT는 양방향 연결을 할 때(SSL(HTTPS)을 사용하는 웹사이트에 접속할 때) 쓰인다고 한다. 

지금까지 HTTP 요청 메소드들에 대해 알아보았는데, GET, POST, DELETE, PUT, PATCH, OPTIONS 정도만 알아두면 된다. 

시작줄을 알았으니, 이제 헤더에 대해 알아보자. 

2021.05.27 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 공통 헤더와 요청 헤더

아래의 포스팅을 참고하여 작성하였습니다. 

https://www.zerocho.com/category/HTTP/post/5b3723477b58fc001b8f6385

HTTP는 Hyper Text Transfer Protocol로, 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다. 

(데이터를 주고 받으면서 발생하는 에러(ex) CORS, CORB)들은 HTTP만 잘 알아도 쉽게 해결할 수 있다.)

아래 이미지는 내가 만든 웹사이트의 어떤 포스트의 데이터를 가져오는 요청과 그에 대한 응답 정보를 담고 있는 헤더이다. 저 각각의 줄들이 다 정보를 담고 있다. 

서버의 역할은 요청에 대한 응답을 보내준다는 것임을 기억하며 '요청'부터 알아보자. 

요청

위 이미지에서 내 웹사이트 서버에게 localhost:3060/post/45에 대한 정보를 달라고 요청했다. 요청을 보낼 때는 요청에 대한 정보를 담아서 서버로 보낸다. 

서버도 응답할 때 응답에 대한 정보를 담아 클라이언트로 보낸다. 이런 정보가 담긴 메세지를 HTTP 메세지라고 한다. 

HTTP 메세지는 시작줄, 헤더, 본문으로 구성됩니다. 

첫 줄은 시작줄이다. POST (웹사이트 주소) HTTP/1.1이라고 적혀있다. POST는 HTTP 메서드이다. HTTP/1.1는 HTTP 버전이다. 즉, 요청 메세지의 시작줄은 메서드(POST)-주소(웹사이트 주소)-버전(HTTP/1.1)으로 구성된 것이다. 

두 번째 줄부터는 헤더이다. 요청에 대한 정보를 담고 있다. User-Agent, Upgrade-Insecure-Requests 등이 헤더에 해당된다. 헤더 종류는 이 뿐만 아니라 매우 다양하다. 

헤더에서 한 줄 띄우고 본문이 시작된다. 본문은 요청을 할 때, 함께 보낼 데이터를 담는 부분이다. 예를 들어 사용자가 회원가입 요청을 보냈을 때, 아이디, 비밀번호 등 다양한 데이터가 요청에 포함되는데, 이런 데이터가 본문에 담겨있다. 

응답

아래는 HTTP 메시지(응답)이다. 

요청과 마찬가지로 시작줄, 헤더, 본문으로 구성되어 있다. 

첫 줄은 버전(HTTP/1.1)-상태코드(403)-상태메세지(Forbidden)로 구성되어있다. 

두 번째 줄부터는 헤더이다. 응답에 대한 정보를 담고 있다. 역시 헤더 종류는 매우 다양하다. 

요청을 할 때는 따로 전송할 데이터가 없다면 본문이 없는 경우도 있지만, 응답에는 보통 본문이 있다. 보통 서버에 데이터를 요청하고, 응답 메시지에는 요청한 데이터를 담아서 보내주기 때문이다. 

이처럼 HTTP 메시지만 보아도 정말 많은 정보를 알 수가 있다. 

다음으로는 HTTP 요청 메소드에 대해 알아보겠다. (아래 포스팅을 클릭해주세요)

https://dolphinsarah.tistory.com/39

다음 글을 참고하여 작성했습니다.

https://www.zerocho.com/category/HTTP/post/5b344f3af94472001b17f2da