내배캠 TIL 20일차

오병택·2025년 3월 17일

내배캠

목록 보기
42/73
post-thumbnail

학습 요약

Spring 입문 강의

Spring 입문 1주차

네트워크

TCP : 서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜
TCP는 신뢰성이 있지만 연결하는 과정, 데이터 전송에 시간이 많이 소요됨.
이유 : 3 way handshake 과정을 거치기 때문.

UDP : UDP는 비연결형, 신뢰성이 없는 전송 프로토콜
TCP와 달리 UDP는 실시간 통신이나 스트리밍 애플리케이션에서는 빠른 전송이 중요하여 개발됨.

PORT : 같은 IP 내에서 프로세스 구분을 하기 위해서 사용

Web 기초

DNS(Domain Name System)

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

DNS가 나온 이유

  • 컴퓨터 간의 통신을 위해선 IP 주소가 필요
  • IP 주소는 사이트마다 특징도 없고 길어서 외우기가 힘듬.
  • IP 주소가 변경된다면 새로운 IP에 접근x

URI(Uniform Resource Identifier)

인터넷 자원을 나타내는 고유 식별자

  • URL과 URN을 포함하는 상위 개념

URL(Uniform Resource Locator)

자원의 위치를 의미

  • 프로토콜 포함

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

scheme
-주로 프로토콜 사용.
-웹에서는 http, https, ftp를 주로 사용

user[:password]
-사용자 정보
-URL은 보안에 취약하여 사용x

host[:port]
-도메인 명(www.google.com) 또는 IP 주소를 직접 사용
-http : 80, https : 443 포트 사용.
-포트는 일반적으로는 생략

[/path]
-리소스의 경로
-계층 구조

[?query]
-key=value 형태로 구성
-Query Parameter, Query String 이라고도 함
-?로 시작되고 &으로 구분

[#fragment]
-html 내부 북마크 등에 사용 (전달받은 URL로 접속 시 특정 위치(fragment)로 이동)

URL의 한계
자원의 위치를 변경하면 기존 URL 사용 불가

URN(Uniform Resource Name) : 자원의 이름을 의미

  • 프로토콜 포함x
  • 리소스의 위치를 변경해도 이름으로 리소스를 찾기 때문에 동작o

JSON

JSON은 클라이언트와 서버가 통신할 때 사용하는 데이터 양식. 클라이언트와 서버가 사용하는 언어에 관계 없이 통일된 데이터를 주고받을 수 있도록 만들어짐.

JSON 구조

{
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    }
  ]
}
  • snake_case, camelCase 모두 사용이 가능
  • key-value 형태로 구성
  • null, number, string, array, object, boolean 형태의 데이터를 사용

서버의 성능 향상을 위한 두 가지 방법

Scale Up

수직적 확장

  • 단일 서버의 하드웨어의 사용을 높임
  • 요청에 대한 처리를 더욱 빠르게 할 수 있음

Scale Out

수평적 확장

  • 같은 사양의 서버(인스턴스)를 여러 대 배치
  • 동시에 더 많은 사용자 요청을 처리할 수 있도록 만듬

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

Stateful (상태 유지)

단점

  • 같은 서버가 유지돼야 함
  • 서버는 다양한 이유로 동작하지 않을 수 있음
  • 요청 트래픽이 몰리게되면 상태를 유지하는것에 Resource가 많이 소모

Stateless (상태 유지x)

장점

  • 같은 서버를 유지할 필요x
  • Scale Out 수평 확장성이 높음

단점

  • 클라이언트가 데이터를 추가적으로 전송

Stateless 방식의 한계점

WebApplication을 만들때 서버의 확장성을 고려하여 최대한 Stateless하게 만들어야 함. 하지만 로그인과 같은 상태를 유지해야 하는 경우도 발생함.

한계점 해결 방안

Cookie, Session, Token 등을 활용하면 상태 유지를 최소화 시킬 수 있음.

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

Connection (연결)

장점

  • 새로운 연결 과정을 거치지 않아도 됨
  • 그만큼 요청에 대한 응답 속도가 빨라짐

단점

  • 클라이언트가 지속적으로 요청을 보낼거라는 보장x
  • 연결을 위한 자원이 낭비

Connectionless (비연결)

장점

  • 서버 자원을 효율적으로 사용

단점

  • 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야함
  • 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드

단점 해결 방안

  • 캐시, 브라우저 캐싱으로 해결
  • HTTP 지속 연결로 해결

HTTP 지속연결 (Persistent Connections)

하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지
한번만 연결하기 때문에 비연결보다 빠름

HTTP

HTTP 동작 순서


1 -> 2

HTTP 특징

  • Stateless (상태 유지x)
  • Connectionless (비연결)

HTTP Message 구조

내일 이어서 쓸게요 ^^

느낀 점

오늘 모르는 게 너무 많아서 하나하나 다 정리하니까 머리가 지끈거린다. 일단 내일 아침에 마저 쓰는 것으로 하고 자야 겠다. 확실히 처음 배우는 것은 힘든 것 같다. 이해를 해야 넘어가는 스타일인 나에게 조금 가혹하다. 😭

profile
걱정하지 말고 일단 해봐!

0개의 댓글