생각을 개발하자, 박진형

TIL - 0808

웹서버 캐시해보기(2)

기간 만료되지 않았지만 갱신하기

  • 패스별로 캐시를 하기때문에 리소스 이름에 파라미터를 붙여줘서 다시 캐시하도록 함
    • 그렇다면 서버에 쌓인 기존 리소스 처리는? nginx에서 캐시 설정을 해줄 때 기간을 설정하기때문에 지워짐(실제로는 누가 지우지?)
    • 생각해볼 수 있는 문제 : 자주 변경될 수 있다면 제한된 범위 내에서 파라미터를 설정해주기(완전한 랜덤값으로 설정하면 그만큼 많은 파일이 서버에 캐시될 수 있기 때문에 - 그런 상황을 만나봐야알겠지만..)
  • 비정기적으로 변경될 수 있는 정적인 리소스에 대해서는 파라미터를 달아줌으로써 클라이언트가 오래된 캐시 데이터를 그대로 가져다가 쓰지 않도록 할 수 있음
  • 내부적으로 요청 정상적으로 동작하는지 테스트 : curl(커맨드라인용 데이터 요청툴)

HTTP

HTTP 메세지

  • HTTP 어플리케이션 간의 주고 받는 내용 : 요청 - 응답
    • 인바운드(서버로의), 아웃바운드(클라이언트로의) : HTTP 트랜잭션 상에서의 목적지를 말함
    • 다운스트림, 업스트림 : 수신자의 경우 업스트림이고, 발신자의 경우 다운스트림임 고로 클라이언트도 서버도 둘 다 흐름에 따라 됨

메세지 구성

  • 시작줄 / 헤더 / 바디 (헤더와 바디 사이에는 공백인 줄이 있음 - 구분을 위해서, 바디가 없을 경우 공백으로 끝), 바디는 바이너리 데이터나 텍스트 모두 올 수 있고 시작줄과 헤더는 문자열
  • 메세지 종류
    • 요청 메세지
    • 응답 메세지
GET / HTTP/1.1
Host: www.naver.com:443
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
X-DevTools-Emulate-Network-Conditions-Client-Id: E769A147B7E0D67DE55241A555604472

HTTP/1.1 200
cache-control: no-cache, no-store, must-revalidate
content-encoding: gzip
content-length: 29212
content-type: text/html; charset=UTF-8
date: Wed, 08 Aug 2018 01:57:52 GMT
pragma: no-cache
referrer-policy: unsafe-url
server: NWS
status: 200
strict-transport-security: max-age=31536000; preload
vary: Accept-Encoding
x-frame-options: SAMEORIGIN

주요 HTTP 메소드

  1. GET : 가져오기 요청
  2. POST : 데이터를 주고 처리 요청(생성)
  3. PUT : 데이터를 주고 처리 요청(수정)
  4. DELETE : 삭제 요청, HTTP 명세에서 요청 무시를 허용함

주요 상태코드

  1. 2xx : 성공
  2. 3xx : 리다이렉션하도록(304는 리소스 Not Modified 일 때 사용)
  3. 4xx : 클라이언트 에러
  4. 5xx : 서버 에러(신경쓸 것)

연결리스트

Doubly LinkedList

  • Simple LinkedList에 비해서 앞뒤로 왔다갔다 할 수 있으니깐 탐색할 때 더 좋기야하지만 그래도 순차탐색을 해야하므로 탐색에 유리한 배열보다는 좋지못함
  • 같은 타입끼리 하나로 묶지만 연속적인 메모리 공간을 빌려놓고 저장하는게 아니라 떨어져있는 데이터를 하나로 묶어낼 때 사용
  • 빈번한 중간삽입(단 순차 삽입 - head, tail은 배열보다 훨씬 적게 걸림)에 적합한 자료구조가 아님, 특정 요소를 찾아갈 때 적합한 요소도 아님
    • 순차에 어울림, 고정적인 크기를 선언해두고 저장하지않고 효율적으로 동적 저장을 하려면 연결리스트를

기타

System.out.println으로 로그 찍어보는 대신에 로깅 라이브러리(Logback)를 사용하는 이유

  • System.out.println의 비효율 : println() > newLine() - 메소드 synchronized(동기처리 메소드)로 처리함, 여러 쓰레드가 println을 호출했을 때 순차적으로 처리함(시간이 많이 걸릴 수 밖에 하나 박아두고 여러 쓰레드가 호출하면…)
    • System.out은 PrintStream 타입 객체 : 표준출력(시스템 콘솔) 객체(싱글턴)
    • Logback과 같은 범위 출력을 했을 때 Logback 사용했을 때 더 짧게 걸림(Logback 까보기)
  • 생산성을 높여줌 : 로그가 레벨로 나뉘어져있기때문에 일일이 다 지우러 다니지않고 노출 레벨을 조절하면 노출 시키지 않을 수 있으므로 편함
    • ERROR > INFO > DEBUG : 주로 사용하는 것만 적음, 왼쪽부터 가장 높은 레벨, 가장 낮은 레벨로 설정해두면 로그 모두가 찍히고, 가장 높게 설정해두면 아래 레벨은 모두 출력되지않음
  • 모든 로그의 공통된 형식을 지정할 수 있음
<!-- logback.xml : 로그백 사용 설정 파일 -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration>
<configuration>
	<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
		<layout class="ch.qos.logback.classic.PatternLayout">
			
			<!--로그 패턴 지정-->
			<Pattern>%d{HH:mm:ss.SSS} [%-5level] [%thread] [%logger{36}] - %m%n</Pattern>
			
		</layout>
	</appender>
	
	<!-- 디렉토리별로 노출 레벨을 설정할 수 있음 -->
	<logger name="codesquad" level="DEBUG" />
	
	<root level="INFO">
		<appender-ref ref="STDOUT" />
	</root>
</configuration>