Web 이모저모

나는 백엔드/프론트 엔지니어는 아니지만…그래도 웹에 대한 기본 (?) 몇개만 정리해보았다. 인터뷰 대비용 겸이기도 하다.

HTTP Status Code

기본적으로 알면 좋으므로… 간단하게만 정리하자면..

  • 1xx: 정보 확인
  • 2xx: 통신 성공
    • 200 OK: 요청 성공
    • 201 Create: 생성 성공 (POST)
    • 202 Accepted: 요청 접수, 행동 X
    • 204 No Contents: 요청 성공, 내용 없음
  • 3xx: Redirect
    • 300 Multiple Choice: 요청에 대해서 하나 이상의 응답
    • 301 Move Permanently: URI가 영구히 변경됨
    • 304 Not Modified: 응답이 변경되지 않음 (캐시 사용)
  • 4xx: Client 오류
    • 400 Bad Request: API에 정의되지 않은 요청이 들어옴
    • 401 Unauthorized: 비인증, 인증해야함
    • 403 Forbidden: 권한이 없는 곳 접근 시도
    • 404 Not Found: 요청 받은 리소스를 찾을 수 없음
    • 405 Method Not Allowed: 사용할 수 없는 Method 사용
  • 5xx: Server 오류
    • 500 Internal Server Error: 서버 내부 오류
    • 502 Bad Gateway: 서버가 게이트 웨이로부터 잘못된 응답 수신
    • 503 Service Unavailable: 유지보수/과부하 등으로 서버가 요청을 처리할 준비가 되지않음
    • 504 Gateway Timeout: 게이트 웨이 시간 초과

Cookie & Session

쿠키와 세션은 Stateless한 HTTP 프로토콜에서 이전 요청과 현재 요청이 같은 유저인지 알기 위해 State를 저장하는 기술이다.

쿠키는 클라이언트 로컬에 저장되는 키/값을 가지고 있는 파일이다. 이름, 값, 유효 시간 등을 포함하고 있는데, 브라우저가 이를 참조하여 전송한다. 동작 방식에 대해 짧게 설명하면, 클라이언트가 페이지를 요청하면 서버에서 HTTP 헤더에 Set-Cookie를 이용해 쿠키를 포함해서 전송하고, 클라이언트의 브라우저는 이를 받아 다음 요청때 해당 쿠키를 헤더에 포함해서 전송한다. 장바구니 기능이나, 아이디/비밀번호 저장에 유용하다. 쿠키는 크기와 갯수에 제한이 있고, 유효시간이 지나면 만료 된다.

세션은 클라이언트가 아닌 서버측에서 관리가 되는데, 일정 시간 동안 같은 브라우저에서 들어오는 요청을 하나의 상태로 보고 그걸 유지하는 기술이다. 즉, 브라우저를 닫거나 일정 시간 응답이 많으면 만료가 된다. 보안은 좋지만 동접자 수가 많으면 많은 서버 메모리를 차지하게 되어 과부하를 주게 된다. 세션의 과정을 짧게 설명하자면, 클라이언트가 서버에 요청하면 클라이언트의 Unique한 ID (Session ID)를 부여하고, 쿠키에 세션 아이디를 넣어서 보내준다. 추후에도 Session ID를 헤더에 넣어 클라이언트가 요청하게 되고, 서버는 세션 ID를 확인하고 관련 정보를 확인한 후 응답한다. 이는 로그인에 자주 사용된다.

REST

REST란 Representational State Transfer의 약자로 HTTP 프로토콜을 활용하는 아키텍쳐이다. REST는 HTTP URI를 통해 Resource를 명시하고 HTTP Method (GET, POST, PUT, DELETE)를 통해 Resource에 대한 CRUD Operation을 적용하는 것을 의미한다. 즉, 이미지, 동영상, 텍스트 등 모든 자원에 고유한 URI를 부여하여 활용한다. REST는 다양한 클라이언트의 등장으로서 더 필요해졌다. REST는 쉽게 사용할 수 있고, 클라이언트와 서버의 역항릉 분리해주지만 HTTP 메소드의 형태가 제한적이라는 단점이 있다. REST의 구성 요소는 다음과 같다.

  1. Resource (자원): 모든 자원에 고유의 URI를 부여한다. Client는 URI를 통해 자원을 지정한다.
  2. Verb (행위): 자원을 조작하기 위해 Verb인 HTTP Method를 사용한다. GET, POST, PUT, DELETE가 그것이다.
  3. Representation(표현): 클라이언트가 서버로 요청을 보냈을때 응답을 보내주는 자원의 상태를 Representation이라 한다. JSON, XML, TEXT 등의 형태로 나타낼수 있다.

REST의 특징은 다음과 같다.

  1. Client - Server: 자원이 있는 Server, 자원을 요청하는 Client로 나눌 수 있다.
  2. Stateless: HTTP를 따라 무상태성을 가진다. 클라이언트의 Context를 저장하지않는다.
  3. Cacheable
  4. Layered System: API 서버는 비즈니스 로직만 수행하고 앞단에 인증, 암호화, 로드밸런싱의 계층을 둘 수 있다.
  5. Uniform Interface: URI로 지정된 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
  6. Code on Demand (Optional): Method + URI로 이루어져있어 무슨 행위를 하는지 알기 쉽다.

Rest 를 기반으로 서비스 API를 구현하면 REST API가 된다. REST API는 몇가지 설계 규칙을 가지고 있는데, /로 계층관계를 나타내고, 마지막 문자로 /를 두지않으며, _은 사용하지않는다. 또한 URI 경로는 소문자로 사용하고, 파일 확장자는 URI에 포함하지 않는다.

CORS

Cross Origin Resource Sharing의 약자로서 웹 서버에게 다른 출처의 리소스를 공유하는 방법이다. 필자도 이거 Access blocked 된 이슈가 있어서 꽤나 고생했던 적이 있었다. CORS 요청시에 Access-Control-Request-Method로 실제로 보내고자 하는 메서드들을 알리고, Access-Control-Request-Headers에 헤더들을 담아서 보낸다. 서버는 Access-Control-Allow-Origin 와 Access-Control-Allow-Methods를 확인해서 Request와 Allow가 일치하면 CORS요청이 이루어진다.

그래서 나의 경우에는 헤더에 ‘Access-Control-Allow-Origin’으로 넣어주고 있다. 미들웨어 CORS를 두는 법도 있다고는 알고 있다.

Socket.io vs Websocket

Querybook은 Socket.io를 이용해 실시간으로 작성된 글들을 Redis로 보내주고, Superset의 경우에도 Websocket을 놔둬서 tab과 user별로 관리를 할 수 있다. 둘다 실시간 스트리밍 중계/채팅 등에 쓰이는건 알겠는데, 그렇다면 이 둘은 어떻게 다를까? Websocket은 양방향 소통을 위한 프로토콜이다. HTML의 표준 기술로, 매우 빠르고 단순히 듣고 보내는것만 가능하다. Socket.io은 라이브러리라 보면 된다. Javascript를 사용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있다. Socket.io는 약간 느리지만 많은 편의성을 제공하고, 여러 언어들의 라이브러리 또한 지원된다.

잠깐, Websocket은 연결을 위해 HTTP 통신을 하긴한다. Handshake과정이 이루어지면 프로토콜 스위칭이 이루어져 Websocket으로 통신을 한다. HTTP모듈로 클라이언트는 Websocket을 가지고 있다. HTTP 자체에선 실시간 통신을 위해 Polling과 Long Polling, Streaming을 한다. Polling은 일정주기마다 요청을 보내고 서버는 상태를 바로 응답한다. Long Polling은 서버에서 이벤트가 발생 했을때 응답을 내려주고 클라이언트가 응답을 받았을때 다시 다음 응답을 기다리는 요청을 보내는것이다. Streaming은 Long Polling과 비슷하지만 연결을 끊지 않는다. 그러나 이 셋을 양방향 통신이라 보기 어렵다.

Reference

https://brunch.co.kr/@leedongins/65
https://interconnection.tistory.com/74
https://github.com/JaeYeopHan/Interview_Question_for_Beginner#part-1-%EC%A0%84%EC%82%B0-%EA%B8%B0%EC%B4%88
https://beomy.github.io/tech/browser/cors/
https://www.peterkimzz.com/websocket-vs-socket-io/