기존 netstat 도구는 소켓, 경로 및 인터페이스 통계를 표시합니다. 현대 리눅스에서는 커널 소켓 상태를 효율적으로 보여 주고 iproute2와 함께 유지 관리되는 ss가 선호되는 소켓 조사 도구입니다.
문제 해결 · 레슨 4
netstat
ss로 리눅스 소켓, 리스너, 큐 및 TCP 상태를 조사하는 방법을 알아봅니다.
수신 소켓 나열하기
수신 중인 TCP와 UDP 소켓을 숫자로 표시하고, 권한이 있으면 소유 프로세스도 포함합니다.
$ sudo ss -lntup
-l은 리스너를 선택하고, -n은 이름 조회를 피하고, -t와 -u는 TCP와 UDP를 선택하며, -p는 프로세스 데이터를 요청합니다. UDP는 비연결형이므로 연결되지 않은 바인드 소켓에 TCP 방식의 LISTEN 핸드셰이크가 없습니다.
소켓 문제 해결 중 -n을 사용하는 이유는 무엇입니까?
포트, 끝점 및 서비스
로컬 소켓 끝점은 주소, 전송 프로토콜 및 포트로 구성됩니다. TCP 연결은 프로토콜과 출발지 및 목적지 주소와 포트로 구분됩니다. /etc/services는 관례적인 이름을 숫자에 매핑하지만 현재 어느 프로세스가 포트를 소유하거나 어떤 응용 프로토콜을 사용하는지 입증하지 않습니다.
https 443/tcp 같은 /etc/services 항목은 무엇을 확립합니까?
TCP 상태 읽기
일반적인 상태는 다음과 같습니다.
SYN-SENT: 로컬 끝점이 연결 요청을 보내고 진행을 기다립니다.ESTAB: TCP 연결이 수립됐습니다.CLOSE-WAIT: 통신 상대가 송신 측을 닫았지만 로컬 애플리케이션이 소켓을 닫지 않았습니다.TIME-WAIT: 능동적으로 닫은 끝점이 지연 세그먼트가 만료되고 최종 교환을 안전하게 처리할 수 있도록 기다립니다.
CLOSE-WAIT 수가 많거나 계속 증가하면 흔히 로컬 애플리케이션 정리 동작을 가리킵니다. TIME-WAIT는 정상적인 프로토콜 상태이며 수량과 리소스 영향에 따라 운영상 문제인지 판단합니다.
CLOSE-WAIT에서 어느 쪽이 아직 소켓을 닫아야 합니까?
큐 해석하기
Recv-Q와 Send-Q의 의미는 상태와 프로토콜에 따라 다릅니다. 수립된 TCP 소켓에서는 애플리케이션 수신 또는 전송 확인 응답을 기다리는 데이터를 나타낼 수 있습니다. 수신 소켓에서 큐 필드는 같은 방식의 응용 페이로드 바이트가 아니라 연결 백로그 상태를 설명합니다.
스냅샷 하나만으로 누수나 병목을 확립할 수 없습니다. 시간에 따라 표본을 수집하고 프로세스 동작, 애플리케이션 지연 시간, 재전송 및 리소스 제한과 연관 지으십시오.
큰 소켓 큐 스냅샷 하나만으로 진단하기에 부족한 이유는 무엇입니까?
조사 범위 제한하기
문제의 프로토콜, 상태, 끝점 또는 프로세스로 출력을 제한합니다.
$ ss -tn state established
$ ss -ltn 'sport = :443'
리스너는 로컬 전송 준비 상태를 입증하지만 원격 연결 가능성이나 애플리케이션 상태는 입증하지 않습니다. 증상에 맞는 경로, 방화벽, 패킷, TLS 및 응용 테스트를 이어서 수행하십시오.
포트 443의 TCP 리스너가 입증하지 못하는 것은 무엇입니까?
레슨 완료
netstat 완료
이제 포트를 애플리케이션과 혼동하지 않고 ss로 소켓 상태를 조사할 수 있습니다.
프로세스 맥락과 함께 리스너를 숫자로 나열합니다.
관례적인 서비스 이름과 런타임 소유권을 구분합니다.
로컬 끝점 관점에서 TCP 닫기 상태를 해석합니다.
작업 부하 맥락과 함께 시간에 따라 큐를 표본 추출합니다.
로컬 리스너를 넘어 원격 응용 동작을 검증합니다.