# URL 단축기

### API Endpoint

클라이언트가 서버와 소통하기 위해 거치는 관문

- URL 단축용 엔드포인트 : URL 단축 요청이 오면 결과를 반환한다.

- URL 리다이렉션용 엔드포인트 : HTTP(S) 요청을 새 URL로 돌린다. (301 or 302)

### URL Redirection

- 301 (Paermanently Moved)

    - 영구적으로 URL이 리다이렉션되기 때문에 브라우저는 반환된 URL을 캐싱한다.

    - 그리고 나중에 요청을 보낼 때 브라우저 단에서 URL을 바꿔서 보낸다.

    - 이거 테스트 환경에서 잘 못 쓰면 많이 귀찮다.

- 302 (Found)

    - 일시적으로 리다이렉션된다

    - 매번 URL 단축기 서버를 거쳐 가기 때문에 트래픽 분석하기 좋다.

### URL 단축

- 긴 URL을 해싱해서 짧은 URL을 만든다.

- 짧은 URL을 긴 URL로 복원해야 한다.

## 설계

### 데이터 모델

- 해시 테이블 : 유용하지만 메모리는 비싸다.

- RDBMS : 단축 URL을 인덱스로 삼고 찾는다.

### 해시 함수

- 단축 URL은 숫자와 알파벳으로만 구성된다. ⇒ 한 문자에 62개의 경우의 수가 나온다.

- (추정치에 따르면) 3650억 개의 URL을 만들어야 하므로 7자리면 충분하다. (62^7 \approx 3.5 \times 10^{12})

### 해시 충돌 해소

- 해싱을 하면 충돌이 발생하고 충돌을 해소하기 위해서는 임의의 문자열을 덧붙여야 한다. 

- 이렇게 하면 DB에 질의가 많아지고 성능이 저하된다.

- DB 대신 블룸 필터를 쓰면 공간 효율이 좋아진다.

    - false positive를 감안해도 거의 대부분을 거를 수 있다.

### base 62 변환

- 앞서 한 문자에 62개의 경우의 수가 나온다고 했다. (숫자와 알파벳)

- 긴 URL은 결국 0과 1로 된 비트맵이다.

- 긴 URL을 62진법으로 변환한다.

### base 62 계산

- 62 진법 대신 64 진법을 쓴다고 가정

1. 긴 URL을 DB에 저장하고 레코드 ID(숫자) 반환

2. ID를 base62로 단축

## 동작

1. 클라이언트 → 웹 서버 : URL을 묻는다.

2. 웹 서버 → 캐시 : 캐시를 뒤져본다.

3. 웹 서버 → DB : 캐시가 miss 나면 DB를 찾는다.

4. 웹 서버 : DB도 miss 나면 단축 URL을 생성하고 DB에 저장한다.

    1. 캐시에 저장할 지는 캐시 전략에 따라 다르다.

5. 웹 서버 → 클라이언트 : 결과를 반환한다.

For the site tree, see the [root Markdown](https://slashpage.com/kaonmir.md).