면접 시리즈4 - 네트워크

OSI 7계층

TCP/IP 모델

  • Application(응용) 계층 : 최종 목적지로 응용 프로그램과 연관하여 서비스를 수행하는 계층
    • ex) HTTP, FTP, DNS
  • Presentation(표현) 계층 : 데이터 압축, 변환이 이뤄지는 계층
    • ex) JPEG, MPEG
  • Session(세션) 계층 : 데이터가 통신하기 위한 논리적 연결을 담당하는 계층
    • ex) API, Socket
  • Transport(전송) 계층 : 종단 간의 사용자들에게 신뢰성 있는 데이터를 전달하는 계층
    • 흐름 제어 : 송신측과 수신측 사이의 데이터 처리 속도 차이를 제어
    • 혼잡 제어 : 네트워크 혼잡을 피하기 위해 데이터의 전송 속도 제어
    • 오류 제어 : 오류 검출과 재전송
  • Network(네트워크) 계층 : IP를 지정하고 라우터로 경로를 선택해 네트워크를 통해 패킷을 전달하는 계층
  • Data Link(데이터링크) 계층 : 신뢰성 있는 전송을 보장하기 위한 계층
    • 오류 제어, 흐름 제어, 회선 제어
  • Physical(물리) 계층 : 전기적, 물리적 세부 사항을 정의하는 계층

전송계층은 논리적으로 1:1 연결된 송신과 수신 호스트 즉, 종단간의 호스트에 신뢰성 관련 기능을 제공하고, 데이터 링크 계층은 물리적으로 1:1 연결된 호스트 사이의 전송 즉, 직접 묶여있는 호스트-노드 또는 노드-노드 사이에서의 신뢰성 관련 기능을 제공한다.

계층을 나눈 이유 : 통신이 일어나는 과정을 단계별로 알 수 있고, 문제가 생기면 그 단계만 수정하면 된다.

TCP/IP 4계층

현재는 업데이트되어 5계층으로 불린다.

  • Application 계층 : Application + Presentation + Session 계층
  • Transport 계층
  • Network 계층
  • Data Link 계층
  • Physical 계층

DNS란

IP주소를 문자로 표현한 주소로 바꾸는 시스템 혹은 서버

www.google.com에 접속할 때 일어나는 일

  1. www.google.com을 브라우저 주소창에 입력한다.
  2. 브라우저는 캐싱된 DNS 기록을 통해 www.google.com에 대응되는 IP 주소가 있는지 확인한다.
    • 브라우저 캐시 확인
    • OS 캐시 확인
    • 라우터 캐시 확인
    • ISP 캐시 확인
  3. 요청한 URL이 캐시에 없으면 ISP(인터넷 서비스 제공자, kt 등)의 DNS 서버가 www.google.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위해 DNS query를 날려서 찾는다.
  4. 브라우저는 IP주소를 받아 서버와 TCP 연결을 한다. (3 way handshaking)
    • 클라이언트가 서버로 접속 요청 SYN 패킷을 보낸다.
    • 서버에서는 수락하는 ACK와 SYN 패킷을 보낸다.
    • 클라이언트는 서버에게 확인 응답으로 ACK 패킷을 보낸다.
  5. TCP 연결이 완료되면 브라우저가 웹 서버에 HTTP 요청을 보낸다.
  6. 서버는 요청을 처리하고 response를 생성하고 보낸다.
  7. 브라우저가 HTML content를 사용자에게 보여준다.

4 way-hand shaking

HTTP 요청과 응답 과정이 끝나면 연결과정을 종료하는 4-way-handshaking이 진행된다.

  1. 클라이언트가 서버로 연결을 종료하겠다는 FIN 패킷 전송
  2. 서버는 클라이언트에게 우선적으로 ACK 패킷 전송
  3. 서버는 자신의 통신의 끝날 때까지 기다리고 끝나면 클라이언트에게 FIN 패킷 전송
  4. 클라이언트는 확인했다는 의미로 ACK 패킷을 서버에게 전송
  5. 서버가 보내는 FIN보다 서버가 보내는 데이터가 늦게 보내질 경우를 대비해 클라이언트는 일정 시간 동안 소켓을 닫지 않고 잉여 패킷을 기다림(time wait)
  6. 이후에 연결 종료

포트와 소켓

  • 포트
    • 네트워크를 통해 데이터를 주고받는 프로세스를 식별하기 위해 호스트 내부적으로 프로세스가 할당받는 고유한 값
    • 하나의 IP 주소 내에 개별적으로 부여된 통신 프로세스
  • 소켓
    • 네트워크상에서 동작하는 프로그램 간 통신의 종착점(Endpoint)
    • 두 시스템 사이의 네트워크 연결을 나타내는 객체
    • 소켓을 열기 위해선 호스트에 할당된 IP, 포트 번호, 프로토콜이 필요하다.
    • 위 세가지가 소켓을 정의할 수 있지만 유일하게 식별하지는 않는다.
    • 보내는 쪽과 받는 쪽 모두 소켓을 열어야 한다.
    • 하나의 프로세스가 같은 포트를 갖고 여러 개의 소켓을 열 수 있다.

CIDR(사이더)

사이더(Classless inter-Domain Routing, CIDR)는 직역 그대로 클래스없는 도메인간 라우팅 기법 이다.
기존 IP 주소 할당 방식이었던 클래스를 대체하며 IP주소의 네트워크 영역, 호스트영역을 유연하게 나누어준다.
서브넷 마스크는 /를 사용해서 명시한다.

서브넷

  • Subnetting
    • 기본의 class로 분리하는 IP 주소 체계에서, 네트워크 부분과 호스트 부분으로 IP영역대를 분리하는 것
    • 분할하는 이유는 브로드캐스트에서 성능 저하가 발생하기 때문
    • 네트워크 부분이 같다면 같은 네트워크에 포함되어있는 호스트이고, 네트워크 부분을 서브넷 마스크를 통해 구분한다.
  • Subnet
    • 특정 지역에서 관리되는 IP 영역을 몇 개의 영역으로 나눠서 관리하는 것
  • 장점
    • 네트워크 브로드캐스트 사이즈를 줄일 수 있다.
      • 브로드캐스트 : IP 네트워크에 있는 모든 로컬 네트워크 호스트로 데이터를 전송하는 방식
    • 효율적으로 관리할 수 있다.
    • 네트워크 분리에 따라 보안성 향상

10.0.0.0/24 로 예를 들면, 앞에 24비트(서브넷마스크) 10.0.0을 네트워크 영역 뒤에 마지막 0을 호스트 영역이라고 한다. 앞의 24비트는 네트워크 영역으로 같다면 같은 네트워크 대역이다. 뒤쪽의 8비트는 호스트 영역 범위인데 해당 10.0.0 네트워크에 호스트 영역으로 2^8개의 범위, 즉 2^8개의 Ip를 범위를 할당한다는 것이다. 여기서 8은 32비트 - 24비트로 나온 것이다.
여기서 4개의 서브넷으로 쪼갠다고 한다면 마지막 8비트의 맨앞 2자리를 서브넷으로 구분하는데 사용한다. 2자리를 사용하는 이유는 2^n>=4 일때 n는 2가 최소값이기 때문이다. 만약 5개의 서브넷으로 쪼갠다면 앞에 3비트를 써야한다.
4개의 서브넷으로 쪼갠다면 8비트의 맨앞 2자리가 00, 01, 10, 11로 구분되어 2자리가 서브넷 ID가 되고 나머지 뒤에 6자리가 사용가능한 호스트 ID가 된다.

캐스트

  • 유니 캐스트 : 특정 대상과 1:1 통신
  • 멀티 캐스트 : 특정 다수와 1:N 통신
  • 브로드 캐스트 : 네트워크에 있는 모든 대상과 통신

MTU(Maximum Transmission Unit)

패킷이나 프레임의 최대 크기 로 데이터의 크기가 크다면 단편화해야 한다.

TCP, UDP

  • TCP
    • 연결형 서비스를 지원하는 전송계층 프로토콜
    • 흐름 제어(송수신 측의 데이터 처리 속도차이 해결), 혼잡 제어(송신측의 전달과 네트워크 데이터 처리 속도 해결), 오류 제어(오류 검출과 재전송)를 통해 신뢰성을 보장
    • 인터넷 환경(http)에서 기본으로 사용
    • 초기화(3way-hand-shaking)과 종료(4way-hand-shaking) 필요
    • 수신 여부 확인
  • UDP
    • 비연결성 서비스를 지원하는 전송 프로토콜
    • 전송 순서를 보장하지 않음
    • 수신 여부를 확인하지 않음
    • 신뢰성이 낮지만 속도가 빠르다.(스트리밍 서비스에 이용)

HTTP, HTTPS

  • HTTP
    • www 상에서 정보를 주고받을 수 있는 포로토콜
    • 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜
    • 주로 HTML 문서를 주고 받는데 사용
    • TCP(HTTP/1, HTTP/2), UDP(HTTP/3)를 사용하며, 80번 포트를 사용한다.
  • HTTPS
    • HTTP의 보안상 문제를 해결하기 위해 등장한 프로토콜
    • HTTP는 텍스트로 자원을 주고받기 때문에 네트워크를 가로챈다면 내용이 유출되는 보안 이슈가 발생한다.
    • SSL, TLS(SSL의 최신 버전)를 이용해 암호화하여 주고받음
      • 응용 계층 및 전송 계층 사이에 위치
    • 443 포트 사용
    • 모든 HTTP 요청과 응답 데이터는 네트워크로 보내기지 전에 전송 계층과 응용 계층 사이에서 암호화 된다.
    • HTTP 자체를 암호화하는 것이 아니라 운반하는 HTTP Body 부만 암호화를 진행하고 Header는 암호화하지 않는다.
    • 암호화 통신 방법 (공개키/개인키, 대칭키 방식을 혼합해서 사용)
      • A에서 B로 접속 요청
      • B에서 공개키를 A에게 전달
      • A는 자신의 대칭키를 공개키 A로 암호화해서 B에게 전달
      • B는 개인키로 복호화하여 A의 대칭키를 얻음
      • 얻어낸 대칭키를 이용하여 A와 B가 암호문을 주고 받음

HTTP Method

  • GET
    • 조회, 리소스 요청
  • POST
    • 요청된 데이터 처리
    • 자원을 생성
  • PUT
    • 요청된 자원이 없으면 생성
    • 요청된 자원을 새 것으로 전체 갱신
  • PATCH
    • 자원의 일부분만 수정
  • DELETE
    • 요청된 자원 삭제

HTTP 멱등성

특정 HTTP 메서드를 여러 번 요청을 했을 경우, 매번 요청 결과가 같다면 해당 메소드를 멱등성 메소드라고 한다.
GET, PUT, DELETE가 멱등성 메서드에 속하고 POST는 멱등성 메서드가 아니다.
같은 POST를 연속적으로 보낸다면 명령은 여러 번 내린 것처럼 부가적인 결과를 가져오기 때문이다.(POST 요청을 반복하면 같은 내용이더라도 다른 데이터가 계속 추가된다.)
GET은 여러 번 수행해도 서버의 상태가 변하지도 않고 같은 결과를 가져온다.
PUT은 여러 번 수행해도 결과적으로 데이터는 요청한 값으로 수정된 항상 같은 상태이다.
DELETE도 여러 번 수행해도 이미 존재하든, 존재하지 않든 그 데이터는 DELETE 요청을 보낸 시점에 사라진다.

cf 안전성
안전성은 호출해도 리소스를 변경하지 않는 특성으로 서버에 영향을 끼치는 여부로 생각하면 된다.
GET 메서드만 안전성 메서드다.

HTTP와 TCP의 관계

TCP/IP 모델에서 봤을 때, 개념적으로 TCP는 4계층에 존재하고 HTTP는 5계층에 존재한다.
따라서 HTTP는 TCP위에서 동작한다고 할 수 있다.
쉽게 말해, 메시지 형식에 대해서는 HTTP가 제공해주고, 이 메시지를 TCP 방식으로 전달하는 것이다.

keep-alive 헤더

HTTP는 매번 연결을 끊고 새로 생성한다.
특정 시간까지는 access가 없더라도 기다리고 연결상태를 유지하는 헤더이다.
HTTP 1.1부터는 defualt로 keep-alive를 지원한다.

HTTP 1.0 vs HTTP 1.1

  • HTTP 1.0
    • 요청 컨텐츠마다 TCP 커넥션을 맺고 끊음을 반복한다.
    • 요청1 -> 응답1 -> 요청2 -> 응답2 순으로 순차적으로 진행된다. 즉, 응답을 받아야만 다음 작업을 한다.
  • HTTP 1.1
    • 매 요청마다 TCP 커넥션을 맺고 끊음을 반복하지 않고 keep-alive를 통해 일정 시간 동안 커넥션을 유지한다.
    • 클라이언트는 각 요청에 대한 응답을 기다리지 않고 여러개의 요청을 연속적으로 보낸다.(파이프라이닝) 하지만 각 응답의 처리는 순차적으로 처리된다.

cf) 파이프라이닝 그림1

HTTP/2.0

  • 하나의 커넥션으로 동시에 여러 개의 메세지를 주고 받을 수 있으며, response는 순서에 상관없이 stream으로 주고받는다.
  • 서버는 클라이언트의 요청에 대해 요청하지 않은 리소스를 마음대로 보낼 수 있다.
  • Header의 내용과 중복되는 필드를 재전송하지 않아 데이터를 절약한다.

Multiplexed Streams

그림2
HTTP/2.0은 한 커넥션에서 여러개의 메시지를 주고받을 수 있으며, 응답은 순서에 상관없이 stream으로 주고받는다.
위 그림을 보면 하나의 커넥션에서 여러 병렬 스트림(3개)가 존재한다. Stream이 뒤섞여서 전송될 경우, 수신측에서 stream number을 이용해 재조합한다.

Server Push

그림3
서버는 클라이언트 요청에 대해 요청하지 않은 리소스도 보낼 수 있다.
HTTP/1.1에서는 HTML문서를 요청하고 받은뒤 그 안에 css,image 파일이 있다면 서버로 재요청했으나, HTTP/2.0에서는 Server Push 기능으로 클라이언트에서 요청하지 않은 (HTML문서에 포함된 리소스) 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화하여 성능을 향상시킨다.

Header Compression

그림4
Header의 내용과 중복되는 필드를 재전송하지 않도록 하여, 데이터를 절약한다.
기존에 HTTP Header가 Plain Text(평문)이었지만, HTTP/2에서는 Hash Table과 Huffman Coding을 사용하는 HPACK이라는 Header 압축방식을 이용하여 데이터 전송 효율을 높였다.

CORS

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.
웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.

브라우저는 보안상의 이유로, 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다.
예를 들면, domain-a.com <-> domain-b.com 간의 요청은 CORS정책 위반으로, 브라우저에서 요청을 제한한다.
따라서 다른 출처의 리소스를 불러오기 위해서는, 그 출처에서 교차 출처 리소스 공유에 대한 헤더(CORS)를 응답 시 반환해주어야 한다. 기본적으로는 다음과 같이 동작한다.
그림5

  1. 실제 요청을 보내기 전에 Preflight라는 예비 요청을 보낸다. 이때 HTTP의 OPTIONS 메서드를 이용해 서버에 보낸다.
  2. 서버는 예비 요청이 CORS를 위반하고 있는지를 확인하고 정보를 클라이언트에게 보낸다.
  3. Preflight에 대해 서버 응답이 안전하다면 실제 요청을 보낸다.


Spring에서는 아래와 같은 방법으로 해결한다고 한다.

  • Servlet Filter를 커스텀한 Cors 설정하는 방식
  • WebMvcConfigurer를 구현한 Configuration 클래스를 만들어서 addCorsMapping을 재정의하는 방식
  • Spring Security에서 CorsConfigurationSource를 빈 등록하고 Config에 추가하는 방식

REST API

REST는 HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 자원을 처리하도록 설계된 아키텍처이다.
REST를 기반으로 만든 API를 REST API라고 한다.
RESTful은 REST 아키텍처를 구현하는 웹서비스를 나타내는 것으로 REST 원리를 따르는 시스템을 RESTful이라고 한다.
HATEOAS라는 개념이 있는데, 동적인 API를 제공할 수 있게 된다.
모든 관련된 동작 을 URI를 통해 알려주어, 클라이언트가 API의 변화에 일일이 대응하지 않아도 된다는 장점이 있다.
HTTP를 기반으로 동작하다보니 HTTP의 이점을 그대로 가져올 수 있다.(무상태, 캐시처리 등등..)

REST 하지 않다는 것

  • HTTP Method를 한가지만 사용하고 있다.(Post만 사용하고 있다던가)
  • URL에 동사를 사용하고 있다.(리소스는 명사적 특성을 갖는다.)

정리하면, HTTP의 자원을 제대로 활용하지 않고 있다면 REST하지 않다고 볼 수 있다.

쿠키, 세션

기본적으로 HTTP 프로토콜 환경은 “connectionless, stateless”한 특성을 가지기 때문에 서버는 클라이언트가 누구인지 매번 확인해야 한다.
이 특성을 보완하기 위해서 쿠키와 세션을 사용한다.

  • 쿠키
    • 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
  • 세션
    • 일정 시간 동안 같은 브라우저로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 유지하는 것
  • 세션과 쿠키의 차이점
    • 저장 위치
      • 쿠키는 클라이언트, 세션은 서버
    • 라이프 사이클
      • 쿠키는 만료시간까지 유지, 세션은 브라우저 종료 시 삭제
    • 속도
      • 세션은 정보가 서버에 있기 때문에 처리가 요구되어 쿠키가 더 빠르다.
    • 보안
      • 쿠키는 클라이언트 로컬에 저장되어 취약하지만, 세션은 서버에서 관리해서 비교적 안전
  • 세션보다 주로 쿠키를 사용하는 이유
    • 세션은 서버의 자원을 사용하기 때문에 사용자가 많은수록 소모되는 자원이 상당하기 때문

JWT

보통 로그인 방식으로는 세션과 쿠기를 통해 구현한다.
세션에 저장된 정보는 고유 세션ID가 부여되는데 사용자가 로그인을 하면 서버는 쿠키에 세션ID를 실어서 보낸다. 브라우저는 쿠키를 쿠키저장소에 갖고 있다가 다음 페이지를 요청할 때 해당 유저의 쿠키를 다시 요청헤더에 포함해서 전송한다. 서버는 쿠키 내부의 세션ID를 통해 세션 내부에 일치하는 유저 정보를 가져와서 처음에 로그인한 유저가 맞는지 확인하는 작업이 반복되면서 로그인 상태가 유지된다.
세션은 서버의 메모리 내부에 저장되기 때문에 많아지는 만큼 메모리에 부하가 걸리게 되고, 확장 시 세션을 분산시키는 기술을 따로 설계해야 한다.
JWT는 토큰을 만들어 발행하는 방식 으로 쿠키에 담거나 HTTP 헤더에 담아서 보낼 수 있다. 따로 서버에서 저장하지 않기 때문에 토큰이 유효한지 검증하는 과정만 있으면 된다.
하지만 탈취에 의해 악의적으로 사용될 가능성이 있기에 보통 유효시간을 짧게 가져가고 Refresh 토큰을 사용하는 방식으로 구현한다.
쿠키는 웹브라우저에서 사용할 수 있는 기능이므로 모바일 애플리케이션에서는 JWT를 사용한 인증방식이 최적이다.

OAuth

자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜

URI, URL, URN

URI

URI는 인터넷 자원을 식별하기 위한 문자열 이다.
URI는 인터넷 주소 같은 것으로 정보 리소스를 유일하게 식별하고 위치를 지정할 수 있다.

http://test.com/company/location
http://test.com/member/jobhope

URI의 하위 개념으로 URL, URN이 있다.

URL

웹에서 자원의 위치를 나타낸다. 즉, 특정 서버의 한 리소스에 대해 구체적인 위치 를 표현한다.

safefood.com 서버에서 food폴더 안의 salad.png를 요청하는 URL
>> http://safefood.com/food/salad.png

http://example.com/mypage.html - 실제 사이트 URL
http://img.naver.net/static/www/dl_qr_naver.png - 네이버 앱QR코드의 이미지에 대한 URL

URN

어떤 리소스가 있을 때 해당 리소스의 위치에 영향을 받지 않는 고유한 이름 역할을 한다.
만약 backtony.github.io/12 라는 URL를 backtony.github/io/test/12 로 바꿨다면 찾을 수 없게 된다. URL은 주소이지 실제 이름이 아니기 때문에 해당 위치에 있는 리소스를 찾지 못한다.
따라서 이를 방지하기 위해 객체를 가리키는 실제 객체 이름을 사용하는 방식으로 이렇게 되면 위치가 바뀌더라도 리소스의 위치를 찾을 수 있게 된다.

중간자 공격

두 사람이 서로 통신을 주고 받는데, 중간에 제 3의 인물이 끼여서 데이터를 중계한다면, 이 제3자는 그 내용을 모두 알 수 있고, 데이터를 위/변조할 경우 두 사람에게 서로 잘못된 정보를 전달하게 만들 수도 있다. 중간에서 데이터를 가로채는 것이 중간자 공격이다.
중간자 공격은 4가지가 있다.

  • 스니핑
    • 시스템 및 네트워크에서 들어오고 나가는 데이터 패킷을 캡쳐한다.
  • 패킷 주입
    • 공격자가 일반 데이터와 함께 악의적인 데이터를 주입한다.
  • 세션 하이재킹
    • 세션 가로채기라고도 불리며 두 시스템 간 연결이 활성화된 상태를 가로채는 것
  • 보안 소켓 계층 스트리핑
    • 공격자는 SSL/TLS 연결을 차단하여 프로토콜 보안성이 있는 HTTPS에서 안전하지 않은 HTTP로 전환한다.

이 공격법을 방어하기 위한 목적으로 만들어진 것이 TLS 통신이다. TLS 통신은 클라이언트가 연결을 요청하면 서버에서 자신의 공개키가 포함된 인증서를 보내고, 클라이언트는 인증서의 내용을 연결 프로그램(웹 브라우저 등) 또는 운영체제에 내장된 루트 인증서 정보와 비교하여 무결성을 검증한 뒤, 인증서에 있는 공개키로 대칭형 암호화 키를 만들 수 있는 난수 정보를 공개키로 암호화해 서버로 보내며, 클라이언트와 서버가 각각 이 난수에서 암호화 키를 만들어내 암호화 연결이 개시된다.





https://velog.io/@roh-j/CORS-Cross-Origin-Resource-Sharing%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
https://github.com/jobhope/TechnicalNote
https://github.com/WooVictory/Ready-For-Tech-Interview
https://github.com/JaeYeopHan/Interview_Question_for_Beginner
https://github.com/WeareSoft/tech-interview
https://dailyscat.gitbook.io/twis/network/jwt-oauth]


© 2021. By Backtony