s3와 cloud front 배포 후 403 forbidden AccessDenied 에러가 뜬다면 ? s3에서 접속을 했을 경우 퍼블릭 엑세스 권한을 허용해두지않으면 403 forbidden AccessDenied 에러가 뜨는 것은 정상이다. cloudfront로 제어가 목적이라면 그대로 두면된다. 문제는 cloudfront로 배포한 url에 접속시 뜨는 AccessDenied 에러인데, s3 정책 설정까지 모두 제대로 완료했을 경우에는 리전만 추가 등록해준다면 가볍게 해결할 수 있다.

cloudfront 접속 후 원본 > 원본체크 > 편집 순으로 접속한다.

맨 하단에 Enable Origin Shield에 리전을 본인이 지정하고자하는 지역에 선택해 변경 사항을 저장한다.

다른 설정이 빠진게 없다면 cloudfront 배포 주소로 정상 접속되는 것을 확인할 수 있다.

1. AWS S3 CloudFront 배포하는 법
2. Github Action CI/CD 적용하기

2024.09.09 기준 작성된 포스팅입니다.

먼저 s3 cloudfront 배포방법이 알고싶다면 하단 포스팅을 참고할 수 있다.

• s3 cloudfront 배포방법 알기
• workflows 스크립트 명령어 정리

개념과 함께 아는 것이아니라 순서대로 cicd를 적용하고 싶은 사람은 목차 중에 순서대로 github cicd 준비하기를 바로 참고하길 바란다.

github-cicd

먼저 아래는 작성한 전체 workflow.yml 파일이다.

name: DEV CI

on:
  push:
    branches: ["dev"]
  pull_request:
    branches: ["dev"]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Create dotenv file
        run: |
          touch .env
          echo "VITE_BASE_URL=${{secrets.VITE_BASE_URL}}" >> .env 
 # ... env 파일에 생성할 객체 echo 명령어로 추가하기        
          cat .env

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: yarn # yarn으로 설정

      - name: Yarn install
        run: yarn

      - name: Yarn build
        run: yarn build

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Deploy to S3
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.DEV_AWS_S3_BUCKET_NAME }}
          SOURCE_DIR: "dist"

      - name: Invalidate CloudFront Cache
        run: aws cloudfront create-invalidation --distribution-id ${{ secrets.DEV_AWS_DISTRIBUTION_ID }} --paths "/*"

workflows를 통해 할 수 있는 동작

workflows 작성이 어색한 사람들은 해당 섹션을 가볍게 읽어보면 이해하는데 조금 도움이 될 것이다.

1. 특정 브랜치에 push가 일어났을 때 동작 지시하기( = 트리거 조건 설정)

깃 브랜치별로 push가 일어났을 때 다른 동작을 수행하게 하려면 on: 명령어를 통해 동작이 일어날 브랜치를 지정할 수 있다. 해당 스크립트로 main 브랜치와 dev브랜치를 구분하여 배포나 테스트 작업에 구분을 둘 수 있다. 추가적인 스크립트로 매번 수동으로 하던 빌드 -> 업로드 -> 배포 -> 캐싱 무효화 등등과 같은 작업들을 한번에 끝낼 수 있다.

2. 미리 작성해둔 aws 권한으로 번거로운 수동 aws 작업 줄이기

aws access key와 secret access key와 같이 노출되면 안되는 정보들은 미리 github secrets에 등록해둠으로써 보안을 강화할 수 있다. 이때 저장해둔 값들은 workflow에 미리 등록해둔 key를 이용해 불러와 사용할 수 있다. 이때 주로 저장되어 사용하는 값이 aws 권한 인증에 필요한 aws access key와 secret access key이다. 해당 작업은 상단에 작성된 전체 스크립트에 Configure AWS Credentials 부분에 해당한다.

3. github action으로 s3에 빌드파일 자동 업데이트하기

name 스크립트로 구간별 동작을 지정할 수 있다. 이 때, 파일 빌드 작업일 경우 jobs 스크립트 안에 실행될 환경을 설정할 수 있다. 위 스크립트는 우분투 최신버전으로 동작하도록 작성되었다. 후에 순차적으로 strategy.matrix로 node버전을 설정,uses-with 스크립트로 배포파일 지정 등 동작을 지정해둘 수 있다. 마지막으로 env환경 변수에 aws bucket 이름을 지정해줌으로써 파일 업로드가 완료된다. 스크립트에 dist는 해당 스크립트의 프로젝트가 vite-react기준이라 build파일이 dist폴더내에 저장되었기 때문에, dist로 작성되었다.

4. s3업로드 완료 후 cloudfront 캐싱 무효화하기

cloudfront의 장점은 캐싱이 된다는 장점이 있지만, 새로 업데이트를 할 경우 수동으로 캐싱을 무효화해줘야한다. 이ㄸㅐ 할 작업을 workflow에 함께 작성할 수 있다. 아래 명령어를 참고하면 된다. AWS_DISTRIBUTION_ID에는 cloudfront id값을 git secret에 AWS_DISTRIBUTION_ID 변수명으로 작성해주면된다.

      - name: Invalidate CloudFront Cache
        run: aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_DISTRIBUTION_ID }} --paths "/*"

순서대로 github cicd 준비하기

이제 본론으로 들어가 순서대로 cicd를 적용해보자ㅏ.

순서를 간략하게 요약하면 아래와 같다.

• aws 권한 부여를 위한 aws access key 발급
  • 권한 부여 방법은 따로 IAM 계정을 생성해서 해도 되지만 이번 포스팅에는 access key를 직접적으로 활용하였다
• git secret 등록
• workflows .yml 파일 작성

1. aws access key 발급

aws에서 우측 상단에 아이디 탭을 누르고 보안 자격 증명 메뉴를 클릭한다.

용도에 맞게 사용 사례를 선택한다.

생성된 엑세스 키는 보안을 위해 따로 저장하지 않는 편이 좋으며, 생성시에 바로 깃허브 레포 secret에 등록하는 편이 좋다.

2. Git secret 추가

발급받는 엑세스키워 시크릿 엑세스 키를 두고 아래 경로로 접속하여 새로 변수를 등록한다.

접속 순서 : cicd 적용할 레포 > 설정 > secrets and variables > action > new repository secret

아래와 같이 원하는 변수명으로 변경/등록 할 수 있다.

작성된 내용을 github내에서도 두번은 볼 수 없으니 혹시나 잊을까 걱정된다면 다로 메모해둬도 좋지만, 보안을 걱정한다면 주기적으로 엑세스키를 업데이트 하는 것도 방법이다!

cicd 등록시 저장할 변수 목록 ( s3 cloudfront로 배포했을 경우 )

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_DEFAULT_REGION
• AWS_DISTRIBUTION_ID
• AWS_S3_BUCKET_NAME

3. workflows .yml 파일 작성

name: MAIN CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Create dotenv file
        run: |
          touch .env
          echo "VITE_BASE_URL=${{secrets.VITE_BASE_URL}}" >> .env 
 # ... env 파일에 생성할 객체 echo 명령어로 추가하기        
          cat .env

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: yarn # yarn으로 설정

      - name: Yarn install
        run: yarn

      - name: Yarn build
        run: yarn build

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_DEFAULT_REGION }}

      - name: Deploy to S3
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET_NAME }}
          SOURCE_DIR: "dist"

      - name: Invalidate CloudFront Cache
        run: aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_DISTRIBUTION_ID }} --paths "/*"

위 코드가 동작하는 방식을 간략하게 작서하면 다음과 같다.

• main 브랜치에 push나 pull request가 일어날 시 아래 스크립트를 실행한다.
• yarn을 이용해 필요한 package.json 파일을 다운받고, build를 진행한다.
• aws 인증
• s3에 기존에 저장된 파일들을 삭제 후 build된 파일이 있는 dist폴더를 지정된 s3버킷에 저장한다.
• 마지막으로 cloudfront에 있는 캐싱 무효화 작업을 실행한다.

4. 마무리 잘 동작하는지 확인하기

action 카테고리에 들어가면 잘 동작하는지 확인할 수 있다. 프로젝트 크기에따라 오래걸릴 수도 있으니 잠깐 다른 작업을 하고 있으면 된다.

디테일을 보려면 Show all jobs 버튼을 프로그램이 동작하는 것을 확인할 수 있다.

모두 완료된 후 배포 url로 접속하여 업로드가 잘 되었는지 또는 workflows 마지막 단계인 캐싱 무효화가 잘되었는지 등을 통해 잘 동작이 되었는지 확인할 수 있다.

참고

• GitHub Actions의 체크아웃(Checkout) 액션으로 코드 내려받기
• Github Action으로 배포 자동화하기

• 지속적인 운영을 위한 프로덕트 서버 배포
• 서비스 운영에 관계없이 개발에 집중을 하기위한 개발 서버 배포
• Rout53으로 가비아 연결하기

빌드 파일 저장은 s3 스토리지를 이용한다. 왜 ? 이전 기록 삭제하고 다시 빌드 올리기가 쉽기 때문이다.

1. S3 버킷 생성

버킷 만들기 클릭

아래 화면에서 s3 버킷 쓰임에 따라 내용을 작성한 후 버킷을 생성한다.

• 버킷 이름 : 해당 버킷이 어떤 역할을하는지 알아볼 수 있는 이름 작성한다.
• 기존 버킷에서 설정 복사 : 이전에 설정한 버킷과 같은 설정을 하고 싶다면 버킷 선택을 눌러 가져오고 싶은 설정의 버킷을 선택하여 세팅할 수 있다.
• 객체 소유권 : 다른 aws 계정에서 해당 버킷을 이용하게 할 경우 ACL 활성화를 하면 되지만 해당 버킷을 생성하고 있는 계정에서만 쓸 경우에는 비활성화를 선택하면 된다.

• 퍼블릭 엑세스 차단 설정 : 바로 S3로 접속을 할 경우에는 모든 퍼블릭 액세스 차단을 해제한 후 아해 개별 설정을 해줘야하지만 현재는 cloudfront를 이용해 배포를 할 것이기 때문에 기본 값이 모든 퍼블릭 액세스 차단에 체크를해두면 된다.
• 버킷 버전 관리 : 해당 프로젝트는 실사용자가 있어 무분별한 기능 업데이트보다는 버전으로 관리될 예정이므로 혹시 모를 일을 대비해 버전 관리 활성화에 체크하였다. 딱히 버전관리가 필요없다면 비활성화에 체크하면 된다.

• 기본 암호화 : 딱히 키별로 관리할 용도의 버킷이 아니기 때문에 기본값인 SSE-S3로 체크하였다.
• 고급 설정 - 객체 잠금: 여러 명이 함께하는 프로젝트라면 객체잠금을 하겠지만, 현재 프론트가 혼자인 관계로 딱히 설정하지 않았다.

여기까지하면 버킷 만들기 클릭.

개발서버는 앞에 dev, 운영서버는 product를 붙여 구분하였다.

s3 파일 업로드하는 방법은 간단하다. 업로드 부분에 파일을 드래그하거나 업로드 버튼을 눌러 추가하면 된다.

s3만으로 정적 호스팅을 하려면 aws 속성 설정 > 맨 하단의 정적 웹 사이트 호스팅 활성화를 켜면 된다. cloudfront로 배포를 할 것이기 때문에 비활성화 상태로 둔다.

인덱스 문서와 오류 문서 둘다 index.html로 설정한다.

2. cloudfront 생성

생성된 s3버킷을 origin domain으로 두고 cloudfront를 생성한다.

나머지 설정들

• 기본 캐시 동작은 본인 프로젝트에 맞춰 설정해주면 되는데 서버측과 얘기한 후 HTTP and HTTPS로 할지 Redirect HTTP to HTTPS할지 정하면 된다.

쭉 이미지를 따라 설정하다가 인증서 설정이 나오는데

마지막으로 배포 생성 누르면 cloudfront 생성 끝. 가비아나 구매한 url을 연결해주려면 생성 후 cname 등록을 해주어야한다.

3. S3 버킷 정책 수정하기

생성하고 난 후에 뜬 알림문의 정책 복사 후 s3 버킷 권한으로 이동한다.

아래 정책 부분에 복사한 정책을 붙여넣은 후 변경사항 저장을 눌러주자.

다시 클라우드 프론트로 돌아와 배포 url을 확인하면 배포가 잘 되었는지 확인할 수 있다.

오류 페이지 등록

cloudfront에서 페이지를 접속했을 때 403 Forbidden이 뜰 경우 리다이렉트해줄 파일을 선택할 수 있다.

403으로 뜰 경우 index.html 기본 폴더로 리다이렉트되게 설정하였다.

4. CNAME 등록하기

미리 가비아에 구매해둔 도메인을 등록하기 위해 가비아 페이지에서 cname을 등록해주자. 등록해서 바로 적용되는 것이 아닌 짧게는 15분~1시간 길게는 하루 반나절 정도 걸리니, cloudfront 배포 후 바로 등록해주는 것이 좋다.

자세한 내용을 따로 먼저 s3 cloudfront 배포후 추가 포스팅 첨부예정이다.

S3 버킷 정적 호스팅 활성화

S3 get Object 설정

Rout53으로 cname 등록

끝

포스팅 참고 링크

• cloudfront+s3 배포
• inpa DEV 티스토리 : AWS-📚-S3-객체-암호화-기능-종류-및-사용하기

세팅해서 안되길래 게시글을 찾아본 경우

만약 이미 code . 명령어 설정을 했는데 실행이 안되는 경우

zsh: command not found: code

먼저 응용프로그램에 VS code가 설치가 잘 되어있는지 확인해본다. i cloud 사용자라면 그냥 다운로드 폴더 안에 VS code가 설치 되어 있을 수 있기때문에 아무리 세팅을 반복해도 컴퓨터를 껏다키면 적용되지 않는다.

처음 세팅하는 경우

터미널에서 cmd + shift + p 명령어로 설정 탭을 켠후 PATH에 code 명령 설치 또는 Shell Command: Install 'code' command in PATH를 검색하여 클릭해준다.

이미 설정이 되어있는 경우는 아래와 같은 창이 뜬다.

간혹 설정하고 난 후 맥을 껏다켜면

eacces: permission denied, unlink '/usr/local/bin/code'

위와 같은 에러가 뜨는 경우가 있는데 그럴 경우엔 터미널에서

cd /usr/local/bin

bin 파일에 이동한 후 이전에 설정된 code를 삭제시켜준 후 재 설정 가능하다.

sudo rm -rf code
password: 

sudo명령어를 입력한 후에 설정된 비밀번호를 입력해주면 된다.

처음 방법대로 vs code에서 Shall 명령어로 PATH에 code 명령 설치하기를 클릭하면 정상적으로 세팅되는 것을 확인할 수 있다.

이렇게 했는데도 안되는 컴퓨터 재시동시 zsh: command not found: code 에러가 뜨는 경우에는 .zshrc 파일에 VS code 명령어를 실행할 수 있는 PATH설정을 export해준다.

vim ~/.zshrc

읽기 모드로 열리는 경우 i를 눌러 편집모드로 변경 후 아래 코드를 후에 본인이 알아볼 수 있는 주석과 함께 붙여 넣은 후 esc + :wq 명령어를 통해 저장후 나오기를 실행한다.

export PATH="$PATH:/Applications/Visual Studio Code.app/Contents/Resources/app/bin"

재시동후 터미널에서 VS code로 열고싶은 파일로 이동하여 code . 명령어를 실행한다.

husky를 도입하는 이유

lint와 prerrier설정 때문에 husky를 도입함. 강한 안전장치가 필요.

아래 이유를 방지하기 위함.

1. 누군가 vscode/settings.json 또는 CLI 세팅을 넣어주더라도 vscode를 사용하지 않는 팀원 존재.
2. 기존 설정 파일을 변경
3. CLI에서 명령어를 입력을 빼먹는 경우

IDE레벨이 아닌 프로젝트 레벨

• IDE레벨이 아닌 프로젝트 레벨에서 기존에 설정한 룰이 무조건 적용되게 하기위함.

• git커밋 시 eslint, prettier를 무조건 적용.

• git hook precommit를 사용하려면 husky를 써야겠다 생각.

  git hook만 이용하는게 아니라 왜 husky인가?

  git hook만 사용할 경우 git/hooks/pre-commit 파일에서 스크립트를 작성해서 쓰면 됨. 하지만 직접 스크립트를 작성하는데 번거로움이 있음. hook파일은 .git 안에 있어 git이 추적을 하지않아, 개개인이 관리해줘야하는 번거로움을 방지하고자 husky를 많이 사용한다고함.

• 허스키와 같이쓰는 link-staged라이브러리 : lint를 전체 적용하지 않고 git stage된 그런 상태 안에서만 lint 검사를 하여 시간을 단축시킬 수 있는 파일.

기록기록. vm 서버 만들기 부터 환경설정까지 과정을 기록한 포스팅입니다. 이번 포스팅의 요약은 vm 서버 사양이 너무 낮아 사이트 접속 지연 이슈가 생겼다는 결말입니다.

용어 이해하고 네이버 클라우드에서 제공하는 가이드센터만 차근차근 읽어본다면 네이버 클라우드로 vm 만들기 짱 쉬워용.

네이버 클라우드로 vm 서버 만드는 순서 요약

VPC 생성 -> subnet 생성 -> Server 생성

네이버 콘솔에 왼측에 메뉴바 > VPC > VPC Management접속

vpc 생성

• vpc 이름은 본인이 배포할 프로젝트 이름이나 test와같은 구분할 수 있는 이름을 입력해주기
• ip주소 범위는 VPC에서 많이 사용되는 일반적인 IP범위인 10.0.0.0/16로 설정해준다. 10.0.0.0/16는 총 65,536개의 IP 주소를 사용할 수 있다.
• VPC 유형 선택은 일반적으로 독립적인 VPC를 생성할 경우는 NORMAL일 경우에 선택, Transit Gateway와 연결되는 VPC를 생성할 때는 TRANSIT을 선택해준다. Transit Gateway은 여러 VPC와 온-프레미스 네트워크를 연결하는 허브 역할을 한다. 간단한 사이드 프로젝트일 경우라면 NORMAL유형의 VPC 생성을 권장한다. TRANSIT 유형은 복잡한 네트워크 아키텍처를 구현할 때 사용된다.

vpc를 만들고나면 상태가 생성중으로 보통 5~10분 정도 소요된다. 더 복잡한 네트워크 구성이거나 다른 작업이 병행되는 경우에는 더 오래걸릴 수도 있다.

vpc생성 과정

1. VPC메타데이터 및 구성 정보 생성
2. 라우팅 테이블, 보안 그룹 등 관련 리소스 생성
3. 네트워크 환경 설정 및 초기화
4. 생성 상태 검사 및 완료 처리

subnet 생성

VPC > subnet Management 접속 옵션 입력하기

• vpc란에 생성한 vpc 선택해주기
• ip 주소 범위는 10.0.0.0/16으로 설정
• Internet Gateway는 격리 된 공간에 인터넷을 허용할 건지의 여부로 이해했다. 공인 IP를 사용하려면 Public Subnet만 등록이 되므로 Public으로 선택하기 잘못 이해한 거라면 댓글로 알려주세여
• 용도는 일반으로 선택

  용도 옵션 특징

• LoadBalancer 여러 대의 서버에 들어오는 트래픽을 분산 시켜주는 역할
• Bare Metal Server 실제 물리적 서버를 사용하는 옵션
• NAT Gateway 사설 네트워크에서 인터넷에 접근하기 위해 사용됨. 인터넷을 통한 외부 서비스에 접근해야 하는 경우, NAT 게이트웨이를 통해 내부 IP주소를 공용 IP주소로 변환하여 통신함. 주로 보안 및 네트워크 관리를 위해 사용.

VPC와 Subnet 생성이 끝났다면 본인에게 맞는 운영 체제를 선택해 서버를 생성할 수 있다.

서버 생성

Server > Server

무료 버전인 micro를 사용할 경우 linux운영체제를 선택해준다. 결제 수단 등록일로부터 1년간 무료로 제공되므로, 요금제 선택에서 뜨는 월 요금은 무시해주기. 무료 버전은 1개 계정당 서버 1대만 생성 가능하다.

• Network Interface 생성
• 물리 배치 그룹 미사용
• 반납 보호 설정

  스토리지 설정

  기본 크기 10GB로 둔다. 인증키 설정은 보유하고 있는 키가 있다면 보유중인 인증키를 사용하고 없다면 새로운 키를 생성해준다. (요렇게 다운받아짐) 네트워크 접속 마지막으로 Server>ACG로 이동해서 ACG생성 해면 서버 완료 끝~

  ACG란?

• IP 기반 필터링 기능으로 서버로의 네트워크 접근을 관리하는 서비스
• ACG에서 네트워크 접근 ip를 설정 할 수 있음
• 자주 사용하는 TCP, UDP, ICMP 외에도 다양한 프로토콜을 제어 및 관리

공인IP까지 등록해줘야 접속이 가능해용.

• Server > Public IP 이동
• 공인 IP신청
• 적용 서버 선택에 방금 생성한 서버를 선택해주고 최종확인까지 하면 끝!
• 서버 선택에 생성한 서버가 안뜬다면 서버 생성에 시간이 조금 소요되므로 잠시 기다렸다 공인 ip등록을 해준다.

네이버 클라우드 터미널 ssh로 vm 서버 접근하기

아래 명령어 본인 서버에 맞춰 입력하기

ssh <관리자 이름>@<공인 ip 주소>

위 형태로 입력하면되는데 처음 vm 서버에 접속할 시에는 대부분 서버 이름 기본값이 root로 돼있다.

확인하는 방법은 네이버 클라우드 콘솔에서 VPC > Server > Server 카테고리에서 확인할 서버를 선택한 후, 상단에 서버 관리 및 설정 변경 > 관리자 비밀번호 확인에서 처음 vm 서버를 생성 시 등록한 pem 인증키 파일을 첨부해 서버 관리자 이름과 비밀번호를 확인할 수 있다.

초기 서버 이름 확인

터미널로 vm 접속하기

터미널에 위와 같은 창이 뜨면 vm에 접속 성공. 네이버 클라우드 가이드센터 바로가기

비밀번호 변경 명령어

passwd root

vm 서버 환경 설정

각자 프로젝트에 맞는 환경설정을 해준다.

nginx 설치

엑, 무료 버전을 쓰려고 일단 먼저 vm 서버를 만들었는데 네이버 클라우드에서 권장하는 이미지가 있었다. 무료버전으로 해도 조금 느려지는 거 말고 큰 차이 있겠냐 생각하며 그냥 만들어둔 서버에 nginx를 설치했다.

패키지 업그레이드

~# dnf -y upgrade-minimal

모지? 업그레이드가 어마어마하게 돼서 이게 micro 서버에서 괜찮은 건가 살짝 불안해졌지만, 어떻게든 되겠지 생각하고 그대로 진행했다. 설치가 이렇게 오래 걸리는게 맞나? 업그레이드가 완료되면 nginx 설치준비하기. nginx 최신버전을 설치하려면 epel-release 리포지토리 패키지가 필요한데, epel-release 리포지토리 패키지를 설치하기 위해서는 Extras 저장소 파일이 필요하다.

vi /etc/yum.repos.d/Rocky-Extras.repo

파일을 확인했을 때, 아래 처럼 Extras 저장소 설정 파일이 있다면 다음단계로 넘어가면 된다. 그렇지 않다면 아래 내용으로 파일을 생성한다.

EPEL 저장소 패키지 설치

dnf -y install epel-release

nginx 설치, 설치 후 버전 확인

dnf -y install nginx
nginx -v

다음으로 홈으로 사용할 디렉토리 생성 및 해당 디렉토리 소유권 설정을 해준다.

# 테스트 사이트 홈 디렉토리 생성
mkdir -p /ncloud/data/www/nginx-test/

# 해당 디렉토리에 nginx에 권한 부여
chown -R nginx:nginx /ncloud/data/www/nginx-test

# nginx 샘플 페이지를 사이트 디렉토리로 복사
cp /usr/share/nginx/html/*.* /ncloud/data/www/nginx-test/

# 복사된 파일들 확인
ls -al /ncloud/data/www/nginx-test/

디렉토리 파일 구조 확인

tree -P *conf* /etc/nginx/

기본 설정 파일

vi /etc/nginx/nginx.conf

nginx 실행

systemctl enable nginx
systemctl start nginx
systemctl status nginx

nginx 실행 후 vm ip 주소로 접속했을 때 nginx 화면이 실행되면 끝난건데, 서버가 micro 버전이어서 그런지 접속하는데 로딩이 너무 오래걸린다. 한번 해봤으니, 하다 안되면 vm 날리고 다시 처음부터 만들면 된다.

참고링크

linux에 nginx 설치하기

How to Install the Latest Nginx on Rocky Linux

Heade 쿼리로 바로 만들어주는 사이트 :https://capsule-render.vercel.app/

깃허브 상태 코드 : https://github.com/anuraghazra/github-readme-stats

factory 공장 패턴이란? 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴 = 공장(Factory) 클래스로 캡슐화 처리하여 대신 생성하게 하는 생성 디자인 패턴

• 객체 생성 로직이 떼어져 있기 때문에 코드 리팩터링시 한 곳만 고칠 수 있어 유지 보수성이 증가하게된다.
• 각 재료 공장을 연상하기

자바스크립트의 팩토리 패턴

new Object()로 구현 가능. 전달받은 값에 따라 다른 객체를 생성하며 인스턴스의 타입 등을 정함

class Latte {
  constructor() {
    this.name = "latte";
  }
}

class Espresso {
  constructor() {
    this.name = "Espresso";
  }
}

class LatteFactory {
  static createCoffee() {
    return new Latte()
  }
}
class EspressoFactory {
  static createCoffee() {
    return new Espresso()
  }
}

const factoryList = {LatteFactory,EspressoFactory}

class CoffeeFactory {
    static createCoffee(type) {
      const factory = factoryList[type]
      retrun factory.createCoffee()
  }
}

const main = ()=>{
  // Doing order latte
  const coffee = CoffeeFactory.createCoffee("LatteFactory")
  // Calling coffee's name
  console.log(coffee.name) // latte
}
main()

팩토리 메서드 패턴 흐름

패턴 사용 시기

• 클래스 생성과 사용의 처리 로직을 분리하여 결합도를 낮추고자 할때
• 코드가 동작해야 하는 객체의 유형과 종속성을 캡슐화를 통해 정보 은닉 처리 할 경우
• 라이브러리 혹은 프레임워크 사용자에게 구성 요소를 확장하는 방법을 제공하려는 경우
• 기존 객체를 재구성하는 대신 기존 객체를 재사용하여 리소스를 절약하고자 하는 경우

1.1.3 전략 패턴

전략 패턴(strategy pattern) = 정책 패턴(policy pattern)

• 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴

passport의 전략 패턴

Node.js에서 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리

1.1.4 옵저버 패텅

observer pattern은 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있ㅇㄹ 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴

• 트위터가 옵저버 패턴("새로운 트윗을 옵저버들에게 알려준다")
• 주로 이벤트 기반 시스템에 사용하며 MVC 패턴에도 사용된다.

자바스크립트에서의 옵저버 패턴

프록시 객체를 통해 구현 가능

프록시(proxy) 객체? 어떠한 대상의 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출 등)의 작업을 가로챌 수 있는 객체. 프록시 객체는 두 개의 매개변수를 가짐

• target :프록시할 대상
• handler 프록시 객체의 target 동작을 가로채서 정의할 동작들이 정해져 있는 함수

프록시 객체를 이용한 옵저버 패턴

function createReactiveObject(target, callback) {
  const proxy = new Proxy(target, {
    set(obj, prop, value) {
      if (value !== obj[prop]) {
        const prev = obj[prop];
        obj[prop] = value;
        callback(`${prop}(이)가 [${prev}] >> [${value}]로 변경되었습니다.`);
      }
      return true;
    },
  });
  return proxy;
}
const a = {
  채영: "솔로",
};
const b = createReactiveObject(a, console.log);
b.채영 = "솔로";
b.채영 = "커플";
// 채영(이)가 [솔로] >> [커플]로 변경되었습니다.

참고링크

팩토리 메서드 패턴-완벽 마스터하기

• 참고 서적 면접을 위한 CS 전공 지식 노트

프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약'형태로 만들어 놓은 것

1.1.1 싱글톤 패턴

• singlton pattern 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
• 데이터 베이스 연결 모듈에 많이 사용
• 장점 : 해당 인스턴스를 다른 오듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어든다.
• 단점: 의존성이 높아진다.

자바스크립트 싱글톤 패턴

예시 참고

// Singleton.js
let instance;

export default class Singleton {
  constructor(data = "Initial data") {
    if (instance) {
      return instance;
    }
    this.data = data;
    instance = this;
  }

  getData() {
    return this.data;
  }

  setData(data) {
    this.data = data;
  }
}

데이터베이스 연결 모듈

const URL = "mongodb://localhost:27017/app";
const createConnection = url => ({ url: url });

class DB {
  constructor(url) {
    if (!DB.instance) {
      DB.instance = createConnection(url);
    }
    return DB.instance;
  }
  connect() {
    return this.instance;
  }
}

const a = new DB(URL);
const b = new DB(URL);

console.log(a === b); // true

하나의 인스턴스 기반으로 a, b를 생성함으로 데이터베이스 연결에 관한 인스턴스 생성 비용을 아낄 수 있다.

싱글톤 패턴의 단점

1. 독립적인 인스턴스 생성의 어려움

   TDD(Test Driven Development)를 할 때 단위 테스트를 주로 하는데 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야하는데 싱글톤 패턴은 독립적인 인스턴스를 만들기 어렵다.

2. 모듈 간의 의존성이 강함

   모듈 간의 결합을 강하게 만든다. 의존성 주입(DI, Dependency Injection)을 통해 모듈간의 결합을 조금 더 느슨하게 만들어 해결할 수 있다. * 의존성 주입을 종속성이라고도 한다.

의존성 주입의 장점

모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅과 마이그레이션이 수월해진다. 구현 시 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향이 일관되고, 애플리케이션을 쉽게 추론할 수있다.

의존성 주입의 단점

오듈들이 더욱더 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있고 약간의 런타임 페널티가 발생.

의존성 주입의 원칙

• 상위 도율은 하위 모듈에서 어떠한 것도 가져오지 않아야한다. 둘 다 추상화에 의존해야하며 추상화는 세부 사항에 의존하지 않아야한다.

추상화란?

프로그래밍에서 추상화란 복잡하고 불필요한 세부 사항을 숨겨 코드를 더 간단하고 읽기 쉽고 유지 관리하기 쉽게 만드는 프로세스.

• 좋은 객체를 만드는 법, 설계를 잘하는 법을 추상화라고 생각하기

• 참고링크 객체 지향 프로그래밍 4가지 개념 자바스크립트의 추상화: 함수와 고차 함수로 코드 간소화하기

• 참고 서적 면접을 위한 CS 전공 지식 노트

Array.filter(조건 함수)

• 주어진 배열에서 제공된 함수에 의해 구현된 테스트를 통과한 요소로만 필터링한다.

  const words = ['spray', 'elite', 'exuberant', 'destruction', 'present'];
  

const result = words.filter((word) => word.length > 6);

console.log(result); // Expected output: Array ["exuberant", "destruction", "present"]

filter함수의 매개변수
```javascript
filter(callbackFn)
filter(callbackFn, thisArg)

callbackFn

배열의 각 요소에 대해 실행할 함수. 결과 배열에 요소를 유지하려면 참 값을 반환하고 그렇지 않으면 거짓 값을 반환한다.

• 구성 인수 element(배열에서 처리 중인 현재 요소), index(배열에서 처리 중인 현재 요소의 인덱스), array (filter()가 호출된 배열)

thisArg

• callbackFn을 실행할 때 this 값으로 사용할 값, 순회 메서드

순회메서드

• 많은 배열 메서드는 콜백 함수를 인수로 받는다. 콜백 함수는 배열의 각 요소에 대해 순차적으로 최대 한 번만 호출되며, 콜백 함수의 반환값은 메서드의 반환값을 결정하는 데 사용.
• 예시 : every(), filter(), find(), findIndex(), map(), flatMap(), forEach(), some() 등

filter함수란?

얕은 복사본은 반환하는 복사, 순회 메서드로 배열의 각 요소에 대해 제공된 콜백함수를 한 번씩 호출하고, 콜백이 참 값을 반환하는 모든 값으로 새 배열을 구성한다. 콜백함수 테스트를 통과하지 못한 배열 요소는 새 배열에 포함되지 않는다. 콜백함수는 값이 할당된 배열 인덱스에 대해서만 호출된다.

사용 시 주의 사항

• callbackFn은 filter() 호출이 시작되었을 때 배열의 초기 length 값을 초과하여 추가된 요소는 방문하지 않는다.
  • 이미 방문한 인덱스를 변경해도 callbackFn이 해당 인덱스에 대해 다시 호출되지 않는다.
  • 배열의 아직 방문하지 않은 기존 요소가 callbackFn에 의해 변경되는 경우, callbackFn에 전달된 값은 해당 요소가 방문될 당시의 값이 됩니다. delete된 요소는 방문하지 않는다.

    예시

    function isBigEnough(value) {
    return value >= 10;
    }
    

const filtered = [12, 5, 8, 130, 44].filter(isBigEnough); // 필터링된 값은 [12, 130, 44]

```

• filter메서드는 복잡한 코드를 생성하는 경우가 많으므로 꼭 필요한 경우가 아니라면 사용 지양하기.

참고링크

URL 유효성 검사는 웹 개발에서 중요한 부분 중 하나이다. 대부분의 경우, 정규표현식을 사용하여 간단한 유효성 검사를 수행할 수 있다. 그러나 정규표현식은 모든 상황을 다루지 못할 수 있으므로 사용자는 이 한계를 이해하고 추가적인 확인 방법을 고려해야 한다.

URL 유효성 검사에 제공된 정규식은 대부분의 경우에 효과적일 수 있지만, 유효한 URL의 모든 인스턴스를 캡처하지 못할 수도 있다는 점에 유의해야한다.P 주소가 포함된 웹 주소, 라틴 문자가 아닌 문자 또는 FTP와 같은 대체 프로토콜이 포함될 수 있다.

URL 유효성 검사를 위한 정규표현식

URL 유효성 검사를 위한 간단한 정규표현식이다. 이 정규표현식은 대부분의 경우에 효과적일 수 있지만, 모든 상황을 다루지는 않는다. IP 주소, 라틴 문자가 아닌 문자, FTP와 같은 대체 프로토콜 등이 포함될 수 있다. 참고

const urlRegex = /^(https?|ftp):\/\/(-\.)?([^\s\/?\.#-]+\.?)+(\/[^\s]*)?$/i;

정규표현식 한계

이 정규표현식은 일반적인 경우에는 효과적이지만, 모든 상황을 다루지는 못한다. 사용자는 이 한계를 이해하고, 추가적인 검사 방법을 사용하여 정확성을 보장해야 한다. 예를 들어, IP 주소가 포함된 웹 주소나 라틴 문자가 아닌 문자를 다루기 위해 추가적인 확인 로직이 필요할 수 있다.

코드 예시

function isValidURL(url) {
  const urlRegex = /^(https?|ftp):\/\/(-\.)?([^\s\/?\.#-]+\.?)+(\/[^\s]*)?$/i;
  return urlRegex.test(url);
}

// 사용 예시
const url1 = "https://www.example.com";
const url2 = "ftp://ftp.example.com";
const url3 = "invalid-url";

console.log(isValidURL(url1)); // true
console.log(isValidURL(url2)); // true
console.log(isValidURL(url3)); // false

추가 확인 방법 활용하기

정규표현식을 사용한 기본적인 검사 후에도 사용자는 추가적인 확인 방법을 활용하여 정확성을 높일 수 있다. 예를 들어, 네트워크 요청을 통해 실제로 해당 URL이 존재하는지 확인하거나, 더 엄격한 검사를 위해 서드파티 라이브러리를 사용할 수 있다.

자신만의 추가 확인 방법을 도입하여 보다 신뢰성 있는 URL 유효성 검사를 수행할 수 있다.

다양한 url 매칭 방법들

Exact, Simple, Starts, Ends, Contains, Regular Expression 매치 참고링크

URL 유효성 검사는 웹 개발에서 중요한 부분 중 하나이다. 대부분의 경우, 정규표현식을 사용하여 간단한 유효성 검사를 수행할 수 있다. 그러나 정규표현식은 모든 상황을 다루지 못할 수 있으므로 사용자는 이 한계를 이해하고 추가적인 확인 방법을 고려해야 한다.

URL 유효성 검사에 제공된 정규식은 대부분의 경우에 효과적일 수 있지만, 유효한 URL의 모든 인스턴스를 캡처하지 못할 수도 있다는 점에 유의해야한다.P 주소가 포함된 웹 주소, 라틴 문자가 아닌 문자 또는 FTP와 같은 대체 프로토콜이 포함될 수 있다.

URL 유효성 검사를 위한 정규표현식

URL 유효성 검사를 위한 간단한 정규표현식이다. 이 정규표현식은 대부분의 경우에 효과적일 수 있지만, 모든 상황을 다루지는 않는다. IP 주소, 라틴 문자가 아닌 문자, FTP와 같은 대체 프로토콜 등이 포함될 수 있다. 참고

const urlRegex = /^(https?|ftp):\/\/(-\.)?([^\s\/?\.#-]+\.?)+(\/[^\s]*)?$/i;

정규표현식 한계

이 정규표현식은 일반적인 경우에는 효과적이지만, 모든 상황을 다루지는 못한다. 사용자는 이 한계를 이해하고, 추가적인 검사 방법을 사용하여 정확성을 보장해야 한다. 예를 들어, IP 주소가 포함된 웹 주소나 라틴 문자가 아닌 문자를 다루기 위해 추가적인 확인 로직이 필요할 수 있다.

코드 예시

function isValidURL(url) {
  const urlRegex = /^(https?|ftp):\/\/(-\.)?([^\s\/?\.#-]+\.?)+(\/[^\s]*)?$/i;
  return urlRegex.test(url);
}

// 사용 예시
const url1 = "https://www.example.com";
const url2 = "ftp://ftp.example.com";
const url3 = "invalid-url";

console.log(isValidURL(url1)); // true
console.log(isValidURL(url2)); // true
console.log(isValidURL(url3)); // false

추가 확인 방법 활용하기

정규표현식을 사용한 기본적인 검사 후에도 사용자는 추가적인 확인 방법을 활용하여 정확성을 높일 수 있다. 예를 들어, 네트워크 요청을 통해 실제로 해당 URL이 존재하는지 확인하거나, 더 엄격한 검사를 위해 서드파티 라이브러리를 사용할 수 있다.

자신만의 추가 확인 방법을 도입하여 보다 신뢰성 있는 URL 유효성 검사를 수행할 수 있다.

다양한 url 매칭 방법들

Exact, Simple, Starts, Ends, Contains, Regular Expression 매치 참고링크

간단 독서 후기

함께 자라기, 애자일로 가는 길 저자 : 김창준 출판 : 인사이트

책소개

부트캠프 수료식날 코치님께 개발자라면 꼭 읽어보고 가졌으면 좋을 거 같은 태도가 담긴 책이라며 받은 책

• 기술 관련 이야기보다는 개발자 뿐만 아니라 개인이 자기계발을 위해 가져야할 학습의 태도와 더 좋은 협업의 자세에 대한 수필.

책을 읽고

협업하기 전에 이 책을 읽었더라면 더 좋았을 거 같다는 생각이 들었다. 자기 계발이나 스터디, 고객 커뮤니케이션 등등 많은 주제가 몇장에 걸쳐 쓰여있지만 가장 와닿았던 파트는 협업에 관한 이야기였다. 아직 주니어도 아닌 베이비인 내가 겪고 고민해오던 부분이 협업이기에 더 재밌게 읽었던 거 같다. 더 일찍이 읽었으면 이전에 협업하며 겪었던 매 상황에 더 잘 대응하거나 더 좋은 방안으로 이끌어 냈을 수 있겠다는 생각이 들었다. 협업을 처음 할 때의 우리는 협업에 대해 제대로 배워본 적이 없기 때문에 직접 부딪히며 일어나는 갈등이나 소통 방식에 대해 직접 겪고 고민하며 함께하는 사람들과의 규칙을 만들어간다. 이 책에서는 배운 적 없는 협업인 만큼 코드의 추상화나 대화하는 프로그래밍에 대해 언급하며 협업 방식에 대해 더 수련하고 고민해야한다고 말한다. 적극적이어야만 협업이 잘되는 것이 아니다. 성향과 기질에 따른 애자일 방식을 소개하며 설득을 통해 협업을 잘 이끌어 낼 수 있다는 여러 대화문 예시를 통해 소통 접근법에 대해 보여준다. 이 책은 부트캠프가 끝나고 수료식날 코치님께 받게된 책인데 그때 주변에 만나는 사람마다 이 책을 소개하고 꼭 읽어라고 강추한다고 하셨다ㅏ 뒤늦게 쓰게된 독후감(?)이지만 왜 그렇게 강추하셨는지 읽어보며 알게되었다. 이전에 협업하며 했던 고민들이나 혼자 학습이나 스터디 등등으로 했던 고민들을 직간접적으로 해결할 수 있도록 이끌어준 책인 거 같다.

요번 방송통신대학교 이슈

이게 무슨 일이래

한국방송통신대학교의 개인정보 유출 사건은 웹 개발의 보안 측면에서 주목받고 있는 사례 중 하나이다. 이 사건은 지난 13년 동안 지원자들의 민감한 정보가 URL을 통해 쉽게 노출되어 있었다는 점에서 주요한 보안 이슈로 부상했다.

이러한 보안 이슈가 발생한 원인 중 하나는 URL에 접수번호가 그대로 노출되어 있어, 사용자가 이를 변경함으로써 다른 지원자의 정보에 접근할 수 있었다. 이는 개발자들이 URL을 통해 민감한 정보를 전송하거나 저장할 때 취해야 할 보안 조치가 부족했음을 시사이다.

이번 글에서는 해당 보안 이슈가 왜 발생했는지에 대한 근본적인 이유를 살펴보고, 베이비 백엔드 개발자들이 이러한 상황을 예방하고 안전한 애플리케이션을 개발하는 데 어떤 조치를 취할 수 있는지에 대해 알아보자.

1. URL 보안 강화하기: 기사에서 언급된 것처럼 URL을 통해 다른 사용자의 정보에 쉽게 접근할 수 있는 취약점을 보완하기 위해 URL에 민감한 정보를 노출하지 않도록 주의해야 한다. JWT와 Passport를 통한 안전한 사용자 인증 시스템을 구현해보자.

2. JWT(JSON Web Token) 소개: JWT를 활용하여 효과적이고 안전한 사용자 인증을 구현하는 방법에 대해 알아보자.

const jwt = require('jsonwebtoken');

const secretKey = 'yourSecretKey';

const user = { id: 123, username: 'example' };

const token = jwt.sign(user, secretKey);

3. Passport와의 통합: Passport는 다양한 전략을 제공하며, 그 중에서도 JWT를 사용한 인증을 적용하는 방법에 대해 살펴보자.

const passport = require('passport');
const JwtStrategy = require('passport-jwt').Strategy;
const ExtractJwt = require('passport-jwt').ExtractJwt;

const opts = {
  jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
  secretOrKey: 'yourSecretKey',
};

passport.use(new JwtStrategy(opts, (jwt_payload, done) => {
  // 사용자 확인 및 처리 로직
}));

4. Express 애플리케이션에 적용하기: Express 애플리케이션에 Passport 및 JWT를 통합하여 안전한 사용자 인증을 구현하는 방법에 대해 알아보자.

const express = require('express');
const passport = require('passport');

const app = express();

// Passport 초기화
app.use(passport.initialize());

// Passport JWT 미들웨어 적용
app.get('/protected-route', passport.authenticate('jwt', { session: false }), (req, res) => {
  res.json({ message: 'You accessed a protected route!' });
});

5. 기타 보안 강화 방법: 이외에도 HTTPS 사용, 토큰 유효 기간 설정 등을 통해 웹 애플리케이션의 보안을 강화하는 방법에 대해 간략히 다룬다.

마무리

부트캠프에서 코치님들을 통해 이런 경우를 들어오곤 했지만 이번 사례는 정말 개발자가 시스템 자체를 관리를 안했구나 싶은 수준이지만 댓글을 보면서 너무 당연한게 없는 곳이 있구나하는 생각이 들었다.

참고 자료 및 레퍼런스:

• JWT 공식 문서
• Passport.js Documentation
• jsonwebtoken Documentation

이번 엘리스 모의면접 특강에 면접자로 참여하면서 느낀점은 최대한 많이 이야기하면 좋지만, 제대로 말하지 못하면 차라리 제대로 말할 만큼만 외우고 꼬리질문을 하게 만드는 것이 조금 더 떨지않고 말하는데에 도움이 된다는 것이었다. 단순 CS관련 질문이 아니더라도 내가 개발공부를 하면서 겪은 일들은 꾸준히 기록 해두는 것도 면접때 이야기거리가 될 수 있다는 생각에 포스팅을 더 꾸준히 해야겠다는 생각이 들었다.

면접 준비 내용

1. session 기반 인증과 token 기반 인증의 차이는 무엇인가요?

• wiki 및 참고 링크

  https://hudi.blog/session-based-auth-vs-token-based-auth/

  https://giron.tistory.com/137#:~:text=주요 차이점은 세션 기반,방법을 결정해야 한다.

• 내 답안

• 요점* :세션 기반 인증은 서버가 세부 사항을 저장하고 토큰 기반은 클라이언트가 토큰을 가지고 있는 형태입니다. 세션 방식은 쿠키를 날린다거나 세션 유효기간이 만료되면 재인증해야 하는 번거로움이 있지만 토큰 같은 경우는 탈취를 당하면 강제로 로그아웃 시키거나 만료시키는 방법이 없기 때문에 중복 로그인 관리가 민감한 금융앱, 구독 앱, 모바일 PC체크 같은 경우 세션을 사용해 주로 관리합니다.

주요 차이점은 세션 기반 인증은 서버가 세부 사항을 저장하고 토큰 기반은 클라이언트가 토큰을 가지고 있는 형태입니다. 토큰은 대역폭이 크기 때문에 저장해서 사용하는 것보단 대역폭이 작은 세션을 사용하는 편이 좋습니다.

세션 방식은 쿠키를 날린다거나 세션 유효기간이 만료되면 재인증해야 하는 번거로움이 있습니다. 이런 번거로움이 나쁜 것은 아니고 유저의 사용 환경상 웹은 어디서건 접속할 수 있고 본인만 사용하는 PC라는 것을 확인할 수 없기 때문에 적절한 시점에서 로그아웃을 해주는 보안상 안전을 위해 주로 사용됩니다.

앱 사용환경에서는 스마트폰은 자신의 것이라는 컨센서스가 있기 때문에 앱, 서버간 인증에서 매번 로그아웃을 하는 것은 보안 수준이 높아야하는 금융앱 같은 경우를 제외하고 유저에게 번거로운 방식일 수 있습니다.

토큰같은 경우는 탈취를 당하면 강제로 로그아웃 시키거나 만료시키는 방법이 없기 때문에 중복로그인 관리가 민감한 경우 (금융앱, 구독 앱, 모바일 PC체크)에는 세션을 사용해 관리하는게 좋습니다. 하지만 자주 ip가 바뀌는 회사에서 사용하는 서비스일 경우 세션 방식이 중복 로그인을 관리하기는 쉽지 않은 걸로 알고 있습니다.

💡출제 의도

• 두 인증 방법의 차이를 얼마나 알고 있는지
• 어떠한 경우에 해당 인증 방법을 사용하는지를 알고 있는지
• 각 인증 방법의 장단점을 알고 있는지

2. JS진영에서는 callback hell 문제가 종종 발생합니다. 이 문제를 해결하는 방법을 아시는 데로 말씀해주세요.

• wiki 및 참고 링크

  https://springfall.cc/article/2022-11/easy-promise-async-await

  https://ko.javascript.info/async-await

  https://ryurim.tistory.com/137#:~:text=콜백 지옥은 비동기 처리,사용하는 방법이 있습니다.

  https://velog.io/@yangareum1818/JS-비동기-처리-모든-것-콜백지옥을-해결하는-방법

• 내 답안 :

  callback hell은 비동기 작업의 흐름을 제어하지 못하기 때문에 콜백함수를 이용해 코드가 깊어지는 경우 비동기 작업을 효율적으로 해결하기 위한 방안으로 Promise와 async/await을 사용할 수 있습니다. Promise는 비동기 작업의 단위로 new Promise(...) 를 하는 순간 할당된 비동기 작업이 바로 시작됩니다. 비동기 작업의 특징은 언제 끝날지 모르기 때문에 일단 뒤에 함수들을 실행하는데, 비동기 함수의 성공 유무를 따라 작업결과를 뒷처리 함으로 callback hell에 대한 문제를 해결할 수 있습니다.

2. Rest API 설계시 고려해야하는 HTTP메서드 GET과 POST의 차이는 무엇인가요?

• GET은 단순 정보를 요청하는 메서드고 POST는 정보를 제출하는 메서드란 점이 다릅니다. 조회나 검색과 같이 멱등성이 중요한 API인 경우는 GET을 사용하고, 리소스 변경이 필요한 경우는 POST를 주로 사용하지만, GET은 요청시 url에 노출이 되어 보안에는 취약하므로 보안에 예민한 정보 같은 경우는 POST를 주로 이용합니다. 또한 큰 데이터를 전송해야 할 경우 데이터의 길이제한이 없는 POST를 사용하는 것이 적절합니다.

💡출제 의도

• callback hell에 대해서 알고 있는지
• promise와 async/await의 필요성에 대해서 인지하고 있는지

3. 멱등성이란 무엇이며, REST API HTTP method의 4가지 중 멱등성을 보장하는 method는 무엇인지 이유와 함께 설명해보세요.

• 알아야 할 wiki 및 참고 링크

  • 멱등법칙(冪等法則) 또는 멱등성(冪等性, 영어: idempotent)은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.
  • https://june0122.github.io/2021/08/05/term-idempotent/
  • https://tecoble.techcourse.co.kr/post/2020-08-17-put-vs-patch/

• 내 답안 :

  멱등성은 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고 서버의 상태에서도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 합니다. REST API method의 POST를 제외하고 GET, PUT, DELETE가 멱등성을 가집니다. 멱등성이 필요한 이유는 금융 관련 자동이체와 같은 결제 서비스를 이용할 때 중복 이체나 결제를 방지할 수 있기 때문에 안정적인 서비스 제공에 중요한 역할을 합니다.

  ---

  POST는 새로운 데이터를 제출하므로 서버에 새로운 데이터(새로운 primary ID)가 추가된다고 볼 수 있으므로 멱등성이라 볼 수 없다.

  GET은 단순 조회 메서드 이므로 서버의 상태에 영향을 주지 않는다.

  PUT은 같은 primary ID에 같은 요청을 보냄으로 서버의 상태가 동일하게 남는다.

  DELETE는 한번 삭제후 같은 데이터를 재삭제 할 경우 응답은 404를 받게 되지만 멱등성은 서버 응답 기준이 아니라 상태를 기준으로 하기 때문에 멱등성을 가졌다고 볼 수 있다.

💡출제의도

• REST API에 대해 어느 정도 수준으로 알고 있는가
• HTTP method들에 대해서 알고 있는가
• 멱등성이란 개념이 어떠한 상황에서 필요한지 알고 있는가

4. 프로젝트 기간 중 직면했던 도전 과제와 그 과제를 어떻게 극복하셨는지 말씀 해주실 수 있으실까요?

• 내 답안 :

  프로젝트 시 npm 에 올라와있는 passport-kakao 모듈을 이용하여 소셜 로그인을 구현하려 한 적이 있습니다. 해당 라이브러리로 카카오 API의 url scope를 이용해 email을 필수 동의 항목으로 받아오려하였지만 해당 라이브러리를 수정해서 적용하기 쉽지않아 프로젝트 내에서 kakao-passport를 직접 만들어 구현하였습니다. 하지만 생각과는 달리 email은 보안에 중요한 항목이라 kakao API 내에서 제한을 두고 있었고, 소셜 로그인 유저일 경우 email을 따로 입력할 수 있도록 로직을 변경하였습니다. 결론적으로 처음 생각했던 방법과는 다르게 회원 로그인 기능을 완료하였지만 kakao-passport 로직을 직접 구현해보면서 나에게 필요한 외부 라이브러리를 찾아 잘 활용하는 것도 중요하지만 나에게 맞지않는 부분이 있을 때 안되는 부분을 찾아 해당 라이브러리에 이슈를 올리거나 나에게 필요한 부분을 직접 구현하는 것에 자신감이 생긴 거 같습니다.

💡출제 의도

• 문제 해결, 트러블 슈팅, 성능 개선 등 경험에 대한 문제
• 위기 대처 능력이 있는지(위기를 회피하는 사람은 아닌지).
• 프로젝트를 경험하면서 겪었던 문제들을 어떻게 해결했는지.
• 현업에서 일할 때 어떠한 일을 맡겨도 해결해낼 사람인지(이를 통해 성장할 수 있는 사람인지)를 가늠하는 단골 문제.

5. N+1 문제란 무엇이며 이를 해결하기 위한 방법은 무엇인가요?

• wiki 및 참고링크

  https://incheol-jung.gitbook.io/docs/q-and-a/spring/n+1

  https://programmer93.tistory.com/83#:~:text=N%2B1 문제를 해결,등의 방법이 있다.&text=JPQL을 사용하여 DB,문을 생각하면 된다. )

  https://velog.io/@jinyoungchoi95/JPA-모든-N1-발생-케이스과-해결책#n1이-근데-뭐죠

  https://well-balanced.medium.com/graphql에서-n-1-쿼리-점진적으로-개선하기-d758e925cc19

  https://jojoldu.tistory.com/457

• 내 답안 :

  N+1 쿼리 문제는 연관 관계에서 발생하는 이슈로 엔티티를 조회했을 때 조회된 데이터 개수(n)만큼 연관 관계의 조회 쿼리가 추가적으로 따라오는 현상으로 알고 있습니다. 지연 로딩의 경우 fetch join을 이용하면 쉽게 해결할 수 있지만 페이지네이션이나 2개 이상의 collection join에서 MultipleBagFetchException 예외 문제가 발생합니다. 모든 케이스들을 정확히 이해하고 있지는 않지만 DB쿼리 외에 GraphQL 등 에서 발생하는 N+1 문제를 이벤트 루프의 원리를 이용해 해결해주는 dataloader 라이브러리를 사용하여 해결할 수 있는 방안이 있다는 개념정도만 알고 있습니다.

💡출제 의도

• 웹 서비스 개발에서 자주 직면할 수 있는 DB 쿼리 문제인 본 문제에 대해 인지하고 있는가(DB에 대한 이해도 가늠)
• DB 쿼리/업데이트 최적화는 고려하지 않고 어플리케이션 코드만 생각하는 사람인가를 체크하기 위함
• N+1문제가 DB 쿼리 외의 기타 네트워크 요청에서도 발생할 수 있음을 알고 있는가(예: GraphQL, RESTful API 등)
• 네트워크 요청 자체가 전체적인 서비스에 얼마나 영향을 끼치는지 인지하고 있는가

6. www.google.com을 브라우저에 입력했을 때 어떠한 일들이 일어나나요?

• wiki 및 참고링크

  https://velog.io/@tnehd1998/주소창에-www.google.com을-입력했을-때-일어나는-과정#:~:text=1. www.google.com,와 함께 전달을 합니다.

  https://velog.io/@eassy/www.google.com을-주소창에서-입력하면-일어나는-일

• 내 답안 :

  요약 : DNS서버에 IP주소를 조회 → 해당 IP주소를 web server에 요청 → 해당 html 문서에 맞는 웹 페이지 작업 및 db 작업을 web server가 was에게 요청함. //TCP

  입력한 URL 주소 중, 도메인 이름에 해당하는 google.com을 DNS에 검색합니다.

  가장 가까운 DNS 서버에서 해당 도메인 이름에 해당하는 IP주소를 찾아 사용자가 입력한 URL 정보와 함께 전달합니다.

  전달 받은 IP 주소를 이용하여 웹 브라운저는 웹 서버에게 해당 사이트에 맞는 html 문서를 요청합니다.

  WAS와 데이터베이스에서 웹페이지 작업을 처리합니다. WAS에서의 작업 처리 결과들을 웹 서버로 전송하고, 웹 서버는 웹 브라우저에게 html 문서 결과를 전달합니다.

  Critical Rendering Path를 통해 웹 브라우저 화면에 웹 페이지 내용을 출력합니다.

  DOM 트리 , CSSOM 트리를 빌드합니다.

  Render Tree가 생성되고 Render Tree의 노드들에 대한 위치와 크기를 계산하는 단계로 Layout -> 특정 액션과 이벤트에 따라 Reflow & Repaint가 수행됩니다.

  레이아웃과 페인트를 수행하지않고 레이어의 합성만 실행시키는 단계로 Composition이 일어나고나면 www.google.com에 맞는 화면이 웹 브라우저에 출력됩니다.

💡출제 의도

• 브라우저-서버 간의 통신에 대해 얼마나 알고 있는지에 대한 열린 질문
• 네트워크에 대해 얼마나 알고 있는지 가늠이 가능한 문제이기도 하다.

API는 메뉴판이라고 생각하고 설계하자.

명확하고 일관된 API 설계하기 : REST API

REST는 Representational State Transfer 의 약어로 하이퍼 미디어를 전송하는 규칙!

REST의 6 원칙과 제약

조금 더 자세한 설명은 여기에

1. uniform interface 일관성
2. client-server 구분
3. Stateless : 작업에 대한 요청의 상태 정보를 저장하거나 관리 하지 않는다. 요청끼리 서로 의존성이 있으면 안된다.
4. Cacheable : 요청은 캐싱이 가능해야한다.
5. Layered System : 요청 하나는 최종 응답 전에 각 계층의 정보를 얻을 수 없도록 분리되어 계층화돼야된다.
6. Code on Demand : 서버는 유저에게 실행 가능한 코드를 보내줄 수 있다.

네이밍

엔드포인트일 경우 주로 동사형태로 네이밍을 하지만 restful URI(uniform resource identifier)의 경우 문서, 컬렉션, 스토어, 컨트롤 4가지 범주로 자원을 분류하여 어떤 범주에 속하는지에 따라 명사로 네이밍을 한다.

그 외 추가

• URI 마지막에 /를 사용하지 않는다.
• _언더스코어 대신 - 하이픈을 사용해 가독성을 높인다.
• 소문자를 사용한다.
• 파일의 확장자는 사용하지 않는다.
• CRUD 메서드를 사용하지 않는다.
• 자원의 필터링은 쿼리 파라미터를 사용한다.
• 한 API에서 하나의 정보만 요청하도록 한다.

API 종류

• public API
• private API
• Partner API

모든 프로그램은 API를 가질 수 있다.

• Windows API : 윈도우 운영체제 기능들을 사용가능
• Database 관리 프로그램 API : DB 입출력 기능들 사용가능
• 어떤 프로그램 API : 프로그램이 존재한다면 API도 존재. 어떤 프로그램(chatGPT, 파파고 등등)의 기능들을 사용 가능

API 판매하는 플랫폼

• 네이버 클라우드와 같은 사이트에서 다양한 API를 무료 또는 구매하여 사용 할 수 있다.
• APT 마켓 플레이스 "사이트 바로가기"와 같은 곳에서 내가 잘 만든 API를 판매할 수 있다.

API 만들어서 팔아보쟈구

참고글

• https://restfulapi.net/resource-naming/
• https://medium.com/tech-pentasecurity/restful-api-%EB%84%A4%EC%9D%B4%EB%B0%8D-7c81bdb9da63

요점 정리 : 금융 관련 결제 같은 요청들은 멱등성이 보장되는 메서드들 꼭꼭 사용하기

순서

• 멱등성이란?
• 멱등성이 필요한 이유
• HTTP Method의 멱등성
• 설계시 고려해야할 점
• 참고사이트

멱등성이란?

HTTP 메소드의 속성 중에 하나인 멱등성은 여러 번 동일한 요청을 보냈을 때, 서버에 미치는 의도된 영향이 동일할 경우를 말한다. 예를 들어 Safe 요청인 GET, HEAD등과 함께 PUT, DELETE를 멱등한 HTTP 메소드라고 정의한다. DELETE는 요청 한번 보냈을 때 DELETE -> 200 OK 응답 값이 오고 동일한 요청을 보낼 경우 에러 DELETE-> 404 NOT FOUND 를 받지만 멱등성의 기준은 요청 응답 기준이 아닌 서버 기준임을 명시하자. PATCH 또한 리소스를 수정할 경우 기존 리소스에 응답을 추가하는 경우에도 사용될 수 있는데 이때, 호출 결과가 달라질 수 있으므로 멱등하다 할 수 없다.

HTTP 메소드 중 멱등한 메소드

• GET, PUT, DELETE

HTTP 메소드의 멱등성이 필요한 이유는 ?

1. 안전한 요청

멱등한 메소드는 서버 상태를 변경하지 않고 리소스에 대한 정보를 요청하는 데 사용될 수 있다. 이는 해당 요청이 오류 또는 부작용을 발생시키지 않고 여러 번 호출될 수 있음을 의미한다. 예를 들어, HTTP의 GET 메소드는 멱등성을 가지고 있다.

2. 캐싱

멱등한 메소드를 사용하면 캐싱이 더욱 효과적으로 이루어질 수 있다. 동일한 요청에 대한 응답은 항상 동일하므로 캐시된 응답을 재사용할 수 있다.

3. 병행 처리와 복구

멱등한 메소드는 여러 클라이언트에서 동시에 호출되더라도 예상된 결과를 얻을 수 있습니다. 이는 분산 환경에서 병행 처리를 쉽게 만들어주며, 시스템이 실패하거나 중단되더라도 안전하게 복구할 수 있도록 한다.

4. 사용자 경험 향상

멱등한 메소드를 사용하면 사용자 경험이 향상될 수 있다. 사용자가 "새로 고침" 버튼을 누르거나 다시 시도 버튼을 클릭하여 동일한 요청을 여러 번 시도해도 예상된 동일한 결과를 받을 수 있다.

5. 네트워크 문제 대응

멱등한 메소드를 사용하면 네트워크 문제로 인해 요청이 중단되었을 때 다시 시도하는 것이 더 쉽다. 동일한 요청을 여러 번 시도해도 동일한 결과를 얻을 수 있기 때문이다.

멱등성이 필요한 예시

결제 시스템

결제 시스템에서 멱등성은 중요한 개념이다. 결제는 금전적인 거래이기 때문에 중복 결제나 잘못된 금액의 결제 등을 방지하기 위해 멱등성이 필요하다.

1. 중복 결제 방지

• 사용자가 결제 버튼을 눌렀을 때, 네트워크 문제 또는 다양한 이유로 인해 응답이 늦게 도착하거나 사용자 측에서 재시도를 했을 경우 중복 결제가 발생할 수 있다. 멱등성이 없는 경우에는 동일한 결제 요청이 여러 번 발생하면 여러 번의 결제가 이루어질 수 있다. 멱등성이 있는 결제 시스템에서는 동일한 결제 요청이 여러 번 수행되어도 결제가 한 번만 이루어진다.

2. 오류 복구

• 결제 시스템에서 오류가 발생했을 때, 사용자나 시스템이 다시 시도를 할 수 있다. 이때 멱등성이 있는 결제 시스템에서는 동일한 결제 요청을 여러 번 시도해도 동일한 결과를 얻을 수 있다.

3. 시스템 간 통신 문제 대응

• 결제 요청은 여러 시스템 간의 통신을 포함할 수 있다. 이때 통신 문제로 인해 요청이 중단되거나 응답이 손실될 수 있다. 멱등성이 있는 결제 시스템에서는 시스템 간 통신 문제로 인한 중복 결제를 방지할 수 있다.

#결제 요청 예시

http
Copy code
POST /payments
Content-Type: application/json

{
  "amount": 50.00,
  "card_number": "1234-5678-9012-3456",
  "expiry_date": "12/24",
  "cvv": "123",
  "order_id": "abc123"
}

해당 결제 요청이 여러 번 수행되더라도 동일한 order_id에 대한 결제는 한 번만 이루어진다. 이는 멱등성을 통해 중복 결제를 방지하고 시스템의 안정성을 높이는 데 도움된다.

추가적인 예시

• 자동 이체나 정기 결제 서비스 같이 사용자가 한번 등록한 이체나 결제 요청이 여러번 발생 할 수 있는데, 멱등성은 이러한 상황에서 중복 이체나 결제를 방지할 수 있게 안정적인 서비스 제공에 도움을 준다.
• 만약 매월 특정 날짜에 자동이체를 등록해둘 경우, 오류로 인해 여러번 요청이 되더라도 transaction_id에 대한 이체가 한 번만 이루어지게 해둘 수 있다.

멱등성은 금융 거래와 같은 중요한 작업에서 특히 중요한 역할을 한다.

GET과 POST의 차이와 설계시 고려할 점

간단하게 차이점을 얘기하면 GET은 정보의 요청, POST는 정보의 제출로 볼 수 있다.

GET(멱등성 O)

• 주로 쿼리스트링을 통해 데이터를 전송하며 url에 데이터가 노출이 됨으로 보안에 취약할 수 있으니 민감한 정보는 담지않는 것이 좋다. 또한 데이터의 길이 제한이 있다.
• 캐싱이 가능하고, 동일한 GET 요청에 대한 응답은 캐시에서 가져와 사용할 수 있다.

  POST(멱등성 X)

• 주로 리소스를 생성하거나 업데이트할 때 사용된다. 요청은 바디에 데이터를 담아 전송한다. url에 데이터가 노출되지 않으므로 GET 보다는 보안에 우수하지만 특정 경우를 제외하고는 목적을 분명하게 사용하는 편이 좋다. 데이터의 길이 제한이 없다.
• 캐싱이 어렵기 때문에, 동일한 POST 요청의 응답은 캐시에서 가져오지 않는다.

설계시 고려할 점

1. 보안

• 민감한 정보를 전송해야 하는 경우 POST를 사용하는 것이 좋다.

2. 데이터 길이

• 큰 데이터를 전송해야 할 경우 POST를 사용하는 것이 적절하다. GET은 URL 길이 제한이 있을 수 있다.

3. 멱등성

• 멱등성이 필요한 작업인지 고려하여 적절한 메소드를 선택한다.
• 조회나 검색과 같이 멱등성이 중요한 경우 GET을 사용하고, 리소스 변경이 필요한 경우에는 POST를 사용한다.
• HTTP 메소드의 적절한 사용은 웹 애플리케이션의 안정성, 효율성, 보안성 등에 영향을 미치므로 주의 깊게 고려되어야 한다.

4. 캐싱

• 캐싱이 중요한 경우 GET을 사용하여 캐싱을 활용한다.

5. RESTful 설계

RESTful API를 설계할 때는 각 메소드의 의도에 맞게 사용해야 한다. 리소스의 조회는 GET, 생성은 POST와 같이 목적에 따라 메소드를 사용한다.

참고 사이트

• https://mangkyu.tistory.com/251

2024.09.09 기준 fatal: the remote end hung up unexpectedly 에러 발생 시 해결 방법 추가

옮길 repository는 github, 옮겨올 repository는 gitlab으로 명칭하였습니다.

매번 옮겨올 때마다 찾아보기 귀찮아서 한번에 벨로그에 정리하였다.

gitlab에서 github 개인 레포로 잔디, 커밋 내역까지 가져오기

• 먼저 깃허브에 저장소를 새로 만들어준 후 아래 명령어대로 입력하면 된다!

  # gitlab 커밋내역까지 clone 해오는 명령어
  git clone --bare <깃랩 레포 주소>
  

clone해온 파일로 이동하기

cd <프로젝트명>.git

github로 옮기기

git push --mirror <깃허브 레포 주소>

## gitlab에 wiki를 github 레포에 옮기기


- 마찬가지로 github내에 wiki를 생성해준 후 아래 명령어를 입력해준다.
```bash
# gitlab wiki 가져오기
git clone --mirror <깃랩 레포 wiki 주소>

# clone해온 wiki 파일로 이동하기
 cd <프로젝트명>.wiki.git

# github로 옮기기
git push --mirror <깃허브 레포 wiki 주소>

그 외 명령어 정리

# 현재 프로젝트 파일에 연결된 repository 확인 
git remote -v

# 연결된 원격 레포 연결 해제
git remote remove origin

# 원격 레포 연결하기
git remote add origin <연결할 원격 저장소 주소>

fatal: the remote end hung up unexpectedly 에러 발생시 아래 포스팅 참고

fatal: the remote end hung up unexpectedly 오류 해결

끝

간단 동작 원리 정리

웹의 기본 구조

• 클라이언트 <- 방화벽 -> 웹서버 <--> WAS <--> DB 서버
• 방화벽 : http(s)://
• 웹서버 : www.velog.io
• WAS : /write?
• DB서버: id=dajflkdj

웹 서비스를 위한 서버측의 구성은 기본적으로 방화벽, 웹 서버 ,WAS(Web Application Server), DB서버로 구성된다.

방화벽(Firewall)

네트워크를 이용한 악의적인 공격으로부터 내부망과 내부 시스템을 보호하기 위한 보안 장비

웹 서버(Web Server)

HTTP 프로토콜을 이용하여 웹 클라이언트의 요청을 처리하고 응답한다. 사용자의 요청에 빠르게 응답하며, 최적의 UI(화면 구성)를 제공하는 것을 목적으로 한다.

웹 응용 서버(WAS)

• 웹 기반 서비스의 응용(Application) 역할을 담당한다.
• 웹 서버와 응용 서버를 분리하여 구성하므로, '사용자 요청에 대한 응답에 최적화된 웹 서버'의 장점과 '복잡한 로직을 처리하고 기능의 확장에 유리한 응용 서버의 장점을 모두 제공하게 된다.

  DB 서버

• 서비스를 위한 주요 데이터, 사용자 데이터 등을 저장하고 관리한다.

DNS (Domain Name System Server)

url들의 이름과 IP 주소를 저장하고 있는 데이터 베이스로 웹 사이트를 위한 주소록이다. IP주소 대신 사용자가 사용하시 편하도록 주소를 매핑해주는 역할을 한다.

TCP/IP(transmission Control Protocol/ Internet Protocol)

데이터가 어떻게 웹을 건너 여행하는지 정의하는 통신 규약이다. 송신자가 수신자에게 IP주소를 사용해서 데이터를 전달하고 그 데이터가 제대로 갔는지 이야기 하는 것이다.

웹 브라우저에 웹페이지가 표시되는 과정

• 사용자가 velog.io/write?id=saflk와 같은 url을 웹 브라우저의 주소창에 직접 입력하거나, 링크를 클릭한다.
• DNS(Domain Name System) 조회(Query)를 통하여 url을 IP주소로 변환한다.
• TCP의 3way-handshaking연결 방식으로 웹 서버에 연결하며, 일반적으로 80포트를 이용한다. HTTPS일 경우 443 포트를 이용하여 접속한다. ( 서버에 html문서 요청)
• HTTP 프로토콜을 이용하여 웹 서버에 /write?id=saflk를 요청(req)한다.
• /write는 서버에서 실행되는 기능으로, 관련 기능에 따라 WAS와 상호 연동한다. 이때, 필요한 경우 데이터베이스의 정보를 이용한다.
• 웹 서버는 최종 정보를 웹브라우저에 응답(Res)하고, 웹 브라우저는 전송 받는 내용을 표시한다.
• TCP의 4way-handshaking 연결 종료 방식으로 웹 서버와의 연결을 종료한다.

DNS Query의 목적

DNS 서버들을 검색해서 해당 사이트의 IP주소를 찾는대있다. IP 주소를 찾을 때까지 DNS서버에서 다른 DNS 서버를 오가며 에러가 날때까지 반복적으로 검색한다. = recursive search

HTTP 프로토콜

HTTP 요청 메소드(Req Method)

• ⭐️GET : URL 형식으로 리소스(res)데이터를 요청한다.
• ⭐️HEAD : 리소르의 헤더(header) 정보를 요청하며, 서버는 응답 메시지로 본문(body)을 제외한 헤더 정보만 사용한다.
• ⭐️POST : HTTP 요청을 헤더와 바디로 구분하여 사용하고, 요청할 내용을 바디에 담아 서버에 전송한다. 주로 Form문을 사용한 ㄷ이터 전송에 사용한다.
• PUT : 새로운 문서를 만들거나 기본 정보를 갱신하기 위해 사용한다.
• DELETE : 웹의 리소스(파일)를 삭제하기 위해 사용한다.
• CONNECT : 프록시(proxy)와 같은 중간 서버에 접속하기 위해 사용한다.
• TRACE : 요청한 리소스가 수신되는 경로를 확인하기 위해 사용한다.
• ⭐️OPTIONS : 웹 서버가 제공하는 메소드를 확인하기 위해 사용한다.

HTTP 응답과 상태코드

• 웹 클라이언트 요청에 대한 응답시 웹 서버는 HTTP 프로토콜의 버전, 웹 서버 정보, 상태 코드, 데이터 정보(Header 정보)등을 함께 전송한다.
• HTTP 상태코드는 1XX(조건부 응답, 정보교환), 2XX(성공), 3XX(리다이렉션), 4XX(요청오류), 5XX(서버오류)로 구분된다.

  HTTP 헤더 구조

• HTTP 프로토콜의 요청과 응답은 헤더(부가정보)와 바디(실제 데이터)로 구성된다.
• HTTP의 헤더와 바디는 한 줄로 구분 된다.(개행 문자인 \r\n으로 구분)

참고자료

• https://www.yes24.com/Product/Goods/116967738
• https://zero-base.co.kr/event/media_BE_school_qna
• https://github.com/ksundong/backend-interview-question#CS-%EA%B4%80%EB%A0%A8-%EC%A7%80%EC%8B%9D
• https://velog.io/@eassy/www.google.com%EC%9D%84-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90%EC%84%9C-%EC%9E%85%EB%A0%A5%ED%95%98%EB%A9%B4-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC