[Network] 면접 예상 질문(2)
HTTP 1.1 의 keep alive 기능에 대해 간략히 설명해주세요.
HTTP 기본 구조는 1회성 request와 이에 대한 response로 이루어집니다.
따라서, 매번 HTTP request 및 response로 인한 종료시마다,
TCP 프로토콜 단계에서 3-way-handshake 및 4-way-handshake 과정이 필요합니다.
keep alive 기능은 이러한 불필요한 연결과 연결종료 과정을 줄이기 위해,
설정한 keep alive timeout 기간에는 동일한 source 에서 이루어지는
HTTP request 에 대해서 연결을 유지하는 기능입니다.
따라서, keep alive timeout 기간 동안에는 TCP 프로토콜 단계에서,
3-way, 4-way handshake 를 수행할 필요가 없으므로, 성능 개선이 가능합니다.
HTTP와 HTTPS의 차이점에 대해 간략히 설명해주세요
HTTP 프로토콜은 인터넷상에서 정보를 주고받는 프로토콜 입니다.
HTTP 프로토콜이 데이터를 암호화하지 않은 일반 텍스트로 송수신하기 때문에 보안에 취약합니다.
이를 보완한 프로토콜이 HTTPS 프로토콜이며,
HTTPS는 HTTP 프로토콜로 송수신하는 일반 텍스트를
SSL 또는 TLS 프로토콜을 통해 암호화하여 송수신합니다.
(HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로챌 수 있고, 수정할 수 있습니다.
따라서 보안이 취약해짐을 알 수 있습니다. 이를 보완하기 위해 나온 것이 HTTPS입니다.
중간에 암호화 계층을 거쳐서 패킷을 암호화합니다.)
HTTPS에 대해서 설명하고 SSL Handshake에 대해서 설명해보세요.
HTTPS는 HTTP에 보안 계층을 추가한 것입니다.
HTTPS는 제 3자 인증, 공개키 암호화, 비밀키 암호화를 사용합니다.
제3자 인증은 믿을 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이고,
공개키 암호화는 비밀키를 공유하기 위해 사용합니다.
비밀키 암호화는 통신하는 데이터를 암호화하는데 사용합니다.
클라이언트는 TCP 3 way handshake를 수행한 이후 Client Hello를 전송합니다.
서버는 클라이언트 요청에 대한 응답으로 Server Hello를 전송합니다.
서버는 자신의 디지털 인증서를 클라이언트에게 보냅니다.
클라이언트는 받은 인증서를 신뢰하기 위해서 등록된 인증 기관인지 확인합니다.
이 인증서는 인증기관의 개인키로 암호화되어있고, 브라우저에 내장되어 있는 공개키로 검증할 수 있습니다.
클라이언트는 사이트의 정보와, 서버의 공개키를 얻을 수 있습니다.
서버의 공개키로 통신에 사용할 비밀키를 암호화해서 서버에 보냅니다.
서버는 이를 개인키로 확인하고 이후 통신은 공유된 비밀키로 암호화되어 통신합니다.
제3자 인증: 인증서, 인증기관 / 공개키 암호화: 인증서, 비밀키 공유 / 비밀키 암호화: 통신과정
왜 공개키 암호화와 비밀키 암호화를 복합적으로 사용했는지도 질문을 받았습니다.
쿠키와 세션의 차이점에 대해 간략히 설명해주세요.
HTTP 프로토콜이 connectionless, stateless한 특성을 가지고 있기 때문에
상태 정보 유지를 위해 쿠키와 세션을 사용합니다.
쿠키와 세션의 가장 큰 차이점은 상태 정보 저장 위치로,
쿠키는 상태정보를 사용자 브라우저에 저장하지만, 세션은 서버에 저장합니다
HTTP GET, POST 방식에 대해 간략히 설명해주세요.
HTTP GET 방식은 일반적으로 서버에서 정보를 조회할 때,
HTTP POST 방식은 서버에 정보를 입력 또는 추가할 때 사용합니다.
HTTP GET 방식은 요청에 필요한 데이터를 URL에 붙여서 전송합니다.
이에 반해 HTTP POST 방식은 요청에 필요한 데이터를 HTTP request의 body부분에 담아 전송합니다
GET과 POST의 차이점에 대해서 설명해보세요.
GET 요청은 서버에 존재하는 정보를 요청합니다.
이때 반환되는 정보는 정보 자체가 아니라 정보의 표현입니다.
(뒤의 내용은 REST와 연관이 있고, 굳이 답변하지 않으셔도 됩니다.)
일반적으로 Request Body는 입력하지 않는 것이 일반적이며,
레거시 시스템의 경우 요청을 받아들이지 않을 수 있습니다.
캐싱을 수행하기 때문에 캐싱되지 않는 요청은 GET 요청이 맞지 않을 수 있습니다.
POST 요청은 서버에 정보를 생성하는 것을 요청합니다.
예전 HTTP 통신은 POST 요청으로 데이터 삭제, 수정도 form 요청으로 같이 수행했습니다.
POST 요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않습니다.
보통 Request Body에 요청하는 데이터를 담아 전송합니다.
HTTP 메서드와 이것이 하는 역할에 대해서 설명해보세요.
OPTIONS, HEAD, TRACE의 존재에 대해서는 알아만 둡시다. 특히 TRACE는 몰라도 되는 것 같습니다. OPTIONS는 해당 uri에 대해 서버가 허용하는 메서드를 확인할 때 사용합니다. HEAD는 GET과 비슷하나 header만 가져옵니다.
GET 요청은 서버에 존재하는 데이터를 요청하는 것입니다. CRUD로 따지면 R입니다.
POST 요청은 서버에 데이터를 생성하는 것을 요청합니다. CRUD로 따지면 C입니다.
PUT 요청은 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성합니다. CRUD로 따지면 C,U입니다.
DELETE 요청은 서버에 데이터를 제거할 것을 요청합니다. 존재하지 않아도 동일하게 동작합니다. CRUD로 따지면 D입니다.
PATCH 요청은 서버에 존재하는 데이터를 일부 수정합니다. CRUD로 따지면 U입니다.
(HEAD는 GET과 비슷하지만, 실제 데이터 본문을 포함하지 않고 헤더 정보만 요청합니다. 주로 리소스의 메타 정보를 확인할 때 사용됩니다.
OPTIONS는 서버에 해당 리소스(uri)에 대한 어떤 메서드가 지원(허용)되는지 문의합니다. 주로 CORS와 관련하여 사용됩니다.
CONNECT는 웹 소켓을 열 때 사용됩니다. (+ 서버에 프록시 기능을 요청할 때 사용)
TRACE는 클라이언트와 서버 간의 통신 경로를 따라가는 데 사용됩니다. 주로 디버깅 용도로 사용됩니다.)
더 나아가서 불필요한 메서드는 허용하지 않고 "필요한 메서드만 허용"하는 Whitelist 방식으로 관리합시다.
자세한 내용은 HTTP Method 취약점에 대해 검색합시다.
RESTful이란 무엇이며, 이것에 대해서 아는대로 설명해보세요.
HTTP URI를 통해 자원을 표시하고 HTTP Method를 통해 자원에 대한 처리를 표현합니다.
HTTP를 사용하기 때문에 HTTP의 특성을 그대로 반영합니다.
사람이 읽을 수 있는 API라는 것이 특징입니다.
단점으로는 명확한 표준이 존재하지 않는다는 점,
RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭다는 점(그런 REST API로 괜찮은가 참고)이 있습니다.
HATEOAS라는 개념이 있는데, 동적인 API를 제공할 수 있게됩니다.(모든 관련된 동작을 URI를 통해 알려줍니다.)
즉, 클라이언트가 API의 변화에 일일이 대응하지 않아도 된다는 장점을 가져옵니다.
CORS란 무엇이며 이것에 대해서 설명해보세요.
(CORS는 웹개발을 하다가 흔히 만날 수 있는 이슈입니다.
대개는 프론트엔드 개발시에 로컬에서 API 서버에 요청을 보낼 때 흔하게 발생합니다.)
CORS는 도메인, 포트, 프로토콜이 모두 동일한 경우에만
기본적으로 Same-Origin Policy에 따라 보안 정책을 운영하는데,
이 정책을 위반하는 경우 브라우저에서 CORS 오류가 발생합니다.
대부분의 브라우저에서는 이를 기본적으로 차단하며,
서버 측에서 헤더를 통해서 사용가능한 자원을 알려줍니다.
preflight request는 실제 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청입니다.
OPTIONS 메서드로 요청하며 CORS를 허용하는지 확인합니다.
CORS가 허용된 웹 서버라면 사용 가능한 리소스를 헤더에 담아 응답합니다.
웹 브라우저를 실행시켜서 주소창에 특정 URL 값을 입력시킨 후, 엔터를 눌렀을 때, 페이지가 렌더링되는 과정을 웹통신 흐름에 중점을 두어 가능한 구체적으로 설명해주세요
우선 네트워크 상으로는 DNS 프로토콜을 사용해서 주소 창에 넣은 URL의 IP 주소를 알아냅니다.
그리고 해당 IP 주소로 HTTP request를 송신합니다.
이를 통해 서버로부터 HTTP response를 받게되며, 통상 HTTP respose는 HTML 파일이 됩니다.
브라우저는 해당 파일을 화면에 표시해주기 위해, DOM tree, CSSOM(씨에스에스 오브젝트 모델) tree 생성하고,
이를 기반으로 render tree를 생성한 후, 렌더링을 수행합니다.
웹 통신의 큰 흐름: https://www.google.com/ 을 접속할 때 일어나는 일
면접 단골 문제입니다. 면접관 입장에서는 한 질문으로 많은 답변을 들을 수 있기 때문에 대부분의 면접자리에서 나왔던 문제입니다. OSI 7계층과도 연관지어 설명하라는 질문을 받은적도 있습니다.
브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고, OS에 전송 요청을 합니다.
이때, Domain으로 요청을 보낼 수 없기 때문에 DNS Lookup을 수행합니다.
DNS 룩업 과정은 크롬의 경우 브라우저 → hosts 파일 → DNS Cache의 순서로 도메인에 매칭되는 ip를 찾습니다.
일반적으로 설명하는 DNS Lookup은 루트 도메인서버에서부터 서브도메인 서버 순으로 찾게됩니다.
이 요청은 프로토콜 스택이라는 OS에 내장된 네트워크 제어용 소프트웨어에 의해 패킷에 담기고
패킷에 제어정보를 덧붙여 LAN 어댑터에 전송하고, LAN 어댑터는 이를 전기신호로 변환시켜 송출합니다.
패킷은 스위칭, 허브 등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동합니다.
액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달됩니다.
고속 라우터들 사이로 목적지까지 패킷이 흘러들어가게 됩니다.
핵심부를 통과한 패킷은 목적지의 LAN에 도착하고,
방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사합니다.
웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘깁니다.
애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송하고, 이는 전달된 방식 그대로 전송됩니다.
웹 서버 소프트웨어(Apache, Nginx)는 OSI 7계층 중 어디서 작동하는지 설명해보세요.
Apache와 NGINX는 HTTP 웹 서버로, 이들이 동작하는 HTTP 프로토콜은 OSI 7 Layer 중 7계층인 애플리케이션 Layer에 해당하는 프로토콜입니다. HTTP 프로토콜은 TCP/IP 프로토콜을 통해 동작합니다. TCP/IP 프로토콜은 OSI 7 Layer 중 4계층인 Transport Layer에서 동작합니다. 따라서 웹 서버 소프트웨어는 4계층의 TCP/IP 프로토콜과 7계층의 HTTP 프로토콜을 활용하여 동작합니다.
웹 서버 소프트웨어(Apache, Nginx)의 서버 간 라우팅 기능은 OSI 7계층 중 어디서 작동하는지 설명해보세요.
두 가지가 있습니다. Layer 4 (Transport Layer), 그리고 Layer 7 (Application Layer) 입니다. L4 에서는 TCP/UDP 포트 정보를 토대로 라우팅 기능이 제공됩니다. L7에서는 TCP/UDP 뿐만 아니라 HTTP의 URI 등을 토대로 라우팅 기능이 제공 됩니다. L4 에서 라우팅 기능을 사용 한 예시를 들자면, Nginx 의 경우 여러 포트들을 하나의 upstream 블록으로 묶어서 로드 밸런싱, 즉 특정 경로로 전달되는 요청을 각 포트 별로 분산해서 전달하도록 설정 해 줄 수 있습니다. L7 에서 라우팅 기능을 사용 한 예시를 들자면, Apache, Nginx 각각에서 서브 도메인에 대해 라우팅 설정을 해 둘 수 있습니다. 브라우저에서 /test 와 같은 서브 도메인으로 HTTP 프로토콜을 통한 요청을 보낸다면, 웹서버 내 Config 파일에 설정 된 경로 정보를 토대로 요청에 대한 라우팅을 제공하여 스태틱 파일을 전달하거나 API 서버에 대해 리버스 프록시 역할을 해 줄 수 있습니다.