[Chapter 08] Q&A

[travelbeeee]

[Chapter 08] URL 단축기 설계

• 궁금한 점 혹은 이야기하고 싶은 주제 코멘트로 정리
• 추가로 같이 보면 좋을 것 같은 기술 블로그, 아티클 등 공유

[travelbeeee]

현석

• 블룸 필터
  • m 비트와 k개의 해시 함수를 이용해 어떤 원소가 집합에 속해있는지 여부를 확률적으로 빠르게 판단하는 알고리즘
  • 확률적으로 판단하는 알고리즘이기 때문에 100% 원소가 집합에 속해있는지 여부를 알 수는 없음. ( 다만, 굉장히 높은 확률 )
  • 동작원리
  • A 원소를 k 개의 해시 함수에 각각 넣는다.
  • 해시 함수 결과에 해당하는 비트에 1 로 표현한다. ( m 비트 중 )
  • 어떤 a 원소가 집합에 속해있는지 판단하려면 k 개의 해시 함수에 넣고, 결과에 해당하는 비트가 모두 1인지 체크하면 된다.
  • 블룸 필터가 만들어지고 이미 N 개의 원소가 들어가있다면, 특정 원소를 제거하려면 N 개의 원소를 모두 k 개의 해시함수에 넣고 결과를 확인해야된다. ==> 원소 삭제가 굉장히 어렵다.
• 카운팅 필터
  • 블룸 필터에서 원소 삭제가 어려운 점을 보완한 기술
  • m 비트에 0 / 1을 저장하는 것이 아니라 정수를 저장
  • 각 비트에 적힌 숫자는 해시 결과로 해당 비트가 나온 원소의 개수
  • => 원소를 삭제할 때, K개의 해시 함수에 넣고 결과로 나온 비트의 값을 -1 씩 진행해주면 된다.

[easyfordev]

이지

• Q. URL redirection에서 301과 302의 장단점을 설명하는 부분이 이해가 잘 가지 않습니다. 설명해주실 분 구합니다 ㅎㅎ
  • 내용 : 서버의 부하를 줄이는 것이 중요하다면 301을, 트래픽 분석이 중요하다면 302를 선택해라
• Q. 책에서 해시 후 충돌 해소 내용 중 '충돌이 해소될 때 까지 사전에 정한 문자열을 해시 값에 덧붙인다'고 했는데, 이게 한번 생성된 해시값에 덧붙이는건지? 아니면 맨 처음에 요청 들어온 long URL에 덧붙이는건지?
• 참고 : 책에 나온 RESTful 링크 : https://www.restapitutorial.com/index.html
  • 면접때 물어봤었는데 추억이네요
  • 개인적으로 정말 도움이 되었던 DEVIEW 발표 링크 - 그런 REST API로 괜찮은가 https://tv.naver.com/v/2292653
• 블룸 필터가 또 나왔다. 블룸 필터에 대해 잘 알아둘 필요가 있겠다.

[zziri]

지훈

• 블룸 필터가 유용한듯해서 세부 구현이 궁금
  • https://starrykss.tistory.com/1243?category=606547
• 301은 캐싱을 하고 302는 캐싱을 하지 않음
  • 성능은 301이 유리하지만 URL Shortener 서버로 유입되는 트래픽을 측정하려면 캐싱을 하지 않는 302로 리다이렉션해야함
  • 301은 캐싱되므로 여러번 요청해도 최초 한번만 URL Shortener 서버로 요청
• base 62는 62진법이고 base 64는 뭐지
  • https://en.wikipedia.org/wiki/Base64#Design
  • padding은 무엇..?
    • https://parsiya.net/blog/2017-08-06-tldr-base64/

[kihyun-yang]

기현

• 301 Permanent Moved는 서버의 부하를 줄이는데 좋다. (책에서 언급)
  • 브라우저에서 Location 헤더에 반환된 원본 URL을 캐싱하므로
    • https://cherrypick.co.kr/avoid-location-header-cache-in-brower-using-303-http-code/
• 302 Found는 트래픽 분석(클릭 발생률, 발생 위치 추적)하는데 좀 더 유리하다. (책에서 언급)
  • 의문 > 단축 URL 서버 입장에서 트래픽 분석하기 좋다는 것인가?
    • 301을 통해 브라우저에 캐싱된 Location 헤더를 사용하면 첫 요청만 단축 URL 서버로 전송되고, 이후 요청 부터는 단축 URL 서버를 거치지 않으므로 301은 302에 비해 트래픽을 분석하기 어려운 것인가?

[meloncha]

민석

base-62 변환

• 진법 변환은 수의 표현 방식이 다른 두 시스템이 같은 수를 공유하여야 하는 경우에 유용하다 -> 이 부분이 잘 이해가 가지 않습니다. 아시는 분 부탁드려요

base-64 가 유명한데 왜 base-62을 쓸까?

• base 64는 64진법이라는 뜻으로 base 62 (0-9, a-z, A-Z) 에 추가로 특수문자 2개를 사용
• 8비트 이진 데이터(zip, 이미지 파일등)을 문자 코드에 영향을 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식
• 책의 제한 규칙이 없더라도 64보다 62를 더 자주 사용하는데 base-62를 쓰는 이유는 64의 경우 특수문자가 포함되어 query string이 제대로 작동하지 않을 가능성이 있기 때문에 문제 상황을 미연에 방지

[janeljs]

A RESTful Tutorial

• https://www.restapitutorial.com/

해시 후 충돌 해소(133)

• dt 파라미터를 추가하면 안되는가? 왜 같은 문자열을 계속 추가하는가?
  • longUrl 뒤에 decoding 가능한 값 추가해야
• https://uiandwe.tistory.com/1324

base-62 변환

• 11157은 pk?
• pk 대신 해시값을 shortUrl로 제공하는 이유는? 보안상 문제있는 건 마찬가지 아닌가?
  • 자리수 맞추려고

직접 만들어보자!

• https://github.com/Jane-s-Lab/url-shortner

[KKambi]

한비

왜 단축 URL을 사용할까?

1. 기억하거나 전송하기 쉬우며, 길이 제한이 있는 서비스에서 사용할 수 있다 ex) 트위터, 문자
2. URL 단축기에 분석 엔진을 연동할 수 있다.
3. 원래 URL을 숨기기 위한 스팸 메세지에 사용되기도 한다
4. 보안문제 (redirection되는 곳을 클릭하는 사람이 전혀 알 수 없다 / 사이트에서 자체적으로 URL 검사할 수 없다)
5. 일부 기업은 단축 서비스 제공 중지 (네이버, 구글)

SHA-1 해시 함수

임의의 입력데이터 -> 160비트 출력데이터

• 원리: 너무 복잡해서 이해 안됨
• 문제: 취약성이 발견되어 사용 자제 -> SHA-2 & SHA-3 사용 권고