개발관련 책

면접을 위한 CS 전공지식 노트 2장

MIN우 2024. 3. 25. 13:29
728x90

네트워크 기초

 

네트워크란 노드와 링크가 서로 연결되어 있거나 연결되어 있으며 리소스를 공유하는 집합,

여기서 노드는 서버,라우터,스위치 등 네트워크 장치를 의미하고 링크는 유선 또는 무선을 의미합니다.

 

처리량과 지연 시간

 

네트워크를 구축할 때 "좋은: 네트워크로 만드는 것이 중요합니다. 좋은 네트워크란 많은 처리량을 처리할 수 있으며 지연시간이 짧고 장애 빈도가 적으며 좋은 보안을 갖춘 네트워크를 말합니다.

 

처리량

 

- 처리량은 링크 내에서 성공적으로 전달된 데이터의 양을 말하며 보통 얼만큼의 트래픽을 처리했는지를 나타냅니다.

"많은 트래픽을 처리한다= 많은 처리량을 가진다"

 

단위로는 bps(bits per second)를 씁니다. 초당 전송 또는 수신되는 비트 수라는 의미입니다. 처리량은 사용자들이 많은 접속할 때마다 커지는 트래픽, 네트워크 장치 간의 대역폭, 네트워크 중간에 발생하는 에러, 장치의 하드웨어 스펙에 영향을 받습니다.

 

트래픽이 많아짐 -> 흐르는 데이터가 많아졌다

처리량이 많아짐 -> 처리되는 트래픽이 많아졌다

 

대역폭 - 주어진 시간동안 네트워크 연결을 통해 흐를 수 있는 최대 비트 수

 

지연시간 - latency 

요청이 처리되는 시간을 말하며 어떤 메세지가 두 장치 사이를 왕복하는 데 걸린 시간을 말합니다 .

 

지연시간은 매체타입(무선,유선) , 패킷 크기, 라우터의 패킷 처리시간에 영향을 받습니다.

 

네트워크 토폴리지와 병목현상

 

네트워크 토폴리지

 

노드와 링크가 어떻게 배치되어 있는지에 대한 방식이자 연결형태를 의미합니다.

 

트리 토폴리지

 

계층형 토폴로지라고 하며 트리 형태로 배치한 네트워크 구성을 말합니다.

노드의 추가 , 삭제가 쉬우며 특정 노드에 트래픽이 집중될 때 하위 노드에 영향을 끼칠 수 있습니다.

 

버스 토폴리지

 

중앙 통신 회선 하나에 여러 개의 노드가 연결되어 공유하는 네트워크 구성을 말하며 근거리 통신망(LAN)에서 사용합니다.

 

 

설치 비용이 적고 신뢰성이 우수하며 중앙 통신 회선에 노드를 추가하여 삭제하기 쉽습니다. 그러나 스푸핑이 가능한 문제점이 있습니다.

 

스푸핑이란 ?

LAN상에서 송신부에 패킷을 송신과 관련 없는 다른 호스트에 가지 않도록 하는 스위칭 기능을 마비시키거나 속여서 특정 노드에 해당 해킷이 오도록 처리하는 것을 말합니다.

 

스푸핑을 적용하면 올바르게 수신부로 가야 할 패킷이 악의적인 노드에 전달되게 됩니다.

 

스타 토폴리지

 

중앙에 있는 노드에 모두 연결된 네트워크 구성을 말합니다.

노드를 추가하거나 에러를 탐지하기 쉽고 패킷의 충돌발생 가능성이 적습니다. 또한 어떠한 노드에 장애가 발생해도 쉽게 에러를 발견할 수 있으며 장애 노드가 중앙 노드가 아닐 경우 다른 노드에 영향을 끼치는 것이 적다 하지만 중앙 노드에 장애가 발생하면 전체 네트워크를 사용할 수 없고 설치비용이 고가 입니다.

 

링형 토폴리지

 

각각의 노드가 양 옆의 두 노드와 연결하여 전체적으로 고리처럼 하나의 연속된 길을 통해 통신을 하는 망 구성 방식

 

 

노드 수가 증가되어도 네트워크상의 손실이 거의 없고 충돌이 발생되는 가능성이 적고 노드의 고장 발견을 쉽게 찾을 수 있습니다. 하지만 네트워크 구성 변경이 어렵고 회선에 장애가 발생하면 전체 네트워크에 영향을 크게 끼치는 단점이 있습니다. 

 

메시 토폴리지

 

망형 토폴리지라고도 하며 그물망처럼 연결되어 있는 구조입니다.

 

 

한 단말 장치에 장애가 발생해도 여러개의 경로가 존재하므로 네트워크를 계속 사용할 수 있고 트래픽도 분산처리가 가능합니다. 하지만 노드의 추가가 어렵고 구축 비용과 운용 비용이 고가인 단점이 있습니다.

 

-병목현상이란?

전체시스템의 성능이나 용량이 하나의 구송 요소로 인해 제한을 받는 현상

 

네트워크 분류

 

LAN: 근거리 통신망을 의미하며 같은 건물이나 캠퍼스 같은 좁근 공간에서 운영됩니다. 전송속도가 빠르고 혼잡하지 않습니다.

 

MAN: 대도시 지역 네트워크를 나타내며 도시 같은 넓은 지역에서 운영됩니다. 전송 속도는 평균이며 LAN보다는 더 많이 혼잡합니다.

 

WAN: 광역 네트워크를 의미하며 국가 또는 대륙 같은 더 넓은 지역에서 운영됩니다. 전송 속도는 낮으며 MAN보다 더 혼잡합니다.

 

 

 

네트워크 성능 분석 명령어

네트워크 병목 현상의 주된 원인은 다음과 같습니다

 

- 네트워크 대역폭

- 네트워크 토폴로지

- 서버 CPU, 메모리 사용량

- 비효율적인 네트워크 구성

 

ping

 

ping(Packet Internet Grouper)은 네트워크 ㅅ항태를 확인하려는 대상 노드를 향해 일정한 패킷을 전송하는 명령어

이를 통해 해당 노드의 패킷 수신 상태와 도달하기 까지 시간 등을 알 수 있으며 해당 노드까지 네트워크가 잘 연결되어 있는지 확인할 수 있습니다. ping 은 TCP/IP 중 ICMP 프로토콜을 통해 동작하며 이 떄문에  ICMP프로토콜을 지원하지 않은 기기를 대상으로는 실행할 수 없거나 네트워크 정책 상 ICMP나 traceout를 차단하는 대상의 경우 ping 테스팅은 불가능합니다.

 

netstat

 

접속되어 있는 서비스들의 네트워크 상태를 표시하는데 사용되며 네트워크 접속,라우팅 테이블,네트워크 프로토콜 등 리스트를 보여줍니다. 주로 서비스의 포트가 열려 있는지 확인할 때 씁니다.

 

nslookup

 

DNS에 관련된 내용을 확인하기 위해 쓰는 명령어 특정 도메인에 매핑된 IP를 확인하기 위해 사용합니다.

 

 

tracert 

 

윈도우에서는 tracert이고 리눅스에서는 traceoute라는 명령어로 구동된다. 목적지 노드까지의 네트워크 경로를 확인할 때 사용 목적지 노드까지 구간들 중 어느 구간에서 응답 시간이 느려지는지 등을 확인할 수 있다.

 

TCP/IP 4계층

 

인터넷에서 컴퓨터들이 서로 정보를 주고받는데 쓰이는 프로토콜의 집합입니다.

 

 

애플리케이션 계층

FTP,HTTP,SSH,SMTP,DNS 등 응용 프로그램이 사용되는 프로토콜 계층이며 웹 서비스 ,이메일 등 서비스를 실질적으로 사람들에게 제공하는 층입니다.

 

전송계층

- 전송계층은 송신자와 수신자를 연결하는 통신 서비스를 제공하며 연결 지향 데이터 스트림지원, 신뢰성,흐름제어를 제공합니다. 대표적으로 TCP,UDP가 있습니다.

 

TCP는 패킷 사이의 순서를 보장하고 연결 지향 프로토콜을 사용해서 연결을 하여 신뢰성을 구축해서 수신 여부를 확인하여 가상회선 패킷 교환방식이라고 합니다.  3way handshake와 4way handshake에 대한 이해가 필요하다.

 

 

 

UDP는 순서를 보장하지 않고 수신 여부를 확인하지 않으며 단순히 데이터만 주는 데이터그램 패킷 교환방식을 사용합니다.

 

TCP 가상회선 패킷 교환방식 

 

 

인터넷 계층

 

인터넷계층은 장치로부터 받은 네트워크 패킷을 IP주소로 지정된 목적지로 전송하기 위해 사용되는 계층입니다. IP,ARP,ICMP등이 있으며 패킷을 수신해야 할 상대의 주소를 지정하여 데이터를 전달합니다. 상대방이 제대로 받았는지 에 대해 보장하지 않는 비연결형적인 특징을 가지고 있습니다.

 

링크 계층

 

전선 , 광섬유,무선 등으로 실질적으로 데이터를 전달하며 장치 간에 신호를 주고받는 "규칙"을 정하는 계층

물리계층은 무선LAN과 유선 LAN을 통해 0과 1로 이루어진 데이터를 보내는 계층, 데이터 링크계층은 이더넷 프레임을 통해 에러확인 , 흐름제어 ,접근제어를 담당

 

네트워크 기기

 

애플리케이션 계층:L7 스위;치

인터넷 계층: L3 스위치

데이터링크: L2 스위치,브리지

물리계층:NIC,리피터 ,AP

 

L7스위치는 로드밸런서라고도 하며 , 서버의 부하를 분산하는 기기입니다. 클라이언트로부터 오는 요청들을 뒤쪽의 여러서버로 나누는 역할을 하며 시스템이 처리할 수 있는 트래픽 증가를 목표로 합니다.

 

URL,서버,캐시,쿠키들을 기반으로 트래픽을 분산합니다. 또한 , 바이러스 ,불필요한 외부 데이터 등을 걸러내는 필터링 기능 또한 가지고 있으며 응용 프로그램 수준의 트래픽 모니터링도 가능합니다.

만약 장애가 발생한 서버가 있다면 이를 트래픽 분산 대상에서 제외해야하는 , 이는 정기적으로 헬스체크를 이용하면서 감시하고 이루어집니다.

 

L4스위치

IP와 포트를 기반으로(특히 포트를 기반으로) 트래픽을 분산처리 합니다. 

 

AWS에서는 L7스위치를 이용한 로드밸런서인 ALB를 사용하고 , L4는 NLB를 사용합니다.

 

 

NAT

 

NAT(network address translation)는 패킷이 라우팅 장치를 통해 전송되는 동안 패킷의 IP 주소 정보를 수정하여 IP주소를 다른 주소로 매핑하는 방법입니다. IPv4 주소체계만으로는 많은 주소들을 모두 감당하지 못하는 단점이 있는데, 이를 해결하기 위해 NAT로 공인 IP와 사설 IP로 나눠서 많은 주소를 처리합니다. NAT를 가능하게 하는 소프트웨어는 ICS,RRAS,Netfilter등이 있습니다.

 

 

앞의 그림처럼 홍철 팀장, 가영대리는 192.168.0.xxx를 기반으로 각각의 다른 IP를 가지고 있습니다. 이는 사설 IP라고 합니다. 그리고 NAT 장치를 통해 하나의 공인 IP인 121.165.151.200으로 외부 인터넷에 요청할 수 있습니다.

 

이를 통해 어비스 회사에 있는 홍철 팀장과 가영 대리는 하나의 IP인 121.165.151.200을 기반으로 각각의 다른 IP를 가지는 것 처럼 인터넷을 사용할 수 있습니다. 이처럼 NAT장치를 통해 사설 IP를 공인 IP로 변환하거나 공인 IP를 사설 IP로 변환하는데 사용됩니다.

 

NAT를 이용한 보안 

 

NAT를 이용하면 내부 네트워크에서 사용하는 IP주소와 외부에 드러나는 IP주소를 다르게 유지할 수 있기 떄문에 내부 네트워크에 대한 어느정도의 보안이 가능합니다.

 

 

HTTP

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었습니다.이는 RTT 증가를 불러왔습니다.

 

서버로부터 파일을 가져올 때마다 TCP의 3웨이 핸드셰이크를 계속해서 열어줘야하기 때문에 RTT증가하는 단점이 있었습니다.

 

RTT(Round trip delay) ? 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간이며 , 패킷 왕복시간이라고 생각하면된다.

 

RTT해결하기위한 방법 

- 매번 연결할 때마다 RTT가 증가하니 서버에 부담이 많이 가고 사용자 응답시간이 길어졌습니다. 이를 해결하기 위해 

이미지 스플리팅,코드 압축,이미지 Base64인코딩사용했습니다.

 

이미지 스플리팅

 

하나의 이미지인 icons.png를 기반으로 background-position을 통해 2개의 이미지를 설정하여 해결

 

코드 압축

 

코드를 압축하여 개행문자,빈칸을 없애서 코드의 크기를 최소화

 

이미지 Base64인코딩

 

64진법으로 이루어진 문자열로 인코딩. 이 방법을 사용하며 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있습니다.하지만 문자열로 변환할 경우 37% 정도로 크기가 더 커지는 단점이 있습니다.

 

 

HTTP/1.1

 

HTTP/1.0에서 발전한 것이 바로 HTTP/1.1입니다. 매번 TCP연결을 하는 것이 아닌 , 한번 TCP초기화를 한 이후에 keep -alive라는 옵션으로 여러개의 파일을 송수신 할 수 있도록 바뀌었습니다. 1.0에도 있엇지만 표준화가 되지 않았다.

그래서 1.1부터 기본옵션으로 설정되었음

 

하지만 1.1로 단점이 존재함 . 다수의 리소스(이미지,동영상,css 파일 ,js파일 등)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있었다.

 

HOL Blocking

 

네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연이 될때 발생하는 성능 저하 현상

image.jpg가 느리게 받아진다면 그 뒤에 있는 것들이 대기하며 다운로드가 지연되는 상태가 된다.

 

무거운 헤더구조

HTTP1.1의 헤더에는 쿠키 등 많은 메타데이터가 들어가 있고 압축이 되지않아 무거웠다.

 

HTTP/2.0

 

HTTP/2 은 HTTP/1.x보다 지연시간을 줄이고 응답시간을 더 빠르게 할 수 있으며 멀티플렉싱,헤더압축,서버푸시,요청의 우선순위 처리를 지원하는 프로토콜

 

멀티플렉싱이란 ?

 

여러개의 스트림을 사용하여 송수신 한다는 것입니다. 이를 통해 특정 스트름의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 끼치고 나머지 스트림을 멀쩡하게 동작함.

 

스트림이란 ?

 

시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

 

 

 

병렬적인 스트림을 통해 데이터를 서빙하고있다. 스트림내의 데이터 들도 쪼개어져 있습니다. 애플리케이션에서 받아온 메시지를 독립된 프레임으로 조각내어 서로 송수신한 후 다시 조립하여 데이터를 주고 받습니다.

 

 

이로써 2.0에서는 단일 연결을 사용하여 병렬로 여러 요청을 받을 수 있고, 응답을 줄일 수 있었습니다. 이렇게 되면 HTTP/1.x에서 발생하는 문제인 HOL Blocking( Head-of-line blocking )문제를 해결할 수 있고 keep-alive 및 헤더크기문제를 해결할 수 있습니다.

 

HTTP2.0에서는 헤더압축을 써서 해결하는데 이때 허프만 코딩 압축 알고리즘을 사용하여 HPACK 압축 형식을 가집니다.

 

허프만 코딩이란 ?

문자열을 문자단위로 쪼개 빈도수를 세어 빈도가 높은 정보를 적은 비트 수를 사용하여 표현하고,빈도가 낮은 정보를 비트 수를 많인 사용하여 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 원리입니다.

 

서버푸시

 

HTTP1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드받을 수 있었다면 , HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있습니다.

이로써 html에는 css나 js파일이 포함되기 마련인데 html파일을 읽으면서 그 안에 들어 있던 css파일을 서버에 푸시하여 클라이언트에 먼저 줄 수 있습니다.

 

 

HTTPS

HTTP/2는 HTTPS위에서 동작합니다. HTTPS는 애플리케이션 계층과 전송계층 사이에 신뢰계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP요청을 말합니다. 통신을 암호화한다.

 

SSL/TLS은 전송계층에서 보안을 제공하는 프로토콜입니다. 클라이언트와 서버가 통신할 때 SSL/TLS을 통해 제 3자가 메세지를 도청하거나 변조하지 못하도록 합니다.

S

SSL/TLS를 통해 공격자가 서버인 척 하며 사용자의 정보를 가로채는 네트워크상의 "인터셉터"를 방지할 수 있습니다. 

SSL/TLS 는 보안세션을 기반으로 데이터를 암호화하며 보안세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘,해싱알고리즘이 사용됩니다.

 

보안세션이란 ?

보안이 시작되고 끝나는 동안 유지되는 세션을 말하고, SSL/TLS는 핸드셰이크를 통해 보안세션을 생성하고 이를 기반으로 상태 정보를 공유합니다.

 

 

클라이언트와 서버와 키를 공유하고 이를 기반으로 인증합니다. 인증 확인 등의 작업이 일어나는 단 한번의 1-RTT가 생긴 후 데이터를 송신하는 것을 볼 수 있습니다.

 

클라이언트에서 사이퍼 슈트를 서버에 전달하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인합니다. 제공할 수 있다면 서버에서 클라이언트로 인증서는 보내는 인증 메커니즘이 시작되고 이후 해싱 알고리즘 등으로 암호화 된 데이터를 송수신을 시작합니다.

 

사이퍼 슈트란 ?

 프토토콜, 해싱 알고리즘이 나열된 규약을 말합니다.

 

인증매커니즘이란 ?

 

CA(Certificate Authorities)에서 발급한 인증서를 기반으로 이루어집니다. CA에서 발급한 인증서는 안전한 연결을 시작하는데 있어 필요한 공개키를 클라이언트에 제공하고 사용자가 접속한 :"서버가 신뢰"할 수 있다는 서버임을 보장합니다. 인증서는 서비스 정보 ,공개 키 ,지문,디지털 서명등으로 이루어져 있다.

 

CA는 아무기업이나 할 수 있는 것이 아닌 , 신뢰성이 엄격한 공인된 기업들만 참여할 수 있다.

 

CA발급과정

 

자신의 서비스가 CA인증서를 발급받으려면 자신의 사이트 정보와 공개키를 CA에 제출해야합니다. 이후 CA는 공개키를 해시한 값인 지문을 사용하는 CA의 비밀키 등을 기반으로 CA인증서를 발급해줍니다.

 

SHA256 해싱 알고리즘

- 단방향이며 , 해시 함수의 결과값이 256비트인 알고리즘입니다. 복호화 불가능

 

HTTPS 구축방법 3가지 

 

직접 CA에 구매한 인증서를 기반으로 HTTPS 서비스 구축 , 서버 앞단에 HTTPS를 제공하는 로드밸런서 구축 ,서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축

 

HTTPS정리 정말 잘 해놓았다.. 이거보자 대박..! 와이어샤크로 캡처까지...

 

https://nuritech.tistory.com/25

 

HTTPS 통신 원리 쉽게 이해하기 (Feat. SSL Handshake, SSL 인증서)

이 글을 쓰게 된 이유는,, 나의 평소 HTTPS 에 대한 지식은 HTTPS 가 암호화된 네트워크 통신 프로토콜이고 HTTPS 를 사용한 네트워크 통신에서는 주고받는 패킷을 까도 데이터가 암호화되어 있어 안

nuritech.tistory.com

 

간단하게 HTTPS 정리!

 

1. client → server 연결을 시도한다 (Client Hello)
이때, 전송하는 패킷에는 아래의 내용들이 들어있다. (아래 패킷 캡처 참고)

자신(client)이 사용 가능한 cipher suite 목록 (cipher suite 예시 : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA)
이 cipher suite 에 어떤 프로토콜(TLS/SSL)을 사용할지, 인증서 검증 또는 데이터를 어떤 방식으로 암호화할지 등이 표시된다.
session id
ssl protocol version

2. server → client 응답 (Server Hello)
1번에서 클라이언트에서 받은 인사(Client Hello 패킷)에 대해 서버가 응답을 한다. 이 역시 패킷을 찍어보면 Server Hello 라고 나오는 것을 확인할 수 있다.

이때, 서버는 어떤 내용을 담아서 응답하냐면,

클라이언트에서 받은 cipher suite 목록 중 선택한 1개의 cipher suite
ssl protocol version
등등

3. server → client (Certificate,  Server Key Exchange,  Server Hello Done)
이 Certificate 라는 패킷에는 어떤 내용들이 담겨 있냐면, Server 의 SSL 인증서 내용이 들어있다. 아래의 패킷 내부를 보면, 인증서의 signature algorithm, public key info 등을 확인할 수 있다.

보면 Server Key Exchange 가 있는 것을 볼 수 있는데 이건 뭐냐!
위에서 전달한 Certificate 내의 SSL 인증서에 서버의 공개키(public key)가 없는 경우, 서버가 직접 전달함을 의미한다. 즉, 인증서 내부에 서버의 공개키가 존재한다면 Server Key Exchange 는 생략된다!

4. client 에서 server 의 SSL 인증서 검증 

SSL 인증서를 발급한 CA(인증기관)는 CA의 비밀키(private key)를 이용해 인증서를 암호화했다. 그래서 SSL 인증서는 CA의 공개키를 이용해서만 복호화 할 수 있다. 클라이언트는 해당 CA의 공개키를 통해 암호화된 인증서를 복호화 한다. 즉, 클라이언트에서 CA 의 공개키를 이용해 인증서를 복호화했을 때, 복호화가 되었다는 것은 인증서는 해당 CA 에서 발급되었다라는 것을 검증할 수 있는 것.

그렇다면, 클라이언트는 CA 의 공개키를 어디서 구할까?

클라이언트가 브라우저 또는 안드로이드 기기일 경우에는, 인증서를 발급하는 주요 인증기관(CA)의 리스트와 공개키를 가지고 있다. 그래서 매번 CA로 요청하는 것이 아닌 가지고 있는 리스트에서 확인할 수 있다.

그러나, 리스트에 없다면 외부 인터넷을 통해 인증기관의 정보와 공개키를 확보한다. 이것이 SSL 인증서를 사용 시 인터넷 접속이 필요한 이유!

 

🧤 SSL 인증서 검증 정리

클라이언트는 인증서를 발급한 인증기관(CA)의 공개키를 구함.
1번에서 구한 공개키를 이용해 SSL 인증서를 복호화.
복호화 성공 시, 인증서 검증 성공 😇😇


5. client → server 대칭키(비밀키) 전달 (Client Key Exchange, Change Ciper Spec)

이제 클라이언트는 서버와 원하는 데이터를 안전하게 주고받기 위해서는 전달하는 데이터를 암호화해야 한다. 클라이언트는 데이터를 암호화하기 위한 대칭키(비밀키, 데이터를 암호화하는 키)를 생성한다. 

이렇게 생성한 대칭키(비밀키)를 서버에 전달해야 하는데, 그냥 전달하면 큰일 나겠지? 탈취되면 누구나 주고받는 데이터를 볼 수 있을 테니 ^^;

그래서!!!! 클라이언트는 이 대칭키(비밀키)를 서버만 볼 수 있게 하기 위해, 서버의 공개키로 암호화를 해서 서버한테 전달한다. (Client Key Exchange)

6. Server / Client SSL Handshake Finished
서버는 클라이언트가 5번에서 전달한 암호화된 대칭키(비밀키)를 받았다. 이 키는 서버의 공개키로 암호화되었으니, 서버의 비밀키로 복호화해서 얻을 수 있다.

이제 서버와 클라이언트 모두 동일한 대칭키(비밀키)를 갖고 있으니, 통신할 준비 완료 !!!

728x90