어플리케이션 성능 개선

• banwidth와 latency : latency 이슈가 더 많음(얼마나 빠르게 응답을 주느냐) - 서버와의 거리, 우리 개발력(서버 처리 시간…, 동적인 컨텐츠에 대한 처리)
  • CDN : 지역마다 컨텐츠만 전달하는 용도로 두는 서버, latency를 낮추기위해서 물리적인 거리를 줄임(리전 별로 - 전세계 주요 거점에 서버를 둠) - 정적인 콘텐츠

성능 이슈

• css, js, img 자원에 대한 응답이 가장 많이 생김, 특히 이미지

개선 방법

캐시

• 한번 다운로드 받은 파일을 다시 다운로드 받지 않는 것 : 무작정 하면 안되고(재사용 가능한 리소스 - 정적인 자원) -> 서버(웹서버) 설정에 따라 캐시하느냐 마느냐 정할 수 있음
  • WAS가 아니라 웹서버에서 설정 : 리소스 마다 캐시하냐? 아니면 특정 디렉토리에 넣고 설정하면 리소스에 모두 설정이 되는가?
  • disk cache(특정 디렉토리에 파일로 다운로드를 받아둠), memory cache

• Cache - Control : 서버 개발자가 결정해야할 부분

• ETag : 캐시 만료 기간에 도달했을 때 클라이언트가 서버로부터 받은 ETag 값을 서버에 요청해서 사용 계속해도 되는지 물을 때 리소스를 식별하는 값
  • 다운로드를 무조건적으로 다시 받는게 아니라 304 응답이 왔을 때 그대로 사용 : 다운로드 안해도 됨
  • ETag는 서버에서 만들어지고 관리하지않음 : 해시값을 만들고 응답해줌, 알고리즘으로 똑같이 해시를 만들었을 때 있으면 304 응답, 우리는 만들 필요없이 설정만 하면 됨
  • ETag에 해당하는게 없으면 200으로 보내면서 바디에 새로운 컨텐츠를 보내줌
  • 리소스 마다 거는게 아니라 특정 규칙으로 걸어버림(정규표현식), 패스단위로
  • 그럼 만료기간이 아님에도 이미 수정된 경우는 어떻게 해결하나? 클라이언트(브라우저)는 패스 기준으로 캐시함 - 캐시 무효화하려면 패스(이름)자체를 바꿔버리면 됨(배포 시간을 파일 이름으로 하면), 문제점이라면 패스 변경에 대해서 생각을 해야함(리소스 패스 - 동적으로 동작할 수 있게 구성할 수 있어야함) 그닥 큰 문제점은 아님 성능상의 이점이 크기 때문에(bandwidth 훨씬 적게 잡아먹게됨 - 주고 받는 데이터양이 줄어들기때문에)

압축

• 압축하고 압축을 푸는 것에 비용이 듬 : 투자 대비 효과가 좋아야할 수 있음
  • 압축률이 높아야 그만한 비용을 감안하고 할텐데 : text는 압축률이 굉장히 높으나 이미지는 이미 압축이 되어있는 형식을 사용하기때문에 압축률이 높지않아서 사용할 필요성이 없음(성능 관점에서 손실되는 비용이 더 큼)
  • gzip 알고리즘이 가장 많이 사용됨

요청 수 줄이기

• css sprite : 캐시도 가능
• js 줄이기 : 웹팩을 통한 파일 합치기와 같은 작업을 함
• 이미지 경로에 data: : 이미지 데이터를 가지고 있음(바디로 다운로드 받는게 아니라 태그에) - 이미지에 대한 서버에 재요청을 하는게 아니라 그대로 읽어서 랜더링

멀티쓰레드 요청

• 클라이언트 마다 다르지만 멀티쓰레드로 요청을 한꺼번에 보내서 응답을 받는 방식도 있음
  • 순차적으로 요청을 보내서 응답받고 랜더링하는 것보다 더 빠른 처리처럼 보여질 수 있음
  • 서버는 그냥 똑같이 응답해주는거 : 어차피 멀티쓰레드 처리

커넥션 재사용 keep-alive

• 소켓 연결을 위해 기본 3번을 통신해야함(기본적인 latency) : 서버 체크, 클라이언트 정보 체크 등을 해야함(3way handshake - 소켓 연결을 위한 서로 간의 신뢰 형성)
  • HTTP의 경우 이 커넥션을 하나의 리소스만 주고 받고 끊어버림 : 리소스 개체 수가 많을 경우 커넥션을 그만큼 다 만들어야함
  • HTTPS는 더 걸림 : 암호화 key(인증서)를 서로 주고 받아야하기때문에
• keep-alive : 1.1부터 기본으로 들어간 옵션, 커넥션(소켓) 재사용
  • 기본적으로 1.1은 Connection: close를 해야 keep-alive
• 쓰레드를 붙잡고 있는 것으로 1.1을 사용한다면 기본적으로 close로 하고 필요한 부분만 그대로 두면 되는

서비스 성능 측정

• 구글 스피드 사용해서 어느 부분이 취약한지, 얼마나 잘 구성되어있는지 체크해보기

클라이언트 - 서버 식별

• IP, PORT 각각 2개 총 4개로 각각을 식별함

Spring-security

OAuth2 Type

• Implicit Grant : 클라이언트가 인증서버에 요청을 직접 날리고 응답으로 액세스 코드를 받고, 서버에 액세스 코드를 넘겨주고 서버가 액세스 코드를 인증 서버에 물어봐서 발급해준 코드가 맞으면 jwt를 만들어서 만료 기간 전까지는 인증서버로 요청없이도 인증하는 방식
  • 액세스 코드를 가지고 jwt를 만들어서 상태 저장없이(쿠키, 세션 사용x) 사용자 인증을 할 수 있게함 : jwt에 필요 정보가 있음, 만료 전 까지는 인증된 사용자라는 표식
• 왜 액세스 코드는 클라이언트가 받고, 액세스 코드를 서버로 전달해서 jwt를 응답 받는 방식으로 만들까?
  • 위 질문에 대한 대답은 부하를 줄이기위한 방법? 부하 분산을 위한 방법이 아닐까 함 : 인증 서버를 제공하는 쪽에서 자바스크립트로 요청할 수 있는 방법을 제공하기떄문에 서버를 거치지않더라도 바로 요청을 할 수 있도록 하는게 아닐까 함, 서버가 모든 것을 처리하지않고 클라이언트에서도 부담하도록 구현하는 것이 아닐까 생각됨
  • 또 왜 액세스 코드를 jwt로 만들어야할까? 아 액세스 코드에는 만료기간, 삽입하고 싶은 데이터 등 필요한 정보를 설정할 수 없기떄문에 json으로 만든 별도의 웹토큰을 만들어주는거군!