1. Proxy: 클라이언트와 서버 사이에서 중계 역할을 하는 서버나 장비: 사용자와 인터넷 간의 연결을 중개하며, 주로 보안, 성능 향상, 네트워크 관리 등을 목적으로 사용목적- 보안 : IP 숨기기 or 프록시 서버를 방화벽으로 사용(프록시 방화벽)- 속도(캐시) : 동일 요청 시, 저장된 Cache 반환 => 전송 시간 절약, 외부 트래픽을 줄여 네트워크 병목 현상도 방지- ACL : 사이트 접근 범위 정책 정의 (Proxy Server 에 접속할 수 있는 범위를 설정하는 옵션)- Log / Audit : 리포트, 모니터링 (회사 내 직원의 인터넷/인트라넷 사용을 레포팅)분류: Forward Proxy | Reverse Proxy Forward Proxy: Client 측에 위치1) 클..
1. HTTP Cache 동작 원리- 캐시는 임시적인 저장이므로 실시간성 X, 하지만 준실시간성을 보장하고자 함- 재검증은 "주기"와 "기준"으로 판단1.1 HTTP Cache 재검증 기준Last-Modified (수정일) 낮은 정확도 - 텍스트 파일 수정 후, 다시 원상복구한 경우 수정일만 변경검사 방법 - If-Modified-Since : 바뀌었어? - If-Unmodified-Since : 안바뀌었어?ETag (고유값) 높은 정확도 - but, HTTP 1.0 혹은 1.1 호환성을 위해 위와 함께 사용검사 방법 - If-None-Match : 바뀌었어? - If-Match : 안바뀌었어?Last-Modified : 마지막 수정일(시간) 기반으로 캐시의 유효성 판단: 웹 서버가 Last-Modifi..
[03-01] HTTP Cache
1. 등장 배경: WB는 매번 WS에 요청-> 응답, WS는 매번 WB의 요청에 값 반환 ==> 둘 다 바빠진다! => 이전의 로드 응답 똑같다면 굳이 통신 해야할까?: WB or WS에 임시 저장소 == 캐시 => 데이터의 주인 == 서버이므로 헤더를 통해 서버에서 어디에 뿌릴지 관리2. Cache의 종류CacheHTTP CachePrivateShared=> public과 private Server CacheLocalGlobal 2.1 HTTP Cache - HTTP Cache데이터를 캐시하는 곳- 저장 장소 지정 방식에 따라WBprivate 개인의 WB에 저장된 것only WbprivateProxyshared 중간 서버에 저장되서 다수의 WB에서 접근 가능WB + Proxy에 저장publi..
[02-02] 서버의 구성과 트래픽
1. Infrastructure1.1 물리 서버자체적으로 구축한 데이터 센터 => On-Premise단점 => 고정 비용 + 직접 운영 관리- 건물 유지비용, 서버 구매비용, 유지보수 등 - 한번 구매, 설정하면 수요에 상관없이 계속 보유, 관리필요1.2 가상 서버(클라우드 서버)데이터 센터에서 임대 => 온디맨드 비용 + AWS가 대신 운영 관리(아마존은 신이야)장점- 간편한 설정- 고정되지 않은 유동적인 비용1.3 서버리스(Serverless)서버 구축 Xonly 상시 서버가 아닌 필요할 때마다 빌림1) 서버 필요 요청2) 서버 활성화(= 타 서버 대여)3) 작업 이후 서버 비활성화(= 서버 반납)요청 횟수에 따른 과금이기에 => 낮은 트래픽, 고메모리 필요시에 유용(= 호출 횟수는 적고, 작업의 필..
[02-02] 운영체제 기초
1.1 하드웨어: app(sw)가 구동되는 머신: 내부 자원(CPU + Memory) + 외부 자원(I/O)(네트워크 IO, 저장장치 IO, 마우스 키보드 등) 1.2 소프트웨어: 시스템 소프트웨어(OS) + 응용 소프트웨어- 시스템 SW: OS 운영체제(CPU의 자원 관리 - 응용 SW: 어플리케이션(=프로그램), shell 1.3 프로그램, 프로세스, 스레드프로그램- 파일, 코드 등의 정적인 상태프로세스- 프로그램이 자원을 할당 받아 활성화된 상태- 실행 단위가 상대적으로 크고,- 하나의 프로그램에는 하나의 프로세스만 존재- heap(바구니) + Stack(함수 호출)스레드- 프로세스 안의 작은 작업 단위- 실행 단위가 상대적으로 작고- 하나의 프로그램에 다수의 스레드 존재 가능- 프로세스와 공유..
[02-02] Web Application Framework
1.1 Web Application Framework- Java: Spring- Python: Django- C#: ASP, NET- JS: Express.js - 웹 어플리케이션 프레임워크는 다음과 같은 기능을 제공RequestMapping : 어떤 요청에 따라 어떤 메서드(함수 혹은 로직)을 수행할것인지Thread 관리 : 요청을 처리하기 위한 Thread 할당 및 관리, 데이터베이스 접속을 위한 Thread 할당 및 관리데이터베이스 동시성 제어 : 대량 트래픽 발생 시 데이터베이스 조작에 대한 각 요청들 간의 동시성 제어-> Isolation Level(트랜젝션 격리 레벨)Serialization / Deserialization : 요청, 응답 시 어플리케이션의 객체와 클라이언트의 JSON 사이 변..
[02-01] 렌더링 최적화 전략
1. HydrationHydration: SSR로 생성된 정적 HTML 페이지가 클라이언트 측에서 js가 실행되며 동적 웹 애플리케이션으로 활성화(+) Hydration은 처음 페이지가 로드될 때 HTML은 빠르게 표시(-) JS가 로드되고 실행될 때까지 페이지 상호작용이 비활성 상태 -> 인터랙티브 요소가 늦게 동작/비활성화SSG(Static Site Generation): 비실시간성 요소를 미리 생성하여 페이지를 매우 빠르게 반환합SSR(Server-Side Rendering): 실시간성이 필요한 요소는 서버에서 요청이 들어오자마자 렌더링되어 반환CSR(Client-Side Rendering): 모바일 앱처럼 일부 요소는 클라이언트에서 렌더링하여, JS 번들 크기를 줄이고 성능을 최적화2. Pa..
[02-01] 웹 페이지 제공 방법-2
0. 시작하며: 이전 포스트에서 웹 페이지의 3가지 제공 방식을 살펴보았다.SSG이미 만들어진 웹 페이지를 서버에 저장하고 바로 WB에 반환(+) 속도가 빠르다.(-) 실시간성 위배SSR웹 서버가 만든 페이지를 WB에 반환(+) 실시간성 O(-) 웹서버 부하가 크고, 렌더링 시간이 길다.CSRWB가 JS바탕의 페이지를 반환(+) 좋은 UX를 제공(-) 초기 로딩이 느리고, bundled js가 너무 크다.1. Hydration: SSG, SSR의 장점 위에 CSR의 장점을 추가하기 위한 방법 => 즉 , SSG, SSR방식으로 렌더링된 HTML 페이지를 Client에서 동적 웹 애플리케이션으로 활성화되도록 변환한다.SSG웹 페이지 내 비실시간성 요소를 미리 준비-> 빠르게 반환SSR실시간성이 필요한..
[02-01] 웹 페이지 제공 방법-1
1.1 SSG(Static Site Generation): WS가 페이지를 제공 -> (컴파일 타임에) 미리 렌더링된 페이지를 반환비 실시간성SEO 가능(서버에서 만들어진 페이지이므로)서버의 렌더링 부담 제거1.2 SSR(Server-Side Rendering): WS가 페이지를 제공 -> (런타임에) 요청이 올 때마다 렌더링한 페이지를 반환함실시간성(요청에 따른 실시간 데이터가 반영된 최신 페이지 반환) => 실시간 데이터가 중요한 곳에 이용SEO 가능-> build의 결과물 == `거대한 JS` 이를 이용하여 빈 HTML을 채울 `템플릿 엔진` 필요-> `템플릿 엔진`은 Render의 주체로 결과로 view를 생성(이런 식으로 이해)-> Render가 서버에서 발생하므로 SSR1.3 CSR(Clie..