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

김정욱·2021년 5월 27일
3

면접준비

목록 보기
3/6
post-thumbnail

웹 동작 방식

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

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

1)로컬 PChosts파일브라우저 캐시확인하여 입력한 도메인매핑정보가 있는지 확인 (있으면 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계층(전송 계층)
    • TCPUDP를 통해 통신을 활성화. 종단간 연결을 수행
    • 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를 사용하는 이유 ?

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

TCP 3-way handshake & 4-way handshake

[ 3-way handshaking ]

  • 신뢰성 있는 통신을 위해 연결을 설정하는 과정
  • TCP양방향성 연결이기 때문에 상호 간 패킷을 보낼 수 있다는 것을 확인하기 위해서 2-way가 아닌 3-way수행
  • 순서
    1) 클라이언트SYN 패킷서버에 전송
    2) 서버SYN패킷을 받고, ACKSYN패킷전송
    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) AB의 공개키암호화 통신에 사용할 자신의 대칭키암호화하여 B에게 전송
    2) B암호문을 받아, 자신의 비밀키복호화
    3) BA로부터 얻은 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 ]

  • 전 세계에서 유일IPISP(인터넷 서비스 공급자)제공하는 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

0개의 댓글