CS공부 - 네트워크 - 2

다음 글은 보초님의 CS 네트워크 레포를 기반으로 각 질문에 대한 답을 달며 공부하는 글입니다.

오류가 있다면 댓글을 통해 알려주세요! 언제나 환영입니다! :)

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

먼저, 쿠키와 세션은 HTTP 통신의 특징인 Connectionless와, Stateless 문제를 해결하기 위한 장치입니다. 웹 서비스를 이용하다보면 로그인과 각종 체크박스 등 상태를 저장해야 되는 경우가 생기게 되는데 이를 쿠키와 세션을 사용해 해결할 수 있습니다.
둘의 가장 큰 차이는 사용자의 정보를 저장하는 위치로, 쿠키는 브라우저 내의 저장소에 저장되고 세션은 서버에 저장되게 됩니다. 따라서 보안적인 측면에서 봤을 때, 쿠키는 request 작업을 수행하며 스니핑 될 우려가 있기 때문에 세션이 더 안전합니다. 반면 속도적인 측면에서 봤을 때는 쿠키는 쿠키 자체에 정보를 가지고 있고, 세션은 서버에 정보를 가지고 있기 때문에 쿠기가 더 빠르다는 특징이 있습니다.
만료 시점에 대한 차이도 있습니다. 세션도 결과적으로는 세션ID를 쿠키를 이용해 저장하게 되는데, 이때 쿠키를 설정하면서 expires(유효 일자)나 max-age(만료 기간)를 지정하지 않으면 세션 쿠키로 저장이 되고, 지정하면 지속 쿠키로 저장되게 됩니다. 세션 쿠키의 경우 브라우저가 종료되는 시점에서 삭제되며, 지속 쿠키는 브라우저를 닫더라도 지정된 만료 시점이 되기 전까지 유지된다는 차이가 있습니다.

• 세션 방식의 로그인 과정에 대해 설명해 주세요.
  • 클라이언트가 어떤 웹 사이트에 접속하게 되면 해당 사이트는 고유한 세션ID를 생성해 클라이언트에게 주게 됩니다. 이를 받은 클라이언트는 세션ID를 쿠키에 저장하게 되고, 이후 매 요청마다 해당 세션ID는 쿠키에 담겨 전송되게 됩니다. 서버는 세션ID를 보고 해당 클라이언트의 각종 상태를 알 수 있고, 로그인을 하게 된다면 해당 세션ID의 로그인 상태를 유효한 값으로 바꿔 저장하게 됩니다. 이후의 요청에서는 해당 세션ID를 가진 클라이언트의 로그인 상태가 유효하기 때문에 별도의 로그인없이 서비스를 이용할 수 있습니다.
• HTTP의 특성인 Stateless에 대해 설명해 주세요.
  • Stateless를 직역하면 무상태라는 것으로 서버가 클라이언트의 이전 상태를 기억하고 있지 않는다는 것입니다. 때문에 다음 요청을 받는 서버가 이전 요청을 받은 서버일 필요가 없어 서버의 스케일 아웃에 유연하다는 장점이 있지만, 그만큼 클라이언트가 많은 양의 데이터를 보내야 하는 단점이 있습니다.
• Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?
  • Stateless가 무상태를 의미하기 때문에 상태를 유지하는 세션 방식은 이에 반합니다. 하지만 현대의 웹 서비스들을 살펴보면 불가피하게 클라이언트의 상태를 유지해야 하는 경우가 많으며, 무상태를 지향하기 위해 매 요청마다 필요한 정보를 모두 담아 서버와 I/O하는 경우 통신에서 오는 부하와 코스트가 더 클 수 있기에 세션 방식을 사용하는 것 같습니다.
• 규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?
  • 스케일 아웃된 서버 모두가 세션 정보를 공유해야 되므로 Session만을 저장하는 Session Storage를 별도로 만들어 모든 서버에서 해당 Storage를 바라보게 하는 방법이 있습니다. 물론 Session Storage에서 오류가 나는 경우, 전체에 영향을 미친다는 단점이 있지만 이를 대비해 백업용 Session Storage를 준비해놓는다면 해결할 수 있을 것 같습니다.

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

HTTP 응답코드는 HTTP 요청에 대한 처리 결과를 나타내기 위한 코드로 크게 5가지로 분류됩니다. 1로 시작하는 100번 대부터 5로 시작하는 500번 대까지 있으며, 각각 정보, 성공, 리다이렉션, 클라이언트 오류, 서버 오류를 의미합니다. 각 분류 내에서는 좀 더 자세한 분류를 위해 401이나 403과 같이 숫자가 나뉘기도 합니다.

• 401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?
  • 401은 비인증, 403의 권한부족을 의미합니다. 둘 다 사용자측의 모종의 이유로 인한 비인증에 대한 응답이지만, 403은 401과 다르게 클라이언트가 누구인지 알고 있다는 차이가 있습니다. 예를 들어 인증이 안 된 상태의 클라이언트가 관리자 권한의 작업을 요청한다면 서버는 해당 사용자가 일반 사용자인지, 관리자인지 모르기 때문에 401을 통해 인증이 필요함을 표현해야 됩니다. 하지만 일반 사용자가 권리자 권한의 작업을 요청한다면 해당 사용자가 누군지는 알지만 해당 작업에 권한이 없음을 의미하는 403을 표현해야 합니다.
• 200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.
  • 둘 다 HTTP 요청에 대한 성공을 나타내는 응답이지만, 200은 데이터 요청에 성공해 요청한 데이터가 응답으로 반환되고, 201은 데이터 생성에 성공해 새로운 리소스가 생성되었음을 나타냅니다. 보통 POST나 PUT 요청에 대해 성공적으로 실행되면 201 응답을 사용합니다.

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

HTTP 메서드는 주어진 리소스에 수행하길 원하는 작업을 의미하며 데이터를 요구하는 GET, 추가하는 POST, 수정하는 PATCH, 삭제하는 DELETE 등의 메서드가 있습니다.

• HTTP Method의 멱등성에 대해 설명해 주세요.
  • 각 HTTP 요청에 대해서 처음 한 번 요청을 할 때나, 여러 번 요청할 때나 서버의 상태가 동일할 때 해당 HTTP 메서드가 멱등성을 가진다고 합니다. 이때 동일함을 따지기 위해서는 서버의 상태만을 보며 응답코드가 다르다고 멱등성이 없는 것은 아닙니다. 예를 들어 DELETE 메서드는 어떠한 리소스를 삭제했을 때 처음 요청에는 200의 잘 삭제되었음이 응답되지만, 또 요청하게 되면 404의 해당 데이터가 없다고 응답됩니다. 그럼에도 불구하고 첫요청이나 재요청 모두 DB의 상태는 동일할 것이므로 멱등성이 있다고 할 수 있습니다.
• GET과 POST의 차이는 무엇인가요?
  • 먼저 GET은 요청한 리소스를 얻기 위해 사용되며 POST는 리소스에 데이터를 추가하기 위해 사용됩니다. 때문에 가장 큰 차이는 데이터를 담아 보내는 body의 유무로 GET 요청은 body가 없지만 POST 요청은 body가 존재합니다. 또한 GET은 캐시가 되며 브라우저에 기록이 남지만, POST는 캐시가 되지 않고 기록 또한 남지 않습니다.
• POST와 PUT, PATCH의 차이는 무엇인가요?
  • POST 새로운 리소스를 생성하기 위해서 사용되는 메서드입니다. PUT는 해당 리소스가 없다면 생성하고, 있다면 수정하며, PATCH는 이미 있는 리소스를 수정합니다. POST는 멱동성이 없지만, PUT는 멱등성이 있습니다. PATCH는 구현 방법에 따라 멱등성이 있을수도, 없을수도 있습니다. PUT과 PATCH의 디테일한 차이는 PUT은 전달되지 않은 데이터에 대해서는 null로 수정하기 때문에 전체 컬럼에 대한 값을 수정할 때 사용되지만 PATCH는 전달된 데이터만 수정하기 때문에 부분 수정을 위해 사용됩니다.
• HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?
  • GET 요청은 브라우저에 캐시되며 기록이 남을 수 있습니다. 이에 민감한 정보를 GET의 body를 담아 요청하게 되면 보안상의 문제를 야기할 수 있기 때문에 지양하고 있습니다. 또한 아직 많은 개발자들이 가지고 있는 GET의 의미론적 역할에 대해 생각때문에 GET의 body를 지원하지 않는 클라이언트나 서버가 있을 수 있기 때문에 지양하고 있기도 합니다.

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

HTTP는 Hyper Text Transfer Procotol의 약자로 HTML과 같은 하이퍼텍스트 문서를 전송하기 위한 Application단의 프로토콜입니다. 생성 목적에 맞게 초기에는 HTML 문서만을 주고 받았지만 현재는 다양한 데이터를 주고 받는데 사용합니다. 클라이언트가 요청을 하기 위해 연결을 연 다음 응답을 받을때 까지 대기하는 전통적인 클라이언트-서버 모델을 따르며, Connectionless하고 Stateless하다는 특징이 있습니다.

• 공개키와 대칭키에 대해 설명해 주세요.
  • 둘 모두 암호화 기법 중 하나로 대칭키는 암호화와 복호화에 쓰이는 키가 같은 것을 의미합니다. 다만 이 방법은 암호문과 키를 전달하는 과정에서 키를 탈취당할 우려가 있기에 안전하지 않습니다. 이를 보완하기 위해 나온 공개키는 암호화에 쓰이는 키와 복호화에 쓰이는 키가 다른 비대칭키로, 두 개의 키 중 하나는 모두에게 공개되어 있는 공개키, 하나는 개인만이 알고 있는 개인키로 이루어져 있습니다. 따라서 상대방의 공개키를 통해 암호화한 암호문을 상대방에게 보내면 상대방은 개인키를 이용해 복호화할 수 있습니다.
• 왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?
  • 대칭키를 사용해 데이터를 암호화해 교환하게 되면 키를 중간에 탈취당해 보안상에 문제가 있을 수 있습니다. 이와 같은 키교환 문제를 해결하기 위해 HTTPS 통신은 인증서를 사용합니다.
• SSL과 TLS의 차이는 무엇인가요?
  • SSL은 Netscape가 개발한 암호화 프로토콜로 1996년 3.0 버전 이후로 업데이트가 되고 있지 않으며, 각종 보안 취약점이 발견되어 이를 업데이트한 최신 암호화 프로토콜을 TLS라고 합니다. 이름이 바뀐 이유는 SSL의 개발사 중 하나가 업데이트에 참여하지 않으면서 소유권을 가져오기 위해 바꿨습니다. 사실상 SSL의 업데이트 버전이라고 보면 되며 보안과 속도면에서 많이 개선되었습니다.

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

일반적으로 불리는 소켓은 프로그램이 네트워크 상에서 데이터를 주고 받을 수 있도록 사용하는 연결부라고 생각하면 됩니다. 여기서 HTTP 통신의 특징인 Connectionless으로 인해 실시간 통신이 안되는 불편함을 해결하고자 나온 것은 웹소켓으로 IP와 포트번호의 조합을 통해 주소를 특정하는 것이 소켓과 비슷하지만 일반 소켓은 OSI 7계층 중 4계층인 Transport layer에서 동작하는 것과 다르게, 웹 소켓은 7계층인 Apllication layer에서 동작합니다.

• 소켓과 포트의 차이가 무엇인가요?
  • 네트워크에 연결되어 IP가 할당된 통신이 가능한 단말을 호스트라고 부르는데, 호스트 내에는 여러가지 프로세스들이 동작하고 있을 수 있습니다. IP를 타고 호스트에게 도착한 데이터는 특정 프로세스에 도달해야 되는데, 이때 특정 프로세스를 식별하기 위해 호스트가 부여하는 고유한 숫자가 바로 포트입니다. 소켓은 어떠한 프로세스가 네트워크 상에서 데이터를 주고 받기 위해 열어두는 문같은 것으로 하나의 프로세스가 여러 개의 소켓을 가지고 있을 수 있습니다. 따라서 하나의 호스트 내에게서 포트는 고유하나, 같은 프로세스 내에서도 소켓은 고유하지 않을 수 있습니다.
• 여러 소켓이 있다고 할 때, 그 소켓의 포트 번호는 모두 다른가요?
  • 모두 다를 수도 있고, 포트 번호가 같은 소켓이 있을 수도 있습니다. 포트 번호는 하나의 호스트내에서 고유하지만, 하나의 프로세스는 여러 개의 소켓을 열 수 있으므로 같은 IP, 같은 포트수를 가지고 있다 하더라도 여러 개의 소켓이 존재할 수 있습니다.

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

HTTP/2의 핵심은 새롭게 추가된 바이너리 프레이밍 계층을 사용해 요청과 응답의 멀티플렉싱을 지원한다는 것입니다. 기존에 HTTP/1.1에서는 연속해서 보낸 요청에 대해서 앞의 요청이 처리 되지 않으면 뒤의 요청의 응답이 지연되는 HOL Blocking 문제가 있었습니다. 하지만 HTTP/2에서는 메시지를 바이너리 형태의 프레임으로 나누고 전송 후, 받은 쪽에서 다시 조립하는 형식을 사용해 HTTP 단의 HOL Blocking 문제를 해결했습니다. 또한 스트림의 우선 순위를 설정해 우선 순위가 더 높은 리소스를 먼저 응답할 수 있으며, HPACK 압축 형식을 사용해 요청과 응답에 쓰이는 헤더의 메타데이터를 압축해서 주고 받는다는 차이가 있습니다.

• HOL Blocking 에 대해 설명해 주세요.
  • HTTP/1.1 에서는 Pipelining을 이용해 하나의 요청에 대해 응답을 받고 다음 요청을 보내는 것이 아니라 연속으로 요청을 보내고 그 응답을 차례로 받을 수 있습니다. 하지만 첫 번째 요청에 대한 작업과 응답이 느려지게 되면 그 다음 요청들의 작업들이 완료되어도 지연되는 첫 번째 응답때문에 전체가 느려지게 되는데 이러한 현상을 HOL Blocking이라고 합니다. 물론 HTTP/2에서 이러한 HTTP 단의 HOL Blocking 문제를 해결했지만 결국 TCP 단에서 봤을때는 이는 모두 패킷으로 처리되기 때문에 패킷이 유실되어 발생하는 HOL Blocking 문제는 여전하고 최근에는 이를 해결하는 HTTP/3이 대두되고 있습니다.
• HTTP/3.0의 주요 특징에 대해 설명해 주세요.
  • 가장 큰 특징은 기존에 TCP 기반으로 사용되던 HTTP와 다르게 UDP 기반의 Quick UDP Internet Connection이라 불리는 QUIC 프로토콜을 사용하는 것입니다. 또한 선택적으로 사용했던 TLS를 HTTP/3에서는 필수적으로 사용해야 되며, 첫 연결에는 1RTT의 시간, 이후의 연결에는 이전의 연결에서 사용한 정보를 그대로 사용하기 때문에 0RTT가 필요한 굉장히 빠른 속도를 가지고 있습니다.

7. TCP와 UDP의 차이에 대해 설명해 주세요.

둘 다 OSI 7계층 중 4계층인 Transport layer에 속하는 프로토콜인데, TCP는 연결지향 프로토콜인 반면 UDP는 비연결지향 프로토콜입니다. 따라서 TCP는 연결을 위한 3-way handshaking 이라는 과정을 가지고 있는데, 연결 후 통신을 시작하기 때문에 흐름 제어와 혼잡 제어를 지원하며 가상 회선 방식을 이용해 데이터의 순서와 신뢰를 보장합니다. UDP는 TCP와 같은 연결 과정이 없으며 데이터그램 방식을 이용해 보내는 쪽에서 일방적으로 데이터를 전달합니다. 이때문에 TCP보다 전송 속도가 빠르다는 장점이 있지만 데이터에 대한 신뢰를 보장하지 않기 때문에 패킷 손실이 발생할 수 있다는 단점이 있습니다.

• 왜 HTTP는 TCP를 사용하나요?
  • HTTP는 웹상에서 웹상에서 여러 데이터를 주고받기 위해 사용됩니다. 즉, 사용자에게 제공되어야 할 리소스들을 받게 되는데 이러한 정보들은 유실되거나 손상되면 안됩니다. 때문에 가상 회선 방식으로 데이터를 보내 데이터의 순서를 보장하며, 손실된 패킷에 대해서는 재전송을 요청하는 신뢰도 있는 프로토콜인 TCP를 사용합니다.
• 그렇다면, 왜 HTTP/3 에서는 UDP(QUIC)를 사용하나요? 위에서 언급한 UDP의 문제가 해결되었나요?
  • UDP기반의 QUIC 프로토콜을 사용하는 HTTP/3이 이전의 HTTP와 다른 점은 TCP 기반의 HTTP들이 가지는 고질적인 문제인 속도와 HOL Bocking 문제를 해결했다는 것입니다. 위에서 언급한 문제에 대해서는 복수의 스트림을 사용하는 것으로 해결했습니다. 각 데이터에 대해 독립적인 스트림을 사용하기 때문에 어떠한 데이터를 나타내는 패킷이 손상되거나 유실됐다고 하더라도 해당 스트림에만 문제가 있는 것이지, 다른 데이터들의 전송 스트림은 정상적이기 때문에 안전하게 받아 사용할 수 있습니다.
• 본인이 새로운 통신 프로토콜을 TCP나 UDP를 사용해서 구현한다고 하면, 어떤 기준으로 프로토콜을 선택하시겠어요?
  • UDP를 사용하겠습니다. 기존에 TCP와 UDP는 간단하게 느리지만 신뢰성이 높은 프로토콜과 빠르지만 신뢰성이 낮은 프로토콜로 여겨져왔습니다. 하지만 UDP는 흔히 말하든 흰 도화지같은 프로토콜이기 때문에 개발자의 커스터마이징에 따라 TCP와 비슷한 성능을 낼 수도 있습니다. 개발을 진행할 때, 좋은 기능이 모두 들어간 무거운 라이브러리보다는 필요한 기능만 가지고 있는 가벼운 라이브러리를 선호하는 것과 같이 저 또한 UDP를 선택할 것 같습니다.
• Checksum이 무엇인가요?
  • 체크섬은 전송된 데이터에 대해서 오류가 있는지 확인하는 수단 중 하나입니다. IP헤더를 예로 들면 패킷을 수신 받은 측은 IP 헤더를 16비트로 모두 나눠 체크섬 값을 제외한 값을 모두 더합니다. 이때 캐리 값이 발생하면 가장 아래에 더하며 마지막에 1의 보수를 취해 주는데 이 값이 수신된 체크섬값과 일치한다면 정상, 아니라면 손실이 발생했다는 것을 짐작할 수 있습니다.
• TCP와 UDP 중 어느 프로토콜이 Checksum을 수행할까요?
  • 둘 다 체크섬을 수행할 수 있지만 TCP의 경우 필수적으로 요구되며, UDP는 선택적입니다.
• 그렇다면, Checksum을 통해 오류를 정정할 수 있나요?
  • 체크섬은 자체는 단순히 오류를 검출하는 역할을 수행합니다. 하지만 TCP에서는 체크섬을 통해 오류가 검출되는 경우 해당 패킷을 버림으로서 해당 패킷의 재전송을 요청할 수 있습니다.
• TCP가 신뢰성을 보장하는 방법에 대해 설명해 주세요.
  • TCP는 신뢰성을 보장하기 위해 각 데이터에 대해 확인이 되면 다음 데이터를 보내는 방식을 사용합니다. TCP는 데이터 패킷를 세그먼트라는 단위로 쪼개 전송하게 되는데 이 세그먼트들에게 시퀀스 넘버를 부여해 전송합니다. 수신측에서는 받은 세그먼트의 checksum을 계산해 손상되지 않은 데이터인지를 확인하며, 손상 유무에 따라 TCP Flag 응답을 다르게 해 손상된 데이터는 재전송을 요청합니다. 이후 쪼개져서 전달된 세그먼트들은 시퀀스 넘버에 의해 각 순서에 맞게 재조립되기 때문에 신뢰성을 보장할 수 있습니다.
• TCP의 혼잡 제어 처리 방법에 대해 설명해 주세요.
  • TCP에서는 데이터를 전송하는 윈도우의 크기를 조절함으로서 혼잡 제어를 합니다. 원론적인 방법으로는 윈도우의 크기를 1씩 증가시키다가 혼잡을 감지하면 그 절반으로 줄이는 작업을 반복하는 AIMD 기법과 윈도우의 크기를 두배씩 증가시키다가 혼잡을 감지하면 1로 줄이는 작업을 반복하는 Slow Start 기법이 있습니다. 물론 해당 방법을 그대로 쓰지는 않고 적절하게 조합해서 사용하는데, 대표적으로 Tahoe 방식과 Reno 방식이 있습니다. 이중 하나인 Reno 방식은 윈도우의 크기를 지수적으로 증가시키다가 일정수준이 되면 선형으로 증가시키는데, 이 일정수준을 임계점이라고 합니다. 이후, 3중복-ACK를 감지하게 되면 임계점과 윈도우의 수를 혼잡이 발생한 지점의 절반으로 재설정하고 윈도우의 크기를 선형으로 증가시킵니다. 만약 Time-out이 감지된다면 임계점은 그대로 유지하되, 윈도우의 크기를 1로 드롭시킨 후, 지수적 증가를 하며 혼잡 제어를 하는 기법입니다. 하지만 네트워크 대역폭이 커진 최근에는 Cubic, REC, Elastic TCP 등의 방법이 많이 사용된다고 합니다.

참고자료
쿠키(Cookie)와 세션(Session)의 차이 (+캐시(Cache))
쿠키와 document.cookie
다중 서버 환경에서의 세션 불일치 문제와 해결방법
HTTP 상태 코드 정리
HTTP
HTTP GET 메소드와 body
SSL이란?, SSL과 TLS 정의 및 차이
[소켓과 웹소켓] 한 번에 정리 (1) | 소켓이란?, 소켓 API의 실행 흐름, 클라이언트 소켓과 서버 소켓
HTTP/2 소개
TCP와 UDP의 특징 및 차이점 알아보기
🌐 HTTP 3.0 소개 & 통신 기술 알아보기
HTTP/3는 왜 UDP를 선택한 것일까?
사이 좋게 네트워크를 나눠 쓰는 방법, TCP의 혼잡 제어