[Spring]_ Web의 기초

1) DNS(Domain Name System)

- DNS는 도메인 이름과 IP 주소를 서로 변환하는 역할을 수행한다. 즉, 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 읽을 수 있는 IP 주소로 변환한다.

 

• DNS가 나오게된 이유
  1. 컴퓨터 간의 통신을 위해선 IP 주소가 필요하다.
     • IP 주소는 사이트마다 특징도 없고 길어서 외우기가 힘들다.
     • IP 주소가 변경된다면 새로운 IP에 접근할 수 없다.
  2. IP는 변경되는 주소이다.
     • 일반적으로 가정집에서 사용되는 IP는 유동IP 입니다.
     • 만약 IP가 변경된다면 새로운 IP에 접근할 수 없습니다.
• DNS 동작 순서

1.  원하는 이름의 도메인을 구매 후, DNS 서버에 등록한다.

2. 도메인 명을 입력하면 DNS 서버는 IP 주소를 반환한다.

3. IP가 변경되면 DNS 서버에 등록된 IP 주소만 바뀌면 된다.

• • IP주소가 아닌 도메인 명(URL)로 검색이 가능

2) URI(Uniform Resource Identifier)

📚 인터넷 자원(Resource)을 나타내는 고유 식별자(Identifier)를 뜻한다.

• Uniform: 자원(Resource)을 식별하는 통일된 방식을 의미한다.
• Resource: 자원(페이지, 텍스트, 이미지, 동영상, 파일 등)을 의미한다.
• Identifier: 식별자를 의미한다.

>> URI = URL(주소) + URN(이름)

 

 

URL(Uniform Resource Locator)

- 자원(Resource)의 위치를 의미하며, 일반적으로 도메인주소로 알려져있다. (프로토콜 포함 O)

- 다만 위치를 변경하면 기존 URL은 사용할 수 없으며 업데이트가 되지 않으면 찾을 수 없다. -->> URN의 등장 배경

 

URN(Uniform Resource Name)

- 자원(Resource)의 이름(Name)을 의미한다. (프로토콜은 포함 X)

- 리소스의 위치가 변경되어도 이름으로 리소스를 찾기 때문에 잘 동작한다.

- 대중화 되어있지 않다.

 

3) URL(Uniform Resource Locator)의 구조

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
https://www.google.com:443/search?q=스파르타+코딩클럽

• scheme : 프로토콜 (웹에선 http,https,ftp를 사용)
• user[:password] : 사용자 정보(URL은 보안이 취약해 사용안함)
• host[:port] : 도메인명/ IP주소를 사용(http : 80, https : 443 포트 사용하며 일반적으론 생략)
• [/path] : 리소스 경로(계층 구조)
• [?query] : key=value 형태로 구성되며, ?로 시작되고 &으로 구분(Query Parameter, Query String)
• [#fragment] : html 내부 북마크 등에 사용(전달받은 URL로 접속 시 특정 위치(fragment)로 이동)

# 용어모음 #

• JAVA의 명명법

 

• JSON(JavaScript Object Notation)

- 클라이언트와 서버가 통신할 때 사용하는 데이터 양식

- 사람과 기계 모두 이해하기 쉬우며 용량이 작다

- Web에선 공통어로 사용

 

• JSON 구조

- snake_case, camelCase 모두 사용가능

- key-value 형태로 구성

 

• MSA(MicroService Architecture)

- 아주 작은 단위로 서비스를 잘게 나누어 운영하는 아키텍처

 

► Scale Up, Scale Out [ 서버의 성능 향상을 위한 두 가지 방법 ]

 

✓ Scale Up (수직적 확장)

- 단일 서버의 하드웨어 사용을 높임(CPU, Memory 등의 스펙을 높임)

- 요청의 처리를 더욱 빠르게 해줌

 

✓ Scale Out (수평적 확장)

- 같은 사양의 서버(인스턴스)를 여러대 배치

- 동시에 더 많은 사용자의 요청을 처리

 

 

► Stateful, Stateless [ 클라이언트와 서버간의 통신 상태(state) 유지 여부에 따라 나뉘는 특성 ]

 

✓ Stateful(상태 유지)

- 클라이언트의 상태를 유지(만일 서버가 에러로 종료시 다음 요청이 느려짐)

- ex) 상담원은 수강생의 요청들을 기억(상태 유지)하여 다음 질문들에 대한 처리가 가능하다.

 

 

✓ Stateless(무상태)

- 클라이언트 상태를 유지하지 않는다(같은 서버를 유지할 필요 없음)

- Scale Out 수평 확장성이 높다

- 클라이언트가 데이터를 추가적으로 많은 데이터를 전송해야함

< Stateless 방식의 한계점 >
WebApplication을 만들때 서버의 확장성을 고려하여 최대한 Stateless하게 만들어야 한다.
하지만, 실제로는 로그인과 같은 상태를 유지해야하는 경우가 발생한다.
추후에 배울 Cookie, Session, Token 등을 활용하여 상태 유지를 최소화 해야한다

 

 

► Connection, Connectionless [ 클라이언트와 서버 간의 연결(Connection) 유지 여부에 따라 나뉘는 특성 ]

 

✓ Connection(연결)

 

- 서버는 클라이언트와 연결 유지를 위해 자원을 소비

- 다만 동시에 처리하는 요청을 작아 2,3번은 요청이 없얻 유지하게 된다

 

< Connection 장단점 >
장점
새로운 연결 과정을 거치지 않아도 된다.
그만큼 요청에 대한 응답 속도가 빨라진다.

단점
클라이언트가 지속적으로 요청을 보낼거라는 보장이 없다.
즉, 연결을 위한 자원이 낭비된다.

 

✓ Connectionless(비연결)

- 클라이언트와 서버는 연결을 유지하지 않는다.

- 서버는 최소한의 자원만을 사용한다.

 

< Connectionless 장단점>
장점
- 서버 자원을 효율적으로 사용할 수 있다.
단점
- 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다.→ 요청에 대한 응답 시간이 증가한다.
- 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다.→ 캐시, 브라우저 캐싱로 해결 (임시저장)
- 현재는 **HTTP 지속연결(Persistent Connections)**로 문제를 해결한다.

 

► HTTP 지속연결(Persistent Connections)

- 하나의 요청에 필요한 요청들이 모두 응답될 때까지 연결 유지

- 연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다.

   → 그만큼 속도가 빨라졌다.