서린이의 기술 블로그

1. ARP,  DHCP

1. ARP 요청 (Address Resolution Protocol)
정의: ARP는 IP 주소를 MAC 주소로 변환하는 프로토콜입니다.
작동 방식:
ARP 요청: 특정 IP 주소에 해당하는 MAC 주소를 찾기 위해 해당 IP 주소를 가진 장치에게 브로드캐스트 요청을 보냅니다.
ARP 응답: 요청한 장치가 자신의 MAC 주소를 포함한 응답을 보내면, 송신자는 이 정보를 캐시에 저장합니다.
용도: 네트워크에서 데이터를 전송하기 위해 필요한 MAC 주소를 찾는 데 사용됩니다.

2. DHCP Discover (Dynamic Host Configuration Protocol)
정의: DHCP는 네트워크에 연결된 장치에 IP 주소와 기타 네트워크 설정을 자동으로 할당하는 프로토콜입니다.
작동 방식:
DHCP Discover: 새로운 장치가 네트워크에 연결되면, DHCP 서버를 찾기 위해 브로드캐스트 메시지를 보냅니다.
DHCP Offer: DHCP 서버가 해당 요청을 수신하면, 사용 가능한 IP 주소와 설정 정보를 포함한 응답을 보냅니다.
DHCP Request: 장치는 제공받은 정보를 바탕으로 특정 IP 주소를 요청합니다.
DHCP Acknowledgment: DHCP 서버가 요청을 확인하고 IP 주소를 할당합니다.
용도: 네트워크에 자동으로 IP 주소를 할당하여 관리의 편리함을 제공합니다.

- 요약
ARP 요청: IP 주소를 MAC 주소로 변환하기 위한 요청.
DHCP Discover: 네트워크 장치가 DHCP 서버에 IP 주소를 요청하는 첫 단계.

2. 데이터센터 네트워크의 특징

- 데이터센터 네트워크의 특징
고속 데이터 전송: 데이터센터 네트워크는 대량의 데이터를 빠르게 전송하기 위해 고속 링크(예: 10Gbps, 40Gbps, 100Gbps)를 사용합니다.
스케일 아웃 아키텍처: 수많은 서버와 스토리지를 수평적으로 확장할 수 있는 구조로 설계되어 있습니다.
고가용성: 장애 발생 시에도 서비스가 중단되지 않도록 이중화 및 페일오버 기능이 구현되어 있습니다.
가상화 지원: 서버와 네트워크 자원을 가상화하여 효율적으로 관리하고, 자원 할당을 동적으로 조정합니다.
소프트웨어 정의 네트워킹(SDN): 네트워크 관리와 제어를 소프트웨어로 구현하여 유연성과 자동화를 제공합니다.

- 네트워크 토폴로지 전략
동일 랙이 아닌 바로 옆 랙으로 대용량 트래픽이 발생해야 할 경우, 리프-스파인 토폴로지를 고려할 수 있습니다. 이 구조는 다음과 같은 장점을 제공합니다:
저지연성: 모든 서버가 스파인 스위치를 통해 직접 연결되어 있어 트래픽이 효율적으로 전달됩니다.
확장성: 필요에 따라 리프나 스파인 스위치를 추가하여 쉽게 확장할 수 있습니다.
고가용성: 각 노드가 여러 경로를 통해 연결되어 있어 장애에 강합니다.

- 내부 네트워크 트래픽 계산
10 페타바이트의 백엔드 스토리지가 있다고 가정할 때, 내부 네트워크 트래픽은 여러 요소에 따라 다르지만, 일반적으로 스토리지와 컴퓨팅 노드 간의 트래픽은 다음과 같이 계산할 수 있습니다:

I/O 작업 수: 스토리지에 대한 읽기/쓰기 요청 수.
데이터 전송량: 각 요청에 대해 전송되는 데이터의 양.

예시: 만약 하루에 1000회의 I/O 작업이 발생하고 각 작업에서 1GB의 데이터가 전송된다면,
내부 트래픽 = 1000 * 1GB = 1000GB = 1TB.

- 스토리지와 네트워크, 컴퓨팅 노드 간의 분산 전략

데이터 분산: 데이터를 여러 스토리지 노드에 분산 저장하여 I/O 부하를 분산시킵니다.
로컬 캐싱: 자주 사용되는 데이터를 캐싱하여 빠른 접근을 가능하게 합니다.
로드 밸런싱: 트래픽을 여러 경로로 분산시켜 네트워크의 과부하를 방지합니다.

- 외부 트래픽 대응
CDN 사용: 콘텐츠 전송 네트워크(CDN)를 활용하여 외부 사용자에게 더 가까운 위치에서 데이터를 제공하여 지연 시간을 줄입니다.
부하 분산: 외부 트래픽을 여러 서버에 고르게 분산시켜 서버의 과부하를 방지합니다.
보안: 방화벽과 DDoS 방어 시스템을 통해 외부 공격에 대비합니다.

3.프록시는 무엇인가? HTTP / SOCKS 4 / SOCKS5의 차이는?

프록시(Proxy)는 클라이언트와 서버 사이에서 중개 역할을 하는 서버로, 요청을 대신 전달하거나 응답을 대신 받아오는 기능을 합니다. 프록시는 주로 다음과 같은 용도로 사용됩니다:

익명성 제공: 클라이언트의 IP 주소를 숨겨 개인 정보를 보호합니다.
캐싱: 자주 요청되는 데이터를 저장하여 성능을 향상시킵니다.
접근 제어: 특정 웹사이트에 대한 접근을 제한하는 등의 보안 기능을 제공합니다.
트래픽 모니터링: 네트워크 트래픽을 분석하고 기록하는 데 사용됩니다.

- HTTP, SOCKS 4, SOCKS 5의 차이

- HTTP 프록시
프로토콜: HTTP 프로토콜을 사용합니다.
용도: 주로 웹 브라우징에 사용되며, HTTP 요청과 응답을 처리합니다.
특징: 웹 페이지의 요청을 중개하며, HTTPS를 지원하는 경우 SSL 터널링을 통해 보안 연결을 제공합니다.

- SOCKS 4
프로토콜: SOCKS 4 프로토콜을 사용합니다.
용도: TCP/IP 연결을 중개하며, 웹 브라우징뿐만 아니라 FTP, SMTP 등 다양한 프로토콜을 지원합니다.
특징: 인증 기능이 없으며, IP 주소와 포트 정보만 사용합니다.

- SOCKS 5
프로토콜: SOCKS 5 프로토콜을 사용합니다.
용도: SOCKS 4의 기능을 확장하여 TCP 및 UDP 연결을 모두 지원합니다.
특징: 인증 기능을 지원하여 보안을 강화하고, 다양한 프로토콜과 애플리케이션에서 사용할 수 있습니다. 또한, IPv6를 지원합니다.

- 요약

HTTP 프록시: 웹 트래픽 전용, HTTP 프로토콜 사용.
SOCKS 4: 다양한 프로토콜 지원, 인증 없음.
SOCKS 5: SOCKS 4의 확장, TCP/UDP 지원, 인증 기능 포함.

4. 로드밸런서는 무엇인가? 리버스 프록시와 차이는?

- 로드밸런서
로드밸런서는 클라이언트의 요청을 여러 서버에 분산시켜 시스템의 성능과 가용성을 향상시키는 장치입니다. 주로 다음과 같은 기능을 수행합니다:

트래픽 분산: 서버 간의 부하를 고르게 나누어 성능을 최적화합니다.
가용성 향상: 하나의 서버가 다운되더라도 다른 서버에서 요청을 처리할 수 있도록 합니다.
스케일링: 필요에 따라 서버를 추가하거나 제거하여 유연하게 대응할 수 있습니다.

- 리버스 프록시와의 차이
리버스 프록시: 클라이언트의 요청을 받아 실제 서버에 전달하고, 서버의 응답을 클라이언트에게 반환하는 역할을 합니다. 주로 보안, 캐싱, SSL 오프로드 등의 기능을 제공합니다.
로드밸런서: 클라이언트의 요청을 여러 서버에 분산하여 처리하는 역할에 집중합니다. 리버스 프록시 기능을 포함할 수도 있지만, 주된 목적은 부하 분산입니다.

5. 노스-사우스 트래픽과 이스트-웨스트 트래픽 L4/L7의 차이는?

소프트웨어, 하드웨어 차이는? SSL 오프로딩이 무엇인가?

- 노스-사우스 트래픽과 이스트-웨스트 트래픽
노스-사우스 트래픽: 클라이언트와 서버 간의 트래픽을 의미합니다. 예를 들어, 사용자가 웹사이트에 접근할 때 발생하는 트래픽입니다.
이스트-웨스트 트래픽: 데이터 센터 내에서 서버 간의 트래픽을 의미합니다. 예를 들어, 백엔드 서비스가 서로 통신할 때 발생하는 트래픽입니다.

- L4 / L7의 차이
L4 (Layer 4): 전송 계층에서 동작하며, IP 주소와 TCP/UDP 포트 정보를 기반으로 트래픽을 분산합니다. 패킷 헤더 정보를 사용하여 결정합니다.
L7 (Layer 7): 응용 계층에서 동작하며, HTTP 요청, URL, 쿠키 등 애플리케이션 레벨의 정보를 기반으로 트래픽을 분산합니다. 더 정교한 라우팅과 정책을 적용할 수 있습니다.

- 소프트웨어와 하드웨어 로드밸런서의 차이
소프트웨어 로드밸런서: 서버에서 실행되는 소프트웨어로, 일반적으로 비용이 적고 유연하게 구성할 수 있습니다. 예: NGINX, HAProxy.
하드웨어 로드밸런서: 전용 하드웨어 장비로, 높은 성능과 안정성을 제공합니다. 일반적으로 비용이 더 비쌉니다. 예: F5 BIG-IP, Cisco.

- SSL 오프로드
SSL 오프로드는 로드밸런서나 프록시 서버가 클라이언트와의 SSL/TLS 연결을 처리하고, 내부 서버와는 평문(HTTP)으로 통신하는 기능입니다. 이를 통해 내부 서버의 부하를 줄이고, SSL 처리로 인한 성능 저하를 방지합니다.

6. ㅇCLOS 토폴로지가 무엇인가? 이 토폴로지의 장점은 무엇인가 구현에 어떤 기술을 사용하는가?

- CLOS 토폴로지란?
CLOS 토폴로지(CLOS topology)는 고성능 네트워크 설계를 위한 구조로, 다중 경로를 지원하며 고속 데이터 전송을 가능하게 합니다. 주로 데이터 센터와 대규모 클라우드 환경에서 사용됩니다. CLOS 토폴로지는 기본적으로 세 개의 계층으로 구성됩니다:

엣지 스위치(Edge Switches): 클라이언트나 서버와 연결되는 최하위 계층.
중간 스위치(Spine Switches): 엣지 스위치와 연결되어 데이터 전송을 중계하는 중간 계층.
코어 스위치(Core Switches): 스위치 간의 연결을 관리하며, 대량의 트래픽을 처리합니다.

- CLOS 토폴로지의 장점
확장성: 노드를 추가하거나 제거하는 것이 용이하여 네트워크를 쉽게 확장할 수 있습니다.
고가용성: 다중 경로를 통해 장애가 발생해도 다른 경로로 트래픽을 우회할 수 있어 시스템의 가용성이 높습니다.
부하 분산: 데이터 트래픽이 여러 경로로 분산되어 성능이 향상됩니다.
단일 장애점 최소화: 특정 스위치나 링크에서 장애가 발생해도 전체 네트워크에 미치는 영향을 줄일 수 있습니다.

구현에 사용하는 기술
CLOS 토폴로지를 구현하기 위해 다음과 같은 기술이 사용됩니다.

스위칭 기술: 고속 패킷 스위칭을 지원하는 스위치가 필요합니다. 예를 들어, 이더넷 스위치가 자주 사용됩니다.
VLAN 및 VXLAN: 가상 네트워크를 구성하여 트래픽을 분리하고 관리합니다.

SDN(Software-Defined Networking): 네트워크를 소프트웨어로 정의하고 관리하여 유연성과 자동화를 제공합니다.
리던던시 기술: 여러 경로를 통해 트래픽을 전송함으로써 고가용성을 유지합니다.

CLOS 토폴로지는 대규모 데이터 센터와 클라우드 환경에서 매우 효과적인 네트워크 구조이며, 다양한 기술과 설계를 통해 성능을 최적화할 수 있습니다.

7.  DSR 방식의 로드밸런서가 무엇이고, 어떻게 구현이 되는가? L3 방식으로 구현할 수는 없나? 장점은 무엇인가? 왜 쓰는가? 설정할 때 주의 사항은?

- DSR 방식의 로드밸런서란?
DSR(Direct Server Return) 방식의 로드밸런서는 클라이언트의 요청을 로드밸런서가 처리한 후, 서버가 직접 클라이언트에게 응답하는 구조입니다. 이 방식은 로드밸런서가 요청을 분산하는 역할만 하고, 응답은 서버가 직접 전달합니다.

- DSR 방식의 구현
패킷 포워딩: 로드밸런서는 클라이언트의 요청을 수신하고, 해당 요청을 적절한 서버로 포워딩합니다.
IP 주소 변환: 로드밸런서가 클라이언트의 요청을 서버의 IP 주소로 변환하여 전송합니다. 이때 클라이언트는 로드밸런서의 IP를 인식하지 못합니다.
직접 응답: 서버는 클라이언트에게 직접 응답을 보내며, 이때 로드밸런서를 거치지 않습니다.

- L3 방식으로 구현 가능 여부
DSR 방식은 일반적으로 L4 또는 L7에서 구현됩니다. L3 기반으로 구현할 수는 있지만, IP 패킷의 라우팅에 대한 복잡성이 증가할 수 있습니다. L3에서는 TCP 세션 상태를 관리하기 어렵기 때문에, L4/L7 방식이 더 일반적입니다.

- DSR의 장점
성능 향상: 서버가 응답을 직접 클라이언트에게 보내므로 로드밸런서의 부하가 줄어듭니다.
대역폭 절약: 로드밸런서를 통해 다시 데이터를 전송할 필요가 없어 대역폭을 효율적으로 사용할 수 있습니다.
스케일링 용이: 추가 서버를 쉽게 연결할 수 있어 시스템 확장이 용이합니다.

- 왜 DSR 방식을 사용하는가?
대규모 웹 서비스: 많은 클라이언트 요청을 처리해야 하는 대규모 서비스에서 효율성을 극대화할 수 있습니다.
빠른 응답 속도: 클라이언트와 서버 간의 직접적인 응답 경로로 인해 빠른 응답 시간을 제공합니다.

- 설정 시 주의 사항
네트워크 구성: 클라이언트와 서버 간의 네트워크 경로가 올바르게 설정되어야 합니다. 방화벽이나 라우터 설정에 주의해야 합니다.
IP 주소 관리: 서버가 클라이언트에게 직접 응답할 수 있도록 IP 주소를 올바르게 구성해야 합니다.
세션 관리: 클라이언트와 서버 간의 세션 상태를 잘 관리해야 하며, 이를 위해 세션 지속성(Session Persistence) 설정이 필요할 수 있습니다.
모니터링: 로드밸런서와 서버의 상태를 지속적으로 모니터링하여 장애를 조기에 감지하고 대응해야 합니다.

8. PoP(Points of Presence)란?

PoP는 "Points of Presence"의 약자로, 네트워크 서비스 제공자가 고객에게 서비스를 제공하기 위해 구축한 물리적 위치를 의미합니다. 이 위치는 데이터 센터, 네트워크 노드 또는 중계 지점 등 다양한 형태로 존재할 수 있습니다.

- PoP의 주요 기능
접근성: 사용자가 인터넷에 연결할 수 있는 접점을 제공합니다.
데이터 전송: 데이터를 저장하거나 전송하는 역할을 수행합니다.
네트워크 최적화: 사용자와 가까운 위치에서 서비스를 제공함으로써 지연 시간을 줄이고 성능을 향상시킵니다.
로드밸런싱: 여러 서버 간의 트래픽을 분산시켜 안정성과 가용성을 높입니다.

- PoP의 활용 예
콘텐츠 전송 네트워크(CDN): 콘텐츠를 사용자에게 더 빠르게 전달하기 위해 여러 지역에 PoP를 배치합니다.
클라우드 서비스: 클라우드 제공업체가 여러 지역에 PoP를 두어 글로벌 서비스를 제공합니다.
PoP는 네트워크의 성능과 안정성을 높이는 데 중요한 역할을 하며, 특히 대규모 서비스에서 필수적인 요소입니다.

9. BGP가 무엇인가? AS의 개념은 무엇인가? BGP와 IP의 관계는 어떻게 되는가? EBGP는?

BGP란?
BGP(Border Gateway Protocol)는 인터넷에서 사용되는 주요 경로 선택 프로토콜로, 서로 다른 자율 시스템(AS) 간의 라우팅 정보를 교환합니다. BGP는 경로 벡터 프로토콜로, 라우터가 최적의 경로를 선택하고 전달하는 데 필요한 정보를 제공합니다.

AS(자율 시스템)의 개념
AS(Autonomous System)는 하나의 관리 하에 있는 네트워크 집합으로, 고유한 AS 번호를 가지고 있습니다. AS는 ISP(인터넷 서비스 제공자)나 대규모 기업 네트워크 등으로 구성될 수 있습니다. 각 AS는 자체적인 라우팅 정책을 가지고 있으며, BGP를 통해 다른 AS와 정보를 교환합니다.

BGP와 IP의 관계
BGP는 IP 주소를 기반으로 작동합니다. BGP는 IP 패킷이 목적지에 도달하기 위한 최적의 경로를 결정하는 데 사용되며, IP 주소의 프리픽스(주소 범위) 정보를 교환하여 라우팅 테이블을 업데이트합니다. 즉, BGP는 IP 네트워크의 경로 정보를 관리하는 프로토콜입니다.

EBGP(External BGP)
EBGP는 "External BGP"의 약자로, 서로 다른 AS 간의 BGP 세션을 의미합니다. 즉, 두 개의 다른 AS가 BGP를 통해 라우팅 정보를 교환하는 경우입니다. EBGP는 외부 네트워크와의 상호 연결을 담당하며, 경로 선택에서 중요한 역할을 합니다.

1. MTU

MTU(최대 전송 단위, Maximum Transmission Unit)는 네트워크에서 한 번에 전송할 수 있는 최대 패킷 크기를 의미합니다. MTU 값은 네트워크 성능과 효율성에 중요한 영향을 미치며, 기본값은 일반적으로 1500 바이트입니다.

MTU의 역할

• 패킷 전송: MTU는 데이터가 한 번에 전송될 수 있는 최대 크기를 정의하여, 네트워크에서의 패킷 분할(fragmentation)을 방지합니다.
• 성능 최적화: 적절한 MTU 설정은 네트워크 대역폭을 최적화하고, 전송 지연을 줄이는 데 도움을 줍니다.

MTU 값을 변경해야 하는 경우

1. 네트워크 장비의 제한:
   • 특정 네트워크 장비(예: 라우터, 스위치)가 MTU 크기에 제한이 있는 경우, 이를 고려하여 MTU를 낮출 필요가 있습니다.
2. VPN 사용:
   • VPN을 사용하면 종종 추가 헤더가 추가되어 패킷 크기가 증가합니다. 이 경우 MTU를 줄이지 않으면 패킷 분할이 발생할 수 있습니다.
3. 특정 프로토콜 사용:
   • 특정 프로토콜(예: PPPoE)에서는 MTU가 1492 바이트로 제한될 수 있습니다. 이 경우 MTU를 조정해야 원활한 통신이 가능합니다.
4. 네트워크 성능 문제:
   • 패킷 손실, 지연, 또는 성능 저하 문제가 발생하는 경우, MTU 값을 조정하여 최적의 설정을 찾을 수 있습니다.
5. 멀티캐스트 및 브로드캐스트 트래픽:
   • 멀티캐스트 또는 브로드캐스트 트래픽이 많은 네트워크에서는 MTU를 조정하여 성능을 개선할 수 있습니다.

MTU 변경 시 주의사항

• 테스트 필요: MTU를 변경하기 전에, 네트워크 환경을 고려하여 테스트를 진행하는 것이 중요합니다.
• 일관성 유지: 모든 장비에서 동일한 MTU 설정을 유지해야 패킷 손실을 방지할 수 있습니다.

+ 내용

MTU(최대 전송 단위)는 패킷의 "묶음"이라고 보기는 어렵습니다. MTU는 한 번에 전송할 수 있는 최대 패킷 크기를 정의하는 값입니다. 즉, MTU는 패킷의 크기 제한을 나타내며, 네트워크에서 전송할 수 있는 단일 패킷의 최대 바이트 수를 의미합니다.

요약

• MTU: 한 번에 전송할 수 있는 최대 패킷 크기.
• 패킷: 실제로 전송되는 데이터의 단위.

2. MTU가 1500바이트면 시간당 흐르는 패킷의 양은?

MTU가 1500바이트라는 것은 한 번에 전송할 수 있는 최대 패킷 크기입니다. 시간당 흐르는 패킷의 양을 계산하기 위해서는 네트워크의 대역폭(속도)을 알아야 합니다.

예시 계산

1. 대역폭 설정: 예를 들어, 네트워크 속도가 100 Mbps(메가비트 per 초)라고 가정해 보겠습니다.
2. 비트로 변환:
   • 100 Mbps = 100,000,000 비트/초
3. 바이트로 변환:
   • 100,000,000 비트/초 ÷ 8 = 12,500,000 바이트/초
4. 패킷 수 계산:
   • 12,500,000 바이트/초 ÷ 1500 바이트/패킷 = 약 8333 패킷/초
5. 시간당 패킷 수:
   • 8333 패킷/초 × 3600 초/시간 = 약 30,000,000 패킷/시간

결론

따라서, 100 Mbps의 대역폭에서 MTU가 1500 바이트일 경우, 시간당 약 30,000,000개의 패킷이 흐를 수 있습니다.

3. 패킷의 구성요소

패킷은 네트워크를 통해 데이터가 전송될 때, 정보의 단위로 사용되는 구조입니다. 패킷의 구성 요소는 일반적으로 다음과 같습니다:

1. 헤더 (Header)

• 출발지 주소: 패킷이 어디에서 왔는지를 나타내는 주소.
• 목적지 주소: 패킷이 어디로 가야 하는지를 나타내는 주소.
• 프로토콜 정보: 어떤 프로토콜이 사용되는지를 나타내는 정보 (예: TCP, UDP).
• 시퀀스 번호: 연결된 패킷의 순서를 식별하는 번호.
• 제어 정보: 오류 검사, 흐름 제어 등과 관련된 정보.

2. 데이터 (Payload)

• 실제 전송되고자 하는 정보나 데이터입니다. 이 부분이 패킷의 주요 내용이며, 애플리케이션의 데이터(예: 웹 페이지, 이메일 등)가 포함됩니다.

3. 트레일러 (Trailer)

• 오류 검사 정보: 패킷이 전송 중 손상되었는지 확인하기 위한 정보(예: CRC 체크섬).
• 일부 프로토콜에서는 트레일러가 포함될 수 있으며, 모든 패킷에 필수는 아닙니다.

패킷 구조의 예

• IP 패킷: 인터넷 프로토콜(IP) 패킷은 헤더와 데이터로 구성되며, 헤더는 출발지 및 목적지 IP 주소, 프로토콜 정보 등을 포함합니다.
• TCP 세그먼트: TCP 프로토콜의 경우, TCP 헤더가 포함되어 추가적인 제어 정보(예: 포트 번호, 플래그 등)를 제공합니다.

결론

패킷은 헤더, 데이터, 트레일러로 구성되어 있으며, 이 구성 요소들은 패킷이 네트워크를 통해 올바르게 전달되고 처리되는 데 필요한 중요한 정보를 포함합니다.

4. IP의 서브넷 마스크 계산 방법

서브넷 마스크 개념

서브넷 마스크는 네트워크 주소와 호스트 주소를 구분하는 데 사용됩니다. 일반적으로 서브넷 마스크는 네트워크의 비트 수를 나타내며, 이는 IP 주소의 어느 부분이 네트워크를 나타내고 어느 부분이 호스트를 나타내는지를 결정합니다.

서브넷 마스크 계산 방법

1. IP 주소와 서브넷 마스크 이해하기
   • IP 주소는 32비트로 구성되며, 보통 4개의 옥텟(예: 192.168.1.1)으로 표시됩니다.
   • 서브넷 마스크도 32비트이며, 네트워크 부분은 1로, 호스트 부분은 0으로 표시됩니다.
2. 네트워크 요구 사항 결정하기
   • 네트워크에서 필요한 호스트 수를 결정합니다. 예를 들어, 50개의 호스트가 필요하다면 서브넷 마스크를 계산해야 합니다.
3. 필요한 비트 수 계산하기
   • 필요한 호스트 수에 따라 2의 거듭제곱을 사용하여 필요한 비트 수를 계산합니다.
   • 예: 50개의 호스트가 필요하다면, (2^6 = 64) (6비트)로 설정할 수 있습니다. (64는 50보다 크므로 적합)
4. 서브넷 마스크 비트 수 결정하기
   • 전체 비트 수 32에서 필요한 호스트 비트 수를 뺍니다.
   • 예: 32 - 6 = 26. 따라서, 서브넷 마스크는 26비트가 됩니다.
5. 서브넷 마스크 작성하기
   • 26비트의 서브넷 마스크를 작성합니다. 1로 설정된 비트는 네트워크 부분, 0으로 설정된 비트는 호스트 부분입니다.
   • 26비트 서브넷 마스크는 255.255.255.192입니다. (255.255.255.192 = 11111111.11111111.11111111.11000000)

예시

• IP 주소: 192.168.1.0
• 필요한 호스트 수: 50
• 서브넷 마스크: 255.255.255.192 (/26)

결론

서브넷 마스크는 호스트 수에 따라 비트를 계산하고, 이를 바탕으로 IP 주소와 함께 사용하여 네트워크를 구성합니다.

5. 유니캐스트, 멀티캐스트, 브로드캐스트

유니캐스트, 멀티캐스트, 브로드캐스트는 네트워크에서 데이터 전송 방식에 따라 구분됩니다. 각각의 차이점은 다음과 같습니다:

1. 유니캐스트 (Unicast)

• 정의: 한 송신자가 한 수신자에게 데이터를 전송하는 방식입니다.
• 특징:
  • 1:1 통신 방식으로, 특정 대상에게만 메시지가 전달됩니다.
  • 예: 한 컴퓨터가 특정 서버에 요청을 보내는 경우.
• 장점: 데이터가 특정 수신자에게만 전달되므로 보안성이 높고, 불필요한 트래픽이 발생하지 않습니다.

2. 멀티캐스트 (Multicast)

• 정의: 한 송신자가 여러 특정 수신자에게 동시에 데이터를 전송하는 방식입니다.
• 특징:
  • 1:N 통신 방식으로, 그룹에 속한 여러 수신자에게 동시에 전달됩니다.
  • 예: IPTV 방송이나 화상 회의에서 여러 사용자에게 스트리밍할 때 사용됩니다.
• 장점: 필요한 수신자에게만 데이터를 전송하므로 대역폭을 절약할 수 있습니다.

3. 브로드캐스트 (Broadcast)

• 정의: 한 송신자가 네트워크에 연결된 모든 수신자에게 데이터를 전송하는 방식입니다.
• 특징:
  • 1:모든 통신 방식으로, 네트워크 내의 모든 장치가 수신합니다.
  • 예: ARP 요청이나 DHCP Discover 메시지.
• 장점: 모든 장치가 동시에 수신하므로, 네트워크의 모든 장치와 정보를 쉽게 공유할 수 있습니다.

요약

• 유니캐스트: 1:1 통신 (특정 수신자).
• 멀티캐스트: 1:N 통신 (특정 그룹 수신자).
• 브로드캐스트: 1:모든 통신 (모든 장치).

1. TCP,  UDP,  ICMP

TCP, UDP, ICMP는 네트워크 통신에서 중요한 역할을 하는 프로토콜입니다. 이들은 각각의 목적과 동작 방식에 따라 특정한 기능을 제공합니다.

1. TCP (Transmission Control Protocol)

• 설명: TCP는 신뢰성 있는 데이터 전송을 보장하는 연결 지향 프로토콜입니다. 연결을 설정하고 데이터 전송 전에 세 가지 단계를 통해 상대방과 연결을 가집니다.
• 특징:
  • 신뢰성: 데이터가 전송되었는지 확인하고, 오류가 발생한 경우 재전송합니다.
  • 연결 지향: 데이터 전송 전에 연결을 설정해야 합니다. 이를 위해 3-way handshake라는 과정을 거칩니다:
    • 클라이언트가 SYN 패킷 전송
    • 서버가 SYN-ACK 패킷 응답
    • 클라이언트가 ACK 패킷 전송 1
• 헤더 구조:
  • 소스/목적 포트: 통신을 위한 포트 번호.
  • 순서 번호: 전송된 데이터의 위치를 나타냅니다.
  • ACK 번호: 수신한 데이터의 다음 순서를 나타냅니다.
  • 체크섬: 데이터의 오류를 체크하는 데 사용됩니다.

2. UDP (User Datagram Protocol)

• 설명: UDP는 비연결형 프로토콜로, TCP보다 간단한 구조를 가지고 있습니다. 신뢰성을 요구하지 않는 데이터 전송에 사용됩니다.
• 특징:
  • 비연결성: 데이터 전송 전에 연결을 설정하지 않습니다.
  • 속도: 데이터그램을 즉시 전송하기 때문에 실시간 애플리케이션에 유리합니다 (예: 비디오 스트리밍).
  • 신뢰성 부족: 패킷 손실이나 오류에 대해 신경 쓰지 않으므로, 높은 속도가 필요한 상황에서 주로 사용됩니다.
• 헤더 구조:
  • 소스/목적 포트: TCP와 동일하게 포트 번호가 포함됩니다.
  • 길이: UDP 헤더와 데이터의 길이.
  • 체크섬: 데이터의 오류를 검증하는 기능이 있지만, 필수는 아닙니다.

3. ICMP (Internet Control Message Protocol)

• 설명: ICMP는 네트워크 장비 간의 오류 메시지와 운영 정보를 전달하는 데 사용됩니다. 주로 네트워크 진단 도구에서 사용됩니다.
• 특징:
  • 오류 메시지: 데이터 전송 중 문제가 발생했을 때 이를 알리는 데 사용됩니다.
  • Ping 명령: ICMP Echo Request와 Echo Reply 메시지를 통해 네트워크 상태를 검사합니다.
  • 비연결형: 직접 데이터 흐름을 관리하지 않으며, 오히려 다른 프로토콜을 보조합니다.
• 헤더 구조:
  • 타입 및 코드: 메시지의 종류와 세부적인 코드를 나타냅니다.
  • 체크섬: 오류 검증을 위해 사용됩니다.

4. 관련 주제: 프로토콜의 비교

• 신뢰성:
  • TCP는 데이터의 전송 신뢰성을 보장하는 반면 UDP는 이를 보장하지 않습니다.
• 연결 방식:
  • TCP는 연결 지향적이며 UDP는 비연결 지향적입니다.
• 용도:
  • TCP는 웹 브라우징, 이메일 등에 사용되고, UDP는 온라인 게임, VoIP, 스트리밍 서비스 등에 많이 활용됩니다.

2. TIME_WAIT

TIME_WAIT 상태는 TCP 연결 종료 후 클라이언트 소켓이 일정 시간 동안 유지되는 상태로, 여러 가지 이유로 필요합니다.

1. 패킷 손실 처리

• TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 세그먼트의 전송 상태를 확인합니다. 클라이언트가 연결을 종료하고 소켓을 닫았을 때, 지연된 패킷이나 재전송된 패킷이 도착할 수 있습니다.
• TIME_WAIT 상태는 이러한 지연된 패킷을 처리할 시간을 제공합니다. 만약 클라이언트가 닫힌 소켓에 지연된 FIN 패킷을 받으면, 이미 닫힌 연결이므로 해당 패킷은 무시하거나 적절히 처리할 수 있습니다.

2. 중복 연결 방지

• TIME_WAIT 상태는 동일한 소켓 쌍(소스 IP, 소스 포트, 목적지 IP, 목적지 포트)으로 새로운 연결을 생성하기 전에 일정 시간을 대기하게 합니다. 이는 이전 연결이 완전히 종료될 수 있도록 보장합니다.
• 이 시간 동안 새로운 연결이 발생하더라도, 이전 연결의 패킷이 혼동되지 않도록 하여 데이터의 무결성을 보장합니다.

3. 재전송 처리

• 서버가 클라이언트의 마지막 ACK를 받지 못했을 경우, FIN 패킷을 재전송할 수 있습니다. 클라이언트가 TIME_WAIT 상태에 있을 때, 이 재전송된 FIN 패킷을 수신하게 되면 적절히 응답할 수 있습니다.
• 이를 통해 재전송된 패킷이 정상적으로 처리되도록 하고, 연결이 완전히 종료되는 과정을 보장합니다.

4. 효율적인 연결 종료

• TIME_WAIT 상태가 없었다면, 클라이언트는 즉시 소켓을 닫고 새로운 연결을 생성할 수 있었으나, 이로 인해 이전 연결의 패킷이 혼란을 일으킬 수 있었습니다.
• 따라서 TIME_WAIT 상태는 네트워크 자원을 효율적으로 관리하고, 연결 종료 과정에서 발생할 수 있는 오류를 최소화하는 역할을 합니다.

3. TCP Half-open connection

TCP Half-open 연결은 두 통신 호스트 간의 상태가 비동기화된 TCP 연결을 의미하며, 일반적으로 한 쪽이 오류로 인해 정상적으로 종료되지 않았을 때 발생합니다. 이 상태는 연결의 한 쪽에서만 소켓이 종료되었고, 반대편은 여전히 연결된 상태로 남아 있는 상황입니다.

1. Half-open 상태의 정의

• 정의: 한쪽 호스트(서버 또는 클라이언트)가 연결을 종료하거나 소켓을 삭제했지만, 다른 쪽 호스트가 이를 인지하지 못한 경우 발생합니다. 결과적으로 하나의 연결만 비활성화되고, 나머지 쪽은 여전히 활성 상태입니다.
• 비정상적 종료: 이 상태는 통상적으로 다음과 같은 상황에서 발생할 수 있습니다.
  • 한 쪽 호스트가 충돌(crash)한 경우
  • 연결 종료를 통지하지 않고 소켓을 비활성화한 경우

2. Half-open 상태의 예

• 서버 충돌 예시: 서버가 연결에 대한 FIN 패킷을 보내지 않고 갑자기 종료되면, 클라이언트는 서버에 대한 연결을 여전히 유지한 채로 남게 됩니다. 이 클라이언트는 이제 데이터를 보내려고 시도할 수 있지만, 서버는 해당 데이터를 수신할 수 없습니다.
• 상태 비동기화: 이 상황에서 클라이언트는 여전히 정상적으로 작동하는 자원으로 인식하지만, 실제로는 서버가 응답하지 않기 때문에 연결이 이상 상태로 들어갑니다.

3. Half-open 연결의 원인

• TCP 설정 처리 오류: 연결을 종료했지만 시간이 오래 걸린 경우, 이로 인해 않는 패킷 수신 잔액의 통신에 대한 기대가 일어날 수 있습니다.
• Stateful Firewall Timeout: 상태를 관리하는 방화벽이 일정 시간 동안 통신이 없으면 연결 상태를 삭제하는 경우, 연결의 일쪽이 데이터 패킷을 전송하면 방화벽은 패킷을 버릴 수 있습니다. 이로 인해 연결이 half-open 상태로 남게 됩니다 1.

4. Half-open 연결의 문제점

• 자원 낭비: Half-open 연결이 유지되는 동안, 시스템 자원(메모리 및 소켓 포트)이 낭비됩니다.
• 데이터 전송 실패: 한쪽이 비정상적으로 종료되었기 때문에, 데이터 전송이 실패할 수 있습니다.
• 보안 위험: 한쪽 연결이 더 이상 기능하지 않지만, 공격자는 이를 이용할 수 있는 가능성이 존재합니다.

5. 관련 주제: Embryonic Connection

• 정의: Embryonic Connection은 TCP 연결이 설정 과정에 있는 상태를 의미합니다. 이 상태에서 클라이언트는 서버의 응답을 기다리고 있으며, 이 연결이 완전히 설정되지 않았습니다.
• 상태 관리:
  • 클라이언트가 SYN 패킷을 전송하고, 서버가 SYN-ACK 패킷을 응답하면, 클라이언트는 최종 ACK 패킷을 전송하여 연결을 확립합니다. 이 상태에서 오류가 발생하면, 연결은 half-open 상태로 전환될 수 있습니다.

4. 네트워크 인터페이스 리스트와 라우팅

1. 네트워크 인터페이스 리스트

네트워크 인터페이스는 서버가 네트워크에 연결될 수 있도록 하는 하드웨어 또는 소프트웨어 구성 요소입니다. 일반적으로 다음과 같은 정보가 포함됩니다.

• 인터페이스 이름: 예를 들어, eth0, wlan0, lo(루프백) 등.
• IP 주소: 각 인터페이스에 할당된 고유한 IP 주소.
• 서브넷 마스크: IP 주소의 네트워크 부분과 호스트 부분을 구분하는 데 사용되는 마스크.
• MAC 주소: 물리적 네트워크 인터페이스에 할당된 고유 식별자.
• 상태: 인터페이스가 활성화(active) 또는 비활성화(inactive) 상태인지 여부.

이 정보는 일반적으로 명령어를 통해 확인할 수 있으며, 예를 들어 Linux에서는 ifconfig 또는 ip addr 명령어를 사용할 수 있습니다.

2. 라우팅 설정

라우팅 설정은 패킷이 네트워크를 통해 이동하는 경로를 결정합니다. 라우팅 테이블은 각 목적지에 대한 경로 정보를 포함하고 있으며, 주요 항목은 다음과 같습니다.

• 목적지 네트워크: 패킷이 전송될 대상 IP 주소 또는 네트워크.
• 서브넷 마스크: 목적지 네트워크를 정의하는 데 사용되는 마스크.
• 게이트웨이: 패킷이 전달될 다음 홉의 IP 주소. 일반적으로 라우터의 주소입니다.
• 인터페이스: 패킷이 전송될 네트워크 인터페이스.
• 메트릭: 경로의 우선 순위를 결정하는 값. 낮은 값일수록 높은 우선 순위를 가집니다.

라우팅 테이블은 route 또는 ip route 명령어를 통해 확인할 수 있습니다.

3. 예시

• 네트워크 인터페이스:
  • eth0: 192.168.1.10, 서브넷 마스크 255.255.255.0, 상태: 활성화.
  • lo: 127.0.0.1, 서브넷 마스크 255.0.0.0.
• 라우팅 테이블:
  • 목적지: 0.0.0.0, 서브넷 마스크: 0.0.0.0, 게이트웨이: 192.168.1.1, 인터페이스: eth0, 메트릭: 100.

4. 중요성

• 네트워크 연결: 올바른 네트워크 인터페이스 설정은 서버가 네트워크에 제대로 연결되도록 보장합니다.
• 효율적인 데이터 전송: 라우팅 설정은 데이터 패킷이 최적의 경로를 통해 전달되도록 하여 네트워크 성능을 향상시킵니다.

5. 서브넷 마스크

서브넷 마스크는 IP 주소에서 네트워크 부분과 호스트 부분을 구분하는 데 사용되는 값입니다. 네트워크의 크기를 정의하고, 어떤 IP 주소가 동일한 네트워크에 속하는지를 판단하는 데 중요한 역할을 합니다.

서브넷 마스크의 구성

서브넷 마스크는 일반적으로 32비트의 이진수로 표현되며, 1로 설정된 비트는 네트워크 부분을, 0으로 설정된 비트는 호스트 부분을 나타냅니다. 예를 들어, 서브넷 마스크가 255.255.255.0인 경우:

• 이진수: 11111111.11111111.11111111.00000000
• 네트워크 부분: 24비트 (첫 3옥타브)
• 호스트 부분: 8비트 (마지막 옥타브)

예시

1. IP 주소와 서브넷 마스크:
   • IP 주소: 192.168.1.10
   • 서브넷 마스크: 255.255.255.0
   여기서 192.168.1.10의 네트워크 부분은 192.168.1이고, 호스트 부분은 10입니다. 이 설정은 192.168.1.0 네트워크 내에서 최대 254개의 호스트(192.168.1.1 ~ 192.168.1.254)를 지원합니다.
2. 다른 서브넷 마스크 예시:
   • IP 주소: 10.0.0.5
   • 서브넷 마스크: 255.0.0.0
   이 경우, 네트워크 부분은 10이고, 호스트 부분은 0.0.5입니다. 이 설정은 10.0.0.0 네트워크 내에서 약 1천7백만 개의 호스트를 지원합니다.
3. 서브넷 마스크 계산 방법 :
   1. IP 주소와 서브넷 마스크 이해하기
      • IP 주소는 32비트로 구성되며, 보통 4개의 옥텟(예: 192.168.1.1)으로 표시됩니다.
      • 서브넷 마스크도 32비트이며, 네트워크 부분은 1로, 호스트 부분은 0으로 표시됩니다.
   2. 네트워크 요구 사항 결정하기
      • 네트워크에서 필요한 호스트 수를 결정합니다. 예를 들어, 50개의 호스트가 필요하다면 서브넷 마스크를 계산해야 합니다.
   3. 필요한 비트 수 계산하기
      • 필요한 호스트 수에 따라 2의 거듭제곱을 사용하여 필요한 비트 수를 계산합니다.
      • 예: 50개의 호스트가 필요하다면, (2^6 = 64) (6비트)로 설정할 수 있습니다. (64는 50보다 크므로 적합)
   4. 서브넷 마스크 비트 수 결정하기
      • 전체 비트 수 32에서 필요한 호스트 비트 수를 뺍니다.
      • 예: 32 - 6 = 26. 따라서, 서브넷 마스크는 26비트가 됩니다.
   5. 서브넷 마스크 작성하기
      • 26비트의 서브넷 마스크를 작성합니다. 1로 설정된 비트는 네트워크 부분, 0으로 설정된 비트는 호스트 부분입니다.
      • 26비트 서브넷 마스크는 255.255.255.192입니다. (255.255.255.192 = 11111111.11111111.11111111.11000000)
   예시
   • IP 주소: 192.168.1.0
   • 필요한 호스트 수: 50
   • 서브넷 마스크: 255.255.255.192 (/26)

TCP 핸드쉐이크 프로세스 (연결 및 종료 과정) TCP (Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 위해 세션을 설정하는 핸드쉐이크 프로세스를 사용합니다. 이 과정은 주로 연결을 설정할 때와 종료할 때의 두 가지 단계로 나뉘어집니다.

1. TCP 연결 설정 (핸드쉐이크)

TCP 연결 설정 과정은 일반적으로 3단계로 이루어져 있습니다. 다음은 각 단계의 설명입니다:

• SYN 단계:
  • 클라이언트는 서버에 연결 요청을 위해 SYN (Synchronize) 패킷을 보냅니다. 이 패킷에는 클라이언트의 초기 시퀀스 번호가 포함됩니다.
• SYN-ACK 단계:
  • 서버는 클라이언트의 SYN 요청에 대해 응답으로 SYN-ACK (Synchronize-Acknowledge) 패킷을 보냅니다. 이 패킷은 서버의 초기 시퀀스 번호와 함께 클라이언트의 요청을 확인하는 ACK (Acknowledgment)를 포함합니다.
• ACK 단계:
  • 클라이언트는 서버의 SYN-ACK 패킷을 받고, ACK (Acknowledgment) 패킷으로 응답합니다. 이 단계에서 클라이언트는 서버의 시퀀스 번호를 확인하며, 이제 클라이언트와 서버 간의 연결이 성공적으로 설정됩니다.

이러한 3단계 과정을 통해 TCP 연결이 형성되고, 데이터 전송이 가능해집니다.

2. TCP 연결 종료

TCP 연결 종료는 일반적으로 4단계로 이루어집니다:

• FIN 단계:
  • 클라이언트 또는 서버가 더 이상 데이터를 전송하지 않겠다고 결정할 경우, FIN (Finish) 패킷을 보냅니다. 이 패킷은 종료를 알리는 신호입니다.
• ACK 단계:
  • 상대방은 FIN 패킷을 수신하면 확인 응답으로 ACK를 보냅니다. 이 단계에서 한 쪽의 연결이 종료됩니다.
• FIN 단계:
  • 이제 상대방도 종료를 요청할 수 있으며, FIN 패킷을 전송합니다.
• ACK 단계:
  • 원래의 클라이언트/서버가 FIN 패킷을 수신하고 ACK 패킷으로 응답함으로써 TCP 연결은 완전히 종료됩니다.

이 과정을 통해 상대방도 연결이 종료되었음을 확인하고, 모든 데이터가 안전하게 전송되었는지를 보장합니다.

3. 추가 확인할 점: TCP 상태 전이 다이어그램

TCP 핸드쉐이크 및 종료 과정은 상태 전이 다이어그램을 통해 명확하게 표현될 수 있습니다. 이 다이어그램은 연결이 설정되거나 종료되는 과정에서 각 상태 간의 전환을 시각적으로 나타냅니다.

• 상태 변화:
  • TCP는 여러 상태를 거치며 연결을 관리합니다. 예를 들어, LISTEN 상태에서 SYN 수신 후 SYN-RECEIVED 상태로, FIN 수신 후 TIME_WAIT 상태로 넘어갑니다.
• 시작 및 종료:

연결이 시작되면 ESTABLISHED 상태로 전이되며, 종료가 완료되면 CLOSED 상태로 되돌아갑니다.

1. 네트워크 : 노드와 링크가 서로 연결되어 있으며, 리소스를 공유하는 집합을 의미

  - 노드 : 서버, 라우터, 스위치 등 장치

  - 링크(엣지) : 유선 또는 무선과 같은 연결매체 (와이파이나 LAN)

2. 트래픽 : 트래픽은 특정시점에 링크 내의 “흐르는” 데이터의 양을 말합니다.

예를 들어 서버에 저장된 파일(문서,이미지,동영상 등)을 클라이언트(사용자)가 다운로드 시 발생되는 데이터의 누적량을 뜻합니다.

트래픽과 처리량을 헷갈릴 수 있는데 이렇게 이해하면 됩니다.

  - 트래픽이 많아졌다. = 흐르는 데이터가 많아졌다.

  - 처리량이 많아졌다. = 처리되는 트래픽이 많아졌다.

A1. 100KB x 1,000 = 100,000KB(100MB)

A2. 10MB x 10 = 100MB

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

  - 단위 : bps(bits per second) 초당 전송 또는 수신되는 비트 수

처리량은 사용자들이 많이 접속할 때마다 커지는 트래픽, 네트워크 장치 간의 대역폭, 네트워크 중간에 발생하는 에러, 장치의 하드웨어 스펙에 영향을 받습니다.

4. 대역폭 : 대역폭(bandwidth)은 주어진 시간 동안 네트워크 연결을 통해 흐를 수 있는 최대 비트 수를 말하며 최대로 처리할 수 있는 트래픽을 말합니다.

예를 들어 고속도로의 차선이 2차선보다 8차선일 때 더욱 원활하게 교통이 이루어지듯이 대역폭이 높을수록 사용자에게 빠른 서비스를 제공 할 수 있습니다. 대략적인 최대동시접속자수를 유추하는데의 척도가 됩니다.

  - 단위 : bps(bits per second) 초당 전송 또는 수신되는 비트 수

Q. 100Mbps라는 대역폭을 가진 서버가 있고 한사용자당 100kbps로 동영상 파일을 요청한다고 해봅시다. 최대 동접자수는 어떻게 될까요?

A.100Mbps / 100kbps = 약 1000명

5. RTT : RTT(Round Trip Time : 왕복 지연시간)는 신호를 전송하고 해당 신호의 수신확인에 걸린 시간을 더한 값이자 어떤 메시지가 두 장치 사이를 왕복하는 데 걸린 시간입니다.

출처 : 인프런 강의, CS 지식의 정석 | 디자인패턴 네트워크 운영체제 데이터베이스 자료구조, 강사 : 큰돌

1. HTTP Request

  - TCP/IP 계층에서 HTML(하이퍼텍스트)를 교환하기 위하여 만들어진 프로토콜(=규약)

  - 헤더와 바디로 구성

2. HTTP Header

  - 헤더는 콜론 ':'으로 서로 구분되는 key - value형태로 설정됨

  - General, Response Headers, Request Headers 3가지로 구성

  - 서버에서 설정하는 헤더를 응답헤더, 클라이언트에서 설정한 헤더를 요청헤더라고 함

3. 예시

  - www.naver.com  요청시, Network 분석

  - Headers

    I. General(일반헤더) :

요청한 URL, 요청메서드, 해당 자원을 요청할 때, 해당자원의 출처를 나타내는 URL을 노출시킬지 말지를 정하는 보안정도가 설정되어있는 Referrer Policy 등이 들어감

    II. Request Headers(요청헤더) :

클라이언트가 서버에 요청할 때 클라이언트가 설정하는 또는 자동으로 설정되는 헤더, 요청헤더에는 메서드, 클라이언트 OS, 브라우저, 기기 정보 등이 담김

    III. Resonse Headers(응답헤더) : 

서버가 클라이언트에게 응답을 보낼 때 설정하는 또는 자동으로 설정되는 헤더, 서버의 소프트웨어 정보가 담겨있음, 대부분의 서버는 일반적으로 해커가 서버에서 어떤 소프트웨어가 사용되고 있는지 알기 어렵게 하기 위해 서버 정보를 숨김. 예를들어, 위 그림을 보면 server: NWS 라고 써 있는 건, Naver Web Server를 의미, content-encoding에 gzip 외에는 자세정보를 제공하지 않음

  - Preview : HTTP Request Body (xml, json, String ..)

  - Response : 응답

4. 응답헤더 만들어보기

출처 : 인프런 강의, CS 지식의 정석 | 디자인패턴 네트워크 운영체제 데이터베이스 자료구조, 강사 : 큰돌