📌 모의 면접 회고

HTML 수업 때 데레사 강사님께 기술면접을 1:1로 본 이후로 오래간만에 모의 면접을 보게되었다.

박신영 강사님께서 인성면접을, 다른 수강생은 기술면접을 면접관 입장이 되어 나에게 질문해주었다.

1. 😃 인성 면접

어떤 개발자가 되길 원하는가?, 프로젝트 및 협업 과정에서 어떤 갈등을 겪었고 어떻게 해결하였는지 등 개발자로서 어떤 마인드를 가지고 있고 어떤 사람인지 판단할 수 있을 만한 질문들이었다.

모든 질문에 어떻게 답변했는지는 기억나지 않지만 피드백을 받은 것을 이야기해보자면,

👍 좋았던 점

1. 시작할 때 웃는 모습이 좋은 사람이라는 인상을 주고 마음을 편안하게 해주어 좋았다.
2. 커뮤니케이션과 협업을 일관되게 강조하고 중요시하고 있다는 점이 좋았다.
3. 말의 끝맺음을 제대로 하여 듣는 사람 입장에서 좋았다.
   • 추가로 대화에서, 개발에서 정리를 잘하는 사람인데 이 부분으로 어필할 수 있으면 더욱 좋을듯!
4. Why? 에 대해 생각하는 사람으로 느껴져서 좋았다.
5. 약점에 대해서 스스로 대안이 있어서 인상적이었다.

💦 아쉬운 점

1. 의견, 주장이 강해보여 의견 충돌 시 강한 타입처럼 느껴질 수 있을 것 같아보인다.
2. 어떤 개발자가 되고 싶냐는 질문에 좀 더 직무, 역량 관점에서 답변할 수 있으면 좋을 것 같다.
3. 면접볼 때는 흔들의자에 앉지 말고 고정된 의자에 앉도록 하자.
4. 개발자로서 역량 설명할 때 커뮤니케이션 부분에서 누구와 협업을 하는지에 대해서도 간략하게 짚고 넘어갔으면 좋았을 것 같다.
5. 협업 경험에 대해 설명할 때, 부정적인 얘기를 했던게 기억에 남을 것 같다. 이 부분을 나의 약점을 잘 살려냈던 것처럼 풀어나가보면 좋을 것 같다.
6. 신입,주니어 라는 용어 사용 금지

2. 🛠 기술 면접

기술면접은 프로젝트 경험에 대해 질문해주셨고 기술적으로 깊은 고민을 해본 적이 있는지, 면접자가 기술에 사용 이유와 원리를 알고 사용하는 것인지 확인하는 질문들이었다.

👍 좋았던 점

1. 페어프로그래밍을 통해 기술적인 단계를 깊이있게 공부하고 블로그에 정리해두었다는 점이 인상깊었다.
2. 기술 블로그에 대해 피드백을 받고 개선한다는 부분을 차별점으로 어필하는 모습 좋았다.

💦 아쉬운 점

1. 전반적으로 기술적인 답변이 제대로 나오지 않아 아쉬웠다.
2. CBD 라이브러리를 만들었다고 할 때 정확히 어떤 부분까지 만들어보았는지 자세한 설명이 부족했다.
3. 회피와 타협이라는 부정적인 단어 사용이 잦아서 아쉬웠다.
   • 부정적인 단어 대신 “라이브러리를 고치는 것은 비용이 많이 드는 작업이어서 프로젝트 기간에는 해당 부분을 이런 식으로 구현하여 해결하였다”로 사용해보자.
4. 트러블 슈팅 질문에 대한 답변이 기술적인 이슈 해결이 아닌 다른 답변이 나와서 아쉬웠다.
   • 트러블 슈팅 질문에 대한 소스들을 미리 준비해두면 도움이 될 것 같다.
5. 리팩터링 질문이 나왔을 때, 너무 협업에만 집중해서 이야기한 것이 아쉽다. 그렇다면 성능 개선, 최적화 등에 대한 고민을 하지 않는 것처럼 보여서 아쉬웠다.

댓글 공유

📌 CORS란?

교차 출처 리소스 공유(Cross-Origin Resource Sharing)는 추가 HTTP Header를 사용하여 한 출처에서 실행 중인 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게 알려준다.

웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때, 교차 출처 HTTP 요청을 실행한다.

ex) https://domain-a.com의 프론트 엔드 JavaScript 코드가 XMLHttpRequest를 사용하여 https://domain-b.com/data.json을 요청하는 경우 보안 상의 이유로 브라우저는 HTTP 요청을 제한한다.

• CORS 체제는 브라우저와 서버 간의 안전한 교차 출처 요청 및 데이터 전송을 지원한다.
• CORS 표준에 맞춘다는 것은 서버에서도 새로운 요청과 응답 Header를 처리해야한다.

🤿 DeepDive

CORS 표준은 웹 브라우저에서 허용된 출처를 서버에서 새로운 HTTP Header에 추가함으로써 동작한다.

📮 Simple Request

HTTP 요청 메서드가 GET, POST 일 때 사용한다.

1. 다른 출처끼리 요청을 보낼 때, 요청에 Origin이라는 Header를 추가한다.

   1	https://loco9939.com:5000

   • Origin은 요청하는 쪽의 Scheme, 도메인, 포트가 담겨있다.
   • scheme : https
   • 도메인 : loco9939.com
   • 포트 : :5000

2. 요청 받은 서버는 응답 Header에 지정된 ACAO(Access Control Allow Origin) 정보를 실어서 보낸다.

3. 브라우저가 ACAO 정보가 담긴 응답과 요청의 Origin을 비교하여 동일하면 허락한다.

✈️ Preflight

브라우저가 사전요청을 먼저 보낸 후 서버의 응답을 보고 안전한지 확인한 후 본 요청을 보내는 방식이다. 본 요청은 Simple Request 방식과 동일하다.

🌈 CORS 오류 해결 방법

🔨 서버 측

• ACAO(Access Control Allow Origin) 설정하기
  • 구체적인 출처 명시하기
  • Credentials: include 옵션 사용한 경우 * 사용한 경우 CORS 에러발생

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

var http = require("http");

const PORT = process.env.PORT || 3000;

var httpServer = http.createServer(function (request, response) {
  // Setting up Headers
  response.setHeader("Access-Control-Allow-origin", "*"); // 모든 출처(orogin)을 허용
  response.setHeader(
    "Access-Control-Allow-Methods",
    "GET, POST, OPTIONS, PUT, PATCH, DELETE"
  ); // 모든 HTTP 메서드 허용
  response.setHeader("Access-Control-Allow-Credentials", "true"); // 클라이언트와 서버 간에 쿠키 주고받기 허용

  // ...

  response.writeHead(200, { "Content-Type": "text/plain" });
  response.end("ok");
});

httpServer.listen(PORT, () => {
  console.log("Server is running at port 3000...");
});

Access-Control-Allow-origin 헤더 값으로 * 을 사용하면 모든 Origin에서 오는 요청을 허용한다는 의미이므로 당장은 편할 수 있겠지만, 바꿔서 생각하면 정체도 모르는 이상한 출처에서 오는 요청까지 모두 허용하기 때문에 보안은 더 허술해진다. 그러니 가급적이면 귀찮더라도 다음과 같이 출처를 직접 명시해주도록 하자.

👑 클라이언트 측

• Proxy 설정
  • 브라우저 요청을 Proxy에서 설정한 주소로 우회하여 전송하는 방법
  • 라이브러리 사용한다
  • 개발단계에서만 사용하고 Production 환경에서는 Proxy 처리가 되지 않는다.

댓글 공유

📌 디자인 패턴이란?

디자인 패턴은 애플리케이션내에서 각자 역할에 맞는 코드끼리 분리하여 유지보수성을 높이고 탄탄한 구조를 가진 애플리케이션을 설계할 수 있다.

✏️ 디자인 패턴 장점

1. 검증된 해결책

디자인 패턴은 소프트웨어 개발의 문제를 해결하는 확실한 접근 방식을 제공한다.

2. 쉬운 재사용

일반적으로 필요에 따라 조정가능하며 즉시 사용가능한 솔루션을 반영한다.

다만, 디자인 패턴이 모든 문제의 해결책은 아니다. 패턴의 역할은 솔루션 체계를 제공하고 이를 지원하는 역할을 한다.

이외의 사소한 문제를 예방할 수 있고 반복을 피하여 파일 크기를 줄일 수 있으며, 개발자간의 소통을 원할하게 하는 장점이 있다.

🛤 MVC 패턴

Model + View + Controller를 합친 용어이다.

• Model : 데이터와 데이터 변경 함수 관리하는 부분
• View : 사용자에게 보여지는 UI
• Controller : 사용자의 입력을 받고 처리하는 부분

동작

1. 사용자 액션이 들어오면 컨트롤러가 액션 확인하고 모델을 업데이트한다.
2. 컨트롤러는 모델을 나타낼 뷰를 선택한다.
3. 뷰는 모델을 이용하여 화면에 나타낸다.

1
2
3
4

참고 - MVC에서 View가 업데이트 되는 방법
- 뷰가 모델을 이용하여 직접 업데이트
- 모델이 뷰에게 알림을 주어 업데이트
- 뷰가 Polling으로 모델의 변경을 주기적으로 감지하여 업데이트

polling이란?

하나의 장치가 충돌 회피 또는 동기화를 목적으로 다른 장치의 상태를 주기적으로 검사하여 일정 조건을 만족할 때, 송수신 자료를 처리하는 방식

특징

• 컨트롤러는 여러 개의 뷰를 선택할 수 있는 1:n 구조
• 보편적이며 단순하다.
• 뷰와 모델 사이의 의존성이 높다. (bad~👎)

🏸 MVP 패턴

Model + View + Presenter를 합친 용어이다.

• Model : 데이터와 데이터 변경 함수 관리하는 부분
• View : 사용자에게 보여지는 UI
• Presenter : 뷰에서 요청한 정보로 모델을 가공하여 뷰에게 전달해주는 부분(View, Model을 붙여주는 접착제역할)

동작

1. 사용자 액션은 뷰를 통해 들어온다.
2. 뷰는 프레젠터에게 데이터를 요청한다.
3. 프레젠터는 모델에게 데이터 요청한다.
4. 모델은 프레젠터에게 요청받은 데이터를 응답한다.
5. 프레젠터는 뷰에게 데이터를 응답한다.
6. 뷰가 응답받은 데이터를 화면에 나타낸다.

특징

• 프레젠터는 뷰와 모델의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할
• 프레젠터와 뷰는 1:1
• 뷰와 모델간의 의존성이 없다. (Good~👍)
• 하지만 뷰와 프레젠터의 의존성 높다.

👑 MVVM 패턴

Model + View + View Model을 합친 용어이다.

• Model : 데이터와 데이터 변경 함수 관리하는 부분
• View : 사용자에게 보여지는 UI
• View Model : 뷰를 표현하기 위해 만든 뷰를 위한 모델

동작

1. 사용자 액션이 뷰를 통해 들어온다.
2. 뷰에 액션이 들어오면 Command 패턴으로 뷰 모델에 액션을 전달한다.
3. 뷰 모델은 모델에게 데이터를 요청한다.
4. 모델은 뷰 모델에게 요청받은 데이터를 응답한다.
5. 뷰 모델은 응답받은 데이터를 가공하여 저장한다.
6. 뷰는 뷰 모델과 데이터 바인딩하여 화면에 나타낸다.

특징

• Command 패턴과 데이터 바인딩 두가지 패턴을 사용(뷰와 뷰 모델 사이의 의존성 제거)
• 뷰 모델과 뷰는 1:n
• 뷰와 모델사이의 의존성도 없으므로 각 부분은 독립적으로 모듈화하여 개발할 수 있다.
• 뷰 모델 설계가 어렵다.

Command패턴이란?

요청을 객체 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 사용할 수 있도록 메서드명, 매개변수 등 요청에 필요한 정보를 저장,로깅, 취소하는 패턴이다.

참고

[디자인패턴]MVC,MVP,MVVM 패턴 비교

댓글 공유

📌 Flux 패턴

페이스북이 전통적인 MVC 디자인 패턴이 복잡한 애플리케이션에서 적합하지 않다고 판단하여 새로운 디자인 패턴을 소개한 것이 바로 단방향 데이터 흐름을 갖는 Flux 패턴이다.

🔥 문제점

애플리케이션 규모가 커짐에 따라 양방향 데이터 흐름을 그림처럼 복잡한 구조를 가지게 된다.

사용자와 상호작용하는 여러 View가 연결된 여러 Model을 업데이트하고 Model 또한 연결된 View를 업데이트하는 매우 복잡한 상황이 발생하기에 데이터 흐름을 예측하기란 매우 어려워진다.

사실 위 그림은 전통적인 MVC 패턴이고 Apple의 MVC 패턴은 사진처럼 Model과 View의 양방향 데이터 흐름이 발생하지 않는다. 문제는 양방향 데이터 흐름이다.

🦖 Flux 아키텍처

Flux 패턴은 앱의 단방향 데이터 흐름을 촉진하는 시스템 아키텍처를 말한다.

Action

사용자의 요청을 정의한 객체를 말한다.

• 사용자 요청 타입(Type)과 데이터(Payload)를 가진다.
• 액션 크리에이터(Action Creator) 함수를 사용하여 디스패처로 전달한다.

Dispatcher

디스패처는 중앙 데이터 흐름 관리한다. 스토어에 등록된 액션 타입마다 콜백되는 함수가 존재한다.

• 사용자 액션으로부터 받은 액션 타입에 맞는 콜백함수를 실행한다.
• 스토어 데이터 변경은 디스패처를 통해서만 가능하다.

Store

스토어는 상태(Model)를 관리하는 저장소이며 상태를 변경할 수 있는 콜백을 가진다. 각 액션을 처리하는 콜백함수는 디스패처에 등록된다.

• 상태와 상태를 변경하는 함수를 가진다.
• 디스패처에 등록된 콜백함수가 실행되면 스토어의 상태가 변경되며 View에 데이터가 변경되었음을 알린다.(옵저버 패턴 활용)

View

뷰는 사용자와 상호작용하는 컴포넌트이다. 스토어에서 상태가 변경되었다는 알림이 오면 뷰는 리렌더링이 발생한다.

• 사용자는 View를 조작할 수 있고 상태 변경을 요청하는 액션을 생성할 수 있다.
• 생성된 액션은 디스패처에게 전달되고 디스패처는 해당 액션에 연결된 콜백을 실행하여 스토어의 상태를 변경한다.
• 상태가 변경되었음을 뷰에게 알리고 뷰는 리렌더링이 발생한다.

댓글 공유

📌 Cookie란?

서버가 클라이언트에게 전송하는 데이터이다. 서버가 HTTP Response Header의 Set-Cookie에 내용을 넣어 전달하면 브라우저가 이 내용을 자체적으로 브라우저에 저장한다.

1
2
3
4
5
6

<!-- Reponse Header -->
HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookies: <cookie-name>=<cookie-value>

// Page Content...

• 쿠키는 key,value를 쌍으로 브라우저에 문자열로 저장된다.
• 주로 만료 기간을 설정하거나 자동으로 서버로 전송되어야할 작은 용량의 정보를 담는다.
  • Ex) n일 동안 보지 않기, 비로그인 장바구니 기능
• 쿠키는 주로 인증을 위해 사용된다.
• 쿠키는 세션쿠키와 퍼머넌트 쿠키가 있다.

🐶 Session Cookie

세션 쿠키는 클라이언트가 셧다운 되면 사라지는 쿠키이다. 왜냐하면 Expires, Max-Age를 지정해주지 않았기 때문이다.

일부 브라우저는 Session Resorting을 사용하여 세션쿠키를 영구적으로 만들 수 있다.

• Expires, Max-Age 설정으로 만료 기한을 정해주지 않은 쿠키

🐸 Permanent Cookie

클라이언트가 브라우저를 열고 닫거나 새로고침을 하여도 쿠키의 데이터가 보존되는 쿠키이다. Set-Cookie에 몇가지 조건을 추가하여 Permanent Cookie를 설정할 수 있다.

1

Set-Cookie: id=a3fWa; Expires=Thu, 10 Nov 2022 15:30:00 GMT;

• 만료시간은 클라이언트 시간을 따른다. (서버시간과 상이할 수 있다.)

✏️ 쿠키 접근

1
2
3
4

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
// logs "yummy_cookie=choco; tasty_cookie=strawberry"

🔨 쿠키 보안

🙅‍♂️ 민감한 정보는 HTTP 쿠키 내에 저장하면 안된다.

🪜 HttpOnly Cookie

XSS 공격으로부터 사용자의 쿠키 정보가 유출되는 것을 방지하기 위해 등장하였다.

1

Set-Cookie: id=a3fWa; Expires=Thu, 10 Nov 2022 15:30:00 GMT; HttpOnly

• document.cookie API로 접근할 수 없다.

🔒 Secure Cookie

HTTPS 전송을 보증해주는 역할을 하는 쿠키이다. Secure로 설정된 쿠키는 안전한 전송 프로토콜에만 쿠키 정보를 서버로 보낸다.

1

Set-Cookie: id=a3fWa; Expires=Thu, 10 Nov 2022 15:30:00 GMT; Secure; HttpOnly

👿 Cross-site 요청 위조(CSRF) 공격

현재 사용자가 은행 사이트에 로그인 되어있다. 송금과 같은 은행 업무를 보고 로그아웃 하지 않고 새 탭을 열어 어떤 사이트를 열었다. 그런데 이 사이트에는 해커에게 송금을 요청하는 form이 있고 이 form은 자동으로 제출되도록 설정되었다.

form이 해당 사이트를 거쳐 은행 사이트로 전송될 때 인증 쿠키도 함께 전송된다. 은행은 사용자로 착각하여 해커에게 돈을 송금하는 일이 발생한다.

⇒ 이런 공격을 크로스 사이트 요청 위조 라고 부른다.

🚪 방어 방법

• XSRF 토큰이라는 특수 필드 넣어줘야한다.
• 민감한 동작에 필수로 요구되는 확인 절차가 항상 수행하도록 한다.
• 민감한 동작에 사용되는 쿠키는 짧은 수명만 갖도록 한다.

댓글 공유

📌 GET

GET 방식은 전송 URL에 입력 데이터를 쿼리 스트링으로 보내는 방식
ex) http://jsonplaceholder.typicode.com/posts?userId=1&id=1

• 전송 URL 바로 뒤에 ?를 통해 데이터의 시작을 알려주고, Key-value 형태의 데이터 추가한다.
• 캐시가 가능하다.
• 1개 이상의 전송 데이터는 &로 구분한다.
• URL에 전송 데이터가 모두 노출되어 보안에 문제가 있어 민감한 정보는 사용하지 않는다. 전송할 수 있는 데이터의 한계가 있다. (최대 255자)
• REST API에서 GET 메소드는 모든 또는 특정 리소스의 조회를 요청한다.
  ⇒ GET 요청 보내면 ~ 이거이거 조회할게요~

📌 POST

POST 방식은 사용자의 요청을 Request Body에 담아 보내는 방식
ex) http://jsonplaceholder.typicode.com/posts

• URL에 전송 데이터가 모두 노출되지 않지만 GET에 비해 속도가 느리다.
• 캐시가 불가능하다.
• 데이터 길이와 타입의 제한이 없다.
• REST API에서 POST 메소드는 특정 리소스의 생성을 요청한다.
  ⇒ POST 요청 보내면 ~ 이거 생성해주세요~

댓글 공유

📌 HTTP

서버/클라이언트 모델을 따라 데이터를 주고받기 위한 프로토콜이다.

일반적으로 프로토콜을 이용하여 HTML 파일을 주고받을 수 있는 공간을 의미한다.

• 텍스트 교환으로 보안에 취약하다.

역사

초기 웹 페이지는 단순한 서버-클라이언트의 구조를 따랐다. 처음부터 TCP / IP 위에서 구현되도록 설계되었다. 지금의 TCP는 무겁고 느리다고 까이지만, 이 당시에는 연결 지향적 특성 때문에 안정적이고 신뢰성있는 통신을 제공하여 평이 좋았다.

초기 HTTP 구조는 매우 간단했다. 요청 메서드도 GET 한가지였고, 헤더나 상태 코드도 없었고 응답은 무조건 HTML 파일 그 자체였다.

하지만 웹이 인기를 끌다 보니 기존 HTTP 사양만으로는 사용자들의 요구사항을 충족시킬 수 없었고 명시적으로 약속된 사양이 없어 여러 브라우저들 간의 혼란이 있어서 HTTP 기본 구조를 그대로 유지하면서 HTTP를 표준화하기 위해 HTTP WG 조직이 탄생하고 이 때 HTTP/1.0이 탄생하게되었다.

📌 HTTP/1.0

• HTTP Header에 버전정보 명시되어있다.
• 요청 메서드 GET, POST, HEAD 3가지
• 상태 코드 추가 되어 클라이언트 측에서 요청 결과에 따라 동작하도록 설계 가능
• Content-type의 도움으로 HTML 이외의 파일도 전송할 수 있게되었다.

1
2
3
4
5
6
7
8
9
10
11
12

<!-- 요청 -->
GET /mypage.html HTTP/1.0
User-Agent: ...

<!-- 응답 -->
200 OK
...
Content-Type: text/html
<HTML>
  A page with on image
  <img src="/myimage.jpg" />
</HTML>

• HTTP/1.0의 간단한 요청과 응답 예시이다.

📌 HTTP/1.1

❓ HTTP/1.0의 문제

• HTTP/1.0에서는 요청에 따른 응답이 수신되면 TCP 연결 바로 종료
  • 웹 페이지가 복잡해짐에 따라 이러한 TCP 핸드쉐이크 과정을 새로 거쳐야 하여 속도가 느려지는 문제가 있었다.
• 1개의 요청을 보내면 1개의 응답을 받고 1번의 연결이 종료된다. 만약 10번의 요청을 보내면 TCP 연결을 10번 해야하므로 서버에 부담이 된다.

❗️ 문제 해결책

• 연결 상태 유지(Persistent connection) : 기본적으로 한번 수립한 연결을 재사용 할 수 있도록 설정
  • 지정한 시간동안 연결을 끊지 않는 방식
  • 연결 유지 시간 길어지면 서버 부하 🔺
• Pipelining(파이프라이닝) : 클라이언트가 여러 요청 연달아 보내야할 때, 먼저 보낸 요청의 응답을 기다리는 것이 아니라 발생한 요청은 일단 전송하는 방식
  • 클라이언트에서 여러 요청을 순차적으로 보내면 서버는 받은 순서에 따라 응답을 제공한다.

📌 HTTP/2

❓ HTTP/1.1의 문제

• 매 요청마다 헤더를 중복해서 전송해야만 하는데 이것이 굉장한 낭비였다.
• 서버가 항상 요청받은 순서대로 응답해야하므로 HOLB(Head-of-Line Blocking) 방식이었다.
• 하나의 연결 내에서 응답 다중화(multiplexing)을 할 수 없어 요청이 순차적으로 처리되어야 했는데, 서버가 응답 작성 중간에 문제가 생기면 후속 요청들이 전송되지 못하고 지연되는 문제가 있었다.

❗️ 문제 해결책

• SPDY 프로토콜 기반으로 동작 ⇒ 웹 페이지 로드 시간 단축
  • 이진 프로토콜 : 단순 텍스트를 전송하는 것보다 컴퓨터 입장에서 훨씬 더 효율적으로 데이터 전송 가능

• 응답 다중화 지원 : 하나의 TCP 연결에서 여러 요청을 동시에 처리할 수 있다. 바이너리 프레이밍으로 TCP 연결을 스트림, 메시지, 프레임으로 세분화하였다. 이는 요청 별 순서를 반드시 지켜야 했던 HTTP/1.1과 대조적이다.
  • 스트림 : 요청과 응답이 양방향으로 오가는 연결 단위
  • 메시지 : 하나의 요청과 응답을 구성하는 단위
  • 프레임 : 메시지를 구성하는 최소 단위

• 위 사진에서 하나의 TCP 연결에서 3개의 스트림이 존재한다.
• 5번 스트림은 클라이언트 측에서 서버로 데이터 전송하고, 1,3번 스트림은 서버 측에서 클라이언트로 데이터를 전송중이다.
• 1번 프레임 사이에 3번 스트림의 프레임이 끼워져있다.

이로써 HTTP/1.1에서 발생한 HOLB 문제 해결할 수 있었다.

• 헤더 필드 압축 지원 : 달라진 부분만 다시 전송하는 코딩 기법 사용

📌 HTTP/3

❗️ TCP로 인한 문제점

앞서 헤더 필드 압축을 통해 HTTP/1.1에서 발생한 HOLB 문제를 해결했다고 하였지만 이와 별개로 TCP로 인해 발생하는 HOLB 문제는 해결할 수 없다는 한계가 있었다.

• 신뢰성 지향하기에 데이터 손실 발생 시 데이터를 재전송하는데 순서대로 처리해야하기 때문에 HOLB 문제를 해결할 수 없다.
• 혼잡제어를 수행하기 때문에 전송 속도를 낮은 상태에서 높이는 방식으로 속도 제어를 하는데 이는 네트워크 상황이 좋을 때 불필요한 지연을 발생시킨다.

문제를 해결하기 위해 TCP/IP기반이 아닌 UDP기반인 QUIC 프로토콜 위에서 동작하는 HTTP/3가 나왔다.

⇒ UDP는 신뢰성을 보장하지 않는데 QUIC 신뢰성 기능을 직접 구현하여 신뢰성 기능이 제공되는 UDP 기반의 프로토콜이다.

👍 HTTP/3 장점

• 0-RTT 기능 : 연결 정보를 캐싱하여 재사용하여 다음 연결때는 바로 연결이 가능

• 연결 다중화 지원 : 각 스트림이 독립적으로 동작한다.
  • HTTP/2 방식의 경우 TCP 특성상 데이터 손실이 발생할 경우 데이터 복구를 우선 처리하여 HOLB가 발생한다.
  • HTTP/3는 데이터 손실이 발생해도 연결 내 스트림이 독립적으로 동작하기 때문에 다른 스트림에 영향을 주지 않는다.
• 연결 별 고유 UUID 지원
  • TCP 기반의 통신은 wifi 환경에서 셀룰러 환경으로 이동하는경우 IP주소가 변경되어 연결 재수립 과정을 거쳐야하지만, QUIC는 UUID(Connection ID) 연결 ID 기반으로 식별하여 연결을 유지할 수 있다.

📌 HTTP Message

HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식이다. 메시지 타입에는 요청(Request), 응답(Response)이 있다.

요청과 응답의 구조는 유사하다.

1. 실행 되어야 할 요청 또는 요청의 성공, 실패가 기록된 한줄

2. 요청에 대한 설명, 메시지 본문에 대한 설명이 포함된 HTTP Header 세트(optional)

3. 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄(blank line)

4. 요청과 관련된 내용이 옵션으로 들어가거나, 응답과 관련된 문서가 들어간다. 본문의 존재 유무는 첫 줄과 HTTP Header에 명시된다.

✏️ HTTP Request

요청은 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지이다.

1. Start Line

1. HTTP 메서드

GET,POST 등의 서버가 수행해야 할 동작을 나타낸다.

2. 요청 타겟 : URL 또는 (프로토콜,포트, 도메인)

요청 타겟 포맷은 HTTP 메서드에 따라 달라진다.

• Origin 형식 : 끝에 ‘?’와 쿼리 문자열이 붙는 절대경로이다. 가장 일반적인 형식으로 GET, POST, HEAD, OPTIONS 메서드와 함께 사용한다.

1
2
3
4

POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0

• absolute 형식 : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET과 사용한다.

1

GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

3. 마지막으로 HTTP 버전이 들어간다.

2. Header

대소문자 구분없는 문자열 다음에 콜론(:)이 붙고 그 뒤에 오는 값은 Header에 따라 달라진다.

• HTTP Method
• HTTP Version
• Host
• Content-Type

3. Body(본문)

모든 요청에 본문이 들어가지 않는다. GET, HEAD, DELETE, OPTIONS 처럼 리소스를 가져오는 요청은 본문이 필요 없다.

보통 POST 요청으로 서버에 데이터를 업데이트 하기 위해 본문이 필요하다.

본문은 두가지 종류로 나뉜다.

• 단일-리소스 본문(single-resource bodies) : Header 2개(Content-Type, Content-Length)로 정의된 단일 파일
• 다중-리소스 본문(muliple-resource bodies) : 파트마다 다른 정보를 지닌다.

✏️ HTTP Response

응답은 요청에 대한 서버의 답변이다.

1. Start Line

1. 프로토콜 버전 (보통 HTTP/1.1)

2. 상태 코드 : 요청의 성공 여부를 나타낸다. 200, 404 또는 302

3. 상태 텍스트 : 상태 코드에 대한 설명글

1

HTTP/1.1 404 Not Found.

2. Header

요청 Header와 동일한 구조이다.

• HTTP Version
• Status
• Content-Type
• Set-Cookie

3. Body

모든 응답에 Body가 들어가지는 않는다. 201, 204 상태 코드를 가진 응답은 Body가 없다.

📌 HTTPS

기존 프로토콜에서 데이터가 쉽게 도난당하는 것을 방지하기 위해 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 프로토콜 을 사용하여 브라우저와 서버를 암호화하여 연결해준다.

또한 데이터가 전송중에 손상되거나 수정되는 것을 방지한다.

• 구글같은 포털에서 SEO 가산점을 준다.

✏️ SSL(Secure Socket Layer) 프로토콜

HTTPS 프로토콜이 텍스트를 암호화 할 수 있도록 도와주는 프로토콜이다. 암호화 원리는 공개키 암호화 방식이다.

SSL 프로토콜 통제권을 IETF로 넘기면서 TLS로 바뀐 상태인데 현재는 두가지를 혼용해서 사용하고 있다.

공개키 암호화 방식

공개키 암호화 방식은 공개키와 개인키를 사용하는 방식이다.

• 공개키는 모두에게 공개해서 사용하는 키이다.
• 개인키는 서버에서만 가지고 있는 키이다.

예시

1. A 서버가 HTTPS 적용하기 위해 공개키와 개인키를 만든다.
2. CA 기업을 선택하고 해당 CA 기업에게 공개키 관리를 부탁하며 계약한다.
3. CA 기업은 기업명, A 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공한다.
4. A 서버는 CA 기업의 개인키로 암호화된 인증서를 가지고서 클라이언트로부터 HTTPS이 아닌 요청이 오면 암호화된 인증서를 건네준다.
5. 클라이언트는 예를 들어 main.html 을 서버에 요청했다고 하자. HTTPS 요청이 아니기 때문에 CA기업의 개인키로 암호화된 인증서를 받게된다.
   • CA 기업의 공개키는 모두에게 공개되므로 클라이언트는 인증서를 공개키로 복호화하여 A 서버 공개키를 얻었다.
6. 클라이언트가 A 서버에 요청을 보낼 때 텍스트를 공개키로 암호화하며 HTTPS 요청을 보낸다.
7. 서버는 개인키로 암호화된 텍스트를 복호화하여 데이터를 해석하고 응답을 개인키로 암호화하여 클라이언트에게 보낸다.
8. 클라이언트는 다시 공개키로 응답을 해석하여 해당 서버가 인증된 서버임을 알 수 있다.

📚 참고

• Velog/@Jiseung

• [MDN] HTTP

• Tech Interview

• 웹 개발자라면 알고 있어야 할 HTTP의 진화 과정 | 요즘IT

댓글 공유

📌CDN

• Content Delivery Network의 약자
• 지리적으로 분산된 여러 서버가 있고 사용자와 지리적으로 가까운 서버에서 전송하여 전송속도를 높인다.
• ATM기기와 비슷하다고 생각하면 된다.

CDN은 전체 트래픽의 균형을 맞춰 인터넷 컨텐츠에 접속하는 사용자들에게 최고의 웹 경험을 제공한다.

사용이유

20여 년동안 전 세계 사용자들이 빠르고 확장성있게 온라인 콘텐츠를 전송하도록 도와주었다.

만약 CDN을 사용하지 않았더라면 Origin 서버가 data를 복제 및 저장한 후 사용자가 웹에 접속하는 곳까지 컨텐츠를 가져가야하기 때문에 인터넷 속도가 느려질 수 있다.

단점

Origin 서버와 다른 여러 서버가 연결되어 있는데, 이 서버중 한곳에라도 문제가 생길 시 CDN을 사용하는 데에 문제가 발생할 수 있다.

가령 수강생들끼리 axios를 CDN으로 적용하여 페어프로그래밍 진행중 CDN이 먹통이 되어 모두 원하는 코드가 동작하지 않았던 경험이 있다.

🏓 소감

간편하게는 사용하면 좋을 것 같지만 프로젝트를 하거나 안정성이 요구되는 상황에서는 CDN을 지양하는 것이 좋겠다.

댓글 공유

기술면접 후기

제로베이스 커넥to 스쿨에 들어온지 4주차에 접어들었다.

데레사 강사님의 HTML/CSS 수업을 들으며 정신없이 과제도 하며 나름 수업 복습도 열심히 하면서 지내왔다고 생각했다.

면접은 항상 준비가 되어있든 되어 있지 않든 긴장감이 있기 마련이다.

하지만 이번 기술면접은 다른 면접과는 다르게 더욱 긴장되었다.

그 이유는 거의 한달동안 배웠던 수업 내용에 대해 (자바스크립트 질문도 많았지만,) 면접관에게 직접 설명을 해야했고,

그 과정에서 나를 어필할 수 있는 방법을 써서 설명을 해야하는 부분 때문에 더욱 부담스럽게 느껴졌다.

면접은 20분간 진행되기로 예정되었지만 긴장을 하여 말이 빨라지니 13분만에 끝마쳤다.

나름 면접관에게 돋보이기 위해 제스쳐도 크게 하려하고 아이컨택도 많이 하려고 했다.

하지만 개념에 대해 명확하게 알고 있지 않았고 명확히 알고 있는 개념도 누군가에게 말로 설명을 해보지 않았는데,

실제로 말로 해보려하니 머릿속에서 정리되지 않아 논리적이지 않은 사람으로 보였다.

피드백

1. 면접관의 흥미를 유발하라

오늘 면접관님의 태도는 매우 좋았다. 내가 무슨 말을 하는지 귀담아 들으려 노력해주시고 아이컨택도 계속 해주셨다.

하지만 실제 면접장에서 면접관들은 지원자의 말을 귀담아 듣지 않는다.

나라는 존재를 수많은 지원자 중에 1명으로 보여지게 하고 싶지 않다면, 그들의 흥미를 유발할 수 있는 어조, 제스쳐, 스토리 등으로 나를 어필해야 한다.

예를 들어, 클로져에 대해 아는대로 설명해보세요 라는 질문을 받았다면 다음과 같이 답변해보자.

제가 클로저라는 부분을 처음 접했을 때, 왜 자바스크립트에서만 이런 개념이 생겨나는지 궁금해서 찾아보았다. 그 이유 자바스크립트에서는 public 개념과 private 개념이 없기 때문이라는 것을 알게 되었다. 하지만 현재는 클래스라는 개념이 생겨나 이런 부분을 해결할 수 있었다. 저는 이 부분을 사용하여 이런 부분을 개선해보도록 노력해본 경험이 있습니다.

위와 같이 스토리를 풀어서 설명하면 면접관의 흥미를 유발할 수 있을 것이다.

2. 말로 안되면 그려서라도 설명하라

프로그래밍 개념은 말로만 전달하기 어려운 개념들이 많이 존재한다.

내가 만약 조리있게 말하지 못할 것 같은 질문이 나왔다면, 면접관에게 양해를 구한 후 그림을 그려서라도 설명을 해보자

이 때, 주의해야할 점이 그림을 다 그린 후 머릿속에서 어떻게 설명할지 정리한 다음에 설명을 이어가자.

면접장에 가면 마음이 조급해져서 위와 같은 상황에서 그림도 이해할 수 없을 정도로 대충 그리고 그 상태에서 말을 진행하게 된다.

이렇게 되면 그림을 그릴 시간을 달라한 이유가 없다.

3. 모르는 것은 모른다라고 확실히 말하자

아는 척하여 무엇 무엇 일 것 같다.. 라는 식의 답변은 최악이다.

모르는 질문이 나왔다면 모른다고 답변하자. 다만, 여기서 태도의 차이가 분명하게 나타날 수 있다.

누군가는 그 질문에 대해 모른다고 답변하고 끝날지라도, 누군가는 그 질문과 연관된 다른 내용을 설명해도 되겠냐는 양해를 구한다.

두명의 지원자를 비교해보았을 때, 당신이라면 누구를 더 선호할 것인가?

소감

아침부터 프로젝트도 준비해야하고 기술면접도 준비해야해서 머리도 복잡해지고 힘든 하루가 지나갔다.

그래도 기술면접을 직접 경험해봄으로써 실제 면접장의 압박감과 내가 어떤 부분에서 부족하게 보였는지를 알게되어

그 부분을 고쳐나가면 면접을 즐길 수 있게 될 것 같다.

나를 죽이지 못하는 고통은 나를 더 성장하게 만든다.

댓글 공유