https://github.com/JaeYeopHan/Interview_Question_for_Beginner 위 링크에 있는 문제에 대한 답안을 정리해보았다.

네트워크

GET, POST 방식의 차이점

  • GET
    • 데이터를 url의 쿼리스트링을 통해 전송
    • url이라는 공간에 담기 때문에 전송할 수 있는 데이터의 크기가 제한적
    • 데이터가 url에 노출되므로 보안이 필요한 데이터에는 적합하지 않음
    • Idempotent함. 서버에게 동일한 요청을 여러번 전송해도 동일한 응답이 나타나야 함.
    • 때문에 주로 조회를 할 때 사용
  • POST
    • HTTP Message의 Body에 담아 데이터를 전송
    • 보낼 수 있는 데이터의 크기가 크고 보안 면에서 GET보다 낫다
    • Non-idempotent. 서버에게 동일한 요청을 전송해도 결과값은 다를 수 있음.
    • 때문에 서버의 상태나 데이터를 변경할 때 사용.

OSI 7 계층

  • 1 : Physical Layer
    • 전기적, 기계적 특성을 통해 통신 케이블로 데이터를 전송
    • 이 단계에서 통신 단위는 bit. 1과 0으로 나타나는 전기적으로 on, off 상태
    • 데이터를 전달하기만 할 뿐 전송하려는 데이터가 무엇인지 신경쓰지 않음
    • 통신 케이블, 허브, 리피터
  • 2 : Data-Link Layer
    • 물리 계층에서 받은 정보의 전달을 수행
    • 물리 계층의 오류를 찾아내고 수정하는 기능 제공
    • 맥 주소를 가지고 통신
    • 이 계층에서 부르는 데이터의 단위는 프레임
    • 브리지, 스위치
  • 3 : Network Layer
    • 데이터를 목적지까지 빠르고 안전하게 전달(라우팅)
    • 어느 컴퓨터에 데이터를 전송할지 주소를 갖고 있음. IP 주소
    • 데이터 단위는 패킷
    • 주소 부여(IP), 경로 설정(Route)
  • 4 : Transport Layer
    • 양 끝단의 사용자들이 신뢰성 있는 데이터를 주고 받을 수 있게 해줌
    • 송신자와 수신자 간의 효율적인 데이터 전송을 위해 오류검출 및 복구, 흐름제어와 중복조사 등을 수행
    • 데이터 전송을 위해 Port 번호가 사용됨
    • 대표적인 프로토콜로는 TCP와 UDP가 있음
    • 데이터 단위는 세그먼트
  • 5 : Session Layer
    • 응용 프로세스가 통신을 관리하기 위한 방법 정의
    • TCP/IP 세션을 만들고 없애는 역할
    • 통신하는 사용자들을 동기화하고 오류복구 명령들을 일괄적으로 다룸
  • 6 : Presentation Layer
    • 데이터를 어떻게 표현할지 정하는 역할을 하는 계층, 일종의 확장자
    • 데이터 압축, 암호화 등의 기능을 수행
    • ex) EBCDIC로 인코딩된 파일을 ASCII 로 인코딩된 파일로 바꿔주는 것
  • 7 : Application Layer
    • 최종 목적지. HTTP, FTP, SMTP 등과 같은 프로토콜이 있다
    • 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행
  • 참조
    • https://shlee0882.tistory.com/110
    • https://reakwon.tistory.com/59

TCP 3-way-handshake

  • Transport Layer의 프로토콜에는 크게 TCP와 UDP가 있음. 전자는 연결지향적이고, 후자는 비연결적. TCP가 연결 지향적인 특성을 갖게 해주는 방법이 바로 TCP 3-way-handshake 방식.
  • 과정
    • SYN은 Synchronize Sequence Number, ACK는 Acknowledge의 약자
      1. A 클라이언트는 B 서버에 접속을 요청하는 SYN 패킷을 보낸다. 이때 A 클라이언트는 SYN을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 된다
      1. 이때 서버는 Listen 상태로 포트 서비스가 가능한 상태여야 한다. B 서버는 SYN 요청을 받고 A 클라이언트에게 요청을 수락한다는 ACK와 SYN flag가 설정된 패킷을 발송하고 A가 다시 ACK로 응답하길 기다린다. 이때 B 서버는 SYN_RECEIVED 상태가 된다
      1. A 클라이어트는 B 서버에게 ACK를 보내고 이후로 연결이 이어져 데이터가 오간다. 이때 B 서버의 상태는 ESTABLISHED 이다.
  • 참조
    • https://mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-22%ED%8E%B8-TCP-3-WayHandshake-4-WayHandshake

TCP 와 UDP 의 차이점

  • TCP (Transmission Control Protocol)
    • 연결형 서비스로 가상 회선 방식을 제공한다 (3-way-handshake 방식으로 연결 설정, 4-way-handshake 방식으로 연결 해제)
    • 서버와 클라이언트는 1대1로 연결된다
    • 흐름 제어 : 데이터 처리 속도를 조절하여 수산자의 버퍼 오버플로우를 방지
    • 혼잡 제어 : 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지
    • 신뢰성이 높은 전송
      • Dupack-based retransmission
        • 정상적인 상황에서는 ACK 값이 연속적으로 전송되어야 한다
        • 그러나 ACk 값이 중복으로 올 경우 패킷 이상을 감지하고 재전송을 요청한다
      • Timeout-based retransmission - 일정시간동안 ACK 값이 수신을 못할 경우 재전송을 요청한다
    • 패킷에 대한 응답을 해야 하기 때문에(시간지연, CPU 소모) 성능이 낮다
    • Streaming 서비스에 불리하다 (손실된 경우 재전송 요청을 하므로)
  • UDP (User Datagram Protocol)
    • 비연결형 서비스로 데이터그램 방식을 제공한다
    • 정보를 주고 받을 때 신호절차를 거치지 않는다
    • UDP 헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다
    • 신뢰성이 낮다
    • TCP보다 속도가 빠르다
    • 서버와 클라이언트는 1대1, 1대N, N대M 등으로 연결될 수 있다
    • 흐름 제어가 없어서 패킷이 제대로 전송되었는지 확인할 수 없다
    • 파일 전송과 같은 신뢰성이 필요한 서비스보다 성능이 우선되는 경우에 사용한다
  • 참조
    • https://mangkyu.tistory.com/15
    • https://velog.io/@hidaehyunlee/TCP-%EC%99%80-UDP-%EC%9D%98-%EC%B0%A8%EC%9D%B4

HTTP 와 HTTPS 의 차이점

  • HTTP (HyperText Transfer Protocol)
    • 서버와 클라이언트가 인터넷에서 데이터를 주고받기 위한 프로토콜
    • 장점
      • 불특정 다수를 대상으로 하는 서비스에 적합
      • 클라이언트와 서버가 계속 연결된 상태가 아니기 때문에 클라이언트와 서버 간 최대 연결수보다 많은 요청과 응답 처리가 가능
    • 단점
      • 연결을 끊어버리기 때문에, 클라이언트는 이전 상황을 알 수 없음
      • 이러한 특징을 무상태성(stateless)라고 함
      • 정보 유지를 위해 cookie 같은 기술이 등장
    • 문제점 - 통신 상대를 확인하지 않기 때문에 누구나 요청을 보낼 수 있다. 액세스 제한이 없는 경우 요청이 오면 그게 누구든지 응답을 반환한다. - 평문 통신이기 때문에 도청이 가능 - 통신 상대를 확인하지 않기 때문에 위장이 가능 - 완전성을 증명할 수 없기 때문에 변조가 가능 - 의미없는 리퀘스트도 수신한다 -> DoS 공격을 방지할 수 없다
    • 보안 방법 - TCP/IP 구조의 통신은 도청이 가능한 네트워크 - 1. 통신 자체를 암호화 - SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 다른 프로토콜을 조합해 HTTP 통신 내용을 암호화한다 - SSL을 조합한 HTTP를 HTTPS(HTTP Secure)라고 한다
        1. 콘텐츠를 암호화 - HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것으로 받은 측에서는 암호를 해독화하는 처리가 필요하다
  • HTTPS
    • HTTP에 암호화, 인증, 완전성 보호를 더한 것
    • HTTP가 통신하는 소켓 부분을 SSL(Secure Socket Layer)이나 TLS라는 다른 프로토콜로 대체하는 것
    • HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 이용한다
    • 모든 웹페이지에서 HTTPS를 이용하지 않는 이유
      • 평문 통신에 비해 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요하다
      • 통신할 때마다 암호화를 하면 많은 리소스를 소비하게 되어 서버 한 대당 처리할 수 있는 리퀘스트 수가 줄어든다
    • HTTP 2.0이 나오면서 HTTPS가 HTTP보다 빨라졌다고 한다
  • 참조
    • https://brenden.tistory.com/45

DNS round robin 방식

  • DNS(Domain Name System): 도메인 이름과 IP 주소를 변환하는 역할
  • DNS Round Robin
    • DNS를 이용해 하나의 서비스에 여러 대의 서버를 분산시키는 방법
    • 웹 사이트에 접속하는 다수의 사용자는 복수의 웹 서버를 접속, 자연스럽게 서버의 부하가 분산됨
  • 장점
    • 비용적인 부담이 줄어든다
    • 중간 장비 없이도 서비스가 가능하다
  • 단점
    • 서버의 수만큼 공인 IP 주소가 필요하다
    • 한 대의 서버에서 장애가 발생할시, 원인을 찾기 힘들다
    • 부하의 분산이 고르지 않다
    • 서버에 이상이 있는 경우에도 서버로 부하를 분산한다
  • 참조
    • https://server-talk.tistory.com/121

웹 통신의 큰 흐름

브라우저에 url을 입력했을 때 일어나는 일

  1. 브라우저의 url 파싱
    • url의 구조 : https(protocol)://www.naver.com(URL):443(port)
    • 어떤 프로토콜, url, 포트로 요청할지 해석하여 분석한다
    • 포트를 명시적으로 선언하지 않았다면 기본값 (HTTP-80, HTTPS-443)을 요청
  2. HSTS 목록 조회
    • HSTS(HTTP Strict Transport Security)는 HTTP를 허용하지 않고 HTTPS만 허용하는 기능
    • HTTP로 응답 요청이 오면 헤더에 Strict Transport Security라는 필드를 포함하여 응답하고 이를 확인한 브라우저는 HSTS 캐시에 해당 URL을 저장 -> HSTS 목록
    • 브라우저에서는 이 목록을 조회하여 해당 요청을 HTTPS로 보낼지 판단
  3. URL을 IP 주소로 변환
    • URL을 컴퓨터가 읽을 수 있는 IP로 변환해야 함
    • 브라우저는 자신의 로컬 hosts 파일과 브라우저 캐시에 해당 url이 존재하는지 확인
    • 존재하지 않느다면 도메인 주소를 IP 주소로 변환해주는 DNS 서버에 요청하여 변환
  4. 라우터를 통해 해당 서버의 게이트웨이까지 이동
    • 라우터는 라우팅을 통해 해당 요청이 어디로 가야할지 경로를 정해줌
  5. ARP를 통해 IP 주소를 MAC 주소로 변환
    • 논리 주소인 IP 주소를 물리 주소인 MAC 주소로 변환
  6. 대상 서버와 TCP 소켓 연결
    • 소켓 연결은 3-way-handshake 과정을 통해 이루어짐
    • HTTPS 에서는 서로 암호화 통신을 위해 TLS 핸드쉐이킹이 추가됨
  7. HTTP(HTTPS) 프로토콜로 요청, 응답
    • 해당 페이지를 달라고 서버에게 요청
    • 서버에서 요청을 받고 수행할 수 있는지 검사
    • 서버는 응답을 생성하여 브라우저에 전달
  8. 브라우저에서 응답을 해석
    • 서버에서 응답한 내용은 HTML, CSS, JavaScript 등으로 이루어짐
    • 이를 브라우저에서 해석하여 그려줌 - 참조
    • https://deveric.tistory.com/97