HTTP는 웹 브라우저와 서버 간에 데이터를 전송하는 방식을 정의한다.

이 데이터는 HTML, 이미지, 비디오, 오디오 및 기타 형식의 컨텐츠를 포함할 수 있다.

HTTP는 일반적으로 암호화되지 않은 텍스트로 전송된다. 따라서 보안에 취약하다.

HTTP의 동작 원리는 다음과 같다.

• 클라이언트가 서버에 HTTP 요청 메시지를 보낸다.
  • 이 요청 메시지는 HTTP 메서드(GET, POST, PUT, DELETE 등)와 요청 URI(Uniform Resource Identifier)로 구성된다.
  • GET 메서드는 서버로부터 데이터를 요청하고, POST 메서드는 클라이언트에서 서버로 데이터를 전송하는 등의 역할을 한다.
• 서버는 클라이언트의 요청을 받고, 요청한 데이터를 찾아서 HTTP 응답 메시지를 보낸다.
  • 이 응답 메시지는 상태 코드(200, 404, 500 등)와 응답 본문으로 구성된다.
  • 상태 코드는 클라이언트의 요청에 대한 성공 여부를 나타내며, 응답 본문은 요청한 데이터를 포함한다.
• 클라이언트는 서버로부터 받은 응답 메시지를 해석하고, 필요에 따라 추가적인 요청을 보낼 수 있다.
  • 예를 들어, 클라이언트가 웹 페이지를 요청한 경우, 서버는 HTML, CSS, JavaScript 등의 파일을 포함한 응답을 보내게 된다.
  • 이후 클라이언트는 이 파일들을 받아서 웹 페이지를 렌더링한다.

HTTPS는 HTTP의 보안 버전이다.

HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)를 사용하여 데이터를 암호화하고 인증서를 사용하여 통신하는 서버의 신원을 확인한다.

HTTPS를 사용하면 민감한 정보를 전송할 때 데이터가 암호화되므로 중간에서 누군가가 정보를 가로채서 읽을 수 없다.

간단히 말해, HTTP는 암호화되지 않은 인터넷 연결을 사용하여 데이터를 전송하는 반면, HTTPS는 암호화된 연결을 사용하여 데이터를 전송하는 것이다.

HTTPS를 사용하면 데이터의 기밀성과 무결성을 유지할 수 있으며, 중간자 공격 및 다른 보안 위협으로부터 보호된다.

HTTPS의 동작 원리는 다음과 같다.

• 클라이언트가 HTTPS로 보호된 서버에 접속한다. 이때 클라이언트는 SSL/TLS를 지원하는 브라우저를 사용해야 한다.
• 클라이언트는 서버의 공개키를 요청한다. 이를 위해 서버는 SSL/TLS 인증서를 전송한다. 인증서는 클라이언트와 서버 간의 통신을 보호하기 위한 공개키, 인증 기관의 정보 등을 포함한다.
• 클라이언트는 서버의 인증서를 검증한다. 이를 위해 클라이언트는 인증 기관의 공개키를 이용하여 서버의 공개키가 올바른지 확인한다.
• 클라이언트는 서버의 공개키를 사용하여 세션 키를 생성한다. 이 세션 키는 클라이언트와 서버 간의 통신을 암호화하기 위한 대칭키이다.
• 클라이언트는 서버의 공개키를 사용하여 세션 키를 암호화하여 서버에 전송한다.
• 서버는 자신의 비공개키를 사용하여 세션 키를 복호화한다.
• 클라이언트와 서버는 이제 세션 키를 사용하여 암호화된 HTTPS 통신을 수행한다.

• HTTP / HTTPS 란?

OSI 7계층과 TCP/IP 4계층은 둘 다 네트워크 프로토콜 스택의 구성 요소이다. 하지만 각각은 서로 다른 방식으로 계층을 구성하고 있다.

OSI 7계층과 TCP/IP 4계층을 비교해보면, OSI 모델의 상위 3개 계층인 세션 계층, 표현 계층, 응용 계층은 응용 프로그램에 관련된 기능을 담당하고, 이에 대한 표준 프로토콜들이 정의되어 있다.

반면에 TCP/IP 모델은 응용 프로그램 계층이 TCP와 UDP 프로토콜을 포함하고 있어서, 응용 프로그램 계층과 트랜스포트 계층을 연결해주는 역할을 한다.

세션 계층과 표현 계층은 데이터의 형식 변환, 데이터의 구조화, 압축 및 암호화와 같은 기능을 담당하는 반면, TCP/IP 모델은 이러한 기능을 담당하는 계층이 없다. 이러한 기능들은 응용 계층에서 직접 처리될 수 있다.

OSI 7계층은 Open Systems Interconnection 모델을 의미한다. 이 모델은 국제 표준화 기구(ISO)에서 개발한 네트워크 프로토콜 스택의 참조 모델이다.

7계층은 다음과 같이 구성된다:

• 물리 계층 (Physical Layer): 전기적, 물리적 신호를 전송하는 계층이다.
  • 프로토콜 : Ethernet, Fast Ethernet, Gigabit Ethernet, Wi-Fi, Bluetooth, USB
• 데이터 링크 계층 (Data Link Layer): 네트워크에서의 신뢰성 있는 데이터 전송을 담당한다.
  • 프로토콜 : Ethernet, Token Ring, FDDI, HDLC, PPP, SLIP
• 네트워크 계층 (Network Layer): 데이터를 목적지로 전달하는 경로를 선택하고, 패킷의 전송을 관리한다.
  • 프로토콜 : IP, ICMP, ARP, RARP, OSPF, BGP, IS-IS
• 전송 계층 (Transport Layer): 데이터의 전송을 보장하고, 오류 검출과 복구를 담당한다.
  • 프로토콜 : TCP, UDP, SCTP
• 세션 계층 (Session Layer): 양 끝단의 사용자 간의 연결을 관리하고, 통신 방식을 제어한다.
  • 프로토콜 : NetBIOS, RPC, SQL
• 표현 계층 (Presentation Layer): 데이터의 형식을 변환하거나, 암호화, 복호화 등의 처리를 수행한다.
  • 프로토콜 : JPEG, MPEG, SMB
• 응용 계층 (Application Layer): 응용 프로그램에게 서비스를 제공하는 계층이다.
  • 프로토콜 : HTTP, FTP, SMTP, POP3, IMAP, Telnet, SSH

TCP/IP 4계층은 Transmission Control Protocol/Internet Protocol 모델을 의미한다. 이 모델은 인터넷 프로토콜 스택의 참조 모델이다.

4계층은 다음과 같이 구성된다.

• 네트워크 인터페이스 계층 (Network Interface Layer): 물리적인 네트워크를 관리한다. 물리 계층과 데이터 링크 계층의 역할을 수행한다. 이 계층에서는 네트워크 인터페이스, 랜 카드 등의 장비가 사용된다.
• 인터넷 계층 (Internet Layer): IP 주소를 사용하여 데이터를 전송한다. 네트워크 계층의 역할을 수행한다. 이 계층에서는 IP 프로토콜이 사용된다.
• 전송 계층 (Transport Layer): TCP나 UDP 프로토콜을 사용하여 데이터의 전송을 보장하고, 오류 검출과 복구를 담당한다. OSI 모델의 전송 계층에 해당하는 역할을 수행한다.
• 응용 계층 (Application Layer): 응용 프로그램에게 서비스를 제공하는 계층이다. OSI 모델의 응용 계층, 표현 계층, 세션 계층의 역할을 수행한다. 이 계층에서는 HTTP, FTP, SMTP 등의 프로토콜이 사용된다.

• OSI 7계층 & TCP/IP 4계층이란?

AS란 Autonomous System(자율 시스템) 의 약자로 하나의 네트워크 관리자에 의해서 관리되는 라우터의 집단, 하나의 관리 규정 아래서 운영되는 라우터의 집단, 또는 하나의 관리 전략으로 구성된 라우터의 집단이다.

• AS 안에서 라우터들끼리 라우팅 정보를 주고받기 위해 라우터가 사용하는 프로토콜
• 종류: RIP, IGRP, EIGRP, OSPF

• AS와 AS간 외부에서 서로 라우팅 정보를 주고 받기 위해 라우터가 사용하는 프로토콜
• 종류: EGP, BGP (요즘은 EGP 보다 BGP를 사용하는 추세)

라우터가 가지는 정보를 효율적으로 관리하고 인터넷 서비스를 좀더 간편하게 할수 있다.

AS안에 있는 라우터들은 자신의 AS에 속해있는 라우터에 대한 내부 네트워크 정보만 알고 있다가 외부, 즉 AS 밖으로 나갈때는 그 AS의 문지기 라우터 ASBR (Autonomous System Boundary Router)에게 정보를 물어본후 외부 인터넷으로 나가게 되는 것이다.

문지기 라우터 ASBR은 자신의 AS와 인접해 있는 다른 AS에 대한 정보를 가지고 있으면서 자기 AS에서 밖으로 나가는 라우터나 외부 AS에서 자기 AS쪽으로 들어오는 라우터에게 정보를 제공하는 역할을 한다.

이러한 시스템 때문에 라우터들은 인터넷에 접속하더라도 전 세계의 모든 네트워크에 대한 정보를 다 가지고 있을 필요없이 단지 자신이 속한 AS에 대한 정보만 가지면 되는 것이다.

이때 라우터가 AS 내부에서 사용하는 라우팅 프로토콜을 내부용 라우팅 프로토콜(Interior Routing Protocols) 또는 IGP 라고 하고, AS 간에, 즉 AS 외부에서 서로 라우팅 정보를 주고 받기 위해 사용 하는 라우팅 프로토콜을 외부용 라우팅 프로토콜 (Exterior Routing Protocols) 또는 EGP 라고 한다.

• AS, BGP(Border Gateway Protocol)란?

BGP는 Border Gateway Protocol이다. AS의 가장자리에 위치한 BG(Border Gateway)들 간의 프로토콜을 BGP라고 한다.

따라서 모든 BGP 프로토콜이 서로 다른 AS들을 연결해주는 것이아니다.

그래서 물론 다른 AS들에 속한 BG간의 연결에도 관여하지만, 같은 AS 내의 BG 간의 연결에도 관여한다. 이러한 역할의 차이에 따라 BGP는 크게 두가지로 구분된다.

서로 같은 AS 상의 Border Gateway들 끼리의 연결을 담당하는 BGP

서로 다른 AS 상의 Border Gateway들 끼리의 연결을 담당은 BGP, inter-AS 라우팅이다.

또한 BGP 라우터는 AS 피어링 계약에 설정된 의사 결정 알고리즘과 정책을 사용해서 프리픽스 선언을 통해 수집하는 데이터를 분석하고 그 시점에 각 패킷 스트림을 보낼 최적의 피어를 선택한다.

대부분의 경우 네트워크 홉의 수가 가장 적은 경로가 선택되지만, 혼잡과 지연으로 인해 더 긴 경로의 속도가 더 빠를 수도 있다.

트래픽이 AS를 통과해 이동하여 다른 AS에 연결된 다른 BGP 라우터에 도달하면 데이터가 목적지 사이트가 위치한 AS에 도달할 때까지 이 프로세스가 반복된다.  TCP 포트 179번을 사용하고 유니캐스트 방식으로 교환한다.

IGP와 다르게 직접 연결되어 있지 않은 장비와 BGP Peer(Neighbor) 관계를 형성하는 것이 가능하다.

유니캐스트(1:1)

• 출발지와 목적지가 정확해야하는 일대일 통신
• 송신 노드 하나가  수신노드 하나에 데이터를 전송하는 일대일 방식

브로드캐스트(1:All)

• 내가 속한 네트워크 내의 모든 장비들과 통신을 하는 방식
• 개별 PC의 성능에도 영향을 미치고, 네트워크 전체적인 트래픽에도 영향을 미침

멀티캐스트(1:Group)

• 특정 일부에게 정보를 동시에 보내야 하는 경우 사용 (ex 10명중 8명)
• 선택적으로 데이터를 전송하여 불필요한 트래픽이나 성능저하를 막음

애니캐스트(1:1)

• 가장 가까운 노드와 통신하는 방식
• 유니캐스트와 차이점은 송신 노드가 네트워크에 연결된 수신 가능한 노드 중 한 노드에만 데이터를 전송

• AS, BGP(Border Gateway Protocol)란?

HTTP 메서드는 클라이언트가 웹 서버에게 어떤 종류의 동작을 원하는지를 나타내는 방법이다. 각 메서드는 특정한 종류의 작업을 수행하도록 설계되었다.

• 주로 서버에서 정보를 조회할 때 사용한다. (Get)
• GET 요청은 데이터를 변경하거나 생성하는 데 사용되지 않으며, 오직 데이터를 읽는 데만 사용된다.

• 주로 서버에 리소스를 추가할 때 사용한다. (Create)
• 클라이언트가 서버의 리소스를 생성하려고 할 때 사용한다.
• POST 요청은 서버에게 데이터를 보내고, 그 데이터를 사용해서 새로운 리소스를 생성하거나 기존 리소스를 업데이트하라는 요청을 한다.

• GET 요청과 거의 유사하지만, 실제 본문의 내용 없이 HTTP 헤더 정보만을 반환한다. (No Body)
• response에 Body가 없다.
• 리소스를 가져오지 않고도 그에 대한 정보를 얻을 수 있어 효율적이다.

• 특정 URL에 대응하는 리소스의 전체 내용을 갱신하는 데 사용한다. (Update)
• 만약 해당 URL에 리소스가 이미 존재한다면 PUT 요청은 그 리소스를 새로운 것으로 대체하고, 만약 리소스가 존재하지 않는다면 새로운 리소스를 생성한다.

• 특정 리소스를 제거하는 데 사용된다.
• DELETE 요청은 성공했을 때 보통 응답 본문에 데이터를 포함하지 않는다.

• 소스의 부분적인 변경을 적용하는 데 사용된다.
• PATCH 요청은 일부만 변경하기 때문에 PUT 요청보다 더 효율적일 수 있다.

• 리소스가 지원하는 메서드의 종류를 확인하는 데 사용된다.
• OPTIONS 요청은 "Allow"라는 헤더와 함께 해당 리소스에서 사용 가능한 HTTP 메서드 목록을 반환한다.

• 주로 진단 목적으로 사용된다.
• TRACE 요청은 클라이언트에서 서버로 전송되며, 이 과정에서 어떤 변경이나 추가가 이루어지는지를 확인하는데 사용될 수 있다. TRACE 요청이 서버에 도달하면, 서버는 요청을 그대로 응답 본문으로 반환한다.
• 이를 통해 클라이언트는 요청이 어떻게 처리되었는지 확인할 수 있다.

• 주로 네트워크 터널을 만드는 데 사용된다. 가장 흔한 예는 HTTPS 통신을 위한 SSL 터널이다.
• 클라이언트가 CONNECT 메서드를 사용하면, 웹 서버는 목적지 서버와의 네트워크 연결을 설정하고, 클라이언트와 목적지 서버 사이에서 데이터를 릴레이하게 된다.

• HTTP 메서드(Method)란? / HTTP Status Code

HTTP 상태 코드(HTTP Status Code)는 HTTP 응답에서 서버가 클라이언트에게 요청 처리의 결과를 전달하는 방법이다.

이 코드는 세 자리 숫자로 구성되며, 각각이 의미하는 바는 다음과 같다.

• 1xx (Informational): 요청이 수신되었고 프로세스가 계속되는 중임을 나타낸다.
• 2xx (Successful): 요청이 성공적으로 수신, 이해, 그리고 수용되었음을 나타낸다. 가장 일반적인 코드는 200 OK로, 요청이 성공적으로 처리되었음을 나타낸다.
• 3xx (Redirection): 클라이언트는 요청을 완료하기 위해 추가 동작을 취해야 함을 나타낸다. 예를 들어, 301 Moved Permanently는 요청한 리소스의 URI가 변경되었음을 나타내며, 새로운 URI를 클라이언트에게 제공한다.
• 4xx (Client Error): 클라이언트의 요청이 잘못되었거나 완료할 수 없음을 나타낸다. 가장 흔히 볼 수 있는 코드는 404 Not Found로, 요청한 리소스를 서버에서 찾을 수 없을 때 반환된다.
• 5xx (Server Error): 서버가 유효한 요청을 처리하는 데 실패했음을 나타낸다. 500 Internal Server Error는 서버에 문제가 있음을 나타내는 가장 일반적인 코드이다.

• HTTP 메서드(Method)란? / HTTP Status Code

DNS(Domain Name System)는 인터넷에서 사용되는 호스트 이름(도메인 이름)을 실제 IP 주소로 변환하는 시스템 이다.

Root DNS 서버는 인터넷에서 가장 중요한 DNS 서버 중 하나이다. 이 서버는 전 세계적으로 분산되어 있으며, 인터넷 상의 모든 도메인 이름에 대한 최상위 DNS 서버로 인터넷 전체 DNS 시스템의 기초를 담당한다.

그리고 루트 도메인 이름을 관리한다. 루트 도메인 이름은 인터넷에서 사용되는 도메인 이름 중 최상위 도메인 이름이다. 루트 도메인 이름은 .(점)으로 표시되며, 예를 들어 보자면 www.aaa.com이라는 도메인 이름의 의 루트 도메인 이름은 .com이다.

Root DNS 서버는 TLD DNS 서버의 IP 주소를 알고 있다. 따라서 사용자가 www.aaa.com이라는 도메인 이름으로 쿼리를 수행할 때, 먼저 Root DNS 서버에 해당 도메인 이름의 TLD DNS 서버가 어디에 있는지 물어본다. 그리고 Root DNS 서버는 TLD DNS 서버의 IP 주소를 반환하고, 이후 사용자의 DNS 쿼리는 해당 TLD DNS 서버로 전달된다.

즉, Root DNS 서버는 인터넷 상의 모든 DNS 서버에 대한 출발점이며, 인터넷 전체 DNS 시스템의 핵심 역할을 담당한다. Root DNS 서버는 전 세계적으로 분산되어 있으며, ICANN(Internet Corporation for Assigned Names and Numbers)에서 관리된다.

TLD DNS 서버는 인터넷에서 사용되는 최상위 도메인 이름(Top-Level Domain)을 관리하는 DNS 서버이다. .com, .org, .edu 등과 같이 최상위 도메인 이름에 대한 DNS 서버로, 각 도메인 이름의 DNS 쿼리를 처리한다.

TLD DNS 서버는 각 TLD 도메인 이름에 대한 IP 주소와 기타 DNS 레코드 정보를 관리한다. 예를 들어, .com 도메인 이름에 대한 TLD DNS 서버는 .com 도메인 이름에 대한 모든 DNS 쿼리를 처리합니다. 이러한 DNS 쿼리는 해당 도메인 이름에 대한 IP 주소를 찾는 것이 주된 목적이다.

TLD DNS 서버는 또한 ICANN(Internet Corporation for Assigned Names and Numbers)에 등록되어 있으며, 해당 TLD 도메인 이름을 사용하는 도메인 이름 등록 업체(Domain Name Registrar)와 협력하여 해당 도메인 이름에 대한 정보를 업데이트한다.

TLD DNS 서버는 Root DNS 서버로부터 요청된 DNS 쿼리를 받는다. Root DNS 서버는 TLD DNS 서버의 IP 주소를 알고 있으며, 이를 통해 사용자가 요청한 도메인 이름의 TLD DNS 서버를 찾아서 DNS 쿼리를 전달한다. TLD DNS 서버는 이후 해당 도메인 이름의 Second-Level DNS 서버를 찾아서 DNS 쿼리를 전달한다.

따라서, TLD DNS 서버는 인터넷 상의 모든 도메인 이름에 대한 DNS 쿼리 처리에서 중요한 역할을 담당합니다. TLD DNS 서버는 전 세계적으로 분산되어 있으며, 도메인 이름 등록 업체와 ICANN에 의해 관리된다.

Second-Level DNS는 DNS의 핵심 요소 중 하나로, 특정 도메인 이름에 대한 IP 주소 정보를 제공하는 DNS 서버이다.

일반적으로 도메인/호스팅 업체의 네임서버를 말한다.

또한 해당 도메인 이름에 대한 정보를 가지고 있는 최종적인 답변자 역할을 한다. 예를 들어 aaa.com 도메인 이름에 대한 IP 주소를 알고 있는 DNS 서버가 있다면, 해당 DNS 서버는 Second-Level DNS 서버가 된다.

DNS record는 Domain Name System(DNS)에서 도메인 이름과 해당 도메인과 연결된 IP 주소를 매핑하는 데 사용되는 데이터 항목이다. DNS 레코드는 도메인 이름과 관련된 정보를 담고 있으며, DNS 쿼리를 수행하는 서버에 의해 사용된다.

DNS 레코드의 유형은 다양하다. 다음은 일반적인 DNS 레코드 유형의 몇 가지 예이다.

• A 레코드: 도메인 이름을 IP 주소로 매핑한다. 이 레코드는 도메인 이름을 IP 주소로 해석하는 데 사용된다..
• CNAME 레코드: 도메인 이름을 다른 도메인 이름으로 매핑한다.. 이 레코드는 도메인 이름을 다른 도메인 이름으로 변경하는 데 사용된다..
• MX 레코드: 도메인 이름과 연결된 메일 서버의 우선 순위를 지정한다. 이 레코드는 이메일을 전송할 때 도메인 이름과 연결된 메일 서버를 찾는 데 사용된다.
• NS 레코드: 도메인 이름에 대한 권한 DNS 서버를 식별한다. 이 레코드는 DNS 쿼리가 수행될 때 도메인 이름에 대한 권한 DNS 서버를 찾는 데 사용된다.
• TXT 레코드: 도메인 이름과 연결된 텍스트 정보를 포함된다. 이 레코드는 보안, 인증 등 다양한 목적으로 사용된다.
• SPF(Sender Policy Framework) 레코드: 이메일 스팸을 방지하기 위해 도메인 이름의 이메일 발송 권한을 확인하는 데 사용된다. SPF 레코드는 도메인 이름을 검색하여 이메일 발송 권한을 확인하고, 이를 통해 도메인 이름의 이메일 스팸을 방지한다.
• SRV(Service) 레코드: DNS 서버가 제공하는 특정 서비스의 위치를 식별하는 데 사용된다. 이 레코드는 웹 서비스, VoIP, FTP 등과 같은 특정 서비스의 위치를 찾는 데 사용된다.
• AAAA 레코드: IPv6 주소를 도메인 이름에 매핑하는 데 사용된다. IPv6는 IPv4의 주소 고갈 문제를 해결하기 위해 개발된 새로운 IP 주소 체계이다.
• SOA(Start of Authority) 레코드: 도메인 이름에 대한 기본 설정을 제공한다. 이 레코드는 도메인 이름의 소유자, DNS 서버, 캐시 된 정보의 유효 기간 등의 정보를 제공한다.
• PTR(Pointer) 레코드: 이 레코드는 IP 주소를 도메인 이름으로 매핑하는 데 사용된다. A 레코드가 도메인 이름을 IP 주소로 매핑하는 반면, PTR 레코드는 IP 주소를 도메인 이름으로 매핑한다. PTR 레코드는 역 DNS (reverse DNS)라고도 하며, 주로 이메일 서버에서 사용된다.. 이메일 서버에서는 전송된 이메일의 IP 주소를 역 DNS 쿼리로 검색하여 해당 IP 주소가 신뢰할 수 있는 소스에서 전송되었는지 확인할 수 있다.

• DNS의 동작원리

Service Mesh는 분산 애플리케이션에서 서비스 간의 통신을 관리하기 위한 인프라스트럭처이다. 마이크로서비스 아키텍처에서는 여러 개의 작은 서비스로 구성된 애플리케이션을 구축하게 되는데, 이러한 작은 서비스들은 서로 통신하면서 애플리케이션을 구성한. 이때, 서비스 간의 통신은 네트워크 상에서 발생하기 때문에 이를 관리하기 위한 인프라스트럭처가 필요하다.

Service Mesh는 이러한 서비스 간의 통신을 추상화하여 관리한다. 즉, 서비스 간의 통신을 위한 네트워크 인프라를 쉽게 관리할 수 있도록 도와준다. Service Mesh는 분산 추적, 보안, 로깅, 부하 분산 등의 기능을 제공하며, 이러한 기능들은 서비스 간의 통신을 안전하고 효율적으로 처리할 수 있도록 도와준다.

Service Mesh를 구현하는 방법에는 여러가지가 있지만, 일반적으로는 사이드카 패턴(Sidecar Pattern)을 사용한다. 사이드카 패턴은 각 서비스 인스턴스에 사이드카 컨테이너를 배치하여, 이를 통해 서비스 간의 통신을 관리한다. 이때, 사이드카 컨테이너는 Service Mesh 솔루션에서 제공하는 프록시나 에이전트로 구성된다.

Istio 또는 Linkerd와 같은 서비스 메시는 Kubernetes 환경에서 자주 사용된다.

• 분산 추적: 서비스 간의 통신을 추적하고 분석하여, 문제 발생 시 신속한 대응이 가능하다.
• 보안: 트래픽 암호화, 인증, 인가, 접근 제어 등의 기능을 제공하여, 보안성을 향상시킨다.
• 로깅: 서비스 간의 통신 내역을 기록하여, 문제 해결에 도움을 준다.
• 부하 분산: 트래픽을 여러 서비스 인스턴스로 분산시켜, 안정적인 서비스 제공을 가능하게 한다.

주요 Service Mesh 솔루션으로는 Istio, Linkerd, Consul 등이 있다. 이러한 솔루션을 사용하면, Service Mesh를 쉽게 구현하고 운영할 수 있다.

API Gateway는 마이크로서비스 아키텍처에서 여러 개의 서비스를 하나의 API로 노출시키는 역할을 하는 서비스이다. 클라이언트는 API Gateway에 HTTP 요청을 보내면, API Gateway는 내부의 여러 서비스를 호출하고, 그 결과를 적절히 변환하여 클라이언트에게 전달한다.

• 인증과 인가: 클라이언트의 요청을 검증하고, 사용자 인증과 권한 검사를 수행한다. 이를 통해 보안적인 측면에서 안전한 API를 제공할 수 있다.
• 로드 밸런싱: 여러 개의 서비스를 처리할 때, 요청을 분산하여 각각의 서비스에 고르게 전달한다. 이를 통해 각 서비스의 부하를 분산시킬 수 있고, 가용성을 향상시킬 수 있다.
• 캐싱: 반복적인 요청에 대해 빠른 응답을 제공하기 위해, API Gateway는 캐시를 활용하여 서비스의 부하를 줄인다.
• 로깅과 모니터링: API Gateway는 클라이언트의 요청 및 서비스의 응답 등을 기록하고 모니터링할 수 있다. 이를 통해 문제 발생 시 즉각적으로 대응할 수 있다.
• API 관리: API Gateway는 API를 관리하고 버전을 관리할 수 있다. 새로운 버전의 API를 배포하거나, 이전 버전의 API를 제거할 수 있다.

API Gateway는 마이크로서비스 아키텍처에서 필수적인 서비스로, 다양한 기능과 유연성을 제공하여 애플리케이션을 효율적으로 관리하고 운영할 수 있다.

API Gateway와 Service Mesh는 모두 분산 애플리케이션에서 서비스 간의 통신을 관리하기 위한 도구이다. 하지만 둘은 목적과 구현 방법에서 차이가 있다.

API Gateway는 클라이언트와 백엔드 서비스 간의 통신을 중개하는 서버이다. 클라이언트는 API Gateway를 통해 백엔드 서비스에 요청을 보내며, API Gateway는 해당 요청을 수신하여 필요한 인증, 인가, 로깅 등의 처리를 수행한 뒤에 백엔드 서비스에 전달한다. API Gateway는 단일 진입점(Single Entry Point)을 제공하여 클라이언트와 백엔드 서비스 간의 통신을 간소화하고, 보안과 모니터링을 향상시킬 수 있다.

반면에, Service Mesh는 분산 애플리케이션 내부의 서비스 간의 통신을 관리한다. 각 서비스 인스턴스에 사이드카 컨테이너를 배치하여, 이를 통해 서비스 간의 통신을 중개한다. Service Mesh는 분산 추적, 보안, 로깅, 부하 분산 등의 기능을 제공하여 서비스 간의 통신을 안전하고 효율적으로 처리할 수 있도록 도와준다.

따라서, API Gateway는 클라이언트와 백엔드 서비스 간의 통신을 중개하는 서버로서, 외부에서 액세스하는 서비스를 관리하고 보호하는데 사용되며, Service Mesh는 분산 애플리케이션 내부의 서비스 간의 통신을 관리하여, 분산 애플리케이션을 보호하고 안정적으로 운영하는데 사용된다.

• Service Mesh vs Api Gateway

역방향 프록시(Reverse Proxy) 는 웹 서버 앞에 앉아 클라이언트(예: 웹 브라우저) 요청을 웹 서버에 전달하는 서버의 한 유형이다. 역방향 프록시와 순방향 프록시의 주요 차이점은 서비스의 방향에 있다. 순방향 프록시는 사용자와 인터넷의 방대한 자원 사이의 게이트웨이 역할을 하는 반면, 역방향 프록시는 인터넷과 더 작은 서버 그룹 사이의 게이트웨이 역할을 한다.

• 로드 밸런싱(Load Balancing): 클라이언트 요청을 여러 서버에 분산하여 로드 균형을 조정하여 리소스의 속도와 안정성을 향상시킨다.
• 글로벌 서버 로드 밸런싱(Global Server Load Balancing): 여기에는 클라이언트의 지리적 위치를 기반으로 가장 가까운 서버로 클라이언트 요청을 라우팅하여 사용자 응답 시간을 향상시키는 작업이 포함된다.
• SSL 암호화(SSL Encryption): SSL 인증서 관리를 개별 서버에서 관리하는 대신 한 곳에서 중앙 집중화한다.
• 콘텐츠 캐싱(Caching Content): 웹 서버에서 캐시된 정적 및 동적 콘텐츠를 제공하여 서버 로드를 줄인다.
• 압축(Compression): 파일을 클라이언트에 보내기 전에 압축하여 응답 대역폭을 줄인다.
• 보안 및 익명성(Security and Anonymity): 백엔드 서버의 특성과 출처를 숨겨 보안을 제공한다.

Nginx는 웹 서버, 로드 밸런서, HTTP 캐시 및 메일 프록시로 사용되는 것 외에도 세계에서 가장 인기 있는 역방향 프록시 서버 중 하나이다. 고성능, 안정성, 풍부한 기능 세트, 간단한 구성 및 낮은 리소스 소비로 잘 알려져 있다.

http {
    upstream backend {
        server backend1.example.com weight=5;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

• upstream backend 는 서로 다른 가중치를 갖는 서버 백엔드 그룹을 정의한다(지정되지 않은 경우 각각의 가중치는 동일함). 이를 통해 Nginx는 트래픽을 다른 서버로 전달할 뿐만 아니라 가중치가 더 높은 서버에 더 많은 트래픽을 할당함으로써 로드를 분산할 수 있다.
• proxy_pass 지시어는 요청을 업스트림 서버 그룹에 전달한다.
• proxy_set_header 지시문은 백엔드 서버에 전달되는 요청 헤더를 수정합니다. 여기에는 실제 클라이언트 IP 주소 및 기타 세부 정보를 백엔드로 전달하는 것이 포함될 수 있다.

STP(Spanning Tree Protocol) 및 RSTP(Rapid Spanning Tree Protocol)는 네트워크 환경에서 루프 상태를 방지하는 데 사용되는 두 가지 네트워크 프로토콜이다. 이는 스위치 간 다중 경로를 포함하는 이더넷 네트워크에서 특히 중요하다.

IEEE 802.1D로 표준화된 STP는 이더넷 네트워크를 위한 루프 없는 토폴로지를 유지하도록 설계되었다. 이것은 루프를 야기할 수 있는 중복 경로들 중 일부를 선택적으로 차단함으로써 작동한다. STP는 활성 링크가 실패할 경우, 브리지 루프나 그와 연관된 방송 방사의 위험 없이, 내결함성 및 자동 백업 경로 활성화를 제공하기 위해 네트워크 설계를 포함하도록 한다.

작동방식은 아래와 같다.

• 루트 브리지 선택(Root Bridge Selection): 모든 스위치는 선택 프로세스에 참여하여 네트워크의 논리적 중심인 루트 브리지를 선택한다. 브리지 ID가 가장 낮은 스위치가 루트가 된다.
• 경로 선택(Path Selection): 각 스위치는 경로 비용을 기준으로 자체에서 루트 브리지까지의 최단 경로를 결정한다.
• 중복 경로 차단(Blocking Redundant Paths): 루프를 방지하기 위해 STP는 루프를 형성할 수 있는 중복 경로를 차단하지만 이를 백업 링크로 유지한다.
• 포트 상태 및 역할(ort States and Roles): STP 토폴로지의 포트는 차단, 듣기, 학습, 전달 또는 비활성화와 같은 여러 상태 중 하나일 수 있다. 루트 브리지가 아닌 각 포트에는 루트 포트(루트 브리지에 도달하는 가장 좋은 포트), 지정된 포트(네트워크 세그먼트를 오가는 포트 전달 프레임) 또는 지정되지 않은 포트(차단된 포트) 중 하나의 역할이 있다.

IEEE 802.1w에 정의된 RSTP는 네트워크 변경 시 더 빠른 수렴을 제공하는 STP의 진화형이다. 표준 STP와 역호환되도록 설계되었다.

작동방식은 아래와 같다.

• Faster Convergence: RSTP는 빠른 상태 전환을 통해 더 빠른 수렴을 달성할 수 있다. 새로운 포트 역할과 상태를 도입하여 타이머가 만료될 때까지 기다리지 않고도 스위치가 포트를 전달 상태로 안전하게 이동할 수 있는지 적극적으로 확인할 수 있다.
• 포트 역할(Port Roles): RSTP는 루트 포트, 지정 포트, 대체 포트(루트 포트로 백업), 백업 포트(지정 포트로 백업)와 같은 역할을 정의한다.
• 포트 상태(Port States): RSTP는 STP의 5개 포트 상태(폐기, 학습 및 전달)에 비해 3개 포트 상태만 사용한다.
• 에지 포트(Edge Ports): 엔드 스테이션에 직접 연결된 포트는 네트워크 루프를 생성할 가능성이 없으므로 이러한 포트를 에지 포트로 구성하여 기존 청취/학습 상태를 우회하고 전달 상태로 직접 전환할 수 있다.
• 링크 유형(Link Type): RSTP는 링크 유형도 식별할 수 있으며 링크가 지점 간 링크인 경우 RSTP는 해당 링크의 수렴 속도를 높인다.

이점은 아래와 같다. 네트워크 변경이나 장애에 대응하여 훨씬 더 빠른 복구를 제공하여 많은 경우에 수십 초(STP 사용)에서 1초 미만으로 시간을 단축한다. 네트워크 문제 해결을 단순화하고 네트워크 안정성과 성능을 향상시킨다.

요약하면 STP는 네트워크 루프를 방지하는 데 효과적이지만 RSTP는 더 빠른 수렴을 제공하여 STP를 개선한다. 이는 가동 중지 시간을 최소화하는 것이 중요한 네트워크에서 매우 중요할 수 있다.

Hub & Spoke 네트워크 아키텍처는 중앙 집중식 관리와 효율적인 연결 사용이 필요한 다양한 분야에 적용되는 기본 설계이다. 중앙 지점을 강력하게 관리할 수 있고 네트워크 인프라를 효율적으로 확장하려는 조직에 적합하다.

• 허브(Hub): 네트워크의 다른 모든 노드에 대한 공통 연결 지점 역할을 하는 중앙 노드이다. 허브는 모든 데이터가 통과하는 네트워크의 핵심으로, 데이터 흐름을 관리하는 구심점 역할을 한다.
• 스포크(Spoke): 허브에 연결된 노드이다. 각 스포크는 허브에만 연결되며 다른 스포크에는 연결되지 않는다. 이 설정은 노드 간의 연결 수를 줄여 전체 네트워크 설계를 단순화한다.

• 중앙 집중식 관리(Centralized Management): Hub & Spoke 아키텍처를 사용하면 중앙 집중식 관리가 가능하므로 정책을 더 쉽게 구현하고 네트워크 활동을 모니터링할 수 있다.
• 리소스 사용의 효율성(Efficiency in Resource Use): 리소스를 허브에 중앙 집중화함으로써 네트워크는 대역폭을 효율적으로 관리하고 트래픽 우선 순위를 지정할 수 있으며 이는 특히 WAN(광역 네트워크)에 유용하다.
• 확장성(Scalability): 새 스포크를 추가하는 것은 기존 스포크 연결에 영향을 주지 않고 허브에서 새 노드로 라인을 확장하는 작업이므로 비교적 간단하다.

• 장점
  • 간단한 인프라(Simplified Infrastructure): 여러 노드 간의 직접 연결을 최소화하여 여러 노드를 연결하는 복잡성을 줄인다.
  • 비용 효율적(Cost-Effective): 각 노드가 다른 모든 노드와 직접 연결되는 완전 메시형 네트워크에 비해 케이블 연결이나 라우팅이 덜 필요하다.
  • 유지 관리 및 문제 해결(Easier Maintenance and Troubleshooting): 허브에서 관리 기능을 중앙 집중화하면 업데이트 배포 및 문제 해결이 더 쉬워진다.
• 단점
  • 단일 실패 지점(Single Point of Failure): 허브가 중요한 실패 지점이 된다. 허브가 다운되면 스포크 전체의 모든 연결이 끊어질 수 있다.
  • 잠재적인 병목 현상(Potential Bottlenecks): 제대로 장착되지 않은 경우, 특히 네트워크 트래픽이 매우 높은 경우 허브에 병목 현상이 발생하여 성능과 속도에 영향을 미칠 수 있다.
• 확장 허브 및 스포크(Extended Hub & Spoke): 때로는 로드를 분산하고 중복성을 제공하기 위해 보조 허브가 도입되어 단일 허브 시스템에 내재된 위험 중 일부를 완화할 수 있다.

IPsec(인터넷 프로토콜 보안) 및 SSL(보안 소켓 레이어) 은 모두 네트워크 트래픽을 보호하는 데 사용되는 프로토콜이다. 이는 인터넷을 통해 데이터 무결성, 기밀성 및 신뢰성을 제공하지만 네트워크 스택의 다양한 계층에서 작동한다.

IPsec은 통신 세션의 각 IP 패킷을 인증하고 암호화하여 인터넷 프로토콜(IP) 통신을 보호하기 위한 프로토콜 모음이다. IPsec에는 세션 시작 시 에이전트 간 상호 인증을 설정하고 세션 중에 사용할 암호화 키를 협상하기 위한 프로토콜이 포함되어 있다.

• 네트워크 계층 보안(Network Layer Security): IPsec은 IP 계층에서 작동하므로 이를 통과하는 모든 트래픽을 보호할 수 있으므로 VPN에 적합하다.
• 암호화 및 인증(Encryption and Authentication): 두 가지 작동 모드를 제공합니다. 전송 모드(encrypts the payload only) 및 터널 모드(encrypts the entire IP packet).
• 다양한 애플리케이션(Versatile in Application): 인터넷과 같이 신뢰할 수 없는 네트워크에서 보안 네트워크(VPN)를 만드는 데 사용할 수 있다.

SSL(and its successor, TLS - Transport Layer Security)은 네트워크로 연결된 컴퓨터 간의 연결을 보호하기 위한 프로토콜이다. 원래는 HTTP 트래픽용으로 설계되었지만 인터넷을 통한 다양한 유형의 통신을 보호하는 데 사용된다.

• 세션 계층 보안(Session Layer Security): SSL은 세션 계층에서 작동하지만 SSL을 활용하도록 설계된 특정 애플리케이션을 보호한다.
• 암호화, 인증 및 무결성(Encryption, Authentication, and Integrity): SSL은 데이터가 인터넷을 통해 전송되기 전에 암호화 알고리즘을 사용하여 데이터를 암호화하고 인증을 위해 인증서를 사용한다.
• 보안 웹 브라우징에 널리 사용됨(Widely Used for Secure Web Browsing): 일반적으로 신용 카드 거래, 데이터 전송 및 웹 사이트 로그인을 보호하는 데 사용된다.

• 운영 계층(Layer of Operation): IPsec은 네트워크 계층에서 작동하여 통과하는 모든 트래픽을 보호한다. SSL은 세션 계층에서 작동하여 사용자와 애플리케이션 간의 특정 세션을 보호한다.
• 인증서 관리(Management of Certificates): SSL은 일반적으로 신뢰할 수 있는 인증 기관의 계층 구조를 사용하여 엔드포인트의 ID를 인증한다. IPsec은 인증서를 사용할 수도 있지만 사전 공유 키나 다른 형태의 네트워크 수준 인증을 통해 관리되는 경우가 많다.
• 유연성 및 설정(Flexibility and Setup): SSL은 일반적으로 애플리케이션별로 설정하고 관리하기가 더 쉬운 것으로 간주된다. 네트워크 아키텍처에 통합되는 IPsec은 더 많은 설정이 필요하고 보안 애플리케이션이 덜 세분화되어 있지만 더 넓은 적용 범위를 제공한다.
• 사용 시나리오(Usage Scenarios): IPsec은 전체 네트워크 트래픽의 보안이 필요한 VPN에 선호된다. SSL은 특히 HTTP(HTTPS)를 통한 웹 사이트 보안과 같은 특정 애플리케이션에 선호된다.

질문: 웹 애플리케이션으로 HTTP 요청이 전달되는 과정을 패킷 레벨에서 설명하세요. Kubernetes 환경과 일반 EC2 인스턴스 환경을 비교하여 각 단계에서의 헤더 변화와 네트워크 컴포넌트를 설명하세요.

답변:

[클라이언트] 
    ↓
[인터넷 게이트웨이]
    ↓
[ALB (Application Load Balancer)]
    ↓
[EC2 인스턴스 (웹 서버)]

Step 1: 클라이언트 → ALB

클라이언트 측 패킷 구조:
┌─────────────────────────────────────────────────────┐
│ Ethernet Header                                      │
│  - Src MAC: 클라이언트 MAC (aa:bb:cc:dd:ee:ff)      │
│  - Dst MAC: 게이트웨이 MAC (11:22:33:44:55:66)      │
├─────────────────────────────────────────────────────┤
│ IP Header                                            │
│  - Src IP: 클라이언트 IP (203.0.113.100)            │
│  - Dst IP: ALB Public IP (54.230.10.20)             │
│  - Protocol: TCP (6)                                 │
│  - TTL: 64                                           │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 50001 (ephemeral)                      │
│  - Dst Port: 443 (HTTPS)                            │
│  - Seq: 1000, Ack: 0                                │
│  - Flags: SYN                                        │
│  - Window: 65535                                     │
├─────────────────────────────────────────────────────┤
│ TLS Client Hello (Application Layer)                │
│  - SNI: example.com                                  │
│  - Cipher Suites                                     │
└─────────────────────────────────────────────────────┘

경로: 클라이언트 → ISP → AWS Edge Location → IGW → ALB

Step 2: ALB → EC2 인스턴스

ALB에서 EC2로 전송되는 패킷:
┌─────────────────────────────────────────────────────┐
│ Ethernet Header (VPC 내부)                           │
│  - Src MAC: ALB ENI MAC (aa:aa:aa:aa:aa:aa)         │
│  - Dst MAC: EC2 ENI MAC (bb:bb:bb:bb:bb:bb)         │
├─────────────────────────────────────────────────────┤
│ IP Header                                            │
│  - Src IP: ALB Private IP (10.0.1.100)              │
│  - Dst IP: EC2 Private IP (10.0.2.50)               │
│  - Protocol: TCP (6)                                 │
│  - TTL: 63 (감소)                                    │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 45678 (ALB ephemeral)                  │
│  - Dst Port: 8080 (애플리케이션)                     │
│  - Seq: 2000, Ack: 1500                             │
│  - Flags: PSH, ACK                                   │
├─────────────────────────────────────────────────────┤
│ HTTP Request (평문 또는 ALB에서 TLS 종료)            │
│  GET /api/users HTTP/1.1                            │
│  Host: example.com                                   │
│  X-Forwarded-For: 203.0.113.100                     │
│  X-Forwarded-Proto: https                            │
└─────────────────────────────────────────────────────┘

주요 변경사항:
✓ TLS 종료: ALB에서 HTTPS → HTTP 변환 (선택사항)
✓ Source IP: 클라이언트 IP → ALB IP
✓ 헤더 추가: X-Forwarded-For로 원본 클라이언트 IP 전달
✓ 커넥션 풀: ALB와 EC2 간 Keep-Alive 연결 재사용

Step 3: EC2 응답 → 클라이언트

EC2 → ALB:
┌─────────────────────────────────────────────────────┐
│ IP Header                                            │
│  - Src IP: 10.0.2.50 (EC2)                          │
│  - Dst IP: 10.0.1.100 (ALB)                         │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 8080                                    │
│  - Dst Port: 45678                                   │
├─────────────────────────────────────────────────────┤
│ HTTP Response                                        │
│  HTTP/1.1 200 OK                                     │
│  Content-Type: application/json                      │
│  {"users": [...]}                                    │
└─────────────────────────────────────────────────────┘

ALB → 클라이언트:
┌─────────────────────────────────────────────────────┐
│ IP Header                                            │
│  - Src IP: 54.230.10.20 (ALB Public)                │
│  - Dst IP: 203.0.113.100 (클라이언트)               │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 443                                     │
│  - Dst Port: 50001                                   │
├─────────────────────────────────────────────────────┤
│ TLS Encrypted HTTP Response                         │
│  (ALB에서 다시 TLS 암호화)                           │
└─────────────────────────────────────────────────────┘

[클라이언트]
    ↓
[인터넷 게이트웨이]
    ↓
[NLB/ALB (Ingress)]
    ↓
[Kubernetes Service (ClusterIP)]
    ↓
[kube-proxy (iptables/IPVS)]
    ↓
[CNI (Calico/Cilium/AWS VPC CNI)]
    ↓
[Pod Network Namespace]
    ↓
[Container (애플리케이션)]

Step 1: 클라이언트 → NLB/ALB (Ingress)

일반 인스턴스와 동일:
┌─────────────────────────────────────────────────────┐
│ Ethernet Header                                      │
│ IP Header                                            │
│  - Src IP: 203.0.113.100                            │
│  - Dst IP: NLB Public IP (52.200.10.30)             │
│ TCP Header                                           │
│  - Dst Port: 443                                     │
│ TLS/HTTP Request                                     │
└─────────────────────────────────────────────────────┘

Step 2: NLB → Kubernetes NodePort

NLB가 워커 노드의 NodePort로 전송:
┌─────────────────────────────────────────────────────┐
│ IP Header                                            │
│  - Src IP: NLB Private IP (10.0.1.50)               │
│  - Dst IP: Worker Node IP (10.0.3.100)              │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 54321                                   │
│  - Dst Port: 30080 (NodePort)                       │
├─────────────────────────────────────────────────────┤
│ HTTP Request (Ingress Controller가 TLS 종료)        │
└─────────────────────────────────────────────────────┘

NodePort 매핑:
- Service Type: NodePort
- 모든 워커 노드의 30080 포트가 열림
- kube-proxy가 iptables 규칙 생성

Step 3: kube-proxy iptables NAT 처리

# kube-proxy가 생성한 iptables 규칙 예시
iptables -t nat -A KUBE-SERVICES -p tcp --dport 30080 \
  -j KUBE-SVC-ABCD1234

iptables -t nat -A KUBE-SVC-ABCD1234 -m statistic \
  --mode random --probability 0.33 -j KUBE-SEP-POD1

iptables -t nat -A KUBE-SEP-POD1 -p tcp \
  -j DNAT --to-destination 10.244.1.50:8080

패킷 변환 과정:

NodePort 진입 후 DNAT 적용:
┌─────────────────────────────────────────────────────┐
│ IP Header (DNAT 후)                                  │
│  - Src IP: 10.0.1.50 (NLB) [SNAT 가능]              │
│  - Dst IP: 10.244.1.50 (Pod IP) ← 변경됨!           │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 54321                                   │
│  - Dst Port: 8080 ← 변경됨! (NodePort → Container)  │
├─────────────────────────────────────────────────────┤
│ HTTP Request                                         │
└─────────────────────────────────────────────────────┘

주요 변경:
✓ Destination IP: 노드 IP → Pod IP (10.244.x.x 대역)
✓ Destination Port: 30080 → 8080
✓ kube-proxy가 로드밸런싱 (Pod 3개 중 랜덤 선택)

Step 4: CNI 네트워크 라우팅 (AWS VPC CNI 예시)

AWS VPC CNI 동작:
┌─────────────────────────────────────────────────────┐
│ 워커 노드 라우팅 테이블                              │
│  10.244.1.0/24 → veth1234abcd (Pod veth pair)       │
│  10.244.2.0/24 → 다른 노드 (노드 간 라우팅)         │
└─────────────────────────────────────────────────────┘

# 노드에서 라우팅 확인
ip route show
# 10.244.1.50 dev veth1234abcd scope link

패킷이 veth pair를 통해 Pod Network Namespace로 전달:
┌──────────────────────────────────────┐
│ Host Network Namespace               │
│   eth0 (10.0.3.100)                  │
│   veth1234abcd ← 호스트 측 인터페이스│
└──────────┬───────────────────────────┘
           │ veth pair
┌──────────▼───────────────────────────┐
│ Pod Network Namespace                │
│   eth0@if5 (10.244.1.50) ← Pod 측    │
│   Container Process (PID 1)          │
└──────────────────────────────────────┘

Step 5: Pod 내부 수신

Pod 내 컨테이너가 수신하는 패킷:
┌─────────────────────────────────────────────────────┐
│ Ethernet Header (veth)                               │
│  - Src MAC: veth host side                          │
│  - Dst MAC: veth pod side                           │
├─────────────────────────────────────────────────────┤
│ IP Header                                            │
│  - Src IP: 10.0.1.50 (또는 SNAT된 IP)               │
│  - Dst IP: 10.244.1.50 (Pod IP)                     │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 54321                                   │
│  - Dst Port: 8080                                    │
├─────────────────────────────────────────────────────┤
│ HTTP Request                                         │
│  GET /api/users HTTP/1.1                            │
│  Host: example.com                                   │
│  X-Forwarded-For: 203.0.113.100                     │
│  X-Real-IP: 203.0.113.100                           │
└─────────────────────────────────────────────────────┘

컨테이너 수신 과정:
1. 커널이 netfilter 체인 통과 (PREROUTING → INPUT)
2. Socket Buffer에 패킷 저장
3. 애플리케이션이 read() 시스템 콜로 수신

Step 6: 응답 경로 (역방향)

Pod → kube-proxy → Node → NLB → 클라이언트

Pod 송신:
┌─────────────────────────────────────────────────────┐
│ IP Header                                            │
│  - Src IP: 10.244.1.50 (Pod)                        │
│  - Dst IP: 10.0.1.50 (NLB)                          │
├─────────────────────────────────────────────────────┤
│ HTTP Response 200 OK                                │
└─────────────────────────────────────────────────────┘

kube-proxy SNAT 역변환:
┌─────────────────────────────────────────────────────┐
│ IP Header (SNAT 후)                                 │
│  - Src IP: 10.0.3.100 (Node IP) ← 변경됨!           │
│  - Dst IP: 10.0.1.50 (NLB)                          │
├─────────────────────────────────────────────────────┤
│ TCP Header                                           │
│  - Src Port: 30080 ← 복원됨!                        │
└─────────────────────────────────────────────────────┘

NLB → 클라이언트:
- NLB가 Source IP를 자신의 Public IP로 변경
- 클라이언트에게 응답 전달

# 1. Pod 찾기
kubectl get pods -o wide
# NAME                     READY   STATUS    IP            NODE
# webapp-7d8f9c-abcd       1/1     Running   10.244.1.50   node-1

# 2. Pod의 Network Namespace 확인
kubectl exec webapp-7d8f9c-abcd -- cat /proc/1/ns/net
# net:[4026532456]

# 3. 워커 노드에 SSH 접속 후 Pod Network Namespace에서 tcpdump
NODE_IP=$(kubectl get pod webapp-7d8f9c-abcd -o jsonpath='{.status.hostIP}')
ssh ec2-user@$NODE_IP

# Pod의 PID 찾기
docker inspect --format '{{.State.Pid}}' $(docker ps | grep webapp | awk '{print $1}')
# 12345

# nsenter로 Pod Network Namespace 진입
sudo nsenter -t 12345 -n tcpdump -i eth0 -nn port 8080

# 출력 예시:
# 10.0.1.50.54321 > 10.244.1.50.8080: Flags [P.], seq 1:100, ack 1, win 502
# GET /api/users HTTP/1.1

# Service → Endpoint 매핑 확인
kubectl get svc webapp-service -o yaml
# clusterIP: 10.96.10.20
# ports:
# - port: 80
#   targetPort: 8080
#   nodePort: 30080

# iptables NAT 체인 확인
sudo iptables -t nat -L KUBE-SERVICES -n | grep 10.96.10.20
# KUBE-SVC-ABC123 tcp -- 0.0.0.0/0 10.96.10.20 tcp dpt:80

sudo iptables -t nat -L KUBE-SVC-ABC123 -n
# KUBE-SEP-POD1 all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.33
# KUBE-SEP-POD2 all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50
# KUBE-SEP-POD3 all -- 0.0.0.0/0 0.0.0.0/0

sudo iptables -t nat -L KUBE-SEP-POD1 -n
# DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.1.50:8080

# AWS VPC CNI: Secondary IP 방식
ip addr show eth0
# eth0: <BROADCAST,MULTICAST,UP>
#     inet 10.0.3.100/24 (Primary)
#     inet 10.244.1.50/32 (Pod IP - Secondary)

ip route show
# 10.244.1.50 dev eth0 scope link

# Calico: IP-in-IP 터널링
ip route show
# 10.244.2.0/24 via 10.0.3.101 dev tunl0 proto bird onlink

# Cilium: eBPF 기반 (iptables 우회)
cilium bpf lb list
# 10.96.10.20:80 => 
#   10.244.1.50:8080 (1/3)
#   10.244.2.30:8080 (1/3)
#   10.244.3.10:8080 (1/3)

• 네트워크 홉 수 적음 (낮은 레이턴시)
• NAT/DNAT 오버헤드 없음
• 단순한 디버깅 (단일 네트워크 네임스페이스)

• Pod 간 네트워크 격리 (보안)
• Service Discovery (DNS 자동화)
• 동적 로드밸런싱 (Pod Autoscaling)
• Network Policy로 마이크로세그먼테이션

# externalTrafficPolicy: Local (Source IP 보존 + 노드 간 홉 제거)
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local  # ← 패킷이 로컬 노드 Pod로만 전달
  ports:
  - port: 80
    targetPort: 8080

패킷 경로 차이:

Cluster (기본값):
클라이언트 → NLB → Node1 → kube-proxy → Node2 Pod (노드 간 이동 가능)

Local:
클라이언트 → NLB → Node1 → kube-proxy → Node1 Pod (동일 노드만)
                   → Node2 → kube-proxy → Node2 Pod

디버깅 시나리오:

# 문제: Pod로 트래픽이 안 들어옴

# 1. Service Endpoint 확인
kubectl get endpoints webapp-service
# NAME              ENDPOINTS
# webapp-service    10.244.1.50:8080,10.244.2.30:8080

# 2. kube-proxy 로그 확인
kubectl logs -n kube-system kube-proxy-xxxx
# I0106 sync iptables rules for service webapp-service

# 3. Pod에서 tcpdump (헬퍼 컨테이너 사용)
kubectl debug webapp-7d8f9c-abcd -it --image=nicolaka/netshoot
# 디버그 Pod에서:
tcpdump -i eth0 -nn port 8080

# 4. 노드에서 iptables NAT 추적
sudo iptables -t nat -nvL | grep 10.244.1.50
# 패킷 카운터 확인 (pkts bytes)

# 5. conntrack 테이블 확인
sudo conntrack -L | grep 10.244.1.50
# tcp 6 117 ESTABLISHED src=10.0.1.50 dst=10.244.1.50

• ← KR_네트워크.md로 돌아가기