Doctor Pepper

서버와 연관된 네트워크 장애 처리에는 몇 가지 필수적인 서버 네트워크 명령어를 알아두는 것이 효과적입니다. 장애 발생 시 이를 빠르게 진단하고 해결할 수 있도록 돕는 유용한 명령어를 소개하겠습니다. 또한, HTTP 상태 코드와 작업 후 서비스 상태를 확인할 수 있는 모니터링 툴에 대한 정보도 중요하다. 1. netstat 명령서버 네트워크 장애 처리에서 netstat 명령어는 필수적인 도구이다. 이 명령어는 시스템의 네트워크 상태를 실시간으로 점검하고, 네트워크 연결 상태를 확인하는 데 유용하다. netstat를 사용하면 서버의 열린 포트, 현재의 네트워크 연결, 소켓 상태 등을 확인할 수 있으며, 장애 발생 시 문제를 진단하는 데 중요한 정보를 제공한다.- netstat 주요 기능 연결된 포트와 IP ..

1. L4 스위치 서비스 그룹 및 실제 서버 관리 L4 스위치는 서비스 트래픽의 로드 밸런싱 역할을 수행하며, 서비스 그룹에 속한 실제 서버의 상태를 주기적으로 감시하여 정상적인 서버로 트래픽을 분배한다. 이러한 서버 상태 감시를 헬스 체크(Health Check)라 하며, 주로 다음과 같은 방법들이 사용된다. - ICMP 기반 헬스 체크 방법 ping을 통해 서비스 그룹 내 서버의 연결성을 확인함. 특징 네트워크 레이어 수준의 단순 연결 상태를 체크함.  - TCP 포트 기반 헬스 체크 방법 - 3-way 핸드셰이킹 과정을 통해 서버의 서비스 포트를 확인.  1. L4 스위치가 서버에 SYN 패킷 전송.  2. 서버가 SYN-ACK 응답을 보내면 연결 정상으로 판단.  3. 이후 FIN 패킷을 전..

TCP는 세션 연결을 설정할 때 3-way handshaking을 사용하며, 세션 종료를 위해 4-way handshaking 과정을 수행한다. 연결 설정 시 SYN 플래그가 사용되는 것처럼, 세션 종료 시에는 FIN(Finish) 플래그가 활용된다. TCP 세션 종료는 크게 두 가지 방식으로 일반적인 종료 방식과 동시 종료 방식으로 나뉜다. 1. TCP 정상 종료의 4-way Handshake TCP 연결 종료는 일반적으로 4-way 핸드셰이킹 과정을 통해 이루어진다. 이 과정은 양방향으로 데이터를 주고받는 연결을 안전하게 종료하기 위한 절차이다. - 4-way Handshaking 과정 클라이언트의 종료 요청 클라이언트는 애플리케이션으로부터 연결 종료 요청을 받고, FIN 세그먼트를 서버로 전송하며..

1. TCP 체크섬 오프로드 기능- 체크섬 계산의 기본 수행 위치TCP 체크섬 계산은 보통 운영체제의 소켓 레벨에서 이루어진다. 하지만 최근 통신 성능 향상을 위해 체크섬 연산을 이더넷 NIC(Network Interface Card)에서 처리하는 경우가 많아지고 있다. - 체크섬 오프로트듸 장점NIC에서 체크섬을 계산하면 시스템의 통신 처리 성능이 향상된다.일반 패킷 약 5% 성능 향상 점보 패킷 약 15% 성능 향상  - 체크섬 오프로드와 패킷 캡처 패킷 캡처 도구(예: Wireshark)에서 TCP Bad Checksum 오류가 나타나는 경우, 실제 통신 에러일 수도 있지만 대부분은 NIC에서 잘못된 체크섬 연산 때문에 발생한다. - 체크섬 오프로드 비활성화 방법NIC에서 체크섬 오프로드 기능을..

VRRP(Virtual Router Redundancy Protocol)와 HSRP(Hot Standby Router Protocol)는 시스템(PC, 서버 등)이 종적 라우팅 프로토콜을 사용하지 않는 환경이나 정적 라우팅을 사용하는 환경에서 1홉 라우팅의 장애를 극복할 수 있는 이중화 구성을 구현하는 프로토콜이다. 이들은 여러 라우터나 멀티레이어 스위치를 그룹으로 구성하여 하나의 대표 라우터가 평상시 동작하다가 장애 발생 시 다른 라우터가 이를 대신하여 서비스의 연속성을 보장한다. 즉, 이러한 프로토콜들은 1홉 라우팅에 대한 신뢰성을 확보하는 데 중요한 역할을 한다. VRRP와 HSRP의 동작 방식은 유사하지만, VRRP는 표준화된 프로토콜이고, HSRP는 Cisco의 독자적인 프로토콜이다. 1. VR..

1. 라우팅 누락으로 인한 장애 네트워크 경로를 추가한 후, 특정 대역의 서비스가 불가능한 상태가 발생할 수 있다. 여러 가지 원인이 있을 수 있지만, 라우팅 누락이 주요 원인일 수 있다.  예를 들어, 10.10.10.0/24 대역에 대한 라우팅이 R2에서 잘못 설정되어 루핑이 발생하는 경우를 들 수 있다. 보통 R1, R2, R3의 네트워크 담당자가 다를 경우, 전체 라우팅 구조를 제대로 이해하지 못한 채 이런 문제가 발생할 수 있다. 이 문제를 진단하는 방법으로, 라우터에서 Traceroute 테스트를 수행하면 루핑 현상을 확인할 수 있다. 또한 서버나 클라이언트 PC에서 #netstat -an 명령어를 통해 TCP 3-way handshake가 성립되지 않음을 확인할 수 있다. 이를 통해 장애 원..