[CS 스터디] 네트워크 1

1. 쿠키와 세션의 차이에 대해 설명해 주세요.

세션은 서버측에서 클라이언트에 대한 고유 세션 ID를 발급하고 저장하여 관리하는 공간을 의미합니다.
클라이언트가 보낸 요청이 인증된 요청인지 세션 ID를 통해 정보를 조회하고 올바른 정보가 세션에 저장되어 있는 것이 확인되면 요청을 처리해주는 방식을 구현하기 위한 저장 공간입니다.
쿠키는 쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일을 의미합니다.
쿠키는 사용자 인증에 필요한 유효시간을 명시할 수 있고, 유효시간 내에서는 브라우저가 종료되더라도 유지됩니다.

세션 방식의 로그인 과정에 대해 설명해 주세요.

클라이언트가 서버로 요청을 보냅니다. (로그인 요청)
서버는 해당 요청에 있는 클라이언트의 ID, 비밀번호를 참고해 유저 정보를 조회합니다.
조회된 정보를 특정 세션 ID의 value로 지정해 세션에 저장합니다.
응답 객체 해더에 세션 ID를 담아 클라이언트에게 전달합니다.
브라우저에서 쿠키에 해당 세션 ID를 저장합니다.
이후 다른 요청을 서버에게 보낼 때, 요청 헤더에 세션 ID를 담아 보냅니다. (로그인 요청 외 다른 서비스 이용)
서버에선 해당 세션 ID의 정보 여부와 검증을 통해 요청의 처리 여부를 결정합니다.

HTTP의 특성인 Stateless에 대해 설명해 주세요.

Stateless는 서버와 클라이언트가 통신을 위해 한번 연결을 맺은 후, 요청에 따른 응답을 주고 받았다면 연결을 끊고 서로의 존재를 유지하지 않는 것을 의미합니다.
더 자세히 말하면, 서버가 클라이언트에 대한 정보를 유지하지 않는 것입니다.
이러한 다양한 서버와 클라이언트가 연결과 통신을 주고받은 HTTP 환경에서 서버가 수많은 클라이언트에 대한 정보를 유지하는 것은 불필요한 리소스를 많이 생성할 수 있기 때문입니다.

Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

Stateless한 HTTP의 성격을 보안하기 위한 인증 방식으로 세션이 사용된다고 생각합니다.
클라이언트가 동일한 서버에 요청을 보내야 할 때마다 동일한 인증절차를 거쳐야 한다면 이 또한 불필요한 반복 작업이 진행되며 이를 줄일 필요성도 있습니다.
그렇기 때문에 로그인을 통해 한번 인증을 받은 이후에는 서버가 세션에서 클라이언트에 대한 정보를 일정 기간동안 유지하면서 효율적인 요청 처리가 가능하다고 생각합니다.

규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

Scale Out을 고려한 설계에서 서버의 개수가 여러대가 된다면 세션에 대한 동기화 문제를 해결해야 합니다.
이는 각각의 서버마다 고유의 세션을 가질 수 있기 때문입니다.
그래서 이를 관리하는 방법은 다음과 같이 세가지가 있습니다.
- Sticky Session
  - 각각의 서버가 개별적인 세션을 관리하는 것입니다. 그리고 로드밸런서는 클라이언트 별로 접근할 서버를 고정합니다.
  - 이 과정에서 특정 서버만 과부화가 올 수 있고 세션 서버가 다운되면 해당 서버에 붙어있던 세션이 모두 유실되는 단점을 가지고 있습니다.
- Session Clustering
  - 모든 서버에 저장된 데이터를 공유하고 모든 세션이 같은 정보를 가지고 있게끔 생성된 객체를 공유 및 복제하는 방식입니다.
  - 이는 세션들의 동기화는 가능하지만 서버의 수가 많아질수록 소요도 함께 커진다는 단점이 있습니다.
- Session Storage
  - 모든 서버가 동일하게 접근할 수 있고 관리하는 하나의 공통 저장소를 구성하는 방법입니다.

2. HTTP 응답코드에 대해 설명해 주세요.

HTTP 응답코드는 클라이언트가 보낸 요청을 처리하고 응답을 리턴할 때 응답에 대한 상태를 표현하는 코드입니다.
응답 코드의 종류는 다음과 같습니다.
- 정보 응답(1xx)
- 성공 응답(2xx)
- 리다이렉션 메세지(3xx) : 서버로의 재요청을 해야하는 상황인 경우
- 클라이언트 에러 응답(4xx) : 클라이언트 측에서 문제로 정상적인 처리가 되지 않은 경우(인증 실패, url 오타)
- 서버 에러 응답(5xx) : 서버 측에서의 문제로 정상적인 처리가 되지 않은 경우(런타임 에러, 타임아웃)

401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?

mdn에서 정의하는 401과 403은 다음과 같습니다.
- 401 (Unauthorized)
  - 비록 HTTP 표준에서는 “미승인(unauthorized)”를 명확히 하고 있지만, 의미상 이 응답은 “비인증(unauthenticated)”을 의미합니다.
  - 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.
- 403 (Forbidden)
  - 클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다.
  - 예를 들어 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다.
  - 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.
“401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.” 라고 명시가 되어 있습니다. 이는 인증과 인가에 대한 차이점과 동일하다고 생각합니다.
- 인증(Authentication) : 서버에 접근 권한을 얻는 것으로 로그인 절차를 의미합니다.
- 인가(Authorization) : 특정 요청에 대한 클라이언트의 접근을 허용해 주는 것으로 접근 가능 범위와 관련이 있습니다.
그래서 로그인 자체가 되어 있지 않아 서버에서 제공하는 서비스 자체에 접근할 수 없는 상태라면 401 에러가 맞고 로그인은 되어 있는데 해당 클라이언트가 가진 권한으로는 접근하거나 처리할 수 없는 요청을 했을 경우는 403 에러가 맞습니다.
인가 실패의 구체적인 예로는, 관리자 전용 url로 접근했을 경우나 체험판 사용자가 구독 회원이 사용할 수 있는 서비스에 대한 요청을 하는 경우가 있습니다.

200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.

200은 클라이언트의 요청이 정상적으로 서버에 전달되어 처리되었다의 의미를 가집니다.
201은 클라이언트의 요청이 성공했고 이로 인해 새로운 리소스(DB에 CREATE가 동작)가 생성이 되었다는 것을 명시합니다.
그래서 201은 PUT, POST의 경우에만 사용되며 200은 통상적으로 사용됩니다.

(추가 질문) HTTP/1.1과 HTTP/2.0의 응답 코드는 다른가요?

동일합니다. 그래서 두 버전은 호환이 가눙합니다.

3. HTTP Method 에 대해 설명해 주세요.

HTTP Method란 클라이언트와 서버 사이에 이뤄지는 요청과 응답 데이터를 전송하는 방식을 정의하는 것입니다.
즉, 서버가 수행해야 할 동작을 지정하는 요청을 보내는 방법입니다.
HTTP Method의 종류와 특징은 다음과 같습니다.
- GET : 리소스 조회
- POST : 요청 데이터 처리, 주로 데이터 등록에 사용
- PUT : 리소스를 대체(수정), 해당 리소스가 없으면 생성, 만약 일부 데이터만 전달되면 전달되지 못한 데이터는 사라질 수 있습니다.
- PATCH : 리소스를 일부만 변경, 변경할 데이터만 서버로 전달해도 다른 데이터는 기존의 값을 유지합니다.
- DELETE : 리소스 삭제
위 5가지 외에도 사용할 수 있는 메소드 종류는 다음과 같습니다.
- HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
- OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
- CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
- TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP Method의 멱등성에 대해 설명해 주세요.

멱등성이란 같은 연산을 여러번 실행해도 그 결과가 달라지지 않는 성질을 의미합니다.
HTTP Method에서 멱등성을 적용해본다면 여러번 요청을 보내더라도 그 결과로 받는 응답은 항상 동일해야 한다는 의미를 가집니다.
이 경우, 주요 메소드 중 GET, PUT, DELETE는 멱등성을 보장한다고 볼 수 있지만 POST와 PATCH는 그렇지 않습니다.
- POST는 데이터 추가를 위한 동작이므로 요청이 실행될 때마다 새로운 리소스가 생성될 것입니다.
- PATCH는 멱등성이 보장되도록 설계가 되었지만 멱등성을 보장하지 않는 형태로로 구현이 가능합니다.
  - age를 10씩 더하는 연산이라면? 동작할 때마다 age는 계속 증가할 것입니다.

GET과 POST의 차이는 무엇인가요?

GET의 특징은 다음과 같습니다.
- 정보 요청, 조회의 목적으로 사용됩니다.
- 파라미터로 데이터를 서버측에 전달합니다.
- 요청이 캐싱될 수 있습니다.
- 브라우저에 기록이 남습니다.
- 북마크에 추가할 수 있습니다.
- 데이터 길이 제한이 있습니다.(경로 문자 수를 뺀 최대 2,048자로 제한)
- 요청 성공시, 200 코드나 여러 형태의 데이터를 함께 반환합니다.
- 멱등성을 보장합니다.
POST의 특징은 다음과 같습니다.
- 데이터 생성의 목적으로 사용됩니다.
- 바디에 데이터를 담아 서버측에 전달합니다.
- 요청이 캐싱되지 않습니다.
- 브라우저 그록에 남아 있지 않습니다.
- 북마크에 추가할 수 없습니다.
- 데이터 길이 제한이 없습니다.
- 요청 성공시, 201 코드를 반환합니다.
- 멱등성을 보장하지 않습니다.

POST와 PUT, PATCH의 차이는 무엇인가요?

우선 세 메소드의 특징은 간단하게 아래와 같습니다.
- POST : 데이터 생성을 담당하는 메소드로 연속 요청 시 새로운 데이터가 계속해서 생성됩니다.
- PUT : 데이터 수정 및 대체를 담당하는 메소드로 이미 존재한다면 수정, 아니면 생성을 하게 됩니다.
- PATCH : 데이터 일부 수정을 담당하는 메소드로 리소스에 포함된 데이터 중 일부만 전달해도 기존 데이터는 유지한 상태로 일부 수정만 이뤄집니다.
이를 특성 별로 나눠본다면 아래와 같습니다.
- 데이터 생성 가능 여부 : POST, PUT은 가능 / PATCH는 불가능
- 멱등성 보장 : PUT은 보장 / PATCH는 상황에 따라 다름 / POST는 미보장

HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?

GET 요청의 의미는 단순 조회 목적으로 사용되므로 서버에 영향을 주지 않는 안전한 요청임을 보장하는 내용이 포함되어 있습니다.
그러다 보니 body를 통해 전달되는 것을 허용해 민감한 데이터가 전달되어 서버에 영향을 준다면 이는 위험한 설계일 수 있다는 의견이 존재했습니다.
하지만 이후에는 보안적인 측면에서 큰 문제가 있다고 판단하지는 않지만 과거에 금기되었던 이미지가 있어 일부 서버에선 GET 요청에 body를 추가하면 거절당할 수 있어 되도록 지양하게 되었다고 알고 있습니다.

(추가질문) POST로 처리할 수 있음에도 GET을 사용하는 이유는 무엇일까요?

GET은 멱등성을 가지고 있기 때문입니다. 멱등성을 유지하기 위해선 POST보단 GET을 사용하는 것이 좋습니다.
GET에 민감한 데이터를 담게 되면 파라미터에서 노출이 되므로 보안적인 측면에서 제한된 데이터를 사용한 설계 및 구현이 가능합니다.

(추가질문) PRG 패턴에 대해서 설명해주세요.

POST 방식에서 중복 처리되는 문제를 해결하기 위해 적용할 수 있는 패턴입니다.
즉, POST 방식으로 온 요청에 대해서 GET 방식의 웹페이지로 리다이렉트 시키는 것을 의미합니다.

4. HTTP에 대해 설명해 주세요.

HTTP는 인터넷 프로토콜 규약에서 네트워크 계층이 속하는 통신 규약 중 하나입니다.
HTTP는 웹 문서 요청과 전송을 위해 사용되며 그 중 하나로 HTML을 예로 들 수 있습니다.
즉, HTML과 같은 웹 문서를 서버와 클라이언트가 주고 받는 약속을 의미합니다.
HTTP의 특징은 다음과 같습니다.
- 클라이언트-서버 구조
  - 요청을 보내는 클라이언트와 요청을 처리해 응답만을 전달해주는 서버로 구성됩니다.
  - 이로 인해 두 객체간의 결합도가 낮아져 독립적으로 동작 및 발전시킬 수 있었습니다.
- Connectionless
  - 서버와 클라이언트의 연결을 유지하지 않습니다.
  - 이는 리소스의 낭비를 최소화 하기 위함이며 한번 연결을 맺고 문서나 데이터를 주고 받으면 연결을 끊는 것을 의미합니다.
- Stateless
  - 서버가 클라이언트의 상태를 가지고 있지 않습니다.
  - 이 또한 리소스의 낭비를 줄이기 위함입니다.
  - 크라이언트가 서버에게 요청을 보낼 때, 보내는 요청마다 클라이언트에 대한 정보를 포함해 모든 정보를 담아서 요청을 보내 서버가 직관적으로 요청을 이해할 수 있도록 하기 위함입니다.
  - 이로 인해 요청 자체는 복잡해지지만 서버가 클라이언트에 대한 정보를 유지할 필요가 없습니다.
  - 이러한 성격으로 서버는 확장에 용이한 구조를 가질 수 있습니다. -> 클라이언트와의 결합도를 낮추는 구조

공개키와 대칭키에 대해 설명해 주세요.

키라는 것은 서버와 클라이언트가 주고 받은 데이터에 대한 보안을 높혀 외부로 데이터가 노출되는 것을 막기 위해 사용됩니다.
키를 가지고 데이터를 암호화 할 수 있고 암호화된 데이터를 복호화할 수 있습니다.
키의 종류는 크게 공개키와 대칭키로 나눠볼 수 있습니다.
- 대칭키
  - 서버와 클라이언트가 가지고 있는 키가 동일한 방식입니다.
  - 하지만 키가 탈취되고 노출될 경우, 보안성이 매우 떨어지는 단점이 있습니다.
- 공개키
  - 서버와 클라이언트가 가지고 있는 키가 다른 방식입니다.
  - 서버는 서버만 가지고 외부로 노출되지 않는 개인키를 가지고 있고 개인키와 매칭되어 암호/복호화가 가능한 공개키는 여러 클라이언트에게 공개하는 방식입니다.
  - 클라이언트는 서버와 매칭이 되는 개인키를 가지고 있어야만 원활환 통신이 가능합니다.
  - 만약 제 3자가 같은 공개키로 데이터를 복호화해 탈취하려 해도 공개키로 암호화된 데이터는 개인키로만 복호화가 가능해 대칭키에 비해 데이터 보안이 강해집니다.

왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?

일반적인 HTTP 방식으로 통신할 경우, 클라이언트와 서버가 주고 받은 요청 정보를 제 3자가 확인할 수 있으므로 SSL 인증 절차를 추가해 서버와 클라이언트만이 알고 있는 대칭키를 사용하는 것을 HTTPS 방식이라고 합니다.
HTTPS의 통신 방식은 다음과 같습니다.
- 클라이언트가 서버에게 임의의 데이터1을 전송합니다.
- 서버가 클라이언트에게 임의의 데이터2를 보내면서 인증서를 함께 보냅니다.
- 클라이언트는 인증서를 여러 CA들의 공개키 리스트 중 매칭되는 공개키로 복호화를 합니다. 복호화한 인증서 내에는 서버의 개인키와 매핑되는 공개키가 포함되어 있습니다.
- 클라이언트는 핸드 쉐이크 과정에서 주고 받은 두 임의 데이터를 가지고 대칭키를 생성하고 서버의 공개키로 암호화해 서버로 전달합니다.
- 서버는 개인키로 복호화해 대칭키를 가지게 됩니다.
- 이렇게 서버와 클라이언트는 개인키 방식으로 대칭키를 주고 받게 되고, 이후로는 대칭키로 리소스의 사용을 줄여 통신을 하게 됩니다.
즉, HTTPS에서 인증서를 사용하는 것은 CA를 통해 클라이언트가 요청을 보낸 서버가 올바른지 판단하기 위해서 입니다.
CA에서 제공하는 인증서는 CA의 개인키로 암호화되었고 이를 서버에만 제공합니다.
그렇기에 서버가 제공한 인증서를 클라이언트가 올바른 CA의 개인키와 매핑되는 공개키로 복호화해야만 정상적으로 인증서 내부에 있는 서버 공개키를 확인할 수 있으므로 서버에 대한 인증을 해주는 것입니다.

SSL과 TLS의 차이는 무엇인가요?

SSL과 TLS 모두 서버, 애플리케이션, 사용자 및 시스템 간의 데이터를 암호화하는 통신 프로토콜이며 네트워크를 통해 연결된 두 당사자를 인증하므로 데이터를 안전하게 교환할 수 있습니다.
쉽게 생각해서 SSL은 TLS의 전신이며 SSL의 문제를 보안하기 위해 나온 것이 TLS입니다. 현재는 SSL 방식이라고 하더라도 TLS 방식을 제공합니다.
구체적인 두 인증 방식의 차이점은 다음과 같습니다.
- SSL/TLS 핸드셰이크
  - SSL 핸드셰이크는 명시적 연결인 반면 TLS 핸드셰이크는 암시적 연결입니다. SSL 핸드셰이크 프로세스는 TLS 프로세스보다 단계가 더 많았습니다. TLS는 추가 단계를 제거하고 총 암호 그룹 수를 줄여서 프로세스 속도를 높였습니다.
- 알림 메시지
  - SSL에는 경고와 치명적이라는 두 가지 알림 메시지 유형만 있습니다.
    - 경고 알림은 오류가 발생했지만 연결을 계속할 수 있음을 나타냅니다.
    - 치명적 알림은 연결을 즉시 종료해야 함을 나타냅니다.
  - 또한 SSL 알림 메시지는 암호화되지 않습니다.
  - TLS에는 닫기 알림이라는 추가 알림 메시지 유형이 있습니다.
    - 닫기 알림은 세션 종료를 알립니다.
  - 또한 TLS 알림은 추가 보안을 위해 암호화됩니다.
- 메시지 인증
  - SSL과 TLS 모두 메시지의 진본성과 무결성을 확인하기 위한 암호화 기술인 메시지 인증 코드(MAC)를 사용합니다.
  - SSL 프로토콜은 MAC 생성에 MD5 알고리즘(현재는 구식)을 사용합니다. TLS는 더 복잡한 암호화와 보안에 해시 기반 메시지 인증 코드(HMAC)를 사용합니다.
- 암호 그룹
  - 암호 그룹은 브라우저와 서버 간의 정보를 암호화하기 위한 키를 생성하는 알고리즘 모음입니다.
  - 일반적으로 암호 그룹에는 키 교환 알고리즘, 검증 알고리즘, 대량 암호화 알고리즘 및 MAC 알고리즘이 포함됩니다.
  - 보안 문제로 인해 TLS의 여러 알고리즘이 SSL에서 업그레이드되었습니다.

5. 웹소켓과 소켓 통신의 차이에 대해 설명해 주세요.

소켓이란 보통 TCP 위에서 프로그램이 네트워크 상에서 데이터를 송신과 수신을 하기 위한 연결부입니다.
소켓은 통신 연결을 받아드리는 서버 소켓과 통신 연결 요청을 보내는 클라이언트 소켓으로 나뉩니다.
하지만 소켓의 한계라면 stateless한 성격을 가진다는 것입니다.
즉, 연결 후 통신이 끝나면 소켓은 종료하고 서버와 클라이언트의 연결을 끝냅니다.
이러한 stateless를 stateful하게 유지하기 위해 생겨난 것이 웹소켓입니다.
웹소켓으로 클라이언트와 서버를 연결하면 통신상태를 유지한 상태로 간단한 메세지를 실시간으로 주고받을 수 있게 됩니다.
이러한 웹소켓은 실시간 채팅, 게임 등과 같은 곳에서 사용할 수 있으며 알맞은 상황에 따라 효율적인 데이터 통신이 가능합니다.

소켓과 포트의 차이가 무엇인가요?

소켓은 네트워에서 두 디바이스 간의 데이터 통신을 위한 종착점이자 엔드포인트입니다.
클라이언트-서버 구조에서 소켓은 클라이언트가 서버에게 요청을 전달하기 위한 톨게이트 역할을 한다고 이해할 수 있습니다.
보통 TCP/IP를 사용하여 통신을 진행합니다.
소켓이 디바이스와 디바이스의 연결을 위한 역할을 한다면 포트는 디바이스 내에서 프로세스, 프로그램을 구분하기 위한 식별값이라고 할 수 있습니다.
예로 들면 소켓은 아파트 주소, 포트는 아파트 내에 호수와 같은 관계를 가진다고 할 수 있습니다.

여러 소켓이 있다고 할 때, 그 소켓의 포트 번호는 모두 다른가요?

포트 번호가 같을 수 있고 다를 수 있습니다.
포트 번호가 다르다면 충돌이나 중복 요쳥과 같은 문제가 발생하지 않겠지만 포트번호가 같다면 IP 주소가 달라야만 구분이 됩니다

6. HTTP/1.1과 HTTP/2의 차이점은 무엇인가요?

1.1의 경우 가지는 특징과 단점은 다음과 같습니다.
- 기본적으로 Connection 하나당 하나의 요청만 처리 할 수 있습니다. 이로 인해 특정 요청이 지연될 경우, 이후 처리할 요청의 대기시간도 함께 길어지는 문제가 발생할 수 있습니다.(HOL Blocking)
- Pipelining이라는 기법을 통해 하나의 커넥션에서 다수의 요청을 담아가 처리하도록 하는 방법도 있지만 이도 결국 처리 순서를 보장하는 과정에서 HOL Blocking이 발생하게 됩니다.
- 요청을 보낼 때마다 TCP에선 연결에 대한 신뢰성을 보장하기 위해 3-way-handshake 과정을 반복적으로 실행합니다. 이는 RTT(Round Trip Time)을 증가 시킵니다.
- Header에 내용이 많습니다. 이는 매 요청마다 많은 양의 데이터가 포함되고 오히려 전송하려는 값보다 헤더가 큰 경우도 있게 됩니다.
이를 1.1의 기능적 단점을 보완하고 대처하기 위해 발전한 형태가 HTTP 2라고 볼 수 있습니다.
- Multiplexed Streams : Stream이라는 두 객체 간 양방향 흐름 안에서 다중 요청을 처리할 수 있고 응답 순서는 정해지지 않은 형태로 받을 수 있습니다.
- Stream Priritization : 리소스 간의 우선 순위를 지정해 순서를 결정할 수도 있습니다.
- Header Compression : 중복되는 헤더 내용은 테이블에서 별도로 관리해 포함시키지 않고 중복되지 않은 헤더 정보는 별도의 인코딩 과정(Huffman Encoding)을 거쳐 전송합니다.
- Server Push : HTML 문서에 포함되는 리소스를 클라이언트가 요청해야만 전달해주는 것이 아니라 서버에서 알아서 push해주는 방식이 가능합니다.

HOL(Head Of Line) Blocking 에 대해 설명해 주세요.

1.1에서는 응답 순서를 보장하는데 먼저 처리되어야 하는 요청이 처리 시간이 길어질 경우 다른 남은 요청들의 대기 시간이 길어져 성능에 직접적인 영향을 주는 것이 HOL Blocking이라고 합니다.

HTTP/3.0의 주요 특징에 대해 설명해 주세요.

새로운 전송 프로토콜인 QUIC 위에서 동작합니다. QUIC는 Quick UDP Internet Connection의 약자로 UDP를 사용하는 프로토콜입니다.
- UDP는 TCP와 다르게 데이터 전송에 대한 신뢰성을 보장을 하지 않고 전송 순서 또한 지켜지지 않을 수 있습니다.
- 이로 인해 handShake 같은 절차가 없어 신뢰성은 낮지만 빠른 전송 속도를 가져갈 수 있습니다.
- 기존 TCP 방식은 이미 복잡한 구조로 구현되어 있어 이 구조 내에서 성능상 이점을 가져오기 위한 커스텀이 불가능에 가깝다고 볼 수 있습니다.
- 반대로 UDP의 경우는 빠른 데이터 전송에만 목적을 두고 있어 단순한 구조와 형태를 가지고 있습니다.
- 그래서 빠른 전송 속도를 유지하면서 신뢰성에 대해 필요한 기능을 커스텀하기 용이하다는 것이 3.0을 사용하는 주 목적이라고 할 수 있습니다.
3.0의 특징은 다음과 같습니다.
- 전송 속도 향상을 위해 첫 연결 설정에서 필요 데이터를 함께 전송하고 연결이 성공하면 연결 정보를 캐싱해 다음 연결 시에 별도의 확인 절차 없이 전송을 실행합니다.
  - Connection UUID를 서버와 매핑하고 이를 클라이언트가 가지고 있어 UUID를 통해 빠른 서버 연결이 가능합니다.
- TLS 기본 적용해 데이터 보안성을 향상시켰습니다.
- 하나의 스트림에 여러 데이터가 포함되는 것이 아니라 독립 스트림으로 구성함으로써 데이터 전송 지연 문제를 해결하고 향상된 멀티플렉싱 기능을 제공합니다.

[CS 스터디] 네트워크 1

1. 쿠키와 세션의 차이에 대해 설명해 주세요.

세션 방식의 로그인 과정에 대해 설명해 주세요.

HTTP의 특성인 Stateless에 대해 설명해 주세요.

Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

2. HTTP 응답코드에 대해 설명해 주세요.

401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?

200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.

(추가 질문) HTTP/1.1과 HTTP/2.0의 응답 코드는 다른가요?

3. HTTP Method 에 대해 설명해 주세요.

HTTP Method의 멱등성에 대해 설명해 주세요.

GET과 POST의 차이는 무엇인가요?

POST와 PUT, PATCH의 차이는 무엇인가요?

HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?

(추가질문) POST로 처리할 수 있음에도 GET을 사용하는 이유는 무엇일까요?

(추가질문) PRG 패턴에 대해서 설명해주세요.

4. HTTP에 대해 설명해 주세요.

공개키와 대칭키에 대해 설명해 주세요.

왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?

SSL과 TLS의 차이는 무엇인가요?

5. 웹소켓과 소켓 통신의 차이에 대해 설명해 주세요.

소켓과 포트의 차이가 무엇인가요?

여러 소켓이 있다고 할 때, 그 소켓의 포트 번호는 모두 다른가요?

6. HTTP/1.1과 HTTP/2의 차이점은 무엇인가요?

HOL(Head Of Line) Blocking 에 대해 설명해 주세요.

HTTP/3.0의 주요 특징에 대해 설명해 주세요.

Further Reading

[CS 스터디] 데이터베이스 1

CS 기초

[CS 스터디] 데이터베이스 2