Dev Diary.

무상태 프로토콜 스테이스리스(Stateless)

서버가 클라이언트의 상태를 보존하지 않는다.

장점: 서버 확장성 높음

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

Stateful,Stateless 차이

상태유지 : 중간에 서버가 바뀌면 안된다.

다른 서버로 바뀔때 상태정보를 미리 알려줘야한다.

무상태 : 중간에 서버가 바뀌어도된다.

갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설가능

스케일 아웃 - 수평확장 유리

Stateless 실무 한계

 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.

무상태 

예) 로그인이 필요 없는 단순한 서비스 소개 화면

상태유지

예) 로그인

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지

일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지

상태 유지는 최소한만 사용

Request Response 구조

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

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

비즈니스로직과 데이터같은 것들은 서버에 밀어넣고,

클라이언트는 UI에 집중하면 좋은점은

서로 독립적으로 성장할 수 있다.

HTTP에 대해서 알아보았다.

HTTP

HyperText Transfer Protocal

html, text 뿐만 아니라 요즘엔 모든 형태의 데이터를 전송할 수 있다.

서버간에 데이터를 주고 받을 때도 HTTP를 사용한다.

지금은 HTTP 시대이다.

기반 프로토콜

TCP : HTTP/1.1, HTTP/2

UDP : HTTP/3

현재 HTTP/1.1 주로 사용

HTTP/2, HTTP/3도 점점 증가한다.

HTTP 특징

클라이언트 서버 구조

무상태 프로토콜, 비연결성

HTTP 메시지

단순함, 확장 가능

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

위 의 url을 보내게되는 과정

먼저 웹브라우저가 구글서버를 찾아야한다. 그러기위해선

DNS서버를 조회한다. 그렇게 IP를 찾을 수 있고 443포트를 알아낼 수 있다.

HTTP요청 메시지를 생성한다.

HTTP 메시지라는것이 전송 데이터이다.

그런 다음에 구글서버에서 HTTP 응답 메시지를 만들어낸다.

Content-Type을 보면 응답하는 데이터가 text/html 형식이고 언어는 UTF-8방식을 사용한다라는 뜻이다.

그 후 웹브라우저가 html을 랜더링하고 

우리가 그 정보를 볼 수 있게된다.

URI와 웹 브라우저 요청 흐름

URI(Uniform Resource Identifier)

URI, URL, URN ???? 

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

자원을 식별하는 방법이다. 크게 2가지가 있는데

첫번째는 URL(Resource Locater) 리소스의 위치이다.

두번째는 URN(Resource Name) 리소스의 이름이다.

두 가지의 차이이다. 

거의 URL만 쓴다.

U: Uniform 리소스를 식별하는 통일된 방식

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

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

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

hello라는 것을 검색한 것과 같은 결과가 나온다. 

URL 전체 문법

scheme://[userinfo@]host[:port][/path][?query][#fragment]

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

프로토콜(https) 

호스트명(www.google.com)

포트번호(443)

패스(/search)

쿼리 파라미터(q=hello%hl=ko)

scheme

주로 프로토콜 사용

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

userinfo

URL에 사용자정보를 포함해서 인증할때 사용

거의 사용하지 않음

host

호스트명

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

port

포트

생략가능하다.

특정서버에 따로 접근할때는 사용하기도 함

path

리소스 경로, 계층적 구조

예) 

/home/file1.jpg

/members

/members/100, /items/iphone12

query

key=value 형태

?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB

query parameter, query string 등으로 불림, 웹서버에서 제공하는 파라미터, 문자 형태

fragment

html 내부 북마크 등에 사용

서버에 전송하는 정보 아님

IP는 기억하기 어렵다.

IP는 변동될 수 도 있다.

DNS

도메인 네임 시스템

전화번호부 같은 서버를 제공

도메인 명을 ip주소로 변환

위의 2가지 문제를 해결할 수 있다.

IP프로토콜 만으로 신뢰할 수 가 없고 PORT도 없고 순서가 꼬일 수 있기때문에

TCP프로토콜이 해결해 줄 수 있다. PORT는 같은 IP안에서 동작하는 애플리케이션을

구분할 수 있도록하기위하여 사용하고 DNS는 ip를 도메인명으로 변환하여 변동되거나 헷갈리지 

않도록 하게 해준다.

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

예를들면 PC에 게임, 화상통화, 웹 서핑을 같이한다면?

패킷들이 올때 게임관련인지, 화상통화인지 어떻게 알까?

출발지PORT , 목적지PORT로 알 수 있다.

같은 IP내에서 프로세스 구분하는 것이 PORT이다.

클라이언트에서 출발지 PORT를 포함시켜서 보내기때문에

서버에서 내 PORT까지 알 수 있다.

IP가 아파트라면 PORT는 몇동 몇호를 뜻한다고 생각하면 쉽다.

PORT

0~65535 할당 가능

0~1023 잘 알려진 포트, 사용하지 않는 것이 좋음

이전 IP 프로토콜의 문제들을 TCP 프로토콜이 해결을 해준다.

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

애플리케이션 계층 - HTTP,FTP

전송 계층 - TCP,UDP

인터넷 계층 - IP

네트워크 인터페이스 계층 

이 있다.

IP 패킷 정보 

출발지 IP, 목적지 IP, 기타등등

전송 데이터가 있다.

TCP/IP 패킷 정보

출발지 IP, 목적지 IP, 기타등등

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

전송 데이터가 있다.

TCP 특징

전송 제어 프로토콜

연결지향 - TCP 3 way handShake

데이터 전달 보증

순서 보장

신뢰할 수 있는 프로토콜

현재는 대부분 TCP 사용

TCP 3 way handshake

클라이언트에서 서버로 SYN 메시지 보냄

서버에서 클라이언트로 ACK + SYN 메시지를 보냄

클라이언트에서 서버로 ACK를 보냄 

이렇게 하면 둘이 연결이 됐다고 인식을 하게 된다. 

그다음에 데이터를 전송한다. 

중요한 것은 TCP연결이 되었단 것은 진짜 연결이 된 것은 아니고

개념적으로만 연결이 되었다는 것이다. 

순서 보장

2번이 올 차례에 3번이 왔다. 

서버는 패킷2번을 보내라고 요청을 한다.

UDP 특징

하얀 도화지에 비유

비연결성

데이터 전달 보증 x

순서 보장 x

단순하고 빠르다.

마치 IP프로토콜과 똑같지만

PORT+체크섬 정도가 추가되었다.

최근에 각광을 받고 있다. 왜냐하면 웹 브라우저에서 HTTP통신을 할때

더 최적화를 하여 UDP를 사용하며 굉장히 뜨고있다고 한다.

앞서 포스팅했던 인터넷 통신에서 

복잡한 구조의 인터넷을 통해 목적지 까지 도달하기 위해선 

어떠한 약속 및 규칙들이 필요할 것이다.

그것이 바로 IP 주소 부여를 통해 가능해진다.

먼저 클라이언트가 IP주소를 부여 받아야한다.

서버 또한 IP주소가 있어야한다.

여기서 IP(인터넷 프로토콜)의 역할은?

- 지정한  IP주소에 데이터 전달

- 패킷이라는 통신 단위로 데이터 전달

IP 패킷 정보

메시지를 그냥 보내는 것이 아니라 IP패킷이라는 규칙이있다.

나의IP,목적지IP 두 가지와 기타등등 과 함께 패킷을 만든다.

만든 패킷을 IP프로토콜에 의해서 수많은 노드(서버)들은

패킷에 있는 나의 IP,목적지 IP를 해석하여 노드끼리 던지게 된다.

목적지 IP를 받을 수 있는 서버를 찾아

최종적으로 목적지에 도달하게 된다.

서버 패킷 전달

목적지에 도착했다면 목적지 서버또한 

출발IP, 목적IP를 넣고 잘 받았다는 내용과 함께

전송하면 최종적으로 나에게 도착하게 된다.

IP프로토콜의 한계

-비연결성

패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

-비신뢰성

중간에 패킷이 사라지거나

패킷이 순서대로 오지않는 경우를 해결할 수없다.

-프로그램 구분

같은  IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

이 한계를 해결하기 위한 것이 TCP,UDP이다.

인터넷 네트워크

- 인터넷 통신

- IP

- TCP,UDP

- PORT

- DNS

인터넷 통신

인터넷에서 컴퓨터 둘은 어떻게 통신할까?

클라이언트 서버가 바로 옆에 붙어있다면 케이블로 데이터를 주고 받으면 될거라고 생각된다.

인터넷이라는 것이 클라이언트 와 서버 사이에 있다면?

인터넷 망을 통해서 메시지를 보내야한다.

인터넷은 단순하지 않다. 수많은 서버들 또는 노드들을 거쳐서 도달해야한다.

어떤 복잡한 상황을 거쳐 목적지까지 안전하게 가게 할 수 있을까?

그것을 가능하게 하는 것이 IP(인터넷 프로토콜)이다.