[SK 쉴더스 루키즈] 네트워크 - TCP, UDP, IP 헤더, ICMP, 단편화

4 way handshake

 

CLOSE_WAIT

- 클라이언트에게 응답

 

LAST_ACK

- 서버 입장에서 클라이언트한테 할당했던 리소스를 종료 요청(진짜 종료는 아직 아님)

 

TIME_WAIT

- 서버에서 연결은 끊었지만 아직 클라이언트측에서는 연결을 끊지 않은 상태.

netstat -an

연결 종료 시 서버 측에서 먼저 끊고 클라이언트는 시간을 두고 나중에 끊는다!

그 이유는?

client-> server 마지막 ACK가 중간에 손실이 나면 server는 응답을 못 받았으니까 계속 FIN 재전송을 하게 된다. 

그런데 이미 client에서는 연결을 끊었기 때문에 server가 보내는 FIN 응답을 받지 못한다. 

결국 FIN이 계속해서 client에 쌓이게 되는 문제가 발생한다.

 

따라서 두 번의 FIN이 올 시간만큼만 기다리다가(TIME_WAIT) client도 closed 하는 것이다.

 

 

UDP vs TCP vs IP

UDP

- 비신뢰성, 비연결성

- 헤더길이가 고정되어 있음(고정길이헤더) -> 8byte

- 항상 데이터가 있다.

 

UDP checksum

UDP 헤더만이 아니라 IP 정보까지 포함해서 계산한다.

1) Pseudo Header(가짜 헤더)

- ip 프로토콜(udp=17) + src ip + dest ip + udp header len

 

2) UDP Header

- src port + dest port + len + checksum(=0)

 

3) data

- 실제 전송 데이터

 

계산

1. 전체를 16비트 단위로 나눔

2. 1) + 2) + 3)

3. 1의 보수를 취함.

 

TCP

- 가변길이 헤더(20-60byte) ->  option전까지가 20byte이고 option이 40byte

- 데이터가 없을 수도 있다.

TCP는 IP와 다르게 total length를 안 줌. 안 주는데도 3 whs때 len을 더해서 ACK를 준다는 건 정말로 데이터를 잘 받았다는 뜻!

seq number: 데이터에 번호를 붙여줌

 

 

window size(receive window)

   - 0이면 수신자가 받을 수 없는 상태임을 나타냄

   - 0이 계속 나오면 수신지에 이상이 있는 건 아닌지 상태를 체크해봐야 한다.

 

TCP options

- window scale factor

  문제)

  TCP 헤더의 window size 필드는 16비트이다. 2^16=65535 byte = 최대 64kb까지만 전송 가능.

  -> 고속 네트워크에서 64KB는 너무 작다.

 

  해결) window size * window  scale 을 해서 윈도우 크기를 키운다.

실제 윈도우 크기 = Window Size × 2^(scale factor)

Window Scale = 7 이면
실제 윈도우 크기 = 65535 × 2^7
               = 65535 × 128
               = 약 8MB

 

NOP, EOP

NOP

- No-Operation option

- tcp option 앞부분 빈칸 채우기 용. -> tcp 헤더는 블록당 32bits를 맞춰야 함

- 1byte씩 여러개 사용 가능.

 

EOP

- End of Option

- tcp option 뒷부분 빈칸 채우기 용.

- 1byte  단위. 오직 한번만 사용 가능.

 

 

TCP flags

- URG: 이 데이터 급하니까 순서 무시하고 먼저 처리해 

- ACK: 3WHS, 4WHS, 데이터 전송

- PSH: 앞 뒤 연관되어 있는 패킷 없어. 바로 보내

- RST: 비정상종료

- SYN=1: 3 WHS 과정 중이구나

- FIN: 정상종료(4WHS) 과정 중이구나

ACK=1, PSH=1

Urgent pointer

- 긴급 데이터의 끝 위치를 가리키는 오프셋

- 현재 시퀀스 번호 기준으로 어디까지가 urgent 데이터인지 알려주는 것

 

TCP checksum

TCP data도 같이 체크. IP 헤더도 같이 체크

 

1) Pseudo Header(가짜 헤더)

- ip 프로토콜(tcp=6) + src ip + dest ip + tcp header len

 

2) UDP Header

- src port + dest port + len + checksum(=0)

 

3) data

- 실제 전송 데이터

 

계산

1. 전체를 16비트 단위로 나눔

2. 1) + 2) + 3)

3. 1의 보수를 취함.

 

IP

- 가변길이 헤더(20-60byte)

- header len도 있고 total len도 있다

len이 total len

- ver 4 bit / header len 4bit

4bit씩 나눠쓴다를 명시

total length 16bit -> 전체 크기: 최대 2^16=65536 byte

 

TTL(Time To Live)

최대 홉 수 (시간 x). 너무 많은 홉을 패킷들이 지나지 않게 제한해주는 역할

ttl 값은 os가 결정해서 내보낸다.

TTL 값은 홉을 지날 때마다 1씩 감소한다. 요청이 가다가 0이 되면 그냥 죽는다.

ttl 설정을 너무 크게 하면 목적지가 존재하지 않는데도 불구하고 좀비처럼 망을 게속해서 떠돌 수 있기 때문에 적당히 설정을 해야 한다.

디폴트 홉 수 128개

디폴트 홉 수 변경 방법

• 명령어: netsh interface ipv4 set global defaultcurhoplimit=64
• 레지스트리 편집: HKEY LOCAL MACHINE \SYSTEM\Current\~~~~

tracert

맨 왼쪽 숫자는 홉 수(TTL)를 의미한다.

 

최대 TTL값을 제한해서 ping을 날려보자.

내 컴퓨터에서 8.8.8.8까지 가려면 12 TTL을 거쳐야하는데, 지금 TTL값이 최대 7로 잡혀져 있기 때문에 더 이상 갈 수가 없다.

10.222.18.140이 TTL이 7이 되는 시점이다.

 

tracert는 TTL값을 하나씩 늘리면서 중간중간 잘 가는 지 확인하는 명령어이다.

 

 

 

protocol(저 그림에선 upper layer.)

SAP(Service Access Point)

누구를 싣고 가고 있는지 표시(윗 계층 애들 중에)

4계층 애들 중에 TCP를 담아서 가고 있다.

 

TCP의 넘버는 6번이다.

C:\Windows\System32\drivers\etc\protocol

IP checksum

data 는 빼고 함. checksum 자신도 뺌.(당연)

헤더의 오류를 검증하기 위해 사용

무결성 보장, 패킷 헤더의 변조를 확인.

 

 

checksum 비교

SW 기반 (tcp, udp, ip checksum)

CPU가 직접 계산하는 방식

장점

- os 레벨에서 제어 가능

 

단점

- cpu부하 큼: 트래픽 많으면 성능 저하

- 속도 느림: 고속 네트워크에서 병목 발생

 

 

HW 기반(nic fcs)

NIC가 대신 처리

장점

- CPU 영향 없음

 

단점

- L2까지만 검사. ip/tcp 레벨 오류는 못 잡음.

- 오류나면 그냥 폐기(복구 없음)

 

 

단편화

데이터 크기가 크면 쪼개서 보내야 한다. 단편화는 4계층에서 할 수도, 3계층에서 할 수도 있다.

ip에서 identification 필드의 값이 똑같고, offset이 다르다면 단편화가 진행된 것!

(원래 id 값은 다 달라야 함. 고유한 값이라)

 

flag 필드는 3개로 나눠진다.

- Reserved bit: 항상 0으로 세팅. 미래를 위해 예약된 비트. 현재는 사용 안 함

- Don't fragment: 1 > 이 패킷 단편화 하지 마라 / 0 > 단편화 해도 됨

- More fragments: 뒤에 단편화 패킷이 더 있는가

 

more fragments: 1 > 뒤에 조각 더 있어

 

 

more fragments: Not set > 뒤에 조각 더 없어

 

MTU(Maximum Transfer Unit)

-  IP 헤더 + IP 페이로드(tcp 헤더 + tcp data)

-  L2계층. NIC가 한 번에 전송할 수 있는 최대 프레임 크기.

- 1500 byte(Ethernet)

ethernet header: 14byte / CRC: 4byte / packet size: 1500byte → 총 나가는 데이터는 1518byte이다

- LAN 카드에 따라 크기가 정해짐

  But, MTU의 사이즈는 os 레벨에서 조절할 수 있다.

   방법 1. 레지스트리 편집기

   방법 2. netsh 명령어: netsh interface ipv4 set subinterface "이더넷" mtu=1400 store=persistent

MTU 1500

하지만 내 MTU만 바꿔서 되는게 아니라 지나가는 path의 router들의 MTU도 다 맞춰져 있어야 한다.

 

MSS

- TCP payload만

- L4 계층

- TCP가 한 번에 보낼 수 있는 최대 데이터 크기

- 헤더 미포함. 순수 tcp data만

- MSS = MTU -ip,tcp 헤더

[IP 헤더 20][TCP 헤더 20][     TCP Data 1460     ]
            [-------- IP payload ----------------]
                         [------ MSS 1460 -------]

- MTU처럼 크기가 정해져 있는 것 x. MTU에 따라 값이 바뀜

 

3계층 vs 4계층

3계층에서 단편화했을 때 재조립 시간이 많이 걸리고, 4계층에서 단편화했을 때는 재조립 시간이 적게 걸린다.

이유?

4계층 단편화 유실 시

해당 세그먼트만 재전송 → 빠르게 복구
→ 대기 시간 최소화

- Seq 번호로 재조립

- 유실된 세그먼트만 재전송(SACK) 가능

 

 

3계층 단편화 유실 시

전체 재전송 → 또 기다림 → 또 유실 가능
→ 대기 시간이 기하급수적으로 늘어날 수 있음

- Fragment Offset으로 재조립

- 조각 하나가 유실되면 전체가 재전송되어야 한다.

 

 

추가

- UDP는 단편화 안 한다.

 

 

ICMP

IP의 단점인 비신뢰성, 비연결형을 보완. 3계층 프로토콜

ip의 body에 기생해서 존재한다. 혼자 떠돌아다닐 수 없다.

메시지 종류

- 오류 보고 메시지      >>>>>>>>>>>>>     error reporting

- 질의 메시지: 정보 취득 위함 >>>>>>>     echo request/reply

ping 명령어를 통해 echo request를 날릴 수 있다.

 

ping [게이트웨이]

req, reply

ping은 기본적으로 4개의 ICMP Echo Request를 보낸다. 응답도 와야 하므로 총 8개의 패킷을 볼 수 있다.

 

 

ping -l 100 192.168.45.1

100바이트짜리 데이터를 담은 ICMP 패킷을 보내라

 

ping -l 4000 192.168.45.1

단편화가 되어 들어간 것을 확인할 수 있다.

MTU 1500이고 데이터 4000이니까 (+ip header 20byte) 1480, 1480, 나머지~ 이렇게 나눠진다.

+ ICMP 헤더: 8

조각데이터	크기	offset
1	1480	0
2	1480	1480
3	1048	2960

 

 

ping -f 192.168.45.1

단편화 금지

 

DF: Don’t Fragment

ICMP는 네트워크 계층에서 오류 및 제어 메시지를 전달하기 위한 프로토콜로, TCP/UDP 통신 중 발생하는 오류를 상위 계층 대신 전달한다.

ping은 ICMP를 직접 쓰고, TCP/UDP는 문제 생기면 ICMP를 통해 오류를 전달받는다.

추가

DNS - UDP? TCP?

- 일반 DNS 쿼리는 기본적으로 UDP 사용(53번 포트)

- Zone Transfer(영역전송) 일때는 TCP 사용

  - 전체 DNS 레코드를 동기화할 때

     -> 데이터 양이 많고 신뢰성이 중요함 -> TCP 사용