HTTP 웹 기본 지식

두별·2022년 3월 18일

목록 보기

13/46

인터넷 네트워크

인터넷 통신

인터넷에서 컴퓨터 둘은 어떻게 통신을 하나?

클라이언트 < 인터넷 < 서버

인터넷 망을 통해 메세지를 전송하는데 해저 광테이블 ..인공위성 .. 등 수많은 중간 서버(노드)를 거쳐서 건너감
도대체 어떤 규칙으로 ? 수많은 복잡한 상황을 건너 목적지까지 잘 갈 수 있는 것인가? 이걸 이해하기 위해선 먼저 IP에 대한 이해가 필요하다.

IP (인터넷 프로토콜)

IP주소를 통한 규칙
클라이언트가 주소를 부여받아야 한다.
서버도 IP 주소가 있어야 한다.

IP 패킷 정보란?

데이터를 전송하기 전에
출발지 IP, 목적지 IP를 적어야한다.

서버 패킷 전달

마찬가지로 출발지 IP, 목적지 IP가 있어야 한다.

IP 프로토콜의 한계

비연결성
비신뢰성
프로그램 구분

대상이 서비스 불능일때 패킷 전송

클라이언트는 대상 서버가 패킷을 받을 수 있는 상태인지 모름

패킷 소실

서버를 거쳐서 전달이 되던 중 중간 서버에 문제가 생겼을때 클라이언트가 보낸 패킷이 유실됨

패킷 전달 순서 문제 발생

hello
world !
를 보냈는데 많은 중간 노드를 타다보면
world !
hello
이렇게 순서가 뒤바껴 전달될 수 있다.

위와 같은 문제들을 해결하기 위해선 TCP가 필요하다.

TCP, UDP

인터넷 프로토콜 스택의 4계층

애플리케이션 계층 HTTP , FTP
전송 계층 TCP, UDP
인터넷 계층 IP
네트워크 인터페이스 계층

프로토콜 계층

프로그램이 메시지 생성
socket 라이브러리를 통해 전달
TCP 정보 생성, 메시지 데이터 포함
IP 패킷 생성, TCP 데이터 포함
랜카드 -> 인터넷 -> 서버 ...

IP 패킷 정보

출발지 IP
목적지 IP
기타

IP 패킷 : 덩어리, 버킷 의 합성어

TCP 세그먼트

출발지 PORT
목적지 PORT
전송제어
순서
검증 정보
전송데이터

TCP 특징

전송제어 프로토콜

연결지향
데이터 전달 보증
순서 보장
신뢰할 수 있는 프로토콜
현재는 대부분 TCP 사용

TCP 3way handshake

SYN - connect 연결 과정
SYN + ACK
ACK
데이터 전송

데이터 전달 보증

클라이언트 : 데이터 전송
서버 : 데이터 잘 받았음 ㅇㅇ

순서 보장

클라이언트 : 1,2,3 패킷 순서로 전송
서버 : 1,3,2 순서로 도착
서버 > 클라이언트 : 패킷2부터 다시 보내셈

UDP 특징

사용자 데이터그램 프로토콜

하얀 도화지에 비유 . 기능이 거의 없음
연결지향 X
순서보장 X
데이터 전달 보증 X
단순하고 빠름
PORT가 추가됨
IP와 거의 같다. +PORT +체크섬 정도만 추가
애플리케이션에서 추가 작업 필요

PORT

항구

한번에 둘 이상 연결해야 하면?

클라이언트가 게임도 하고 화상통화도 하고 웹브라우저 요청도 하고
이런 경우 클라이언트가 여러 서버와 통신해야 한다.
서버에서 날라온 패킷이 게임인지 화상통화인지 웹브라우저인지 보낼때도 마찬가지로 알수가 없지 않나. 그래서 TCP 패킷 안에 PORT가 있는 것 !

TCP 패킷 정보

출발지 PORT
목적지 PORT

IP는 목적지 , 출발지 IP 패킷 정보를 담음

PORT - 같은 IP 내에서 프로세스 구분

게임 port : 8090 : 게임 서버 연결
화상통화 port : 21000 : 화상통화 통신
웹 브라우저 : 10010 : 웹 브라우저 요청

DNS

IP는 기억하기 어렵다.

200.200.200.2???

IP는 변경될 수 있다.

과거 IP와 신규 IP가 다를 수 있고 그러면 클라이언트는 접속할 수 가 없음

DNS

도메인 네임 시스템

전화번호부
도메인 명을 IP주소로 변환

DNS 사용

도메인명 : google.com
응답 : 200.200.200.2
접속 : 200.200.200.2

DNS 서버가 있으면 위 두개의 문제가 해결됨.

URI와 웹 브라우저 요청 흐름

URI

소스를 식별하기 위한 통합된 방법

URI와 웹 브라우저 요청 흐름

URI
웹 브라우저 요청 흐름

URI?URL?URN?

URI는 로케이터, 이름 또는 둘다 추가로 분류될 수 있다.

URL은 scheme://authority/path/query/fragement

URN은 ResoureName

URI

단어 뜻

Uniform : 리소스 식별하는 통일된 방식
Resource: 자원, URI로 식별할 수 있는 모든 것. 제한 없음
Identifier: 다른 항목과 구분하는데 필요한 정보
URL : Uniform Resource Locator
URN : Uniform Resource Name

URL, URN

URL : Locator : 리소스가 있는 위치를 지정
URN : Name : 리소스에 이름을 부여
위치는 변할 수 있찌만 이름은 변하지 않는다.
URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음
앞으로 URI == URL 같은 의미로 설명

URL 전체 문법

프로토콜 https
호스트명 www.google.com
포트번호 8080
패스 /search
쿼리 파라미터 q=hello

URL scheme

스키마

주로 프로토콜 사용
어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 http, https, ftp 등
http는 80포트, https는 443포트 주로 사용, 포트는 생략 가능
https는 http에 강력한 보안이 적용된 것

URL host

호스트명
도메인명 또는 IP주소를 직접 사용 가능

URL port

port
접속 포트
생략가능

URL path

리소스 경로, 계층적 구조

URL query

key value 형태
?로 시작, &로 추가 가능
query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터 문자형태

URL fragment

html 내부 북마크 등에 사용
서버에 전송하는 정보 아님

웹 브라우저 요청 흐름

HTTP 요청 메시지

GET /search?q=hello HTTP/1.1
Host: www.google.com

HTTP 메시지 전송

웹 브라우저가 HTTP 메시지 생성
SOCKET 라이브러리를 통해 전달

A:TCP/IP 연결 (IP, PORT)
B: 데이터 전달

TCP/IP 패킷 생성, HTTP 메시지 포함

HTTP 응답 메시지

HTML 데이터가 들어있다.
웹 브라우저가 렌더링 한다.

HTTP 기본

모든 것이 HTTP

HTTP 메시지에 모든 것을 전송

HTML, TEXT
image, 음성, 영상, 파일 ..
JSON, XML
거의 모든 형태의 데이터 전송 가능
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
지금은 HTTP 시대!

HTTP 역사

0.9
0.1
- 1.1 97년 : 가장 많이 사용, 우리에게 가장 중요한 버전
2.0 2015년 : 성능개선
3.0 진행중 : 성능개선

기반 프로토콜

TCP : HTTP/1.1 , HTTP/2
UDP : HTTP/3
현재 HTTP/1.1 주로 사용
- HTTP/2, HTTP/3도 점점 증가

HTTP 특징

클라이언트 서버 구조
무상태 프로토콜, 비연결성
HTTP 메시지
단숨함, 확장 가능

클라이언트 서버 구조

Request Response 구조
클라이언트는 서버에 요청을 보내고, 응답을 대기
서버가 요청에 대한 결과를 만들어서 응답

Stateful, Stateless

무상태 프로토콜

서버가 클라이언트의 상태를 보존 X

상태 유지 - stateful

클라이언트의 상태를 보존
항상 같은 서버가 유지되어야 한다.

무상태 - stateless

클라이언트의 상태를 보존 X
아무 서버나 호출해도 된다.
중간에 서버가 동작할 수 없어도 중계서버가 다른 서버로 던져줄 수 있다.
스케알 아웃 : 수평 확장에 유리하다.
실무 한계 :
- 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
- 무상태
  예) 로그인이 필요없는 단순한 서비스 소개 화면
- 상태 유지
  예 ) 로그인
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
- 상태 유지는 최소한만 사용

상태유지, 무상태 차이

상태유지 : 중간에 다른 서버로 바뀌면 안된다. (중간에 다른 서버로 바뀔때 상태정보를 다른 서버에게 미리 알려주어야 한다.)
무상태 : 중간에 다른 서버로 바뀌어도 된다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. > 무한한 서버 증설 가능

비연결성

HTTP는 기본이 연결을 유지하지 않는 모델
일반적으로 초 단위 이하의 빠른 속도로 응답
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
- 예) 웹 브라우저에서 계속 연속해서 검색버튼을 누르지는 않는다.
서버 자원을 매우 효율적으로 사용할 수 있음

연결을 유지하는 모델

HTTP 지속 연결

연결을 유지하지 않는 모델

자원을 주고 받을때에만 연결하고 서버 연결 유지 x , 최소한의 자원 사용으로 서버를 운영

비연결성 한계와 극복

TCP/IP 연결을 새로 맺어야함 - 3way handshake 시간 추가
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css , 추가 이미지등 수많은 자원이 함께 다운로드
지금은 HTTP 지속 연결로 문제 해결
HTTP/2, HTTP/3에서 더 많은 최적화

스테이스리스를 기억하자

서버 개발자들이 어려워하는 업무

정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
예) 선착순 이벤트, 명절 KTX, 수강신청

HTTP 메시지

요청메시지

메서드

GET, POST , PUT, DELETE ...
서버가 수행해야할 동작 지정

요청대상

절대경로="/"로 시작하는 경로

HTTP 버전

응답 메시지

HTTP 버전
HTTP 상태 코드 : 요청 성공, 실패를 나타냄
- 200 : 성공
- 400 : 클라이언트 요청 오류
- 500 : 서버 내부 오류

HTTP 헤더

용도

HTTP 전송에 필요한 모든 부가정보
메시지 body의 내용, 크기, 압축, 인증, 요청 클라이언트 브라우저의 정보, 서버 애플리케이션 정보, 캐시 관리 정보 ...
표준 헤더가 너무 많음
필요시 임의의 헤더 추가 가능

HTTP 메시지 바디

실제 전송할 데이터
HTML 문서, 이미지, JSON 등 ..

단순함 확장 가능

HTTP는 단순하다. 스펙도 읽어볼만..
HTTP 메시지도 매우 단순
크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술

HTTP 메서드

HTTP API

API URI 고민

리소스란?
- 회원등록, 수정, 조회가 리소스가 아님
- 미네랄을 캐라 -> 미네랄이 리소스
- 회원이라는 개념 자체가 리소스이다.
리소스를 어떻게 식별하는게 좋을까?
- 회원등록,수정,조회 모두 배제
- 회원이라는 리소스만 식별 > 회원 리소스를 URI에 매핑

회원목록조회/members/
회원조회/members/{id} -> 어떻게 구분하지?
회원등록/members/{id} -> 어떻게 구분하지?
회원수정/members/{id} -> 어떻게 구분하지?
회원삭제/members/{id} -> 어떻게 구분하지?

URI는 리소스만 식별 !
리소스와 해당 리소스를 대상으로 하는 행위를 분리
- 리소스 : 회원
- 행위 : 조회,등록,삭제,변경
리소스는 명사, 행위는 동사 (미네랄을 캐라)
행위는 어떻게 구분? -> GET, POST

HTTP 메서드 - GET,POST

주요 메서드 종류

GET 리소스 조회
POST : 요청데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체, 해당리소스가 없으면 생성
PATCH : 리소스 부분 변경
DELETE

기타 메서드

HEAD : GET과 동일하지만 메시지 부분을 제외한, 상태줄과 헤더만 반환
OPTIONS: 대상 리소스에 대한 통신 옵션을 설명 .. CORS에서 주로 사용
...

GET

GET /search?q=hello&hi=ko HTTP/1.1
Host:www.google.com

리소스 조회
서버에 전달하고 싶은 데이터는 query 파라미러를 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만 , 지원하지 않는곳이 많아서 권장X

POST

POST /members HTTP/1.1
Content-Type:application/json

요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터를 처리
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
주로 신규 리소스 등록, 프로세스 처리에 사용

PUT

POST /members/100 HTTP/1.1
Content-Type:application/json

리소스를 대체
리소가 있으면 대체
리소스가 없으면 생성
쉽게 이야기해서 덮어버림

중요! 클라이언트가 리소스를 식별
클라이언트가 리소스 위치를 알고 URI 지정
POST와 차이점은 지정한다는것

PACTH

리소스 부분변경

DELETE

리소스 제거

HTTP 메서드의 속성

안전

호출해도 리소스를 변경하지 않는다 (GET, HEAD)

멱등

한번호출하든 두번호출하든 100번 호출하든 결과가 똑같다
GET
PUT
DELETE
POST : 멱등아님 ! 두번호출하면 중복결제 발생
활용 : 자동복구 매커니즘. 서버가 응답을 못했을때 클라이언트의 재요청 여부

캐시가능

응답결과 리소스를 캐시해서 사용해도 되는가?
GET,HEAD,POST,PATCH 캐시가능
실제로는 GET,HEAD 정도만 캐시로 사용
POST,PATCH는 본문내용까지 캐시 키로 고려해야하는데 구현이 쉽지 않음

HTTP 메서드 활용

클라이언트에서 서버로 데이터 전송

데이터 전달 방식은 크게 2가지

쿼리 파라미터를 통한 데이터 전송
- GET
- 주로 정렬필터 (검색어)

메시지 바디를 통한 데이터 전송
- POST, PUT, PATCH
- 회원가입, 상품주문, 리소스 등록, 리소스 변경

4가지 상황

정적 데이터 조회
- 이미지, 정적 텍스트 문서
- 조회 GET 사용
동적 데이터 조회
- 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성
- 조회 GET 사용

HTML Form 데이터 전송
- POST 전송 -저장
  - Content-Type : application/x-www-form-urlencoded
  - 쿼리 파라미터와 거의 동일한 방식
- GET 전송 - 저장x 조회o
  - GET은 조회에만 사용, 리소스 변경이 발생하는 곳에 사용하면 안됨
- multipart/form-data
  - 여러 콘텐츠 타입을 전송, 바이너리 타입 전송시 사용
  - 참고로 HTML Form 전송은 GET,POST만 지원
HTTP API를 통한 데이터 전송
- 회원가입,상품주문,데이터변경
- 서버 to 서버, 앱클라이언트, 웹클라이언트 Ajax

HTTP API 설계 예시

API 설계 -POST 기반 등록

회원목록조회/members/ -> GET
회원조회/members/{id} -> GET
회원등록/members/ -> POST
회원수정/members/{id} -> PATCH(권장),PUT(게시글,파일),POST
회원삭제/members/{id} -> DELETE

HTTP 상태코드

HTTP 상태코드 소개

1xx : 요청이 수신되어 처리중
- 거의 사용하지 않으므로 생략
2xx : 요청 정상 처리
- 200 OK : 요청성공
- 201 Created : 요청성공해서 새로운 리소스가 생성됨 /members/100
- 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음 배치 처리같은 곳
- 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 (save버튼을 눌러도 아무런 반응이 필요없을때)
3xx : 요청을 완료하려면 추가 행동이 필요 (리다이렉트)
- 301,308 : 영구 리다이렉션, 원래 URL를 사용 X , 검색엔진등에서도 변경 인지
- 302, 307, 303 : 일시적인 리다이렉션, 검색엔진등에서 URL을 변경하면 안됨
- 300 : Multiple Choices , 안쓴다
- 304 : Not Modified, 진짜 안쓴다
4xx : 클라이언트 오류, 잘못된 문법등으로 서버가 요청수행 불가
- 400 : 요청구문, 메시지 등등 오류, 요청 파라미터가 잘못되거나 api 스펙이 맞지 않을때
- 401 : 클라이언트가 해당 리소스에 대한 인증이 필요함 , 로그인 , 권한등
- 403 : 서버가 요청을 이해했지만 승인을 거부, 등급이 안맞음
- 404 : 요청 리소스가 서버에 없음
5xx : 서버오류, 서버가 정상요청을 처리하지 못함
- 500 : 서버내부 오류
- 503 : 서버 과부하 또는 예정된 작업으로 잠시 요청 처리불가

HTTP 헤더1 - 일반 헤더

HTTP 헤더 개요

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name 대소문자 구분 없음

HTTP 헤더

헤더 분류
• General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: close
• Request 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..)
• Response 헤더: 응답 정보, 예) Server: Apache
• Entity 헤더: 엔티티 바디 정보, 예) Content-Type: text/html, Content-Length: 3423

HTTP BODY

메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용
• 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
• 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공
• 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

RFC723x 변화

• 엔티티(Entity) -> 표현(Representation)
• Representation = representation Metadata + Representation Data
• 표현 = 표현 메타데이터 + 표현 데이터

HTTP BODY (최신)

• 메시지 본문(message body)을 통해 표현 데이터 전달
• 메시지 본문 = 페이로드(payload)
• 표현은 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
• 데이터 유형(html, json), 데이터 길이, 압축 정보 등등
• 참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만, 여기서는 생략

표현

• Content-Type: 표현 데이터의 형식
• 미디어 타입, 문자 인코딩
• 예)
• text/html; charset=utf-8
• application/json
• image/png
• Content-Encoding: 표현 데이터의 압축 방식
• 표현 데이터를 압축하기 위해 사용
• 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
• 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
• 예)
• gzip
• deflate
• identity
• Content-Language: 표현 데이터의 자연 언어 ko, en, en-US
• Content-Length: 표현 데이터의 길이
• 표현 헤더는 전송, 응답 둘다 사용

협상

클라이언트가 선호하는 표현 요청

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어
• 협상 헤더는 요청시에만 사용

전송방식

• 단순 전송
• 압축 전송
• 분할 전송
• 범위 전송

일반 정보

• From: 유저 에이전트의 이메일 정보
• Referer: 이전 웹 페이지 주소
• User-Agent: 유저 에이전트 애플리케이션 정보
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
• Date: 메시지가 생성된 날짜

Form

유저 에이전트의 이메일 정보
• 일반적으로 잘 사용되지 않음
• 검색 엔진 같은 곳에서, 주로 사용
• 요청에서 사용

Referer

이전 웹 페이지 주소
• 현재 요청된 페이지의 이전 웹 페이지 주소
• A -> B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청
• Referer를 사용해서 유입 경로 분석 가능
• 요청에서 사용
• 참고: referer는 단어 referrer의 오타

User-Agent

유저 에이전트 애플리케이션 정보
• user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/
537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
• 클리이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
• 통계 정보
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• 요청에서 사용

Server

요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
• Server: Apache/2.2.22 (Debian)
• server: nginx
• 응답에서 사용

Date

메시지가 발생한 날짜와 시간
• Date: Tue, 15 Nov 1994 08:12:31 GMT
• 응답에서 사용

특별한 정보

• Host: 요청한 호스트 정보(도메인)
• 요청에서 사용
• 필수
• 하나의 서버가 여러 도메인을 처리해야 할 때
• 하나의 IP 주소에 여러 도메인이 적용되어 있을 때
• Location: 페이지 리다이렉션
• Allow: 허용 가능한 HTTP 메서드
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

Location

페이지 리다이렉션
• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
(리다이렉트)
• 응답코드 3xx에서 설명
• 201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를
가리킴

Allow

허용 가능한 HTTP 메서드
• 405 (Method Not Allowed) 에서 응답에 포함해야함
• Allow: GET, HEAD, PUT

Retry-After

유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
• 503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
• Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
• Retry-After: 120 (초단위 표기)

인증

• Authorization: 클라이언트 인증 정보를 서버에 전달
• WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

Authorization

클라이언트 인증 정보를 서버에 전달
• Authorization: Basic xxxxxxxxxxxxxxxx

WWW-Authenticate

리소스 접근시 필요한 인증 방법 정의
• 리소스 접근시 필요한 인증 방법 정의
• 401 Unauthorized 응답과 함께 사용
• WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple"

쿠키

• Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

Stateless

• HTTP는 무상태(Stateless) 프로토콜이다.
• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
• 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
• 클라이언트와 서버는 서로 상태를 유지하지 않는다

쿠키 미사용

모든 요청에 정보를 넘기는 문제
• 모든 요청에 사용자 정보가 포함되도록 개발 해야함
• 브라우저를 완전히 종료하고 다시 열면?

쿠키

• 예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
• 사용처
• 사용자 로그인 세션 관리
• 광고 정보 트래킹
• 쿠키 정보는 항상 서버에 전송됨
• 네트워크 트래픽 추가 유발
• 최소한의 정보만 사용(세션 id, 인증 토큰)
• 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고
• 주의!
• 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)

쿠키 - 생명주기

• Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
• 만료일이 되면 쿠키 삭제
• Set-Cookie: max-age=3600 (3600초)
• 0이나 음수를 지정하면 쿠키 삭제
• 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
• 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 - 도메인

• 예) domain=example.org
• 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
• domain=example.org를 지정해서 쿠키 생성
• example.org는 물론이고
• dev.example.org도 쿠키 접근
• 생략: 현재 문서 기준 도메인만 적용
• example.org 에서 쿠키를 생성하고 domain 지정을 생략
• example.org 에서만 쿠키 접근
• dev.example.org는 쿠키 미접근

쿠키 - 경로

• 예) path=/home
• 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
• 일반적으로 path=/ 루트로 지정
• 예)
• path=/home 지정
• /home -> 가능
• /home/level1 -> 가능
• /home/level1/level2 -> 가능
• /hello -> 불가능

쿠키 - 보안

• Secure
• 쿠키는 http, https를 구분하지 않고 전송
• Secure를 적용하면 https인 경우에만 전송
• HttpOnly
• XSS 공격 방지
• 자바스크립트에서 접근 불가(document.cookie)
• HTTP 전송에만 사용
• SameSite
• XSRF 공격 방지
• 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

HTTP 헤더2 - 캐시와 조건부 요청

캐시 기본 동작

캐시가 없을 때

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
• 인터넷 네트워크는 매우 느리고 비싸다.
• 브라우저 로딩 속도가 느리다.
• 느린 사용자 경험

캐시 적용

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 매우 빠르다.
• 빠른 사용자 경험

캐시 시간 초과

• 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
• 이때 다시 네트워크 다운로드가 발생한다.

검증 헤더와 조건부 요청1

캐시 시간 초과

• 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.
1. 서버에서 기존 데이터를 변경함
2. 서버에서 기존 데이터를 변경하지 않음

• 캐시 만료후에도 서버에서 데이터를 변경하지 않음
• 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.
• 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요
-> Last-Modified : 2020.11.10.10:10:10 검증할 수 있는 값
-> if-modified-since : 2020.11.10.10:10:10
-> 데이터가 아직 수정되지 않았다.

정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

검증 헤더와 조건부 요청2

검증 헤더와 조건부 요청

• 검증 헤더
• 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
• Last-Modified , ETag
• 조건부 요청 헤더
• 검증 헤더로 조건에 따른 분기
• If-Modified-Since: Last-Modified 사용
• If-None-Match: ETag 사용
• 조건이 만족하면 200 OK
• 조건이 만족하지 않으면 304 Not Modified

검증 헤더와 조건부 요청 예시

• If-Modified-Since: 이후에 데이터가 수정되었으면?
• 데이터 미변경 예시
• 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
• 304 Not Modified, 헤더 데이터만 전송(BODY 미포함)
• 전송 용량 0.1M (헤더 0.1M, 바디 1.0M)
• 데이터 변경 예시
• 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
• 200 OK, 모든 데이터 전송(BODY 포함)
• 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

Last-Modified, If-Modified-Since 단점

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
• 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag, If-None-Match

• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기!
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
• 예)
• 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
• 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

캐시와 조건부 요청 헤더

캐시 제어 헤더

• Cache-Control: 캐시 제어
• Pragma: 캐시 제어(하위 호환)
• Expires: 캐시 유효 기간(하위 호환)

Cache-Control

캐시 지시어

• Cache-Control: max-age
• 캐시 유효 시간, 초 단위
• Cache-Control: no-cache
• 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
• Cache-Control: no-store
• 데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)

Pragma

캐시 제어(하위 호환)
• Pragma: no-cache
• HTTP 1.0 하위 호환

Expires

캐시 만료일 지정(하위 호환)

• expires: Mon, 01 Jan 1990 00:00:00 GMT

• 캐시 만료일을 정확한 날짜로 지정
• HTTP 1.0 부터 사용
• 지금은 더 유연한 Cache-Control: max-age 권장
• Cache-Control: max-age와 함께 사용하면 Expires는 무시

검증 헤더와 조건부 요청 헤더

• 검증 헤더 (Validator)
• ETag: "v1.0", ETag: "asid93jkrh2l"
• Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT
• 조건부 요청 헤더
• If-Match, If-None-Match: ETag 값 사용
• If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

프록시 캐시

Cache-Control

캐시 지시어(directives) - 기타

• Cache-Control: public
• 응답이 public 캐시에 저장되어도 됨
• Cache-Control: private
• 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
• Cache-Control: s-maxage
• 프록시 캐시에만 적용되는 max-age
• Age: 60 (HTTP 헤더)
• 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

캐시 무효화

Cache-Control

확실한 캐시 무효화 응답

• Cache-Control: no-cache, no-store, must-revalidate
• Pragma: no-cache
• HTTP 1.0 하위 호환

Cache-Control

캐시 지시어(directives) - 확실한 캐시 무효화

• Cache-Control: no-cache
• 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
• Cache-Control: no-store
• 데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)
• Cache-Control: must-revalidate
• 캐시 만료후 최초 조회시 원 서버에 검증해야함
• 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
• must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
• Pragma: no-cache
• HTTP 1.0 하위 호환

두별

이전 포스트

java: warning: source release 11 requires target release 11

다음 포스트

HTTP 웹 기본 지식

TIL

인터넷 통신

인터넷에서 컴퓨터 둘은 어떻게 통신을 하나?

클라이언트 < 인터넷 < 서버

IP (인터넷 프로토콜)

IP 패킷 정보란?

서버 패킷 전달

IP 프로토콜의 한계

대상이 서비스 불능일때 패킷 전송

패킷 소실

패킷 전달 순서 문제 발생

TCP, UDP

인터넷 프로토콜 스택의 4계층

프로토콜 계층

IP 패킷 정보

TCP 특징

TCP 3way handshake

데이터 전달 보증

순서 보장

UDP 특징

PORT

한번에 둘 이상 연결해야 하면?

TCP 패킷 정보

PORT - 같은 IP 내에서 프로세스 구분

DNS

IP는 기억하기 어렵다.

IP는 변경될 수 있다.

DNS

DNS 사용

URI

URI와 웹 브라우저 요청 흐름

URI?URL?URN?

URI

URL, URN

URL 전체 문법

URL scheme

URL host

URL port

URL path

URL query

URL fragment

웹 브라우저 요청 흐름

HTTP 요청 메시지

HTTP 메시지 전송

HTTP 응답 메시지

모든 것이 HTTP

HTTP 역사

기반 프로토콜

HTTP 특징

클라이언트 서버 구조

Stateful, Stateless

무상태 프로토콜

상태 유지 - stateful

무상태 - stateless

상태유지, 무상태 차이

비연결성

연결을 유지하는 모델

연결을 유지하지 않는 모델

비연결성 한계와 극복

스테이스리스를 기억하자

HTTP 메시지

요청메시지

메서드

요청대상

HTTP 버전

응답 메시지

HTTP 헤더

용도

HTTP 메시지 바디

단순함 확장 가능

HTTP API

API URI 고민

HTTP 메서드 - GET,POST

주요 메서드 종류

기타 메서드

GET

POST

PUT

PACTH