보다 나은 내일, 다이어리

https://gray-behavior-aa7.notion.site/5cd2baa12dd849468989ac4c3e2233a3?pvs=4

Router는 L3 Switch지만 Host라고도 할 수 있음 (IP도 다 부여, 컴퓨터라고도 할 수 있음)

라우터에 NIC가 여러개 있을 수 있다.

패킷이라는 것이 처리될 때, 라우터 같은 Inline 장치가 어떻게 처리될까?

라우터 내부에서 외부로 통신을 할 때 NIC#1에서 출발하여 IP→TCP→Process→TCP/IP →NIC#2 의 경로를 탈 수 있지만 User모드, Kernel모드, HW를 나누는 경계선을 건널 때마다 waiting 시간이나 CPU를 사용하기 때문에 전산 비용이 비싸진다.

그러므로 NIC#1 ⇒ NIC#2 로 한번에 가도록 하는 HW기반 통신을 하면 ‘가속했다’고 얘기하면서 굉장히 빨라진다.

그런데 NIC#3이 또 있을 수도 있다.

따라서 NIC#1에서 출발하여(=네트워크로 프레임 단위 데이터가 들어와서 패킷 단위로 잘라지든 해서 데이터를 Read했다) IP단에서 처리한 뒤 write를 해야 할 때, NIC#2로 보낼지 NIC#3로 보낼지 인터페이스를 선택을 해야 함

그런데 만약 Read를 했는데 write를 안한다면? 패킷이 필터링되어서 drop이 됨

패킷의 정보를 보고 어디로 보낼지 결정해야 하는데 L3 Switch니까 IP주소를 보고 할 것이다. 그런데 두 개의 NIC 중 적절한 게 없다면 못보내서 Drop되는 경우도 있다.

라우터가 IP단에서 단지처리만 한다면 L3 Switch, Router만이지만, 패킷을 보안적인 측면도 생각해서 처리하면 패킷 단위의 필터링 방화벽이 된다. 필터링을 거쳐서 Bypass 또는 Drop도 하게 되는 것이다.

*Inline 구성이란??

• 인라인 구성은 모든 트래픽이 해당 보안 장비를 물리적으로 거쳐야만 목적지로 전송될 수 있도록 네트워크를 구성한 것을 말한다.
• 상/하단 장비와 동일 대역대에 위치하며 기능을 수행하는 포트에 IP 설정이 필요없는 장비

패킷 단위의 감시대상이 장비를 통과하는 모든 트래픽

• Inbound 트래픽 : 방향성이 내부를 향함. 클 → 서버
• Outbound 트래픽 : 방향성이 외부를 향함. 서버 → 클

Bypass를 하든지 Drop을 하든지 !

출처: (널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

https://run-it.tistory.com/40

• socket + stream
• TCP + Segment (MSS)
• IP + packet (MTU)
• NIC + Frame
• IP와 Driver 사이에 있는 공간
  • Filter → Filter에서 넘어가면 ByPass, 걸러지면 Drop
  • 필터할 필요가 없다면 Sensor → 항상 ByPass면서 감시하면서 수집, 캡쳐만 함 (예. Npcap 드라이버)
  • Wireshark가 이 캡쳐들을 디코딩함 즉, Analyzer
  • 그런데 만약 카톡을 수집한다면 도감청에 잡혀갑니다. 그런 의미에서 Sniffer라고도 함
  • 그러므로 적법한 목적 상의 수집인지가 중요합니다. 윤리의식 중요!!
• 트래픽이 호스트에서 네트워크쪽으로 나가는 것이 Outbond, 그 반대가 Inbound

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

Header + Payload

• Header에서 TCP인지 IP인지 특징 : 20 byte
• Payload
  • MSS (Maximum Segment Size) : 1460 byte
  • MTU (Maximum Transmission Unit) : 1500 byte

• Data : 2^{16} byte (64 KB) 까지 → Total Length가 16 bit 이므로 총 2^{16}가지의 수를 표현할 수 있음

(1KB = 1024Byte)

• IHL (Internet Header Length) : 주로 5 bit
• TOS (Type Of Service) : 대역폭 품질 관리 시 기재
• Identification, Flags, Fragment offset : 단편화와 관련됨
  • MTU가 1400일 때 1500 크기를 보내야 할 때 단편화해서 보내야 하는데
  • 보낼 때 순서를 알아야 하므로 ID가 필요
• TTL (Time To Live) : 패킷이 인터넷에 너무 오래 있어서 버려져야 하는지 여부 알려줌
  • 인터넷에선 라우터라는 거대한 집합체가 패킷을 유통한다. 그 과정에서 문제가 생길 수 있으므로 R→R으로 이동할 때마다 TTL을 1씩 감소시킨다. 그러면 TTL이 언젠가 0이 될 텐데 그때 그 라우터가 패킷을 버린다.
• Protocol : 상위 계층 프로토콜을 가리킴, L4
• Header Checksum : 오류여부 확인

잘 정리된 사이트: https://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-18편-IP-Header-IP헤더-구조

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

L2에서는 Mac 주소 (48bit)

네트워크는 한 마디로 switch의 집합체다..!

• NIC
• L2 Access switch ****: PC와 같은 endpoint들이 처음 만나게 되는 switch (방 하나)
• L2 Distribution switch : switch를 위한 switch (건물의 층 하나)
• Router : 전체 PC들의 gateway 역할 (건물 하나)
• Internet
• Uplink : 상위 계층 스위치로 연결됐다는 의미 (L2 Access → L2 Distribution)
• Link-up: 케이블 연결이 딱 됐다는 의미
• Link-down : 연결이 해제됐다는 의미

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

UDP 통신이란? 

• User Datagram Protocol, 데이터를 데이터그램 단위로 처리하는 프로토콜
• 비연결형, 신뢰성 없는 전송 프로토콜
• 데이터그램 단위로 쪼개면서 전송해야 하기 때문에 L4, transport Layer

TCP와 UDP가 나온 이유

• IP의 역할은 Host to Host만을 지원한다. 하나의 장비 안에서 수많은 프로그램이 통신해야 할 경우는 IP만으로는 한계가 있다 
  • =>프로세스별 구분 지을 수 있는 Port 번호가 등장하게 됨
• IP에서 오류가 발생하면 ICMP에서 알려준다. 하지만 알려주기만 할 뿐 대처는 못하므로 상위 프로토콜인 TCP와 UDP가 나오게 됐다

ICMP ? 인터넷 제어 메시지 프로토콜. 네트워크 컴퓨터 위에서 돌아가는 OS에서 오류 메시지를 전송받는데 쓰임

TCP와 UDP의 오류 해결법?

• TCP: 데이터의 순차성과 분실, 중복 등을 자동으로 보정해줌으로써 송수신 데이터의 정확한 전달을 보장
• UDP: IP가 제공하는 정도의 수준만을 제공하는 간단한 IP 상위 계층의 프로토콜, 확인 응답을 못하므로 TCP와 달리 에러가 날 수 있고 재전송이나 순서가 뒤바뀔 수 있는 번거로움 존재하며 신뢰도 떨어짐

UDP Header

• Source Port: 시작 포트
• Destination Port: 목적지 포트
• Length: 길이
• Checksum: 오류 검출
  • 중복 검사의 한 형태로, 오류 정정을 통해 자료의 무결성을 보호하는 단순한 방법

UDP는 왜 사용할까?

• 데이터의 빠른 처리, 신속성 때문 !!
• 주로 실시간 방송과 온라인 게임에서 사용됨
• 네트워크 환경이 안 좋을 때, 끊기는 현상을 생각하자

DNS에서 UDP를 사용하는 이유

• DNS Request의 양이 작음 -> UDP Segment에 담길 수 있음
• 3 way handshaking으로 연결을 유지할 필요가 없음 (TCP는 Protocol Overhead가 큼 )
• Request의 손실은 Application layer에서 제어함으로써 신뢰성이 추가될 수 있음 (Timeout이나 재전송 작업을 통해서)
• DNS: port 53번
• 하지만 TCP를 사용하는 경우?
  • Zone Transfer(=DNS 서버 간의 요청을 주고받을 때 사용하는 transter)를 사용해야 하는 경우! 
  • 데이터의 크기가 512바이트(UDP의 제한크기) 를 넘기거나 응답을 못받은 경우

TCP와 UDP 통신 실습

• UDP

UDP server 코드

from socket import *

serverName = "192.168.0.108"
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind((serverName, serverPort)) # 12000 포트로 들어오는 프로세스를 소켓에 바인딩
print("The server is ready to receive")

while True:
    message, clientAddress = serverSocket.recvfrom(2048) # 서버에 들어온 정보를 2kbyte로 계속 읽어들임
    modifiedMessages = message.decode().upper() # 읽어드린 바이트 정보를 str로 변환 후 대문자화
    serverSocket.sendto(modifiedMessages.encode(), clientAddress) # 클라이언트 목적지 주소도 명시해서 보냄

UDP client 코드

from socket import *

serverName = "192.168.0.108"
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM) # UDP의 소켓타입=SOCK_DRGAM
message = input("input lowercase sentence")

clientSocket.sendto(message.encode(), (serverName, serverPort)) # 서버의 IP 주소와 port 번호를 명시해서 서버에게 데이터 요청
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
print(modifiedMessage.decode())

clientSocket.close()

결과

1. UDP는 비연결형 프로토콜로,  데이터 전송 시에 IP 주소와 port 번호를 명시해줘야 한다.
2. sendTo() 메서드를 사용

• TCP

TCP server 코드

from socket import *

serverPort = 12000
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind(("", serverPort))
serverSocket.listen(1)
print("The server is ready to receive")

while True:
    connectionSocket, addr = serverSocket.accept() # 요청을 기다리고 받은 후엔 connection 소켓이라는 새로운 분리된 연결을 만듬

    sentence = connectionSocket.recv(1024).decode()
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence.encode()) # UDP와 달리 connection이 있으므로 목적지 주소가 필요없음

    connectionSocket.close() # 이때 serverSocket은 닫지 않음

TCP client 코드

from socket import *

serverName = "192.168.0.108"
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM) # TCP의 소켓타입=SOCK_STREAM
clientSocket.connect((serverName, serverPort))
sentence = input("Input lowercase sentence")

clientSocket.send(sentence.encode()) # 서버의 목적지 주소 명시안해도 됨
modifiedSentence = clientSocket.recv(1024)
print("From Server: ", modifiedSentence.decode())
clientSocket.close()

결과

1. TCP는 연결형 프로토콜로, 서버와 클라이언트는 항상 1대1로 연결되어서 통신하므로 따로 명시해줄 필요가 없다.
2. send() 메서드를 사용

참고

https://gyoogle.dev/blog/computer-science/network/UDP.html

(개발자와 네트워크 관리자 모두에게 중요한 개념!★)

• user단의 process가 실행(I/O 혹은 R/W)되면 커널단의 TCP/IP와 디바이스 드라이버를 거치고 NIC를 타고 인터넷으로 연결된다.
• user model application이 TCP에 도달하기 위한 인터페이스가 Socket(=파일의 일종)
• socket의 단위는 stream, 길이는 얼마나 긴지 모름
• stream을 TCP에 보내기 위해 segment로 일정 단위로 댕강댕강 잘라냄
• segment를 한번 encapsulate되면 packet 형식이 되고
• packet이 또 encapsulate되면 frame이 된다.

<패킷의 구성>

• 패킷 하나당 1500byte(MTU, Maximum Transfer Unit)정도
• Header(!송장!)와 Payload(!택배!)로 나뉨

Header는 IP(L3, 20바이트)와 TCP(L4, 20바이트)로 나뉨

payload는 보통 1460바이트가 됨.

⇒ 즉, stream 데이터를 1460바이트씩 끊어내서 Payload로 넣는 것임!

• DPI (Deep Packet Inspection) : payload까지 다 검사하는 것
• encapsulate는 segment를 내용물이라고 한다면 이것을 포장해서 택배박스에 넣는 작업
• frame은 트럭처럼, encapsulate된 패킷들을 다시 encapsulate하는 개념으로 생각하면 됨

출처(널널한한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

TCP 통신이란?

- 신뢰성과 순차성을 가진 네트워크 통신 방식

- 신뢰성 없는 네트워크 환경에서 reliable함을 보장

- network congestion avoidance 알고리즘 사용

신뢰성 보장 시 발생가능 문제

1. 손실 : 송수신 시 패킷 손실

2. 순서바뀜: 패킷 순서가 바뀜

3. congestion : 네트워크가 혼잡

4. overload : 수신자 버퍼 용량 초과

흐름제어

- 송수신 간 데이터 처리 속도 차를 해결하기 위한 기법

- 수신측이 송신측보다 처리속도가 느릴 때 문제 발생

- 수신측에서 제한된 용량이 초과 시 데이터가 손실될 수 있으며, 손실된다면 불필요하게 응답과 데이터 전송이 송수신 간에 빈번이 발생하게 됨

🗝 해결법

1. Stop and Wait

- 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송

2. Go Back N (Sliding Window)

- 수신측에서 설정한 window size (=송신 후 수신까지 동안 전송가능한 패킷의 수)만큼 세그먼트를 송신

- 송신측은 ack 프레임을 받으면 ack 프레임 수만큼 경계가 확장됨

- 송신측에서 ack가 안된 가장 오래된 패킷 번호부터 돌아가서 다시 순서대로 보낸다

혼잡제어

- 송신측의 데이터는 지역망이나 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 된다. 혼잡이 가중되면 오버플로우나 손실이 발생할 수 있다.

- 따라서 송신측에서 보내는 데이터의 전송속도를 강제로 줄임

- 혼잡: 네트워크 내에서 패킷 수가 과도하게 증가하는 현상

- 혼잡제어: 혼잡현상을 방지하거나 제거하는 기능

🗝 해결법

1. AIMD (Addictive Increase/Multiplicative Decrease)

- 처음에 패킷을 하나씩 보내고 문제가 없으면 window size를 1씩 증가시키며 전송 ws+1

- 전송실패하거나 time-out이 되면 패킷 보내는 속도를 절반으로 줄임  ws*0.5

- 네트워크에 참여한 순서와 관계없이 모든 호스트의 window size가 평행 상태로 수렴하게 되는 특징.

- 문제점: 네트워크의 대역폭이 펑펑 남아도는 상황에도 너무 조금씩 늘리면서 접근하므로, 제대로 된 속도로 통신하기까지 시간이 오래 걸림

2. Slow start

- 처음에 패킷 하나씩 보내고, 문제가 없으면 각각의 ack 패킷마다 window size를 1씩 늘려주기 때문에 한 주기가 지나면 window size가 2배로 된다.  지수함수꼴로 증가

- 혼잡현상 발생 시 window size를 1로 떨어뜨림 -> 혼잡현상이 발생했던 window size의 절반까지는 지수함수꼴로 증가 -> 그 이후는 1씩 증가

3. 빠른 재전송

- 혼잡제어 추가된 정책 중 하나

- 먼저 도착해야 할 패킷이 나중에 도착하더라도 ack 패킷을 보냄

- 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷 순번을 ack 패킷에 실어서 보내므로, 중간에 하나가 손실되면 송신 측에서 순번이 중복된 ack 패킷을 받게 되고, 이를 감지하는 순간 재전송함

- 중복 패킷을 3번 받으면 재전송 -> 혼잡감지하고 window size를 줄임

- Tahoe는 기본적으로 Slow start를 사용하다가 혼잡이 느껴지면 AIMD로 전환하는데, 빠른 재전송을 처음으로 도입한 방법

4. 빠른 회복

- 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시킴

- 빠른 회복을 적용하면 혼잡상황을 한번 겪고 나면 순수한 AIMD 방식으로 동작함

- Reno는 빠른 회복을 도입한다.

참고

https://evan-moon.github.io/2019/11/26/tcp-congestion-control/

https://gyoogle.dev/blog/computer-science/network/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%20&%20%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4.html