본문 바로가기
Study/한빛미디어 - 혼자 공부하는 네트워크

혼공네트 6주차 - 실습, 네트워크 심화(Wireshark 패킷/프로토콜 분석, 다중화, 로드밸런싱, 암호화, 무선 네트워크)

by Dev Lighthouse 2024. 8. 17.
320x100
320x100

시작하기 전에..

내가 직접 씀) 이번 주차에서 나올 Wireshark를 통한 패킷 분석은 개인적으로 집에서만 실시하자

공공장소 또는 회사내에서 패킷 분석을 하는것은 불법이라고 알고 있다

 

독서 & 스터디

패킷 캡처 실습하는 내모습도 흐릿하게...

드디어 마지막주 혼공네트 스터디이다!!

책의 챕터로는 6~7 챕터, 총 2개 챕터를 다룬다

 

6-1 와이어샤크 설치 및 사용법

와이어샤크 설치

맥OS

https://www.wireshark.org/download.html

 

Wireshark · Download

Wireshark: The world's most popular network protocol analyzer

www.wireshark.org

해당 컴퓨터 운영체제/칩셋에 맞는 버전 다운로드

나는 macOS의 Arm 아키텍처 버전을 사용하고 있기때문에 macOS Arm Disk Image로 다운받았다

다운로드 된 파일
다운로드 된 dmg 파일이 열린 모습

 

맨 위에 있는 Wireshark 프로그램 설치 후, 패킷 캡처를 위해 ChmodBPF.pkg도 설치해주자

설치할 프로그램 2가지
완료

 

와이어샤크 사용법

패킷 캡처

특정 wifi의 송수신되는 패킷 그래프

 

Wi-Fi를 선택하면 패킷 캡처링이 시작되면서 와이어샤크의 파란색 아이콘 모양에서 초록색으로 바뀐다

패킷 캡처링 전
패킷 캡처링 중


와이어샤크 화면 구성

전체
구역별 표시

  • 빨간색 부분(상단): 선택한 인터페이스에서 송수신된 패킷들에 대한 정보
    • 패킷 번호(No)
    • 시간(Time)
    • 송신지(Source)
    • 수신지(Destination)
    • 프로토콜(Protocol)
    • 패킷의 길이(Length)
    • 설명(Info)
  • 연두색 부분(우하단): 패킷에 해당하는 실제 데이터 정보
    • 컴퓨터는 0과 1로 이루어짐. 네트워크도 마찬가지
    • 2진수를 그대로 표기하면 표기가 너무 길어지므로 16진수로 줄여서 표기
  • 파란색 부분(좌하단): 해당 패킷이 어떻게 캡슐화되어있는지에 대한 정보
    • TLS(Transport Layer Security)
    • TCP(Transmission Control Protocol)
    • IPv4(Internet Protocol Version 4)
    • Ethernet II(Ethernet)
    • Frame
  • 파란색 부분에서 보면 캡슐화 과정을 하나하나 선택할때마다 우측의 데이터에서 HTTP 메시지에 대한 내용이 강조된다
    아래는 예시를 위해 https말고 http로 다시 필터링한 화면을 녹화해봤다

 

 

패킷 필터링

  • 와이어샤크가 제공하는 기능
  • 아래에 있는 붉은 박스에 필터 조건을 입력하면 필터 조건에 맞는 특정 패킷만 조회

패킷 필터링

필터 종류에 대해서 알아보자~!

책에 나와있는 모두 이 책에서 학습한 반가운 이름들이지요? 라는 말에서 저자분이 드디어 실습이라 신나셨구나..싶었다ㅋㅋ

 

기본 필터

필터 설명
eth Ethernet
ip Internet Protocol Version 4(IPv4)
ipv6 Internet Protocol Version 6(IPv6)
arp Address Resolution Protocol(ARP)
dhcp Dynamic Host Configuration Protocol(DHCP)
rip Routing Infromation Protocol(RIP)
ospf Open Shortest Path First(OSPF)
bgp Border Gateway Protocol(BGP)
icmp Internet Control Message Protocol(ICMP)
tcp Transmission Control Protocol(TCP)
udp User Datagram Protocol(UDP)
dns Domain Name System(DNS)
http Hypertext Transfer Protocol(HTTP)
http2 Hypertext Transfer Protocol Version 2(HTTP2)
http3 Hypertext Transfer Protocol Version 3(HTTP3)
tls Transport Layer Security(TLS)

 

세부적인 필터 - eth 관련 필터

필터 설명
eth.addr 수신지 혹은 송신지 MAC 주소
eth.dst 수신지 MAC 주소
eth.src 송신지 MAC 주소
eth.len 길이(16비트 음이 아닌 정수)
eth.type 타입(16비트 음이 아닌 정수)

 

세부적인 필터 - ip 관련 필터

필터 설명
ip.addr 송신지 혹은 수신지 IPv4 주소
ip.dst 수신지 IPv4 주소
ip.src 송신지 IPv4 주소
ip.flags 플래그 값들(8비트 음이 아닌 정수)
ip.flags.df DF(Don't fragment) 플래그(불리언)
ip.flags.mf MF(More fragments) 플래그(불리언)
ip.frag_offset 단편화 오프셋(16비트 음이 아닌 정수)
ip.hdr_len 헤더 길이(8비트 음이 아닌 정수)
ip.id 식별지(16비트 음이 아닌 정수)
ip.len 총 길이(16비트 음이 아닌 정수)
ip.opt.mtu MTU(16비트 음이 아닌 정수)
ip.ttl TTL(8비트 음이 아닌 정수)

 

세부적인 필터 - udp 관련 필터

필터 설명
udp.port 수신지 혹은 송신지 포트 번호(16비트 음이 아닌 정수)
udp.dstport 수신지 포트 번호(16비트 음이 아닌 정수)
udp.srcport 송신지 포트 번호(16비트 음이 아닌 정수)
udp.length UDP 데이터그램 길이(16비트 음이 아닌 정수)

 

세부적인 필터 - tcp 관련 필터

필터 설명
tcp.port 송신지 혹은 수신지 포트 번호(16비트 음이 아닌 정수)
tcp.dstport 수신지 포트 번호(16비트 음이 아닌 정수)
tcp.srcport 송신지 포트 번호(16비트 음이 아닌 정수)
tcp.seq 순서 번호(32비트 음이 아닌 정수)
tcp.seq_raw 실제 순서 번호(32비트 음이 아닌 정수)
tcp.nxtseq 다음 순서 번호(32비트 음이 아닌 정수)
tcp.ack 확인 응답 번호(32비트 음이 아닌 정수)
tcp.ack_raw 실제 확인 응답 번호(32비트 음이 아닌 정수)
tcp.flags 플래그 값들(16비트 음이 아닌 정수)
tcp.flags.ack ACK 플래그(불리언)
tcp.flags.fin FIN 플래그(불리언)
tcp.flags.syn SYN 플래그(불리언)
tcp.hdr_len 헤더 길이(8비트 음이 아닌 정수)
tcp.len TCP 세그먼트 길이(32비트 음이 아닌 정수)
tcp.window_size_value 윈도우 크기(16비트)
tcp.options.mss_val MSS 값(16비트 음이 아닌 정수)
tcp.analysis.ack_rtt 세그먼트에 대한 ACK까지의 RTT
tcp.analysis.out_of_order 순서가 어긋난 세그먼트
tcp.analysis.retransmission 재전송 세그먼트
tcp.analysis.fast_retransmission 빠른 재전송
tcp.analysis.duplicate_ack 중복된 ACK
tcp.analysis.duplicate_ack_num 중복된 ACK 수(32비트 음이 아닌 정수)

 

세부적인 필터 - http 관련 필터

필터 설명
http.request HTTP 요청(불리언)
http.request.line HTTP 요청 라인(문자열)
http.request.method HTTP 요청 Method(문자열)
http.request.uri HTTP 요청 URI(문자열)
http.request.uri.path HTTP 요청 URI 경로(문자열)
http.request.uri.query HTTP 요청 URI 쿼리(문자열)
http.request.uri.query.parameter HTTP 요청 URI 쿼리 파라미터(문자열)
http.request.version HTTP 요청 버전(문자열)
http.response HTTP 응답(불리언)
http.response.code HTTP 응답 코드(16비트 음이 아닌 정수)
http.response.phrase HTTP 응답 코드 설명(문자열)
http.response.line HTTP 응답 라인(문자열)
http.response.version HTTP 응답 버전(문자열)
http.accept Accept 헤더(문자열)
http.accept_encoding Accept-Encoding 헤더(문자열)
http.accept_language Accept-Language 헤더(문자열)
http.cache_control Cache-Control 헤더(문자열)
http.connection Connection 헤더(문자열)
http.content_encoding Content-Encoding 헤더(문자열)
http.content_length Content-Length 헤더(음이 아닌 64비트 정수)
http.content_type Content-Type 헤더(문자열)
http.date Date 헤더(문자열)
http.host Host 헤더(문자열)
http.location Location 헤더(문자열)
http.last_modified Last-Modified 헤더(문자열)
http.server Server 헤더(문자열)
http.set_cookie Set-Cookie 헤더(문자열)
http.cookie Cookie 헤더(문자열)
http.user_agent User-Agent 헤더(문자열)
http.referer Referer 헤더(문자열)
http.authorization Authorization 헤더(문자열)
http.www_authenticate
 WWW-Authenticate 헤더(문자열)

 

연산자

연산자 설명
== eq 조건을 만족하는 패킷을 선택
!= ne 조건을 만족하지 않는 패킷을 선택
&& and 조건을 모두 만족하는 패킷을 선택
|| or 조건을 하나 이상 만족하는 패킷을 선택
! not 조건에 부합하지 않는 패킷을 선택
> gt 지정한 값을 초과하는 패킷을 선택
< lt 지정한 값보다 작은 패킷을 선택
>= ge 지정한 값보다 크거나 같은 패킷을 선택
<= le 지정한 값보다 작거나 같은 패킷을 선택

 

사용 예

책하고 다르게 실습해봤다

[www.example.com] < 해당 주소의 IP를 알아내야 한다

 

ping/traceroute/nslookup 명령어로 해당 패킷이 향하는 목적지(IP)를 알 수 있다

사실 가장 정확히는 dns로부터 ip를 얻어내는거니깐 dnslookup이 제일 적당한 명령어이긴 하다

  1. ping
ping -c 3 www.example.com

ping 명령어

www.example.com의 주소는 93.184.215.14인 것을 알아 냈다

 

2. traceroute

traceroute www.example.com

traceroute 명령어

www.example.com의 주소는 93.184.215.14인 것을 알아 냈다

 

3. nslookup ✅

nslookup www.example.com

nslookup 명령어

www.example.com의 주소는 93.184.215.14인 것을 알아 냈다

참고로 Non-authorative answer라는 뜻은 도메인의 책임네임서버에서 직접 데이터를 얻은게 아닌, 캐싱되거나 다른 네임서버가 가진 데이터로 응답했다는 의미이다

 

그럼 이제 www.example.com의 443번 포트.  그러니까 https://example.com 으로 향하는 패킷을 필터링해보겠다

tcp.dstport eq 443 && ip.dst eq 93.184.215.14

tcp의 목적지 포트가 443번이고(TLS)

ip의 목적지는 93.184.215.14번으로 가는 패킷만 살펴보겠다는 의미이다

아래는 필터링한 결과이다

와이어샤크 패킷 필터링

 

캡처 파일 저장 & 열기

  • 저장: 파일->저장. 일반적으로 pcap확장자 또는 pcapng확장자로 저장됨
  • 열기: 파일->열기

패킷 캡처 파일

6-2 와이어샤크를 통한 프로토콜 분석

와이어샤크를 통한 프로토콜 분석 실습에서 사용되는 파일들은 저자님의 github에서 파일을 받아서 사용했다

  1. ipv4-fragmentation.pcapng
  2. ipv6-fragmentation.pcapng
  3. 3-way-handshake.pcapng
  4. connection-close.pcapng
  5. tcp-retransmission.pcapng
  6. http-request-response.pcapng

IP 분석

IPv4 단편화 + ICMP

  • 파일열기: ipv4-fragmentation.pcapng

IPv4 + ICMP

  • 분석
    • 1~7번: 10.0.0.1 -> 10.0.0.2 패킷 전송
    • 8~14번: 10.0.0.2 -> 10.0.0.1 패킷 전송
  • IP주된 역할 2가지(1) - IP 주소지정
    • 송신지 IP 주소(Source Address) / 수신지 IP 주소(Destination Address)

IP 주소지정

  • IP주된 역할 2가지(2) - IP 단편화
    • 식별자(Identification) / 플래그(Flags) / 단편화 오프셋(Offset)

IP 단편화 - Frame 1
IP 단편화 - Frame 2

Frame1, 2의 Identification은 같은 주소이므로, 같은 패킷에서부터 단편화되었음을 나타냄

MoreFragments, 즉 MF 플래그이므로 단편화된 패킷이 더 존재하는 것을 알림

Frame1에서는 Offset이 1480이므로, 각 패킷의 데이터는 1480바이트씩 떨어져 있다

 

  • ICMP: 패킷의 전송 과정에 대한 피드백을 얻기 위한 프로토콜. 피드백 메시지의 종류는 ICMP 패킷의 타입+코드 필드의 조합

ICMP - Frame 7

 

ICMP - Frame 14

Frame7은 Type이 8, Code는 0. 이 경우 ICMP 메시지는 에코 요청 메시지

Frame14은 Type 0, Code 0. 이 경우 7번 패킷의 에코 요청에 대한 에코 응답

 

IPv6 단편화 + UDP

  • 파일열기: ipv6-fragmentation.pcapng

IPv6 + UDP

  • 분석
    • 1~2번: 20f4:c750:2f42:53df::11:0 -> 26f7:f750:2ffb:53df::1001 패킷 전송
    • 3~6번: 26f7:f750:2ffb:53df::1001 -> 20f4:c750:2f42:53df::11:0 패킷 전송
  • IPv6 주소 줄여쓰기
    • IPv6 주소는 128비트 크기의 주소 체계
    • 네 개의 16진수가 콜론(:)으로 구분되어 8개의 그룹으로 나뉨
    • 하지만 wireshark에서 나타난 IPv6를 보면 32개의 16진수가 사용되지 않음
    • IPv6의 16진수 일부(0 표기)가 생략된 것
    • 콜론으로 구분된 그룹 앞부분에 0이 연속해서 등장할 경우, 연속된 0은 하나의 0으로 단축할 수 있다
    • 20f4:c750:2f42:53df:0000:0000:0011:0000 -> 20f4:c750:2f42:53df::11:0
    • 여러 필드에 걸쳐 0이 연속해서 등장할 경우 "::"과 같이 필드에 명시되는 0을 생략할 수 있다
    • 26f7:f750:2ffb:53df:0000:0000:0000:1001 -> 26f7:f750:2ffb:53df::1001
  • IPv6 - IP 주소지정
    • 송신지 IPv6 주소(Source Address) / 수신지 IPv6 주소(Destination Address)

  • IPv6 - 단편화
    • Frame 1~2는 Next Header 필드는 캡슐화한 프로토콜인 UDP를 가리키고 있음
    • Frame 3~6는 단편화되어 전송된 패킷으로 단편화 확장 헤더가 포함되어 있음(Fragment Header for IPv6)
      • 확장 헤더: 캡슐화된 UDP, 식별자(Identification), 오프셋(Offset)

Frame 1~2
Frame 3~6

  • UDP 데이터그램
    • User Datagram Protocol - Source Port(송신지 포트) / Destination Port(수신지 포트)

UDP Datagram

TCP 분석

TCP 연결 수립

  • 파일열기: 3-way-handshake.pcapng

3-way handshake

  • 연결 수립 순서: 3-way handshake
    Info 부분에 보면 각 순서마다 어떤 세그먼트 플래그를 받는지 요약해서 볼 수 있다.
    클라이언트 포트(49859)를 보니 동적 포트인 것 또한 확인 가능할 수 있다(대표적으로 웹 브라우저)
    • 클라이언트 연결 요청(192.168.0.1:49859 -> 10.10.10.1:80): SYN 비트가 설정된 세그먼트
    • 서버 연결 요청 확인(10.10.10.1:80 -> 192.168.0.1:49859): SYN + ACK 비트가 설정된 세그먼트
    • 클라이언트 연결 확인(192.168.0.1:49859 -> 10.10.10.1:80): ACK 비트가 설정된 세그먼트

TCP 연결 종료

  • 파일열기: connection-close.pcapng

4-way handshake

  • 연결 종료 순서: 4-way handshake
    • 연결 종료 요청(10.10.10.1 -> 192.168.0.1): FIN + ACK 비트가 설정된 세그먼트 [ 액티브 클로즈 ]
    • 연결 종료 확인(192.168.0.1 -> 10.10.10.1): ACK 비트가 설정된 세그먼트 [ 패시브 클로즈 ]
    • 연결 종료 요청(192.168.0.1 -> 10.10.10.1): FIN + ACK 비트가 설정된 세그먼트 [ 패시브 클로즈 ]
    • 연결 종료 확인(10.10.10.1 -> 192.168.0.1): ACK 비트가 설정된 세그먼트 [ 액티브 클로즈 ]

 

TCP 재전송

  • 파일열기: tcp-retransmission.pcapng

TCP Fast Retransmission - 빠른 재전송 & 회복 알고리즘

  • 빠른 재전송 순서
    • 3번 패킷(2번째 패킷 유실) - TCP Previous segment not captured. 이전 세그먼트를 받지 못했다는 메시지
    • 4번 패킷 - 중복된 ACK 세그먼트 수신(누적 1)
    • 6번 패킷 - 중복된 ACK 세그먼트 수신(누적 2)
    • 8번 패킷 - 중복된 ACK 세그먼트 수신(누적 3)
    • 9번 패킷 - 3번의 중복된 ACK 세그먼트를 수신했기 때문에 빠른 재전송 및 회복 알고리즘 수행 예상
  • 재전송 관련 유용한 필터 3가지
    1. 재전송된 패킷 필터링 - tcp.analysis.retransmission
    2. 빠른 재전송 패킷 필터링 - tcp.analysis.fast_retransmission
    3. 중복된 ACK 세그먼트 필터링 - tcp.analysis.duplicate_ack

중복된 ACK 세그먼트를 필터링 하는 모습

 

 

HTTP 분석

  • 파일열기: http-request-response.pcapng

HTTP 통신 - Request/Response
접속한 웹사이트(세계 최초의 웹 사이트 모습이라고 함)

 

  • HTTP 요청/응답 순서
    • 1번 패킷 - 웹 브라우저로 http://info.cern.ch/에 접속 [ Host: info.cern.ch, HTTP Method: GET ]
    • 2번 패킷 - 응답코드 200. 본문의 Content-Type은 text/html
    • 3번 패킷 - 클라이언트에서 서버의 /hypertext/WWW/TheProject.html로 GET 요청
    • 4번 패킷 - 서버에서 클라이언트로 TCP 통신
    • 5번 패킷 - 3번 패킷에 대한 응답. 응답 상태코드는 200. 서버에서 클라이언트로 html/text 문서를 내려줌
  • \r\n
    • \r: 캐리지 리턴(Carriage Return). 즉 커서를 현재 행의 맨 앞으로 이동하라는 의미
    • \n: 라인 피드(Line Feed). 즉 다음 행으로 커서를 이동하라는 의미
    • 결국 \r\n을 입력하면 다음 행 맨 앞으로 이동하게 됨!!

 

 

7-1 안정성을 위한 기술

가용성

가용성 - Availability

  • 안정성의 정도를 나타내는 용어
  • 컴퓨터 시스템이 특정 기능을 실제로 수행할 수 있는 시간의 비율
  • 컴퓨터 시스템: 서버/네트워크/프로그램 등 다양한 의미로 사용
  • 전체 사용 시간 중에서 정상적인 사용 시간을 의미
  • 정상적인 사용 시간: uptime
  • 정상적인 사용 시간이 불가능한 시간: downtime
  • 가용성을 높이려면? 다운타임을 낮춰야 함

가용성 수식

고가용성 - High Availability

  • 위 수식의 결괏값이 크다는 것은 전체 사용 시간 중에서 대부분을 사용 가능하다는 말과 같음
  • '가용성이 높다'라고 표현
  • 가용성이 높은 성질을 의미
  • HA라고 줄여서 부르기도 함

안정적인 수준

99.999%

  • 수식을 백분율로 표기했을 때 안정적인 수준은 몇 퍼센트인가?
  • 일반적으로 '안정적'이라고 평가받는 시스템은 99.999% 이상을 목표로 함
  • 99.999%라는 수치는 '9가 다섯개'라는 의미에서 '파이브 나인스(Five Nines)'라고도 함
  • 이 수치를 달성하면 시스템이 정상적으로 운영되지 않는 다운타임이 대략 1년에 5.26분, 1개월로 하면 26.3초

퍼센트별 다운타임 수치 테이블

가용성(%) 1년간 다운타임 한 달간 다운타임 한 주간 다운타임
90%(원 나인) 36.53일 73.05시간 16.8시간
99%(투 나인스) 3.65일 7.31시간 1.68시간
99.5% 1.83일 3.65시간 50.4분
99.9%(쓰리 나인스) 8.77시간 43.83분 10.08분
99.95% 4.38시간 21.92분 5.04분
99.99%(포 나인스) 52.56분 4.38분 1.01분
99.999%(파이브 나인스) 5.26분 26.3초 6.05초
99.9999%(식스 나인스) 31.56초 2.63초 0.604초
99.99999%(세븐 나인스) 3.16초 0.262초 0.0604초

 

결함 감내 - Fault Tolerance

  • 서비스가 다운되는 원인은 다양함 => 다운타임의 발생 원이르 모두 찾아 원천적으로 차단하기는 현실적으로 어려움
    • 과도한 트래픽
    • 예기치못한 소프트웨어상의 오류
    • 하드웨어 장애
    • 보안 공격
    • 자연 재해
  • 핵심: 문제가 발생하지 않도록 하는게 아니라, 문제가 발생하더라도 계속 기능할 수 있도록 설계하는 것
  • 문제가 발생하더라도 기능할 수 있는 능력을 결함 감내(fault tolerance)라 부름
  • 다운타임을 낮추고 가용성을 높이기 위해서는 결함을 감내할 수 있도록 서비스나 인프라를 설계하는 것이 중요!!

 

이중화

이중화 - Duplex, Duplication

  • 무언가를 이중으로 두는 기술
  • 결함을 감내하여 가용성을 높이기 위한 가장 기본적이고 대표적인 방법
  • '예비(백업)을 마련하는 방법'
  • 이중화할 수 있는 대상
    • 서버 컴퓨터
    • 네트워크 인터페이스(NIC)
    • 스위치
    • 데이터베이스
    • 웹 서버 프로그램
  • 이중화할 수 있는 대상들의 공통점: '문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상'

단일 장애점 - SPOF(Single Point Of Failure)

  • 문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상 <
  • SPOF는 최대한 없애는 것이 좋음
  • 즉, 가용성을 높이기 위해서는 SPOF를 이중화하는 것이 좋음

액티브/스탠바이 - Active/Standby

  • 액티브: 가동 상태
  • 스탠바이: 액티브의 백업으로서 대기하는 상태
  • 액티브/스탠바이: 한 시스템은 가동하고, 다른 시스템은 백업 용도로 대기 상태(스탠바이)로 두는 이중화 구성 방식
  • 액티브 상태인 시스템에 문제가 발생할 경우 스탠바이 시스템이 자동으로 액티브 시스템을 대신하여 동작
  • 하나의 장비의 장비를 사용할 때에 비해 성능상의 큰 변화를 기대하기는 어려움
    (두 장비가 동시에 가동되지 않고 한 번에 하나만 가동되기 때문)

페일오버 - Failover

  • 액티브 시스템에 문제가 생겼을 경우, 예비된 스탠바이 시스템으로 자동 전환되는 기능

액티브/액티브 - Active/Active

  • 액티브/액티브: 두 시스템 모두를 가동 상태로 두는 구성 방식
  • 두 시스템 모두를 가동 상태로 두는 액티브/액티브로 이중화하면 두 시스템이 함께 가동되므로 성능상의 이점도 있음
  • 한 시스템에 문제가 발생하면 순간적으로 다른 시스템에 부하가 급증할 수 있으며, 이로 인해 추가적인 문제가 발생할 수 있음

다중화 - Redundancy

  • 이중화 기술이 더욱 확장된 개념
  • 이중화 - '무언가를 이중으로 두는 기술'
  • 다중화 - '무언가를 여러개로 두는 기술'
  • 오늘날 많은 사용자가 이용하는 거의 모든 서비스는 하나 이상의 시스템이 다중화되어 구성됨

티밍 - Teaming

  • 이중화/다중화의 사례
  • 주로 윈도우에서 사용되는 용어
  • 여러 개의 네트워크 인터페이스(NIC)를 이중화/다중화하여 마치 더 뛰어나고 안정적인 성능을 보유한 하나의 인터페이스처럼 보이게 하는 기술
  • 티밍 시에 액티브/액티브, 액티브/스탠바이로 구성할지 선택 가능
  • ex) 3개의 NIC(1Gbps)를 모두 액티브 상태로 구현할 경우 마치 3Gbps 인터페이스를 사용하는 것과 같은 효과를 얻음

본딩 - Bonding

  • 이중화/다중화의 사례
  • 주로 리눅스에서 사용되는 용어
  • 여러 개의 네트워크 인터페이스(NIC)를 이중화/다중화하여 마치 더 뛰어나고 안정적인 성능을 보유한 하나의 인터페이스처럼 보이게 하는 기술
  • 나머지 설명은 위와 동일

 

로드 밸런싱

고가용성을 요구하는 호스트는 클라이언트보다는 일반적으로 서버

서버의 입장에서의 가용성: 트래픽 분배

 

트래픽 - Traffic

  • 사전적 정의: 주어진 시점에 네트워크를 경유한 데이터의 양
  • 일반적 표현: 주어진 시점에 특정 노드를 경유한 패킷의 양
  • 서버에 과도한 트래픽이 몰린다면 (서버의 가용성을 떨어뜨림)
    • 높은 부하로 인해 CPU 발열 상승
    • 메모리 공간 부족
    • 제한된 대역폭과 병목 현상으로 인해 응답이 느려짐
    • 일부 요청에 대한 응답이 누락
    • 프로그램의 일관성이 손상
  • 특정 서버에만 트래픽이 몰릴 경우 가용성이 떨어짐
  • 서버를 다중화했더라도 트래픽을 고르게 분산해야 가용성이 높아짐

로드 밸런싱 - Load Balancing

  • 트래픽의 고른 분배를 위해 사용되는 기술
  • 부하(Load) + 균형 유지(Balancing)
  • 로드밸런싱은 로드밸런서에 의해 수행됨

로드 밸런서 - Load Balancer

로드밸런서

  • 로드밸런싱을 담당하는 주체
  • 'L4, L7 스위치'라 불리는 네트워크 장비로 로드밸런서 역할 가능
    • L4 스위치 - 주로 IP주소와 포트번호와 같은 전송계층까지의 정보를 바탕으로 로드밸런싱을 수행
    • L7 스위치 - URI, HTTP 메시지 일부, 쿠키 등 응용 계층의 정보까지 활용하여 로드밸런싱을 수행
  • 로드밸런싱 기능을 제공하는 소프트웨어를 설치하면 일반 호스트도 로드밸런서로 사용 가능
  • 대표적인 소프트웨어: HAProxy, Envoy, Nginx
  • 로드밸런서는 일반적으로 이중화나 다중화된 서버와 클라이언트 사이에 위치
  • 클라이언트들은 로드 밸런서에 요청을 보내고, 로드 밸런서는 해당 요청을 각 서버에 균등하게 분배

헬스체크 - Health Check

  • 다중화된 서버 환경에서 어떤 서버에 문제가 생긴다면 다른 서버들이 이를 빠르게 감지할 수 있어야 함
  • 다중화된 서버 환경에서는 현재 문제가 있는 서버는 없는지, 현재 요청에 대해 올바른 응답을 할 수 있는 상태인지를 주기적으로 검사하는 것을 헬스 체크(health check)라고 함
  • 서버들의 건강 상태를 주기적으로 모니터링하고 체크하는 것
  • 헬스 체크는 주로 로드밸런서에 의해 이루어지는 경우가 많으며, HTTP/ICMP 등 다양한 프로토콜을 활용할 수 있음

하트비트(heartbeat)

  • 로드밸런서가 주도하는 헬스 체크 이외에 서버간에 heartbeat 메시지를 주고받는 방법도 존재
  • 서버끼리 주기적으로 하트비트 메시지를 주고받다가, 신호가 끊겼을 때 문제 발생을 감지하는 방법

로드 밸런싱 알고리즘

로드 밸런서가 요청을 전달할 수 있는 서버가 여러 개 있을 경우, 어떤 서버에 요청을 전달할지, 어떤 서버를 선택해야 부하가 고르게 분배될지, 부하가 균등하게 분산되도록 부하 대상을 선택하는 방법

 

라운드 로빈 알고리즘 - Round Robin Algorithm

  • 단순히 서버를 돌아가며 부하를 전달하는 알고리즘

최소 연결 알고리즘 - Least Connection Algorithm

  • 연결이 적은 서버부터 우선적으로 부하를 전달하는 알고리즘

IP 해싱 방식 - IP Hash Algorithm

  • client IP를 해싱한 값을 사용해서 부하를 분산하는 알고리즘

최소 응답 시간 방식 - Least Response Algorithm

  • 응답 시간이 가장 짧은 서버를 선택하는 알고리즘

 

로드 밸런싱 알고리즘 - 가중치

서버마다 가중치(weight)를 부여해서, 가중치가 높은 서버가 더 많이 선택되어 더 많은 부하를 받게 하는 알고리즘

 

가중치 라운드 로빈 알고리즘 / 가중치 최소 연결 알고리즘

가중치 라운드로빈 알고리즘

 

 

더더 알아보기~!(책에는 없는 내용)

  • AWS에서 나온 설명으로 LB에 대해서 알아보자

https://aws.amazon.com/ko/what-is/load-balancing/

 

로드 밸런싱이란 무엇인가요? - 로드 밸런싱 알고리즘 설명 - AWS

로드 밸런싱이란 무엇인가요? 로드 밸런싱은 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법입니다. 최신 애플리케이션은 수백만 명의 사용자를 동시에

aws.amazon.com

에 나와 있는 정보로 ALB/NLB 차이와

AWS - ELB, ALB, NLB, GLB, CLB 등의 차이점도 알아보자~

 

Load Balancing 종류

en
ko

 

AWS에서 지원하는 Load Balancing 종류

en
ko

포워드 프록시 & 리버스 프록시

처음 네트워크를 학습할 때는 단순화를 위해 클라이언트와 서버가 나란히 붙어 있는 것처럼 서술하는 경우가 많지만, 실제로는 클라이언트와 서버 사이에는 수많은 서버들이 존재할 수 있음

중간 서버, 오리진 서버, 인바운드/아웃바운드 메시지

 

오리진 서버 - Origin Server

  • 자원을 생성하고 클라이언트에게 권한 있는 응답을 보낼 수 있는 HTTP 서버

인바운드(inbound) 메시지

  • 오리진 서버로 향하는 메시지(클라이언트 -> 오리진 서버)

아웃바운드(outbound) 메시지

  • 클라이언트로 향하는 메시지(오리진 서버 -> 클라이언트)

HTTP 중간 서버

  • 프록시(포워드 프록시) - Proxy(Forward Proxy) 
    • 프록시는 클라이언트가 선택한 메시지 전달 대리자
    • 프록시를 언제 어떻게 사용할지는 클라이언트가 선택
    • 따라서, 일반적으로 프록시는 오리진 서버보다 클라이언트와 더 가까이 위치함
    • 주로 캐시 저장, 클라이언트 암호화 및 접근 제한 등의 기능 제공
    • 추가) 소프트웨어: Squid, Privoxy, Shadowsocks, Fiddler, Charles Proxy

포워드 프록시

 

  • 게이트웨이(리버스 프록시) - Gateway(Reverse Proxy)
    • 게이트웨이는 아웃바운드 연결에 대해 오리진 서버 역할을 하지만, 수신된 요청을 반환하여 다른 인바운드 서버(들)로 전달하는 중자 역할을 함
    • 네트워크 외부에서 보면 오리진 서버와 같이 보임
    • 하지만 게이트웨이에 요청을 보내면 오리진 서버에게 요청을 전달하게 됨
    • 따라서, 일반적으로 게이트웨이는 오리진 서버(들)에 더 가까이 위치함
    • 게이트웨이도 캐시를 저장할 수 있고, 로드 밸런서로 동작할 수 있음
    • 추가) 소프트웨어: Nginx, Apache HTTP Server (mod_proxy 모듈 사용), Traefik, Caddy, Envoy, Kong, Istio

게이트웨이(리버스 프록시)

 

포워드 프록시 & 리버스 프록시 둘다 지원하는 소프트웨어

  • Nginx, Squid, Apache HTTP Server

 

다중화된 오리진 서버들의 네트워크를 '오리진 서버들이 사는 대저택'에 비유

- 프록시: 클라이언트를 대신해 대저택에 심부름을 가는 심부름꾼

- 게이트웨이: 대저택을 지키는 경비

 

7-2 안정성을 위한 기술

암호와 인증서

암호화 - Encryption

  • 원문 데이터를 알아볼 수 없는 형태로 변경하는 것

복호화 - Decryption

  • 암호화된 데이터를 원문 데이터로 되돌리는 과정

대칭 키 암호화 - Symmetric Key Cryptography

  • 암호화와 복호화에 동일한 키를 사용함
  • 한계점 - 상대방에게 안전하게 키를 전달하기가 어려움
  • 키가 유출되면 큰 문제가 발생 - 상대방에게 키를 안전하게 전달하는 방법 필요

공개 키 암호화 - Public Key Cryptography / 비대칭 키 암호화 - Asymmetric Key Cryptography

  • 암호화에 사용하는 키와 복호화에 사용하는 키는 다른 키를 사용
  • 이 한쌍의 키를 공개키(public key), 개인키(private key)라고 부름
  • 공개 키만으로 개인 키를 유추할 수 없고, 반대로 개인 키만으로 공개 키를 유추할 수 없음(큰 두 소수 사용. 이산 로그 문제)
  • 공개 키로 원문을 암호화하고, 개인키 로 암호문을 복호화

장단점

  • 대칭 키 암호화
    • 키를 안전하게 전송하기 어렵지만, 적은 부하 덕분에 암/복호화를 빠르게 수행 가능
  • 공개 키 암호화
    • 암/복호화에 시간과 부하가 상대적으로 많이 들지만, 키를 안전하게 공유 가능

세션 키 - Session Key

  • 여러 장단점을 고려해 대칭 키 암호와 공개 키 암호화 방식을 함께 사용하는 경우가 많음
  • ex) 대칭 키를 상대에게 안전하게 전달하기 위해 공개 키로 대칭 키를 암호화하고, 개인 키로 암호화된 대칭 키를 복호화
  • 위와같은 방식으로 활용되는 대칭 키를 세션 키라고 부름

 

인증서와 디지털 서명

인증서 - Certificate

  • 무엇인가를 증명하기 위한 문서

공개키 인증서 - Public Key Certificate

  • 네트워크(인터넷)에서 사용되는 '인증서'의 일반적 의미
  • 공개 키와 공개 키의 유효성을 입증하기 위한 전자 문서

인증 기관 - CA(Certification Authority)

  • 인증서를 발급해주는 제3의 공인 기관
  • 인증서의 발급, 검증, 저장과 같은 역할을 수행
  • 일반적으로 CA라고 줄여서 부름
  • 전 세계적으로 다양한 CA들이 존재
  • 대표적으로 IdenTrust, DigiCert, GlobalSign 등이 있음

서명 값 - Signature

  • CA가 발급한 인증서에 존재하는 보증값
  • '이 공개 키 인증서는 진짜야. 내가 보증할게'라는 내용을 담은 서명값
  • 클라이언트는 이 서명 값을 바탕으로 인증서 검증 가능
  • 서명 만드는 방식
    1. 인증서 내용에 대한 해시 값을
    2. CA의 개인 키로 암호화
    3. CA는 이 정보를 서명 값으로 삼아 클라이언트에게 인증서와 함께 전송

지문 - Fingerprint

  • 인증서 내용에 대한 해시값을 지문(fingerprint)라 함

디지털 서명 - Digital Signature

  • 개인 키로 암호화된 메시지를 공개 키로 복화함으로써 신원을 증명하는 절차

 

HTTPS: SSL, TLS

SSL - Secure Sockets Layer

  • 대칭 키/공개 키/공개 키 인증서를 기반으로 동작하는 프로토콜
  • 인증과 암호화를 수행하는 프로토콜
  • SSL 2.0(1.0은 미출시)
  • SSL 3.0

TLS - Transport Layer Security

  • 대칭 키/공개 키/공개 키 인증서를 기반으로 동작하는 프로토콜
  • 인증과 암호를 수행하는 프로토콜
  • TLS 1.0
  • TLS 1.1
  • TLS 1.2
  • TLS 1.3 출시 - 오늘날 주로 사용

HTTPS

자물쇠 모양 - https://www.naver.com
자물쇠 모양 - 이 연결은 안전합니다(티스토리)

 

SSL/TLS를 사용하지 않는 HTTP 프로토콜

  • SSL/TLS를 사용하는 대표적인 프로토콜
  • HTTP 메시지의 안전한 송수신을 위해 개발된 프로토콜

HTTPS 동작 과정(feat. TLS 1.3 handshake)

  • TCP 3-way handshake
  • TLS handshake
  • 암호화된 메시지 송수신

TLS handshake 핵심 2가지

  1. 암호화 통신을 위한 키 교환
  2. 인증서 송수신과 검증

TLS handshake

TLS 핸드셰이크

  1. 클라이언트 to 서버: ClientHello 메시지 전송 - 암호화 이전에 맞춰봐야할 정보들을 제시하는 메시지
    (지원되는 TLS 버전, 사용 가능한 암호화 방식, 해시 함수, 키를 만들기 위해 사용할 클라이언트의 난수 등이 포함)
  2. 서버 to 클라이언트: ClientHello에 대한 응답으로 ServerHello 메시지 전송 - 제시된 정보들을 선택하는 메시지
    (선택된 TLS 버전, 암호 스위트 정보, 키를 만들기 위해 사용할 서버의 난수 등이 포함)
  3. 1번과 2번에서 서로 협의된 정보를 토대로 암호화에 사용할 키를 생성(키 교환)
  4. 3단계 이후부터 클라이언트와 서버는 키로 암호화된 암호문을 주고받을 수 있음
  5. 서버 to 클라이언트: ServerHello 메세지와 함께 Certificate, CertificateVerify 메시지 전송
    (각각 인증서와 검증을 위한 디지털 서명을 의미)
  6. 서버 to 클라이언트: 5번 메시지 + Application Data(암호화된 메시지)와 함께 TLS 핸드셰이크의 마지막을 의미하는 Finished 메시지 또한 전송
  7. 클라이언트 to 서버: Application Data(암호화된 메시지) + Finished 메시지 함께 전송
  8. 서버 to 클라이언트 / 클라이언트 to 서버: Application Data(암호화된 메시지) 주고받음

암호 스위트(cipher suite)

  • 사용 가능한 암호화 방식과 해시 함수를 담은 정보

 

7-3 무선 네트워크

7장 첫 부분

책에서 볼 수 있는 저자분의 라이브 집필(like 라이브 코딩) 설명 ㅋㅋ

 

전파와 주파수

전파 - Radio Wave

  • 무선네트워크를 이해하기 앞서, 무선통신의 기반이 되는 전파를 알아야 함
  • 약 3kHz ~ 3THz 사이의 진동수를 갖는 전자기파
  • 눈에 보이지 않는 전자기파의 일종
  • 자연적으로도 발생할 수 있음

주파수 대역

  • 많은 기기가 전파를 통해 통신하는 경우, 신호 혼재를 방지하기 위해 미리 설정된 대역값
  • 서로 다른 전파 신호를 구분할 수 있는 방법 - 주파수 대역
  • 주파수 대역을 어떤 용도로 사용할지는 나라마다 다름
  • 방송용, 위성 통신용, 항공/해상 통신용 주파수 등으로 나뉘어짐
  • 번개/태양의 활동 등으로 인해 발생한 전파의 주파수가 현재 사용하고 있는 주파수 대역과 겹칠 경우 통신 중 잡음이 발생하기도 함

 

와이파이(Wi-Fi)와 802.11

IEEE 802.3과 IEEE 802.11

  • 오늘날 LAN 환경에서의 유선 통신은 IEEE 802.3으로 표준화되어 있음
  • 오늘날 LAN 환경에서의 무선 통신은 IEEE 802.11로 표준화되어 있음
  • IEEE 802.11 표준은 대부분 2.4GHz, 5GHz 대역을 사용

IEEE 802.11 규격에 따른 주파수 대역과 최대 전송 속도

표준 규격 주파수 대역 전송 속도
IEEE 802.11a 5GHz 54Mbps
IEEE 802.11g 2.4GHz 54Mbps
IEEE 802.11n 2.4/5GHz 450Mbps
IEEE 802.11ac 5GHz 6.9Gbps
IEEE 802.11ax 2.4/5/6GHz 9.6Gbps
IEEE 802.11be 2.4/5/6GHz 46.1Gbps

 

나도 현재 졸업한 학교인 광운대학교 도서관에서 블로깅을 하는 중인데.. 어떤 규격을 사용하는지 확인해봤다

802.11ax 규격을 사용중인 것을 확인할 수 있었다!!

802.11ax

 

변조 - Modulation

  • 정보를 원하는 형태의 신호로 변환하는 것

복조 - deModulation

  • 변조된 신호를 원래의 정보로 다시 변환하는 것

와이파이 - Wi-Fi

  • 오늘날 IEEE 802.11 표준을 따르는 무선 LAN 기술을 가리키는 말로도 많이 사용됨
  • 하지만, 본래는 와이파이 얼라이언스(Wi-Fi Alliance)라는 비영리단체의 트레이드마크(브랜드) 이름
  • Wi-Fi 세대의 의미: 특정 802.11 규격을 준수하는 기술
세대 이름 표준 규격
Wi-Fi 7 IEEE 802.11be
Wi-Fi 6 IEEE 802.11ax
Wi-Fi 5 IEEE 802.11ac
Wi-Fi 4 IEEE 802.11n

 

2.4GHz vs 5GHz. 어느 것이 더 좋을까?

  • 상황에 따라 다르다
  • 2.4GHz: 속도는 5GHz보다 느리지만, 장애물의 영향을 덜 받아서 신호가 멀리까지 잡힘
  • 5Ghz: 속도는 2.4GHz보다 빠르지만, 장애물의 영향을 받아서 신호가 짧음
  • 주파수에 따른 회절성 때문
  • 회절성: 파동이 장애물이나 좁은 틈을 통과할 때, 파동이 그 뒤편까지 전파되는 현상
  • 상대적으로 낮은 주파수는 회절성이 좋지만, 높은 주파수는 회절성이 낮음
  • 결론: 장애물이 많다면 2.4GHz 와이파이를 이용, 장애물이 적다면 5GHz 이용

채널 - Channel

  • 같은 주파수 대역(2.4GHz, 5GHz)를 사용하는 네트워크라 할지라도 별개의 무선 네트워크들이 존재 가능(n개 사용)
  • 같은 대역을 사용할지라도 별개의 무선 네트워크는 서로의 신호에 간섭하지 않아야 함
  • 그래서 2.4GHz, 5GHz 주파수 대역은 채널이라 불리는 하위 주파수 대역으로 또 한 번 세분화되고, 해당 채널 대역에서 통신함
  • 통신 주파수 대역을 채널로 간주하는 것
  • 채널에는 번호가 할당되어 있음
  • 2.4GHz: 1,2,3,4,5,6,7,8,9,10,11,12
  • 5GHz: 36,40,44,48
  • 채널은 일반적으로 자동으로 설정되지만, 수동으로도 설정 가능
  • 내가 덧붙임) 예전에 고딩때 집에서 게임을 하다가 와이파이가 신호가 약할 때 구글링해봤었는데.. 공유기 설정 사이트 들어가서 와이파이 채널을 바꾸라고 나와있었는데.. 그게 이거군!! 하고 생각했다(경험적으로 떠올려서 기억에 더 오래남기기ㅋ)

 

AP와 서비스 셋

무선 네트워크 관련 네트워크 장비

 

AP - Access Point

  • 무선 네트워크를 생성하기 위해서 필요한 장비
  • AP(Access Point)는 무선 통신 기기들을 연결하여 무선 네트워크를 구성하는 장치
  • 가정에 무선 공유기가 있다면, 그것이 AP 역할을 수행하는 장치라고 볼 수 있음
  • 일반적으로 AP에는 유선 연결 매체를 연결할 수 있는 지점이 함께 제공되어 유/무선 네트워크 연결을 담당하는 역할도 수행할 수 있음

인프라스트럭처 모드 - Infrastructure mode

  • 무선 LAN의 기기들은 AP를 공유해 인터넷에 접속하거나 서로 메시지를 주고받을 수 있음
  • 다시 말해, AP는 무선 LAN에서 통신을 중개하는 역할을 수행
  • AP를 경유하여 통신이 이루어지는 무선 네트워크 통신 방식을 인프라스트럭처 모드라 지칭
  • 오늘날 많은 무선 LAN이 AP가 중개하는 인프라스트럭처 모드로 동작

애드 혹 모드 - Ad Hoc mode

  • AP간의 간섭 없이 호스트간 1:1로 통신하는 무선 통신 모드

서비스 셋 - Service Set

  • AP를 중심으로 연결된 여러 장치가 무선 네트워크를 형성
  • 무선 네트워크를 이루는 AP와 여러 장치들의 집합을 서비스 셋이라 부름
  • 같은 서비스 셋에 속한 장치들은 같은 무선 네트워크에 속한다고 볼 수 잇음

서비스 셋 식별자 - SSID(Service Set IDentifier)

  • 각기 다른 서비스 셋을 구분할 수 있는 수단이 필요
  • 서비스 셋을 식별하기 위해 SSID를 사용
  • SSID는 무선 네트워크를 구분짓는 수단이자 무선 네트워크를 지칭하는 고유한 이름
  • 와이파이 이름이 바로 SSID

오~ 광운대 도서관 와이파이 달아놓은 사람 SSID라고 문앞에 붙여놓다니.. 네트워크 쫌 아시는분인듯..?

 

BSS / ESS

  • 인프라스트럭처 모드로 구성된 무선 LAN은 하나의 AP만으로 구성될 수도 있고, 여러 AP로도 구성될 수 있음
  • BSS(Basic Service Set): 하나의 AP로 구성된 무선 LAN
  • ESS(Extended Service Set): 여러 AP로 구성된 무선 LAN

아까 확인했던 Wi-Fi를 보니깐 내가 있는 곳은 BSS인가보다!!

BSS + IDentifier로 해서 BSSID값이 보이나보다

1개의 AP로 구성되어있구만 광운대 도서관..ㅋ

BSSID

비컨 프레임 - Beacon Frame

  • AP는 외부에 자신의 존재를 지속해서 알려야 함
  • AP가 자신의 존재를 알리지 않는다면 호스트는 연결 가능한 무선 네트워크가 존재한다는 사실조차 알 수 없기 때문
  • AP는 불특정 다수에게 자신을 알리는 브로드캐스트 메시지를 주기적으로 전송
  • 이 브로드캐스트 메시지를 비컨 프레임이라 함
  • 우리가 핸드폰을 켜서 와이파이 신호를 켜고 목록을 볼 수 있는 것도 내 핸드폰이 AP로부터 비컨 프레임을 받았기 때문!!! 신기하군

서비스 메시 - Service Mesh [ 책에는 없어서 내가 추가해본 것! ]

종종 서비스 메시라는 말을 들어왔을 것이다. MSA 환경을 구축하고 있거나, 구축되어 있는 회사에 다니는 사람들이라면 들어봤을 법한 용어! 그래서 추가 해봤다

  • 정의: 마이크로서비스 간의 통신을 관리하고 제어하기 위해 사용되는 인프라 계층
  • 기능: 서비스 메시를 통해 서비스 간의 트래픽을 제어하고, 서비스 간의 보안, 모니터링, 로깅 등
  • 목적: 마이크로서비스 환경에서 각 서비스 간의 통신을 더욱 세밀하게 제어하고, 이를 통해 애플리케이션의 안정성, 보안성, 가시성을 높이는 것
  • 특징
    • 서비스 메시의 핵심 구성 요소는 사이드카 프록시임
    • 이 프록시는 각 마이크로서비스 인스턴스에 부착되어 트래픽을 가로채고, 제어하며, 정책을 적용
    • Istio, Linkerd, Consul Connect 등이 대표적인 서비스 메시 솔루션

 

숙제

Ch.06(06-2) 확인 문제 1번(p.379), (07-2) 확인 문제 2번(p.407) 풀고 설명하기

Q. 다음은 호스트 A와 B간의 쓰리 웨이 핸드셰이크 과정에서 호스트 A가 호스트 B에게 전송한 첫 번째 SYN 세그먼트의 일부입니다. 쓰리 웨이 핸드셰이크상에서 호스트 B가 호스트 A에게 전송할 다음 세그먼트의 Acknowledgment number(raw)는 무엇일까요?

문제 사진

A. 3588415413(3588415412 + 1)
 
ACK는 SEQ number 에 대한 응답이다

 
 
Q. 다음 그림은 두 호스트가 TLS 1.3 핸드셰이크를 수행하는 과정을 나타낸 그림 일부입니다. 괄호 안에 들어갈 TLS 관련 메시지로 알맞은 말을 골라 보세요.

문제 사진

1) Application Data
2) ARP Request
3) ServerHello
4) Finished

 

A. 3번
 
암호화된 통신을 위해 보낸 ClientHello에 대한 응답으로 ServerHello를 응답한다

 

추가숙제

와이어샤크에서 실제 TCP/UDP 패킷 확인해 보기

  • tcp 또는 udp 프로토콜만을 보기 위해 tcp || udp 필터를 걸어서 확인해봤다

TCP or UDP


 

후기

드디어 한빛미디어에서 진행한 혼공학습단 12기 혼자공부하는 네트워크의 6주차를 마무리지었다

7월 1일부터 8월 18일까지!! 여름방학 1주까지 합하면 총 7주간 진행된 스터디였다

2024년 여름을 제대로 불태운 스터디였던 것 같다(아직도 여름은 현재진행형... 💦)

이번 챕터도 정말 배운게 많았다. 실습 위주라 좋았고, 알고 있던 개념을 더 채울 수 있었다

한 가지 아쉬운 점을 덧붙이자면 블루투스 통신에 대해서는 나오지 않은 점이다! 이건 내가 알아봐야지~(원영적 사고)

전체적인 혼공 스터디의 회고는 다음 글로, 좀 더 디테일하게 작성해볼 예정이다

 

책 구매처

https://www.yes24.com/Product/Goods/125830483

 

혼자 공부하는 네트워크 - 예스24

혼자 해도 충분하다!1:1 과외하듯 배우는 네트워크 자습서『혼자 공부하는 네트워크』는 개발자의 필수 지식인 네트워크를 기본부터 제대로 학습할 수 있도록 돕는 입문서이다. 다수의 네트워

www.yes24.com

 

 
 

저작자표시 비영리 동일조건

'Study > 한빛미디어 - 혼자 공부하는 네트워크' 카테고리의 다른 글

혼공학습단 12기 활동회고록 - [혼공네트]  (2) 2024.08.18
혼공네트 5주차 - 응용 계층(DNS, URI/URL, HTTP Message, HTTP Header, 캐시, 쿠키, 콘텐츠 협상)  (0) 2024.08.13
혼공네트 4주차 - 전송 계층(Port, NAPT, ICMP, TCP, UDP, 3-way handshake, 오류/흐름/혼잡 제어)  (0) 2024.07.28

관련글

댓글

티스토리툴바