과정을 즐기자

개발바닥 장학 퀴즈를 정리해 보자 본문

Network

개발바닥 장학 퀴즈를 정리해 보자

320Hwany 2024. 7. 31. 16:51

이번 글에서는 개발바닥 유튜브 채널에 있는 개발바닥 장학 라이브 퀴즈를 같이 보고 정리해보려고 합니다.

꽤 오래전에 본 영상인데 최근에 다시 보다가 재밌는 이야기가 많아 글로 써보려고 합니다.

 

 

📕 창의력 쑥쑥 문제 1

 

👍 서버 제한 풀기

앱에서 서버로 이미지를 전달하는데 5MB를 초과할 때 문제가 발생합니다.

뭐 간단하게... 서버 5MB 제한을 풀면 될 거 같지만 문제의 조건에는 맞지 않습니다.

그래도 생각해보자면 Spring Boot를 사용할 때 application-yml, application-properties 와 같은 설정을 수정할 수 있습니다.

spring:
  servlet:
    multipart:
      max-file-size: 100MB
      max-request-size: 100MB

 

이외에도 Nginx, Apache와 같은 웹서버를 사용한다면 해당 웹 서버의 설정을 변경해줄 수도 있습니다.

👍 앱에서 분할하여 전송

다음으로 생각해볼 수 있는 것을 클라이언트 쪽에서 이미지를 분할하여 전송하고 서버에서 합치는 방법이 있습니다.

 

이미지를 Base64 인코딩하여 나온 텍스트를 분할하여 전송할 수도 있습니다.

Base64로 인코딩하여 처리하면 텍스트를 처리하는 것이라서 조금 더 간편하게 처리할 수 있습니다.

하지만 데이터 크기가 약 33% 정도 증가한다는 단점이 있어서 처리 성능에는 좋지 않을 수 있습니다.

 

다음으로 이미지 파일을 바이트 배열로 읽고 이를 일정 크기로 분할하여 전송할 수도 있습니다.

인코딩, 디코딩 과정이 없이 바이트 데이터를 직접 처리하기 때문에 처리 속도가 더 빠릅니다.

하지만 파일을 쪼개서 업로드하고 서버에서 합치는 과정에서 조금 더 코드가 복잡해질 수 있다는 단점이 있습니다.

이 부분은 코드로 한번 살펴보겠습니다.

 

 

대용량 파일의 처리까지 생각해본다면 병렬 처리까지 가능하여 더 효율적일 수도 있을 것 같습니다.

 

👍 앱에서 압축하기

다음으로 앱에서 압축을 해서 보내는 방법도 생각할 수 있습니다.

안드로이드를 기준으로 하면 Picasso, Glide, Compressor 등과 같은 다양한 라이브러리가 있습니다.

앱에서 해당 라이브러리를 사용하여 이미지를 압축한뒤 서버에 전송을 하는 방식입니다.

압축을 해서 데이터 전송량을 줄여 데이터 전송 속도를 높일 수도 있습니다.

하지만 압축에 소요되는 시간도 있기 때문에 이 부분에 대해서는 테스트를 해보고 사용해야할 것 같습니다.

 

또한 손실 압축의 경우에는 이미지 파일의 해상도가 떨어질 수도 있습니다. 

 

  • 손실 압축은 파일 크기를 줄이는 데 효과적이지만, 품질과 해상도가 저하될 수 있습니다.
  • 무손실 압축은 품질과 해상도를 유지하지만, 파일 크기 감소의 폭이 제한적입니다.

 

👍 파일 서버 사용하여 백엔드 서버에는 이미지 URL만 전송

파일 서버를 따로 사용한다면 그곳에 이미지 파일을 저장하고 이미지 URL만 백엔드 서버로 전송할 수도 있습니다.

그래서 백엔드 서버의 부하를 줄일 수도 있습니다.

 

⛳️ 정답 확인

 

 

📕 창의력 쑥쑥 문제 2

 

👍 만료기간이 긴 토큰 사용...?!

현재는 세션 클러스터링 개발이 안되는 상황입니다. 즉, RDB나 Redis에 토큰이나 세션 정보를 저장할 수는 없습니다.

JWT와 같은 토큰을 사용한다면 보통 RefreshToken은 RDB나 Redis에 저장하고 AccessToken은 따로 저장하지 않고

사용자만 들고 있습니다. RefreshToken은 AccessToken을 재발급하거나 중복 로그인 방지 등에 사용될 수 있습니다.

하지만 세션 클러스터링 개발이 안되기 때문에 만료기간이 긴 AccessToken을 사용한다면 단기적으로는 해결해볼 수 있을 것 같습니다.

하지만 보안에는 취약해질 수 있겠네요... 😅

 

👍 서버를 1대만 사용...?!

각 서버에 로그인 정보를 가지고 있기 때문에 서버를 1대만 사용하면 해결됩니다....

좋은 방법은 아니지만 Stateless한 HTTP 환경에서 로그인 관리를 위해 세션 클러스터링의 중요성을 알려주는 문제 같습니다...!

 

👍 sticky session 사용

sticky session은 로드밸런서가 세션 기간 동안 동일한 클라이언트의 request를 항상 동일한 서버로 라우팅 해주는 기능입니다.

이렇게 하면 사용자가 항상 로그인 정보를 가지고 있는 서버로 요청을 보내기 때문에 로그인을 유지할 수 있습니다.

하지만 특정 서버에 과부하가 발생할 수 있기 때문에 트래픽이 균등하게 배분되지 않을 수 있습니다.

Stateless한 HTTP가 가진 장점을 역행하는 해결 방법인 것 같고 요즘에는 거의 사용하지 않을 것 같습니다.

 

⛳️ 정답 확인

 

저작자표시

'Network' 카테고리의 다른 글

HTTP의 버전별 특징(0.9, 1.0, 1.1, 2.0)  (0) 2023.11.17
서버가 처리할 수 있는 요청의 수는 어떻게 결정될까?  (0) 2023.08.31
애플리케이션 계층(L7)이 하는 일  (0) 2023.08.10
로그인 방식 비교하기 (세션 방식 VS 토큰 방식)  (0) 2023.08.06
트랜스포트 계층(L4)이 하는 일(feat. 포트, TCP, UDP, QUIC)  (0) 2023.07.27
'Network' Related Articles more