대바보의 끄적끄적

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데이터를 많이 보내야한다.