네트워크 면접 질문 정리

보기좋게 수정 할 예정~

• 웹 통신의 큰 흐름: https://www.google.com/ 을 접속할 때 일어나는 일
  https://www.youtube.com/watch?v=5MM8NDzWHdE
  1. www.google.com을 브라우저 주소창에 입력한다.
  해당 URL 일부를 분류해보면 제일 앞에 https룰 볼 수 있습니다. https는 통신 규약입니다. 다음 www.google.com은 사이트의 도메인 이름입니다. 기억하기 쉬운 주소이며 특정 서버의 IP 주소를 가리킵니다. ip 주소를 찾기위해
  2. 브라우저는 캐싱된 DNS 기록을 통해 www.google.com에 대응되는 IP 주소가 있는지 확인한다.
  DNS는 빠르게 수행되어야하기 때문에 다양한 위치에 데이터가 임시저장되어 있고 이를 캐시라고 부릅니다. 차례대로
  - 브라우저 캐시 확인
  - OS 캐시 확인
  - 라우터의 로컬 네트워크 캐시
  - 회사 네트워크 또는 인터넷 서비스 제공업체(ISP)의 DNS 서버 캐시
  를 확인합니다.
  3. 만약 요청한 URL이 캐시에 없으면 ISP(인터넷 서비스 제공자, kt 등)의 DNS 서버가 www.google.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위해 재귀적 DNS 조회를 수행합니다.
  4. 브라우저가 IP주소를 받아 웹 서버와 TCP 3way핸드쉐이킹을 통해 연결을 설정하고, HTTPS를 사용하기때문에 주고 받는 데이터의 암호화를 위한 TLS (Transport Layer Security) 핸드셰이크라는 추가 과정을 수행합니다.
  5. TCP 연결이 완료되면 브라우저가 웹 서버에 HTTP 요청을 보낸다.
  웹 브라우저가 페이지의 콘텐츠를 요청하기 위해 서버에 HTTP 요청을 전송하는데 HTTP 요청에는 HTTP 메서드, 경로, HTTP버전, 헤더(또는 요청에 대한 메타데이터) 및 본문이 포함됩니다.
  6. 웹 서버는 요청을 받으면 응답을 생성하여 클라이언트로 다시 전송합니다. 응답에는 상태코드와 헤더 요청한 리소스가 포함됩니다.
  7. 웹 브라우저가 서버로부터 응답을 받으면 전송 받은 콘텐츠를 렌더링합니다.
• TCP와 UDP의 차이점에 대해서 설명해보세요. TCP는 연결 지향형 프로토콜이고 UDP는 비연결형 프로토콜입니다. TCP는 가상 회선을 만들어 신뢰성을 보장하도록(흐름 제어, 혼잡 제어, 오류 제어) 하는 프로토콜로 따로 신뢰성을 보장하기 위한 절차가 없는 UDP에 비해 속도가 느린편입니다. TCP는 그래서 파일전송과 같은 신뢰성이 중요한 서비스에 사용되고, UDP는 스트리밍 같이 연속성이 더 중요한 서비스에 사용됩니다. +) 꼬리질문 udp에도 신뢰성을 보장할 수 있나요>? UDP도 신뢰성을 UDP자체에서 보장하지 않는 것 뿐이지, 개발자가 직접 신뢰성을 보장하도록 할 수 있습니다. 그래서 HTTP/3은 QUIC이라는 프로토콜을 기반으로 하는데, QUIC은 UDP를 기반으로 합니다. 즉, UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통해 신뢰성을 보장받을 수 있습니다.
  
• TCP 3, 4 way handshake에 대해서 설명해보세요. TCP 3way handshake는 연결을 수립하는 과정입니다. SYN, ACK 패킷을 주고받으며, 클라이언트가 임의의 난수로 SYN 플래그를 서버에 전송하고, 서버는 요청을 수락했다는 표시로 받은 임의의 난수에 1을 더한값을 ACK로 그리고 클라이언트도 연결을 받아달라 SYN 메시지를 전송합니다. 마지막으로 클라이언트가 수락 확인 ACK를 보내며 연결을 맺습니다. 왜 임의의 난수를 지정하느냐는 꼬리질문이 나올 수 있습니다. 기존 요청과 구분하기 위해서 정도로 알고있고, 그 이상은 생각해본적이 없네요. 4way handshake는 TCP 연결을 해제하는 과정우로, 클라이언트가 연결을 종료하겠다는 FIN 플래그를 서버로 전송하면 서버는 확인 메시지를 보내고 자신의 통신이 끝날때까지 기다립니다. 통신이 끝나면 연결 종료해도 괜찮다는 의미로 FIN을 클라이언트로 전송하고 클라이언트는 time wait상태를 거치고 FIN 메시지를 받았다는 ACK를 전송해 연결을 해제한다.
  • 꼬리 질문 - TCP의 연결 과정에서 3way와 4way가 단계 차이가 나는 이유
    Client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 ACK만 먼저 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메시지를 보내기 때문이다.
  • Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도작한 상황이 발생하면?
    이러한 현상을 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정기간 time wait동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다.
  • 초기 Sequence Number인 ISM을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유
    커넥션을 맺을 때 사용하는 포트는 시간이 지남에 따라 재사용된다.
    따라서 두 통신이 과거에 사용된 포트 번호 쌍을 사용할 가능성이 생기고 난수가 아닌 순차적 Number가 전송된다면 이전의 커넥션으로부터 오는 패킷으로 인식할 가능성이 생긴다.
• HTTP와 HTTPS의 차이점에 대해서 설명해보세요. HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로챌 수 있고, 수정할 수 있습니다. 따라서 보안이 취약해짐을 알 수 있습니다. 이를 보완하기 위해 나온 것이 HTTPS입니다. HTTP 자체를 암호화하는 것이 아니라 운반하는 HTTP Body 부만 암호화를 진행하고 Header는 암호화하지 않는다.
  • HTTPS를 사용해야하는 이유!
  1. 보안성 2. SEO-검색엔진(구글 등)에서 가산점을 준다.
• HTTPS에 대해서 설명하고 SSL Handshake에 대해서 설명해보세요. HTTPS는 HTTP에 보안 계층을 추가한 것입니다. HTTPS는 제3자 인증, 공개키, 비밀키를 혼합해서 사용합니다. 제3자 인증은 믿을 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이고, 공개키 암호화는 비밀키를 공유하기 위해 사용합니다. 비밀키 암호화는 통신하는 데이터를 암호화하는데 사용합니다. 클라이언트는 TCP 3way handshake를 수행한 이후 Client Hello를 전송합니다. 서버는 인증서를 보냅니다. 클라이언트는 받은 인증서를 신뢰하기 위해서 등록된 인증기관인지 확인합니다. 이 인증서는 인증기관의 개인키로 암호화되어있고, 공개키로 검증할 수 있습니다. 클라이언트는 사이트의 정보와, 서버의 공개키를 얻을 수 있습니다. 서버의 공개키로 통신에 사용할 비밀키를 암호화해서 서버에 보냅니다. 서버는 이를 개인키로 확인하고 이후 통신은 공유된 비밀키로 암호화되어 통신합니다. https://steady-coding.tistory.com/512 제3자 인증: 인증서, 인증기관/공개키 암호화: 인증서, 비밀키 공유/비밀키 암호화: 통신과정
  • 꼬리 왜 공개키 암호화와 비밀키 암호화를 복합적으로 사용했나요?
    대칭키는 암호화 복호화 키가 똑같아 암호하는 연산이 간단하고 빠르지만 대칭키가 털리면 암호를 쉽게 노출되는 단점을 가진다.공개키는 암호화와 복호화 키가 달라 암호 연산이 느리지만 공개키를 뺏겨도 암호를 풀 수 없는 보안이 강하다는 장점을 가지고 있습니다.각 공개키와 대칭키의 장단점이 상반되기 때문에 SSL은 두가지를 혼용해서 사용합니다.
• HTTP 메서드와 이것이 하는 역할에 대해서 설명해보세요.
  • GET
    • 조회, 리소스 요청
  • POST
    • 요청된 데이터 처리
    • 자원을 생성
  • PUT
    • 요청된 자원이 없으면 생성
    • 요청된 자원을 새 것으로 전체 갱신
  • PATCH
    • 자원의 일부분만 수정
  • DELETE
    • 요청된 자원 삭제
• RESTful이란 무엇이며, 이것에 대해서 아는대로 설명해보세요.(보충필요) RESTful은 REST 원리를 따르는 시스템입니다. REST는 HTTP URI를 통해 자원을 표시하고 HTTP Method를 통해 자원에 대한 처리를 표현합니다. HTTP를 사용하기 때문에 HTTP의 이점을 그대로 가져올 수 있다. 또한 별도의 인프라 구축이 필요없습니다. 단점으로는 명확한 표준이 존재하지 않아 RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭습니다. HATEOAS라는 개념이 있는데, 동적인 API를 제공할 수 있게됩니다.
  모든 관련된 동작을 URI를 통해 알려주어, 클라이언트가 API의 변화에 일일이 대응하지 않아도 된다는 장점이 있다.
  
• CORS란 무엇이며 이것에 대해서 설명해보세요. 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다. 브라우저는 보안상의 이유로, 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다. 따라서 다른 출처의 리소스를 불러오기 위해서는, 그 출처에서 교차 출처 리소스 공유에 대한 헤더(CORS)를 응답 시 반환해주어야 한다. preflight request는 실제 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청입니다. HTTP의 OPTIONS 메서드로 요청하며 CORS를 허용하는지 확인합니다. CORS가 허용된 웹서버라면 사용 가능한 리소스를 헤더에 담아 응답합니다.
  
• OSI7계층과 그 존재 이유, TCP/IP 4계층에 대해 설명해보세요. OSI7계층은 네트워크 통신을 구성하는 요소들 7개의 계층으로 표준화 한 것입니다. 이렇게 표준화하는 것의 장점은 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제가 발생하면 해당 문제를 해결하기 용이해집니다. 실제로 우리가 대부분 사용하는 네트워크는 TCP/IP 4계층입니다. 통신에 실제로 사용되는 계층이고 OSI의 7계층과 비교했을때 물리, 데이터링크 계층이 링크계층으로 OSI 5 6 7 계층이 TCP/IP 애플리케이션에서 통합되어 표현합니다.
  
• HTTP 1.0과 HTTP 1.1의 차이
  • HTTP 1.0
    • 요청 컨텐츠마다 TCP 커넥션을 맺고 끊음을 반복한다.
    • 요청1 -> 응답1 -> 요청2 -> 응답2 순으로 순차적으로 진행된다. 즉, 응답을 받아야만 다음 작업을 한다.
  • HTTP 1.1
    • 매 요청마다 TCP 커넥션을 맺고 끊음을 반복하지 않고 keep-alive를 통해 일정 시간 동안 커넥션을 유지한다.
    • 클라이언트는 각 요청에 대한 응답을 기다리지 않고 여러개의 요청을 연속적으로 보낸다.(파이프라이닝) 하지만 각 응답의 처리는 순차적으로 처리된다.
• HTTP 2.0의 특징 HTTP2눈 HTTP 1.버전보다 지연시간을 줄이고 응답시간을 더 빠르게 할 수 있으며 멀티플렉싱, 헤더압축, 서버푸시 요청의 우선순위 처리를 지원하는 프로토콜입니다. 장점은 멀티플렉싱과 서버푸시입니다. 멀티 플렉싱이란 여러 개의 스트림을 사용하여 송수신한다는 것입니다. 이를 통해 특정 스트림은 멀쩡하게 동작할 수 있습니다. 서버 푸시란 http1.1애소는 클라이언트가 서버에 요청을 해야 파일을 다운받을 수 있습니다. http2는 클라이언트 요청없이 서버가 바로 리소스를 푸시하는것을 말합니다. html에는 css나 js파일이 포함되기 마련인데 html을 읽으면서 그 안에 들어있던 css 파일을 서버에서 푸시하여 클라이언트에 먼저 줄 수 있습니다.
  
• 쿠키와 세션과 토큰의 차이점 쿠키는 브라우저 스토리지의 개념입니다. 세션은 서버에 세션 저장소를 두고 세션 저장소에는 로그인 시 사용자 정보를 저장하고, key로 사용할 수 있는 세션 ID를 만듦. 세션 ID는 클라이언트에게 보내 브라우저에서 세션 ID를 쿠키에 저장함. 따로 저장소가 필요하고 세션 저장소를 중앙에서 관리하기 떄문에 서비스가 분리되어있을땐 쓰기 어렵다는 단점을 가지고 있습니다. 토큰은 제가 JWT를 사용했기때문에 JWT라고 하고 설명드리겠습니다. JWT (JSON Web Token) 는 인증에 필요한 정보들을 암호화시킨 토큰입니다. HTTP 헤더에 실어 서버에 전송합니다. 토큰안에 페이로드에 사용자의 정보를 담을 수 있습니다. 따로 저장소가 필요하지 않고 소셜로그인과 같은 확장성이 뛰어납니다.
  • 꼬리 확장성이 뛰어나다고 하셨는데 어떤 부분에서 확장이 가능한가요?
    OAuth - 자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜로 해당 프로토콜을 사용하면 소셜로그인을 구현할때 간편하게 구현할 수 있습니다.
• HTTP 멱등성이란 특정 HTTP 메서드를 여러 번 요청을 했을 경우, 매번 요청 결과가 같다면 해당 메소드를 멱등성 메소드라고 한다.GET, PUT, DELETE가 멱등성 메서드에 속하고 POST는 멱등성 메서드가 아니다.같은 POST를 연속적으로 보낸다면 명령은 여러 번 내린 것처럼 부가적인 결과를 가져오기 때문이다.
  
• 로드밸런서란? 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드밸런싱입니다. 클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 요청을 여러 서버에 분산시켜준다. 요청이 많아지면 서버를 추가 증설함으로 로드 밸런서를 관리해주면 서버 부하 해결이 가능하다. 꼬리질문 로드밸런싱을 해본 경험이 있나요? 네 있습니다. msa 환경에서 각 서비스에 들어오는 요청을 관리하기 위해 api gateway 서버를 로드밸런싱으로 사용하였습니다.