대바보의 끄적끄적

쿠키

HTTP는 무상태 프로토콜이기에 쿠키 미사용시엔 클라이언트가 서버에 접속했는지 계속 확인할 수 없다.

사용하는 예

1)로그인후에 유저 정보를 서버가 알기 위해 사용한다.

Set-Cookie

- 서버에서 클라이언트로 쿠키 전달(Response)

Cookie

- 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달

즉, 서버가 쿠키를 전달하면 클라이언트는 저장하고 항상 보내준다.

모든 요청에 자동으로 포함한다.

보안을 위해 쿠키를 서버를 세팅할때 세션 아이디를 생성해서 사용한다.

세션 아이디를 통해 서버에서 누군지 해석한다.

사용처

- 사용자 로그인 세션 관리에서 사용한다.

- 광고 정보 트래킹

쿠키 정보는 항상 서버에 전동 됨

- 최소한의 정보만 사용

- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sessionStorage) 참고

주의점

- 보안에 민감한 데이터는 저장하면 안 됨(주민번호, 신용카드 번호)

쿠키 생명주기

Expires(날짜), max-age(시간)

쿠키를 계속 유지할 수 없기에 날짜, 시간을 제한한다.

세션 쿠키

- 만료 날짜를 생략하면 브라우저 종료 시까지만 유지

영속 쿠키

- 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키-도메인

명시

- 명시한 문서 기준 도메인+ 서브 도메인 포함

- domain=example.org로 설정할 경우

- example.org와 dev.example.org 모두에 접근 가능하다.

생략 : 현재 문서 기준 도메인만 적용

쿠키 - 경로

이 경로를 포함한 하위 경로 페이지만 쿠키 접근

일반적으로 path=/ 루트로 지정

쿠키 - 보안

Secure, HttpOnly, SameSite

Secure

- Https에서만 전송한다.

HttpOnly

- XSS 공격 방비

- 자바스크립트에서 접근 불가(document.cookie)

- http 전송에만 사용

SameSite

- XSRF 공격 방지

- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 전송

전송방식

단순 전송

- 콘텐츠의 길이를 할 때 사용한다.

- Content-Length 

압축 전송

- 컨텐츠의 용량이 클 때 압축해서 전송한다.

- Content-Encoding

분할 전송

- 컨텐츠를 분할해서 전송한다.

- 종료시에 0 \r\n으로 표현한다.

- 분한 전송시엔 Content-Length이 포함되지 않는다.

- Transfer-Encoding

범위 전송

- 클라이언트가 요청한 범위를 전송한다.

- Request = Ranges: Bytes=1001~2000

- Response = Content-Range: bytes 1001~2000 / 2000 <-끝길이

일반정보

단순한 정보성 헤더이다.

From

- 유저 에이전트의 이메일 정보

Referer 

- 이전 웹 페이지의 주소 (구글에서 검색해서 다른 페이지로 접속 시 구글이 표현된다)

- 유입경로를 분석할때 사용한다.

User-Agent

- 유저 에이전트 애플리케이션 정보(즉 클라이언트 애플리케이션 정보)

- 특정 브라우저에서의 오류를 체크할 수 있다.

- Request에서 사용한다.

Server

- 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

- 중간에 거치는 프록시 서버가 아닌 진짜 처리하는 서버 정보를 제공한다.

- Response에서 사용한다.

Date

- 메시지가 발생한 날짜와 시간

- Response에서 사용한다.

특별한 정보

Host

- 요청한 호스트 정보(도메인)

- 필수

- 하나의 서버가 여러 도메인을 처리해야 할 때 사용한다.

- IP로만 통신하기에 필요하다.

- Host: aaa.com

Location

- 웹 브라우저가 3xx 응답 결과에 Location헤더가 있으면, Location 위치로 자동 이동

- 201 : Location 값은 요청에 의해 생성된 리소스 URI

Allow

- 허용 가능한 HTTP 메서드

- 405 (Method Now Allowed) 에서 응답에 포함해야 함

- Allow: GET, HEAD, PUT

Retry-After

- 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

- 날짜 단위, 초 단위로 표현 가능하다.

인증

Authorization

- 클라이언트 인증 정보를 서버에 전달한다.

- Basic xxxxxxxxx

WWW-Authenticate

- 리소스 접근 시 필요한 인증 방법 정의

- 401 Unauthorized 응답과 함께 사용

- WWW-Authenticate : Newauth realm=“apps”…

표현

리소스(데이터)를 어떤 표현으로 전달할지를 의미한다.

즉, 서버와 클라이언트가 주고받는 전송 형태를 말한다.

json으로, xml으로 표현한다.

표현 헤더는 reqeust, response 둘 다 사용

Ex)

HTTP/1.1 200 OK

Content-Type : application/json

Content-Length : 16



{“data”:”hello”}

Content-Encoding

     - gzip등으로 압축했을 때 클라리언트에서 압축방식을 알아야 하기에 표현을 전달할 때 사용한다.

Content-Length

     - ko,en등 한국어, 영어 표현

Content-Language

     - byte단위로 표현의 길이를 나타낸다.

협상(콘텐츠 네고시에이션)

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

협상헤더는 reqeust에서만 사용한다.

예를 다중언어를 지원하는 서버에서 기본이 영어일 때 한국어를 요청할 때 사용한다.

협상과 우선순위1

Quality values

우선순위를 설정해서 서버에 요청한다

Accept-Language : ko-KR, ko;ko;q=0.9, en-US;9=0.8

1.ko-KR;q=1(q=1은 생략)

2.ko;q=0.9

3.en-US;q=0.8

식으로 숫자가 큰 순으로 우선순위를 정해 요청한다.

협상과 우선순위 2

Quality values(q)

구체적인 것이 우선한다.

Accept : text/*, text/plain, text/plain;format=flowed, */*

협상과 우선순위 3

구체적인 것을 기준으로 미디어 타입을 맞춘다.

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

주로 GET에선 쿼리 파라미터로 전송한다.

body도 되긴 하나 잘 사용하지 않는다.

POST, PUT, PATCH에선 HTTP 메시지 body로 보낸다.

정적 데이터 조회

- GET을 사용한다.

- 쿼리 파라미터를 사용하지 않는다.

- 이미지를 가져올 때 사용한다.

동적 데이터 조회

- GET을 사용한다.

- 쿼리 파라미터를 기반으로 결과를 동적으로 생성

- 검색어 = 필터 라한다.

HTML FORM 전송

- POST를 사용한다.

- 웹 브라우저가 FORM데이터를 읽어 HTTP 메시지를 생성해준다.

- Content-Type : application/x-www-form-urlencoded

- HTTP 메시지 바디에 담아 서버로 보낸다.

- GET으로 변경도 가능하나 데이터 변경 작업이 있으면 사용하면 안 된다.(조회에서 사용 가능)

HTML FORM 데이터 전송

- multipart/form-data

- form에 파일을 담아 보낼 때 사용한다.

- 파일만 가는 게 아니라 form데이터 전체를 보낸다.

- Content-Type: multipart/form-data;boundary=123

- 바운더리로 구분한다.

HTTP API 전송

- 서버 TO 서버

- 앱 클라이언트

- 웹 클라이언트(ajax, React, Vue)

- GET, POST, PUT, PATCH 다 사용 가능하다.

- Content-Type : application/json을 주로 사용한다.

HTTP API 설계 예시

리소스 기반(/members)으로 설계한다.

[

회원 목록 /members -> GET

회원 등록 /members -> POST

회원 조회 /members/{id} -> GET

회원 수정 /members/{id} -> PATCH, PUT, POST

회원 삭제 /members/{id} -> DELETE

]

HTTP API - 컬렉션

(서버가 관리하는 리소스 디렉터리)

- POST 기반 등록

POST로 등록할 시 등록될 URI정보를 모른다.

서버에서 RESPONSE에 Location을 담아준다.

즉, 서버에 요청해 서버가 정해준다.

HTTP API - 스토어

(클라이언트가 관리하는 리소스 저장소)

- PUT 기반 등록

클라이언트가 직접 리소소의 URI를 지정한다.

클라이언트에서 서버에 원격으로 데이터를 넣을 때 사용한다.

클라이언트가 파일 이름을 알고 있고 파일을 업로드할 때 사용한다.

POST, PUT 중에선 주로 POST를 사용한다.

HTTP FORM 사용

GET, POST만 지원한다.

컨트롤 URI를 사용한다. ex) /members/{id}/delete

FORM은 GET,POST만 지원해 제약이 있다.

제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.

/members/{id}/delete

좋은 URI 설계 개념

문서

- 단일 개념(파일 하나, 객체 하나)

-/members/100

컬렉션

- 서버가 관리하는 리소스 디렉터리

- 서버가 리소스의 URI를 생성하고 관리

스토어

- 클라이언트가 관리하는 자원 저장소

- 클라이언트가 리소스의 URI를 알고 관리

컨트롤러, 컨트롤 URI

- 문서, 컬렉션, 스토러로 해결하기 어려운 추가 프로세스 실행

- GET, POST, PUT, PATCH만으로.

- /members/{id}/delete

비연결성(Connectionless)

TCP/IP는 연결을 유지한다.

요청 <-> 응답 형태

근데 서버에 연결된 클라이언트가 많아지면 서버의 부하가 많이 된다.

비연결성의 사용 이유!

연결을 유지하지 않는 모델은 서버가 유지해야 하는 자원이 줄어서 좋다.

HTTP는 기본적으로 연결을 유지하지 않는다.

Request, Response 형식으로 요청하고 응답이 오면 종료한다.

연결을 바로바로 끊게 되면 수천 명이 사용해도 동시에 들어오는 건 매우 적다.

비연결성의 단점

1.TCP/IP 연결에 필요한 3 way handshake 시간이 계속 추가된다.

2. 웹 브라이저로 사이트를 요청하면 HTML뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드된다.

처리방법

하나당 연결 후 끊는 게 아니라 다천리 될 때까지는 연결을 유지한다.

http 메시지

http는 모든 바이너리 데이터를 다 전송할 수 있다.(이미지, html, json 등등)

http를 사용하는 이유!

http 메시지 구성 형식

공식 스펙도 이렇게 되어있다.

Request(요청)

요청 시 메시지 구성요소에 들어가는 것

시작 라인 request-line

1.Http 메서드

- GET, POST, PUT, DELETE 등이 있다.

2. 요청 대상

- 대부분 절대 경로 이후의 값이 들어간다.

- /search?q=hello&hl=ko

3.Http 버전

- HTTP/1.1

Request(응답)

응답 시 메시지 구성요소에 들어가는 것

시작 라인 status-line

1.Http 버전

2.HTTP상태 코드(요청 성공, 실패를 나타냄)

- 200 : 성공

- 400 : 클라이언트 요청 오류

- 500 : 서버 내부 오류

3. 이유 문구

- 사람이 읽을 수 있는 오류 문구

Http header  

Key:Value 형태로 구성된다.

Key는 대소문자 구분하지 않는다.

value는 당연히 대소문자를 구분한다.

Http header 용도

http 전송에 필요한 부가 정보가 모두 포함되어있다.

서버와 협의 시에 부가 정보도 추가할 수 있다. 

ex) 특정 헤더 값 추가

KEY-TEST : "바보"

HTTP 메시지 바디

실제로 전송할 데이터가 포함된다.

URI

URI (Uniform Resource Identifier) : 

Uniform  = 리소스 식별하는 통일된 방식

Resource = 자원, URI로 식별할 수 있는 모든 것

Identifier = 다른 항목과 구분하는데 필요한 정보

URI? URL? URN?

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

즉, URI는 가장 큰 개념으로 생각하면 된다.

URL, URN을 포함한다.

URL = 리소스가 있는 위치를 지정

URN = 리소스에 이름을 부여

URL을 쓰고 URN을 잘 안 쓰는 이유?

위치는 변할 수 있지만, 이름은 변하지 않는다.

또, URN는 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지 않았다.

URL 분석

url예제 :  https://www.google.com/search?q=hello&hl=ko

https = 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙

ex) http, https, ftp

www.google.com = 호스트명 : 도메인명이나 IP주소 사용

/search = path : 리소스 경로, 계층적 구조

?q=hello = query : (key : value) 형태로 되어있다. 

Query parameter, query string이라고 불린다.

#fragment = http안에서 사용한다. 서버로 가지는 않음.

웹브라우저 요청 흐름

https://www.google.com/search?q=hello&hl=ko

참고사항 https는 433 포트가 생략되어있다.

DNS 조회 www.google.com/

PORT 조회 433포트

http 요청 메시지 생성 전달

서버에서 응답받은 메시지로 페이지 구성

위에 동작을 글로 표현한다면? 

클라이언트

소켓 라이브러리로 

구글 서버와 연결

TCP/IP로 포장 후 전송 데이터(http메시지) 전송

서버

http메시지 분석 후 동작

http 응답 메시지를 전송해준다.

http

HyperText Transfer Protocol

모든 것을 http으로 전송할 수 있다.

Http/1.1을 가장 많이 사용한다.

기반 프로토콜

http/1.1, http/2는 TCP 기반

http/3은 UDP 기반이다.

현재는 http/1.1이 많이 사용된다.

관리자 도구에서 프로토콜을 확인할 수 있다.

아래 사진은 http/3을 사용하는 걸 확인할 수 있다.

HTTP 특징

1. 클라이언트 서버 구조

2. 무상태 프로토콜 (스테이스 리스), 비연결성

HTTP 메시지

단순함, 확장 가능

1. 클라이언트 서버 구조

Request Response 구조

클라이언트는 서버에 요청을 보내고, 응답을 대기

서버가 요청에 대한 결과를 만들어서 응답

클라이언트 -> 요청 -> 서버

클라이언트 <- 응답 <- 서버

클라이언트는 ui를 그리는데 집중한다.

비즈니스 로직은 서버에 다 처리한다.

대용량 트래픽 처리에 유리하다

백앤드에서 아키텍처를 정해 비즈니스 로직을 처리한다.

2. 무상태 프로토콜

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

장점 : 서버 확정성 높음(스케일 아웃)

단점 : 클라이언트가 추가 데이터 전송

Stateful 상태 유지

무상태의 반대!

서버가 이전 상태를 보존한다.

같은 서버로 항상 유지되어야 한다.

또 사용 서버가 장애 날 경우 처음부터 다시 시작해야 한다.

Stateless 무상태

프런트에서 데이터를 저장하고 있고

서버에 전달한다.

상태 유지는 서버가 바뀔 경우 장애가 난다.

무상태는 서버가 바뀌어도 결제할 수 있다.

즉, 필요한 데이터를 그때그때 모두 주기에

 서버를 대량 증설해도 문제없다.

Stateless 한계 및 단점

모든 것을 무상태로 설계할 수 없다.

http데이터를 많이 보내야한다.

HTTP

인터넷 네트워크

인터넷 통신이라고 함은? 클라이언트와 서버가 통신하는 것을 말한다..

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

중간 노드(서버)들을 거쳐서 데이터가 전달된다.

IP(인터넷 프로토콜)

데이터를 전달하려면 주소가 필요한데 그것이 IP이다.

IP주소를 통해 데이터를 전달한다.

패킷단위로 전송한다.

패킷에 출발지IP,목적지IP등이 저장된다.

클라이언트 -> 서버, 서버 -> 클라이언트

양쪽 다 모두 동일하다.

IP만 있을 때 문제점!

1. 비연결성

상대 주소가 있는 없든 보낸다.

대상 서버가 패킷을 받을 수 있는지 모른다.

2. 비신뢰성

패킷 전송 중 패킷이 사라질 때?

패킷의 용량이 클 때 패킷이 순서대로 안 갈 수 있다.

3. 프로그램 구분

여러 개 프로그램 구동

이 문제를 해결하기 위해

TCP\UDP를 사용된다.

4단계 형식으로 감싸 진다 

즉, IP 위에 TCP를 이용해 사용할 수 있게 한다고

생각하면 된다.

4단계 예제

ex) 채팅

socket(애플리케이션 계층)

 (socket(애플리케이션계층),TCP)

((socket(애플리케이션 계층), TCP), IP)

식으로 감싸서 전달한다.

TCP를 통해 IP에서 부족한 것을 채워준다.

IP : 출발지 IP, 목적지 IP

TCP : 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보

TCP 사용 이유

연결 지향 - 먼저 연결해보고 메시지를 보낸다.

물리적으로 연결된 게 아니라

논리적으로 연결되어 있다.

TCP 3 way handshake

1. SYN (클라이언트-> 서버)
2. SYN + ACK (서버 -> 클라이언트)
3. ACK (클라이언트 -> 서버) 데이터도 함께 전송 가능

데이터 전달 보증 - 메시지 누락을 체크할 수 있다.

순서 보장

UDP - 기능이 거의 없다.

IP와 동일하지만 PORT가 추가되었다.

장점 속도가 빠르다.

최근엔 UDP를 많이 사용하려 한다.

PORT

PORT는 애플리케이션 하나에 하나씩 할당된다.

한 번에 둘 이상을 연결하기 위해 사용한다.

IP만 있다고 생각하면 패킷들을 분리할 방법이 없다.

IP는 서버를 찾고 PORT는 애플리케이션을 구분한다.

DNS(Domain Name System)

IP는 기억하기 어렵다.

또 IP는 변경될 수 있다.

도메인명으로 IP주소를 연결한다.

도메인명은 그대로있고 변경된 IP주소를 연결하면된다.

우리가 사용하는 웹브라우저는 URL을 입력하면 DNS에서 IP를 받아와

IP에 리퀘스트request를 만들어 요청한다.

리퀘스트request를 요청 받은 WEB서버는  처리 후 response를 반환해준다.

웹브라우저에서 웹에 접속할때 간단히 표현하면

클라이언트 요청

-> 리퀘스트 생성

-> 리퀘스트 전달

-> 웹서버에 통신도착

-> 리퀘스트 해독

-> 리스폰스 반환

통신과정을 거친다.

그런데 이런 통신을 할려면 모두가 사용하는 약속이 필요하다.

그 약속 = 프로토콜이 HTTP이다.

HTTP1.1이 된후 WEB 뿐만 아닌 다양한 곳에서 HTTP 프로토콜이 사용되고 있다.

위에서 말한 HTTP는 TCP/IP 프로토콜(약속)중 하나를 말한다.

여기서말한 TCP/IP 프로토콜은 TCP,IP프로토콜 2개를 말하는게 아닌

IP프로토콜을 사용하는 통신에 사용되는 프로토콜을 총칭해 TCP/IP라고 표현한다.

TCP/IP에는 계층이라는 중요한 개념이 있다.

계층은 애플리케이션,트랜스포트(TCP),네트워크(IP),링트 4계층으로 이루어져 있다.

간단히 알아보면

애플리케이션(HTTP): 리퀘스트request를 작성한다.

트랜스포트(TCP):  TCP 부분이다.작성된 데이터를 통신하기 쉽게 분해하고 안내,포트번호를 붙인다.

네트워크(IP):트랜스포트 계층에서 분해된 데이터에 수신될 MAC주소를 추가해 링크계층에 전달한다.

링크:하드웨어를 제어하는 디바이스드라이버,인터페이스카드, 하드웨어 케이블 등을 말한다.

링크를 통해 데이터가 전달된다.

송신할땐 애플리케이션 -> 트랜스포트 - > 네트워크 순으로 캡슐화하고

반대로 수신측에선

네트워크 -> 트랜스포트 -> 애플리케이션 순으로 캡슐화를 제거한다.