1. Toy - 37일차
-
DP 동전문제.. 예전에 했던 기억을 살려서 해결
-
계수정렬(counting sort)
https://www.cs.miami.edu/home/burt/learning/Csc517.091/workbook/countingsort.html
이름처럼 count를 새어놓고
누적합을 구한 후
정렬 전 배열의 뒤부터 역순회하며 누적합의 인덱스에 정렬 -
기수정렬
자리수에 맞는 queue에 값을 넣음 (1의 자리, 10의 자리 ...)
dequeue 후 다음 자릿수에 대한 정렬
2. 인터넷 프로토콜
-
IP(Internet Protocol)
-
지정한 IP주소에 패킷단위로 데이터를 전달
-
패킷을 무사히 받는다면, 응답을 돌려줘야 함
-
비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태임에도 패킷 전송(서버의 상태를 알 수 없기에) -
비신뢰성
중간에 패킷이 사라질 수 있음 (중간에 소실되더라도 알 수 있는 방법이 없음)
패킷의 순서를 보장할 수 없음 -
TCP 특징
연결 지향
데이터 전달 보증
순서 보장
신뢰할 수 있는 프로토콜 -
패킷=>
<=패킷+ACK응답
ACK응답=>
위와 같이 ACK응답을 돌려주기 때문에, 비연결성을 보완할 수 있음
또 패킷이 순서대로 도착하지 않는다면, 재전송 요청이 발생하여 비신뢰성 보완
-
UDP 특징
기능이 거의 없음 (하얀 도화지)
비 연결지향
데이터 전달 보증 X
순서 보장 X
단순하고 빠름, 연속성이 중요한 서비스에서 자주 사용됨(ex. 실시간 스트리밍)
-
HTTP
Request - Response 구조
무상태성 => 서버 증설에 유리
그 이유는..
상태를 가진다면 중간에 에러 생기거나 서버가 중단된다면,
다른 서버에 처음부터 다시 정보를 보내야 함
무상태성은 한번에 필요한 정보를 다 담아 보내기 때문에,
다른 서버에 요청을 보내면 됨
상태를 유지해야 하는 경우 => 브라우저 쿠키, 서버 세션 등으로 보완 -
HTTP 특징
연결을 유지하지 않음
초 단위 이하의 빠른 속도의 응답
1시간 동안 수천명이 서비스를 이용해도, 서버가 동시에 처리하는 양은 수십개 이하로 적다
TCP/IP 연결을 새로 맺어야 함
HTML 뿐만 아니라 수 많은 자원을 함께 다운로드
HTTP 지속 연결로 문제 해결 => 연결과 종료로 낭비되던 시간이 지속 연결이 가능해지면서 시간 절약
HTTP/2, HTTP/3 에서 더 많은 최적화 -
헤더
컨텐츠 협상(content negotiation)
선호 하는 언어에 대해서 우선순위 부여가능(0~1)
ex) ko;q=0.9,en-US;q=0.8 (클수록 높은 우선순위)
cache-control을 통해 유효한 캐시 시간을 설정가능
캐시 유효기간이 초과되면 다시 요청을 보내게 되고, 유효기간이 재설정된다
이때, 데이터가 변경되지 않은 경우 다음과 같이 조건부 요청을 통해 데이터를 그대로 사용할 수 있다
Last-Modified 속성 => 최종 수정 시간
If-Modified-Since
1) 데이터에 변경사항이 있는지 검증
2) 조건 확인
이때, 캐시 유효시간이 초과되었으나, 서버의 데이터가 수정되지 않은 경우
304 Not Modified + 헤더 메타데이터로 응답, 바디가 없음
클라이언트 위 응답을 통해 캐시의 메타데이터 갱신, 재사용
바디를 다시 다운로드할 일을 줄이기 때문에 실용적인 사용책
단점으로는
1초 미만의 조정이 불가능
날짜 기반의 로직
데이터를 수정해서 최종 수정날짜가 다르지만, 데이터 내용은 같은 경우
서버에서 별도의 캐시 로직을 관리하고 싶은 경우
Etag와 If-None-Match 검증헤더 사용으로 더 간단하게 사용가능
서버에서 헤더에 ETag를 작성해서 응답하면, 클라이언트의 캐시에서 해당 ETag값을 저장
캐시 유효시간이 초과되면 If-None-Match를 요청 헤더에 작성
Cache-Control: max-age(유효시간), no-cache(데이터는 캐시해도 되지만, Origin 서버에서 검증하고 사용), no-store(저장하지 않음)
Expires 로 날짜로 지정할 수 있지만, 현재는 위 옵션들을 선호함, 위 옵션이 있으면 무시되는 옵션 -
프록시 캐시
클라이언트 - 프록시 캐시 서버 - 서버
위와 같이 원 서버와의 거리가 멀거나 오래 걸리는 경우, 프록시 캐시 서버를 두어 클라이언트가 프록시 캐시 서버에서 데이터를 받을 수 있음
여러 사람이 찾은 자료일 수록, 캐시 서버에 등록되어있기에 빨리 받을 수 있음
Cache-Control:
public 응답이 public(프록시)에 저장되어도 됨
private 응답이 해당 사용자만을 위함, private(개인 브라우저)에 저장되어야 함
must-revalidate
캐시 만료 후 최초 조회 시 원 서버에서 검증해야함
원 서버 접근 실패 시 반드시 오류 발생
캐시 유효 시간이라면 캐시를 사용함
s-maxage 프록시 캐시에만 적용되는 max-age
Pragma: no-cahce, HTTP 1.0 하위호환
Age: 오리진 서버에 응답 후 프록시 캐시 내에 머문 시간 -
no-cache vs must-revalidate
no-cache의 경우 프록시와 원서버의 연결이 안되는 경우, 갱신되지 않는 데이터라도 보여줌
이때, 계좌 정보나 중요한 정보를 받아야할 때, 갱신되지 않은 정보를 받으면 문제가 생김!
must-revalidate는 원 서버 접근 실패시 504에러를 발생 -
CDN(Content Delivery Network)
원본을 복사하여 저장할 여러개의 캐시 서버로 구성
데이터를 전달하기 가장 유리한 서버에서 콘텐츠 제공
위치상으로 가장 가까운 서버가 우선순위 -
정적 , 동적 콘텐츠
정적
내용이 거의 변하지 않는 콘텐츠
HTML, 동영상
변화가 없는 콘텐츠
개인하되지 않은 대중적인 콘텐츠
캐시 서버에 저장하기 적합
동적
접속할 때마다 내용이 바뀌거나 사용자마다 다른 내용을 보여주는 컨텐츠
위치, IP, 사용시간
카드번호, 전화번호 등 개인화된 정보 컨텐츠
컨텐츠가 바뀔 때마다 서버에 바뀐 컨텐츠가 전파되어야 함 -
CDN의 이점
DDOS공격에 대해 어느정도 대응 가능
로딩속도 증가
트래픽 분산 -
Scattered, Consolidated 방식
Scattered 방식
최대한 빠른 응답속도 목표
세계 곳곳에 낮은 성능의 데이터 센터를 구성
관리비용이 높다 > 사용자에게 부담
Consolidated 방식
고성능의 데이터 센터 운용
응답시간 증가, 관리비용 감소
연결 수요가 많은 지역에 적합
