[CS 정리] 네트워크(Network)

김정욱·2021년 5월 27일
computer sciencenetwork면접준비
3

면접준비

목록 보기
3/6
post-thumbnail
post-custom-banner

웹 동작 방식

ref : https://hongchan.tistory.com/46

  • 브라우저를 통해 "www.naver.com" 값을 입력하면 어떤 일이 벌어질까?

1)로컬 PC의 hosts파일과 브라우저 캐시를 확인하여 입력한 도메인의 매핑정보가 있는지 확인 (있으면 DNS 쿼리를 생략)
2) DHCP 서버로부터 [사용자 자신의 IP] [가장 가까운 라우터의 IP주소] [가장 가까운 DNS서버의 IP주소]를 받는다
3) ARP 프로토콜을 이용해 가장 가까운 라우터의 MAC주소를 알아낸다
4) DNS쿼리를 DNS 서버에 송신하여, 웹 서버의 IP주소를 받는다
    4-1) 구체적으로.. Root 네임서버 -> .com 네임서버 -> naver.com 네임서버를 거쳐서 IP주소를 수신
5) TCP 소켓을 개방하고 3-way handshaking을 통해 상호간 연결
6) TCP연결에 성공하면, HTTP request를 보내서 응답으로 리소스를 받음
7) 브라우저는 받은 리소스 구문을 분석하고 DOM 트리 생성, 렌더링등을 거쳐서 화면에 표시

OSI 7Layer

OSI 7Layer 란?

  • 국제 표준화 기구 ISO에서 개발한 모델로 컴퓨터 네트워크 통신을 계층으로 나누어 설명하여 개방형 시스템간의 통신을 위해 재정한 권고 사항

PDU ?

  • 개념
    • Protocol Data Unit
    • 데이터 통신에서 상위 계층이 전달한 데이터에 붙이는 제어정보 단위
      (각 계층에서 사용되는 제어 정보 단위)

설명

  • 7계층(응용 계층)
    • 사용자와 직접 상호작용하는 응용 프로그램들이 포함된 계층
    • PDU : Data
    • Ex) HTTP / FTP / DNS 등
  • 6계층(표현 계층)
    • 데이터 표현에 대한 독립성을 제공하고 암호화하는 역할
    • PDU : Data
    • Ex) JPEG / MPEG 등
  • 5계층(세션 계층)
    • 데이터가 통신하기 위한 논리적 연결을 담당. TCP/IP 세션을 만들고 없애는 책임
    • PDU : Data
    • Ex) API / Socket
  • 4계층(전송 계층)
    • TCP와 UDP를 통해 통신을 활성화. 종단간 연결을 수행
    • PDU : 세그먼트(Segment)
    • Ex )
      • TCP : 신뢰성, 연결지향적
      • UDP : 비 신뢰성, 비 연결성, 실시간
  • 3계층(네트워크 계층)
    • 라우팅을 통해 이동할 경로를 선택하여 데이터를 목적지까지 전달
    • PDU : 패킷(Packet) or 데이터그램(Datagram)
    • 라우팅 / 흐름제어 / 오류제어 / 세그먼테이션 등
  • 2계층(데이터 링크 계층)
    • 물리 계층으로 송수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할
    • 흐름제어 / 오류제어
    • PDU : 프레임(Frame)
    • Ex) 브릿지 / 스위치 등
  • 1계층(물리 계층)
    • 데이터를 전기적인 신호로 변환해서 주고받는 기능을 진행하는 공간
    • PDU : 비트(Bit)
    • Ex) 리피터 / 케이블 / 허브 등

TCP / UDP

[ TCP ]

  • TCP는 연결형 서비스로 3-way handshaking 과정을 통해 연결 설정을 수행
  • 순차적 전달과 지연과 손실이 발생하지 않도록 보장함
    --> 흐름제어 / 혼잡제어를 통해
  • 높은 신뢰성을 보장하지만, UDP에 비해 느림

[ UDP ]

  • UDP는 비연결형 서비스인 전송 프로토콜
  • TCP에 비해 속도가 빠르지만, 수신여부, 도착 순서 등을 보장하지 않음
  • 실시간성이 중요한 스트리밍에 자주 사용됨 (게임 포함)

DNS에서 주로 UDP를 사용하는 이유 ?

  • TCP는 3-way handshake를 통해 connection을 유지하지만, UDP는 유지하지 않는다
  • DNS request는 UDP segment에 꼭 들어갈 정도로 작다
  • 즉, DNS를 TCP로 하기에는 커넥션도 유지해야하고 오히려 오버헤드가 더 커지기 때문에 DNS를 주로 사용
    --> 하지만, 크기가 UDP의 제한을 넘어가는 경우에는 TCP를 사용한다

TCP 3-way handshake & 4-way handshake

[ 3-way handshaking ]

  • 신뢰성 있는 통신을 위해 연결을 설정하는 과정
  • TCP는 양방향성 연결이기 때문에 상호 간 패킷을 보낼 수 있다는 것을 확인하기 위해서 2-way가 아닌 3-way를 수행
  • 순서
    1) 클라이언트가 SYN 패킷을 서버에 전송
    2) 서버는 SYN패킷을 받고, ACK과 SYN패킷을 전송
    3) 클라이언트는 ACK과, SYN패킷을 받고, 이에 응답으로 ACK 전송

[ 4 way handshaking ]

  • TCP 연결을 해제하는 과정

  • 순서
    1) 클라이언트는 서버에게 연결을 종료하겠다는 FIN 패킷을 전송
    2) 서버는 이에 대한 응답으로 ACK패킷을 전송
    (이 때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다)
    3) 데이터를 모두 보냈다면, 서버는 연결이 종료되었다는 FIN 패킷을 클라이언트에게 보냄
    4) 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다
         (아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다)
          -서버는 ACK를 받은 이후에 소켓을 닫는다(Closed)
          -클라이언트는 TIME_WAIT 시간이 끝나면 소켓을 닫는다(Closed)

    주의

  • 마지막 4번째 ACK를 보내고 반드시 TIME_WAIT 상태로 일정시간 대기해야 한다
    --> 그렇지 않으면, 만약 ACK가 손실되었을 때 다시 서버가 FIN을 보내야 하는데, 클라이언트는 이미 닫혀있기 때문에 정상 종료를 할 수 없음
    (30초정도 기다리는 시간을 갖는다)

TCP 흐름제어 & 혼잡제어

[ 흐름 제어(Flow Control) ]

기본 설명

  • 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
  • 수신측의 버퍼 정보를 확인해서 송신측의 송신 속도를 낮추거나 증가시킨다.
  • 송신측은 수신측의 버퍼에 대한 정보를 TCP 세그먼트의 rwnd(receive window) 값을 통해서 받는다.

흐름제어 방법

  • 흐름제어 방법
    • Stop and Wait
      : 매번 전송한 패킷에 대해 확인 응답을 받아야만 다음 패킷을 전송
      --> 하나씩 보내기 때문에 너무 비효율적
    • Sliding Window (TCP 채택 방식)
      : 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 해서 데이터 흐름을 동적으로 조절하는 제어 기법

송 / 수신측 유지 정보

  • 송신측 유지 정보
    • LastByteSent : 가장 최근에 보낸 세그먼트
    • LastByteAcked : 가장 최근에 받은 확인 응답
  • 수신측 유지 정보
    • LastByteRead : 가장 최근에 애플리케이션이 프로세스 버퍼에서 읽은 것
    • LastByteRcvd : 가장 최근에 송신측으로부터 받은 데이터 스트림의 마지막 바이트 수
    • RcvBuffer : 할당된 수신 버퍼 크기

동작 원리

  • 수신측 버퍼 정보(rwnd)
    (버퍼의 여유 공간) = RcvBuffer - [LastByteRcvd - LastByteRead]
  • 송신측은 TCP 세그먼트내에 rwnd 값을 받는다.
  • 송신측은 [LastByteSent - LastByteAcked] <= rwnd를 유지하도록 송신 속도 조절

[ 혼잡 제어(Congestion Control) ]

기본 설명

  • 혼잡제어(congestion control)은 네트워크 자체를 혼잡하게 하는 송신자를 억제해서 네트워크의 혼잡을 줄이는 매커니즘

3가지 핵심 포인트

  • 네트워크 혼잡을 감지하는 방법 ?
    : 라우터에서 오버플로우가 발생하여 데이터그램이 손실되는 여부를 통해 파악
    --> 즉, timeout이 나거나 중복 ACK로 인해 데이터그램이 손실되는 것
  • 송신측의 송신속도 조절 ?
    : 송신측은 수신측의 혼잡제어 변수(cwnd)를 통해 송신 속도를 조절
  • 혼잡 제어 알고리즘 ?
    : 송신측의 송신 속도를 조절하기 위해 다양한 정책으로 이루어진 혼잡제어 알고리즘이 사용

혼잡 제어 알고리즘을 위한 정책들

  • AIMD (Additive Increase / Multiplicative Decrease)
    • cwnd 값을 1MSS씩 순차적 증가, 제승적 감소를 수행
    • 패킷 전송에 실패하거나 일정 시간을 넘으면 보내는 속도를 절반으로 감소
  • Slow Start
    • AIMD방식은 최초 임계치까지 도달하기 위해 선형적으로 증가하는데, 이것은 매우 비효율적
    • AIMD의 최초 전송속도를 지수적으로 증가시켜 효율적으로 하는 방법
    • Slow Start 임계치 값 (ssthresh) 까지 지수적 증가 / 그 이후 선형적 증가
  • Fast Retransmit
    • 중복된 ACK 패킷을 받으면 빠르게 재전송을 수행
    • 3-중복ACK가 되면 Fast Recovery를 수행해서 cwnd의 사이즈를 줄인다.
  • Fast Recovery
    • 패킷이 timeout으로 손실되면 cwnd를 1MSS로 낮추지만, 3-중복 ACK로 인해 패킷이 손실되면 cwnd를 절반으로 낮추어 보다 빠르게 크기를 회복하는 방법

혼잡 제어 알고리즘

  • 전체 흐름
    • 기본적으로 AIMD 정책을 따라 선형적으로 증가
    • 초기 시작의 비효율을 극복하기 위해 Slow Start 적용
    • ssthresh(Slow Start threshold), Slow Start의 임계치에 도달하면 Congestion Avoidance를 통해 선형 증가
    • 3-중복 ACK로 인해 손실이 발생하면, Fast Retransmit 을 수행하여 Fast Recovery 상태로 들어간다.
    • Fast Recovery 과정을 통해 cwnd 값을 1MSS로 줄이지 않고 절반으로 떨어 뜨린 후 다시 선형 적인 증가를 수행
    • Timeout으로 데이터그램 손실이 발생했을 때에는 무조건 cwnd를 1MSS로 조정

대칭키 & 공개키 & SSL

[ 대칭키 암호화 ]

설명

  • 암호화 / 복호화에 사용되는 키가 동일한 암호화 방식
  • 장점
    • 공개키 암호화 방식에 비해 빠르다
  • 단점
    • 키를 관리하는 문제로 인해 공개키 방식보다 보안에 취약
      (하나의 키로 암호화 / 복호화를 해야 하기 때문에 공유되어야 한다)
      (인원이 증가할 수록 키 관리가 어려워짐)
  • 예시
    • DES / 3DES
    • AES
    • SEED

[ 공개키 암호화 ]

설명

  • 암호화 / 복호화를 두개의 다른 키를 통해서 하는 암호화 방식
  • 장점
    • 키를 관리하기 편하며, 보안에 강하다
  • 단점
    • 대칭키(개인키)방식에 비해 속도가 느리다
  • 예시
    • RSA

[ SSL(Secure Socket Layer) ]

ref : https://preamtree.tistory.com/38

용어 정리

  • CA(Certificate Authority)
    • 인증서의 핵심은 해당 사이트가 클라이언트가 의도한 서버가 맞는지 보장 해야 한다.
    • 이러한 인증서를 발급하는 기관을 CA라고 한다.
    • CA를 통해서 SSL 인증서를 발급받아야 한다.(무료 or 유료)
  • SSL 인증서 내용
    • 서비스의 정보 (인증서를 발급한 CA / 서비스의 도메인 등)
    • 서버 측 공개키 (공개키의 내용 / 공개키의 암호화 방법 등)
  • 브라우저는 CA의 리스트를 보유하고 있다
    • 공인된 CA의 목록들을 통해 공개키 정보도 함께 가지고 있다

SSL의 핵심 방식

  • 대칭키 암호화 방식과 공개키 암호화 방식을 적절히 혼합하여 탄생한 암호화 방식이 바로 SSL의 핵심 방식이다
  • 원리
    1) A가 B의 공개키로 암호화 통신에 사용할 자신의 대칭키를 암호화하여 B에게 전송
    2) B는 암호문을 받아, 자신의 비밀키로 복호화
    3) B는 A로부터 얻은 A의 대칭키로 A에게 보낼 평문을 암호화하여 A에게 전송
    4) A는 자신의 대칭키로 암호문을 복호화
    5) 이제 앞으로 A의 대칭키를 통해서 암호화 통신을 지속

즉, 정리하면 대칭키를 주고 받는 과정에서 공개키를 사용했을 뿐, 그 이후에는 모두 대칭키 암호화 방식을 이용

SSL 원리

  • SSL은 실제 데이터의 공유로는 대칭키를 사용하며, 대칭키를 공유하는 방법으로 공개키 방식을 사용한다
    --> 공개키 방식은 대칭키보다 비용이 크기 때문
  • 사용하는 방식
    • 실제 데이터 --> 대칭키 방식
    • 대칭키를 공유하기 위해 --> 공개키 방식

SSL 동작 순서

  • 크게 2가지 과정으로 나눌 수 있음
    • 인증서 발급
    • 클라이언트-서버 통신
  • 인증서 발급
    • 웹사이트의 정보(도메인 등등)와 공개키를 CA에 제출
    • CA는 검토 후 [CA의 비밀키]로 우리가 [보낸 사이트의 정보 + 공개키]를 암호화한 인증서를 만듬
    • CA는 인증서를 웹사이트에 발급
  • 클라이언트-서버 통신
    • 사용자가 https에 적용된 화면에 들어감
    • 서버는 해당 화면의 정보와 함께 [인증서]를 보냄
    • 사용자는 브라우저가 가진 [공인 CA리스트]에서 해당 인증서의 발급기관이 있는지 확인하며, 유효기관 등 정보들을 확인
    • [공인 CA 리스트]에 있다면 [해당 CA기관의 공개키]로 받은 [인증서와 정보]를 복호화 한다
    • 복호화를 통해 인증서에 포함되어 있는 [서버의 공개키]를 추출한다
    • 사용자는 [현재 통신에 필요한 대칭키]를 발급하고 추출한 [서버의 공개키]로 암호화 해서 서버에 전송
    • 서버는 [서버의 비밀키]로 사용자의 요청을 복호화 해서 통신에 필요한 [대칭키]를 추출한다
    • 이제 클라이언트와 서버는 지금 통신에 필요한 [대칭키]를 모두 가지고 있으니, 이것을 이용해서 실제 데이터를 주고 받는다!

로드 밸런싱

  • 사용자의 요청에 대한 트래픽을 여러 대의 서버에 균등하게 분산시켜주어 해결하는 기법
  • Load Balancer를 클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 여러 서버에 분산
  • 분산식 웹 서비스
  • 로드 밸런서가 서버를 선택하는 방식
    • 라운드 로빈(Round Robin)
      : 순차적으로 시간단위로 할당하는 방식(CPU 선점 스케줄링 방식)
    • Least Connections
      : 연결 개수가 가장 적은 서버를 선택
    • Source
      : 사용자 IP를 해싱하여 분배 (특정 사용자가 항상 같은 서버로 연결되게 보장)

블로킹 & 논블로킹 / 동기 vs 비동기

ref : https://siyoon210.tistory.com/147 /

  • 동기 vs 비동기 : 하나의 작업에 대해, 작업을 어떠한 '흐름'으로 처리할 것인가
  • 블로킹 vs 논 블로킹 : 전체적인 작업 '흐름'을 막느냐 안막느냐(전체 작업의 제어권을 주냐 안주냐)

[ Blocking & Non-Blocking]

  • Blocking
    • 호출된 함수가 자신이 할 일을 모두 마칠 때 까지 제어권을 계속 가지고서 호출한 함수에게 돌려주지 않아서 계속 기다리도록 하는 방식
  • Non-Blocking
    • 호출된 함수가 자신이 할 일을 채 마치지 않았더라도 바로 제어권을 건네주어(return) 호출한 함수가 다른 일을 진행할 수 있도록 해주는 방식

[ Synchronous & Asynchronous ]

  • Synchronous
    • 호출된 함수의 수행 결과 및 종료 여부를 호출한 함수가 신경쓰는 것
  • Asynchronous
    • 호출된 함수의 수행 결과 및 종료 여부를 호출한 함수가 신경쓰지 않는 것

[ 조합 ]

  • Blocking + Synchronous
    • 결과가 처리되어 나올 때 까지 제어권이 없으니 대기해야 한다
  • NonBlocking + Asynchronous
    • 작업 요청을 받아서 바로 제어권을 넘기기 때문에 결과를 받을 때 까지 다른 일 수행 가능

  • NonBlocking + Synchronous
    • CPU 제어권을 바로 반납하여 다른일을 수행할 수 있지만, 함수 처리 결과를 알기 위해 수시로 확인한다
      (수시로 확인하는 과정에서 Context Switching이 계속 발생해서 비효율적으로 동작하게 됨)

  • Blocking + Asynchronous
    • CPU 제어권을 바로 return 하지 않아서 비동기라도 계속 대기하게 된다

HTTP

  • HyperText Text Transfer Protocol의 약자
  • 인터넷에서 데이터를 주고받을 때 사용되는 프로토콜
  • Stateless 라는 특징이 있다
    --> 그래서 클라이언트-서버간 정보를 유지하기 위해 쿠키,세션,토큰과 같은 인증 수단이 필요

쿠키 / 세션 / 토큰

REST / API / REST API / RESTful

[ REST ]

  • Representational State Transfer의 약자
  • 자원의 이름을 명시하여 상태 정보를 주고 받는 모든 것을 의미
  • 통신을 위해 사용되는 하나의 아키텍처
  • 전송 관련 상태를 표현하는 구조

[ API ]

  • Application Programming Interface의 약자
  • 정보 사용자가 원하는 목표 달성에 있어서 사용되는 interface
  • 모든 내부 로직을 몰라도 interface 사용법만 알면 사용이 가능하다
  • 정보 제공자와 사용자 간 소통하기 위한 하나의 매개채

[ REST API ]

  • 자원의 이름을 명시하여 상태 정보를 주고 받는 REST에 기반한 API

[ RESTful ]

  • REST 구조에 맞게 이루어져 있다는 뜻
  • 목적에 맞게 행위를 HTTP method에 맞추어야 한다
    (CRUD 모두 POST로 하면 안됨)

공인 IP & 사설 IP

[ 공인 IP ]

  • 전 세계에서 유일한 IP로 ISP(인터넷 서비스 공급자)가 제공하는 IP주소
  • 외부에 공개되어 있기 때문에 인터넷에 연결된 다른 장비로부터 접근이 가능
  • 그에 따라 방화벽 등과 같은 보안설정이 필요

[ 사설 IP ]

  • IPV4의 부족으로 인해 모든 네트워크가 공인 IP를 사용하는 것이 불가능해서, 네트워크 안에서 라우터를 통해 할당받는 가상의 주소
  • 별도의 설정 없이는 외부에서 접근이 불가능
  • 특정 네트워크에서만 유일
  • 사설 IP 주소는 다음 3가지 주소 대역으로 고정
    • Class A : 10.0.0.0 ~ 10.255.255.255
    • Class B : 172.16.0.0 ~ 172.31.255.255
    • Class C : 192.168.0.0 ~ 192.168.255.255

NAT / NAPT

[ NAT ]

설명

  • Network Address Translation의 약자
  • 하나의 공인 IP를 여러개의 사설 IP로 변환하는 시스템
  • 일반적으로 라우터가 이 역할을 수행함
  • NAT 테이블을 통해 정보를 요청한 프로토콜, 도메인 등 다양한 정보로 기록하여 되돌아 오는 응답을 매핑해준다
  • 사설 IP로 요청을 할 때에는 공인 IP로 요청한 후 포트포워딩 작업을 통해 통신
  • 같은 사이트에 요청을 하면 더이상 NAT만으로는 여러 요청의 사설 IP를 구분할 수 없다
    --> NAPT의 등장 원인

장점

  • 공인 IP의 절약
  • 공공 망과 분리되어 보안성이 높다

[ NAPT ]

설명

  • Network Address Port Translation
  • NAT의 한계를 극복하기 위해 등장한 기법
  • IP주소 변환과 동시에 포트번호로 변환하여 NAT의 한계 극복 가능
  • docekr와 같은 가상화 방식에서도 사용
profile
김정욱
Developer & PhotoGrapher
이전 포스트

[CS 정리] 알고리즘 (Algorithm)

다음 포스트

[CS 정리] 운영체제 (OS)

post-custom-banner

0개의 댓글