[면접 대비] 네트워크

Swim Lee·2021년 4월 27일
UDPhttphttpstcp신뢰성연결지향
0

기술면접 대비

목록 보기
2/13

네트워크

TCP/IP

  • TCP : 신뢰성, 연결지향적
  • UDP : 비신뢰성, 비연결지향적, 실시간 (신뢰적인 전송보다 실시간 처리가 더 중요한 경우 사용 - ex) 화상회의, 음성통화)

TCP

  • 신뢰적인 통신, 연결지향적
  • 기본적으로 IP 프로토콜같은 비신뢰적인 통신에서 신뢰성을 보장할 수 있도록 해주는 프로토콜이다.

3way handshaking (연결설정)

  • TCP에서 통신전에 연결을 수립하는 단계
  • 수신지 호스트에서 송신지 호스트가 데이터를 받을 수 있는 상태인지 확인하고 연결을 수립하는 작업
  • 3단계로 이루어지기 때문에 3 way handshaking이라고 함
    • syn
    • syn + ack
    • ack

4way hanshaking (연결 해제)

  • 데이터통신이 끝나고 연결을 해제해주는 단계
  • 마찬가지로 4단계로 이루어짐
    • FIN
    • ACK : FIN 패킷을 확인했다는 답장 (바로 연결끊지 않고 미처 전송하지 못한 데이터 전송하는 시간 기다려줌)
    • FIN : 데이터 전송 다끝내고 클라이언트에게 연결끊으라고 메시지 보냄
    • ACK : 서버에서 보낸 FIN에 대한 응답을 해주고, 바로 연결끊지 않고 서버에서 미처 받지 못한 데이터 기다림. TIME_OUT 만큼 기다리고 연결 끊음

3way hanshaking이랑 차이점은 연결 끊으라는 FIN 패킷을 받았을 때, 바로 연결을 끊는 것이 아니라, 서버에서 아직 전송못한 데이터를 기다려주는 시간(TIME_OUT, TIME_WAIT)을 갖는다.

  1. 위그림에서 맨처음에 클라이언트에서 서버에게 연결을 끊겠다고 FIN 패킷 전송
  2. 서버는 FIN 패킷을 받고 알겠다고 ACK를 보낸다음, 미처 전송못한 데이터를 전송하는 시간을 가진다 (TIME_OUT)
  3. 데이터 전송이 다 끝나면 이제 서버가 클라이언트한테 연결을 종료하겠다고 FIN 패킷을 보낸다.
  4. 클라이언트는 FIN 패킷에 대한 응답 ACK를 보낸다. 그리고 서버에서 오는 데이터를 다 받을 때까지 기다린다 (TIME_WAIT)
  5. 서버는 클라이언트의 ACK를 받으면 연결을 종료한다.
  6. 클라이언트는 TIME_WAIT 시간이 지나면 연결을 끊는다.

신뢰성 보장

  • 패킷 손실
  • 패킷 순서 바뀜
  • Congestion : 네트워크 혼잡
  • Overload : 송신자의 버퍼 오버플로우

위 4가지 문제를 보장해준다는 것

패킷 손실과 패킷 순서바뀜 문제같은 경우는 TCP 헤더에 seq number와 ack number를 통해서 보장한다.

수신측에서 받은 패킷의 seq 번호를 확인 후, 이에 대해 잘 받았다는 표시로 ack = seq+1로 해서 응답 패킷을 보내준다.

제대로 전송이 되지 않아서 ack가 제대로 오지 않았다면 (ack가 유실되거나, 와야할 순서의 ack가 오지 않은 경우) 송신측에서는 재전송을 해주는 것!

흐름제어/혼잡제어

흐름제어

  • end to end 통신
  • 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
  • flow control은 수신측이 지나치게 많은 패킷을 받지 않도록 조절하는 것
  • 기본개념은 수신측이 송신측에게 현재 자신의 상태를 피드백 하는 것

혼잡제어

  • 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
  • 전체 네트워크의 트래픽 상태를 보고 제어하는 것 (end to end가 아니라 전체 네트워크)

전송의 전체과정 (인캡슐레이션/디캡슐레이션)

  • 애플리케이션 레이어 : 송신측 애플리케이션 레이어에서 소켓에 데이터를 씀
  • 전송층 : 데이터를 세그먼트에 감싸고 전송층 헤더 (TCP 헤더)를 붙여서 네트워크층에 넘겨준다.
  • 네트워크 층에서는 IP 헤더를 붙여서 IP 패킷으로 감싸고 아랫단으로 계속 인캡슐레이션 시킴
  • 맨 아래 물리층에서는 NIC를 통해서 나간다.
  • 많은 노드들을 지나 송신측 노드로 데이터 패킷이 전달된다. 이때 송신측의 send buffer에 데이터를 저장하고, 수신측은 recieve buffer에 데이터를 저장한다.
  • 애플리케이션에서 준비가 되면 이 buffer에 있는 것을 읽기 시작한다.
  • 따라서 flow control의 핵심은 이 buffer가 넘치지 않도록 하는 것이다.
  • 따라서 수신측은 RWND (Recieve WiNDow)의 남은 공간을 홍보한다. 슬라이딩 윈도우 방식 (윈도우는 송신측에서 한번에 전송하는 패킷 사이즈를 말한다.)

흐름 제어 (Flow Control)

  • 수신측이 송신측보다 데이터 처리 속도가 빠르면 문제 없지만, 송신측의 속도가 빠를 경우 문제가 생긴다.
  • 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있으며, 만약 손실된다면 불필요하게 응답과 데이터 전송이 송수신측 간에 빈번하게 발생
  • 따라서 이러한 위험을 줄이기 위해 송신측의 데이터 전송량을 수신측에 따라 조절해야한다.
  • 대표적인 해결방법으로 슬라이딩 윈도우방식이 있다.

UDP

  • 데이터를 패킷단위가 아닌 데이터그램 단위로 처리하는 프로토콜이다.
  • 비연결성, 신뢰성 없는 전송 프로토콜이다.
  • 데이터그램 단위로 쪼개면서 전송을 해야하기 때문에, 전송계층

TCP/UDP의 등장 배경

  • IP 프로토콜의 역할은 host to host 통신 (장치 to 장치) 만을 지원
  • 장치에서 장치로 이동은 IP 주소로 해결되지만, 하나의 장치에서 동작하는 수많은 프로세스들간에 통신을 할 경우에는 (end to end 통신) IP만으로는 불가능
  • 또한, IP에서는 오류가 발생하면 ICMP(Internet Control Message Protocol)에서 알려주지만 해결해주진 않음
  • IP는 비신뢰적 비연결지향 프로토콜이기 때문에 상위계층인 전송층에서 이런한 신뢰성과 연결지향적인 성격을 보장해주어야한다.
  • 데이터 전송시 패킷을 캡슐화하면서 각 계층마다 헤더가 붙는다.
  • 이러한 헤더에는 크게 2가지 정보가 붙는다.
    • 현재 계층의 정보 (2계층 : MAC주소 / 3계층 : IP 주소 / 4계층 : seq, ack번호)
    • 상위 계층의 프로토콜 정보 (2계층 : 이더타입 / 3계층 : 프로토콜 넘버 / 4계층 : 포트번호)
  • TCP 헤더의 포트번호로 end to end 통신이 가능해진다 (프로세스 구분 가능)
  • TCP 헤더의 seq 넘버, ack 넘버로 패킷 손실, 순서보장이 가능해진다.

UDP 는?

  • IP와 기능 거의 같다.
  • 전송층의 신뢰성 보장 기능이 없다.
  • 단지 포트번호만 추가되었을 뿐이다.
  • TCP와 다르게 에러가 날 수 있고, 재전송이나 순서가 뒤바뀔 수도 있기 때문에 애플리케이션 레이어 단에서 이러한 신뢰성 보장을 처리해줘야한다.

그럼 왜사용?

  • UDP의 결정적인 장점은 데이터의 신속성이다. 데이터의 처리가 TCP보다 빠르다.
  • 왜냐하면 TCP는 통신전에 3way handshaking을 통해 연결설정도 해줘야하고, 패킷을 보내면 잘 보내졌는지 확인하기 위해 ack도 받아야하고, 아무래도 상대적으로 속도가 느릴 수 밖에 없다.
  • 하지만 UDP는 연결설정, 응답확인 등의 과정이 전혀 없기 때문에 속도가 훨씬 빠르다.
  • 따라서 패킷의 손실이나 순서보장보다 실시간 응답이 더 중요한 경우에 이러한 UDP 프로토콜이 사용된다.

대칭키 & 공개키

  • 대칭키 : 암호화와 복호화에 같은 암호키를 사용하는 알고리즘
    • 동일한 키를 주고 받기 때문에 매우 빠르다는 장점이 있다.
    • 다만 대칭키 전달과정에서 해킹 위험에 노출된다. (상대적으로 덜 복잡)
  • 공개키 : 암호화와 복호화에 사용하는 암호키를 분리한 알고리즘, 비대칭키
    • 자신이 가지고 있는 고유한 암호키(비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에게 공개한다.
    • 공개키로 암호화한 것은 개인키로 복호화할 수 있고,
    • 개인키로 암호화한 것은 공개키로 복호화할 수 있다.
    • 암호화 복호화가 매우 복잡하다.

대칭키와 공개키 암호화 방식을 적절히 혼합해보면 어떨까?
-> SSL 탄생의 시초가 됨

1. A가 B의 공개키로 암호화 통신에 사용한 **대칭키**를 암호화하여서 B에게 보낸다.
2. B는 암호문을 받고 자신의 개인키로 이를 복호화한다.
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화해서 A에게 보낸다.
4. A는 자신의 대칭키로 암호문을 복호화한다.
5. 앞으로 이 대칭키로 암호화

정리하면 평문 암호화에 사용할 대칭키를 주고 받을 때 비대칭키 암호화 방식을 사용하는 것!

대칭키를 주고받을 때만 공개키 암호화 방식을 사용하고, 이후에는 계속 대칭키 암호화 방식으로 통신한다.

HTTPS 의 통신 방법의 시초이다.

HTTP & HTTPS

  • 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
  • 모든 형식의 데이터를 다 주고 받을 수 있다.
  • HTTP는 텍스트 교환이므로, 누군가가 네트워크에서 신호를 가로채면 내용이 노출되는 보안이슈가 존재한다.
  • 이런 보안문제를 해결해주는 프로토콜이 HTTPS 이다.

참고 :
https://mangkyu.tistory.com/98
https://opentutorials.org/course/228/4894

HTTPS

  • 인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약이다.
  • HTTP 프로토콜 아래 SSL 계층(암호화 계층)을 하나 더 두는 것
  • HTTPS는 텍스트를 암호화한다. (공개키 + 대칭키)

HTTPS 통신흐름

  • 애플리케이션 서버를 만드는 A기업은 HTTPS를 적용하기 위해 공개키를 만든다. 암호화 방식(대칭키, 공개키)은 기업이 선택하기 나름
  • 신뢰할 수 있는 CA 기업을 선택하고 그 기업에게 A기업의 공개키 관리를 부탁하며 계약을 한다.
  • 계약이 완료된 CA기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA기업의 개인키로 암호화해서 A서버에게 제공한다.
  • A서버는 암호화된 인증서를 갖게되었다.
  • 이제 클라이언트 요청이 오면 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건네준다.
  • 클라이언트가 리소스 요청을 했다 가정하자
  • HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA기업의 개인키로 암호화한 인증서를 받게 된다.
  • CA기업의 공개키는 이미 브라우저가 알고 있다. CA기업의 공개키로 복호화가 된다는 것은 CA기업에 의해 이미 신뢰성 검토를 받았다는 것이고, 이는 클라이언트가 A기업을 신뢰할 수 있다는 뜻이다.
  • 브라우저는 CA기업의 공개키로 인증서를 복호화해서 A기업의 공개키를 얻게된다.
  • 이제 A서버와 통신시 A서버의 공개키로 암호화해서 요청을 날리게된다.
profile
Swim Lee
백엔드 꿈나무 🐥
이전 포스트

[면접 대비] 데이터베이스 - 트랜잭션, 동시성

다음 포스트

[면접 대비] 운영체제

0개의 댓글