일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- go
- Elasticsearch
- tucker의 go 언어 프로그래밍
- 오블완
- Linux
- 정보처리기사 실기 기출문제
- AWS EKS
- Java
- mysql 튜닝
- aws
- 공부
- golang
- CloudWatch
- kotlin querydsl
- APM
- CKA
- AI
- kotlin coroutine
- CKA 기출문제
- Pinpoint
- 코틀린 코루틴의 정석
- kotlin
- PETERICA
- 기록으로 실력을 쌓자
- docker
- 정보처리기사실기 기출문제
- Kubernetes
- minikube
- 티스토리챌린지
- Spring
- Today
- Total
목록tcpdump (2)
피터의 개발이야기

ㅁ 개요 ㅇ WireShark를 이용한 패킷 헤더를 분석하는 과정을 정리하였다. ㅇ 지난글 [Kubernetes] Kubernetes Pod별 Tcpdump 방법을 통해 얻게 된 pcap 파일을 분석하면서 정리한 내용이다. ㅇ 패킷의 head에를 분석 파악하는 것이 목적이다. ㅁ pcap 파일 로딩 ㅇ WireShark을 실행하고 tcpdumpNode.pcap 파일을 로딩하였다. ㅇ 패킷의 정보 분석 컬럼 내용 No 패킷을 수집한 순서 Time 패킷이 수집된 시간 Source 패킷을 보낸 주소 Destination 패킷 도착 주소 Protocol 프로토콜 정보 Length 패킷의 길이 Info 패킷 정보 ㅇ 제일 처음의 Standard query 0xc8d4 A peterica.tistory.co.def..

[kubernetes] 모니터링 방법 정리 ㅁ 개요 ㅇ kubernetes cluster 운영환경에서 pod에서 발생한 IP packet에 대한 tcpdump를 해야하는 경우가 발생한다. ㅁ tcpdump를 확인해야만 했던 이유 외부 연동된 사이트와의 통신에서 천만분의 1의 경우로 network timeout이 발생하여 확인하는 과정이었다. 연동된 사이트에서 확인한 결과 우리가 발신한 packet의 Accept-Charse의 길이가 길다는 이슈를 확인하였다. 받는 쪽에서 Accept-Charset 항목이 상당히 긴 편이라 짧은 메시지의 경우에도 네트워크 상에서 패킷이 다건 분할 되어 처리되고 있는 것 같다면서, 혹시 발송된 정보와 다르다면 알려달라는 요청이 있었다. 그 과정에서 나는 1차적으로 소스상 분..