일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Collection
- Java
- 파이썬
- 큐
- functional programming
- JDBC
- tcp
- DesignPattern
- 람다 칼큘러스
- 자바
- 겨울카카오인턴
- Network
- 디자인패턴
- Collections
- javscript
- Eclipse
- 백준
- 로버트마틴
- Spring
- 스택
- 프로그래머스
- exception
- solid
- lambda calculus
- 함수형 프로그래밍
- design-pattern
- Rails
- JavaScript
- Pattern
- Python
- Today
- Total
개발자 노트
TCP, IP 패킷 분석 with wireshark 본문
패킷 분석
패킷 분석 목표
- ip 패킷 헤더 보기
- tcp 패킷 헤더 보기
- 3way handshake보
요청 페이지
보기 편하게 필터링
- 최초로 TCP로 3way handshake 하는 부분을 찾은 다음… (눈으로 [SYN] 인 부분을 찾았네요)
- ip, port에 대해 필터링을 합니다
- ip: sender, receiver의 패킷을 상대 host로 필터링 합니다.
- tcp: 보내고 받는 포트를 클라이언트 포트로 설정합니다.
로컬 호스트 내 특정 클라이언트와 서버간 통신하는 목록만 볼 수 있습니다.
특정 클라이언트라 이렇게 표현하는 이유는 브라우저의 경우 빨리 데이터를 받아오기 위해 여러 클라이언트로 동시에 요청하기 때문에 서버와 연결하는 여러 클라이언트 포트가 있을 수 있습니다.
Layer 별 순 표기
하단에 보시면 계층별로 표기가 됩니다.
physical layer (Frame)
link layer (Ethernet)
network layer (IP protocol)
Transport Layer (TCP)
헤더 살펴보기
Internet protocol
local host → server host 패킷 전송시, IP 정보입니다.
헤더 정보가 있는데요, rfc랑 비교해봅시다
https://datatracker.ietf.org/doc/html/rfc791#section-3.1
Version
4라고 하네요.
4bit가 할당되는데, 2진수로 4라고 표기되어 있습니다.
IHL
internet header length로, 20byte입니다.
옵션 필드가 없어서 20byte네요.
Type of Service
이 헤더 필드엔 8비트를 할당하는데요,
기록된 패킷 상 0000_0000입니다. 와이어 샤크에서는 Default 값이라고 표기 하네요.
Total Length
16 bit를 할당합니다. 16 진수 표기 값을 보면 00 40
으로 와이어 샤크에서 64라고 표기한 대로 64가 맞습니다.
이 total length는 fragment(network packet)가 감싸고 있는 segment(transport packet)까지 포함한 길이입니다.
하단에서 보시면 아시겠지만, segment의 크기는 44 bytes입니다.
따라서
ip header의 크기 + segment 크기 = 20bytes + 44 bytes = 64bytes 가 맞네요.
Identification, Flags, Fragment Offset
fragment의 MTU는 보통 1500bytes입니다. fragment의 header가 20bytes라 할 경우, segment가 1480bytes 초과된 크기로 newwork 계층에 전송되면 fragment의 크기는 1500bytes가 넘으므로 파편화를 진행합니다.
이 필드는 그때 사용하는 필드인데요,
각각 16 bits, 3 bits, 13bits
를 할당받습니다.
Identification: 0x0000 (16 bits)
flag 값은 010
으로 Don’t Fragment에 해당합니다. (3bits)
그리고 Fragment Offset 또한 모두 0으로 설정되어 있습니다. (13 bits)
한편
flag 값이 0x40으로 되어 있는데, 아마 1바이트씩 값을 읽어서 그런 것 같습니다.
flag는 3bit만 할당하지만, 1바이트 단위로 읽어서 0100 0000
으로 40표기된 것 같네요.
Time to Live
8 bits가 할당되고요, 64로 설정되어 있네요.
기본적으로 1초에 1씩 감소되지만, 라우터에서 처리할 때 1초 미만이여도 1이 감소됩니다. 데이타그램이 맥시멈으로 살아남을 수 있는 시간으로 보면 됩니다.
ghost datagram을 없애기 위한 설정입니다.
Protocol
8 bits가 할당됩니다.
upper layer의 protocol을 나타냅니다. 즉, transport layer의 protocol이 무엇인지 나타내는 필드이고요, 값은 6으로 설정되어 있습니다.
6일 경우에 TCP를 나타내나 봅니다.
Header Checksum
16 bits 할당입니다.
0x739e 값을 가지는데, validation 기능이 꺼져있다고 하네요. 이건 와이어샤크 자체 설정같습니다. 헤더 값에 표현이 없네요.
Source Address
32 bits 할당입니다.
로컬 호스트의 192.168.0.6에서 보냈습니다. ip 주소의 동일하게 32bits를 할당하네요.
인터넷으로 넘어갈 때는 라우터에서 NAT를 하기 때문에, dst에서 fragment를 받을 땐 라우터의 IP일 것입니다.
Destination Address
32 bits 할당입니다.
104.74.158.33으로 보냈습니다.
Transmission Control Protocol
RFC 793: https://datatracker.ietf.org/doc/html/rfc793#section-3.1
Segment 의 시작
68 4a 9e 21
이 fragment의 header 마지막 값인데요, 바로 이 다음에
segment가 나오는 것을 확인하실 수 있습니다.
TCP 정보
Source port
16 bits 할당입니다.
fragment는 호스트간 통신 패킷이라 그런지 헤더에 ip가 있었지만, segment는 프로세스간 통신 패킷이라 port가 있네요!
Client port는 61841 입니다.
Destination Port
16 bits 할당입니다.
https 통신이라 443포트로 요청하네요.
Sequence Number
32 bits
Sequence Number: 0 (relative sequence number)
Sequence Number (raw): 2573254770
첫 데이터의 sequence number를 의미합니다. 실제 값은 2573254770인데, 와이어샤크가 분석툴이라 그런지 relative sequence number라고 해서 첫 데이터의 번호를 0으로 설정해주네요. 보다 보기 편합니다.
Acknowledgment Number
32 bits
실제값도 0으로 설정되어 있습니다. 3way handshake에서 첫 번째 절차인 SYN이기 때문에 ack가 0으로 설정되어 있네요.
(서버로부터 받은 seq가 없으니 디폴트로 0으로 설정해두는 것이겠지요.)
Data Offset
4 bits
options 필드가 variable이기 때문에 존재합니다.
data가 언제 시작하는지 알려주죠.
여기선 값이 1011(2)로 11을 나타냅니다.
The number of 32 bit words in the TCP Header.
TCP 헤더의 32bit words 수를 나타낸다고 합니다.
즉 11 word라는 뜻이고 그 1 워드가 32 bits 이므로,
11 * 32 bits = 11 * 4 bytes = 44 bytes
를 나타냅니다.
Flags
bit vectors로 사용 유무를 표기합니다.
Reserved
6 bits
반드시 0이어야 합니다. 미래를 위해 사용될 값이라네요. rfc 문서상에서는 6 비트하는데, 와이어 샤크상에서는 3비트로 되어 있네요.
현재, 사용하고 있긴 한가 봅니다.
Reserved가 3bits로 설정되어 있고,
Nonce, CWR, ECN-Echo가 각각 1비트씩 할당받고 있네요.
Control Bits
6 bits 할당입니다.
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Syn 작업 중이라 Syn을 나타내는 비트가 1로 설정되어 있습니다.
Window
16 bits
receiver(server)에게 sender측의 receive buffer의 여유공간을 알려주기 위한 것.
flow control을 위한 field로 보면 됩니다.
초기에 2^16 bytes로 설정됩니다.
3way handshake 중 3단계가 되어야 client에서 tcp에 관련된 buffer와 variable을 할당하죠.
Checksum
16bits
Urgent Pointer
자세한 내용은 모르겠습니다.
Options
variable bits (가변 길이)
전공 책에서는 잘 안쓴다고 하는데 사용하네요??
포맷이 총 2가지가 있다고 합니다.
Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option:
Case 1: A single octet of option-kind.
Case 2: An octet of option-kind, an octet of option-length, and the actual option-data octets.
case 1
1byte로 option 종류만 표기하는 것,
case 2
옵션 종류(1byte) / 옵션의 길이 (1byte) / 실제 옵션 데이터 (n bytes)
로 표기
옵션의 길이 값은 옵션종류 1byte + 옵션길이 1byte + 실제옵션데이터 nbyte → 2 + n이 됨.
Options 중 하나인 Maximum segment Size를 보면,
02 04 05 b4
입니다.
1byte | 1byte | 2bytes |
option 종류 | option 길이 | option필드에 대한 값 |
02 | 04 | 05 b4 |
Maximum Segment Size | 4 bytes. (1bytes + 1bytes + 2bytes) | 1460으로 MSS가 1460 임을 표기. |
3Way-Handshake
Client
ip: 192.168.0.6 port: 61841
Server
ip: 104.74.158.33, port: 443
- Client가 Server에게 SYN segment를 전달합니다.
- 동기화 하자~ 연결하자 뜻입니다.
- SEQ = 0으로 설정됩니다. (relative고, 실제 값: 2573254770)
- application layer data는 존재하지 않습니다.
- window scale option: Options에서 window scale을 6으로 설정해두었습니다. 따라서, client의 window field에 적힌 값 << 6 (2^6) 이라고 server는 알아야 합니다. 3번째 단계에서 정확한 값을 알 수 있죠.
- Server는 [SYN, ACK] segment를 전달합니다.
- SYN는 connection 의미에서 1로 설정
- ACK는 client segment를 받았다는 의미에서 ACK = 1로 설정됩니다.(실제 값: 2573254770 + 1)
- application layer data는 존재하지 않습니다.
- server가 tcp를 위한 buffer와 variable를 초기화 합니다.
- 서버의 SEQ = 0으로 설정됩니다.(실제 값: 4054166202)
- flag에서 ACK = 1, SYN = 1로 설정됩니다.
- server의 window scale option은 7이네요. 따라서 이후 server의 window size field << 7 이 실제 윈도우 사이즈입니다.
- Client는 [ACK] segment를 전달합니다.
- ACK의 실제 값은 4054166202 + 1 입니다.
- 이때 client측의 tcp와 관련된 buffers와 variables가 초기화 됩니다.
- window 사이즈가 131712bytes네요. 이 값은 [SYN]에서 보냈던 window scale의 shit count = 6으로 설정했었고, window field의 값이 2058이므로, 2058 << 6 = 2058 * (2^64) = 131712가 된 것입니다.
- application layer data가 실릴수도 있고 안 실릴수도 있다 했는데, 여기선 안 실렸네요.
'컴퓨터과학 기초 > 네트워크' 카테고리의 다른 글
TLS 통신 패킷 분석 (0) | 2022.06.24 |
---|---|
[computer networking] Chapter 3.2 Multiplexing and Demultiplexing (0) | 2021.05.30 |
TCP server의 포트 번호에 대해 - 두 소켓의 포트 번호는 같을 수 있다. (5) | 2021.05.30 |
[computer networking] Chapter 3.1 Introduction and Transport-Layer Services (0) | 2021.05.23 |
TCP 소켓 (0) | 2021.05.03 |