> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/2-1.-networks.md). # 2-1. Networks 데이터를 송수신 하는 네트워크에 대하여 ### 📌 Networks Theory ### 1. CDN(Content Delivery Network)의 정의와 트래픽 분산 메커니즘 * CDN은 콘텐츠 전송 네트워크를 의미하며, 콘텐츠를 사용자에 더 빠르고 안정적으로 전달하기 위해 고안된 분산 네트워크 시스템이다. * 웹사이트의 이미지, 동영상, CSS, 자바스크립트 파일 등 정적인 자원들을 전 세계 각지에 분산 배치된 여러 엣지 서버(Edge Server)에 복제하여 등록하고 관리한다. * 작동 메커니즘: 사용자가 특정 콘텐츠를 요청하면 오리진(Origin) 서버로 매번 신호가 가는 것이 아니라, 사용자의 물리적 위치와 가장 가까운 엣지 서버를 찾아내어 캐싱된 콘텐츠를 즉시 전달한다. 이를 통해 백엔드 서버의 트래픽 부하를 파격적으로 분산시키고 서버 다운 등의 대형 장애를 미연에 방지한다. * 도입 시 고려사항: 외부 제 3자 캐시 제공 기업에 물리적인 클라우드(Cloud) 이용 비용을 추가로 지불해야 하므로 비용 최적화가 필요하며, 빈번하게 변경되는 동적 데이터가 아닌 성능 향상에 적절하고 고정된 정적 콘텐츠 위주로 정밀하게 선별하여 캐싱 아키텍처를 설계해야 한다. ### 2. DNS(Domain Name System)의 변환 체계와 서비스 추상화 가치 * DNS는 도메인 네임 시스템을 의미하며, 숫자로 구성되어 사람이 기억하기 힘든 물리적인 IP 주소를 문자로 된 도메인 이름(예: example.com)으로 상호 변환해 주는 거대한 분산 데이터베이스 시스템이다. * 서비스 추상화 가치: 이는 인프라 아키텍처에서 게이트웨이(Gateway) 서버에 서비스를 등록할 때, 하드웨어의 물리적인 IP 주소를 기재하지 않고 추상화된 고유 Service ID로 등록하여 제어하는 체계와 완벽히 일치하는 맥락을 공유한다. * 클라이언트 유연성 확보: 만약 DNS가 없다면 클라이언트는 서버의 장비 교체, 스케일 아웃, 장애 복구 등으로 인해 계속해서 변동하는 물리적 IP 주소를 매번 알아내어 수동으로 코드를 수정해야 한다. * 추상화 통신 메커니즘: DNS를 통하면 클라이언트는 변동하는 하부의 물리적 주소를 전혀 신경 쓸 필요 없이 변하지 않는 단 하나의 도메인 이름(Service ID)만을 바라보면 된다. 이 이름을 이표로 삼아 유연하고 추상화된 체계 하에 안정적으로 네트워크 통신을 완수할 수 있게 된다. ### 3. 회선 교환 네트워크(Circuit Switching)와 패킷 교환 네트워크(Packet Switching)의 아키텍처 차이 * 회선 교환 네트워크: 통신을 원하는 두 엔드 포인트 사이에 물리적인 전용 통신 회선(Circuit)을 미리 완전히 할당하고 점유하여 통신하는 방식이다. * 작동 특성: 연결이 유효한 동안 해당 회선은 다른 사용자가 절대 사용할 수 없도록 독점된다. 과거의 전통적인 전화망이 이에 해당한다. * 장단점: 대용량 데이터나 실시간 음성 통신 시 지연(Delay)이 없고 전송 품질이 보장된다는 장점이 있으나, 통신하지 않는 대기 시간에도 회선이 낭비되므로 네트워크 전체의 자원 이용 효율성이 매우 떨어진다는 치명적인 단점이 존재한다. * 패킷 교환 네트워크: 전용 회선을 개설하지 않고, 전송할 데이터를 패킷(Packet)이라는 일정한 크기의 작은 단위로 쪼개어 네트워크망에 전송하는 방식이다. * 작동 특성: 각 패킷에는 출발지 주소, 목적지 주소, 순서 제어 번호 등이 담긴 헤더가 부착된다. 패킷들은 네트워크 라우터들을 거치며 독립적으로 가장 최적의 경로를 찾아 이동한다. 오늘날 인터넷망의 근간이 되는 형태다. * 장단점: 하나의 물리적 회선을 여러 사용자의 패킷들이 실시간으로 공유하며 동적으로 나누어 쓰므로 네트워크 자원 효율성이 극대화된다. 다만, 네트워크 트래픽이 한꺼번에 몰릴 경우 패킷의 도착 지연이나 손실이 발생할 수 있는 가변성을 지닌다. ### 4. 소켓(Socket)과 패킷(Packet)의 물리적 정의와 커널-애플리케이션 간 제어 역할 * 소켓은 프로그램이 네트워크를 통해 데이터를 주고받을 수 있도록 운영체제(OS)가 제공하는 추상화된 통신 창구이자 API 구현체다. 전송 계층 프로토콜을 사용하기 위한 네트워크 엔드 포인트(연결 지점) 인터페이스 일종이다. * 자바 개발 코드 표준 예시: Socket socket = new Socket("example.com", 80); OutputStream out = socket.getOutputStream(); out.write("hello".getBytes()); * 위 코드와 같이 애플리케이션 프로그래밍 레벨에서 소켓 객체를 생성하고 스트림에 데이터를 밀어 넣으면, 운영체제 커널이 이를 인지하여 하부의 물리적인 네트워크 제어망으로 데이터를 안전하게 송출하는 중계 인터페이스 역할을 수행한다. * 패킷은 네트워크 통신 간에 물리적 선로를 타고 실제로 이동하는 메시지이자 데이터의 최소 전송 단위다. 애플리케이션이 소켓을 통해 내보내는 거대한 데이터 덩어리들은 운영체제 커널의 전송 규격에 따라 잘게 쪼개져 패킷 형태로 네트워크망을 이동한다. ### 5. OSI 7계층(OSI 7 Layer)의 상세 구조, 계층별 역할 및 상호작용 메커니즘 * OSI 7계층은 국제표준화기구(ISO)에서 개발한 네트워크 통신 프레임워크 표준 모델로, 통신 과정을 7개의 독립적인 계층으로 나누어 각 계층이 고유한 역할을 수행하고 인터페이스를 통해 상하위 계층과 유기적으로 상호작용하도록 명세한 체계다. * 1계층 - 물리 계층(Physical Layer): 상위 계층에서 내려온 데이터를 물리적인 전송 매체(케이블, 광섬유 등)를 통해 신호로 변환하여 전송하는 계층이다. 데이터 단위는 비트(Bit)이며, 단지 전기적 신호를 송수신하는 하드웨어적 역할만 수행한다. * 2계층 - 데이터 링크 계층(Data Link Layer): 물리적인 네트워크 사이의 안전한 데이터 전송을 보장하고 흐름을 제어하는 계층이다. 물리 주소인 MAC 주소를 사용하여 이웃한 장비 간의 통신을 제어하며, 에러 검출 및 재전송 기능을 수행한다. 데이터 단위는 프레임(Frame)이다. * 3계층 - 네트워크 계층(Network Layer): 다중 네트워크 링크를 거쳐 데이터 패킷을 최종 목적지까지 가장 안전하고 빠른 경로를 찾아 전달하는 라우팅(Routing)을 전담하는 계층이다. 논리 주소인 IP 주소를 정의하고 관리하며, 데이터 단위는 패킷(Packet)이다. * 4계층 - 전송 계층(Transport Layer): 송신 프로세스와 수신 프로세스 간의 신뢰성 있고 정확한 데이터 전송을 종단 간(End-to-End)에 보장하는 핵심 계층이다. 에러 제어, 흐름 제어, 혼잡 제어를 수행하며 포트(Port) 번호를 통해 상위 애플리케이션을 구분한다. 데이터 단위는 세그먼트(Segment) 또는 데이터그램(Datagram)이다. * 5계층 - 세션 계층(Session Layer): 통신하는 프로세스들 간의 세션(연결 상태)을 개설, 유지, 동기화하고 종료하는 제어 기능을 담당하는 계층이다. 통신 장치들 간의 대화 체계를 수립하고 체크포인트를 두어 연결 손실 시 복구하는 역할을 수행한다. * 6계층 - 표현 계층(Presentation Layer): 송수신자가 서로 다른 데이터 표현 방식을 사용할 때, 이를 공통의 형식으로 변환하여 상호 호환성을 보장하는 계층이다. 데이터의 인코딩/디코딩, 암호화/복호화, 데이터 압축 등의 연산을 전담한다. * 7계층 - 응용 계층(Application Layer): 최상위 계층으로서 사용자가 네트워크에 접근할 수 있도록 UI와 직접 연결되는 다양한 프로토콜 서비스를 제공하는 계층이다. 웹 브라우저, 메일 프로그램 등이 이 계층의 서비스를 이용한다. * 계층 간 상호작용 및 TCP 적용 메커니즘: * 각 계층은 독립적으로 동작하지만, 데이터를 전송할 때는 상위 7계층에서 하위 1계층 방향으로, 수신할 때는 하위 1계층에서 상위 7계층 방향으로 데이터를 토스하며 상호작용한다. * 현대 인터넷 환경에서 가장 많이 범용적으로 사용하는 핵심 프로토콜인 TCP(Transmission Control Protocol)는 이 표준 모델 중 \*\*4계층(전송 계층)\*\*에 명확히 적용되는 개념이다. * 7계층의 응용 프로그램(예: HTTP 웹 서버)이 생성한 순수 데이터를 아래로 내려보내면, 4계층에 위치한 TCP 프로토콜이 데이터의 유실 없는 신뢰성 보장을 위해 순서 번호, 확인 응답 번호, 포트 번호 등이 포함된 TCP 헤더를 결합하여 세그먼트 형태로 패킹한 뒤 3계층(IP)으로 전달하는 구조로 작동한다. ### 6. TCP 3-Way Handshake의 커넥션 수립 메커니즘 * TCP 3-Way Handshake는 전송 계층에서 두 엔드 포인트 간의 가상 통신 선로를 확보하고 신뢰성 있는 연결을 설정하기 위해 3단계로 인사를 주고받는 정밀한 동기화 과정이다. * 단계별 플래그 통신 메커니즘: * 1단계 (SYN): 클라이언트가 서버에 연결을 요청하며 임의의 시퀀스 번호를 담은 SYN(Synchronize Sequence Number) 플래그 패킷을 전송한다. 이 시점의 클라이언트는 SYN\_SENT 상태가 된다. * 2단계 (SYN+ACK): 서버가 클라이언트의 요청을 정상적으로 확인했음을 알리는 응답 플래그 ACK(Acknowledgment)와, 자신도 클라이언트와 연결을 수립하겠다는 의미의 SYN 플래그를 동시에 결합하여 SYN+ACK 패킷을 클라이언트에 발송한다. 서버는 SYN\_RECEIVED 상태로 대기한다. * 3단계 (ACK): 서버의 응답을 확인한 클라이언트가 최종 확답 플래그인 ACK 패킷을 서버에 전송한다. * 연산 결과: 이 3단계의 패킷 교환이 완전하게 완수되는 순간 양측 모두 연결 확립(ESTABLISHED) 상태로 전환되며, 비로소 상위 응용 계층의 실제 데이터(HTTP, API 요청 등)를 안전하게 실어 나를 수 있는 가상 회선이 오픈된다. ### 7. TCP 4-Way Handshake의 커넥션 수립 메커니즘 * TCP 4-Way Handshake는 데이터 전송이 완전히 종료된 후 시스템 자원의 유실과 낭비를 방지하기 위해 통신 선로를 안전하게 폐쇄하고 할당된 소켓 자원을 완전히 해제하는 4단계 종료 과정이다. * 단계별 플래그 해제 메커니즘: * 1단계 (FIN): 더 이상 보낼 데이터가 없는 클라이언트가 서버에 통신 종료를 선언하며 FIN(Finish) 플래그 패킷을 전송한다. 클라이언트는 FIN\_WAIT\_1 상태로 진입한다. * 2단계 (ACK): 서버는 클라이언트의 FIN 요청을 수신하고 우선 확답인 ACK 패킷을 보낸다. 서버는 아직 미처 전송하지 못한 자신의 잔여 데이터 송신과 내부 자원 정리를 마무리하기 위해 CLOSE\_WAIT 상태로 전환한다. 이 ACK를 받은 클라이언트는 서버가 완전히 닫힐 때까지 대기하는 FIN\_WAIT\_2 상태가 된다. * 3단계 (FIN): 내부 정리를 완전히 완수한 서버가 최종 종료 준비가 끝났음을 알리기 위해 클라이언트에 FIN 플래그 패킷을 전송한다. 서버는 LAST\_ACK 상태가 된다. * 4단계 (ACK): 클라이언트는 서버의 FIN 패킷을 수신하고 최종 확인을 뜻하는 ACK 패킷을 서버에 보낸다. 이후 클라이언트는 혹시나 네트워크 지연으로 인해 뒤늦게 도착할 수 있는 잔여 패킷(패킷 미도착으로 인한 유실 데이터)을 안전하게 수용하고 데이터 유실 오동작을 방지하기 위해 TIME\_WAIT 상태로 일정 시간 유예 기간을 둔 뒤 소켓을 최종 소멸시킨다. 서버는 이 ACK를 받는 즉시 CLOSED 상태가 되어 자원을 반환한다. ### 8. OSI 7계층 및 TCP/IP 모델에서의 캡슐화(Encapsulation)와 역캡슐화(Decapsulation) * 사용자가 전송하려는 응용 계층 데이터가 실제 물리 선로를 거쳐 상대방 애플리케이션에 도달하기까지 각 계층 간의 물리적 변환 연산이 수행된다. * 캡슐화(Encapsulation): 송신단에서 상위 계층의 데이터가 하위 계층으로 내려가면서 각 계층의 프로토콜이 요구하는 네트워크 제어 정보인 헤더(Header) 또는 트레일러(Trailer)를 데이터 앞뒤에 물리적으로 결합해 나가는 가공 과정이다. * 7계층 응용 데이터에 제어 정보가 붙고, 4계층 전송 계층으로 내려와 TCP 헤더가 결합되면서 \[세그먼트]가 된다. * 3계층 네트워크 계층에서 IP 헤더가 결합되어 \[패킷] 형태로 완전히 감싸진다. * 2계층 데이터 링크 계층에서 MAC 주소 헤더와 에러 검출용 CRC 트레일러가 붙어 최종 \[프레임] 단위의 온전한 캡슐이 완성되며, 1계층 물리 계층에 의해 전기적 신호나 광신호로 변환되어 송출된다. * 역캡슐화(Decapsulation): 수신단에서 물리 신호를 받아 상위 계층으로 올리면서, 각 계층에 해당하는 헤더 정보를 읽고 해석하여 제어를 수행한 뒤 해당 헤더를 순차적으로 제거하고 상위 데이터만을 위로 토스하는 과정이다. 최종 7계층 응용 프로그램에는 모든 네트워크 제어 껍데기가 다 벗겨진 최초의 순수 데이터만 도달하게 된다. ### 9. NAT(Network Address Translation)와 포트 포워딩(Port Forwarding)의 개념 및 차이점 * NAT(네트워크 주소 변환): 주로 제한된 공인 IP 주소를 절약하고 내부 네트워크를 보호하기 위해, 사설 IP 주소를 공인 IP 주소로 또는 그 반대로 변환해 주는 기술 체계다. * 작동 특성: 내부 사설망의 수많은 컴퓨터가 외부 인터넷에 접속할 때 라우터(공유기)가 출발지 사설 IP를 단 하나의 대표 공인 IP 주소로 변환하여 외부로 내보낸다. 외부에서는 내부 사설 IP 주소를 알 수 없으므로 강력한 보안 장벽 기능도 수행한다. * 포트 포워딩(포트 전달): 외부에서 공인 IP의 특정 포트(Port) 번호로 접속을 시도했을 때, 라우터가 미리 설정된 규칙에 따라 사설망 내부의 특정 사설 IP와 특정 포트를 사용하는 내부 서버로 트래픽을 그대로 매핑하여 전달해 주는 기술이다. * 작동 특성: 내부 사설망에 속한 웹 서버(사설 IP 192.168.0.10:80)를 외부에 오픈하고 싶을 때, 공유기에 공인 IP의 8080 포트로 들어오는 요청은 192.168.0.10의 80 포트로 가라고 이표를 설정해 두는 연산이다. * 핵심 차이점: NAT는 사설 IP와 공인 IP 간의 주소 변환(1:N 혹은 1:1) 자체에 목적이 있으며 주로 내부에서 외부로 나가는 통신에 초점이 맞춰져 있다. 반면 포트 포워딩은 외부에서 내부 사설망 안의 특정 서버 자원에 강제로 접근할 수 있도록 포트 번호를 이표 삼아 통로를 열어주는 세부 매핑 설정이다. ### 10. TCP와 UDP 프로토콜의 본질적 아키텍처 특성 비교 * TCP(Transmission Control Protocol): 신뢰성을 최우선 가치로 두는 연결 지향형 프로토콜이다. * 핵심 기포: 3-Way Handshake를 통해 연결을 먼저 확인한 후 데이터를 전송하며, 패킷의 전송 순서를 완벽히 보장한다. 수신단이 데이터를 잘 받았는지 확인하는 ACK 신호를 일일이 체크하며, 유실 발생 시 재전송(ARQ)을 수행하고 흐름 제어 및 혼잡 제어 연산을 실행하므로 데이터 무결성이 완벽히 보장된다. 다만 제어 오버헤드로 인해 전송 속도가 UDP에 비해 상대적으로 느리다. 웹 통신(HTTP), 파일 전송(FTP), 데이터베이스 통신 등에 필수적이다. * UDP(User Datagram Protocol): 속도와 간결성을 최우선 가치로 두는 비연결형 프로토콜이다. * 핵심 기포: 핸드셰이크 과정 없이 연결을 수립하지 않고 수신단의 수신 가능 여부도 확인하지 않은 채 데이터를 일방적으로 던진다. 패킷의 도착 순서 보장이나 유실에 대한 재전송 제어가 전혀 존재하지 않으며, 오직 최소한의 에러 검출 기능만 소유한다. * 장점: 제어 오버헤드가 원천적으로 없기 때문에 전송 속도가 압도적으로 신속하다. 데이터가 일부 유실되더라도 끊김 없는 실시간성이 중요한 스트리밍 서비스, 온라인 게임, DNS 질의 통신 등에 주로 활용된다. ### 11. 웹소켓(WebSocket) 프로토콜의 전이중 통신 메커니즘과 자원 효율성 * 웹소켓은 웹 브라우저와 웹 서버 간의 지속적인 양방향 전이중(Full-Duplex) 통신을 지원하기 위해 고안된 네트워크 프로토콜이다. * 핸드셰이크 변환 연산: 최초 연결 시에는 전통적인 HTTP 프로토콜을 사용하여 요청을 보낸 뒤, HTTP 헤더의 Upgrade 명세를 활용하여 웹소켓 프로토콜(ws 또는 wss)로 전이(Handshake)하는 과정을 거친다. * 통신 방식의 혁신: 한 번 연결이 수립되면 매번 HTTP 요청 헤더를 새로 만들 필요 없이, 단 하나의 단일 TCP 커넥션을 유지하며 서버와 클라이언트가 원할 때 언제든 실시간으로 데이터를 밀어 넣을 수 있다. * 자원 효율성: 매번 커넥션을 열고 닫거나 무의미한 조회를 반복하는 HTTP 폴링(Polling) 방식에 비해 네트워크 오버헤드가 극적으로 감소하며, 실시간 채팅, 실시간 주식 차트, 협업 툴 등 실시간 양방향 데이터 교환에 최적화된 자원 방어력을 발휘한다. ### 12. 현대 애플리케이션 인프라 환경에서의 TCP 적용 구체적 예시 * HTTP/1.1 및 HTTP/2 통신: 웹 브라우저가 API 서버와 데이터를 주고받을 때 데이터 유실이 없어야 하므로 4계층 전송 프로토콜로 반드시 TCP를 탑재하여 구동한다. * 데이터베이스 연동(JDBC/RDS): Spring Boot 애플리케이션이 외부의 MySQL이나 RDS 데이터베이스에 접속하여 SQL 쿼리를 실행하고 데이터를 가져올 때, 커넥션 풀(HikariCP)이 맺는 물리적 주소의 실체는 모두 안전한 TCP 소켓 커넥션 구조 위에서 작동한다. * 캐시 및 메시지 큐 통신: 분산 캐시 시스템인 Redis 시스템이나 메시지 지향 미들웨어인 RabbitMQ 등과 데이터를 주고받을 때 역시 데이터 명령어가 누락되면 안 되므로 철저하게 신뢰성 기반의 TCP 소켓 프로토콜을 기반으로 통신 파이프라인을 구축한다. ### 13. 대외계 시스템 FEP(Front End Processor) 인프라 아키텍처에서의 네트워크 통신 특성 * FEP(전치 프로세서)는 주로 금융권이나 기업 간 대외계 시스템 연동 시, 내부 메인프레임이나 핵심 백엔드 서버의 통신 부하를 줄이고 프로토콜 변환 및 보안 격리를 전담하기 위해 전방에 배치하는 독립된 인프라 장비 또는 소프트웨어 계층이다. * 네트워크 통신 제어 특성: FEP 환경에서는 외부 기관(예: 카드사, 은행, 정부 기관)과의 고정된 전용선이나 VPN 선로를 타고 대량의 전문 데이터가 실시간으로 인입된다. * 신뢰성과 동기화 메커니즘: 데이터의 유실이 절대 용납되지 않는 금융/계정계 특성상, 완벽한 신뢰성을 지원하는 고성능 TCP 동기/비동기 소켓 통신 아키텍처를 핵심 기반으로 채택한다. * 패킷 파싱과 전문 가공: FEP는 인입된 가변/고정 길이 바이트 전문 패킷을 네트워크 단에서 실시간으로 캡슐화 해제하고 파싱한 뒤, 내부 시스템이 이해할 수 있는 프로토콜 데이터 형식으로 고속 변환하여 안전하게 내부 WAS로 라우팅해 주는 고도의 네트워크 게이트웨이 제어 역할을 수행한다. ### 14. AMQP 프로토콜의 아키텍처 모델과 Kafka의 독자적 프로토콜 체계 * AMQP(Advanced Message Queuing Protocol)는 전통적인 메시지 지향 미들웨어를 위한 표준 프로토콜이다. * 생산자(Producer)가 메시지를 발행하면 미들웨어 내부의 Exchange(교환기) 장치가 바인딩 규칙에 따라 적절한 Message Queue(메시지 큐)로 라우팅을 수행하는 구조다. 큐에 들어간 메시지는 소비자가 가져가면 큐에서 즉시 제거되거나 ACK 확인 후 소멸되는 메커니즘을 취한다. * Kafka가 AMQP를 사용하지 않는 본질적 이유: Kafka는 설계 사상과 목적부터가 전통적인 메시지 큐 모델이 아니었기 때문이다. * Kafka는 메시지 라우팅을 가치로 두지 않고, 단순히 들어온 데이터를 파티션 로그 파일의 맨 끝에 차례대로 이어 붙이는 Append-Only Log 보관 체계를 사용한다. * 소비자가 데이터를 읽어가더라도 로그 파일에서 메시지가 소멸되지 않고 그대로 잔존하며, 소비자는 단지 자신이 어디까지 읽었는지를 나타내는 message offset(오프셋) 값만 이동시키며 데이터를 소비한다. * 따라서 정교한 라우팅 규칙이 포함된 고비용의 AMQP 프로토콜을 사용하면 무거운 오버헤드가 동반되므로, Kafka는 복잡성을 완전히 걷어내고 단순함과 성능 향상을 극대화하기 위해 전용 TCP 소켓 기반의 바이너리 프로토콜(Binary Protocol)을 독자적으로 사용한다. ### 15. HTTP Keep Alive 설정의 동작 매커니즘과 자원 효율성 * Keep Alive는 네트워크 및 시스템 환경에서 기존에 수립된 TCP 연결 커넥션을 끊지 않고 일정 시간 동안 계속 유지하기 위해 필요한 네트워크 설정 제어 기법이다. * 연결 유지의 목적: 특히 HTTP/1.1 통신 환경에서 위력을 발휘한다. 만약 이 설정이 없다면 브라우저가 웹 페이지의 이미지, 스크립트 파일 등을 하나씩 요청할 때마다 매번 고비용의 TCP 3-Way Handshake와 4-Way Handshake를 수없이 반복해야 하므로 서버와 클라이언트 모두에 치명적인 네트워크 부하가 걸린다. * 자원 효율성 원리: Keep Alive 설정을 활성화하면 하나의 동일한 TCP 연결 통로를 재사용하여 다수의 HTTP 요청과 응답을 연속적으로 처리할 수 있다. 불필요한 커넥션 생성/해제 오버헤드를 원천 차단함으로써 네트워크 반응 속도를 획기적으로 가속하고 시스템 자원을 효율적으로 방어한다. ### 16. Socket / Polling #### Socket은 네트워크 연결을 위한 인터페이스, Polling은 네트워크 연결 전략이자 방법으로 본질적으로 다르지만, 네트워크 연결 전략의 방법론 측면에서 살펴볼 필요가 있다. * 네트워크 연결 지속성(Persistence) 및 상태유지(Stateful/Stateless) * TCP, Web이든 Socket은 기본적으로 연결을 계속 유지할 수 있으며, 이 연결 Connection 상에서 지속적인 데이터 송수신이 가능하다. * 그만큼 지속적인 상태 지속 및 데이터 교환이 가능하기에, 리소스 점유 및 낭비가 그만큼 심하다는 특성을 지닌다. * 이에 반해 Polling은 Stateless, 네트워크 연결을 하기 위한 하나의 방법론이며 리소스를 점유하지 않고 바로 반납한다는 관점에서 리소스 점유 걱정을 하지 않아도 된다. * 3 Way / 4 Way HandShake * TCP Socket은 기본적으로 연결 지향이며, 이 연결 수립 및 제거 과정에서 3 Way / 4 Way의 방법을 사용하는 것이다. * 3 Way는 Syc(C) / Syc + Ack(S) / Syn(C)의 연결 수립 과정을 통해 연결이 이루어지며, 4 Way는 연결 종료 시 Fin(C) / Ack(S) / FIN(S) / ACK(C)의 양방향 연결 종료를 통해 이루어진다. * HTTP 네트워크 * HTTP 네트워크는 TCP Socket 연결 및 통신 상에서 이루어지는 데이터 송수신 과정이며, 기본적으로 TCP Socket(4계층, Transaport) / HTTP(7계층, Application)의 역할이 다르기에 분리해서 살펴 볼 필요가 있다. * 정확히 말하자면, TCP Socket을 통한 연결은 연결 가능한 프로토콜을 의미하며, 이 연결을 계속 유지할 것인가 혹은 중지할 것인가에 따라 세부적인 연결 및 상태 지속 전략이 달라진다. HTTP의 경우 데이터 송수신 후 바로 연결 종료가 이루어지기에, 연결 종료가 바로 이루어진다. 그 연결이 이루어지는 동안 데이터 송수신이 계속 이루어지는 것일 뿐이다. ### 📌 Networks with OSI 7 Layers ### 네트워크의 본질과 OSI 7 Layers ``` OpenAPI를 제공하는 서버 측에 postman을 통해 API Request를 요청하였다고 가정해보자. ``` 아래의 전문이 보내진다고 본다면, ``` POST https://api.example.com/orders HTTP/1.1 Host: api.example.com Content-Type: application/json Authorization: Bearer abc123 { "productId": 100, "quantity": 2 } ``` 이 전문들은 OSI 7 Layer의 목적, 역할에 맞게 계층적으로 정보가 포장(Encapsulation)된다. ``` [ Ethernet Header ] [ IP Header ] [ TCP Header ] [ HTTP Header ] [ HTTP Body ] ``` 그리고 그리고, 서버에 도착한 전문은 반대로 벗겨진다(Decapsulation). ``` Ethernet ↓ IP ↓ TCP ↓ HTTP ↓ JSON ``` **결국 네트워크의 본질은, 필요한 규칙 및 프로토콜에 따라 데이터를 규격화하여 보내는 것이다.** | OSI | 이름 | 대표적인 것 | 이 예제에서 | | --- | ------------ | ----------------- | --------------- | | 7 | Application | HTTP, DNS | HTTP API 요청 | | 6 | Presentation | Encoding, 암호화/복호화 | JSON, TLS 관련 처리 | | 5 | Session | 세션 관리 | 연결/세션 개념 | | 4 | Transport | TCP, UDP | TCP | | 3 | Network | IP, Router | IP | | 2 | Data Link | Ethernet, MAC | 이더넷 프레임 | | 1 | Physical | 전기/광/무선 신호 | 실제 0/1 전달 | 구체적으로, 각 전문에서 목적에 맞게 Encapsulation한 요소들은 철저하게 7계층으로 분리되기 보다는, 데이터 네트워크를 위해 필요한 규칙/프로토콜에 맞추어 규격화하고 전송하는 것이다. ``` Application │ │ HTTP ▼ Socket API │ │ TCP ▼ Operating System Network Stack │ │ IP ▼ Network Interface │ │ Ethernet / Wi-Fi ▼ NIC │ │ 전기/전파 ▼ Network ``` 모델을 기능별로 분류한 것이지, 실제 데이터 네트워킹 시 필요한 요소들만 채워 보내는 점을 유의하자. ### Layer 7(Application/프로토콜) 7계층은 말 그대로 Application 측에서 HTTP 요청을 만들며, Application 측에서 본인이 보내고자 하는 데이터 및 Header 등을 조합하여 생성한다. ``` HTTP Header ──────────────────────────── POST /orders HTTP/1.1 Host: api.example.com Content-Type: application/json Authorization: Bearer abc123 HTTP Body ──────────────────────────── { "productId": 100, "quantity": 2 } ``` ``` 내 PC │ │ "api.example.com의 IP가 뭐야?" ▼ DNS Server │ │ "203.0.113.10이야" ▼ 내 PC ``` 우선적으로DNS를 사용하여 엔드포인트만 알고 있을뿐이다. 이후의 과정을 통해 IP주소로 변환해야 내용을 보낼 수 있다. 최종적으로 IP주소로 변환해야 내용을 보낼 수 있으며, 이 외 DNS, HTTP, SMTP 등모두 7계층에서 이루어지는 내용들이다(프로토콜). ### Layer 4(TCP/Transport/Segment) 주소는 알고 있는데, 어떤 포트를사용하여 데이터를 전송해야 할지 모른다. 이때 4계층에 해당하는 전송 포트(TCP)를 저장하게 된다. ``` 203.0.113.10 ├── SSH : 22 ├── HTTP : 80 ├── HTTPS : 443 └── 기타 서버 -> 203.0.113.10:443 ``` 수많은 포트번호(SSH/HTTP/HTTPS) 중 데이터 전송 규칙에 맞는 포트를 선택하고, 이 포트번호를 4계층에 적재해놓는다. 참고로, TCP 연결 방법도 여러 가지가 존재하며, 이중 3 way handshake의 경우 SYN/SYN+ACK/ACK의 과정 이후 연결/전송한다. ``` ┌──────────────────────────┐ │ TCP Header │ │ │ │ Source Port: 53000 │ │ Destination Port: 443 │ │ Sequence Number │ │ ACK Number │ │ Flags │ │ ... │ ├──────────────────────────┤ │ HTTP Data │ │ │ │ POST /orders ... │ │ { ... } │ └──────────────────────────┘ ``` 그리고, 앞서 생성한 HTTP 데이터를 TCP에 넘기는데, 정확하게는 TCP가 목적지 정보를 Header에 붙여 Application이 제공한 Request와 통합된 Segment를 생성한다. **Header에 구성되어있는 Seq Number를 통해 순서 보장을 넘어, 서버 측 수신 확인, 흐름제어, 혼잡제어, 유실방지(재전송) 등 TCP가 모두 책임을 진다.** ### Layer 3(IP/Packet) IP 측은 TCP Segment에 IP Header를 붙여, 전송 데이터의 출발지/목적지 정보 등을 저장한다. IP Header가 붙여진 TCP Segment는 이제 IP Packet으로 관리하며, 여기서 Packet 개념이 등장한다. ``` ┌──────────────────────────────┐ │ IP Header │ │ │ │ Source IP: 192.168.0.10 │ │ Destination IP: 203.0.113.10 │ │ TTL │ │ Protocol: TCP │ │ ... │ ├──────────────────────────────┤ │ TCP Header │ ├──────────────────────────────┤ │ HTTP Data │ └──────────────────────────────┘ ``` IP Packet의 핵심은 데이터를 출발지부터 목적지까지 어느 경로로 보낼 것인지 그 정보가 들어있다는 점이다. ``` HTTP ↓ TCP Segment ↓ IP Packet ``` IP Packet을 참고하여, IP Router 측은 데이터를 보낼 다음 목적지를 인지하고 결정한다. TCP가 컴퓨터의 내부 통신 엔드포인트라면, IP는 외부 통신 엔드포인트이다. ### Layer 2\~1(Ehternet/Physical) 이더넷이 Frame 안에 IP Packet을 넣고, 이를 최종적으로 전기신호로 변환하여 물리적으로 전송한다. ``` PC │ │ Ethernet Frame ▼ 공유기 │ │ 새로운 Frame ▼ ISP Router │ │ 새로운 Frame ▼ 중간 Router │ │ 새로운 Frame ▼ 서버 ``` 실제 보내지는 정보들은 0,1로 이루어진 비트이며, IP Packet은 그대로 전달되며 이더넷 프레임만 각 구간마다 새로 만들어져 바뀐다. 최종 목적지 측에서 받는 형태는 이더넷 프레임이며, IP Packet(IP), TCP Segment(Port 등)을 확인 후 HTTP Request를 전달받는다. 참고로, 우리가 흔히 말하는 JSON은 HTTP Request의 body를 읽기 쉬운 문자열 형태로 받아 관리함을 의미한다. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://leehyokyun.gitbook.io/openbook/2-1.-networks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.