네트워크 패킷 샘플 분석

Hae_To·2025년 4월 17일

네트워크 패킷

패킷 분석 결과 약식 작성
- 분석 대상
  - 파일명: 200722_tcp_anon.pcapng (Netcat - string, file and characters)
  - 파일 다운로드 URL: https://wiki.wireshark.org/SampleCaptures#tcp
  - 패킷이 접속한 URL: https://www.rfc-editor.org/rfc/rfc2549.html
  - 원문 파일명: IP over Avian Carriers with Quality of Service
- 분석 결과
  - 샘플 패킷 정보를 기반으로 행위에 대한 분석 결과 작성
  - [참고 자료]
```
        ![[TCP Header 정보](https://www.rfc-editor.org/rfc/rfc793#section-3.1)](https://prod-files-secure.s3.us-west-2.amazonaws.com/3bbf5c9e-8b3d-4be4-a6f6-31914e778834/e7fe14f1-92a0-483a-a40b-6240b6f52de2/image.png)
        
        [TCP Header 정보](https://www.rfc-editor.org/rfc/rfc793#section-3.1)
        
        ![[3-Way Handshake 개념](https://afteracademy.com/blog/what-is-a-tcp-3-way-handshake-process/)](https://prod-files-secure.s3.us-west-2.amazonaws.com/3bbf5c9e-8b3d-4be4-a6f6-31914e778834/f56c845d-6982-466b-b3ec-5f04863e143f/image.png)
        
        [3-Way Handshake 개념](https://afteracademy.com/blog/what-is-a-tcp-3-way-handshake-process/)
        
```
  0. 패킷 개요
- 해당 패킷은 총 35패킷으로 이루어져 있다.
- 3-Way Handshake의 대표적인 예시 패킷으로 보임.
  [연결 확인]
  
  (1) 클라이언트가 도착할 서버에 SYN 패킷을 보냄.
  (출발지 7875 → 도착지 2000)
  
  (2) 서버는 클라이언트의 SYN 패킷을 수신하고 SYN + ACK 패킷을 보냄. (2000 → 7875) 이때 Ack= +1 증가
  
  (3) 정상 응답 후 클라이언트가 보낸 시퀀스번호에 +1 증가하여 새로운 시퀀스번호를 생성하고 보냄.
  
  1. 패킷 상세 분석
1. 패킷 송수신 날짜 확인
  
  Arrival Time: Jul 23, 2020 11:05:24.234640000 대한민국 표준시
  (첫 연결 기준)
2. 길이
  
  66 bytes (528 bits)
  
  Total Length: 52
  
  16진수 00 34 → 10진수 변환 시 52(일치)
3. 도착 연결 지 확인 (이상치 탐지)
  
  송수신된 패킷 중 데이터(문자열)가 높은 몇 개의 패킷을 발견 해당 패킷을 자세히 분석 진행
  - 데이터가 높은 패킷을 확인 결과 무언가를 접속한 듯함 해당 문자열을 출력해 메모장에 옮겨서 분석 실행
  - 프로토콜 설명으로 보이는 문서 내용을 발견 해당 내용의 진위 확인
  - QoS 프로토콜 설명 페이지는 하나의 SPA(Single Page Application) 형식으로 보이나 실제 패킷이 송수신되었을 때는 여러 번 나눠 전달됨.
  - 해당 프로토콜 문서 확인 결과 인터넷의 유희성을 보여주는 사례 중 하나로 볼 수 있음 - 실제로 구현되거나 사용되기 위한 기술 문서가 아님
  - 아래의 하위 페이지는 QoS 프로토콜 전문 및 번역본 [ IP over Avian Carriers with Quality of Service](https://www.notion.so/IP-over-Avian-Carriers-with-Quality-of-Service-3e297778f1254befa821051eb8ae32ff?pvs=21)

2. 패킷이 나눠서 통신된 이유(feat.MSS)

MTU - (TCP 헤더 + IP 헤더) = MSS

(TCP의 경우 손실(Loss) 발생 시 해당 패킷을 다시 전송해야 하는데 크기가 크면 비용이 너무 많이 든다. 반대로 패킷이 너무 작아도 헤더가 자주 붙어서 오히려 비용이 많이 든다)

본 과제의 첨부된 패킷들의 경우 1460 크기로 5개 + 759 크기 1개로 분할되어 문서가 전달되었음

[1460 크기로 분할하여 수신된 이유]

네트워크 라우터의 MTU가 1,500이라고 가정하면 최대 1,500바이트 길이의 패킷만 수신하기 때문이다. (더 긴 패킷은 분편화된다.)

MTU - (TCP 헤더 + IP 헤더) = MSS

*1,500 - (20 + 20) = 1,460*

라우터의 MSS는 1,460바이트로 설정해야 합니다. 페이로드 크기가 1,460바이트보다 큰 패킷은 삭제됩니다. (장치는 해당 장치와 다른 장치 사이에 있는 라우터의 MTU 및 MSS 설정을 인식하지 못하는 경우 실수로 이와 같이 지나치게 큰 패킷을 보낼 수 있습니다. 경로 MTU 검색이라고 하는 프로세스는 이러한 사고를 방지하는 데 도움이 됩니다.)

문서의 total크기는 8059이다.

아래의 이미지는 MSS 개념을 설명한다.